all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Stefan Kangas <stefan@marxist.se>
To: Drew Adams <drew.adams@oracle.com>
Cc: Lars Ingebrigtsen <larsi@gnus.org>, 20697@debbugs.gnu.org
Subject: bug#20697: 25.0.50; Mention `M-x report-emacs-bug' on splash screen
Date: Sat, 14 Sep 2019 14:01:54 +0200	[thread overview]
Message-ID: <CADwFkm=7-QUvZ+-0g3PzZa4fiO-u6FGmJLD7bUs3KF1ZS1duWw@mail.gmail.com> (raw)
In-Reply-To: <5e1c6ad4-5c01-4989-bbcf-7e398ba9ede6@default>

[-- Attachment #1: Type: text/plain, Size: 2660 bytes --]

Drew Adams <drew.adams@oracle.com> 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

[-- Attachment #2: 0001-Document-feature-requests-in-the-Emacs-manual.patch --]
[-- Type: text/x-patch, Size: 1341 bytes --]

From 009c01d9df3103d0e0828dfb6a5fa8dcd5aca2ba Mon Sep 17 00:00:00 2001
From: Stefan Kangas <stefankangas@gmail.com>
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


  reply	other threads:[~2019-09-14 12:01 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-30 14:42 bug#20697: 25.0.50; Mention `M-x report-emacs-bug' on splash screen Drew Adams
2016-04-30 19:33 ` Lars Ingebrigtsen
2019-08-21  0:41 ` Stefan Kangas
2019-08-21  1:59   ` Drew Adams
2019-08-21 20:02   ` Lars Ingebrigtsen
2019-08-21 21:02     ` Stefan Kangas
2019-08-21 21:27       ` Drew Adams
2019-09-13 19:39         ` Stefan Kangas
2019-09-13 20:13           ` Drew Adams
2019-09-14 12:01             ` Stefan Kangas [this message]
2019-09-14 15:54               ` Drew Adams
2019-09-28 13:44                 ` Stefan Kangas
2019-09-28 13:49                   ` Stefan Kangas
2019-09-29  0:42                   ` Drew Adams
2020-01-16  2:06                   ` Stefan Kangas
2020-01-16 14:49                     ` Eli Zaretskii
2020-01-16 14:55                       ` Stefan Kangas
2020-01-16 15:16                         ` Eli Zaretskii
2020-01-16 20:36                           ` Stefan Kangas
2019-08-21 21:38       ` Lars Ingebrigtsen
2019-09-13 19:29         ` Stefan Kangas
2019-09-14  6:41           ` Eli Zaretskii
2019-09-14 12:06             ` Stefan Kangas
2019-09-14 12:11           ` Lars Ingebrigtsen
2019-09-28 13:39             ` Stefan Kangas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CADwFkm=7-QUvZ+-0g3PzZa4fiO-u6FGmJLD7bUs3KF1ZS1duWw@mail.gmail.com' \
    --to=stefan@marxist.se \
    --cc=20697@debbugs.gnu.org \
    --cc=drew.adams@oracle.com \
    --cc=larsi@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.