Updating style and replacing old rust post

3 files changed, 118 insertions, 371 deletions

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!
-<!-- (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)
+> 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!
diff --git a/crumbs/static/css/crumbs.css b/crumbs/static/css/crumbs.css
index 177b88c..18f637d 100644
--- a/crumbs/static/css/crumbs.css
+++ b/crumbs/static/css/crumbs.css
@@ -26,13 +26,19 @@ a:hover {
   text-decoration: none;
 }
 
+ul {
+    padding-top: 5px;
+    padding-bottom: 5px;
+}
+
+ol {
+    padding-top: 5px;
+    padding-bottom: 5px;
+}
 li {
-  font-size: 22px;
-  font-weight: 300;
-  padding-bottom: 15px;
-  padding-left: 35px;
-  padding-right: 50px;
-  text-indent: 25px;
+  font-size: 19px;
+  margin-left: 15px;
+  text-indent: 5px;
 }
 
 strong {