Fixing editorial inconsistencies

Author: vkay11

CODE_OF_CONDUCT.md

@@ -3,7 +3,7 @@
 ## Our Pledge
 
 In the interest of fostering an open and welcoming environment, we as
-contributors and maintainers pledge to making participation in our project and
+contributors and maintainers pledge to make participation in our project and
 our community a harassment-free experience for everyone, regardless of age, body
 size, disability, ethnicity, gender identity and expression, level of experience,
 nationality, personal appearance, race, religion, or sexual identity and

CONTRIBUTING.md

@@ -24,7 +24,7 @@ There are many ways you can directly contribute to the guides (in descending ord
 * Fix editorial inconsistencies or inaccuracies
 * [Translate guides into other languages](docs/translations.md)
 
-Interested in making a contribution? Read on!
+Interested in contributing to this Open Source Guide? Read on!
 
 ## Ground rules & expectations
 

_articles/best-practices.md

@@ -47,7 +47,7 @@ For example, @lord discovered that having a project vision helped him figure out
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/lord?s=180" class="pquote-avatar" alt="avatar">
-  I fumbled it. I didn't put in the effort to come up with a complete solution. Instead of an half-assed solution, I wish I had said "I don't have time for this right now, but I'll add it to the long term nice-to-have list."
+  I fumbled it. I didn't put in the effort to come up with a complete solution. Instead of a half-assed solution, I wish I had said "I don't have time for this right now, but I'll add it to the long term nice-to-have list."
   <p markdown="1" class="pquote-credit">
 — @lord, ["Tips for new open source maintainers"](https://lord.io/blog/2014/oss-tips/)
   </p>
@@ -104,7 +104,7 @@ If you receive a contribution you don't want to accept, your first reaction migh
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/krausefx?s=180" class="pquote-avatar" alt="avatar">
-  The key to handle support for large-scale open source projects is to keep issues moving. Try to avoid having issues stall. If you're an iOS developer you know how frustrating it can be to submit radars. You might hear back 2 years later, and are told to try again with the latest version of iOS.
+  The key to handling support for large-scale open source projects is to keep issues moving. Try to avoid having issues stall. If you're an iOS developer you know how frustrating it can be to submit radars. You might hear back 2 years later, and are told to try again with the latest version of iOS.
   <p markdown="1" class="pquote-credit">
 — @KrauseFx, ["Scaling open source communities"](https://krausefx.com/blog/scaling-open-source-communities)
   </p>
@@ -236,7 +236,7 @@ If you add tests, make sure to explain how they work in your CONTRIBUTING file.
 
 ### Use tools to automate basic maintenance tasks
 
-The good news about maintaining a popular project is that other maintainers have probably faced similar issues and built a solution for it.
+The good news about maintaining a popular project is that other maintainers have probably faced similar issues and built a solution for them.
 
 There are a [variety of tools available](https://github.com/showcases/tools-for-open-source) to help automate some aspects of maintenance work. A few examples:
 

_articles/building-community.md

@@ -38,7 +38,7 @@ Start with your documentation:
 
 * **When someone new lands on your project, thank them for their interest!** It only takes one negative experience to make someone not want to come back.
 * **Be responsive.** If you don't respond to their issue for a month, chances are, they've already forgotten about your project.
-* **Be open-minded about the types of contributions you'll accept.** Many contributors start with a bug report or small fix. There are [many ways to contribute](../how-to-contribute/#what-it-means-to-contribute) to a project. Let people help how they want to help.
+* **Be open-minded about the types of contributions you'll accept.** Many contributors start with a bug report or a small fix. There are [many ways to contribute](../how-to-contribute/#what-it-means-to-contribute) to a project. Let people help how they want to help.
 * **If there's a contribution you disagree with,** thank them for their idea and [explain why](../best-practices/#learning-to-say-no) it doesn't fit into the scope of the project, linking to relevant documentation if you have it.
 
 <aside markdown="1" class="pquote">

_articles/getting-paid.md

@@ -17,7 +17,7 @@ related:
 
 ## Why some people seek financial support
 
-Much of open source work is volunteered. For example, someone might come across a bug in a project they use and submit a quick fix, or they might enjoy tinkering with an open source project in their spare time.
+Much of the open source work is volunteered. For example, someone might come across a bug in a project they use and submit a quick fix, or they might enjoy tinkering with an open source project in their spare time.
 
 <aside markdown="1" class="pquote">
   <img src="https://avatars.githubusercontent.com/gvanrossum?s=180" class="pquote-avatar" alt="avatar">
@@ -119,7 +119,7 @@ Finally, sometimes open source projects put bounties on issues that you might co
 
 Beyond arrangements for individual contributors, sometimes projects raise money from companies, individuals, or others to fund ongoing work.
 
-Organizational funding might go towards paying current contributors, covering the costs of running the project (such as hosting fees), or investing into new features or ideas.
+Organizational funding might go towards paying current contributors, covering the costs of running the project (such as hosting fees), or investing in new features or ideas.
 
 As open source's popularity increases, finding funding for projects is still experimental, but there are a few common options available.
 

_articles/how-to-contribute.md

@@ -410,7 +410,7 @@ Before you open an issue or pull request, or ask a question in chat, keep these
 >
 > 😢 _"X is broken! Please fix it."_
 
-**Do your homework beforehand.** It's OK not to know things, but show that you tried. Before asking for help, be sure to check a project's README, documentation, issues (open or closed), mailing list, and search the internet for an answer. People will appreciate when you demonstrate that you're trying to learn.
+**Do your homework beforehand.** It's OK not to know things, but show that you tried. Before asking for help, be sure to check a project's README, documentation, issues (open or closed), mailing list, and search the internet for an answer. People will appreciate it when you demonstrate that you're trying to learn.
 
 > 😇 _"I'm not sure how to implement X. I checked the help docs and didn't find any mentions."_
 >
@@ -494,7 +494,7 @@ If the project is on GitHub, here's how to submit a pull request:
 * **Reference any relevant issues** or supporting documentation in your PR (for example, "Closes #37.")
 * **Include screenshots of the before and after** if your changes include differences in HTML/CSS. Drag and drop the images into the body of your pull request.
 * **Test your changes!** Run your changes against any existing tests if they exist and create new ones when needed. Whether tests exist or not, make sure your changes don't break the existing project.
-* **Contribute in the style of the project** to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future.
+* **Contribute to the style of the project** to the best of your abilities. This may mean using indents, semi-colons or comments differently than you would in your own repository, but makes it easier for the maintainer to merge, others to understand and maintain in the future.
 
 If this is your first pull request, check out [Make a Pull Request](http://makeapullrequest.com/), which @kentcdodds created as a walkthrough video tutorial. You can also practice making a pull request in the [First Contributions](https://github.com/Roshanjossey/first-contributions) repository, created by @Roshanjossey.
 

docs/content-model.md

@@ -39,6 +39,6 @@ Historical vignettes are fun anecdotes that keep a reader's attention. They make
 
 We use bulleted lists to keep articles approachable and skim-able, and to group examples and checklists. However, avoid:
 
-- Articles consisting almost entirely of lists; lists should enhance narrative rather than serve as the main attraction.
+- Articles consisting almost entirely of lists; lists should enhance the narrative rather than serve as the main attraction.
 - Exhaustive or canonical lists; follows from above. If such a list is relevant, [link](styleguide.md#content-principles) to one maintained elsewhere.
 - Lists consisting of only links; a guide is not an awesome list. Check out how we link to the main awesome list in a list, [for example](https://opensource.guide/how-to-contribute/#you-dont-just-have-to-work-on-software-projects).

docs/personas.md

@@ -10,7 +10,7 @@
 
 * Sees self as ultimate decisionmaker
 
-* Still building community reputation
+* Still building a community reputation
 
 * Has never open sourced a project before
 

docs/styleguide.md

@@ -2,7 +2,7 @@
 
 From the GitHub Manual of Style, which this style guide inherits from:
 
-> Words are an important part of how software works. Just as we have a style guide for our code, we have a style guide for our tone and our voice. Even though there may be dozens of people creating a product, it should still sound like we speak in one consistent voice.
+> Words are an important part of how the software works. Just as we have a style guide for our code, we have a style guide for our tone and our voice. Even though there may be dozens of people creating a product, it should still sound like we speak in one consistent voice.
 >
 > In other words, the way we write is just as important as the way we design. Consider these things when writing copy.
 
@@ -11,7 +11,7 @@ Where possible, [automated tests](../test/prose) enforce style rules.
 ## Content principles
 All written content should follow these principles:
 
-* **Approachability:** Don't assume reader has prior knowledge
+* **Approachability:** Don't assume the reader has prior knowledge
 * **Brevity:** Keep it simple, link to outside content for deeper dives
 * **Curation:** Amplify community best practices vs. any individual's point of view
 
@@ -34,7 +34,7 @@ When referring to a project on GitHub, link to the repository so others can dive
 "Guides" is capitalized when referring to the "Open Source Guides", but not when saying "the guide" or "this guide".
 
 - :smile: Welcome to Open Source Guides!
-- :smile: The guide is meant to..
+- :smile: The guide is meant to...
 - :cry: The goal of this Guide is to...
 
 ## More guidance

docs/translations.md

@@ -1,6 +1,6 @@
 # Translations
 
-Thanks for your interest in helping translating the guides!
+Thanks for your interest in helping to translate the guides!
 
 ## Starting a translation
 
@@ -15,7 +15,7 @@ If there's not, then today is your day to lead this effort! Here's how to start:
 1. Create a new directory in `_articles/` for your language e.g. `_articles/es/`, copy each guide from `_articles/` into that folder and translate the content in each guide, except for the field names in the front matter between the `---`s at the top of each file, e.g., `title:` should remain unchanged. Remove the `toc:` fields (they are only used for English).
 1. Copy `index.html` to your target language index file e.g. `[_articles/es/index.html](https://github.com/github/opensource.guide/blob/HEAD/_articles/es/index.html)` and update the `lang:` and add the `permalink:` fields. Example: `lang: es` and `permalink: /es/`. All other fields' values must remain unchanged.
 1. Run `script/test` and make sure there are no failures with your translation files. Note that you may need to fix broken links.
-1. Send a pull request. (You may send a pull request before all steps above are complete: e.g., you may want to ask for help with translations, or getting tests to pass. However your pull request will not be merged until all steps above are complete.)
+1. Send a pull request. (You may send a pull request before all steps above are complete: e.g., you may want to ask for help with translations, or getting tests to pass. However, your pull request will not be merged until all steps above are complete.)
 
 Completing an initial translation of the whole site is a fairly large task. One way to break that task up is to work with other translators through pull requests on your fork. Example: [pull requests on fork for German translation](https://github.com/katrinleinweber/opensource.guide/pulls?q=is%3Apr+is%3Aclosed) and corresponding [initial pull request for German translation](https://github.com/github/opensource.guide/pull/577) on this repository. You can also [add collaborators to your fork](https://help.github.com/en/github/setting-up-and-managing-your-github-user-account/inviting-collaborators-to-a-personal-repository) if you'd like to invite other translators to commit directly to your fork and share responsibility for merging pull requests.