Document how to contribute by doing triage
Created by: eileenmcnaughton
@ErikHommel has offered to help up with doing triage. I think that since this is a task community members take on a times to contribute we should document it. Here is my take:
Triage is doing one or more of the following actions, either to issues you logged or just randomly from the list below. Ideally we would co-opt 2-3 people to spend an hour or 2 a week on triage.
The first priority with triage is to ensure incoming issues Incoming issues are triaged
- determine if it is accurately categorised as bug vs improvement
- detemine if priority is appropriate
- try to ensure component description & title are correct & meaningful
- determine if the issue still is replicable on the latest master
- ask any additional questions that seem necessary
- provide any first-level support you feel able to.
- announce any new regressions or critical issues (that really are) on the product-maintenance channel in chat
- discuss any that are hard to triage on the product-maintenance channel in chat
This is a good example of a triager doing the above steps -
Prioritisaion can be tricky. I consider
'Blocker' to be only applicable to something that would block the next release going out or change the release schedule to get a new hot fix out.
Critical is something that - causes data integrity errors or a fatal error or for CiviCRM to do something substantially different to what it 'says it will do' - e.g the group of people who receive an email being different from those selected.
Important is generally for subsytems IMHO - ie. something that would be a blocker or critical for work that is not currently part of our core offering - such as Drupal 8, Mosaico, new CiviCase
Major includes things that have an notable impact on many users or significant impact on a smaller set.
Minor is a significant impact in an obscure scenario or a minor impact or an important improvement request.
Trivial is ... trivial - e.g wording, translation (sorry people). most improvement requests
Where an issue has been logged or championed by someone who could fix it themselves (e.g a partner) but has not I think that is an indication to err on the side of lowering the priority or considering it to be an 'Improvement request' rather than a bug. Ditto where a bug is newly discovered but has been around for a long time. For example if a behaviour has been in place since 4.5 then it would be hard to make a case for it to be a major bug.