Add Bug Triaging Guide
I would like to add a bug triaging guide to the repository at
doc/bug_triaging.rdoc, giving recommendations for triaging bugs. Alternatively, this guide could be added as a Wiki page on the bug tracker (
HowToBugTriage). I plan to spend a substantial amount of time triaging the 1300+ open bugs in the bug tracker, and having a guide would make this process easier for me, and hopefully easier for other people to help triage.
Here is my proposal for the initial content of the guide. I would like to know if any committers have issues with any of these guidelines. If so, let's please discuss changes.
= Bug Triaging Guide This guide discusses recommendations for triaging bugs in Ruby's bug tracker. == Bugs with Reproducible Examples These are the best bug reports. First, consider whether the bug reported is actually an issue or if it is expected Ruby behavior. If it is expected Ruby behavior, update the issue with why the behavior is expected, and set the Status to Rejected. If the bug reported appears to be an actual bug, try reproducing the bug with the master branch. If you are not able to reproduce the issue on the master branch, try reproducing it on the latest version for the branch the bug was reported on. If you cannot reproduce the issue in either case, update the issue stating you cannot reproduce the issue, ask the reporter if they can reproduce the issue with either the master branch or a later release, and set the status to Feedback. If you can reproduce the example with the master branch, try to figure out what is causing the issue. If you feel comfortable, try working on a patch for the issue, update the issue, and attach the patch. Try to figure out which committer should be assigned to the issue, and set them as the assignee, and set the status to Assigned. If you cannot reproduce the example with the master branch, but can reproduce the issue on the latest version for the branch, then it is likely the bug has already been fixed, but it has not been backported yet. Try to determine which commit fixed it, and update the issue noting that the issue has been fixed but not yet backported. == Crash Bugs Without Reproducers Many bugs reported have little more than a crash report, often with no way to reproduce the issue. These bugs are difficult to triage as they often do not contain enough information. For these bugs, if the ruby version is not longer current (e.g. 2.5.0 when the latest 2.5 version is 2.5.5), add a note to the issue asking the reporter to try the latest ruby version and report back, and change the status to Feedback. If the ruby version is in the security maintenance phase or no longer supported, change the status to Closed. == Crash Bugs With 3rd Party C Extensions If the crash happens inside a 3rd party C extension, try to figure out which C extension it happens inside, and add a note to the issue to report the issue to that C extension, and set the status to Third Party's Issue. == Non-Bug reports Any issues in the bug tracker that are not reports of problems should have the tracker changed from Bug to either Feature (new features or performance improvements) or Misc. == Stale Issues There are many issues that are stale, with no updates in months or even years. For stale issues in Feedback state, where the feedback has not been received, you can change the status to Closed. For stale issues in Assigned state, you can reach out the assignee and see if they can update the issue.
Updated by duerst (Martin Dürst) 24 days ago
Many thanks for writing this guide (and then using in and triaging lots of bugs)! It's pretty much straightforward, and I don't have any issues with it.
The only addition I might suggest is to mention that bugs that may benefit from general committer attention or discussion should be put on the agenda of the next committers' meeting (see https://bugs.ruby-lang.org/issues/14770 for links to these meetings).