Qt-contributors-summit-2013-QtCSBugDiscussion

This article may require cleanup to meet the Qt Wiki's quality standards. Reason: Auto-imported from ExpressionEngine. Please improve this article if you can. Remove the {{cleanup}} tag and add this page to Updated pages list after it's clean.

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.

WIP
Please add to the list if there are topics related to Qt Bugs that you would like to discuss.
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