Tame Complexity through Community Involvement Tools
Edit: I’d just like to say that I think 2018 has been a great year for rust. Rereading this, I realize may have come off as a little negative. End edit.
Rust has a “big” problem. Our feedback loops have gotten big because we have gotten big (as a community). We’ve started to council together at the end of the year. I don’t think it’s bad, but part of it is reaching consensus on the current state of Rust. I think it’s good actually, but we need more things like it - I’m not suggesting we call for even more blog posts, but that we start tailoring activities to address the “big” problem.
The “big” problem is growth (and increased community size) - it’s a good problem to have, but it does cause issues.
Rust has a lot of gaps caused by its explosive growth, more prominent ones have already been covered:
- A gap between what we have approved (language wise) and what has been implemented (the fallow year)
- A gap between input and processing capacity team/person wise (organizational debt)
- A gap between what we have and what we have documented (Stevek Klabnik’s 2019 post)
These are all artifacts of growth. It’s gotten harder to hold everything about Rust in your head. The tools the Rust community has been using (mostly github provided ones) were good at small sizes, but don’t scale well. They’re leaky abstractions. Pros and Cons analysis with consensus represented by a linear discussion, state scattered across the web, etc. Harder to follow, harder to moderate, harder to contribute to.
It’s harder to:
- track things you care about (I see this as a large contributing factor in the impl Trait return position & website controversies)
- see the overall status of rust
- see where things need help
We should build something to fix that.
We should build Rust specific infrastructure to manage the complexity that comes community sprawl (the sprawl is not bad). Organization specific infra is a thing (I’m looking at you task-cluster that replaced jenkins)
What will it look like? I’m not sure, but I suspect each team will need something different - form following domain.
I have a couple of ideas after reading some other Rust2019 posts of what said central, easy to find tooling should include:
We should probably get an RFC tracker. A real tracker, not github issues (Can you imagine if https://caniuse.com/ used Github issues/prs for its UI? ). Lets track by time and state, category and syntax impact (and more?!). There is so much metadata about RFCs that would be useful if it was understandable by computers. Lay people could get a better idea of what’s going on, and contributors could see what’s happening at a glance.
In addition to the overview/tracking tool, we need a better tool for contributors of RFCs to use. Discussion is the big one. Can we build a tool for structured discussions - pros/cons, links to other RFCs, view changes overtime and hidden votes (because while things aren’t a popularity, it’s probably still a good idea to let people express themselves, even if only so the moderators / leaders can see). There are also proposals for limiting throughput, a more distinct staged process, needing a team champion, etc. We could integrate that too.
I heard the docs need love. So it’d be great to have a list of things that need doing. Sections to proofread, sections that need feedback (e.g. I’m trying to accomplish x, but it’s not working / coming off right), things to write (cookbook), brainstorming structure/approach ideas, etc.
It’d also be nice to a have one big index to rule them all, about the various docs, what’s next on the doc teams plate (we’re hoping to improve x, other big initiatives, etc), etc.
The embededded working group could probably use a page listing all the platforms, and what their status is, along with a list of drivers. It actually probably exists. Somewhere.
There are probably other things for other teams that would be great to put into this one, mythical centralized location. An improved team index would be nice (e.g. direct links to the discord / other place of preferred chat, links to the team specific areas, etc.)
If we were to open infrastructure support to contributors (I have a perfectly good machine laying around I’d be willing to run a CI runner on 24/7), we’d probably want a public dashboard of some sort listing current capacity and a way to volunteer your computer. Barring that, we’d probably want a graph of average wait time on compiler PRs (which is measured in days!).
There is surely a lot more than this to what we’d want (I think) - I’m not really familiar enough to say though. Heck half these things are from what I’ve read in the 2018 posts, if not more.
The rust community has been great. In addition to the great language, the people are great, and trying hard things - transparent consensus (well, taking in put into account)-based decision making. It’s been harder to do that at scale (it either exacts a big toll or breaks down). I think we should fix that.
This is a call to trade generic tools for hand-crafted tools. To trade in a little team personality (each team does stuff differently), for less friction (and more accessible to new people).
Custom tooling is a big effort. But I think it’s the best way a growing community long term without giving up the great things that characterize Rust’s governance and growth.