How? Everything is done openly on https://github.com/rust-lang/rfcs

I mean, I hear you. I understand what you're saying, I just don't understand how you (or others) think this is related to the technical aspects of the language.

Because the same people are involved, and they knowingly sidestepped these exact sorts of processes without care. It might not be important to you, but this seems like a red flag to many.

> Everything is done openly on https://github.com/rust-lang/rfcs

But the RFCs are written and reviewed by people. And they need to have the feeling that the work they do isn't useless because the one who actually decides is somebody else who hasn't been involved in the process at all until the very end. It's ok having somebody being able to veto stuff, but this must be known and communicated beforehand - "yes, that's ok for us, but $PERSON has the last word on this so we have to await his approval".

If leadership acts so carelessly with regard to matters concerning a human being in such a shady and disrespecting manner, why would they act less careless with regard to technical matters? Will they just enforce their biased opinion, ignoring valid and generally accepted technical arguments? Rust leadership sounds a bit like the elite leadership of a communist state. I'd prefer an open dictatorship over that.

Notable in this backlash that this happened Friday evening/Saturday morning. So many of whom you’re characterising as the “elite leadership of a communist state” might not have seen this yet. They need to coordinate, build consensus and speak with one voice. I expect that might take a couple of days so they might have a response by Wednesday or so.

Also, my understanding is that the consensus among the committee was to invite and then one person broke that consensus. You’re characterising this as a careful, considered decision made by all of Rust project leadership but that might not be the case at all.

No, I am not presenting this as a careful, considered decision. I was just responding why this incident could possibly also reflect on technical matters (not saying that it actually does). I have no clue what went on exactly. But clearly leadership somehow failed in this incident. Looking forward to hear more about how exactly this has happened.

It’s possible to characterise anything as a leadership failure because the buck stops with them. But I don’t see what they could have done differently other than all being available on weekends to troubleshoot issues like this.

If just one person inside leadership fails, that's also leadership failure. If that's the case, most likely the remaining leadership will distance itself from this soon enough.

I’m less interested in collective blame/punishment and more about “how do we prevent this from reoccurring?”

I’m not seeing any obvious solution. If one member of the leadership team does something stupid on a Friday, it can only be resolved by Tuesday or Wednesday. Folks are going to pick up their pitchforks on Sunday and say that “leadership failed”. Sure. But I don’t see a way around this.

The solution is to pick better leaders. This should never have happened in the first place. Whoever is responsible for this needs to go.

You must be fun at incident review. "The solution is to hire better engineers. Our root cause analysis shows that this should have never happened in the first place. Whoever is responsible for this needs to go."

You’re missing the distinction here between incompetence and malice. One member of leadership acted maliciously; the fact that they were successful indicates that leadership as a whole was missing some controls (formal or otherwise). The latter party is analogous to whichever engineer accidentally brought down prod, whom our post-mortems should not blame—but the former is not.

If some dirtbag got angry about being passed over for a promotion, got offers for a new gig, and then rage-deleted prod at 5pm on their last day, you get to blame that dude at the post-mortem.

I agree with everything you said. I think you meant to write this to the other person. They kept trying to blame the entirety of leadership for a leadership failure and suggests “picking better leaders”.

I, like you, suggested that the process needs to be improved but I’m not sure how.

Ahhhhhh, legit, sorry. I’d read “whoever is responsible for this needs to go” as referring to only the malicious party—but “better leaders” does indeed suggest the GP wants multiple heads to roll.

You read it right the first time. I am just referring to the malicious party. By saying "better leaders" I mean get rid of the malicious part of your leadership. That will result in a better leadership, thus "better leaders". I must admit, maybe I am expressing myself a bit too mathematical here.

If the incident review shows that it is due to sabotage, how would you deal with the responsible person?

And how can what they did – presenting their own decision to other organisations or levels of their own organisation as if it were the legitimate “Leadership” consensus decision – how could that be anything other than a conscious and intentional act on their part, i.e, to use your term, “sabotage”? It's not like it could somehow be an accident, is it? “Oops, I slipped and fell onto my keyboard and these somewhat coherent and grammatically correct e-mails went out”?

Of-fucking-course it was sabotage, and of course they should be fired as all hell.