Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Orion/Bug Triage"
< Orion
(Created page with "== How to triage a bug == # Make sure there is an owner for the bug. The owner must not be the inbox user. Use the component owner table to determine the owner. Being the own...") |
m |
||
| (38 intermediate revisions by 8 users not shown) | |||
| Line 1: | Line 1: | ||
| − | == How to | + | == How to Triage a Bug == |
| − | + | The bug system is the heart beat of an open source project. In order to understand how an open source project is working, it is often necessary to understand how the project uses its bug system. | |
| + | |||
| + | Here are the rules we use to triage a bug: | ||
| + | |||
| + | # Verify that the bug is reproducible. If not, ask for details. Verify that the enhancement request is reasonable. | ||
| + | # Find and owner for the bug: | ||
| + | #* Use the component owner table (TBD) to determine the owner. | ||
| + | #* Being the owner means watching the bug, being knowledgeable in the code area and knowing how to answer questions and help someone who wants to work on it. | ||
# Set the bug priority. If unsure leave it as default (P3). | # Set the bug priority. If unsure leave it as default (P3). | ||
# Make sure it is in the right bugzilla component | # Make sure it is in the right bugzilla component | ||
| − | #* P1: Stop ship. Fix it now! | + | #* '''P1''': Stop ship. Fix it now! |
| − | #* P2: Important, in progress | + | #* '''P2''': Important, in progress |
| − | #* P3: Maybe someone will get to it | + | #* '''P3''': Maybe someone will get to it |
| − | #* P4: Nice to have, probably won't get to it | + | #* '''P4''': Nice to have, probably won't get to it |
| − | #* P5: Probably won't happen | + | #* '''P5''': Probably won't happen |
# Add the "helpwanted" keyword for easy, non-critical bugs that would be good for a newcomer to work on | # Add the "helpwanted" keyword for easy, non-critical bugs that would be good for a newcomer to work on | ||
# Make sure the severity is set to "enhancement" for feature requests. For other severities leave it as selected by bug originator. | # Make sure the severity is set to "enhancement" for feature requests. For other severities leave it as selected by bug originator. | ||
| − | |||
| − | Bugzilla | + | Once a bug is triaged, it is addressed in priority order by the owner. Bug that are unowned are not being worked on. |
| + | |||
| + | == How we deliver (work management) == | ||
| + | We use an iterative development model for work planning, defined at 2 week intervals: | ||
| + | *2017-01-27 | ||
| + | *2017-02-10 | ||
| + | *2017-02-24 | ||
| + | *... | ||
| + | These milestones are added to the whiteboard space in the bugzilla.<br> | ||
| + | <br> | ||
| + | We plan for an iteration at the beginning of the previous iteration using the backlog, only P1, P2s and P3s. These are assigned to people with the intent of completing the work in that iteration.<br> | ||
| + | <br> | ||
| + | A bugzilla issue that has a milestone attached to it, should also have an “Assignee”. If the assignee is actively working on the defect they will set it to the ASSIGNED state.<br> | ||
| + | |||
| + | ===Backlog=== | ||
| + | Backlog should be allocated a priority and story points as input to iteration planning. Story points should be assigned in the whiteboard using a fibonacci sequence where:<br> | ||
| + | <br> | ||
| + | '''S:1''' = minutes -> ''"This will take minutes."''<br> | ||
| + | '''S:2''' = hours -> ''"This will take hours."''<br> | ||
| + | '''S:3''' = days -> ''"This will take days."''<br> | ||
| + | '''S:5''' = weeks -> ''"This will take weeks."''<br> | ||
| + | '''S:8''' = months -> ''"This will take months."''<br> | ||
| + | '''S:13''' = quarters -> ''"This will take a quarter or more"''<br> | ||
| + | '''S:21''' = half year -> ''"This will take half a year to a year."''<br> | ||
| + | '''S:40''' = years -> ''"This will take years."''<br> | ||
| + | |||
| + | == Bugzilla Cleanup == | ||
| + | |||
| + | Developers simply cannot fix every bug that comes in (sad, but true). So, in an effort to keep the Orion Bugzilla in a reasonable state, about once per calendar year we go through the entire thing and close out stale bugs. | ||
| + | |||
| + | The process we use for this mass-triage is as follows: | ||
| + | # We discuss on the weekly status call a few weeks in advance of the clean up to make sure all interested parties have a chance to comment on the process and / or update bugs they do not want closed. We also decide how far back to set the "cutoff" for when a bug is considered too old / stale. Typically, the rule of thumb is if a bug has not been touched for the last 3 releases, it is stale. | ||
| + | # Then we send out an email to the [https://dev.eclipse.org/mailman/listinfo/orion-dev orion-dev] mailing and a message to our [https://mattermost.eclipse.org/eclipse/channels/orion# mattermost channel]. The message changes a bit each time, but in general it [https://dev.eclipse.org/mhonarc/lists/orion-dev/msg04002.html looks like this]. | ||
| + | # Once the community has been notified, they go through the inboxes they are interested in, either reassigning or setting the ''triaged'' keyword on the bug (all bugs tagged with ''triaged'' will be ignored during the mass triage regardless of their age or "stale-ness"). | ||
| + | # The big day arrives to perform the triage: A bugzilla query is run, followed by using the "multiple bug edit" feature of Bugzilla to close out all the bugs in the query. Each bug closed has a message stating the reason why it was closed with a link back to the notification. For example: | ||
| + | <pre> | ||
| + | Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. | ||
| + | For more details see: | ||
| − | + | https://dev.eclipse.org/mhonarc/lists/orion-dev/msg04002.html | |
| − | + | </pre> | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
Latest revision as of 10:48, 30 March 2017
How to Triage a Bug
The bug system is the heart beat of an open source project. In order to understand how an open source project is working, it is often necessary to understand how the project uses its bug system.
Here are the rules we use to triage a bug:
- Verify that the bug is reproducible. If not, ask for details. Verify that the enhancement request is reasonable.
- Find and owner for the bug:
- Use the component owner table (TBD) to determine the owner.
- Being the owner means watching the bug, being knowledgeable in the code area and knowing how to answer questions and help someone who wants to work on it.
- Set the bug priority. If unsure leave it as default (P3).
- Make sure it is in the right bugzilla component
- P1: Stop ship. Fix it now!
- P2: Important, in progress
- P3: Maybe someone will get to it
- P4: Nice to have, probably won't get to it
- P5: Probably won't happen
- Add the "helpwanted" keyword for easy, non-critical bugs that would be good for a newcomer to work on
- Make sure the severity is set to "enhancement" for feature requests. For other severities leave it as selected by bug originator.
Once a bug is triaged, it is addressed in priority order by the owner. Bug that are unowned are not being worked on.
How we deliver (work management)
We use an iterative development model for work planning, defined at 2 week intervals:
- 2017-01-27
- 2017-02-10
- 2017-02-24
- ...
These milestones are added to the whiteboard space in the bugzilla.
We plan for an iteration at the beginning of the previous iteration using the backlog, only P1, P2s and P3s. These are assigned to people with the intent of completing the work in that iteration.
A bugzilla issue that has a milestone attached to it, should also have an “Assignee”. If the assignee is actively working on the defect they will set it to the ASSIGNED state.
Backlog
Backlog should be allocated a priority and story points as input to iteration planning. Story points should be assigned in the whiteboard using a fibonacci sequence where:
S:1 = minutes -> "This will take minutes."
S:2 = hours -> "This will take hours."
S:3 = days -> "This will take days."
S:5 = weeks -> "This will take weeks."
S:8 = months -> "This will take months."
S:13 = quarters -> "This will take a quarter or more"
S:21 = half year -> "This will take half a year to a year."
S:40 = years -> "This will take years."
Bugzilla Cleanup
Developers simply cannot fix every bug that comes in (sad, but true). So, in an effort to keep the Orion Bugzilla in a reasonable state, about once per calendar year we go through the entire thing and close out stale bugs.
The process we use for this mass-triage is as follows:
- We discuss on the weekly status call a few weeks in advance of the clean up to make sure all interested parties have a chance to comment on the process and / or update bugs they do not want closed. We also decide how far back to set the "cutoff" for when a bug is considered too old / stale. Typically, the rule of thumb is if a bug has not been touched for the last 3 releases, it is stale.
- Then we send out an email to the orion-dev mailing and a message to our mattermost channel. The message changes a bit each time, but in general it looks like this.
- Once the community has been notified, they go through the inboxes they are interested in, either reassigning or setting the triaged keyword on the bug (all bugs tagged with triaged will be ignored during the mass triage regardless of their age or "stale-ness").
- The big day arrives to perform the triage: A bugzilla query is run, followed by using the "multiple bug edit" feature of Bugzilla to close out all the bugs in the query. Each bug closed has a message stating the reason why it was closed with a link back to the notification. For example:
Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you.
For more details see:
https://dev.eclipse.org/mhonarc/lists/orion-dev/msg04002.html