Adding note about shepherds and fixing markup

1 files changed, 12 insertions, 6 deletions

diff --git a/content/blog/111_rust_2020.md b/content/blog/111_rust_2020.md
index e2b8645..9dc3514 100644
--- a/content/blog/111_rust_2020.md
+++ b/content/blog/111_rust_2020.md
@@ -109,13 +109,19 @@ 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.
 
+**An important note here:** shepherds don't have to be part of a team that
+would otherwise oversee the development of a feature (like lang or
+compiler) and instead can be any community member who feels like
+nominating themselves or who is nominated by someone else. The idea is
+that *everybody* should be involved in overseeing incoming RFCs.
+
 ## 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.
+to remain a healthy project, 5, 10 or 15 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]
@@ -138,13 +144,13 @@ 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
+`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
+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.
+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
+There's `clap` 3.0 things that are happening although maybe those will
 all be done by the end of the year. Who knows?
 
 But mostly, I want to address a pain point in application
@@ -163,7 +169,7 @@ 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
+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