But we’ve long since reached the point where coordinating our design vision by osmosis is not working well

(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: lawrence@krubner.com, or follow me on Twitter.

The community around the Rust language is increasingly in conflict with itself. Why allow a team to grow out of control like this?

That’s a total of 770 comments on the design of the API for the Pin type, which has not yet been stabilized; I expect it will pass 800 comments before this is done. This is just one significant but ultimately fairly small std API addition, and it doesn’t isn’t including the discussion that’s gone on around the features that are built on top of it, like async/await, generators and futures. And it doesn’t include discussion outside of official venues, like reddit threads and IRC or Discord chatter.

Rust is my full time job and even I find it impossible to keep up on every design discussion happening related to the teams that I am on (lang, libs, and cargo). Its been a regular event this year that I discover during lang team triage that there’s a new RFC I hadn’t seen that already has more than 50 comments. For someone who isn’t paid to do this, trying to participate productively in any of these discussions seems extremely difficult.

…In order to produce a coherent user experience, Rust needs to have a cohesive design vision across different aspects of the product. It used to be, when the total team membership was under 30 people, that a shared vision could be diffused naturally across the project, as people involved in mutual projects coordinated and discussed and developed their viewpoints together, like a beautifully evolving neural network.

But we’ve long since reached the point where coordinating our design vision by osmosis is not working well. We need an active and intentional circulatory system for information, patterns, and frameworks of decision making related to design. I’ve run into threads repeatedly this year in which decision making felt frought to me because we had no guidelines from which to make decisions. Different teams begin to diverge in product viewpoint, different components become managed by subsets of teams and other contributors without much interaction from the rest of the team, and the project risks becoming scattered and irregular.

About this:

It used to be, when the total team membership was under 30 people, that a shared vision could be diffused naturally across the project, as people involved in mutual projects coordinated and discussed and developed their viewpoints together, like a beautifully evolving neural network.

So why not limit the decision making to 30 people?

Source