I'm late to the party, I know. But writing this post took a little longer. In fact, I wrote it three times, not really sure where I wanted it to go and what I wanted to say. In the end, I think most things have already been said. So this will be short.
Problems
There have been a great number of blog posts about the problems that the Rust community is facing. I recommend you read some of them because they're really good. For example boats who published an article early december about "Organisational Dept". Or killercup about how we count contributions (and other things). Or skade, who published a small collection of articles on organisational subjects.
There's many more under the #rust2019 hashtag on twitter.
My point is: you can read about what the issues are elsewhere, from more perspectives. There's no point in me trying to rehash the same stuff again. I'm not that good a writer that I will bring anything to the table that these people haven't already.
In my opinion the issues we have at the moment are because of two things.
- Teams that have too much responsibility
- Bad tools
(I won't really talk about the tools issue in this post. In summary: the tools we use to communicate are all garbage. And github and discourse comments are terrible for debates. Really, any linear chat platform is terrible - there might be another article at some point)
As I've said, there are plenty of articles that go into what is the problem with our current process. I want to focus on the why, how and how we stop it bit of that.
And first we need to talk about how things are built.
Vision vs Implementation
Fundamentally there are two parts to design:
Vision is what drives a project forward, creating new concepts and thinking about their implications, while Implementation is finding the most elegant, sustainable and performant way of making vision a reality!
Now, these two can very often not be separated as easily as I make it out there. Take the example of the CLI-WG. When we first assembled earlier this year, we started working on a vision: "how should CLI development look". What followed then was an implementation of the vision, as closely as we could manage with the resources and time available. I would argue that during the implementation period of the vision, some aspects of what we thought should be done were influenced by things we learned about how to do them. Like hitting a moving target. To some extent this is how most software development works, unless you are working towards a very well defined spec!
Having the same group of people be in charge of both the overall vision for a system and it's implementation isn't a bad thing, given that the system is small enough!
And this is where teams come in! Splitting up the community into smaller groups who work on the same stuff, so that this kind of collaboration becomes possible again.
In a way, the Rust 2018 working groups were inspired by the same idea. The difference between teams and working groups being, that the latter has a more loosely defined governance structure and allows people to join and collaborate easier and more quickly. There's less "established structure" in a working group. These lower barriers are one of the reasons why I'm a huge fan of working groups, and feel like the Rust project should expand on them in the future. Maybe some teams could even be replaced.
But that's not fundamentally the issue that the project is facing.
Blurring the lines
Problems arise when these lines are blurred too much. This happens with both discussions, as well as to teams of people, who get involved in too many things. Ultimately, we need to face the fact that days are short, people's time is limited and the number of responsibilities a single person can have isn't infinite!
Througout previous blog posts and conversations with others, the need or "desire" to have better communication channels has been made clear. And I feel that we need to work on the way that we communicate, if we are ever to fix the way that we make decisions.
But before I go into detail about what that means to me, specifically, I want to talk quickly about the core team.
The core team is a medium sized group of Rust developers, who oversee large areas of the development of Rust. As the website puts it:
Overall direction and policies of the project, subteam leadership, cross-cutting concerns.
As such, I feel it would be the perfect candidate to step back from implementation, and focus on both vision for the entire language, as well as communication among smaller teams. Unfortunately this hasn't seemed to be the case in the past and is something the core team should work on this year.
Note that I think, that this is a responsibly that should also not be taken lightly. Most of the members of the core team are also active in other teams, sometimes even leading them. I feel that this is one of the reasons why this role has been neglected.
Solutions
So I would sugest something, that I've heard others talk about before, although rarely publicly, which might be considered a bit of a hot take.
The core team should be rotated.
What that means is that the core team in itself still exists, does a certain number of jobs and should be considered quite a time-intensive commitment. But the people involved in it shouldn't stay involved with it forever. Even if it's currently (practically) already the case that the team rotates, making this more explicit and making the roles of the core team a central part of how other teams communicate and operate, I feel would benefit the overall contribution climate of the rust project significantly.
Ultimately, we have a problem in how we communicate. The lines between vision and implementation get blurred too often. Not only in RFC discussions. Implementation specific bikesheds on github often result in new rationale being pushed forward, that have nothing to do with the actual question at hand. And as such, people often talk past each other.
I don't know how wide the communication scope of the core team should be, but I definitely think that moving it's responsibility away from implementation and back towards communication and fostering collaboration between teams and working groups is the approach we will have to take this year to solve our problems of Organisational dept!