My resignation from Emacs development

[Christopher Dimech <dimech@gmx.com>]

> Sent: Wednesday, November 27, 2024 at 7:01 AM
> From: "Daniel Radetsky" <dradetsky@gmail.com>
> To: "Adam Porter" <adam@alphapapa.net>
> Cc: acm@muc.de, emacs-devel@gnu.org
> Subject: Re: My resignation from Emacs development
>
> On Thu, Nov 21, 2024 at 11:35:35PM -0600, Adam Porter wrote:
> > But it is not okay for you to blame Stefan for your decision to leave.
>
> I disagree. If he chooses to leave, and the reason for this
> choice is Stefan's behavior or decisions, then blaming
> Stefan seems straightforwardly informative.

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.

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.

> I'm not as much of a veteran of this list as some of you,
> and my few interactions with Stefan have been positive. So I
> can't really speak to who's in the right and don't think I
> should. But it's broadly better to have information about
> what's going on and what decisions are being made and how
> everyone feels about those decisions than to not have this
> information.
>
> Basically, if Stefan made a decisions, and this made Alan so
> unhappy that he wants to leave, this is something everyone
> should know. Sometimes this is the price of a decision. We
> need to know the price to make informed choices.
>
> I'm not accusing you of this specifically, but it seems like
> in situations like this there's a desire to make the
> situation black and white. Either Stefan made a bad decision
> which ought to be reversed, and the fact that it is not
> being reversed would justify Alan leaving, or Alan is being
> unreasonable and thus his decision to leave is a foregone
> conclusion being unfairly blamed on Stefan. Thus if we don't
> want to reverse Stefan's decision, we must believe that Alan
> is being unreasonable.
>
> But it's also possible that e.g. Stefan made a good decision
> in the big picture, but this was locally problematic for
> Alan. And even though we prefer Stefan's good decision, we
> prefer a worse decision with the benefit of Alan's continued
> contribution than the alternative. Or maybe not, but this is
> why we want to surface the costs of decisions. It's better
> than pretending that hard decisions don't need to be made,
> and that the true costs of those decisions are just somebody
> being unreasonable and thus not worth counting on the "cost"
> side of the ledger.
>
> If Alan isn't happy with Stefan's decision then even if we
> think it was overall a good decision, this doesn't mean we
> have to be unhappy with Alan. We can just ask ourselves if
> the whole thing is worth it. Or rather, the rest of you can
> ask it; I don't have an opinion on the specifics.
>
> --dmr
>
>