3 ms·

> ### How does this group make decisions? In the early days of the Apache Software Foundation, individual projects were expected to draft their own bylaws. Thi

> ### How does this group make decisions? In the early days of the Apache Software Foundation, individual projects were expected to draft their own bylaws. This had the advantage of getting project members to think about hard about the content of the bylaws. However, it had the downside of producing a lot of sloppy bylaws with ambiguous or otherwise unworkable rules. For instance, some bylaws were written to require 3/4 of the all eligible voting members to change them, rather than 3/4 of those who vote — which can become a problem as members with voting privileges go inactive and become unreachable. Documenting processes by which conflicts are resolved is hard. If you're lucky, most of the time, the rules don't matter as people reach consensus without having to go through exacting, difficult negotiations. But when you really need a formal process to resolve conflict, then it matters if your process is borken and pathological. The best high-level design is to have the rules for resolving conflicts written by a few specialists who really care about precise drafting, and for most other entities within the organization to inherit those rules whenever possible.

steveklabnik 6y ago
The situation here is more about getting it written down at all than it is having conflicting systems; teams almost exclusively operate by full consensus among members, but that's through the sort of inheritance you refer to, rather than having it actually written down somewhere.
- rectang 6y ago
  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

The situation here is more about getting it written down at all than it is having conflicting systems; teams almost exclusively operate by full consensus among members, but that's through the sort of inheritance you refer to, rather than having it actually written down somewhere.

rectang 6y ago
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.