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 <[email protected] > 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 > [email protected] > http://lists.qt-project.org/mailman/listinfo/development >
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
