Fix Vale typos (#592)

* Update outline.md for typos * Update video-proposal.asciidoc typo * Update 03-major-benefits-are-built-into-the-innersource-process-article.asciidoc * Update 04-new-roles-and-responsibilities-article.asciidoc * Update outline.md * Update 01-introduction.asciidoc * Toggle ISC.InnerSource rule temporarily, to not alert on "Inner__Source__" --------- Co-authored-by: Sebastian Spier <[email protected]>
InnerSourceCommons · Sep 13, 2023 · b16b234 · b16b234
1 parent 02fa7c0
commit b16b234
Show file tree

Hide file tree

Showing 7 changed files with 13 additions and 9 deletions.
diff --git a/contributor/02-becoming-a-contributor-article.asciidoc b/contributor/02-becoming-a-contributor-article.asciidoc
@@ -28,8 +28,12 @@ A good Contributor can comfortably make a call for when it makes both technical
 
 === Scope of InnerSource contributions
 
+pass:[<!-- vale ISC.InnerSource = NO -->]
+
 So is Inner__Source__ only about __Source__Code? Of course not. If your team's business depends on an outside component, you want to make sure it's well maintained and well run. As an InnerSource Contributor, you can help the host team in multiple ways. Reporting issues you see when using the component is a valuable contribution. Creating or fixing test cases that show that the code isn't working as expected is valuable. So is improving documentation, so others spend less time using it and contributing to it. Supporting other users, helping with bug triage can be valuable contributions. Improving builds is another example of a valuable contribution.
 
+pass:[<!-- vale ISC.InnerSource = YES -->]
+
 To summarize no contribution is too small to contribute. Here is one that I made
 to https://github.com/tensorflow/models/pull/4784[tensorflow/models]. A simple label change in a graph.
 

diff --git a/contributor/video-proposal.asciidoc b/contributor/video-proposal.asciidoc
@@ -36,7 +36,7 @@ This section teaches the mindset, the habits, technical approaches and other det
 ==== This video is for you because...
 
 * You are a possible future Contributor to an InnerSource project and want to know what to expect
-* You are a host team member looking to open your work for outside contributors / inner sourcing and want to be prepared to know what being a contributor may be like
+* You are a host team member looking to open your work for outside contributors / InnerSource contributions and want to be prepared to know what being a contributor may be like
 * You are a product owner looking to support your TC or a (line) manager and want to know how the InnerSource approach is meant to work.
 
 ==== Prerequisites

diff --git a/...owner/03-major-benefits-are-built-into-the-innersource-process-article.asciidoc b/...owner/03-major-benefits-are-built-into-the-innersource-process-article.asciidoc
@@ -12,7 +12,7 @@ You can start to implement and plan more effectively.
 Often, your team's problem (or feature) may not be the highest priority for that other team.
 You no longer have to lean on escalations to upper management and politics to get access to that team.
  Instead, you have more power to determine priorities with your team and reduce your dependencies on others.
-Sometimes it may take longer because of the learning curves. But if it is a team that is a constant bottleneck, you can get those stories out of their backlog that've been sitting there for years.
+Sometimes it may take longer because of the learning curves. But if it is a team that is a constant bottleneck, you can get those stories out of their backlog that have been sitting there for years.
 
 _Open planning_ - this is where everyone publishes their planning process in an open and standardized fashion.
 At PayPal, we have the UPE standard. It stands for Unified Product Experience.
@@ -25,7 +25,7 @@ Open planning allows for more effective negotiations between teams.
 
 One of the things we work a lot on in InnerSource is _open documentation_.
 This includes the planning process, the standards, things of that nature.
-A key element of this is the findability and the fact that there's a certain amount of centralization, so that everybody knows where to go to find the documentation to figure out how to collaborate with you better.
+A key element of this is the discoverability and the fact that there's a certain amount of centralization, so that everybody knows where to go to find the documentation to figure out how to collaborate with you better.
 
 It has a lot of benefits in regards to your success.
 Some of that is the open planning and the open standards, so that you can collaborate better.

diff --git a/product-owner/04-new-roles-and-responsibilities-article.asciidoc b/product-owner/04-new-roles-and-responsibilities-article.asciidoc
@@ -33,7 +33,7 @@ Once you start working with those other teams, and when you onboard new develope
 If your tool is one of those bottlenecks and is really important to them, they may even offer to help you do a lot of the heavy lifting in regards to the standards, because they want to integrate in with your product.
 
 Lastly, internal marketing.
-There're some projects that everyone wants to contribute code to.
+There are some projects that everyone wants to contribute code to.
 Oftentimes, these projects are the bottlenecks.
 I find that people start working on InnerSource projects at first because they must get something into one of those bottleneck projects.
 So they can progress their own projects forward. But what if you aren't one of those projects?

diff --git a/project-leader/outline.md b/project-leader/outline.md
@@ -43,7 +43,7 @@ Challenges with InnerSource and agile (these challenges form the basis for the r
    - Common fears (like losing control) and counter measures
    - Same phrase - different meaning: How issue trackers and code reviews are used differently in InnerSource projects than is common in the industry.
    - The impact of transparency: How InnerSource depends on trust, what to avoid to keep trust alive.
-   - written first is not to avoid verbal communication or to move everything into DMs or long winded email threads
+   - written first is not to avoid verbal communication or to move everything into direct messages or long winded email threads
 
 InnerSource and capacity planning
 
@@ -70,7 +70,7 @@ Options for shared ownership
    - Implications of each level on product management
 - Common hurdles (line management, performance review setups)
 - Advantages
-- Commons issues wrt. operations and solutions
+- Commons issues with respect to operations and solutions
 
 
 Relation to open source

diff --git a/trusted-committer/outline.md b/trusted-committer/outline.md
@@ -7,7 +7,7 @@
 - Different ways to become TC
 - TC lifecycle (bringing on successors, sunsetting)
 - Useful skills/attitude/emotional maturity
-- TC antipatterns
+- TC anti-patterns
 - Why is the TC role important for IS success
 
 ## Target Audience
@@ -26,7 +26,7 @@
     - Contributor/Guest
         - Responsible for "fitting in"/conforming to the host team and it's
           expectations/processes.
-    - Product Owner (distinction btw. Guest and Host PO)
+    - Product Owner (distinction between Guest and Host PO)
     - TC
         - TC has rights to push code closer to production than a contributor
         - also known as _Host_

diff --git a/workbook/01-introduction.asciidoc b/workbook/01-introduction.asciidoc
@@ -105,7 +105,7 @@ More than one answer may be correct in some questions.
 
 ====== Correct answer: 1
 
-Why 1 is correct: The host teams open their code base to others and put effort into vetting contributions precisely because their code end up better and more featureful than if they did all the coding themselves.
+Why 1 is correct: The host teams open their code base to others and put effort into vetting contributions precisely because their code end up better and with more features than if they did all the coding themselves.
 
 Why 2 is incorrect: InnerSource has no impact on the definition of requirements and priorities. As with any professional software development, developers have to understand their users.