Re: My resignation from Emacs development

[Adam Porter]

On 11/26/24 13:01, Daniel Radetsky wrote:
> 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.

1.  As has been clearly stated, Stefan is not in charge of this 
project--the maintainers are.  Any change made by anyone, including 
Stefan, only persists with their approval.

So to blame Stefan is to imply a responsibility he does not bear, which 
is unfair and wrong.

2.  As has been clearly stated, the technical matters in question have 
been discussed extensively by the maintainers, and the status quo 
appears to be somewhat of a compromise, an approximation of the best 
that could be done given the circumstances and the timeframe.  It 
doesn't seem that anyone is truly content with the current 
implementation, yet no agreement on how to improve it has been reached.

So to blame Stefan for an implementation that even he is not fully 
satisfied with, yet no one has been able improve upon with consensus, is 
unfair and wrong.

3.  As has been admitted by Alan himself, he made a relevant change 
without discussing it first, and one that apparently forced the hand of 
the maintainers to deal with.  That would seem to imply his own having 
committed the same kind of misdeed which he accuses Stefan of committing.

So to blame Stefan for an action which Alan himself has taken, in the 
same context, even, is unfair and wrong.

> 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.

You seem to imply that this information has only now been revealed.  As 
has been clearly stated, these discussions about the technical matters 
are not recent, and they were primarily conducted in public.  You can 
review them and come to your own conclusions.  The only new information 
here is Alan's recent decision to stop contributing, which is not a 
technical matter.

> 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.

Alan's feelings about and reaction to these technical issues are Alan's 
concern.  If he chooses to make them public, that's his decision, but it 
doesn't necessarily make them our concern.  Disagreements about how to 
manage a project like this are common, and they needn't always be made 
public--especially, they should not be in the form of public character 
assassination and ritual defamation.

> 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.

You imply circumstances which are not so.  See earlier paragraphs.

> 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.

I don't think that any project ought to govern itself by acceding to "my 
way or the highway" demands--what could be more unhealthy.

> 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.
Respectfully, it seems like you have spoken without fully informing 
yourself of the context.  This whole situation is very simple (not being 
a technical problem, though originating in one): 1. Stefan made a 
change, 2. Alan doesn't like it, 3. no consensus has been reached on how 
to improve it, 4. the maintainers don't think that reverting the change 
would be an improvement, and 5. Alan has decided to cease contributing.

All of that is fine, though Alan's decision is regrettable.  What isn't 
fine is to misplace blame on Stefan, for a decision that the maintainers 
themselves support, and one that no one is fully satisfied with.

All parties would be well advised to set aside ego, territorialism, and 
grudges, and seek the best of the project, which is our common interest, 
the reason we are here.  Technical problems can be solved, and social 
ones can be forgiven--if the parties are willing.

But each one must decide for himself.  And once a participant has made 
his decision, for the good of the project and its participants, he ought 
to stop publicly litigating it.

And any outside participants who feel a duty to offer their input ought 
to do so with the utmost care, and only after fully informing themselves 
of the context and all parties' views, lest they only throw fuel on the 
fire.

--Adam