bug#20697: 25.0.50; Mention `M-x report-emacs-bug' on splash screen

[Drew Adams <drew.adams@oracle.com>]

> > > 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.