[Development] Bug management and jira workflow

Motyka Rafal Rafal.Motyka at digia.com
Tue Jul 30 12:40:38 CEST 2013


This clarification was needed:

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

Otherwise, having a field with two different meanings (like ‘fixed in’ and ‘planned to be fixed in’) would lead to confusion.




Rafal Motyka

Quality Assurance

Digia, Qt

Email: rafal.motyka at digia.com

Mobile: +47 95005389


Qt Blog: http://blog.qt.digia.com/

Qt Facebook: www.facebook.com/qt

Qt Twitter: www.twitter.com/qtcommercial



This message and any attachments are intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error, please contact the sender immediately and delete the message and any attachments accompanying it. Digia Plc does not accept liability for any corruption, interception, amendment, tampering or viruses occurring to this message.


-----Original Message-----
From: development-bounces+rafal.motyka=digia.com at qt-project.org [mailto:development-bounces+rafal.motyka=digia.com at qt-project.org] On Behalf Of Jedrzej Nowacki
Sent: 23. juli 2013 13:26
To: development at qt-project.org
Subject: [Development] Bug management and jira workflow


  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

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




Development mailing list

Development at qt-project.org<mailto:Development at qt-project.org>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130730/c8a1c77a/attachment.html>

More information about the Development mailing list