github · nayafia · Aug 17, 2016 · Aug 16, 2016 · Aug 17, 2016 · Aug 17, 2016
diff --git a/docs/personas.md b/docs/personas.md
@@ -18,7 +18,7 @@
 
 * Wants people to notice their project
 
-* Wants people to actually use the project, give him/her feedback
+* Wants people to actually use the project and give feedback
 
 ### Frustrations/Pain Points
 
@@ -42,7 +42,7 @@
 
 ### Primary Goals
 
-* Manage personal time so project demands don’t overwhelm him/her
+* Manage personal time so project demands don’t become overwhelming
 
 * Find other contributors or maintainers to help with the project
 

diff --git a/getting-started/legal.md b/getting-started/legal.md
@@ -20,7 +20,7 @@ Thankfully, you don’t have to start from scratch. This section will make sure
 
 When you publish a creative work (which includes code), your work is under copyright by default. Unless you include a license that specifies otherwise, nobody can copy or modify your work without being subject to copyright law.
 
-An open source license guarantees that others can use, modify and share your project. It protects both you and anybody else who might interact with your project.
+An open source license guarantees that others can use, modify, and share your project. It protects both you and anybody else who might interact with your project.
 
 Making your GitHub project public is not the same as licensing your project. Public GitHub projects allow others to view and fork your project, but your work is otherwise copyrighted unless you add an open source license.
 

diff --git a/getting-started/preparing.md b/getting-started/preparing.md
@@ -16,7 +16,7 @@ As a maintainer, these components will help you communicate expectations, manage
 
 ## Choosing a license
 
-An open source license guarantees that others can use, copy, modify and contribute back to your project without repercussions. It also protects you from any sticky legal situations.
+An open source license guarantees that others can use, copy, modify, and contribute back to your project without repercussions. It also protects you from any sticky legal situations.
 
 Legal work is no fun. The good news is there are many licenses available that you can copy and paste into your repository. It will only take a minute to protect your hard work.
 

diff --git a/getting-started/setting-expectations.md b/getting-started/setting-expectations.md
@@ -15,7 +15,7 @@ There is no one right answer to this question. You may find that you have multip
 
 Here are some examples of reasons why people open source their work:
 
-* An individual wants to show off his or her portfolio
+* An individual wants to show off their portfolio
 * An individual or company wants others to use what they’ve created
 * A community wants to find collaborators to shape the project and help it grow
 * An individual wants to get feedback on their work

diff --git a/index.md b/index.md
@@ -7,4 +7,4 @@ Welcome to the Open Source Handbook! We created this handbook to help creators l
 
 We wrote this handbook based on what we’ve learned from watching millions of open source projects on GitHub’s platform. Whether you’re an individual, a company, or a community, you’ll find plenty of real stories and experiences in this handbook to guide you.
 
