User:BCornwall-WMF/Traffic task workflow
Material may not yet be complete, information may presently be omitted, and certain parts of the content may be subject to radical, rapid alteration. More information pertaining to this may be available on the talk page.
This workflow is specific to the Traffic team. Other teams' definitions, expectations, and workflows will differ. Policies more broadly applicable to all teams (such as how to handle security tasks) still apply.
Triage
All tasks set to Needs Triage are to be reviewed:
- Are they fit for a Traffic ticket?
- Is this actionable work or just "We should think about doing this thing"?
- Is this ticket unlikely to sit and rot from inactivity?
If the answer is yes to all of these, then the ticket should be triaged with a priority, signalling that the work is accepted and something that is intended to be worked on.
Prioritized tickets with inactivity will be automatically un-prioritized (i.e. placed back into Needs Triage) for re-review.
The goal is to keep the number of Needs Triage tickets to zero.
Backlog review
A Phabricator bot is tasked with automatically un-prioritizing inactive tickets. It's up to humans to routinely triage tickets or close them.
Priorities
"Priorities" are a combination of severity/priority on the following:
- Running services
- Progress on work
- Security coverage
- Risk of causing incident
- Unblock Now!
- "Drop everything now and fix it", just as it is understood in the rest of SRE
- High
- Actively impeding or at high risk of causing incident
- Medium
- Potentially impeding or at moderate risk of causing incident
- Low
- Not impeding and can be worked around, but should be fixed
In general, work on high-priority tickets before medium; medium before low. However, time estimating is also worth consideration: If one high-priority task would take a long time to complete yet a low-priority task a day then it's understandable to choose working on the low-priority task. These are guidelines, however: To borrow from a phrase from that one weird cult, "people over process".
Status
While it's common for Phabricator projects to utilize kanban boards to organize task statuses, these are best left to the Status field. The Status field is a definitive indicator used SRE-wide. Using the kanban columns as work progress indicators duplicates information in confusing ways (e.g. Task A set to In Progress while left in a Needs Triage column).
Closing unserviced tickets
Traffic has attempted to wrangle the task queue a number of times before (be that extreme amounts of categorization, prioritization of ticket stacks, inclusively keeping tickets around in hopes that someone will eventually service them, etc.) Long-term, the results were always the same: An accumulation of zombie tickets that were never going to get serviced.
The traffic team is incredibly small. It's an unfortunate reality that we will be unable to service most tickets that come our way. To both keep our team efficient and maintain reasonable expectations from external parties we must make sacrifices to tickets we think will not be realistically serviceable. See #External communication for how to gently communicate this subject in an appropriate way.
Low priority bugs come with an expiration. Routine task list pruning may provide opportunity to close tickets if:
- systems/progress continue to function long enough without completing a task
- it feels like servicing will likely not occur
If a task ever becomes important to service later then the team can always re-open/re-prioritize it.
External communication
Public engagement is tricky due to both unending workloads and limited personnel. The unfortunate reality is that some tasks will never be serviced. It may be tempting to merely leave a task open: "Eventually someone will get to it", one might say. Truthfully, the task will rot (and often become irrelevant). To uphold transparent internal/community communication, routine pruning of our task pool will keep expectations clear and workload expectation more realistic.
When closing a task filed by the general public use gentle, humanistic language (or at the very least a canned response) to provide the user(s) transparency on why the task is closed. Closing tasks without action can initially cause disappointment or hurt, so approaching the realities of work prioritization with empathetic engagement is important.
Tags
It's common practice for teams to add their team's tags for "radar" visibility. While the intentions are sound, this gives rise to a overflowing bin of tasks. If individuals want to follow a task, they can subscribe to the task. If the ticket does not require action by the Traffic team, consider refraining from adding the Traffic tag (or removing it if it's already there).
That said, Traffic does include a Radar/Not for service column, so do use it if it seems useful.