diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst
index b638147fdd..a92773515f 100644
--- a/CONTRIBUTING.rst
+++ b/CONTRIBUTING.rst
@@ -11,9 +11,9 @@ but here's a step-by-step guide that should help you get started.
 Step 0: Join the Conversation
 =============================
 
-Got an idea for how to improve the codebase? Fantastic; we'd love to hear about
+Got an idea for how to improve the codebase? Fantastic, we'd love to hear about
 it! Before you dive in and spend a lot of time and effort making a pull request,
-it's a good idea to discuss your idea with other interested developers; you may
+it's a good idea to discuss your idea with other interested developers. You may
 get some valuable feedback that changes how you think about your idea, or you
 may find other developers who have the same idea and want to work together.
 
diff --git a/docs/en_us/developers/source/testing/code-coverage.rst b/docs/en_us/developers/source/testing/code-coverage.rst
index 754b788e36..7f3f88e7a7 100644
--- a/docs/en_us/developers/source/testing/code-coverage.rst
+++ b/docs/en_us/developers/source/testing/code-coverage.rst
@@ -5,7 +5,7 @@ Code Coverage
 We measure which lines of our codebase are covered by unit tests using
 `coverage.py`_ for Python and `JSCover`_ for Javascript.
 
-Our codebase is far from perfect, but the goal is to slowly improve our coverage
+Our codebase is far from perfect, but the goal is to steadily improve our coverage
 over time. To do this, we wrote a tool called `diff-cover`_ that will
 report which lines in your branch are not covered by tests, while ignoring
 other lines in the project that may not be covered. Using this tool,
diff --git a/docs/en_us/developers/source/testing/code-quality.rst b/docs/en_us/developers/source/testing/code-quality.rst
index 324b88585f..bbcb180a1b 100644
--- a/docs/en_us/developers/source/testing/code-quality.rst
+++ b/docs/en_us/developers/source/testing/code-quality.rst
@@ -2,13 +2,13 @@
 Code Quality
 ************
 
-In order to keep our codebase as clear and readable as possible, we use various
+In order to keep our code as clear and readable as possible, we use various
 tools to assess the quality of pull requests:
 
 * We use the `pep8`_ tool to follow `PEP-8`_ guidelines
 * We use `pylint`_ for static analysis and uncovering trouble spots in our code
 
-Our codebase is far from perfect, but the goal is to slowly improve our quality
+Our codebase is far from perfect, but the goal is to steadily improve our quality
 over time. To do this, we wrote a tool called `diff-quality`_ that will
 only report on the quality violations on lines that have changed in a
 pull request. Using this tool, we can ensure that pull requests do not introduce