View source for Qt-contributors-summit-2013-QtCSBugDiscussion

==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