From 68fddf3c4d4714783347877672d8229cc1077464 Mon Sep 17 00:00:00 2001 From: Katharina Fey Date: Mon, 21 Jan 2019 13:47:01 +0100 Subject: Rewriting the Rust blog article from scratch --- content/blog/105_rust_2019.md | 149 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 149 insertions(+) create mode 100644 content/blog/105_rust_2019.md (limited to 'content/blog') diff --git a/content/blog/105_rust_2019.md b/content/blog/105_rust_2019.md new file mode 100644 index 0000000..e5bdeb6 --- /dev/null +++ b/content/blog/105_rust_2019.md @@ -0,0 +1,149 @@ +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