“I'm basically giving myself a permanent vacation from being BDFL”

OP wants code to legislate trust problems within a small, closed group, however no amount of code can ever solve trust problems within a small, closed group.

No amount of code thrown at people mismanaging their relationship with other people will ever help people more effectively manage their relationship with those people -- it just creates artificial obstacles that further exacerbate or obscure the problem.

There is simply no combination or refinement of the logic OP proposed that would ever be perfectly sufficient to avert the need for human judgement in their scenario.

What if 51% of the project simultaneously reveal themselves to be alt-right fanatics who want to take the work in a new, fundamentally evil direction, ideologically aberrant to OP? Oh that's easy - OP can just step in with his admin privileges and disable their access. And that just underscores the point -- the original voting logic was a facade, and the original trust problem remained. The presence of that logic failed to solve any problem, the reality was always a true power structure that differed from the imaginary codified structure.

Perhaps one alternative would be for OP to give up admin rights entirely - but only a fool would believe a bunch of codified rules spread across a couple of software functions could ever perfectly mediate the complexities of a community of people in every possible scenario.

I hadn't considered the problem to be solved one of trust (which I agree can't be solved with technology), but rather one of coordination/ social choice. Technology again is a valuable assist in this sphere (e.g. evaluating the results of theoretically-nice-but-computationally-heavy voting methods like Schultz or Kemeny-Young).

Slow down, I don't think I've done a single thing about "trust."

That's still a social problem.

What I want is that the mechanical process of doing code reviews, accepting pull requests, and orchestrating the Access Control Lists, and the membership of them, can be implemented by the code repo.

Rather than giving unfettered power to a small list of owners, who could literally do anything to the repo. And if they all get hit by the same bus, then we're SOL.

Heck, I want a Deadman Switch, too. If Github doesn't hear from me in 90 days, even after emailing me to get my attention, then ownership of this repo should be assigned to this other person. If that fails, on to this other person, etc.

"only a fool would believe a bunch of codified rules spread across a couple of software functions could ever perfectly mediate the complexities of a community of people in every possible scenario."

Or someone who has experienced such a system at a company, and wishes the rest of the world had similar functions.

Note that I'm happy to allow for escape hatches... Such as we could always Fork the repo.

"What if 51%"

Then I fork the repo.

What do you do if the 1 single owner of a repo turns out to be a fanatic?

You and twenty other people all fork the repo, and then debate ensues about who is the One True Repo.

I'm suggesting that there's a smarter way to handle the problem of a small number of people having absolute power over our repos.

And if you're smart, you leave in a provision for completely changing the governance, in case you screw it up. Or you just fork. Like we do today.