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

From: Stefan Kangas <[email-masked]>
Date: Sat, 14 Sep 2019 14:01:54 +0200

Drew Adams <[email-masked]> writes:

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

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.  But
perhaps that's an unwarranted fear, 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.

On the other hand, what we need more than suggestions would be patches
to fix what is already in the bug tracker, and this doesn't do much to
help that.  There are already many worthy and good projects in the bug
tracker, suitable for everything from beginners to experts.  More low
quality feature requests would make it harder to find these requests
in the bug tracker, thus raising the barrier for new developers.

So I see both arguments as valid here, and I'm conflicted between
them.  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.

Best regards,
Stefan Kangas
From 009c01d9df3103d0e0828dfb6a5fa8dcd5aca2ba Mon Sep 17 00:00:00 2001
From: Stefan Kangas <[email-masked]>
Date: Sat, 14 Sep 2019 13:27:10 +0200
Subject: [PATCH] Document feature requests in the Emacs manual

* doc/emacs/trouble.texi (Contributing): Document feature
requests.  (Bug20697)
---
 doc/emacs/trouble.texi | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/doc/emacs/trouble.texi b/doc/emacs/trouble.texi
index 13d3e8475c..17de6edec8 100644
--- a/doc/emacs/trouble.texi
+++ b/doc/emacs/trouble.texi
@@ -1299,6 +1299,19 @@ Contributing
 @end ifhtml
 You can ask for suggested projects or suggest your own ideas.
 
+If you have a feature request or a suggestion for how to improve
+Emacs, the best place to send it is to
+@ifnothtml
+@email{bug-gnu-emacs.org}
+@end ifnothtml
+@ifhtml
+@url{https://lists.gnu.org/mailman/listinfo/bug-gnu-emacs, bug-gnu-emacs}
+@end ifhtml
+.  Please explain in clear language exactly what change you would like
+to see, and why and how you think it would improve Emacs.  If your
+suggestion is accepted, this will allow it to stand a better chance of
+attracting interest from one of many volunteer Emacs developers.
+
 If you have already written an improvement, please tell us about it.  If
 you have not yet started work, it is useful to contact
 @ifnothtml
-- 
2.20.1