From 251b0c790887573526f586c4d5b0869fdf59e165 Mon Sep 17 00:00:00 2001 From: Katharina Fey Date: Mon, 21 Jan 2019 13:57:13 +0100 Subject: Updating style and replacing old rust post --- content/blog/103_rust_2019.md | 322 ++++++++++++++---------------------------- content/blog/105_rust_2019.md | 149 ------------------- 2 files changed, 106 insertions(+), 365 deletions(-) delete mode 100644 content/blog/105_rust_2019.md (limited to 'content') diff --git a/content/blog/103_rust_2019.md b/content/blog/103_rust_2019.md index 31acf72..cf243e5 100644 --- a/content/blog/103_rust_2019.md +++ b/content/blog/103_rust_2019.md @@ -1,134 +1,56 @@ -Title: Rust 2019: abolish all teams +Title: Rust 2019: how we make decisions Category: Blog Tags: /dev/diary, rust -Date: 2019-01-15 +Date: 2019-01-21 -**Disclaimer** this post contains my personal opinions -and does not reflect on either my employer or the Rust project as a whole! +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. -## The TLDR +## Problems -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. +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. -Why am I writing this tldr then? +[boats]: https://boats.gitlab.io/blog/post/rust-2019/ +[killercup]: https://deterministic.space/rust-2019.html +[skade]: https://yakshav.es/rust-2019/ -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. +There's many more under the [#rust2019] hashtag on twitter. -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... +[#rust2019]: https://twitter.com/search?q=%23rust2019&src=typed_query -## Some background +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. -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. +In my opinion the issues we have at the moment are because of two things. -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. +- Teams that have too much responsibility +- Bad tools -[how Rust helped]: /blog/failure-or-why-rust-is-probably-the-best-programming-language-ever-created +(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) -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. +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. -This post is about none of that. -Nor is it about the technical visions and ideas I have, going into the new year. +And first we need to talk about how things are built. -## Organisation Dept +## Vision vs Implementation -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. +Fundamentally there are two parts to design: -["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, +**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! @@ -150,111 +72,79 @@ 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. +Exactly this is where the concept of teams comes in. +Splitting up the community into groups of people who work on the same stuff, +in smaller numbers, so that collaboration on this scale becomes possible agian. + +In a way, that was also the idea of the working groups for the Rust 2018 edition. +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. +This is one of the reasons why I feel that the Rust project +needs to expand on the idea of working groups, maybe even replacing some teams. + +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. -## What is the core team? +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 veteran Rust developers +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! - - -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) - - -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) +> 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. + +I think 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 other teams. +I feel that this has lead to the role of the core team being 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! diff --git a/content/blog/105_rust_2019.md b/content/blog/105_rust_2019.md deleted file mode 100644 index e5bdeb6..0000000 --- a/content/blog/105_rust_2019.md +++ /dev/null @@ -1,149 +0,0 @@ -Title: Rust 2019: how we make decisions -Category: Blog -Tags: /dev/diary, rust -Date: 2019-01-19 - -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. - -[boats]: https://boats.gitlab.io/blog/post/rust-2019/ -[killercup]: https://deterministic.space/rust-2019.html -[skade]: https://yakshav.es/rust-2019/ - -There's many more under the [#rust2019] hashtag on twitter. - -[#rust2019]: https://twitter.com/search?q=%23rust2019&src=typed_query - -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.) - -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 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!** - -Exactly this is where the concept of teams comes in. -Splitting up the community into groups of people who work on the same stuff, -in smaller numbers, so that collaboration on this scale becomes possible agian. - -In a way, that was also the idea of the working groups for the Rust 2018 edition. -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. -This is one of the reasons why I feel that the Rust project -needs to expand on the idea of working groups, maybe even replacing some teams. - -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 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. - -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. - -I think 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 other teams. -I feel that this has lead to the role of the core team being 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! -- cgit v1.2.3