Merge pull request #27 from githubtraining/fix-typos

brianamarie · web-flow · commit e924adee2003 · 2019-09-04T11:22:46.000+02:00
Fix typos &amp; Bug
diff --git a/responses/00_welcome.md b/responses/00_welcome.md
@@ -1,12 +1,13 @@
-# Welcome! 
+# Welcome!
 
-This repository will be a working website that you can publish as your own InnerSource commons. 
+This repository will be a working website that you can publish as your own InnerSource landing page.
 
 ![Screen Shot of final product](https://user-images.githubusercontent.com/6351798/56301905-009cad00-60f6-11e9-9bf4-ed1c1907ef55.png)
 
 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 the importance of each topic in InnerSource practices
diff --git a/responses/01_innersource-v-opensource.md b/responses/01_innersource-v-opensource.md
@@ -2,8 +2,9 @@
 
 InnerSource and open source are very similar concepts, but they're not the same.
 
-**Open source** software public and typically accepts contributions from outside of an organization.
+**Open source** software is 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.
+**InnerSource** is the practice of adopting open source patterns internally within your organization. An organization that practices InnerSource may or may not also maintain open source software.
 
-You can find your next steps in the [next pull request]({{ url }}).
+<hr>
+<h3 align="center">You can find your next steps in the <a href="{{ url }}">next pull request</a>.</h3>
diff --git a/responses/01_repo-owner.md b/responses/01_repo-owner.md
@@ -1,4 +1,4 @@
-This pull request is all about repository ownership and naming conventions. 
+This pull request is about repository ownership and naming conventions.
 
 ### Challenge question
 
diff --git a/responses/02_repo-owner-answer.md b/responses/02_repo-owner-answer.md
@@ -9,19 +9,26 @@ A repository _does_ exist at githubtraining/training-manual, but it is private.
 
 ## Understanding repository visibility
 
-There are three types of repository visiility: **public, internal, and private**. 
+There are three types of repository visibility: **public, internal, and private**.
 
-Our repository, `githubtraining/training-manual`, isn't public. It could be internal, which means only members of the organizations that an account owns will see it, or it could be private, which means only teams and individuals that have been granted access to it can see it. 
+Our repository, `githubtraining/training-manual`, isn't public. It could be _internal_, which means only members of the organizations that an account owns will see it. Or, it could be _private_, which means only teams and individuals that have been granted access to it can see it.
 
-This is an example of why having the right ownership structure is important. Otherwise, it can be difficult for members of your team to find and contribute to projects. Having too many disconnected organizations with restrictive permissions silos and isolates each organization's work.
+This is an example of why ownership structure is important. Otherwise, it can be difficult for members of your team to find and contribute to projects. Having too many disconnected organizations with restrictive permissions isolates each organization's work.
+
+Here are some recommendations based on some :sparkles: admirable :sparkles: use of GitHub that we've seen:
 
-Here are some recommendations based on some :sparkles: use of GitHub that we've seen:
 - Use the internal visibility (currently in beta) if you're working on behalf of an [enterprise account](https://help.github.com/en/articles/about-enterprise-accounts).
-- Name your repositories in a meaningful manner. Usually a simple project or application name will suffice.
+- Name your repositories meaningfully. Usually a simple project or application name is best.
+
 <hr>
 </details>
 
-Please merge this pull request.
+### :keyboard: Activity: Review this pull request
+
+1. Read the additions in the `Files changed` tab
+2. Approve this pull request (if needed)
+3. Merge this pull request
+4. Delete the branch
 
 <hr>
-<h3 align="center">I'll respond when you merge this pull request.</h3>
+<h3 align="center">I'll respond after you merge this pull request.</h3>
diff --git a/responses/03_discoverable.md b/responses/03_discoverable.md
@@ -1,4 +1,4 @@
-This pull request is all about how to make your repositories more discoverable.
+This pull request is about making repositories discoverable.
 
 ### Challenge question
 
@@ -7,4 +7,4 @@ What is this repository for?
 ![gif of a repository with no description, link, or and just a few folders: .github, .vscode, _appendix, _events, _includes, _layouts](https://user-images.githubusercontent.com/6351798/56160925-995feb00-5f85-11e9-8a91-a611936c98bd.gif)
 
 <hr>
-<h3 align="center">I'll respond when I detect you comment on this pull request.</h3>
+<h3 align="center">I'll respond when I detect your new comment on this pull request.</h3>
diff --git a/responses/04_discoverability-answer.md b/responses/04_discoverability-answer.md
@@ -5,13 +5,19 @@ 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
 
-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. 
+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.
+
+### :keyboard: Activity: Discoverability
 
-Please merge this pull request.
+1. Review the additions about discoverability in the `Files changed` tab
+2. Approve this pull request (if needed)
+3. Merge this pull request
+4. Delete the branch
 
 <hr>
 <h3 align="center">I'll respond when you merge this pull request.</h3>
diff --git a/responses/06_templates-answer.md b/responses/06_templates-answer.md
@@ -1,10 +1,15 @@
 ### Answer :crystal_ball:
 
-Every project _can_ have a different way to submit bug reports, so all the answers are right. 
+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. Templates show those across the organization the preferred way to contribute.
 
-Please merge this pull request.
+### :keyboard: Activity: Review templates
+
+1. Review the examples and types of template files in the `Files changed` tab
+2. Approve this pull request (if needed)
+3. Merge this pull request
+4. Delete the branch
 
 <hr>
 <h3 align="center">I'll respond when you merge this pull request.</h3>
diff --git a/responses/07_workflows.md b/responses/07_workflows.md
@@ -1,8 +1,8 @@
-This pull request covers a few common workflows that are likely in use within your organization.
+This pull request covers a few common workflows that may be used within your organization.
 
 ### Challenge question
 
-Suppose you'd like to contribute to the repository 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 you use as a base for your 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)
 
diff --git a/responses/08_workflows-answer.md b/responses/08_workflows-answer.md
@@ -8,7 +8,12 @@ This pull request covers the basics, but here are some recommendations to help a
 - 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 pull request.
+### :keyboard: Activity: Review workflow documentation
+
+1. Review the changes in the `Files changed` tab
+2. Approve this pull request (if needed)
+3. Merge this pull request
+4. Delete the branch
 
 <hr>
 <h3 align="center">I'll respond when you merge this pull request.</h3>
diff --git a/responses/10_projects-answer.md b/responses/10_projects-answer.md
@@ -4,5 +4,12 @@ Without a clear project management strategy, you might as well pick any issue.
 
 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.
 
+### :keyboard: Activity: Review project management strategies
+
+1. Review the changes in the `Files changed` tab
+2. Approve this pull request (if needed)
+3. Merge this pull request
+4. Delete the branch
+
 <hr>
 <h3 align="center">I'll respond when you merge this pull request.</h3>
diff --git a/responses/12_metrics-answer.md b/responses/12_metrics-answer.md
@@ -3,10 +3,18 @@
 Those are great ideas!
 
 Here are some other ideas for measuring how well you're doing:
+
 - Time to market
 - Pull requests to fix bugs
 - Pull requests to add suggested features
 - Number of collaborators to a project outside of maintaining team
 
+### :keyboard: Activity: Review measurement techniques
+
+1. Review the changes in the `Files changed` tab
+2. Approve this pull request (if needed)
+3. Merge this pull request
+4. Delete the branch
+
 <hr>
 <h3 align="center">I'll respond when you merge this pull request.</h3>
diff --git a/responses/13_publish.md b/responses/13_publish.md
@@ -3,11 +3,12 @@
 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. Scroll down to the section titled _GitHub Pages_
 1. Select **master branch** in the Source drop down
 
-That's all! GitHub Pages will then deploy your site and repository 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>

Original file line number	Diff line number	Diff line change
`@@ -1,4 +1,4 @@`
`1`		`-This pull request is all about repository ownership and naming conventions.`
	`1`	`+This pull request is about repository ownership and naming conventions.`
`2`	`2`
`3`	`3`	`### Challenge question`
`4`	`4`