Re: My resignation from Emacs development

[Christopher Dimech <dimech@gmx.com>]

> Sent: Wednesday, November 27, 2024 at 2:18 PM
> From: "Adam Porter" <adam@alphapapa.net>
> To: "Christopher Dimech" <dimech@gmx.com>, "Daniel Radetsky" <dradetsky@gmail.com>
> Cc: acm@muc.de, emacs-devel@gnu.org
> Subject: Re: My resignation from Emacs development
>
> Christopher,
>
> On 11/26/24 13:51, Christopher Dimech wrote:
> > In the matter of blaming maintainers for decisions - whether directly or
> > indirectly - the question of whether maintainers should be allowed to
> > break their own rules is critical.  A compelling case exists that they
> > should.  Strict adherence to lengthy review periods or
> > consensus-building processes is often impractical, especially in
> > situations where only maintainers possess the necessary expertise to
> > advance the program.
> >
> > Maintainers breaking their own rules represents a pragmatic approach,
> > prioritizing progress and functionality over rigid adherence to dogmatic
> > processes. This flexibility ensures that the project continues to evolve
> > and adapt to its challenges.
>
> You seem to imply that some kind of rule-breaking has happened.  I don't
> think this is so--unless the rule were "No one may make any change
> unless everyone agrees to it."  The technical matters in question have
> been thoroughly discussed.  A change was made.  The maintainers support
> it (in absence of a better solution, which they have not found).  One
> contributor refuses to tolerate it--regrettable, but solely his decision
> to make.  There's little else--factually--to say.

Even when rule-breaking occurs, this should not inherently be a problem.
Maintainers are justified to make decisions.

> > That said, while maintainers must retain the ability to make such
> > decisions - even if they sometimes result in dissent or the
> > departure of contributors - there is a clear responsibility to avoid
> > fostering a culture of arbitrary rule-breaking.  Transparency,
> > accountability, and judicious use of this authority are essential to
> > maintain the integrity of the program, especially in a collaborative
> > environment heavily reliant on contributor involvement.

> You seem to imply some kind of secrecy is involved.  Everything I see
> indicates the opposite: lengthy, public discussions, long-considered but
> finally needed decisions, and further lengthy, public discussions (with
> unfairly implied chastisement of the maintainers for implied secrecy).
> One could hardly find a more transparently run project.
>
> You even mention integrity, as if to suggest that the maintainers' is in
> question.  Please be careful that your words don't imply criticism where
> none is deserved.

No criticism.  Integrity referred to emacs as a computer program, not of
maintainers.  Contributors should acknowledge that the practical demands
of maintaining necessitate decisions being made without exhaustive
discourse like in this case.  Finally, it is users that have to adapt
accordingly with the tools provided.