Wikimedia Release Engineering Team/Bug triage

From mediawiki.org
Jump to navigation Jump to search

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-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[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.