Re: [Development] Bug management and jira workflow
-- Alex -Original Message- From: development-bounces+alexander.blasche=digia@qt-project.org [mailto:development-bounces+alexander.blasche=digia.com@qt- On terça-feira, 30 de julho de 2013 11:00:22, Blasche Alexander wrote: 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 . The idea from the people in the discussion was that we shouldn't estimate. We're very bad at it. Instead of estimating, I'd go for some generic names that match the branches: any release any minor (feature) release any major release This is not estimation, it's just information about which type of release can contain the change. And those won't require jolly-bumping of versions after a release. Hm this doesn't help me since I have tasks which I want to achieve for the next release (e.g. 5.2) and some which I want for any minor release thereafter. It is merely a todo list for myself. If it is about the bumping then I am happy to bump my own tasks but I need to maintain the list for the next minor release. As long as it is not closed it is not 100% sure anyway. Why don't we accept that any fix in for a non-closed task is a bad estimate. No guarantee. Then we don't have any problems here. -- Alex ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
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.mot...@digia.com Mobile: +47 95005389 http://qt.digia.com Qt Blog: http://blog.qt.digia.com/ Qt Facebook: www.facebook.com/qt Qt Twitter: 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@qt-project.org [mailto:development-bounces+rafal.motyka=digia@qt-project.org] On Behalf Of Jedrzej Nowacki Sent: 23. juli 2013 13:26 To: development@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@qt-project.orgmailto:Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Bug management and jira workflow
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@qt-project.org [mailto:development-bounces+alexander.blasche=digia@qt-project.org] On Behalf Of Motyka Rafal Sent: Tuesday, 30 July 2013 12:41 To: Nowacki Jedrzej; development@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.mot...@digia.commailto:rafal.mot...@digia.com Mobile: +47 95005389 http://qt.digia.com Qt Blog: http://blog.qt.digia.com/ Qt Facebook: www.facebook.com/qthttp://www.facebook.com/qt Qt Twitter: www.twitter.com/qtcommercialhttp://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@qt-project.orgmailto:development-bounces+rafal.motyka=digia@qt-project.org [mailto:development-bounces+rafal.motyka=digia@qt-project.org] On Behalf Of Jedrzej Nowacki Sent: 23. juli 2013 13:26 To: development@qt-project.orgmailto:development@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@qt-project.orgmailto:Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Bug management and jira workflow
On Tue, Jul 30, 2013 at 11:00:22AM +, Blasche Alexander wrote: 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 . deadline != estimation ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Bug management and jira workflow
On terça-feira, 30 de julho de 2013 11:00:22, Blasche Alexander wrote: 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 . The idea from the people in the discussion was that we shouldn't estimate. We're very bad at it. Instead of estimating, I'd go for some generic names that match the branches: any release any minor (feature) release any major release This is not estimation, it's just information about which type of release can contain the change. And those won't require jolly-bumping of versions after a release. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Bug management and jira workflow
Nice session. Unfortunately, I was attending to something else in parallel. Have you discussed the triage bugs documentation to be written in there? As for me, that seems to have been a long standing issue on the contribution wiki page: http://qt-project.org/contribute Just happened to me today that I was trying to help someone to close a bug as fixed after a request on IRC, but I was being unsure what the best workflow for that. This is just a practical example. On Tue, Jul 23, 2013 at 12:25 PM, Jedrzej Nowacki jedrzej.nowa...@digia.com wrote: 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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Bug management and jira workflow
-Original Message- From: development-bounces+alexander.blasche=digia@qt-project.org - Who can prioritize bugs? - whoever ask - we will create a special group in jira we already have it (Triagers) ... it's just not wired yet. Good, who can wire the group? Why do we need yet another group? Any approver can do that already. Or what am I missing? we have some more groups which are kinda redundant or plain weird: Developers vs. OGApprovers (the latter seems pointless; the former is a default group, if i got it right). Qt - ?!? then there is a whole bunch of company-related groups. i don't think they have much value at this point. just clear them out? lastly, there is a lot of component-related groups. do we consider these having any value? They don't have much value. Unfortunately cleaning them out is a major pain as they have references to Permission, Notification and security schemes and here we are not even talking about all the custom filters. - 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 i'm not sure i like that. i thoroughly dislike the idea of the release blocker meta-tasks. this is exactly what a prospective fix version plus the right filter would do. that of course implies that the field must be used exclusively as a deadline designation, not an expession of wishful thinking. Yes, we were discussing which definition we should pick. We decided that not using the field for estimation is better from a random user point of view, that could check which Qt version is actually fixed, without cloning the repository. It doesn't create a wish list either. It seems to be also aligned with idea of time based releases, that changes are released, only if they were merged before a certain date. I can see where there might be a confusion. However if I have a choice between the double loading of the Fix for Version and a release blocker task then I vote for the FixFor version field. The release blocker task doesn't even come close to a replacement. One of the most common filters is What's unresolved and assigned to me for the next release?. Fix for is exactly what you need in this case. Also, as long as the task is not closed it can never be mistaken for a really fixed case anyway. A somewhat better method would be to Split the FixFor field into two fields (e.g. PlannedFor vs FixedIn). But even if we assume that FixFor really means released in version x.y.z, who is going to set it? You cannot set the field until very late in the process. That's exactly what you would do during the Verified-Closed transition (BTW the transition is called Release) and the most likely candidate would be the release team. However this collides with the desire to merge the Resolved/Verified/Closed states because nobody transitions the verified tasks to closed. To me this sounds like the same problem. Nobody wants to clean the tasks right before the release. On the other hand you can actually use the Verified to Closed transition to disambiguate the meaning of FixFor. If it is not closed then it always means that the field is an estimation. If it is closed then it's either part of a release line or it was rejected/invalid/ignored (which means FixFor is invalid anyway). It does imply some issue massaging shortly before the release though. -- Alex ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
