Issue #15943 has been updated by duerst (Martin D=FCrst).


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 i=
t.

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/1477=
0 for links to these meetings).

----------------------------------------
Misc #15943: Add Bug Triaging Guide
https://bugs.ruby-lang.org/issues/15943#change-78941

* Author: jeremyevans0 (Jeremy Evans)
* Status: Open
* Priority: Normal
* Assignee: =

----------------------------------------
I would like to add a bug triaging guide to the repository at `doc/bug_tria=
ging.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 m=
e, 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, le=
t's please discuss changes.  =


```
=3D Bug Triaging Guide

This guide discusses recommendations for triaging bugs in Ruby's bug tracke=
r.

=3D=3D 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 Ru=
by
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 wi=
th
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 reprodu=
ce
the issue on the latest version for the branch, then it is likely the bug h=
as
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.

=3D=3D 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 n=
ot
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.

=3D=3D 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.

=3D=3D 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.

=3D=3D Stale Issues

There are many issues that are stale, with no updates in months or even yea=
rs.
For stale issues in Feedback state, where the feedback has not been receive=
d,
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.
```



-- =

https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=3Dunsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>