[Development] Bug management and jira workflow
jedrzej.nowacki at digia.com
Tue Jul 23 13:25:44 CEST 2013
At the Qt Contributor Summit, we had a really good discussion about bugs and
jira, here is the summary:
- 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
- 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 know that it can be filled automatically, it would be nice to
- 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
- 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
More information about the Development