Wikimedia Release Engineering Team/Bug triage
|This page is under construction|
Please help review and edit this page.
This is a preliminary checklist for triaging the Release Engineering Team backlog.
[ ] Is this actually for our team? [ ] Is this a duplicate?
[ ] Tagged "Release-Engineering-Team" [ ] Move to appropriate column *
Doingif you plan to work on it within this quarter *
Nextif you plan to work on it within the next quarter *
Seenif 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
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.
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.
Helpful information on status at Bug_management/Bug_report_life_cycle.