Merge pull request #1 from mheggeseth/pedantry

Spelling/grammar fixes, et al

Author: BillWagner

README.md

@@ -4,15 +4,15 @@ In most cases, consider the guidance here as our current "default answer" to man
 important questios.
 
 If you are working on a project, and you have a different recommendation, we will 
-consider that request for a single single project. IF it works well in that project,
-we wwill consdier making it the default answer on new projects. We'll also consider
+consider that request for a single project. IF it works well in that project,
+we will consdier making it the default answer on new projects. We'll also consider
 adding that new policy to existing projects, in those cases where the benefits
 justify the work.
 
 The site is built using Jekyll, so that we can easily support markdown 
 formatted pages. Here are some important resources to get started:
 
-This Gihub guide to creating pages with the automated generator shows the basics:
+This Github guide to creating pages with the automated generator shows the basics:
 https://help.github.com/articles/creating-pages-with-the-automatic-generator/
 
 This article explains how Github uses Jekyll to generate the site: 
@@ -22,7 +22,6 @@ For those using Windows, this guide explains how to install and use Jekyll
 on Windows:
 http://jekyll-windows.juthilo.com/
 
-If yuou have a procedure or a tool you'd like us to adopt, please send us a PR.
+If you have a procedure or a tool you'd like us to adopt, please send us a PR.
 This repository, like all of the HTbox projects, is open source, and 
-we welconme your thoughts.
-
+we welcome your thoughts.

doing-the-work.md

@@ -6,7 +6,7 @@ layout: default
 
 ## TL;DR
 
-> Work as you normally would, commit and push your changes at the cadence that works for you. Please make one Pull Request for one Issue, rather than fixing several issues in on PR. It's much easier for us to review and merge when a PR is focused on one issue.
+> Work as you normally would, commit and push your changes at the cadence that works for you. Please make one Pull Request for one Issue, rather than fixing several issues in one PR. It's much easier for us to review and merge when a PR is focused on one issue.
 
 ## Long Version
 

index.html

@@ -20,7 +20,7 @@ <h2>Introduction</h2>
 
 The remainder of this document explains how our projects are organized, how to assign 
 yourself work, and how to sumbit that work for review. We'll also explain how to submit ideas
-for work that you want to do to enhnce our projects.
+for work that you want to do to enhance our projects.
 </p>
 
 <h2><a href="/finding-a-task.html">Finding a Task</a></h2>
@@ -30,7 +30,7 @@ <h2><a href="/doing-the-work.html">Doing the Work</a></h2>
 <h2><a href="/submitting-a-pull-request.html">Submitting a Pull Request</a></h2>
 <h2><a href="/responding-to-reviews.html">Responding to Reviews</a></h2>
 <h1>FAQ</h1>
-As we create FAQ items will will post them here:
+As we create FAQ items, we will post them here:
 
   <ul class="post-list">
     {% for post in site.posts %}

responding-to-reviews.md

@@ -7,7 +7,7 @@ layout: default
 
 ## TL;DR
 
-If you update your code, and push to your fork, github automatically updates the PR. We'll see the changes. If you disagree with the review, please comment on the code, and tell us why your approach is better. We may or may not approve it, but we will listen.
+> If you update your code, and push to your fork, github automatically updates the PR. We'll see the changes. If you disagree with the review, please comment on the code, and tell us why your approach is better. We may or may not approve it, but we will listen.
 
 ## Long Version
 

submitting-a-pull-request.md

@@ -10,7 +10,7 @@ layout: default
 
 ## Long Version
 
-You don't have to wait until all your work is done in order to send us a pull request. If you want the core team to look at your code, but not accept the changes yet, open a pull request, and prefix the title with 'WIP'. That tells us to review the code, but that it is not done, and is not yet ready to merge. When you are finished, and the PR is ready to merge, simply remove 'WIP' from the PR tktle, and we'll give it a final look, and merge it.
+You don't have to wait until all your work is done in order to send us a pull request. If you want the core team to look at your code, but not accept the changes yet, open a pull request, and prefix the title with 'WIP'. That tells us to review the code, but that it is not done, and is not yet ready to merge. When you are finished, and the PR is ready to merge, simply remove 'WIP' from the PR title, and we'll give it a final look, and merge it.
 
 When you submit a pull request, an automated build (using AppVeyor) will merge your changes onto a copy of the master repository, build that configuration, and run all automated tests. If any of those steps fail, we will ask you to fix them before we accept the pull request. (We don't comment on this if you've labelled the PR 'WIP'.)