diff options
Diffstat (limited to 'content/blog/111_rust_2020.md')
| -rw-r--r-- | content/blog/111_rust_2020.md | 24 |
1 files changed, 12 insertions, 12 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 |