unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Adam Porter <adam@alphapapa.net>
To: eliz@gnu.org
Cc: adam@alphapapa.net, daniel@dpettersson.net, dmitry@gutov.dev,
	emacs-devel@gnu.org, joaotavora@gmail.com, john@yates-sheets.org,
	krister.schuchardt@gmail.com, philipk@posteo.net
Subject: Re: [ELPA] New package: dape
Date: Sat, 4 Nov 2023 09:53:46 -0500	[thread overview]
Message-ID: <9c36914f-dd2b-4701-8553-58f9225fc247@alphapapa.net> (raw)
In-Reply-To: <83msvt4nxu.fsf@gnu.org>

Hello Eli,

>> Date: Sat, 4 Nov 2023 08:46:35 -0500 Cc: Dmitry Gutov 
>> <dmitry@gutov.dev>, John Yates <john@yates-sheets.org>, Krister 
>> Schuchardt <krister.schuchardt@gmail.com>, emacs-devel@gnu.org, 
>> philipk@posteo.net From: Adam Porter <adam@alphapapa.net>
>> 
>> While friendly, gentle suggestions are ok, the pressure being put 
>> on authors in this process is unbecoming, to say the least.
> 
> Please stop the insinuations.  There's no pressure.  We are asking 
> authors to consider changing the names, that's all; if they don't 
> agree, the issue is dropped on the floor.

I don't mean to insinuate.  I mean to share observations and 
experiences.  You and others may not intend to pressure authors, but 
when a thread bikeshedding a name goes on for 10 or 20 messages with 
numerous authors piling on their own hues, it can feel, to the author, 
like he is being pressured to change his mind, or that his contribution 
is being, well, taken away, to an extent.

This is especially so when it is not made clear, up front, that the 
author's decision will be accepted in the end, even if he politely 
declines to rename the library.

This is not only my own experience.  The way this issue recurs when 
packages are submitted is noticed in the wider community, and it harms 
GNU ELPA's reputation.  I report this observation with the intent to 
help, not to insinuate or insult.
> It is, after all, our prerogative and even our job, out of the wish 
> to serve our users better, to try to have packages with reasonably
> self-explanatory names where possible.

As I've said numerous times on this list, I agree with that principle.
> You don't have to like it, but at least please respect our views on
> that and our perspective. Your flat rejection of it is unbecoming, to
> say the least.

As I've said numerous times on this list, including in the past few 
days, I do not reject your view, flatly or otherwise.  Please don't 
misrepresent my view, either.

My view is that a name should be chosen with respect to various 
criteria; a name's being self-explanatory is one of them, but is not the 
only, nor even the highest, concern.

To try to make this message productive, I have a concrete suggestion: 
When a package is submitted to GNU ELPA, and it is suggested that the 
author consider renaming it, it should be made clear at the time that 
the suggestion is merely that, and that the author's final decision will 
be accepted.  That would likely help to defuse any feelings of pressure 
that might be felt as the discussion proceeds (and perhaps even make the 
author more receptive to suggestions).

Thanks,
Adam



  parent reply	other threads:[~2023-11-04 14:53 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-13 10:35 [ELPA] New package: dape Daniel Pettersson
2023-10-13 12:24 ` Philip Kaludercic
2023-10-14 12:28   ` Daniel Pettersson
2023-10-14 14:54     ` Philip Kaludercic
2023-10-15 13:50       ` James Thomas
2023-10-15 14:12         ` Philip Kaludercic
2023-10-15 17:24           ` John Yates
2023-10-18 21:54       ` Daniel Pettersson
2023-10-19  2:08         ` Adam Porter
2023-10-19 10:52           ` Krister Schuchardt
2023-10-19 11:06             ` Dmitry Gutov
2023-10-20 14:53               ` John Yates
2023-11-01 19:13                 ` Dmitry Gutov
2023-11-02 14:42                   ` João Távora
2023-11-04  9:51                     ` Daniel Pettersson
2023-11-04 10:00                       ` Philip Kaludercic
2023-11-23  6:10                         ` Philip Kaludercic
2023-12-05  8:41                           ` Philip Kaludercic
2023-12-05  9:18                             ` João Távora
2023-12-05 10:59                               ` Philip Kaludercic
2023-12-05 11:29                                 ` João Távora
2023-12-06  3:57                                   ` Richard Stallman
2023-12-06 10:09                                   ` Daniel Pettersson
2023-12-06 12:30                                     ` Eli Zaretskii
2023-12-06 12:56                                       ` João Távora
2023-12-06 13:08                                         ` Eli Zaretskii
2023-12-06 13:38                                           ` João Távora
2023-12-06 17:00                                             ` Eli Zaretskii
2023-12-06 23:03                                               ` João Távora
2023-12-06 23:55                                               ` Daniel Pettersson
2023-12-07  7:13                                                 ` Eli Zaretskii
2023-11-04 13:46                       ` Adam Porter
2023-11-04 14:01                         ` Eli Zaretskii
2023-11-04 14:24                           ` Philip Kaludercic
2023-11-04 15:06                             ` Adam Porter
2023-11-04 15:27                               ` Philip Kaludercic
2023-11-04 14:53                           ` Adam Porter [this message]
2023-11-04 15:14                             ` Eli Zaretskii
2023-11-04 19:15                               ` Adam Porter
2023-11-04 23:21                       ` João Távora
2023-11-07 10:19                         ` Daniel Pettersson
2023-11-07 10:40                           ` João Távora
2023-11-08  8:31                             ` Daniel Pettersson
2023-10-19 15:12         ` Philip Kaludercic
2023-10-19 17:50         ` Björn Bidar
2023-11-01 16:50         ` Philip Kaludercic
2023-10-15 13:55 ` Mauro Aranda
2023-10-17 20:39   ` Daniel Pettersson
2023-10-20  5:49 ` Milan Glacier

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=9c36914f-dd2b-4701-8553-58f9225fc247@alphapapa.net \
    --to=adam@alphapapa.net \
    --cc=daniel@dpettersson.net \
    --cc=dmitry@gutov.dev \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=joaotavora@gmail.com \
    --cc=john@yates-sheets.org \
    --cc=krister.schuchardt@gmail.com \
    --cc=philipk@posteo.net \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).