[Development] Bug management and jira workflow

[Jedrzej Nowacki]

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