From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#20697: 25.0.50; Mention `M-x report-emacs-bug' on splash screen Date: Sat, 14 Sep 2019 08:54:36 -0700 (PDT) Message-ID: <4496bd9e-58ee-45b5-967d-3402ce4999bd@default> References: <874l2az3r3.fsf@mouse.gnus.org> <5d8f820c-4029-45cf-8fd7-b1fc44f8e6e3@default> <5e1c6ad4-5c01-4989-bbcf-7e398ba9ede6@default> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="153853"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Lars Ingebrigtsen , 20697@debbugs.gnu.org To: Stefan Kangas Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Sep 14 17:55:47 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1i9AOp-000dsQ-35 for geb-bug-gnu-emacs@m.gmane.org; Sat, 14 Sep 2019 17:55:47 +0200 Original-Received: from localhost ([::1]:50944 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i9AOn-0002Jx-PP for geb-bug-gnu-emacs@m.gmane.org; Sat, 14 Sep 2019 11:55:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57353) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i9AO7-0001Z9-UN for bug-gnu-emacs@gnu.org; Sat, 14 Sep 2019 11:55:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i9AO6-0006gZ-9V for bug-gnu-emacs@gnu.org; Sat, 14 Sep 2019 11:55:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38265) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1i9AO6-0006gT-5X for bug-gnu-emacs@gnu.org; Sat, 14 Sep 2019 11:55:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1i9AO6-0000OP-38 for bug-gnu-emacs@gnu.org; Sat, 14 Sep 2019 11:55:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Sep 2019 15:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20697 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 20697-submit@debbugs.gnu.org id=B20697.15684764941487 (code B ref 20697); Sat, 14 Sep 2019 15:55:02 +0000 Original-Received: (at 20697) by debbugs.gnu.org; 14 Sep 2019 15:54:54 +0000 Original-Received: from localhost ([127.0.0.1]:47086 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i9ANx-0000Nv-SH for submit@debbugs.gnu.org; Sat, 14 Sep 2019 11:54:54 -0400 Original-Received: from userp2130.oracle.com ([156.151.31.86]:59850) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1i9ANs-0000Ne-NQ for 20697@debbugs.gnu.org; Sat, 14 Sep 2019 11:54:49 -0400 Original-Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x8EFsWXS123165; Sat, 14 Sep 2019 15:54:42 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2019-08-05; bh=0hKvPZ4LV2Cv6u6HJLXRyvOkUyxWrcEeQejbZ9j82aE=; b=H1k6WbaYbQFhmEG9SG8Pdxfn+6vxeH2IRNTvRrcFJVNCC+oEUhvYr3xhWF8hbPUy668g xj04wc5DSi2KzNPkYZ6OowdIKTKOMYD322zwnUCmlpTJCyDi6prMDj50mWh4aCSK3MGO p2+UipP3H23aHVbYXcX3ORq3oePsV9qcQiurKvOXjkEMx8jnErdzP30DL67wpkYXjuAB x4nEDS/ZAdiyz1pql/r6vT9gz/NWeDIi5FE7BSf7IEjmnOjYjItw6IxhSF9mJq4QQwGt 1lC7NGHhNrPe1BJXgOFq8tl2IKGcuQQMcvHs9DbdTrEWXAIR1x3SL17kG+tEQc2ejXTS pg== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by userp2130.oracle.com with ESMTP id 2v0qmt1k38-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 14 Sep 2019 15:54:42 +0000 Original-Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.27/8.16.0.27) with SMTP id x8EFrvS1061171; Sat, 14 Sep 2019 15:54:42 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userp3030.oracle.com with ESMTP id 2v0nb1w89u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 14 Sep 2019 15:54:41 +0000 Original-Received: from abhmp0002.oracle.com (abhmp0002.oracle.com [141.146.116.8]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id x8EFsbIJ006870; Sat, 14 Sep 2019 15:54:37 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4888.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9380 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1909140168 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9380 signatures=668685 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1909140168 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:166463 Archived-At: > > > Do you have any ideas for how to better emphasize enhancement > > > requests? Should it be a separate bullet point on the "Contribute" > > > page perhaps? > > > > My suggestion is to put it explicitly in the text/link > > that then leads you to the doc section that covers all > > of this. > > > > Although "contribute improvements" covers suggesting > > enhancements, I think the former suggests more > > substantial contribution than just asking for or > > suggesting a possible enhancement - something wished. > > > > I think it's important for users to see, up front, > > an invitation to make even minor or undeveloped, even > > possibly infeasible or not-well-thought-through > > suggestions. > > > > If that invitation is found only after following some > > "contribute" link to doc that covers everything, > > including full-blown patches, then its effect on > > inviting superficial suggestions can be lost. > > > > So I'd "waste" a few extra chars to spell out that > > invitation explicitly. Something like this: > > > > "How to report bugs and suggest or contribute possible improvements" >=20 > I find that line a bit too packed with information to be easily > parsed. I think that the concern Lars has pointed out is valid here: > the about screen is already very dense. Then get rid of some other parts of the link text or other parts of the too-dense screen. Don't get rid of the part about suggesting improvements. This bug report is especially about explicitly inviting enhancement suggestions/wishes. That needs to be on top, up-front, in link text - not relegated to some text at the link target. IMO, this is important. Users who really want to contribute heavily will inevitably find the info about how to do so. That's not a problem now. What's missing, IMO, is a general, well-advertised, make-it-obvious-that-it's-easy-to-do invitation for any and all (whatever their Emacs level) to pass along their suggestions, however blue-sky or half-baked. That should be one of the _main_ things visible and obvious on the splash page etc. It should be one of our main messages. Emacs users should learn right off-the-bat that _they_ are the focus of Emacs: its purpose. Emacs is developed by its users for its users - from core, steady, heavy lifters to newbie ride-by tourists. > I came up with the attached tentative patch that adds a paragraph to > "Contributing" manual page, attached here for discussion. >=20 > But thinking about this a bit more, I can't decide if it's a good idea > to encourage this or not. There is a risk that we get too many low > quality suggestions that we will waste a lot of time handling. I couldn't disagree more with such fear/hesitation. Nothing requires particular action on any suggestion. Nothing even requires consideration of any given suggestion. It's important to get Emacs users involved with their own ideas. Get them thinking about their experiences using Emacs and expressing those thoughts. All ideas, good as well as not-so-good, start out raw or at best half-baked. The emphasis has too long been on setting a high bar - a premature gate to receiving user input. Just adding a friendly encouragement to speak up will help Emacs, not hurt it. > But perhaps that's an unwarranted fear, It's not only an unwarranted fear, IMO. It's restrictive for no reason. Far from discouraging, we should be encouraging suggestions of all sorts. There's plenty of time after receiving a suggestion to consider whether it is "low quality". Prejudging by discouraging, essentially hiding/suppressing the invitation, is backward. > and the biggest problem in the > long run might be users that feel distant and disengaged from Emacs > development. Encouraging feature suggestions might help draw in new > developers. Yes, it might draw in new developers. But Emacs doesn't just need more developers. It will also put existing developers more in touch with more user thoughts and experiences - and provide them with much more food for thought. Emacs features have often come from beyond its "core developers", though some such outsiders later became active developers. That's just the way it works. Even stuff that has become part of distributed (i.e. vanilla) Emacs started as 3rd-party code - see `(emacs)Acknowledgments'. And some features that many users make heavy use of are still outside vanilla Emacs. And plenty of developments have resulted from suggestions by users who never helped develop those features. Any developer of a 3rd-party library knows how helpful user input is - as food for thought as well as pointing out problems. > On the other hand, what we need more than suggestions would be patches > to fix It's not one or the other, or one more than the other. Those are different things. But they're related in the sense that someone encouraged to contribute a suggestion might later contribute a bug fix. > what is already in the bug tracker, and this doesn't do much to > help that. That's not its (direct) aim. (But see previous.) > There are already many worthy and good projects in the bug > tracker, suitable for everything from beginners to experts. Again, that's something else. As Eli is wont to say, correctly, things in Emacs get added/changed because someone had an itch and scratched it. That someone doesn't want to or doesn't have the time to work on a particular bug fix or feature suggestion doesn't mean someone won't work on another suggestion. > More low quality feature requests would make it harder > to find these requests in the bug tracker, thus raising > the barrier for new developers. I don't buy that. But if it's true then that in itself calls for another new feature: better bug-tracker search/organization, ways to lower the barrier for new developers. > So I see both arguments as valid here, and I'm conflicted between > them. They aren't contradictory needs - at least not in the sense of being mutually exclusive. Their contradiction is dialectical. Inviting users to suggest things does not impede bug fixing or other Emacs development. That's a false binary choice. That's essentially saying, "We don't want to hear more suggestions, especially from newbies or half-baked suggestions, because we already have a lot of more important work to do." > Since it's a social issue more than a technical one, I'm not > sure there is one correct answer. >=20 > Perhaps the question is simply if this is subjectively desirable from > the point of view of the leading Emacs developers? After all, they > are the ones who will do the majority of the work handling these > suggestions. Not necessarily. See above. Someone feels an itch - maybe suggested by someone else, and works on it - a little bit or a lot. Someone else picks up on that work and fixes/improves it.