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: [email protected] 
[mailto:[email protected]] On 
Behalf Of Motyka Rafal
Sent: Tuesday, 30 July 2013 12:41
To: Nowacki Jedrzej; [email protected]
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: [email protected]<mailto:[email protected]>

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: 
[email protected]<mailto:[email protected]>
 [mailto:[email protected]] On Behalf 
Of Jedrzej Nowacki
Sent: 23. juli 2013 13:26
To: [email protected]<mailto:[email protected]>
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

[email protected]<mailto:[email protected]>

http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development

Reply via email to