3 ms·

Most of the time, you want to bias for action and not require interacting with the rules to move forward. But "full consensus" has a problem with scale — the m

Most of the time, you want to bias for action and not require interacting with the rules to move forward. But "full consensus" has a problem with scale — the more eligible voting members you have, the more likely it is that you get a holdout on some issue. There needs to be a process by which the concerns of minority factions are heard, which gives the majority a chance to accommodate those concerns rather than steamroll, but then eventually to move on after establishing workable consensus (as opposed to full consensus) despite the holdout. How do you get there — a majority-rule vote, a super-majority rule vote of x% of those voting? How long does the vote run? What's the escalation process? What entity has final say on technical disputes? And so on. Rust is big enough and has been around long enough that it's certain many bitter disputes have arisen and been dealt with — there's surely an abundance of institutional expertise on resolving contentious issues. Nevertheless, it's in everyone's interest to avoid Balkanized, idiosyncratic, possibly suboptimal formal governance rules for the subgroups, so the process of "writing down the rules" should have the goal of producing one central set of canonical rules, possibly customizable, rather than many sets of potentially incompatible and superficially distinct rules.

steveklabnik 6y ago
> Most of the time, you want to bias for action Not everyone agrees with this. One of Rust's core values is stability, and that involves making sure to not move fast and break things. That said, there is always a balance. This is also why I had "almost" in there. There are a few exceptions in certain cases. This is a significant difference between the Apache and Rust outlooks on things. > But "full consensus" has a problem with scale — the more eligible voting members you have, the more likely it is that you get a holdout on some issue. This is true, but you can solve this problem in different ways. Rust takes a federated approach. In the early days, there was only the core team. Eventually, we ran into scale issues. So we broke things out into multiple, smaller teams with full autonomy. This process has continued over time. A lot of the procedural issues you cite only come into effect once you've rejected full consensus. If there's no voting, there's no need for complex supermajority overrule processes. That being said, I fully agree that a common set of rules is a good thing. There's always tension here, because there are pros and cons to uniform rules. We have very common rules for making decisions, but complete balkanization of chat platforms, for example.
- rectang 6y ago
  > > Most of the time, you want to bias for action > Not everyone agrees with this. One of Rust's core values is stability, and that involves making sure to not move fast and break things. Haha, fair point. As a user I appreciate that priority very much. It's hard to resist the pressure to add features. Let me recalibrate and restate: Just because you have a formal process to adjudicate disputes, to the extent possible it should not impact operations when things are going well, infecting everyday routines with needless bureaucratic formalities.

steveklabnik 6y ago

> Most of the time, you want to bias for action Not everyone agrees with this. One of Rust's core values is stability, and that involves making sure to not move fast and break things. That said, there is always a balance. This is also why I had "almost" in there. There are a few exceptions in certain cases. This is a significant difference between the Apache and Rust outlooks on things. > But "full consensus" has a problem with scale — the more eligible voting members you have, the more likely it is that you get a holdout on some issue. This is true, but you can solve this problem in different ways. Rust takes a federated approach. In the early days, there was only the core team. Eventually, we ran into scale issues. So we broke things out into multiple, smaller teams with full autonomy. This process has continued over time. A lot of the procedural issues you cite only come into effect once you've rejected full consensus. If there's no voting, there's no need for complex supermajority overrule processes. That being said, I fully agree that a common set of rules is a good thing. There's always tension here, because there are pros and cons to uniform rules. We have very common rules for making decisions, but complete balkanization of chat platforms, for example.

rectang 6y ago
> > Most of the time, you want to bias for action > Not everyone agrees with this. One of Rust's core values is stability, and that involves making sure to not move fast and break things. Haha, fair point. As a user I appreciate that priority very much. It's hard to resist the pressure to add features. Let me recalibrate and restate: Just because you have a formal process to adjudicate disputes, to the extent possible it should not impact operations when things are going well, infecting everyday routines with needless bureaucratic formalities.