Re: My resignation from Emacs development

[Christopher Dimech]

> Sent: Saturday, November 23, 2024 at 7:48 PM
> From: "Eli Zaretskii" <eliz@gnu.org>
> To: rms@gnu.org
> Cc: stefankangas@gmail.com, acm@muc.de, emacs-devel@gnu.org
> Subject: Re: My resignation from Emacs development
>
> > From: Richard Stallman <rms@gnu.org>
> > Cc: acm@muc.de, emacs-devel@gnu.org
> > Date: Sat, 23 Nov 2024 01:10:42 -0500
> > 
> >   > I have to agree with Eli.  Although it would, in hindsight, certainly
> >   > have been better to discuss these particular changes in more detail in
> >   > advance,
> > 
> > I too have complained that major changes were not being discussed in the
> > way that they call for.
> 
> My impression is that complaints about "changes installed without
> being discussed" assume that discussing them would have stopped them
> from being installed.  When there's a chance that this is the case,
> according to the best judgment of the maintainers, we insist on
> discussions (at least I do) as prerequisite for accepting the changes.
> There are enough changes which were rejected this way.
> 
> However, as I've written elsewhere in this thread, Emacs maintainers
> are just stewards.  They don't "own" the project, and cannot dictate
> their preferences when some change is widely favored by the community,
> not without good reasons, which are considered "good enough" by the
> community.  So when we feel that a change will be widely supported,
> regardless of discussions, we see no reason to delay its installation.
> (Of course, code review and various minor issues like proper
> documentation etc. are still in effect, and many times require
> re-submission of patches before they are installed.)

I challenge the notion that Emacs maintainers act solely as stewards.
The term implies neutrality, but maintainers inherently influence the
project's trajectory.

Maintainers have a fiduciary duty to both the project's longevity and
its contributors' collective vision.  Thus the robustness of the project
and the ease of improvements are important.

> > I think this incident shows that we need to make a rule to ensure
> > they get discused properly.  Some ideas occur to me, which could form
> > a part of this.
> > 
> > Here's one possible approach that occurs to me.
> > It's not the only approach that could be good.
> > 
> > * A new feature must be brought up on emacs-devel with a clear description.
> > 
> > * If anyone on the list says, "This feature calls for careful discussion,"
> > then maintainers must respond saying, "We will now have 14 days for 
> > discussion
> > of this feature."
> > 
> > * 14 later, a maintainer can post, "We have had 14 days of discussion for
> > the feature XyZ.  Here's how the plan stands now.  Does anyone call for 
> > further
> > discussion?"
> > 
> > * If anyone on the list says, "This feature calls for further
> > discussion," then maintainers must respond saying, "We will now have 7
> > days for further discussion of this feature."
> > 
> > * 7 days later, the maintainers can install the feature.
> 
> We already have those rules, albeit not formally.  But rules are not
> always followed to the letter in a community such as ours, and we have
> no real means of enforcing them.  (Extreme examples of disregard for
> those rules cause radical measures like public harsh reprimands of the
> offenders, and reverting of the offending changes, but that is a
> doomsday weapon that must be employed extremely sparingly.  And we
> have nothing else except telling people a-posteriori they should have
> known better.)
> 
> I object to codifying such rules, for two reasons:
> 
>   . Rules that force people to behave decently and respectfully to
>     others send a message that people are not trusted to do it
>     otherwise, which, to me, smells of totalitarian societies and
>     by-default incrimination of people we know nothing about.  We have
>     Gnu Kind Communication Guidelines where other projects have the
>     notorious Codes of Conduct, for this very reason.
>   . If such rules are broken, we have no real power to do anything.
>     IOW, the "or else" clause of any such rule is basically empty.
>     The only measure we have is to take away their write access, which
>     is again a doomsday weapon, and will certainly avert contributors
>     if applied when, say, some change was installed without waiting
>     for 14 days.

They also impose significant logistical burdens on maintainers,
particularly if enforcement becomes a regular necessity or must happen
at inopportune times.  Enforcing rules consistently and addressing
violations, especially during critical project milestones or personal
time constraints, is unsustainable.

Ultimately, the sustainability of enforcement must align with the
maintainers' capacity,

> Beyond the above, I personally have no will to enforce such rules, and
> if the decision is to introduce them, someone else will have to do
> that, because I will not.  It is against my vision of how such
> communities should be led, and no one can ask me to do this job
> against my principles and my best judgment.

Let's put aside competing visions and principles and prioritize
practical judgment. The abundance of conflicting ideals has only added
complexity. It’s time for the maintainers to make a clear decision on
this matter, now that the discussion has been fully laid out.