Adding example replies to bug-triage.

* admin/notes/bug-triage: Added example replies. Also, as requested,
  making the process notes into more of a checklist.

1 files changed, 57 insertions, 23 deletions

diff --git a/admin/notes/bug-triage b/admin/notes/bug-triage
index 5b0e35c144c..7392fb96985 100644
--- a/admin/notes/bug-triage
+++ b/admin/notes/bug-triage
@@ -16,29 +16,63 @@ the ones that are not reproducible on the current release.
      serious, important, or normal.
   2. This will also show closed bugs that have yet to be archived.  You can
      filter these out in debbugs-gnu with "x" (debbugs-gnu-toggle-suppress).
-  3. For each bug, do the following:
-     - Read the mail thread for the bug.  Find out if anyone has been able to
-       reproduce this on the current release.
-     - If someone has been able to, then your work is finished for this bug.
-     - Make sure there's enough information to reproduce the bug.  It should be
-       very clear how to reproduce.  If not, please ask for specific steps to
-       reproduce.  If you don't get them, and you can't reproduce without them,
-       you can close as "doneunreproducible".
-     - If no one has mentioned being able to reproduce on the current release,
-       read the bug description and attempt to reproduce on an emacs started
-       with "emacs -Q" (the goal is to not let our personal configs interfere
-       with bug testing).
-     - If you can reproduce, then reply on the thread (either on the original
-       message, or anywhere you find appropriate) that you can reproduce this on
-       the current release. If your reproduction gives additional info (such as
-       a backtrace), then add that as well, since it will help whoever attempts
-       to fix it.
-     - If you can't reproduce, state that you can't reproduce it on the current
-       release, ask if they can try again against the current release.  Tag the
-       bug as "unreproducable".  Wait a few weeks for their reply - if they can
-       reproduce it, then that's great, otherwise close as "doneunreproducible".
-     - If the bug ends up still open, make sure the priority and other tags
-       seems reasonable.
+  3. For each bug, we want to primarily make sure it is still
+     reproducible.  A bug can and should stay open as long as it is
+     still a bug and no one has fixed it.  The following is a
+     suggested checklist to follow for handling these bugs, along with
+     example replies.  The various closings, taggings, etc, are done
+     with debbugs control messages, which in debbugs-gnu is initiated
+     with a "C".
+     [ ] Read the mail thread for the bug.  Find out if anyone has
+         been able to reproduce this on the current release.  If
+         someone has been able to, then your work is finished for this
+         bug.
+     [ ] Make sure there's enough information to reproduce the bug.
+         It should be very clear how to reproduce.  If not, please ask
+         for specific steps to reproduce.  If you don't get them, and
+         you can't reproduce without them, you can close as
+         "doneunreproducible".  Sometimes there is specific hardware
+         involved, such as particular models of keyboards, or it may
+         simply involve a platform you don't have access to.  It's
+         fine to ignore those, and let a future triager that is better
+         equipped to reproduce it handle it.
+
+         An example reply asking for clear reproduction steps would be
+         something like: "Hi!  In the interest of seeing whether this
+         is reproducible, and to aid anyone who will look at this bug
+         in the future, can you please give instructions on how to
+         reproduce this bug starting from an emacs without
+         configuration ("emacs -Q")?
+     [ ] If there is enough detail to reproduce, but no one has
+         mentioned being able to reproduce on the current release,
+         read the bug description and attempt to reproduce on an emacs
+         started with "emacs -Q" (the goal is to not let our personal
+         configs interfere with bug testing).
+
+         If you can reproduce, then reply on the thread (either on the
+         original message, or anywhere you find appropriate) that you
+         can reproduce this on the current release. If your
+         reproduction gives additional info (such as a backtrace),
+         then add that as well, since it will help whoever attempts to
+         fix it.
+
+         Example reply: "I'd just like to add that I can reproduce
+         this on the latest version of Emacs, Emacs 25."
+
+         If you can't reproduce, state that you can't reproduce it on
+         the current release, ask if they can try again against the
+         current release.  Tag the bug as "unreproducable".  Wait a
+         few weeks for their reply - if they can reproduce it, then
+         that's great, otherwise close as "doneunreproducible".
+
+         Example reply: "I've attempted to reproduce this on the
+         latest version of emacs, Emacs 25, but haven't been able to.
+         Can you try to reproduce this on this version, and let us
+         know if you are able to?  If I don't hear back in a few
+         weeks, I'll just close this bug as unreproducible."
+     [ ] Check that the priority is reasonable.  Most bugs should be
+         marked as normal, but crashers and security issues can be
+         marked as "severe".
   4. Your changes will take some time to take effect.  After a period of minutes
      to hours, you will get a mail telling you the control message has been
      processed.  At this point, if there were no errors detected, you and