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 ambiguouty 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 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:

Commits

Each commit message fulfils three criterias:

• Style: <verb> <information> intending to <reason> in imperative mood

The following sub-phrases in the message gives the observer the following insights of the newly implemented functionality:

verb --> an abstract picture of the implemented functionality

information --> a context of the implemented functionality

reason --> an insight into the impact of the implemented functionality

• Content: A 50-maximum-character textual description solely dedicated to deliver information regarding the new changes accompanied by the commit.

• Metadata: No issue-number is included in the message itself. However, information concerning other related functionality that is affected by the new commit will be disclosed in information or reason if the associated issue is related to another issue.

Examples:

1. "Add new class 'Apple' inheriting from 'Fruit' intending to improve the design by removing redundancy"

2. "Fix 'MusicPlayer' intending to successfully play music"

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 main.

Kanban board

TODO

Code

• Each issue has a code-implementation