Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [

[Eli Zaretskii]

> From: Richard Stallman <address@hidden>
> Date: Mon, 02 Dec 2019 00:41:36 -0500
> Cc: address@hidden
> 
> I just checked the section Reporting Bugs of the Emacs Manual and was
> surprised to see that it asks users to look in debbugs.
> 
> That requires substantial work, and substantial knowledge that users
> otherwise would not need to have, so it is a substantial
> discouragement to reporting bugs.
> 
> It also asks users to look at several mailing lists.  That too is a
> discouragement.
> 
> If we want to encourage users to report bugs, the obvious way is to
> delete those recommendations.  Let's tell users, "It's better to risk
> a duplicate bug report than risk leaving a bug unreported."

I disagree with what you say here, at least with the details of your
proposal.  There are ways of making that chapter in the manual better,
but just removing this section is IMO not a step in that direction.
Here's why I think so.

First, that section was written in response to a bug report, see

  https://lists.gnu.org/archive/html/bug-gnu-emacs/2010-06/msg00509.html

So at least the person who filed that bug did care about having this
information in the manual.

Next, every decent bug tracker has a feature whereby it shows related
bugs; some even do that before they let you file a new bug.  Debbugs
doesn't have such (semi-)automatic feature, but if we move to a more
sophisticated tracker, or enhance debbugs, we will have to
re-introduce a variant of that section anyway, so why remove it now?

Moreover, I cannot disagree more with the notion of "it's better to
risk a duplicate bug report than risk leaving a bug unreported."
Having to deal with duplicate bugs eats up precious time and resources
(realize the bug is a dupe, mark it so in the database, write an email
saying it's a dupe, etc.), of which we don't have enough.  Duplicate
bugs within hours or days of one another are a matter of routine here,
and any method of making these typical floods of similar reports
smaller is a net win for us.  I agree that we shouldn't ask users to
look too far back into the bug reports (so the reference to
emacs-pretest-bug should probably be removed nowadays), but a simple
search via the debbugs page, or a casual skimming thorough the last
week or two of messages on the bug list and emacs-devel, is a small
effort that is likely to bring significant gains, and I do want to
leave them there.  OTOH, the risk that an important bug will be left
unreported is nowadays very small, since a lot of people are tracking
the development branch, and several distros offer snapshot releases.
Thus, we don't need to be afraid of bugs going unreported anymore as
much as we did in the past.

Last, but certainly not least, that chapter is anyway quite long.  It
includes, in addition to "Known Problems", the following sections:

  . Bug Criteria -- when an issue is really a bug
  . Understanding Bug Reporting -- how to describe a bug
  . Checklist -- what information to include in a bug report and how
    to obtain that information

This is quite a lot of material to digest if you are serious about bug
reporting and really read all that stuff before filing a bug.  If we
think what's in the "Known Problems" section requires substantial
work, then the other sections require much more.  Do we remove all
that as well?  I hope not.

And finally, we have strong indications that almost no one reads this
stuff anyway.  We have people reporting duplicates, we have people
(even quite experienced ones) reporting problems without the minimal
information about their build/system, sometimes even without a clear
description of what they did to trigger the issue.  My interpretation
of this is that this chapter is more like a repository of good ideas
and techniques to point users at, not a must-do list of prerequisites
for reporting a bug; it certainly isn't treated as such by our users.
It is therefore not a substantial discouragement, let alone an
obstacle, to reporting bugs, not in practice.

So what does all that mean in terms of improving the UX of bug
reporting?  We could add a short checklist "for the impatient" right
at the beginning of the chapter, describing concisely the necessary
steps, and then encourage them to read the rest, saying that this will
make the bug report be more useful and help the Emacs developers
identify and resolve the issue much more efficiently.  But I would
definitely object to removing these sections, including "Known
Problems", from the chapter, as most of that is very useful, and if
followed, makes the bug reports much easier to deal with.