Confirming bug reports¶
Unconfirmed bugreports are labeld needs confirmation to enable global filtering. Browse through the list, read the bugreports and try to reproduce the issues that are described. If neccessary, add missing information or logs, or improve the quality of the report by other means. Leave a comment stating your device, channel, build number and whether or not you were able to reproduce the issue.
If you have write-access to the repository, you can replace the needs confirmation label with bug (to mark it confirmed) or invalid (if the issue is definitely not reproducable). In that case it should be closed.
If you find two issues describing the same problem, leave a comment and try to find their differences. If they are in fact identical, close the newer one and label it duplicate.
Once a developer finished working on an issue, it’s moved to the quality assurance column of the GitHub project. Check if the issue is still present in the latest update on the devel channel and try to find any problems it is causing. Check if the developer mentioned specific things to look out for when testing and leave a comment detailing your experience. If you have write-access to the repository, you can move the issue back to In Development or forward to Release Candidate as specified by the issue tracking guidelines.
Initial triaging of issues¶
Initial triaging of new issues is done by QA-team members with write-access to the repository. If a new issue is filed, read the report and add the correct labels as specified by the issue tracking guidelines. You can also immediately start confirming the bugreport.
If the new issue has already been reported elsewhere, label it duplicate and close it.