[Development] Bug management and jira workflow

Blasche Alexander Alexander.Blasche at digia.com
Tue Jul 30 13:00:22 CEST 2013


Now I am confused. We don’t want to use “Fixed Version” for estimation. At the same time you say having two different fields is confusing.

How do I set an estimation value? There must be a way to specify the estimation/target. Please don’t offer the Meta task for release x.y option or just a comment. A filter must be able to find the tasks planned for release x.y .

--
Alex

From: development-bounces+alexander.blasche=digia.com at qt-project.org [mailto:development-bounces+alexander.blasche=digia.com at qt-project.org] On Behalf Of Motyka Rafal
Sent: Tuesday, 30 July 2013 12:41
To: Nowacki Jedrzej; development at qt-project.org
Subject: Re: [Development] Bug management and jira workflow


Hello,



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.

Thanks!



Regards,



/Rafal







Rafal Motyka

Quality Assurance

Digia, Qt



Email: rafal.motyka at digia.com<mailto:rafal.motyka at digia.com>

Mobile: +47 95005389

http://qt.digia.com

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

Qt Facebook: www.facebook.com/qt<http://www.facebook.com/qt>

Qt Twitter: www.twitter.com/qtcommercial<http://www.twitter.com/qtcommercial>

------------------------------------------------------------------

PRIVACY AND CONFIDENTIALITY NOTICE

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> [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<mailto:development at qt-project.org>
Subject: [Development] Bug management and jira workflow



Hi,





  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

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





Cheers,

  Jędrek

_______________________________________________

Development mailing list

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

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


More information about the Development mailing list