Re: Confused by y-or-n-p

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: larsi@gnus.org, eliz@gnu.org, rudalics@gmx.at,
>       emacs-devel@gnu.org, juri@linkov.net
> Date: Sun, 03 Jan 2021 01:06:18 -0500
> 
> The dynamic that results is this:
> 
> * A few people decide to make a UI change, which many have not noticed.
> 
> * Some people eventually notice it in master, or in a release, and maybe
>   people start objecting.
> 
> * At that point there is resistance to changing back.

The resistance is understandable, but when this happens on master, and
the objections are valid and supported by enough people, we usually
augment or revert the change.

When this happens in a released version, the resistance is justifiably
stronger.  But those cases should be (and are, IME) very rare.

> The end result is a tendency to make changes because a few people
> are in favor of them, and then it is hard to avoid them.

There's no need and no justification for such generalizations based on
a single incident.  The adverse results you describe are extremely
rare in practice.  In some cases (some people say too many) the
situation is actually the exact opposite: changes are being discussed
"to death" and sometimes never implemented due to controversy.
However, most changes are discussed by suitable groups of people, the
various opinions are heard, and we usually try to accommodate them in
the solution that is actually installed.

So there's no need to present an isolated and exceptional incident as
if it were the rule.

> * A few people decide to make a UI change, which many have not noticed.
> 
> * Someone points out that such a change should be discussed on
>   emacs-devel.  So they do that, before installation.

That is being done already, where we see it necessary.

However, I see no reason to single out emacs-devel as the only medium
suitable for such discussions.  The Emacs issue tracker is another
valid medium for that.  Some changes are so significant that we do
indeed decide to move them to emacs-devel, but I see no reason to do
that for every behavior change.  Moving a discussion has its
downsides: depending on your MUA you can lose the threading
capabilities; some people fail to notice and continue sending messages
to the bug list; some people start cross-posting to both lists and
thus increase the noise level; future forensics will be harder because
references to discussions on emacs-devel are incomplete; etc.  Thus,
we insist on moving the discussions to emacs-devel only for
significant enough issues -- and which ones are significant is a
judgment call.

> * If some are opposed, they install the feature with a variable to
>   enable it, disabled by default.

This is already being done: every backward-incompatible change is
either required to become compatible, or, if that's not feasible, to
provide a way to get back the old behavior.  In some rare cases this
doesn't happen, but such mistakes are rare exceptions, they aren't the
rule.

> * Some time later -- it need not be soon -- poll the users and see who
>   likes it _and why_.  Maybe change the default.

Volunteers are welcome to step forward and take upon themselves the
responsibilities for conducting such polls.  Failing that, I don't see
how we can promise doing this as a matter of routine.