From f5673f1f4c899062ede567b178b2281c4754c83c Mon Sep 17 00:00:00 2001 From: Katharina Fey Date: Mon, 14 Jan 2019 15:10:42 +0100 Subject: Updating Rust 2019 blog pots --- Makefile | 4 +- content/blog/103_rust_2019.md | 260 +++++++++++++++++++++++++++++ crumbs/static/css/crumbs.css | 2 +- crumbs/templates/components/html_head.html | 18 +- 4 files changed, 266 insertions(+), 18 deletions(-) create mode 100644 content/blog/103_rust_2019.md diff --git a/Makefile b/Makefile index d1ddf80..4579789 100755 --- a/Makefile +++ b/Makefile @@ -87,9 +87,9 @@ endif devserver: ifdef PORT - $(BASEDIR)/develop_server.sh restart $(PORT) + $(BASEDIR)/develop_server.sh restart $(PORT) > /dev/null else - $(BASEDIR)/develop_server.sh restart + $(BASEDIR)/develop_server.sh restart > /dev/null endif stopserver: diff --git a/content/blog/103_rust_2019.md b/content/blog/103_rust_2019.md new file mode 100644 index 0000000..31acf72 --- /dev/null +++ b/content/blog/103_rust_2019.md @@ -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! + + +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) diff --git a/crumbs/static/css/crumbs.css b/crumbs/static/css/crumbs.css index 36a4701..177b88c 100644 --- a/crumbs/static/css/crumbs.css +++ b/crumbs/static/css/crumbs.css @@ -36,7 +36,7 @@ li { } strong { - font-weight: 500; + font-weight: 700; } h1, h2, h3, h4 { diff --git a/crumbs/templates/components/html_head.html b/crumbs/templates/components/html_head.html index d9fc581..f08683b 100644 --- a/crumbs/templates/components/html_head.html +++ b/crumbs/templates/components/html_head.html @@ -11,22 +11,10 @@ {% endif %} - + + + - - {# Use my own Matomo for some visitor tracking #} - -- cgit v1.2.3