Conventions

Issue Creation

Each new issue must:

• be labelled appropriately
• either be assigned to self, another member, or a team (who)
• have a deadline where relevant (when)
• be titled correctly
• have a concise description (why + what + how)
• be assigned to project with kanban tags
• be placed under backlog or todo on kanban board

Always include the following infotmation: what, how, why, who, when

Remember to create and label issues before working on any task. DO NOT create or assign issues AFTER the fact.

Example

Issue Management

The issues will be managed through both the GithHub issue manager and the GithHub project kanban board. Each issue must be moved under the appropriate kanban group, starting from backlog or todo, go to each following group, and finally end up in done. Issues must be closed with a comment explaining why, DO NOT close issues without providing context.

Order of operations:

1. Enter title
2. Enter description and deadline
3. Assign issue
4. Pick labels
5. Assign to project
6. Post the issue
7. Pick kanban labels
8. Move to backlog
9. Move to todo
10. Move to in progress
11. Comment on progress if necessary
12. Comment questions and answers if necessary
13. Move to in review
14. Close with comment
15. Move to done

See Kanban board

Meeting Notes

All meetings will have a dedicated note-taker, and the notes will be published on the wiki using the following format:

• Time: Date and Time
• Modality: Face-to-face, Discord, WhatsApp
• Participants: List of names
• Agenda: Purpose of meeting, what will be addressed
• Note Taker: Name
• Discussion & Progress:
  1. Thing that was done 1
  2. Thing that was done 2
  3. etc.
• Action Items:
  1. Thing to be done 1 + deadline + assignee
  2. Thing to be done 2 + deadline + assignee
  3. etc.

Remember to:

• Avoid using vague terms like "everyone"
• Open issues for action items
• Include due dates and assignees for action items
• Be brief and concise, don't use long or vague sentences

Example

Requirement Specification

Requirements will be specified using EARS patterns:

• Ubiquitous: The sysem shall X.
• Event-Driven: When the user X, the system shall Y.
• Unwanted Behavior: If the user X, the system shall Y.
• State-Driven: While the user X, the system shall Y.
• Optional: Where the user X, the system shall Y.

Remember to keep the requirements well-formed, atomic and verifiable. Separate functional and non-functional requirements.

Example: The system shall display post location on a map.

Commits

Commits should be atomic and they should be related to at least one issue.
Commit messages should be like that:

For main repo

Imperative commit message #ISSUENUMBER

Example:

Improve app description in preview mode #25

For mobile repo

[TASK] Imperative commmit message #ISSUENUMBER

Example:

[Pipeline] Add java distribution info for build action #12

Reference: https://cbea.ms/git-commit/

Branching

All code related issues should have their own branches.

feature/ISSUENUMBER-TASK

Example:

feature/36-overall-code-refinement

How to create a branch inside an issue

Screenshots:

https://github.com/SWE574-Fall2023-Group1/SWE574-Fall2023-G1/issues/36#issuecomment-1774143383

Pull Requests

Pull requests should

• have at least one reviewer.
• have at least one assignee.
• be reviewed by its reviwer(s).
• be merged by its assignee(s).