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: #40382

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:

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)