From 35297775dc121ffc018cf03c69df3e7add32a7b1 Mon Sep 17 00:00:00 2001 From: Lars Simon Winzer Date: Fri, 10 Apr 2026 10:28:10 +0200 Subject: [PATCH] Add: Milestone Achievements section to contribution guidelines --- CONTRIBUTING.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 92a520a..c6028a9 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -12,6 +12,7 @@ Since this project is part of a course at the University of Basel, the [Code of - [Creating an issue](#creating-an-issue) - [During implementation](#during-implementation) - [Collaborative work](#collaborative-work) + - [Milestone Achievements](#milestone-achievements) - [Git Workflow](#git-workflow) - [Creating a branch](#creating-a-branch) - [Working on a branch](#working-on-a-branch) @@ -49,6 +50,20 @@ Issue or Task in GitLab **before** any implementation begins. centrally visible and searchable. - Before starting work that overlaps with an existing issue, check its comment thread first to avoid duplicating effort. +### Milestone Achievements +For every process and product-related milestone achievement, there is a dedicated milestone task. + +- **Do not create a branch directly from a milestone task.** +- Instead, create a normal implementation task (using the regular task template) and reference the milestone task there. +- In the merge request, reference the milestone task again. +- If the milestone condition is fully met, you may use `Closing #` to close the milestone task. +- If it is only partially addressed, use `Relates to #` or `Contributes to #` so the milestone task stays open. + +Milestone tasks may, but do not have to, be assigned to a specific person. + +- If multiple people are involved, contribution is tracked through linked tasks that reference the milestone task. +- For small topics, a Milestone Achievement may be assigned to one person. Others should only contribute on request and should not modify components introduced under that achievement without coordination. + ## Git Workflow We use a **feature branch -> main** strategy. The `main` branch is always in a releasable state.