Qt wiki will be updated on October 12th 2023 starting at 11:30 AM (EEST) and the maintenance will last around 2-3 hours. During the maintenance the site will be unavailable.

Qt-contributors-summit-2013-QtCSBugDiscussion: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
 
No edit summary
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

Revision as of 13:59, 24 February 2015

Retrieved from "https://wiki-qt-io-staging.herokuapp.com/index.php?title=Qt-contributors-summit-2013-QtCSBugDiscussion&oldid=5702"