diff --git a/docs/personas.md b/docs/personas.md index 0792f2bb409..9801aab4f18 100644 --- 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 index 4d5c51d9438..e5e027af67d 100644 --- 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 index a10b8b9bc30..a3544b22105 100644 --- 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 index 1893afe7ef5..86e271f7f41 100644 --- 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 index c76aba03428..4af3d68cf60 100644 --- 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 index 4ac2e967317..148f2b49c88 100644 --- 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 index b12f86977bf..c4dc5394dd8 100644 --- 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 index 55749f8fec4..4f2d1c9fc7b 100644 --- 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 index 1e4159f200d..d5fb937355e 100644 --- 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 index bab8616952d..580b068121c 100644 --- 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 index 77979d9e142..83376c8d00e 100644 --- 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 index 49431308235..a7ab7b74b97 100644 --- 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.