From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Emacs project mission (was Re: "If you're still seeing problems, please reopen." [ Date: Mon, 02 Dec 2019 17:42:48 +0200 Message-ID: <831rtmn37r.fsf@gnu.org> References: <20191117113054.49837.qmail@mail.muc.de> <87pnhq7mxg.fsf@gnus.org> <87bltaz9g4.fsf@telefonica.net> <834kz25qp9.fsf@gnu.org> <87y2wexsv1.fsf@telefonica.net> <20191118175639.08d02820@jabberwock.cb.piermont.com> <874kz0pa9y.fsf@gnus.org> <87sgmjyn60.fsf@gmx.de> <87imnezyt5.fsf@gmx.de> <481a1f16-d661-0f96-2f45-3d5ec9c1132e@yandex.ru> <749d3c85-ecd0-5d4e-b9fc-6405c2ca2334@yandex.ru> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="103018"; mail-complaints-to="usenet@blaine.gmane.org" Cc: memnon+usenet@freeshell.org, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 02 16:43:52 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1ibnrc-000Qfv-0a for ged-emacs-devel@m.gmane.org; Mon, 02 Dec 2019 16:43:52 +0100 Original-Received: from localhost ([::1]:37640 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ibnra-0003Y4-PT for ged-emacs-devel@m.gmane.org; Mon, 02 Dec 2019 10:43:50 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48244) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ibnqy-0003Xl-S4 for emacs-devel@gnu.org; Mon, 02 Dec 2019 10:43:14 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:38391) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ibnqy-00027B-Go; Mon, 02 Dec 2019 10:43:12 -0500 Original-Received: from [176.228.60.248] (port=2009 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ibnqm-0003e9-FF; Mon, 02 Dec 2019 10:43:00 -0500 In-reply-to: (message from Richard Stallman on Mon, 02 Dec 2019 00:41:36 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:243004 Archived-At: > From: Richard Stallman > Date: Mon, 02 Dec 2019 00:41:36 -0500 > Cc: emacs-devel@gnu.org > > 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.