Misc language fixes/rewording for CONTRIBUTING.rst

CONTRIBUTING.rst

@@ -4,29 +4,27 @@ Contributor Guidelines
 Contributions are welcome and greatly appreciated. Every little bit
 helps in making Hy better. Potential contributions include:
 
-- Reporting bugs
+- Reporting and fixing bugs.
-- Fixing bugs
+- Requesting features.
-- Requesting features
+- Adding features.
-- Adding features
+- Writing tests for outstanding bugs or untested features.
-- Writing tests for outstanding bugs or untested features
-
   - You can mark tests that Hy can't pass yet as xfail_.
-- Cleaning up the code
+- Cleaning up the code.
-- Improving the documentation
+- Improving the documentation.
 - Answering questions on `the IRC channel`_, `the mailing list`_, or
-  `Stack Overflow`_
+  `Stack Overflow`_.
 - Evangelizing for Hy in your organization, user group, conference, or
-  bus stop
+  bus stop.
 
 Issues
 ~~~~~~
 
-To report bugs or request features, search the `issue tracker`_ to
+In order to report bugs or request features, search the `issue tracker`_ to
 check for a duplicate. (If you're reporting a bug, make sure you can
 reproduce it with the very latest, bleeding-edge version of Hy from
 the ``master`` branch on GitHub. Bugs in stable versions of Hy are
 fixed on ``master`` before the fix makes it into a new stable
-release.) Then make a new issue.
+release.) If there aren't any, then you can make a new issue.
 
 It's totally acceptable to create an issue when you're unsure whether
 something is a bug or not. We'll help you figure it out.
@@ -38,10 +36,10 @@ Pull requests
 
 Submit proposed changes to the code or documentation as pull requests
 (PRs) on GitHub_. Git can be intimidating and confusing to the
-uninitiated. `This getting-started guide`_ may be helpful. But if
+uninitiated. `This getting-started guide`_ may be helpful. However, if
-you're overwhelmed by Git or GitHub or the rules below, don't sweat
+you're overwhelmed by Git, GitHub, or the rules below, don't sweat
-it; we want to keep the barrier to contribution low, so we're happy to
+it. We want to keep the barrier to contribution low, so we're happy to
-help you with these finicky things, or do them for you if necessary.
+help you with these finicky things or do them for you if necessary.
 
 Deciding what to do
 -------------------
@@ -52,7 +50,7 @@ fix, so they may be good targets for your first PR for Hy.
 If you're proposing a major change to the Hy language, or you're
 unsure of the proposed change, create an issue to discuss it before
 you write any code. This will allow others to give feedback on your
-idea, and possibly avoid wasted work.
+idea, and it can possibly avoid wasted work.
 
 File headers
 ------------
@@ -79,9 +77,9 @@ revert other commits in the same PR (``git rebase`` is your friend).
 
 Avoid committing spurious whitespace changes.
 
-Format commit messages as follows. The first line should describe the
+The first line of a commit message should describe the overall change in 50
-overall change in 50 characters or less. If you wish to add more
+characters or less. If you wish to add more information, separate it from the
-information, separate it from the first line with a blank line.
+first line with a blank line.
 
 Testing
 -------
@@ -92,10 +90,10 @@ testing a bug that has a GitHub issue, include a comment with the URL
 of the issue.
 
 No PR may be merged if it causes any tests to fail. You can run the
-test suite and check the style of your code with ``make d``. You can
+test suite and check the style of your code with ``make d``. The byte-compiled
-purge the byte-compiled versions of the test files with ``git
+versions of the test files can be purged using ``git clean -dfx tests/``.
-clean -dfx tests/`` You can run the tests while skipping the slow
+If you want to run the tests while skipping the slow ones in ``test_bin.py``,
-tests in ``test_bin.py`` with ``pytest --ignore=tests/test_bin.py``.
+use ``pytest --ignore=tests/test_bin.py``.
 
 NEWS and AUTHORS
 ----------------
@@ -119,18 +117,18 @@ If the PR fulfills one or more issues, then the body text of the PR
 (case-insensitive) wording, because when a PR containing such text is
 merged, GitHub automatically closes the mentioned issues, which is
 handy. Conversely, avoid this exact language if you want to mention
-an issue without closing it (because e.g. you've partly but not
+an issue without closing it (e.g. because you've partly but not
 entirely fixed a bug).
 
-Before any PR is merged, it must be approved by one or more members of
+Before any PR is merged, it must be approved by members of Hy's core team,
-Hy's core team, none of whom may be the author of the PR. Changes to
+excluding the PR's author. Changes to the documentation, or trivial changes
-the documentation, or trivial changes to code, need to be approved by
+to code, need to be approved by **one** member; all other PRs need to be
-**one** member. All other PRs need to be approved by **two** members.
+approved by **two** members.
 
-Anybody may perform the merge. Merging should create a merge commit
+Anybody on the team may perform the merge. Merging should create a merge commit
-(don't squash, because that would remove separation between logically
+(don't squash unless necessary, because that would remove separation between
-separate commits, and don't fast-forward, because that would throw
+ogically separate commits, and don't fast-forward, because that would throw
-away the history of the commits as a separate branch), which should
+away the history of the commits as a separate branch)which should
 include the PR number in the commit message.
 
 Contributor Code of Conduct