Package: emacs;
Reported by: Drew Adams <drew.adams <at> oracle.com>
Date: Sat, 30 May 2015 14:43:02 UTC
Severity: wishlist
Tags: patch
Found in version 25.0.50
Done: Stefan Kangas <stefan <at> marxist.se>
Bug is archived. No further changes may be made.
View this message in rfc822 format
From: Drew Adams <drew.adams <at> oracle.com> To: Stefan Kangas <stefan <at> marxist.se> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 20697 <at> debbugs.gnu.org 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)
> > > 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" > > 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. > > 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. > > 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.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.