path: root/wiki/src
diff options
author127.0.0.1 <>2019-04-19 19:18:41 +0000
committerIkiWiki <>2019-04-19 19:18:41 +0000
commit49c41c625f1a7a62c3713dbb888e8d65684effeb (patch)
tree98c76cc25ca7802bf4eff4d065b06f8ae283e163 /wiki/src
parent9d7d9a9ea25e3ce3186ab7e1609459f7b20555c3 (diff)
This reverts commit 2a6fcdb33fc07a0cede2bf970dde8188328004ec
Diffstat (limited to 'wiki/src')
1 files changed, 14 insertions, 41 deletions
diff --git a/wiki/src/blueprint/GitLab.mdwn b/wiki/src/blueprint/GitLab.mdwn
index 25f42c6..7f406c9 100644
--- a/wiki/src/blueprint/GitLab.mdwn
+++ b/wiki/src/blueprint/GitLab.mdwn
@@ -78,47 +78,6 @@ issue, which allows one to find duplicates later on if needed.
And to ensure we can list issues that have really been resolved,
add a "Duplicate" label.
-## Status
-Each open issue must have one of these labels:
- - "1. To do" (previously: "Confirmed")
- - "2. Doing" ("In progress" was too vague: it could mean anything
- between "someone did the first 2% of the work 5 years ago" to "this is
- what I'm focused on today")
- - "3. To review" (previously "Ready for QA")
-… except issues that were just created and need to be triaged by Help
-Desk (previously: "New").
-This lends itself to issue boards with 4 columns: "1. To do", "2.
-Doing", "3. To review", and "Closed".
-Closing an issue means one of:
- - The fix or feature the issue is about was merged and will be in
- a future release (previously: "Fix committed" for the next release,
- "Resolved" for 4.0).
- To list these issues: closed issues whose milestone is a version
- was not released yet.
- - The fix or feature the issue is about is already available to
- our users (previously: "Resolved").
- To list these issues: closed issues whose milestone is a version
- that's been released already.
- - We've rejected it or marked it as a duplicate (previously:
- "Rejected" and "Duplicate")
- To list these issues: closed issues with respectively the "Rejected"
- or "Duplicate" label.
-Most closed issues will still have the "3. To review" label.
-That should not cause any problem in practice. Worst case this can be
-fixed automatically, either via a webhook or a scheduled batch job.
## Other issues metadata
- Target version → Milestone
@@ -131,6 +90,20 @@ fixed automatically, either via a webhook or a scheduled batch job.
- One can set multiple labels so we could perhaps merge "Category"
and "Affected Tool". For example, a ticket about Thunderbird
persistence could have the two "C: email" and "C: persistence" labels.
+- Status: use a set of labels, each with a numerical prefix, because
+ it's an ordered flow:
+ - "0. Needs triage" (ideally, have it set automatically on newly
+ created issues; probably requires a webhook; otherwise, can be
+ done in batch regularly on all issues that have no status label
+ set)
+ - "1. Backlog" ("Confirmed")
+ - "2. Working on it" (clearer than the too vague "In progress")
+ - "3. To review" (previously "Ready for QA")
+ - "4. To release" (i.e. closed issue but code not released yet,
+ to replace "Fix committed" which is too often misunderstood)
+- Status = Resolved → closed with neither "Rejected" nor "Duplicate" label
+- Status = Duplicate → closed with "Duplicate" laben
+- Status = Rejected → closed with "Rejected" label
- Log time → Time tracking
- Due date → Due date
- Starter → dedicated label