John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Andrew Hyatt <ahyatt@gmail.com> writes:
>
>> 1) How to identify the bugs to be triaged. I actually don't know the set of
>> bugs you are interested in. All the open ones? Just the ones blocking emacs
>> 25? If I'm using the debbugs package, what's the command I use to display
>> just the set we're interested in?
>
> There are really two sets of bugs we'd like to pay attention to:
>
>   1. Those blocking the release of Emacs 25. Clearly, we can't release until
>      this reaches zero.
>
>   2. All the open bugs, especially the oldest ones. If they don't reproduce
>      against emacs-25 anymore, we'd like to mark them closed as fixed in that
>      release.
>
> #1 is a fairly small list, so just getting more information on those bugs so
> that the developers know how to proceed next is what's important.
>
> #2 is a large list, but would help out the Emacs project by clearing out
> things we don't need to pay attention to anymore.
>
>> Also, what if it does reproduce? I guess just a reply saying that it
>> reproduces? Or does it need to be tagged in some way?
>
> A comment would be valuable, and if what you saw still matches the description
> of the problem.
>
>> Sorry, maybe there was a document that explains this all, and I missed it.
>> If there's isn't such a document, I think it'd be pretty helpful.
>
> Perhaps we do need a targeted document for on-boarding bug herders. If, while
> you're learning this process, you could keep some notes on what helped you to
> get started, Andrew, that could become the start of such a document.

I've put together my notes into a file I stuck in the admin section.
I'm attaching it as a patch.  Feedback would be welcome, of course.  I'm
guessing there's a few other things we'd like to put into this document
as well, but I won't attempt to go beyond just the basic triage
procedure we've discussed in this thread.