-Special thanks to **(list names of people here)** for their valuable input in the initial release of this handbook. If you’d like to contribute, head on over to  to get started!
+Special thanks to **(list names of people here)** for their valuable input in the initial release of this handbook. If you’d like to contribute, head on over to to get started!
diff --git a/marketing/building-community.md b/marketing/building-community.md
@@ -35,7 +35,7 @@ Try to be responsive when someone files an issue, submits a pull request, or ask
 
 [^1]: [Measuring Engagement](https://docs.google.com/presentation/d/1hsJLv1ieSqtXBzd5YZusY-mB8e1VJzaeOmh8Q4VeMio/edit#slide=id.g43d857af8_0177) presentation by David Eaves, Adam Lofting, Pierros Papadeas, Peter Loewen
 
-Remember that conversations about your project could also be happening in other places around the Internet, such as Stack Overflow, Twitter, or Reddit. You can set up notifications in some of these places so you are alerted when someone mentions your project.
+Remember that conversations about your project could also be happening in other places around the internet, such as Stack Overflow, Twitter, or Reddit. You can set up notifications in some of these places so you are alerted when someone mentions your project.
 
 ## Make it easy for people to use and contribute
 

diff --git a/marketing/measuring.md b/marketing/measuring.md
@@ -3,7 +3,7 @@ title: Measuring Success
 next: sustaining/index.md
 ---
 
-Your project is starting to grow. 🌱  Well, you think it’s growing. Is it growing? In this section, we’ll talk about how to measure and track the success of your open source project.
+Your project is starting to grow. 🌱 Well, you think it’s growing. Is it growing? In this section, we’ll talk about how to measure and track the success of your open source project.
 
 ## Discoverability
 
@@ -25,7 +25,7 @@ You may also want to track discoverability in specific places: for example, Goog
 
 ## Usage
 
-People are finding your project on this wild and crazy thing we call the Internet. Ideally, when they see your project, they’ll feel compelled to do something. The second question you’ll want to ask is: _are people using my project?_
+People are finding your project on this wild and crazy thing we call the internet. Ideally, when they see your project, they’ll feel compelled to do something. The second question you’ll want to ask is: _are people using my project?_
 
 If you use a package manager, such as npm or RubyGems.org, to distribute your project, you may be able to track your project’s downloads. Each package manager may use a slightly different definition of "download", and downloads do not not necessarily correlate to installs or use, but it provides some baseline for comparison.
 

diff --git a/sustaining/best-practices.md b/sustaining/best-practices.md
@@ -51,7 +51,7 @@ The first rule of open source, according to @shykes: _"No is temporary, yes is f
 
 Saying no applies to many situations you’ll come across as a maintainer. You can say no to feature requests that don’t fit the scope of your project. You can say no, or refuse to engage, when someone derails a conversation on a mailing list. You can say no to doing work for others that you don’t find important.
 
-One of the most important places you’ll practice saying no is on your your issue and pull request queue.  If someone suggests an idea that you know you won’t accept, don’t leave it open because you feel guilty or want to be nice. Be kind, but firm. Thank them for their contribution and explain why it doesn’t fit into the scope of the project. Then close the request.
+One of the most important places you’ll practice saying no is on your issue and pull request queue. If someone suggests an idea that you know you won’t accept, don’t leave it open because you feel guilty or want to be nice. Be kind, but firm. Thank them for their contribution and explain why it doesn’t fit into the scope of the project. Then close the request.
 
 If you notice repeated requests for things you don’t want to accept, consider adding them into your contribution policy, so you don’t have to keep repeating yourself.
 
@@ -77,7 +77,7 @@ The good news about maintaining a popular open source project is that other main
 
 * [Vossibility](https://github.com/icecrime/vossibility-stack) pulls stats on your project
 
-* [mention-bot](https://github.com/facebook/mention-bot)automatically mentions potential reviewers for pull requests
+* [mention-bot](https://github.com/facebook/mention-bot) automatically mentions potential reviewers for pull requests
 
 * [PullApprove](https://about.pullapprove.com/) helps you manage pull requests
 

diff --git a/sustaining/leadership.md b/sustaining/leadership.md
@@ -3,7 +3,7 @@ title: Leadership & Governance
 next: troubleshooting/index.md
 ---
 
-Your project is growing, people are engaged, and you’re committed to keeping this thing going. At this stage, you’re probably starting to wonder about governance. Maybe you want to recognize a community members who’s made significant contributions to your project. Maybe you’ve gotten into a debate with your community and realized you didn’t know how to resolve it.
+Your project is growing, people are engaged, and you’re committed to keeping this thing going. At this stage, you’re probably starting to wonder about governance. Maybe you want to recognize a community member who’s made significant contributions to your project. Maybe you’ve gotten into a debate with your community and realized you didn’t know how to resolve it.
 
 In this section, we’ll answer some commonly asked questions about leadership and governance for open source projects.
 

diff --git a/troubleshooting/burnout.md b/troubleshooting/burnout.md
@@ -16,7 +16,7 @@ Write your time constraints directly into your README. If your time is purely vo
 
 ## Write an agreement for maintainers and contributors
 
-If you haven’t noticed by now, the more you write down, the easier your life will be. 😎  One thing you may want to consider writing down are ground rules and expectations for maintainers (and contributors!). Think of it as an extension of your code of conduct.
+If you haven’t noticed by now, the more you write down, the easier your life will be. 😎 One thing you may want to consider writing down are ground rules and expectations for maintainers (and contributors!). Think of it as an extension of your code of conduct.
 
 For example, as a maintainer, you might promise to acknowledge every contribution, even if you don’t accept them. You might ask contributors to promise that their code passes all tests before they submit it.
 

diff --git a/troubleshooting/contributions.md b/troubleshooting/contributions.md
@@ -2,7 +2,7 @@
 title: Handling contributions you don't want to accept
 ---
 
-As a maintainer of an open source project, you’ll inevitably receive contributions that you don’t want to accept. Maybe the contribution changes your project’s scope or doesn’t match your vision. Maybe the idea is good, but the execution is poor.
+As a maintainer of an open source project, you’ll inevitably receive contributions that you don’t want to accept. Maybe the contribution changes your project’s scope or doesn’t match your vision. Maybe the idea is good, but the implementation is poor.
 
 Regardless of the reason, here are some strategies to tactfully handle contributions that don’t meet your project’s standards.
 
@@ -14,7 +14,7 @@ Contributing to an open source project can be intimidating, especially if it’s
 
 ## Write down what you won’t accept beforehand
 
-Having a clear contribution policy helps depersonalize situations where you don’t want to accept a contribution. Saying "Your contribution doesn’t match this project’s criteria" feels less personal than “I don’t like your contribution”. In addition, clear contribution policies can reduce the chances that someone will submit something you don’t want in the first place. 
+Having a clear contribution policy helps depersonalize situations where you don’t want to accept a contribution. Saying "Your contribution doesn’t match this project’s criteria" feels less personal than “I don’t like your contribution”. In addition, clear contribution policies can reduce the chances that someone will submit something you don’t want in the first place.
 
 ## Ask that people discuss major changes first
 

diff --git a/troubleshooting/finding-consensus.md b/troubleshooting/finding-consensus.md
@@ -4,7 +4,7 @@ title: Finding community consensus
 
 Early in the life of your open source project, making major decisions is easy. When you want to do something, you just do it.
 
-As your project becomes more popular, more people will take interest in the decisions you make. Even if you don’t have a big community of contributors,, you’ll find that people will start to weigh in on your decisions or raise issues of their own if your project has a lot of users.
+As your project becomes more popular, more people will take interest in the decisions you make. Even if you don’t have a big community of contributors, you’ll find that people will start to weigh in on your decisions or raise issues of their own if your project has a lot of users.
 
 For the most part, if you’ve cultivated a friendly, respectful community and documented your processes openly, you and your community should be able to reach a resolution. But sometimes you run into an issue that’s a little bit harder to address. Here are some strategies to reach consensus.
Original file line number	Diff line number	Diff line change
Expand Up		@@ -7,4 +7,4 @@ Welcome to the Open Source Handbook! We created this handbook to help creators l

		We wrote this handbook based on what we’ve learned from watching millions of open source projects on GitHub’s platform. Whether you’re an individual, a company, or a community, you’ll find plenty of real stories and experiences in this handbook to guide you.

		Special thanks to (list names of people here) for their valuable input in the initial release of this handbook. If you’d like to contribute, head on over to to get started!
		Special thanks to (list names of people here) for their valuable input in the initial release of this handbook. If you’d like to contribute, head on over to to get started!