parent
453a5f2eb2
commit
f5673f1f4c
GPG Key ID:
90734A9E619C8A6C
@ -0,0 +1,260 @@ |
||||
Title: Rust 2019: abolish all teams |
||||
Category: Blog |
||||
Tags: /dev/diary, rust |
||||
Date: 2019-01-15 |
||||
|
||||
**Disclaimer** this post contains my personal opinions |
||||
and does not reflect on either my employer or the Rust project as a whole! |
||||
|
||||
## The TLDR |
||||
|
||||
Originally I was going to write a long and drawn out post, with a lot of snark, |
||||
explaining why I feel that the current team structure in the Rust project is bad, |
||||
and why it should be overhauled. |
||||
I did at no point call for _all_ teams to be abolished |
||||
(do however fucking abolish ICE!), |
||||
but rather called for a reform on certain teams as well as team membership policies. |
||||
|
||||
Why am I writing this tldr then? |
||||
|
||||
Well, because this is the internet, |
||||
and the world is fast and hectic and I felt like writing a blog post, |
||||
where I came across like an asshole for 2/3s of it would not have been the best idea. |
||||
|
||||
The blog post is nearly as long as it once was, but with less snark. |
||||
And I want you to be aware of this TLDR as you're reading it. |
||||
Call it the abstract to get you interested, if you will... |
||||
|
||||
## Some background |
||||
|
||||
As the year was drawing to a close, a lot of people |
||||
from various involvement-groups of the Rust project started publishing their "Rust 2019" posts. |
||||
Last year around this time I hadn't really been involved in the projet enough |
||||
to warrant writing one, this year feels kinda different though. |
||||
|
||||
If you remember, I wrote a post [how Rust helped] me understand |
||||
the values of "right tool for the right job" |
||||
and also remaking a project I had given up on. |
||||
|
||||
[how Rust helped]: /blog/failure-or-why-rust-is-probably-the-best-programming-language-ever-created |
||||
|
||||
This year a bunch of stuff in my life changed. |
||||
Earlier this year, at the all-hands, I got involved in the development of Rust itself a lot more. |
||||
I'm now in the Community Team and the CLI-WG, and contributing to various tools around the ecosystem. |
||||
It's been an absolutely incredibly and rewarding year to work on stuff alongside such amazing, |
||||
talented and compassionate people. |
||||
|
||||
This post is about none of that. |
||||
Nor is it about the technical visions and ideas I have, going into the new year. |
||||
|
||||
## Organisation Dept |
||||
|
||||
When I was at RustRush Moscow, waiting for people in a hotel lobby, |
||||
withoutboats published a blog post entitled ["Organisational Dept"], |
||||
which I can really only recommend everybody should read. |
||||
In it they outline problems within the governance structure of the Rust project, |
||||
failure to scale and remain open in all of the processes, |
||||
that exist in the development of a language and ecosystem. |
||||
|
||||
["Organisational Dept"]: https://boats.gitlab.io/blog/post/rust-2019/ |
||||
|
||||
I had been thinking about some of these issues before myself. |
||||
In fact, there have been several incidents recently, |
||||
that have made me doubt the effectiveness of the Rust governance structure. |
||||
I don't want to mention any specifically here, |
||||
not wanting to add onto the dog-piling that some members of the community have been involved in. |
||||
Nor do I want to make any excuses for these people. |
||||
|
||||
Needless to say, I don't think it's a hot take to say that the Rust project has growing issues. |
||||
|
||||
## Transparency |
||||
|
||||
The Rust language was largely developed by the community. |
||||
|
||||
Yes, the core team is full of people from Mozilla and companies that are directly |
||||
or indirectly funded by Mozilla, |
||||
but at large, most people in the development teams aren't directly affiliated. |
||||
From the very beginning the Rust project has had an open process for development. |
||||
RFCs were adopted early to guide the design of the language |
||||
and openness in the development process was regarded as important. |
||||
|
||||
**Really, the issues we face today are because of this strive for openness.** |
||||
|
||||
A language development team that can work in a small group and simply |
||||
announce their progress from time to time is going to have |
||||
none of the problems that plague the Rust community today. |
||||
|
||||
With this in mind, it is frustrating to see some recent developments in how decisions were made. |
||||
None of these were by design, nobody knowlingly or purpusefully changed the way that |
||||
collaboration happened, these are simply problems of *scale*. |
||||
In fact, these problems have been known about and awknowledged by many many other people. |
||||
I'm hardly the first person to talk about it. Nor will I be the last. |
||||
|
||||
## Why teams? |
||||
|
||||
The basic idea of a team is to give a group of people a common purpose to work on things. |
||||
"Too many cooks spoil the soup" and all that. Thus smaller teams mean easier collaboration |
||||
between people, on various things. |
||||
|
||||
The idea behind teams isn't even neccessarily a bad one |
||||
(the title of this blog post might be a little clickbatey ... woops 🙊). |
||||
|
||||
Teams are rather static, which makes them different from the "working groups", |
||||
that the Rust project has experimented around with for the "Rust 2018" edition. |
||||
This means that there is such a thing as "team membership", |
||||
which includes being advertised on the website as well as |
||||
some unwritten rules about *how* to become a member. |
||||
This can be frustrating from both the "I want to be on a team, but am not" as well as the |
||||
"Why am I/is that person on a team, they're not really active anymore" side of things. |
||||
Both are sentiments that I've heard from various people throughout last year. |
||||
|
||||
The aforementioned "working groups" on the other hand are very different. |
||||
While their reason for existing is similar to teams, their governance is vastly different. |
||||
Instead of having a fixed membership, their participation is a lot more fluid. |
||||
There are no real requirements for joining a working group, |
||||
other than showing up and doing some stuff. |
||||
Even just contributing to a conversation or discussion means that you are, |
||||
in a sense, part of the working group. |
||||
|
||||
This puts them in direct contrast to the static team membership, |
||||
and also opens up the floor to a lot more people to contribute and get involved, |
||||
without feeling that they need to compete with a pre-existing hierarchy. |
||||
|
||||
**In my opinion, working groups form a much better basis for collaboration than teams!** |
||||
|
||||
Before we get into the nitty gritty though, I want to step back a little... |
||||
|
||||
## Vision vs. Implementation |
||||
|
||||
Fundamentally there are two parts to the design of a language (or...most other things actually): |
||||
|
||||
**Vision** is what drives the 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 team 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!** |
||||
|
||||
This is where things become problematic. This isn't due to the nature of teams in general, but the core team explicitly. |
||||
|
||||
## What is the core team? |
||||
|
||||
The core team is a medium sized group of veteran 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. |
||||
|
||||
Unfortunately that's not what has happened in practice. |
||||
|
||||
Instead, the core team has had a quite fundamental role |
||||
in the implementation aspect of Rust's vision for the Rust 2018 edition. |
||||
And while it's understandable that this has happened, |
||||
it's by no means a positive development. |
||||
In fact I would argue that it's been detremental to the overall communication |
||||
between other teams and has meant that development efforts on core language features |
||||
and additions have shifted away from the public space instead to a small group of people, |
||||
with near-static and intransparent team membership. |
||||
|
||||
This needs to change! |
||||
|
||||
## So then...how? |
||||
|
||||
Abolish the core team! |
||||
<!-- (and borders and cops and fucking burn down the god damn system) --> |
||||
|
||||
The Rust project has no place for an oligarchy of developers, |
||||
who semi-privately guide not just the vision of the language |
||||
but also it's implementation. |
||||
Even if conversations don't *technically* happen in private, |
||||
to any outsider or only slightly-involved person, |
||||
the authority of the core team and the existing social bonds between people |
||||
will feel like a wall, keeping them out. |
||||
|
||||
(Please understand that I'm not trying to attack any particular (or any) members of the core team, |
||||
but instead the institutions that they exist in. |
||||
These are institutional problems, no personal ones. |
||||
There's no bad actors that make the system suck, the system just sucks) |
||||
<!-- see capitalism --> |
||||
|
||||
This shouldn't even be such a hot take, |
||||
given that literally the [keynote from RustConf] last year was about issues like this. |
||||
Ashley, Niko and Aaron called themselves out in context of the "module system discussion" |
||||
about having done conversations in an in-group, |
||||
while writing an RFC that impacted the language quite significantly. |
||||
A process isn't just open when people get to have influence on what decisions are taken, |
||||
but only when the decision creation process is open as well! |
||||
|
||||
[keynote from RustConf]: https://www.youtube.com/watch?v=J9OFQm8Qf1I |
||||
|
||||
## Wrapping up |
||||
|
||||
I could go on about this, but I kinda wanna get to a point. |
||||
What is my point here? |
||||
|
||||
First of all, I really like the concept of working groups. |
||||
They are a low-barrier of entry system to get people involved |
||||
in the domain-specific planning and execution of certain language ecosystems. |
||||
And they provide a friendly way for outsiders to stick their heads in the door |
||||
to checkout out how all this stuff works, |
||||
and maybe get involved in more central ways down the line. |
||||
Again...this is literally how I joined the Rust project. |
||||
|
||||
But secondly... |
||||
|
||||
Maybe (not just maybe) "abolish the core team" is hyperbole. |
||||
But we need to refine it. |
||||
Because in it's current form it just doesn't work and it's having negative effects for the project, |
||||
as well as the people *on* the team, who are burning out from the work they are doing. |
||||
|
||||
What's the idea then, you may ask? |
||||
|
||||
Simple: **Rotate the team!** |
||||
|
||||
Letting a small group of people who remain members, |
||||
until they no longer want to work on that position, |
||||
decide the vision of the project isn't eactly democratic. |
||||
|
||||
And I'm not saying there need to be regular elections. |
||||
I'm not calling to create a government here! |
||||
What I'm saying is that we should have a conversation about the *possibility* of having a process, |
||||
in which the Rust project core team is rotated around, giving more people the ability to contribute |
||||
in that role. |
||||
What it also means is that there is precedence for someone from the core team to |
||||
*no longer be on the core team*, if they - say - have too much other stuff going on! |
||||
|
||||
The core team would at this point be disconnected from pretty much all implementation details, |
||||
be in charge of creating new sub-teams for domains that are deemed important, |
||||
steer general RFC creation (by the domain-specific teams!) |
||||
and help with overall communication. |
||||
|
||||
The core team would still hold a lot of responsibility. |
||||
Looking at where Rust is `$now` and trying to estimate where it will be in `$timespan`, |
||||
and what actions should be put in motion to make a certain change happen in one way or another |
||||
is no small task and shouldn't be underestimated. |
||||
I would argue that someone who is on the core team, |
||||
could maybe have time to be active (full time) in one other team, |
||||
and maybe losely involved in conversation in a third. |
||||
|
||||
Because at some point we need to face the fact that days are only 24 hours long, |
||||
and people shouldn't burn out because of their involvement with the Rust project. |
||||
|
||||
So there. That's my hot take. |
||||
|
||||
Feedback: [hate@spacekookie.de](mailto:hate@spacekookie.de) |
||||
Loading…
Reference in new issue