The purpose of bug triage is somehow common to medical triage process (think M*A*S*H TV series) - to find most important cases. In short, the idea is to go through all issues reported and assess and categorize them. Deep technical knowledge is not required in most cases, because we often deal with issues which are not complete, lack of information, incorrectly categorized, already known issues or simple enough.
The purpose of this post is to encourage people doing triage process, it’s simple, it’s doable, it’s huge help and it only takes few minutes per week.
Things to do:
- Check info provided. If there is not enough info for the assessment, set Need more info state and do not check Triaged yet.
- Google the error. It’s as easy as that - reporters often do not bother googling errors (might be useful to limit the search to Redmine and Bugzilla , try search engine and also RedMine search feature as well to find Related issues.
- Ask for Foreman version. And make sure Found in versions is set accordingly, this helps us to decide on backports.
- Verify project and category. It’s very common issue for reporters to choose an incorrect project and category. If you think we are missing a category, speak up.
- Move to Discourse. We have our Support category on Discourse for questions, support or misconfiguration errors. Politely ask the reporter to move the entry and close the report.
- Consider changing the title. Lots of issues have weird title, often copy-pasted from errors or misleading components/plugins when the root of the issue is somewhere else. Don’t hesitate to rename issues if that’s appropriate.
- Change Feature. For RFEs we have a Feature issue type on RedMine.
- Read carefully. Some reports are long and answers are hidden in between lines. Don’t rush and read once but carefully.
- Poke developers. The Weekly triage post is a great chance to poke people if you need more technical expertise or you know that someone recently changed the code.
- Set Target Release. If you think a bug is important enough to be backported into last stable release, just set the Target Release and it will be scheduled for another triage process once fixed.
- Correct priority. Reporters tend to set Urgent or High priority, but this flag is for us. Keep it as Normal and be sure to increase or decrease priority depending of your assessment.
- If you think the issue is security related, send an email to Foreman security team for prompt and coordinated response.
- If the issue seems like a simple fix, set the difficulty to “Easy” or “Trivial” so new contributors can find what to start from.
- Mark as Triaged. When you are done with an issue, be sure to check the Triaged flag so it will disappear from the untriaged report next week.
Things not to do:
- Fixing issues. You want to complete searching the list for bugs you can assess, save them for later.
- Marking when not sure. It’s better just to leave an issue as is when unsure, even after some conversation with reporter. Someone else can still pick it up.
- Only devs can do this. Not at all, all community members are welcome to participate.
- Not for me. Technical knowledge is very often not needed at all! New comers, non-devs and regular Foreman users can all contribute by participating.
- Waste of time. It’s definitely not, participating in our triage process is huge help. Thank you!
This post is a wiki, please correct or add more info. Thanks for participating!