Jump to content

Wikimedia Release Engineering Team/Bug triage

From mediawiki.org

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


Culling

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

Tags

[edit]
   [ ] 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

[edit]

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

[edit]

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

[edit]

Helpful information on status at Bug_management/Bug_report_life_cycle.