[Development] Bug management and jira workflow

[Laszlo Papp]

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.nowacki at 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 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/20130726/5a1934eb/attachment.html>