Wikimedia Release Engineering Team/Bug triage

This is a preliminary checklist for triaging the Release Engineering Team backlog.

Culling
[ ] Is this actually for our team? [ ] Is this a duplicate?

Tags
[ ] Tagged "Release-Engineering-Team-TODO" if we plan to act on it anytime soon [ ] Tagged "Release-Engineering-Team-TODO" current milestone (e.g., 2020-01 to 2020-03 (Q3)) if we plan to do it this quarter [ ] Tagged with one of "Release-Engineering-Team"s subprojects: * Release Engineering Team (Code Health) * Release Engineering Team (Local Dev) * Release Engineering Team (Pipeline) * Release Engineering Team (Unit & Int & System Tooling) * Release Engineering Team (CI & Testing services) * Release Engineering Team (Development services) * Release Engineering Team (Deployment services) [ ] Tagged with an appropriate component * Release Pipeline * Train Deployments * Scap * Release-Engineering-Team * Quibble * Deployments * Developer Productivity * Continuous-Integration-Infrastructure * Continuous-Integration-Config * Zuul * Phabricator * local-charts * Diffusion * dev-images * Github-mirrors * Gerrit * GerritBot

Priority
This blog post about Bugs & Priority by Brian Michel is a good take on bug priority. We may need something more specialized for us in future; i.e., we may want to consider if a feature request is on our roadmap. See also Base SLOs for code

Assignment
In general, we assign things to people when people are *just about* ready to do them, or they're actively working on them.

We should avoid cookie-licking—having people assigned to tasks that they have no intention of touching for, say, 30 days. To combat this problem, we should un-assign tasks that are not actively being worked on or tasks that we have no intention to work on.

There is a danger here of "fun" work being duplicated; i.e., since no one is assigned to a task two people pick up the task and start working on it. Claim tasks quickly (but judiciously) and drop tasks aggressively is probably the only remedy here.