|
|
| Line 1: |
Line 1: |
| ==Bug Management Discussion==
| |
|
| |
|
| Qt Contributors’ Summit 2013
| |
|
| |
| Session Goal: Find out more about how to make Bug Management more efficient
| |
|
| |
| * Gather suggestions, and make some decisions.
| |
|
| |
| '''<span class="caps">WIP</span>'''<br /> Please add to the list if there are topics related to Qt Bugs that you would like to discuss.<br /> After the QtCS, this page will turn into a summary of what was discussed.
| |
|
| |
| ===Some topic suggestions for the Agenda===
| |
|
| |
| Goal for Bug triaging:
| |
|
| |
| * Can/should we get the number of untriaged bugs down to ‘zero’?
| |
| * Verification steps: What are they?
| |
| * Triaging steps: What are they?
| |
| ** Verify that can reproduce as described
| |
| ** Verify that can reproduce on reported platform with latest version in /dev
| |
| ** Prioritize
| |
|
| |
| * Who is responsible for what?
| |
| ** Maintainers should get their number of untriaged bugs down to zero once a week?
| |
| ** Can we have a qt-project wide “bugzy super tuesday”?
| |
| ** Can we allow more people to prioritise bugs?
| |
|
| |
| * How can we get more people involved, and in which areas?
| |
| ** Will it help to get more people involved?
| |
|
| |
| * Use of “fixed version”-field in Jira
| |
|
| |
| * How to help people get involved:
| |
| ** Need How to use jira doc?
| |
| ** wiki: how to get started?
| |
|
| |
| * How to make sure we fix the right bugs
| |
| ** P0 and P1s and beyond
| |
|
| |
| ===Minutes from the session.===
| |
|
| |
| * We have untriaged bugs, we may not be able to triage them all, but we should keep it’s count as low as possible.
| |
| * We agreed on “triaging” definition. Triaging consist of:
| |
| ** checking if a bug report is sensible. It means the reported issue is not a result of a user mistake, use of undefined behavior etc.
| |
| ** checking if a bug report is not missing an important data, so it would be possible to reproduce it in future
| |
| ** setting a priority
| |
| ** optionally the bug report may be verified. It it is reproduced then it should be accept which means moved to open state
| |
|
| |
| Rationale: It looks like the most common behavior of people triaging bugs.
| |
|
| |
| * Who can prioritize bugs?
| |
| ** whoever ask
| |
| ** we will create a special group in jira
| |
| ** approvers should be in the group by default
| |
|
| |
| Rationale: We do not have man power and we need help. We do not expect anyone to destroy our precious bugs reports or play “ping*pong” with a priority.
| |
|
| |
| * What does it mean “fixed version” in bug report
| |
| ** we do not fill it until an issue is really fixed, which means merged
| |
| ** we do not want to use the field for estimation
| |
| ** we now that it can be filled automatically, it would be nice to implement that.
| |
|
| |
| * Jira workflow was designed for much bigger team, that includes QA department, it should be simplify
| |
| ** We decided that “in progress” state means that someone started work on a bug or it have a fix which is not merged yet. Time statistics doesn’t show anything, anyway.
| |
| ** Resolved, Verified and Closed should be merged to a single state. Nobody is going through Resloved bugs to verify them.
| |
| ** It would be nice to have a transition from Open to Closed state
| |