Git workflow

The developed product is defined by numerous milestones/requirements. Each milestone is composed of multiple issues/user stories, which in turn contain specifications and concrete boundaries pertaining to the associated code implementation. The picture below illustrates the defined guidelines for the grouping of milestones, issues, and code:

Milestones - Grouping of functionalities/requirements

• Each milestone has a header Functionalities where the contained requirements are disclosed

Issues - Agreed convention/path of completing fractions of milestones

• Each issue has two headlines with the following content:
• Requirement --> A user story uncovering a persona's desires related to the system in the format as a < persona >, I want to < goal > so that < reason >. If an issue is dependent on functionality originating from other issues, it is also mentioned in this section
• Acceptance criteria --> A functionality breakdown of the aforementioned user story that serves the purpose of eliminating ambiguity in the questioning of whether or not the newly implemented feature satisfies the user story to its fullest extent or not

Lastly, upon creation of an issue, the following actions must be done:

• Set due date serving as a final deadline to complete it
• Assign labels defining the current state, purpose, and priority of it

Labels - Agreed convention of structuring issues

The foundational system for distinguishing the importance of the existing issues in conjunction with the predetermined plan possesses 4 distinct categories and 14 unique tags:

Merge requests

This section concerns two roles with differing obligations:

• Code-implementer: The one pushing the code to a remote branch must confirm that the changes are executable and do these changes in a relevant branch. Once the changes are ready to be pushed to a comprehensive representative branch such as main, creating a merge request that serves as a validation process to protect high-status branches is imperative.
• Reviewer: The one reviewing the code in the merge request, that either updates the label state from pending to approved or blocked depending on his or her view on how the implemented code complies with the team's agreed conventions. Reviewers are also held accountable for providing constructive feedback, enlightening both positive and negative aspects of the code in a sympathetic way favoring the team dynamics.

Closing issues

We only close issues when they are 100% done, meaning they must be executable, satisfy every acceptance criteria, and comply with our design standards where the avoidance of repeatable code is the centralized concept.

Branches

Aiming to protect the main branch, we are working with feature branches originating from issues. Firstly we push working changes to that branch, and once the functionality contained in the branch is done, we merge to the main.

Kanban boards

• Development: solely consists of open and closed issues, providing an overview of the progress of the entirety of the project from start to finish
• Sprints Board: its foundational architecture is based on the three tags dividing the timeline of the project into three equal parts (Sprint 1, Sprint 2, Sprint 3), providing an overview of our progress in each sprint

Code

• Each issue has a code-implementation