Merge pull request #560 from InnerSourceCommons/fix-product-spelling

Spell checking and style checking of the English LP content (vale)

Author: marshmallowrobot

.github/vale/Vocab/Base/accept.txt

@@ -0,0 +1,13 @@
+uplevel
+upleveled
+refactorization
+integrations
+
+POs?
+Committer's
+
+asciidoctor
+asciidoc
+Yonik
+reviewdog
+duplicative

.github/vale/Vocab/Base/reject.txt

@@ -0,0 +1,33 @@
+name: Spelling & Styles
+
+on:
+  push:
+    branches:
+    - main
+    paths:
+    - '**.asciidoc'
+    - '**.md'
+  pull_request:
+    branches:
+    - main
+
+jobs:
+  vale:
+    runs-on: ubuntu-latest
+
+    steps:
+    - uses: actions/checkout@v3
+
+    - name: Vale Linting
+      uses: errata-ai/vale-action@reviewdog
+      with:
+        # the folders to run the checks for
+        files: '["docs/","introduction/", "trusted-committer/", "contributor/", "product-owner/", "project-leader/", "workbook/"]'
+        # we want to check all files in the folders listed above, but exclude
+        # a) any files in subfolders (these are translations)
+        # b) any '-script.asciidoc' files
+        # c) any '*.vtt' files
+        vale_flags: '--glob=!{*/*/*,*/*-script.asciidoc,*/*.vtt}' 
+        # one of: added, diff_context, file, nofilter
+        filter_mode: added 
+        debug: true

.github/workflows/vale.yml

@@ -4,4 +4,5 @@ scripts/node_modules
 scripts/learningpath
 scripts/newsite
 scripts/.env
-.vs
+.vs
+.github/vale

.gitignore

@@ -0,0 +1,9 @@
+StylesPath = .github/vale
+MinAlertLevel = suggestion
+
+Packages = https://github.com/InnerSourceCommons/isc-styles/releases/latest/download/ISC.zip
+
+Vocab = Base
+
+[*]
+BasedOnStyles = ISC

.vale.ini

@@ -1,10 +1,10 @@
 == Becoming an InnerSource Contributor
 
-InnerSource contributors operate outside of regular team boundaries, they are the links crossing organisational silos. As such, they need to be aware of a few common practices that make this work more effective.
+InnerSource contributors operate outside of regular team boundaries, they are the links crossing organizational silos. As such, they need to be aware of a few common practices that make this work more effective.
 
 === Sharing Mindset
 
-So - you're implementing a new feature for your team's product. You need some functionality to get this feature working. Instead of jumping right into the implementation, slow down for a bit: does this functionality reflect a general issue? Is it something that other teams in your organisation face as well due to the shared business domain? Is this functionality orthogonal to the domain of your project? If any of that applies, then start looking beyond your own team: is there a shared solution that you can use or improve to fit your needs? Should there be one?
+So - you're implementing a new feature for your team's product. You need some functionality to get this feature working. Instead of jumping right into the implementation, slow down for a bit: does this functionality reflect a general issue? Is it something that other teams in your organization face as well due to the shared business domain? Is this functionality orthogonal to the domain of your project? If any of that applies, then start looking beyond your own team: is there a shared solution that you can use or improve to fit your needs? Should there be one?
 
 === Benefits to sharing solutions
 

contributor/02-becoming-a-contributor-article.asciidoc

@@ -120,7 +120,7 @@ the software project to which they are contributing.
 As a result, the final call on what the contribution must look like is with the
 host team. It helps to approach the host team with a humble
 mindset, with the assumption that all are collaborating towards the purpose of
-the shared organisation. It helps to be open and transparent - not only about
+the shared organization. It helps to be open and transparent - not only about
 what was implemented and how, but also why the change was needed.
 
 Treat any feedback as a gift: others are trying to improve your solution, saving

contributor/03-contributor-ethos-article.asciidoc

@@ -82,19 +82,19 @@ drain of energy that central dependencies bring to the table? Many open source
 projects are being used by a huge number of players - some of who participate
 in their design and development. Encouraging cross team collaboration in InnerSource
 projects at the corporate level means that you can drive central
-innovation from the edges of your organisation.
+innovation from the edges of your organization.
 
 In general it is well understood that projects with a https://en.wikipedia.org/wiki/Bus_factor[bus
 factor] of one or two people pose a
-risk to the organisation - all the more, when that project turns out to be
+risk to the organization - all the more, when that project turns out to be
 central to the purpose of the business. InnerSource helps not only with making such
 projects transparent, but also provides tools to improve that situation by
 putting focus on mentoring and expanding the contributor base.
 
 While cross team collaboration makes assessing individual contributions hard,
-it also enables learning and knowledge sharing within the organisation. As a
+it also enables learning and knowledge sharing within the organization. As a
 result, the impact of individuals will improve. Best practices and positive
-innovation will spread more easily across the entire organisation. As a side
+innovation will spread more easily across the entire organization. As a side
 effect, improvements to the work environment will more easily spread across the
 organization - helping retain employees.
 

contributor/05-benefits-of-contribution-article.asciidoc

@@ -14,6 +14,6 @@ We hope you've enjoyed watching the videos, and/or and reading the articles, and
 
 If you haven't done so already, we would like to invite you to learn more about the other aspects of InnerSource in our InnerSource learning path: http://innersourcecommons.org/learningpath/
 
-We invite you to check out the InnerSource group http://innersourcecommons.org[InnerSource Commons] online - feel free to join the discussion and share your experiences and lessons learnt in your organization.
+We invite you to check out the InnerSource group http://innersourcecommons.org[InnerSource Commons] online - feel free to join the discussion and share your experiences and lessons learned in your organization.
 
 Live long and have prosperous projects!

contributor/06-conclusion-article.asciidoc

@@ -1,4 +1,4 @@
 ---
 title: Learning Path - Contributor
 ---
-The Contributor section covers what it means to be an InnerSource Contributor, the aspects of behaviour that will make you a successful Contributor, contribution mechanics and the benefits of InnerSource for your team and organization.
+The Contributor section covers what it means to be an InnerSource Contributor, the aspects of behavior that will make you a successful Contributor, contribution mechanics and the benefits of InnerSource for your team and organization.