Updating Rust 2019 blog pots

4 files changed, 266 insertions, 18 deletions

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!
+<!-- (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)
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 @@
         <link href="{{ SITEURL }}/theme/css/crumbs.css" rel="stylesheet">
     {% endif %}
 
-    <link href="https://fonts.googleapis.com/css?family=Montserrat:200,300,400,500;subset=cyrillic,latin-ext" rel="stylesheet"> 
+    <link href="https://fonts.googleapis.com/css?family=Montserrat:400,700,900" rel="stylesheet">
+    <!-- <link href="https://fonts.googleapis.com/css?family=Montserrat:300,400,600;subset=latin-ext" rel="stylesheet"> -->
+
     <link href="https://fonts.googleapis.com/css?family=Inconsolata" rel="stylesheet"> 
     <link rel="stylesheet" href="https://use.fontawesome.com/releases/v5.0.6/css/all.css">
     <link rel="alternate" type="application/rss+xml" href="{{ SITEURL }}/rss.xml" title="{{ SITENAME }} — Latest Posts" />
-
-    {# Use my own Matomo for some visitor tracking #}
-    <script type="text/javascript">
-        var _paq = _paq || [];
-        _paq.push(['trackPageView']);
-        _paq.push(['enableLinkTracking']);
-        (function() {
-            var u="//stats.spacekookie.de/";
-            _paq.push(['setTrackerUrl', u+'piwik.php']);
-            _paq.push(['setSiteId', '1']);
-            var d=document, g=d.createElement('script'), s=d.getElementsByTagName('script')[0];
-            g.type='text/javascript'; g.async=true; g.defer=true; g.src=u+'piwik.js'; s.parentNode.insertBefore(g,s);
-        })();
-    </script>
 </head>