From b92878c8e06689070233db5731c91ad9ef798d28 Mon Sep 17 00:00:00 2001 From: Matthias Simon Date: Thu, 24 Oct 2024 10:03:27 +0200 Subject: [PATCH] Add SOP for how-to-process-change-request --- docs/how-to-process-change-requests.md | 90 ++++++++++++++++++++++++++ 1 file changed, 90 insertions(+) create mode 100644 docs/how-to-process-change-requests.md diff --git a/docs/how-to-process-change-requests.md b/docs/how-to-process-change-requests.md new file mode 100644 index 0000000..ddc4bbc --- /dev/null +++ b/docs/how-to-process-change-requests.md @@ -0,0 +1,90 @@ +# How to process a change request + +## Purpose + +This SOP outlines the process for handling change requests using GitLab. GitLab +supports a wide range of different workflows. This makes it easy to get lost in +the many planning features and provided tools. + +This SOP aims to provide a minimal and +[Kanban-like](https://en.wikipedia.org/wiki/Kanban_(development)) process, +which can be extended and customized once the team is comfortable with the +basics. + +When followed correctly: +- Migration from Mantis to GitLab will be smooth and efficient. +- Frustration about the new tool will be minimized. +- You will have a clear understanding of what has been done and what needs to + be done. + +When not followed: +- Inconsistencies in the process may lead to confusion and overwhelm. + +## Procedure + +**Inputs:** +- You are signed in to GitLab +- You have write access to the project + +**Steps** + +0. **Open the [developer + board.](https://labs.etsi.org/rep/mts/ttcn3/standard/-/boards):** You will + see columns for new issues, planned issues, issues in progress, issues ready + for review, issues done, and closed issues. Columns can be minimized to save + space using the arrow in the top right corner of the column. + +1. **New issues:** All open issues that do not belong to one of the other + list appear here. If you want to work an issue: + - assign it to yourself by adding your name in the assignee field on the right + - move it to the To-Do column by dragging it to the right + +2. **Planned issues:** In this column you'll find all issues that are planned + to be worked on, but not started yet. + If you want to start working on an issue: + - assign it to yourself, if not already done + - move it to the work in progress (WIP) column by dragging it to the right + +3. **Issues in progress:** This column contains all issues that are currently + being worked on. If you are working on an issue, make sure to move it to this + column. If you are done with the issue: + - move it to the review column by dragging it to the right + - remove yourself as the assignee + - you may add reviewers by assigning the issue to them + +4. **Issues ready for review:** This column contains all issues that are ready + for review. If you are a reviewer assign the issue to yourself. You may add + questions or comments to the issue comment section. If you are done + reviewing move the issue either to the "Done" column or back to the To-Do if + column if further refinement is needed. + +5. **Issues done:** This column contains all issues that are done, but still + open. The team lead closes the issue by clicking on the "Close issue" + button. + When you close an issue, it is good practice to assign a resolve-label and + a short rationale, if possible. This serves as helpful documentation for + future reference. Following labels are available: + - **Fixed**: The issue was implemented as suggested. Most change requests + will have this label. Additional comments are usually not required. + - **Duplicate**: If an issue is a duplicate of another request use this + label. Also reference the original issue. This makes it easier to navigate + changes. + - Use the **Won't Fix** label for requests that were rejected. If possible + add a short rationale why the request was rejected, or reference a + decision record. Such documentation becomes valuable, should a request + re-opened. For example as is was with the shorthand assignments (`i++`). + - The label **By Design** is used to clarify that the standard is correct + and the issue is not a bug. For example, someone could create a bug-report + that inout-parameters should not require strong-typing, but this is by + design. It avoid issues with references to unions. + +6. **Closed issues:** + Issues that are reviewed and do not need further refinement are moved to the "Done" column + +7. **Use and improve:** An important part of the process is to continuously + improve the process and refine it where necessary. If you have suggestions + for improvements, please share them. + +**Outputs:** +- You will understand the purpose of the developer board and its columns +- You will know how to change the status or assigmnent of an issue -- GitLab