Merge branch 'tpa-rfc-12' into 'master'

TPA-RFC-12: add triage and office hours to TPA-RFC-2

Closes team#40354 and team#40382

See merge request tpo/tpa/wiki-replica!18

policy/tpa-rfc-2-support.md

@@ -73,11 +73,39 @@ in doubt, just file the issue with as much details as you can.
 
 You can also mark an issue as confidential, in which case only members
 of the team (and the larger "tpo" organisation on GitLab) will be able
-to read it.
+to read it. It is up to the submitter to decide whether an issue
+should be marked as confidential, but TPA might also mark tickets as
+confidential if they feel the information contained should not be
+public.
+
+As a rule of thumb, privately identifiable information like IP
+addresses, addresses, or email addresses should not be
+public. Information relevant only to `tor-internal` should also be
+handled only in confidential tickets.
 
 [GitLab]: https://gitlab.torproject.org/tpo/tpa/team/
 [direct link to a new ticket form]: https://gitlab.torproject.org/tpo/tpa/team/-/issues/new
 
+### Real-time support: office hours
+
+Once a week, sysadmins try to have a full work day where an admin is
+available to answer questions in realtime, in our video-conferencing
+platform (currently [Big Blue Button](howto/conference)). The space can be used for
+problems that cannot be easily worded, more controversial discussions
+that could just use a phone call to clear the air, audio tests, or
+just to hang out with the crew or say hi.
+
+Some office hours might be reserved to some topics, for example "let's
+all test your audio!" If you have a particularly complex issue in a
+ticket, TPA might ask you to join the office hours for a debugging
+session as well.
+
+Typically, office hours are held during business hours of the staff
+available, which is currently the America/Eastern timezone, between
+about 9:00 to 16:00. The schedule might change without this policy
+being updated. The schedule and the location of the BBB room are
+available in the topic of the IRC channel (above).
+
 ### Private question and fallback: email
 
 If you want to discuss a sensitive matter that requires privacy or are
@@ -185,6 +213,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,25 @@ 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.
 
-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.
+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.
+
+Items in a specific queue can be prioritized in the dashboard by
+dragging items up and down. Items on top should be done before items
+at the bottom. When created in the `Open` queue, tickets are processed
+in FIFO (First In, First Out) order, but order in the other queues is
+typically managed manually.
 
 [Kanban]: https://en.wikipedia.org/wiki/Kanban_(development)