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"
   [ ] Move to appropriate column
       * Doing if you plan to work on it within this quarter
       * Next if you plan to work on it within the next quarter
       * Seen if you don't know when we will work on it
   [ ] Tagged with an appropriate component
       * Release Pipeline
       * Train Deployments
       * Scap
       * Quibble
       * Deployments
       * Developer Productivity
       * Continuous-Integration-Infrastructure
       * Continuous-Integration-Config
       * Zuul
       * Phabricator
       * Phatality
       * 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.

Status

Helpful information on status at Bug_management/Bug_report_life_cycle.