Commit e653f5ff authored by mrodzis's avatar mrodzis 🌿
Browse files

style: beautify Markdown

parent 7183d9f9
......@@ -3,14 +3,12 @@
The following is a set of guidelines for contributing to the Ahiqar project's front end.
Feel free to propose changes whenever the workflow could be improved!
## Issue Tracker
Issues are created and assigned by the project's Product Owner during a sprint planning in the [issue tracker](
As soon as you start working on a assigned issue, switch its label to `Doing`.
This will cause the issue to be moved into the right list of the repository's [board](
## Internal Workflow
### Reporting Bugs or Change Requests
......@@ -19,7 +17,6 @@ Bugs and change requests are managed by the project's Product Owner.
Please report any problems that aren't related to to bugfix/feature you're working on right now to her/him.
She/he will create an issue in the correct repository and ask for assignees in the course of the next sprint planning.
### Git Flow
For developing in Ahiqar we use `git flow` as a branching and development model.
......@@ -41,8 +38,10 @@ A well-tried workflow is:
1. A developer decides to work on a feature. She commits her changes to a separate feature branch. After some time she finishes the feature and wants it to be part of the development branch.
2. The developer creates a merge request and assigns everybody she sees fit to properly review her code to it.
3. To avoid diffusion of responsibility, she also assigns one of the chosen assignees as MUST. This means that this person has to approve the MR, otherwise the merge cannot be done. Although GitLab sends notifications to everybody who is newly assigned to a MR, she should notify the MUST assignee personally (in case he or she doesn't notice the mail sent by GitLab). The MR settings are:
* The MR is associated with the current sprint's [milestone](
* The boxes for "Squash Commit" and "Deleting branch after Merge" are ticked
* The MR is associated with the current sprint's [milestone](
* The boxes for "Squash Commit" and "Deleting branch after Merge" are ticked
4. The MUST assignee reviews the changes according to style, variable naming, understandability, documentation provided, functionality, etc. If everything is to his or her liking, he or she approves the MR. The other assignees are free to review the code as well. **Note:** MRs without docs should not be accepted.
5. After the MR has been (dis)approved, the assignee removes his- or herself from the list of assignees. The MUST assignee informs the developer over the review being done.
6. The developer merges her changes into the development branch.
# Ahiqar Frontend
The (static) frontend for the Ahiqar project.
The (static) frontend for the Ahiqar project. <>
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment