Fixing some phrasing issues with the draft

2 files changed, 12 insertions, 189 deletions

diff --git a/content/blog/111_rust_2020.md b/content/blog/111_rust_2020.md
index 0d27df9..c8591fd 100644
--- a/content/blog/111_rust_2020.md
+++ b/content/blog/111_rust_2020.md
@@ -22,13 +22,13 @@ interacting with the NixOS RFC process.
 
 An RFC, or "request for comments" is a mechanism by which a group of
 people can get feedback from a wider community on proposed
-changes. The idea being, that a proposal is written, outlining it's
-scope, implementation details, retionale and impact on the ecosystem,
+changes. The idea is that a written proposal outlines a change's
+scope, implementation details, rationale and impact on the ecosystem,
 then people make comments on the proposal. Usually by the time that
 everybody has stopped shouting at each other, the RFC is ready to be
-merged, meaning it is accepted and it's vision can be
-implemented. This can either be implementing a feature, or removing
-`unstable` flags from it.
+merged, meaning it is accepted and it's vision can be implemented.
+This can either be implementing a feature, or removing `unstable`
+flags from it.
 
 Unfortunately I'm not being too flippant here: the procedure of how an
 RFC goes from "proposed" to "accepted" is very vague and can depend on
@@ -61,9 +61,9 @@ The fact that an RFC is proposed, with no real structure or framework
 on how to continue afterwards means that either feedback is chaotic
 and iterations on the design can seem arbitrary, and on the other hand
 some RFCs remain open for years, in limbo, where nothing really
-happens on them. Both aren't great outcomes, add to stress for the
-people who were involved in writing them, and generally just slows
-down our decision making process.
+happens on them. Both aren't great outcomes, only add to stress levels
+of the people who were involved in writing them, and generally just
+slows down our decision making process.
 
 As XAMPPRocky wrote in her blog post:
 
@@ -73,9 +73,9 @@ As XAMPPRocky wrote in her blog post:
 > to this growth.
 
 While she was talking about how many people get paid for Rust, I feel
-this is also applicable to the way that we make decisions. I wrote
-about this as well in my [Rust 2019][rust2019] post, without giving
-specific examples on how to fix it. Well, I'm mentioning it again,
+this is also applicable to the way that we make decisions. Many people
+wrote about the RFC process for their Rust 2019 posts in rather vague
+terms, including [myself][rust2019]. Well, I'm mentioning it again,
 because I feel like we should try something concrete.
 
 [rust2019]: https://spacekookie.de/blog/rust-2019-how-we-make-decisions/
@@ -145,7 +145,7 @@ improvements to the crate itself, as well as compatibility with other
 crates (such as `diesel` and other migration toolkits), I want to make.
 
 There's `clap 3.0` things that are happening although maybe those will
-all be done by the time of the near year. Who knows?
+all be done by the end of the year. Who knows?
 
 But mostly, I want to address a pain point in application
 packaging. Over the last year I've been tricked into maintaining a
diff --git a/content/blog/xxx_rust_2020.md b/content/blog/xxx_rust_2020.md
deleted file mode 100644
index 4339604..0000000
--- a/content/blog/xxx_rust_2020.md
+++ /dev/null
@@ -1,177 +0,0 @@
-Title: Rust 2020: the RFC process and distributions
-Category: Blog
-Date: 2019-11-11 11:11
-Tags: /dev/diary, rust, roadmap
-
-I must have missed an e-mail in my inbox, because recently I started
-seeing people publish Rust 2020 blogposts so I thought, why not. I
-haven't been incredibly involved in the development of Rust in the
-last few months, (navigating the delicate balance of being self
-employed, working on free software and not burning out) but I feel
-like that might change again. And also, I still have *feelings about
-software*.
-
-This post was also largely inspired by my friend [XAMPPRocky's post][erin],
-as well as attending [NixCon][nixcon] a few weeks ago, and generally
-interacting with the NixOS RFC process.
-
-[erin]: https://xampprocky.github.io/public/blog/rust-2021/
-[nixcon]: https://2019.nixcon.org/
-
-## What even is an RFC?
-
-An RFC, or "request for comments" is a mechanism by which a group of
-people can get feedback from a wider community on proposed
-changes. The idea being, that a proposal is written, outlining it's
-scope, implementation details, retionale and impact on the ecosystem,
-then people make comments on the proposal. Usually by the time that
-everybody has stopped shouting at each other, the RFC is ready to be
-merged, meaning it is accepted and it's vision can be
-implemented. This can either be implementing a feature, or removing
-`unstable` flags from it.
-
-Unfortunately I'm not being too flippant here: the procedure of how an
-RFC goes from "proposed" to "accepted" is very vague and can depend on
-*a lot* of factors. Needless to say, this can also be the source of a
-lot of conflict in a community.
-
-Rust has had an RFC process for a few years now, and most, if not all
-decisions to the language and ecosystem have gone through it, and the
-community feedback it entailed. Some go largely overlooked, like [this
-one][rfc1] that I co-authored at the Rust All Hands 2018 in Berlin
-(it's fine, I understand), others get hundreds of comments. This often
-results in no meaningful conversations, in large parts because it's
-hard to have a discussion with 1000 people, and in other part because
-GitHub is a *terrible* platform to do anything on (sequel hook).
-
-[rfc1]: https://github.com/rust-lang/rfcs/pull/2376
-
-## RFC chaos
-
-I remember this issue first coming up in the module refactoring
-debates and the three (?) RFCs that were in total created before
-everybody felt happy enough about it. These were the first large RFCs
-I witnessed while being kinda part of the community. Many of the
-people who were involved in them talked about how stressful it had
-been and I think they might also be the first time that the RFC
-process, the way that the Rust project implemented it, started showing
-limitations of scale.
-
-The fact that an RFC is proposed, with no real structure or framework
-on how to continue afterwards means that either feedback is chaotic
-and iterations on the design can seem arbitrary, and on the other hand
-some RFCs remain open for years, in limbo, where nothing really
-happens on them. Both aren't great outcomes, add to stress for the
-people who were involved in writing them, and generally just slows
-down our decision making process.
-
-As XAMPPRocky wrote in her blog post:
-
-> When 1.0 launched there was ~30 members of The Rust Programming
-> Language, now in 2019 we have ~200 members. This is nearly 7x the
-> amount of members, yet we've changed very little to be able to adapt
-> to this growth.
-
-While she was talking about how many people get paid for Rust, I feel
-this is also applicable to the way that we make decisions. I wrote
-about this as well in my [Rust 2019][rust2019] post, without giving
-specific examples on how to fix it. Well, I'm mentioning it again,
-because I feel like we should try something concrete.
-
-[rust2019]: https://spacekookie.de/blog/rust-2019-how-we-make-decisions/
-
-## Shepherds and an RFC committee
-
-The NixOS project has two concepts in their RFC process which I think
-are valuable and that the Rust project would benefit from: RFC
-Shepherds and the RFC steering committee.
-
-The RFC steering committee is a group of between 5-6 people, assigned
-for a year to oversee any new RFC, make sure that shepherds get
-assigned to it, and also keep tabs on progress that is being made. Are
-shepherds regularly (in whatever interval they deem appropriate)
-meeting to discuss the RFC, is feedback being taken into account by
-the authors, how the discussion generally going?
-
-They *do not* need to actually understand where the discussion had
-headed, but make sure that a discussion is happening. This would solve
-the problem of RFCs remaining open for years, without getting any
-further feedback and cluttering the PRs page of open RFCs. RFCs that
-were forgotten about by their authors or that the community has
-largely moved on from can be closed/ rejected. It can also give
-closure to people who have written RFCs that was never rejected, but
-not accepted either (again, I'm cool, don't worry).
-
-RFC shepherds are then assigned to an RFC (3-5 people) to actually
-oversee the discussion and consolidate feedback into changes that can
-be made on the RFC. They are also responsible for regular (again, up
-to them how regular) meetings discussing the wider implications, as
-well as small details of an RFC, usually on a video call, taking notes
-for people who can't attend to read up on afterwards.
-
-## Governance WG and a new process
-
-Generally, I think we all know that the RFC process needs to
-change. It has a bunch of problems that have lead to people physically
-and mentally burning out while contributing to Rust. And, as
-XAMPPRocky mentioned in her post, sustainability is important for Rust
-to remain a healthy project, 5 or 10 years down the line.
-
-I haven't followed a lot of progress from the governance workinggroup,
-but reading their charter and some of the proposed [RFC stages][gov]
-might address some of the issues in the process. I feel that
-introducing a new RFC governance body (a set of people who rotate) as
-well as the concept of RFC shepherds would be beneficial to the Rust
-project as a whole, and anyone who's involved in any RFC related
-discussions in the future.
-
-[gov]: http://smallcultfollowing.com/babysteps/blog/2018/06/20/proposal-for-a-staged-rfc-process/
-
-There's some tooling issues to address as well, but I feel those are
-second to the social ones.
-
-## Distributing Rust code
-
-Wow, yea this was supposed to be a post about Rust 2020 and my
-personal roadmap. While I would love to be involved co-authoring an
-RFC on changing the RFC process in the ways that I propose in this
-post, there's some personal projects I want to get going as well.
-
-At the beginning of the year I told myself that my SQL migration crate
-`barrel` would see a `1.0` release by the end of the year. This is
-looking less and less likely, but I want to at least get close to
-it. And then, next year, there will be a `1.0`. There's a bunch of
-improvements to the crate itself, as well as compatibility with other
-crates (such as `diesel` and other migration toolkits), I want to make.
-
-There's `clap 3.0` things that are happening although maybe those will
-all be done by the time of the near year. Who knows?
-
-But mostly, I want to address a pain point in application
-packaging. Over the last year I've been tricked into maintaining a
-Linux distribution, NixOS. And while I'm not _that_ involved in the
-development of it, there's some things that often come up with
-packaging Rust applications that could and should be better.
-
-Mostly this is about applications, written in Rust, that want to
-distribute artifacts other than their binaries as well. Be that
-generated man pages, default configuration, or static files for a
-website. Currently this process is entirely up to the packager of an
-application and relies heavily on the application in question having
-good documentation. This is also a problem for _all_ Linux
-distributions, not just NixOS.
-
-Enter `cargo-dist`, a tool that can be used by a project to easily
-declare exportable artifacts and provides a way to tell an external
-packaging tool (such as `nix`, or `dpkg`) where to copy files to make
-a complete, working application. It <del>steals</del> borrows some
-concepts from autotools, using a `PREFIX` and several paths that
-artifacts can be copied into. This way a Rust application can easily
-be made into a package by calling `cargo dist`, which internally does
-a release build, and exports required artifacts to the appropriate
-places.
-
-All of this is pretty WIP and local on my laptop right now. But I
-would love to finish it soon, and see projects in 2020 adopt this as a
-standard to distribute files for Rust packaging.
-