Bug Workflow for Desktop Team Engineers
The desktop engineers are spending too much time keeping up with triaging incoming bugs, so have precious little time left for fixing bugs and implementing features requested by users. This discussion will be a brainstorming then deciding session where we strive to figure out a new approach to incoming bugs that works for QA, engineers, the community, and users.
Blueprint information
- Status:
- Complete
- Approver:
- Martin Pitt
- Priority:
- Essential
- Drafter:
- Rick Spencer
- Direction:
- Needs approval
- Assignee:
- Rick Spencer
- Definition:
- Approved
- Series goal:
- Accepted for karmic
- Implementation:
-
Implemented
- Milestone target:
- None
- Started by
- Rick Spencer
- Completed by
- Martin Pitt
Whiteboard
rickspencer3 2009-06-04: making a proper blueprint, as there is some work involved based on the discussion
rickspencer3 2009-06-12: adding work items from spec, requesting approval
pitti 2009-06-12:
- did some minor fixes to the BP
- can we change "The desktop team engineers will limit bugs assigned to them to bugs that are targeted to be fixed in the current cycle." to "to bugs which they can and will realistically work on, preferably in the current cycle"? I think it makes sense to assign bugs to you which are to be worked on in the next cycle, but the overall list should have a manageable and honest size
- end user story: I don't think we can set the expectation that every apport-submitted bug will be triaged; I don't expect the number of bug submissions to drop with ubuntu-bug
- I think we need to extend the "upload watch" period to 4 days; reason is that it can take several hours already to reach security.
- Empty design section; perhaps just move the "Approach" section contents into "Design" to have a more standard structure?
- "needs info" button: is the idea of that to respond with canned responses? If so, you need to be able to select from several
- I think you swapped the definition of "Fix" and "Community" buttons
I'd like to get Seb's and Alex' review here as well, since they will/should use that tool heavily.
rickspencer3 200906-17:
- I made each of the recommended changes, and adjusted work items as appropriate
- I pinged Seb and Alex to review, but feel that we don't need to block on that as the tools should iterate based on feedback from their usage as well.
pitti 2009-06-18: approved
seb128 2009-06-18:
- do we want the tool to be a quick way to review bugs or a tool to triage those? requesting the right informations in the needinfo case and tracking reply takes quite some work and we might just tag the bugs as "somebody need to triage the issue and get enough informations to make it useful" rather than sending it to needinfo with a stock reply
- could the "community" mode let the user change the bug priority (some issues are clearly wishlists for example) and open an upstream task to signal that the issue is an upstream one?
es20490446e 2012-01-19 suggests a related blueprint:
https:/
Work Items:
Find package function: DONE
A list view with enough information for assessing the impact of the bug: DONE
A list view that hides bugs after they are triaged: DONE
A log of triaging actions saved locally: POSTPONE
A way to quickly select batches of bugs: DONE
A needs info button that can edit bugs in bulk to need info: DONE
A needs to be worked on button: DONE
A would be nice to get worked on button: POSTPONED
Treeview throws away previously triaged bugs: DONE
Ability to modify comment text while triaging: POSTPONE
a cron job that detects recent uploads: POSTPONE
create a special subscription to bugs on packages related to recent uploads: POSTPONE
set headers for those bug mails so that engineers can sort: POSTPONE
unsubscribe after a set period of time: POSTPONE
