[Meta] how to make decisions as a team during disagreement

[kailuowang]

In the past, there were a couple of times when discussions went into a stalemate but we also kind of really need to make the decision to move ahead. In some of those cases, I jumped out of nowhere and listed the options and propose a vote, and we did and moved forward.
In other situations, when the need to make a decision is not compelling, the usual outcome is simply no decision which results in the PR/change proposal being tabled without a clear verdict, which might be fine but the downside is that later such PR/change proposal might surface again and we are back in the circle.

We can probably optimize this process a bit. Let's discuss in this issue.

[djspiewak]

My vote would be for a sort of de facto fiat meritocracy. This is a terrible system for most things, btw, and probably terrible for software too, so take my recommendation with a grain of salt.

Basically, whoever does the work, gets the final say. And by "does the work" I mean "takes point on project maintainership/leadership/all-the-non-sexy-things." You've been doing that for cats. @alexandru has been doing that for cats-effect. As far as I'm concerned, you get the final vote and veto power on cats, just as Alex gets final vote and veto on cats-effect. Whether you choose to exercise it is your discretion.

This system more or less runs into two problems. First, it relies on the fiat dictators (e.g. you and Alex) to make good decisions that take into account the wisdom of the masses in a reasonable way, where you get to define what "reasonable" means. It also lays on the shoulders of the fiat dictator all of the blame when things go wrong. Second, sometimes there are changeovers in leadership, such as when I had to take a step back from cats-effect last year, or going even further back, when Jason had to take a step back from scalaz and effectively yielded to Lars. Sometimes these transitions can go extremely well (Alex has been awesome). Sometimes it can cause long-term friction. A lot of that comes down to goodwill and whether or not drama was avoided in the reasoning behind the stepping-back.

I don't really know what the idea answer is. Fiat meritocracy works amazingly as long as everyone involved, short- and long-term, has good intentions at heart. It works horribly the moment malice, politics, and pettiness become factors. There probably isn't a way we can protect against that situation without creating insane bureaucracy though.

So the tldr for us would be something similar to what @johnynek proposed here: fiat dictator gets final say as necessary, tries to delegate responsibility and decision-making whenever possible to the community, but ultimately casts the deciding vote. Fiat dictator can be chosen by default (i.e. I think everyone mostly yields to @kailuowang on cats matters even though we've never explicitly discussed this), or could be voted in by a more formalized process (such as what @johnynek suggested). I'm kind of ok with either, though I'm personally always going to bias my respect towards the person who's actually doing the hard work (Kai in this case), whoever that happens to be.

I'm not super fussed about it though. I recognize the value in talking about this stuff before the need arises rather than after, but it is nice that the needs have been of the mostly passive obstruction and entropy variety, rather than actively dramatic.

[ghost]

Very briefly... I think we need a "place" to put the long term, big issues as opposed to the short term ones. @djspiewak has been very good at promoting the root causes recently, as has @johnynek with, for example, BC and related issues. But of course, these can conflict with short term issues and PR's, etc.

So just having some "roadmap/strategy" issues/docs might help out to help steer things along in the right direction.

And yes, @kailuowang if all else fails 😄

[djspiewak]

Agreed with @BennyHill. A more cynical view of my "very good at promoting the root causes" might be to say that I'm just armchair obstructing real work. 😃 Some more explicit roadmap/strategy/acceptance-criteria/stuff would be really great, especially when things come up like the Monad[Future] discussion.

[johnynek]

The rust community has recently had some concerns with hashing things out in an issue, then people not realizing it was happening and coming after the decision was made to rail against it.

I might suggest that we have a discussions directory and work on proposals as docs, and then use the PR to see if it should be adopted.

Things like: why we currently include the Monad on Try (or Future) referencing the Osheim doctrine on lawfulness: https://gist.github.com/non/4d1f49fe41e2f12c463ae075bf5d0f06

Then we can have the discussion, merge the PR and we have a doc that makes a case.

The case where we can't really come to a conclusion, I hope won't happen. I hope we can solve those conflicts together, but if close, I would like us to have some way of closing the discussion.

I do prefer having a specific chief maintainer, who does have to do more work, but also gets to settle these questions (or has to settle them). I would like to reconsider that role every so often.

We could see how this works for now.

The last question: if we make it more formal who is a cats committer (someone who can merge PRs, gets a voice in the maintainer choice), how do we add an remove people from this set?

You could do something like, everyone who has sent a PR in the last year can vote once a year for a set of committers, and say the maintainer can count the votes.

Anyway....

[alexandru]

A process requiring voting feels too formal and should be done only when there's disagreement. Voting involves politics and I'd rather avoid that if possible. For example @kailuowang is very involved in the development and maintenance of Cats, I saw him fix incomplete PRs and push releases forward. There's no question in my mind that he's currently qualified to settle harsh decisions.

There are instances in which there are valid arguments thrown back and forth and you need to resort to voting in order to move forward. Deferring to the popular vote of the contributors is a useful way to unblock things. And if that doesn't solve the issue, then yes, every project needs an active "benevolent dictator", or maybe a group of benevolent dictators that can agree on moving controversial issues forward.

I have this view that in the real world companies and organizations are not democracies. There's always a chain of command, which in open source projects gets established via meritocracy, although I find it really interesting that "meritocracy" was coined by Michael Young in The Rise of the Meritocracy with a negative connotation, the book being a satire 🙂

I do agree with having documents or detailed PR descriptions explaining the hard decisions being made in order to refer to them, because for popular projects it is a guarantee that you'll get people disagreeing with those decisions (on the chat channels, etc) without considering all the variables in play and having something to refer to is much more efficient.