Merge pull request #3603 from him2him2/fix-typos-in-english-docs

Fix typos and grammar errors across English documentation

Author: ahpook

CODE_OF_CONDUCT.md

@@ -47,7 +47,7 @@ threatening, offensive, or harmful.
 
 This Code of Conduct applies both within project spaces and in public spaces
 when an individual is representing the project or its community. Examples of
-representing a project or community includes using an official project e-mail
+representing a project or community include using an official project e-mail
 address, posting via an official social media account, or acting as an appointed
 representative at an online or offline event. Representation of a project may be
 further defined and clarified by project maintainers.

README.md

@@ -18,7 +18,7 @@ Content is released under [CC-BY-4.0](https://creativecommons.org/licenses/by/4.
 
 ## Acknowledgments
 
-The initial release of these guides were authored by **[@nayafia][1], [@bkeepers][2], [@stephbwills][3],** and **[@mlinksva][4]**.
+The initial release of these guides was authored by **[@nayafia][1], [@bkeepers][2], [@stephbwills][3],** and **[@mlinksva][4]**.
 
 Thanks to **[@aitchabee][5], [@benbalter][6], [@brettcannon][7], [@caabernathy][8], [@coralineada][9], [@dmleong][10], [@ericholscher][11], [@gr2m][12], [@janl][13], [@jessfraz][14], [@bluesomewhere][15], [@kfogel][16], [@kytrinyx][17], [@lee-dohm][18], [@mikeal][19], [@mikemcquaid][20], [@nathansobo][21], [@nruff][22], [@nsqe][23], [@orta][24], [@parkr][25], [@shazow][26], [@steveklabnik][27],** and **[@wooorm][28]** for lending their valuable input and expertise leading up to the initial release, and to **[@sophshep][29]** and **[@jeejkang][30]** for designing and illustrating the guides.
 

_articles/best-practices.md

@@ -139,7 +139,7 @@ If you're receiving too many low-quality contributions, require that contributor
 
 If they don't follow your rules, close the issue immediately and point to your documentation.
 
-While this approach may feel unkind at first, being proactive is actually good for both parties. It reduces the chance that someone will put in many wasted hours of work into a pull request that you aren't going to accept. And it makes your workload easier to manage.
+While this approach may feel unkind at first, being proactive is actually good for both parties. It reduces the chance that someone will put many wasted hours of work into a pull request that you aren't going to accept. And it makes your workload easier to manage.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">

_articles/building-community.md

@@ -121,7 +121,7 @@ Do your best to adopt a zero-tolerance policy towards these types of people. If
   </p>
 </aside>
 
-Regular debates over trivial aspects of your project distracts others, including you, from focusing on important tasks. New people who arrive to your project may see these conversations and not want to participate.
+Regular debates over trivial aspects of your project distract others, including you, from focusing on important tasks. New people who arrive to your project may see these conversations and not want to participate.
 
 When you see negative behavior happening on your project, call it out publicly. Explain, in a kind but firm tone, why their behavior is not acceptable. If the problem persists, you may need to [ask them to leave](../code-of-conduct/#enforcing-your-code-of-conduct). Your [code of conduct](../code-of-conduct/) can be a constructive guide for these conversations.
 

_articles/getting-paid.md

@@ -64,7 +64,7 @@ If you're looking for financial support, there are two paths to consider. You ca
 
 Today, many people get paid to work part- or full-time on open source. The most common way to get paid for your time is to talk to your employer.
 
-It's easier to make a case for open source work if your employer actually uses the project, but get creative with your pitch. Maybe your employer doesn't use the project, but they use Python, and maintaining a popular Python project help attract new Python developers. Maybe it makes your employer look more developer-friendly in general.
+It's easier to make a case for open source work if your employer actually uses the project, but get creative with your pitch. Maybe your employer doesn't use the project, but they use Python, and maintaining a popular Python project helps attract new Python developers. Maybe it makes your employer look more developer-friendly in general.
 
 If you don't have an existing open source project you'd like to work on, but would rather that your current work output is open sourced, make a case for your employer to open source some of their internal software.
 
@@ -136,7 +136,7 @@ Some software foundations and companies offer grants for open source work. Somet
 * **[Libraries.io](https://github.com/librariesio)** received a grant from the [Sloan Foundation](https://sloan.org/programs/digital-technology)
 * The **[Python Software Foundation](https://www.python.org/psf/grants/)** offers grants for Python-related work
 * **[FLOSS/fund](https://floss.fund/)** is a dedicated fund to provide no-strings attached financial support to FOSS projects globally.
-* The **[Github Secure Open Source Fund](https://resources.github.com/github-secure-open-source-fund/)** is a program designed to financially and programmatically improve security and sustainability of open source projects.
+* The **[GitHub Secure Open Source Fund](https://resources.github.com/github-secure-open-source-fund/)** is a program designed to financially and programmatically improve security and sustainability of open source projects.
 
 For more detailed options and case studies, @nayafia [wrote a guide](https://github.com/nayafia/lemonade-stand) to getting paid for open source work. Different types of funding require different skills, so consider your strengths to figure out which option works best for you.
 
@@ -176,4 +176,4 @@ Does the funder have any requirements around disbursal? For example, you may nee
 
 ## Experiment and don't give up
 
-Raising money isn't easy, whether you're an open source project, a nonprofit, or a software startup, and in most cases require you to get creative. Identifying how you want to get paid, doing your research, and putting yourself in your funder's shoes will help you build a convincing case for funding.
+Raising money isn't easy, whether you're an open source project, a nonprofit, or a software startup, and in most cases requires you to get creative. Identifying how you want to get paid, doing your research, and putting yourself in your funder's shoes will help you build a convincing case for funding.

_articles/how-to-contribute.md

@@ -189,7 +189,7 @@ Finally, open source projects use the following tools to organize discussion. Re
 
 Now that you've figured out how open source projects work, it's time to find a project to contribute to!
 
-If you've never contributed to open source before, take some advice from U.S. President John F. Kennedy, who once said:, _"Ask not what your country can do for you - ask what you can do for your country."_
+If you've never contributed to open source before, take some advice from U.S. President John F. Kennedy, who once said, _"Ask not what your country can do for you - ask what you can do for your country."_
 
 <aside markdown="1" class="pquote">
   <img src="/assets/images/how-to-contribute/johnfkennedy.jpg" class="pquote-avatar" alt="avatar">

_articles/leadership-and-governance.md

@@ -125,7 +125,7 @@ If you're part of a company launching an open source project, it's worth having
 
 ## What happens if corporate employees start submitting contributions?
 
-Successful open source projects get used by many people and companies, and some companies may eventually have revenue streams eventually tied to the project. For example, a company may use the project's code as one component in a commercial service offering.
+Successful open source projects get used by many people and companies, and some companies may eventually have revenue streams tied to the project. For example, a company may use the project's code as one component in a commercial service offering.
 
 As the project gets more widely used, people who have expertise in it become more in-demand - you may be one of them! - and will sometimes get paid for work they do in the project.
 

_articles/legal.md

@@ -66,7 +66,7 @@ Dependencies with **copyleft licenses** require closer attention. Including any
 
 Dependencies with **source-available licenses**, such as the Business Source License [BSL](https://spdx.org/licenses/BUSL-1.1.html) or the Server Side Public License [SSPL](https://en.wikipedia.org/wiki/Server_Side_Public_License), may appear to be under open source licenses but come with usage and business model restrictions. These restrictions may prevent your project from being considered Open Source as defined by the [Open Source Initiative (OSI)](https://opensource.org/).
 
-Projects often rely on **non-source code content**, such as images, icons, videos, fonts, data files, or other materials, which are governed by their own licenses. As with traditional software dependencies, the licenses these materials range from Commercial to permissive to Copyleft. The [Creative Commons](https://creativecommons.org/share-your-work/cclicenses/), a non-profit organization, created a series of licenses popular for non-source content. Creative Commons licenses range from very permissive [CC0](https://creativecommons.org/publicdomain/zero/1.0/deed.en) to Permissive [CC-BY](https://creativecommons.org/licenses/by/4.0/deed.en) to copyleft [CC-SA](https://creativecommons.org/licenses/by-sa/2.0/deed.en). They also can sometime restrict commercial use by adding a non-commercial (NC) option to these licenses.
+Projects often rely on **non-source code content**, such as images, icons, videos, fonts, data files, or other materials, which are governed by their own licenses. As with traditional software dependencies, the licenses these materials range from Commercial to permissive to Copyleft. The [Creative Commons](https://creativecommons.org/share-your-work/cclicenses/), a non-profit organization, created a series of licenses popular for non-source content. Creative Commons licenses range from very permissive [CC0](https://creativecommons.org/publicdomain/zero/1.0/deed.en) to Permissive [CC-BY](https://creativecommons.org/licenses/by/4.0/deed.en) to copyleft [CC-SA](https://creativecommons.org/licenses/by-sa/2.0/deed.en). They also can sometimes restrict commercial use by adding a non-commercial (NC) option to these licenses.
 You may also want to consider the **communities** you hope will use and contribute to your project:
 
 * **Do you want your project to be used as a dependency by other projects?** Probably best to use the most popular license in your relevant community. For example, [MIT](https://choosealicense.com/licenses/mit/) is the most popular license for [npm libraries](https://libraries.io/search?platforms=NPM).
@@ -112,7 +112,7 @@ Some situations where you may want to consider an additional contributor agreeme
 * Your lawyers want all contributors to expressly accept (_sign_, online or offline) contribution terms, perhaps because they feel the open source license itself is not enough (even though it is!). If this is the only concern, a contributor agreement that affirms the project's open source license should be enough. The [jQuery Individual Contributor License Agreement](https://web.archive.org/web/20161013062112/http://contribute.jquery.org/CLA/) is a good example of a lightweight additional contributor agreement.
 * You or your lawyers want developers to represent that each commit they make is authorized. A [Developer Certificate of Origin](https://developercertificate.org/) requirement is how many projects achieve this. For example, the Node.js community [uses](https://github.com/nodejs/node/blob/HEAD/CONTRIBUTING.md) the DCO [instead](https://nodejs.org/en/blog/uncategorized/notes-from-the-road/#easier-contribution) of their prior CLA. A simple option to automate enforcement of the DCO on your repository is the [DCO Probot](https://github.com/probot/dco).
 * Your project uses an open source license that does not include an express patent grant (such as MIT), and you need a patent grant from all contributors, some of whom may work for companies with large patent portfolios that could be used to target you or the project's other contributors and users. The [Apache Individual Contributor License Agreement](https://www.apache.org/licenses/icla.pdf) is a commonly used additional contributor agreement that has a patent grant mirroring the one found in the Apache License 2.0.
-* Your project is under a copyleft license, but you also need to distribute a proprietary version of the project. You'll need every contributor to assign copyright to you or grant you (but not the public) a permissive license. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) is an example this type of agreement.
+* Your project is under a copyleft license, but you also need to distribute a proprietary version of the project. You'll need every contributor to assign copyright to you or grant you (but not the public) a permissive license. The [MongoDB Contributor Agreement](https://www.mongodb.com/legal/contributor-agreement) is an example of this type of agreement.
 * You think your project might need to change licenses over its lifetime and want contributors to agree in advance to such changes.
 
 If you do need to use an additional contributor agreement with your project, consider using an integration such as [CLA assistant](https://github.com/cla-assistant/cla-assistant) to minimize contributor distraction.
@@ -135,8 +135,8 @@ For better or worse, consider letting them know even if it's a personal project.
 
 * **Privacy:** Does your project collect data on users? "Phone home" to company servers? Your legal team can help you comply with company policies and external regulations.
 
-* **AI** As AI models and functionality become integral to software, it is crucial to understand licensing agreements and relevant legislation controlling their use. Even when a model or service claims to be under a standard open source license, additional terms may impose restrictions, such as preventing abuse or fraud. New legislation is also putting restrictions on the types of systems or actions that can be performed by AI-based software.
-* **Software Bill of Materials** A Software Bill of Materials (SBOM) is a comprehensive list of third-party dependencies, versions, associated licenses, and other metadata. SBOMs are legally mandated in certain countries, industries, or due to contractual obligations. A request for a SBOM often starts the license compliance journey for an organization.
+* **AI:** As AI models and functionality become integral to software, it is crucial to understand licensing agreements and relevant legislation controlling their use. Even when a model or service claims to be under a standard open source license, additional terms may impose restrictions, such as preventing abuse or fraud. New legislation is also putting restrictions on the types of systems or actions that can be performed by AI-based software.
+* **Software Bill of Materials:** A Software Bill of Materials (SBOM) is a comprehensive list of third-party dependencies, versions, associated licenses, and other metadata. SBOMs are legally mandated in certain countries, industries, or due to contractual obligations. A request for a SBOM often starts the license compliance journey for an organization.
 
 If you're releasing your company's first open source project, the above is more than enough to get through (but don't worry, most projects shouldn't raise any major concerns).
 

_articles/maintaining-balance-for-open-source-maintainers.md

@@ -28,7 +28,7 @@ By embracing the concept of personal ecology, maintainers can proactively avoid
 
 ### Identify your motivations for working in open source
 
-Take time to reflect on what parts of open source maintenance energizes you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
+Take time to reflect on what parts of open source maintenance energize you. Understanding your motivations can help you prioritize the work in a way that keeps you engaged and ready for new challenges. Whether it's the positive feedback from users, the joy of collaborating and socializing with the community, or the satisfaction of diving into the code, recognizing your motivations can help guide your focus.
 
 ### Reflect on what causes you to get out of balance and stressed out
 
@@ -128,13 +128,13 @@ This will look different for each maintainer, and will change depending on your
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/danielroe?s=180" class="pquote-avatar" alt="avatar">
- I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in evening.
+ I'm finding more opportunity to sprinkle ‘moments of creativity' in the middle of the day rather than trying to switch off in the evening.
   <p markdown="1" class="pquote-credit">
 — <a href="https://github.com/danielroe">@danielroe</a>, maintainer of Nuxt
   </p>
 </aside>
 
-* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm.”This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
+* **Set boundaries:** You can't say yes to every request. This can be as simple as saying, "I can't get to that right now and I do not have plans to in the future," or listing out what you're interested in doing and not doing in the README. For instance, you could say: "I only merge PRs which have clearly listed reasons why they were made," or, "I only review issues on alternate Thursdays from 6 -7 pm." This sets expectations for others, and gives you something to point to at other times to help de-escalate demands from contributors or users on your time.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/mikemcquaid?s=180" class="pquote-avatar" alt="avatar">

_articles/security-best-practices-for-your-project.md

@@ -12,7 +12,7 @@ Bugs and new features aside, a project's longevity hinges not only on its useful
 
 ## Ensure all privileged contributors have enabled Multi-Factor Authentication (MFA)
 
-### A malicious actor who manages to impersonate a privileged contributor to your project, will cause catastrophic damages.
+### A malicious actor who manages to impersonate a privileged contributor to your project will cause catastrophic damages.
 
 Once they obtain the privileged access, this actor can modify your code to make it perform unwanted actions (e.g. mine cryptocurrency), or can distribute malware to your users' infrastructure, or can access private code repositories to exfiltrate intellectual property and sensitive data, including credentials to other services. 
 
@@ -147,7 +147,7 @@ Security is an ongoing process, not a one-time setup. By involving your communit
 
 These few steps might seem easy or basic to you, but they go a long way to make your project more secure for its users, because they will provide protection against the most common issues.
 
-Security isn't static. Revisit your processes from time to time as your project grows, so do your responsibilities and your attack surface.
+Security isn't static. Revisit your processes from time to time. As your project grows, so do your responsibilities and your attack surface.
 
 ## Contributors