standardize responses

brianamarie · brianamarie · commit 70b13ead4a22 · 2019-04-16T15:20:39.000+02:00
diff --git a/responses/congratulations.md b/responses/congratulations.md
@@ -1,17 +1,17 @@
 # :tada: Congratulations
 
-You are finished with this course. You can see a deployed version of our work together at [your new GitHub Pages site]({{ deploymentURL }}). Feel free to share this link directly with others, or you can save the resources in one of the following ways.
+You finished this course. You can see a deployed version of our work together at [your new GitHub Pages site]({{ deploymentURL }}). Feel free to share this link directly with others, or you can save the resources in one of the following ways.
 
 ### Saving course resources
 
 1. If you'd like to just save the contents to your machine, you can:
-    - Use this shortcut link to [download the files]({{ downloadURL }})
-    - Manually download the files by clicking on the **Code** tab, clicking on **Clone or download** and clicking **Download ZIP**.
-    - [Clone the repository](https://help.github.com/en/articles/cloning-a-repository) to your machine.
+ - Use this shortcut link to [download the files]({{ downloadURL }})
+ - Download the files by clicking on the **Code** tab, clicking on **Clone or download** and clicking **Download ZIP**
+ - [Clone the repository](https://help.github.com/en/articles/cloning-a-repository) to your machine
 1. If you'd like to transfer the repository to an organization on GitHub:
-    - If your organization is on GitHub.com, [fork it]({{ forkURL }}).
-    - If your organization is on GitHub Enterprise Server, [transfer the repository](https://help.github.com/enterprise/2.2/admin/articles/moving-a-repository-from-github-com-to-github-enterprise)
+ - If your organization is on GitHub.com, [fork it]({{ forkURL }})
+ - If your organization is on GitHub Enterprise Server, [transfer the repository](https://help.github.com/enterprise/2.2/admin/articles/moving-a-repository-from-github-com-to-github-enterprise)
 
-I won't monitor any further events in this repository.
+I won't track any further events in this repository.
 
 Your next steps are in the [Innersource learning path]({{ learningPathURL }}).
diff --git a/responses/discoverability-answer.md b/responses/discoverability-answer.md
@@ -5,13 +5,13 @@ This repository is the source code for https://services.github.com.
 Did you guess it? Probably not, because it doesn't contain many of the necessary elements to make a repository discoverable.
 
 Some suggestions to ensure your teammates can find your repository are:
-- use a descriptive repository name
-- give your repository a description
-- provide a URL for the deployment of the app, or documentation about this project
+- Use a descriptive repository name
+- Give your repository a description
+- Provide a URL for the deployment of the app, or documentation about this project
 
 Discover more about how to make a repository discoverable by visiting the **Files Changed** tab. It's OK if you want to do this later, any resources we cover throughout the course will be available at the end. 
 
-Please merge this PR.
+Please merge this pull request.
 
 <hr>
 <h3 align="center">I'll respond when you merge this pull request.</h3>
diff --git a/responses/discoverable.md b/responses/discoverable.md
@@ -1,4 +1,4 @@
-This PR is all about how to make your repositories more discoverable.
+This pull request is all about how to make your repositories more discoverable.
 
 ### Challenge question
 
diff --git a/responses/goto-pr.md b/responses/goto-pr.md
@@ -1 +1 @@
-Go to the [next PR]({{ url }}).
+Go to the [next pull request]({{ url }}).
diff --git a/responses/innersource-v-opensource.md b/responses/innersource-v-opensource.md
@@ -2,6 +2,6 @@
 
 Innersource and open source are very similar concepts, but they're not the same.
 
-**Open source** software is shared publicly and typically accepts contributions from contributors outside of an organization.
+**Open source** software public and typically accepts contributions from outside of an organization.
 
 **Innersource** is the practice of adopting open source practices internally within your organization. An organization that practices innersource, may or may not end up open sourced.
diff --git a/responses/metrics-answer.md b/responses/metrics-answer.md
@@ -4,9 +4,9 @@ Those are great ideas!
 
 Here are some other ideas for measuring how well you're doing:
 - Time to market
-- PRs to fix bugs
-- PRs to implement suggested features
-- number of collaborators to a project outside of maintaining team
+- Pull requests to fix bugs
+- Pull requests to add suggested features
+- Number of collaborators to a project outside of maintaining team
 
 <hr>
 <h3 align="center">I'll respond when you merge this pull request.</h3>
diff --git a/responses/projects-answer.md b/responses/projects-answer.md
@@ -2,7 +2,7 @@
 
 Without a clear project management strategy, you might as well pick any issue.
 
-Being explicit about your project management tool, whether it's inside of GitHub or elsewhere, will help potential contributors figure out whether their contribution will be immediately beneficial or triaged. 
+Being explicit about your project management tool will help potential contributors.  Whether it's inside of GitHub or elsewhere, communicate so they know whether their help is immediately helpful.
 
 <hr>
 <h3 align="center">I'll respond when you merge this pull request.</h3>
diff --git a/responses/publish.md b/responses/publish.md
@@ -1,13 +1,13 @@
 ### Almost done!
 
-It's now time to publish the innersource toolkit you've been working on throughout this course.
+It's time to publish the Innersource toolkit you've been working on.
 
 To publish:
-1. Go to the **Settings** tab for this repository.
+1. Go to the **Settings** tab for this repository
 1. Scroll down to the section titled _GitHub Pages_
-1. Select **master branch** in the Source drop down.
+1. Select **master branch** in the Source drop down
 
-That's all! GitHub Pages will then deploy your site and repo its status back to me. 
+That's all! GitHub Pages will then deploy your site and repository its status back to me. 
 
 <hr>
 <h3 align="center">I'll respond when I detect that GitHub Pages has finished deploying your site.</h3>
diff --git a/responses/repo-owner-answer.md b/responses/repo-owner-answer.md
@@ -7,15 +7,15 @@ A repository _does_ exist at githubtraining/training-manual, but it is private.
 <details>
 <summary>Why can't you see it then? Review the <b>Files Changed</b> tab and see if you can figure it out. Collapse this text if you'd like an explanation.</summary>
 
-The repository `training-manual` in the @githubtraining organization is private, and only visible to memebers of that organization. If you're not a member of the organization, it'll appear like the repository doesn't exist to you. This is an example of why having the right ownership structure is important. Having too many organizations with restrictive permissions means that each organization's work will be siloed. 
+The repository `training-manual` in the @githubtraining organization is private. It's only visible to members of that organization. If you're not a member of the organization, it'll appear like the repository doesn't exist to you. This is an example of why having the right ownership structure is important. Having too many organizations with restrictive permissions silos and isolates each organization's work. 
 </summary>
 
 Here are some recommendations based on some :sparkles: use of GitHub that we've seen:
-- aim for as few organizations as possible, remember: each organization is a black box to those outside of that organization
-- name your repositories in a meaningful manner, usually a simple project or application name will suffice
+- Aim for as few organizations as possible. Remember, each organization is a black box to those outside of that organization.
+- Name your repositories in a meaningful manner. Usually a simple project or application name will suffice.
 </summary>
 
-Please merge this PR.
+Please merge this pull request.
 
 <hr>
 <h3 align="center">I'll respond when you merge this pull request.</h3>
diff --git a/responses/repo-owner.md b/responses/repo-owner.md
@@ -4,8 +4,8 @@ This pull request is all about repository ownership and naming conventions.
 
 Does a repository exist at https://github.com/githubtraining/training-manual?
 
-- [ ] True, there is a repository at the given URL.
-- [ ] False, no repository exists at the given URL.
+- [ ] True, there is a repository at the given URL
+- [ ] False, no repository exists at the given URL
 
 <hr>
 <h3 align="center">I'll respond when you check one of the boxes above.</h3>
diff --git a/responses/templates-answer.md b/responses/templates-answer.md
@@ -2,9 +2,9 @@
 
 Every project _can_ have a different way to submit bug reports, so all the answers are right. 
 
-But, how could you know? With issue and pull request templates, you can take the mystery out of the equation and allow anyone across the organization to know the way each project prefers to receive issues and contributions.
+But, how could you know? With issue and pull request templates, you can take the mystery out of the equation. Templates show those across the organization the preferred way to contribute.
 
-Please merge this PR.
+Please merge this pull request.
 
 <hr>
 <h3 align="center">I'll respond when you merge this pull request.</h3>
diff --git a/responses/templates.md b/responses/templates.md
@@ -7,7 +7,7 @@ Here are four different ways you could submit a bug report. Which is the _right_
 - [ ] Open an issue on GitHub
 - [ ] Create a Jira issue
 - [ ] Open an internal support ticket
-- [ ] DM or email the maintainer
+- [ ] Direct message or email the maintainer
 
 <hr>
 <h3 align="center">I'll respond when you check one of the boxes above.</h3>
diff --git a/responses/welcome.md b/responses/welcome.md
@@ -1,13 +1,15 @@
-This repository will eventually be a working web site that you'll be able to publish internally as your own Innersource commons.
+# Welcome! 
+
+This repository will be a working website that you can publish as your own Innersource commons. 
 
 ![screenshot of final product](https://user-images.githubusercontent.com/16547949/56064057-f1f17700-5d3e-11e9-9100-9678dc91c544.png)
 
-As we work on this repo, we'll be creating a resource others can use within your organization. This repo can continue to be used after the course is finished. 
+As we work, we'll create a resource that others can use within your organization. This repository will be useful even after you finish this course.
 
 This is how this course will move along:
-- every new issue or pull request will start with a challenge question
-- you'll answer the challenge question; don't worry, there are no right or wrong answers
-- the question will highlight why each topic is an important part of applying Innersource practices right
+- Every new issue or pull request will start with a challenge question
+- You'll answer the challenge question _(don't worry, there are no right or wrong answers!)_
+- The question will highlight the importance of each topic in Innersource practices
 
 Here's your first challenge question!
 
diff --git a/responses/workflows-answer.md b/responses/workflows-answer.md
@@ -2,13 +2,13 @@
 
 The real answer is that, without documentation, we don't know!
 
-This PR covers the basics, but here are some recommendations to help any contributor know the right way to open pull requests: 
-- use protected branches, doing so will allow you to accept PRs without fear of breaking production code
-- use Codeowners in combination with protected branches, to ensure that the right people are pinged for specific changes
-- if you haven't picked a workflow, use a common and well documented one that your contributors can easily search for
-- be explicit about your deployment and release strategy
+This pull request covers the basics, but here are some recommendations to help any contributor know the right way to open pull requests: 
+- Use protected branches. Doing so will allow you to accept pull requests without fear of breaking production code.
+- Use `CODEOWNERS` in combination with protected branches to ensure the right people review changes.
+- If you haven't picked a workflow, use a common and well documented one.
+- Be explicit about your deployment and release strategy.
 
-Please merge this PR.
+Please merge this pull request.
 
 <hr>
 <h3 align="center">I'll respond when you merge this pull request.</h3>
diff --git a/responses/workflows.md b/responses/workflows.md
@@ -1,8 +1,8 @@
-This PR covers a few common workflows that are likely in use within your organization.
+This pull request covers a few common workflows that are likely in use within your organization.
 
 ### Challenge question
 
-Suppose you'd like to contribute to the repository whose branches are pictured below. Which branch should I use as a base for my contributions?
+Suppose you'd like to contribute to the repository pictured below. Which branch should I use as a base for my contributions?
 
 ![a screenshot of a repository's branches, they are: a protected master branch, a protected release-v1.0 branch. The rest are unprotected: bug-fix, green-colors, config-release-drafter, add-template](https://user-images.githubusercontent.com/16547949/56039935-5d1d5800-5d03-11e9-8a26-29d36cfc7499.png)
 

Original file line number	Diff line number	Diff line change
`@@ -1,4 +1,4 @@`
`1`		`-This PR is all about how to make your repositories more discoverable.`
	`1`	`+This pull request is all about how to make your repositories more discoverable.`
`2`	`2`
`3`	`3`	`### Challenge question`
`4`	`4`
Original file line number	Diff line number	Diff line change
`@@ -1 +1 @@`
`1`		`-Go to the [next PR]({{ url }}).`
	`1`	`+Go to the [next pull request]({{ url }}).`