Commit 9a020f22 authored by 127.0.0.1's avatar 127.0.0.1 Committed by IkiWiki
Browse files

This reverts commit 1e00810d

parent 80baeaf0
......@@ -12,7 +12,7 @@ See also the [GitLab doc on issues](https://docs.gitlab.com/ce/user/project/issu
One can make an issue
[confidential](https://docs.gitlab.com/ce/user/project/issues/confidential_issues.html)
when creating it; confidentiality can later be toggled on/off at any
time. A confidential issue is visible only by whoever created it and
time. A aonfidential issue is visible only by whoever created it and
by project members with at least
[Reporter](https://docs.gitlab.com/ce/user/permissions.html#project-members-permissions) access.
......@@ -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
......@@ -181,11 +154,6 @@ For example:
- I can click "Add todo" on an issue and it will appear on my list
of Todos (regardless of whether I'm the assignee or not).
## Core team (self-)management
XXX: how to replace e.g.
<https://redmine.tails.boum.org/code/projects/tails/issues?query_id=307>?
## Custom queries
We use Redmine custom queries to have easy access to named searches
......
......@@ -11,13 +11,7 @@ enabled, without the user having to do _anything_ special about it.
Means: use the shim signed by Microsoft + GRUB2.
We don't support booting on a custom built kernel, so that should be
relatively easy. Except:
* The kernel won't allow loading an unsigned `aufs` module so we need
to migrate to `overlayfs` ([[!tails_ticket 8415]]).
* `overlayfs` does not allow stacking enough layers for our current
upgrade system, so we need to [[!tails_ticket 15281 desc="stack one
single SquashFS diff when upgrading"]].
relatively easy.
Resources
=========
......
......@@ -21,12 +21,12 @@ beginning of May.
- February 2019: intrigeri
- March 2019: sajolida
- April 2019: TheNerdyAnarchist & emmapeel
- May 2019: u
- May 2019:
- June 2019:
- July 2019:
- July 2019: u
- August 2019: intrigeri
- September 2019:
- October 2019: u
- October 2019:
- November 2019:
- December 2019:
......
......@@ -20,7 +20,6 @@
* clone upstream git
git clone https://gitlab.gnome.org/GNOME/gnome-shell.git gnome-shell-git
git submodule update --init
* disable upstream VCS tag checking
......
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