1 files changed, 7 insertions, 7 deletions

diff --git a/content/blog/111_rust_2020.md b/content/blog/111_rust_2020.md
index 9dc3514..bff315c 100644
--- a/content/blog/111_rust_2020.md
+++ b/content/blog/111_rust_2020.md
@@ -59,7 +59,7 @@ 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
+and iterations on the design can seem arbitrary, or on the other hand
 some RFCs remain open for years, in limbo, where nothing really
 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
@@ -91,13 +91,13 @@ 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?
+the authors, and how is 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
+They *do not* need to actually understand where the discussion is
+heading, 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 un-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).