From e45afcf319c5d1ba2e7fa3c5e839f33e6cf125d1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Antoine=20Beaupr=C3=A9?= <anarcat@debian.org> Date: Tue, 14 Sep 2021 17:07:41 -0400 Subject: [PATCH] TPA-RFC-12: reformulate the triage policy We had nothing about the star of the weeks, which was informally specified. This clarifies that it's responsible for routine tasks, but also takes care of clarifying the ticket workflow in the gitlab policy. Closes: tpo/tpa/team#40382 --- policy/tpa-rfc-2-support.md | 19 +++++++++++++++++++ policy/tpa-rfc-5-gitlab.md | 35 ++++++++++++++++++++++++----------- 2 files changed, 43 insertions(+), 11 deletions(-) diff --git a/policy/tpa-rfc-2-support.md b/policy/tpa-rfc-2-support.md index 1d70ace4..a93b2759 100644 --- a/policy/tpa-rfc-2-support.md +++ b/policy/tpa-rfc-2-support.md @@ -205,6 +205,25 @@ Example of routine tasks include: * security upgrades * server reboots +### Triage + +One member of TPA is assigned the "Star of the weeks" every other +week. The Star is responsible for triage, which occurs in GitLab, as +per the [TPA-RFC-5: GitLab migration](policy/tpa-rfc-5-gitlab) policy. + +But the Star also handles routine tasks and interruptions. In that +sense, it acts as a "[interruption shield](https://queue.acm.org/detail.cfm?id=1922541)" by taking care of +small, distracting tasks to let others focus on more long-term +projects. + +In that sense, the Star takes care of the above [routine tasks](#routine) +like server reboots, security upgrades and spam runs. It is also +expected to keep an eye on the monitoring system and organise +[incident response](howto/incident-response) when a more serious issue occurs. It is *NOT* +responsible for fixing *all* the issues and it is expected the Star +will assign work or ask for help in an emergency or if it is +overwhelmed. + ## Supported services Services supported by TPA must fulfill the following criteria: diff --git a/policy/tpa-rfc-5-gitlab.md b/policy/tpa-rfc-5-gitlab.md index 5139c99f..adb42a6d 100644 --- a/policy/tpa-rfc-5-gitlab.md +++ b/policy/tpa-rfc-5-gitlab.md @@ -55,12 +55,16 @@ too many moving parts to cohesively release those as a whole. Instead, it is suggested we adopt the [Kanban][] development strategy which is implemented in GitLab as [issue boards](https://docs.gitlab.com/ee/user/project/issue_board.html). -Issues first land into a "triage" queue (`Open`), then get assigned to -a specific queue as the ticket gets planned. We use the `Icebox`, `Backlog`, -`Next`, and `Doing` of the global "TPO" group board labels. With the -`Open` and `Closed` queues, this gives us the following policy: +### Triage - * `Open`: untriaged ticket +Issues first land into a queue (`Open`), then get assigned to +a specific queue as the ticket gets planned. + +We use the `Icebox`, `Backlog`, `Next`, and `Doing` of the global +"TPO" group board labels. With the `Open` and `Closed` queues, this +gives us the following policy: + + * `Open`: un-triaged ticket * `Icebox`: ticket that is stalled, but triaged * `Backlog`: planned work for the "next" iteration (e.g. "next month") * `Next`: work to be done in the current iteration or "sprint" @@ -72,13 +76,22 @@ a specific queue as the ticket gets planned. We use the `Icebox`, `Backlog`, That list can be adjusted in the future without formally reviewing this policy. +The `Open` board should ideally be always empty: as soon as a ticket +is there, it should be processed into some other queue. If the work +needs to be done urgently, it can be moved into the `Doing` queue, if +not, it will typically go into the `Next` or `Backlog` queues. + +Tickets should *not* stay in the `Next` or `Doing` queues for long and +should instead actively be closed or moved back into the `Icebox` or +`Backlog` board. Tickets should *not* be moved back to the `Open` +board once they have been triaged. + +Tickets moved to the `Next` and `Doing` queues should normally be +assigned to a person. The person doing triage should make sure the +assignee has availability to process the ticket before assigning. + Priority of items in the queues are determined by the *order* of items -in the stack. Tickets should *not* stay in the `Next` or `Doing` queues -forever and should instead actively be closed or moved back into the -`Icebox` or `Backlog` board. Tickets should *not* be moved back to the -`Open` board once they have been triaged. The `Open` board should -ideally be always empty: as soon as a ticket is there, it should be -processed into some other queue. +in the stack. [Kanban]: https://en.wikipedia.org/wiki/Kanban_(development) -- GitLab