Qt-contributors-summit-2013-QtCSBugDiscussion: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
m (Categorize) |
||
| (4 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
{{Cleanup | reason=Auto-imported from ExpressionEngine.}} | |||
[[Category:QtCS2013]] | |||
==Bug Management Discussion== | ==Bug Management Discussion== | ||
Qt | Qt Contributors' Summit 2013 | ||
Session Goal: Find out more about how to make Bug Management more efficient | Session Goal: Find out more about how to make Bug Management more efficient | ||
| Line 13: | Line 15: | ||
Goal for Bug triaging: | Goal for Bug triaging: | ||
* Can/should we get the number of untriaged bugs down to | * Can/should we get the number of untriaged bugs down to 'zero'? | ||
* Verification steps: What are they? | * Verification steps: What are they? | ||
* Triaging steps: What are they? | * Triaging steps: What are they? | ||
| Line 22: | Line 24: | ||
* Who is responsible for what? | * Who is responsible for what? | ||
** Maintainers should get their number of untriaged bugs down to zero once a week? | ** Maintainers should get their number of untriaged bugs down to zero once a week? | ||
** Can we have a qt-project wide | ** Can we have a qt-project wide "bugzy super tuesday"? | ||
** Can we allow more people to prioritise bugs? | ** Can we allow more people to prioritise bugs? | ||
| Line 28: | Line 30: | ||
** Will it help to get more people involved? | ** Will it help to get more people involved? | ||
* Use of | * Use of "fixed version"-field in Jira | ||
* How to help people get involved: | * How to help people get involved: | ||
| Line 39: | Line 41: | ||
===Minutes from the session.=== | ===Minutes from the session.=== | ||
* We have untriaged bugs, we may not be able to triage them all, but we should keep | * 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 | * 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 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 | ** checking if a bug report is not missing an important data, so it would be possible to reproduce it in future | ||
| Line 53: | Line 55: | ||
** approvers should be in the group by default | ** 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 | 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 | * 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 fill it until an issue is really fixed, which means merged | ||
** we do not want to use the field for estimation | ** we do not want to use the field for estimation | ||
| Line 61: | Line 63: | ||
* Jira workflow was designed for much bigger team, that includes QA department, it should be simplify | * Jira workflow was designed for much bigger team, that includes QA department, it should be simplify | ||
** We decided that | ** 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. | ** 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 | ** It would be nice to have a transition from Open to Closed state | ||
Latest revision as of 17:30, 6 January 2017
| 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