Project

General

Profile

Actions

Misc #15943

closed

Add Bug Triaging Guide

Added by jeremyevans0 (Jeremy Evans) almost 5 years ago. Updated over 4 years ago.

Status:
Closed
Assignee:
-
[ruby-core:93266]

Description

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.
Actions

Also available in: Atom PDF

Like0
Like0Like0