Rewriting the Rust blog article from scratch

1 files changed, 149 insertions, 0 deletions

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!