Contributing to the Repository

This guide outlines the specific steps that should be followed when contributing code to one of the repositories, whether it be the Swift or the Flutter repository.

1. Create an Issue

Before starting any development, create an issue.

The naming convention should include the type of issue (e.g., feat, bug, docs) followed by a name that describes the action that will be performed on the codebase. It should be in the imperative mood (e.g., feat/add-user-authentication, bug/fix-app-crashing-on-startup).

The issue should:

1. Be associated with a milestone: The milestone should correspond to the sprint in which the issue will be addressed.
2. Have an assignee: Assign the issue to yourself or the relevant team member.
3. Be linked to a project: Associate the issue with the Team-15-Kanban project board.
4. Include appropriate labels: Use labels to categorize the issue. At least, the one referring to the micro-sprint in which the issue will be addressed (e.g., MS7), and possibly more specific ones (e.g., bug, enhancement, documentation).

2. Link the Issue to a Branch

Once the issue is created, link it to a branch where the development will take place. The branch should have the same name as the issue, but it should reference the issue by number after the type and before the name (e.g., feat/12-add-user-authentication).

The new branch must stem from the develop branch.

All branches must be created from develop and eventually merged back into develop. Thus, the develop branch is the integration branch where all development work is consolidated.

The main branch contains the public, stable code and will only be updated by merging from develop after it is deemed stable. The main branch should always reflect the latest stable version of the codebase and possibly the latest release.

3. Commit Changes

While working on your branch, ensure that commits are atomic, meaning one commit per significant action.

All commits must be written in imperative mood and be clear and concise describing the action performed. For example, `

4. Create a Pull Request (PR)

Once your development work is complete, create a Pull Request (PR) to merge your branch into develop.

All PRs must:

• Be linked to an issue: The PR should reference the issue it addresses.
• Be assigned to a reviewer: Assign the PR for review to a non-author team member.
• Describe the changes: Include a description of the changes made. If the commit messages are self-explanatory, there's no need to restate them. However, any important decisions or non-trivial changes should be clearly explained.
  • Include UI changes: If there are any changes related to the UI, include images or GIFs to illustrate the changes.

The PR should be able to be merged automatically. If that is not the case, the author must merge the develop branch into their branch and resolve any conflicts.

After the PR is reviewed and approved, it can be merged into develop. The PR should be closed after the merge.