[WIP] Spell check action

.github/workflows/aspell.yml

@@ -0,0 +1,20 @@
+name: Spell Check
+
+on:
+  push:
+    branches:
+      - "master"
+  pull_request:
+
+jobs:
+  spell-check:
+    runs-on: ubuntu-latest
+    steps:
+    - uses: actions/checkout@v2
+    # - name: spell-check
+    #   uses: reitermarkus/aspell@master
+    #   with:
+    #     files: patterns/2-structured/project-setup/*.md
+    #     args: --lang=en_GB --mode=markdown
+    - name: Spellcheck
+      uses: rojopolis/spellcheck-github-actions@0.5.0

.spellcheck.yml

@@ -0,0 +1,28 @@
+matrix:
+
+- name: markdown
+  sources:
+  - 'patterns/2-structured/project-setup/*.md'
+  # - '**/*.md'
+  aspell:
+    lang: en
+  dictionary:
+    wordlists:
+    - '.wordlist.txt'
+  pipeline:
+  - pyspelling.filters.markdown:
+      markdown_extensions:
+      - markdown.extensions.extra:
+  - pyspelling.filters.html:
+      comments: true
+      attributes:
+      - title
+      - alt
+      ignores:
+      - :matches(code, pre, samp, kbd, var)
+      # In HTML:
+      # <code>  Defines a piece of computer code
+      # <pre>   Defines pre-formatted text
+      # <samp>  Defines sample output from a computer program
+      # <kbd>   Defines keyboard input
+      # <var>   Defines a variable

.wordlist.txt

@@ -0,0 +1,15 @@
+InnerSource
+Patlet
+ISC
+InnerSource Commons
+
+
+gamification
+codebase
+roadmap
+
+
+# known company names
+Paypal
+Europace
+Bosch

patterns/2-structured/contracted-contributor.md

@@ -10,15 +10,15 @@ Associates wanting to contribute to InnerSource are discouraged from doing so by
 
 Without support by middle management, the total number of contributors and, as
 a result, the amount of contributions made and value generated by the
-InnerSource initiative will likely fall below expectation of top level
+InnerSource initiative will likely fall below expectation of top-level
 management. This will likely be amplified if there is no adequate funding for
 and empowerment of [Dedicated Community Leaders](dedicated-community-leader.md).
-This runs the risk of top level management abandoning the InnerSource idea.
+This runs the risk of top-level management abandoning the InnerSource idea.
 
 ## Context
 
 A large corporation has started an InnerSource initiative. Major goals for the
-initiative are to increase the efficiency of distributed software develoment
+initiative are to increase the efficiency of distributed software development
 and to foster innovation by allowing every associate to voluntarily
 contribute to InnerSource projects, regardless of topic and business unit.
 
@@ -27,12 +27,12 @@ them, the InnerSource initiative is just one of many initiatives to foster
 innovation and efficiency, though. They are funding InnerSource with money and
 capacity for community leaders and are largely giving autonomy as for how the
 budget is spent. They are also limiting the breadth and duration of the
-initiative and partake in periodic reviews until there is proof that it yields
+initiative and partake in periodic reviews until there is proof it yields
 the expected results (see [Review Committee](review-committee.md)).  Top level
 management has announced their support for InnerSource on various company
 internal meetings.
 
-However, top level management has not yet empowered or incentivised mid-level
+However, top-level management has not yet empowered or incentivised mid-level
 managers to allow or even motivate their employees to participate in
 cross-divisional InnerSource activities. In addition to that, the capacity of
 every associate is usually allocated to non InnerSource projects for 100 % of
@@ -64,7 +64,7 @@ hours, not during free time.
   his teammates in his business unit increase.
 - Individual contributors will likely consider participating in InnerSource
   as an opportunity to enhance their professional network within the company
-  and to gain knowledege and experience in the technical area of her
+  and to gain knowledge and experience in the technical area of her
   contributions.
 
 ## Solution
@@ -77,7 +77,7 @@ time.
 - The contracting specifies a maximum percentage of the associates work time in
   InnerSource.
 - The contracting clearly states that work in the contributor's business unit
-  takes precendence over work in InnerSource.
+  takes precedence over work in InnerSource.
 - The contracting states that it is not required to work in InnerSource for the
   maximum percentage specified in the contract.
 - The contracting is signed by the contributor, the contributor's line manager,
@@ -115,7 +115,7 @@ A formal contracting is also beneficial for contributors and communities:
   eventually achieve [Trusted Committer](./trusted-committer.md) status.
 - A formal contracting provides a basis for resolving conflict related to
   participation in InnerSource activities. Note that mediation will likely be
-  successful only for a few companies with a culture condusive to that.
+  successful only for a few companies with a culture conducive to that.
 
 ## Known Instances
 

patterns/2-structured/crossteam-project-valuation.md

@@ -31,17 +31,17 @@ Such models give us the tool that we need to focus and amplify high-value collab
 The core of all cross-team project value is the idea that we can get more done together than apart.
 Ascribing value to a cross-team effort is an exercise in quantifying _how much more_ is getting done together.
 The exact delta in productivity will vary by domain and project.
-There is a common process, though, by which you can create a model to calculate it.
+There is a common process, by which you can create a model to calculate it.
 
 ## Explanation
 
 Assemble a small team of subject matter experts in your domain.
 Using that team of experts, estimate 4 things about each consumer of your project output:
 
-  * How long does it take them to consume your project output?
-  * How long would it otherwise take them to home-roll the value of your project output for themselves?
-  * What percentage of your project output is actually useful for them?
-  * How much time on an ongoing basis (ideally per-use) would they otherwise spend maintaining their home-rolled solution?
+* How long does it take them to consume your project output?
+* How long would it otherwise take them to home-roll the value of your project output for themselves?
+* What percentage of your project output is actually useful for them?
+* How much time on an ongoing basis (ideally per-use) would they otherwise spend maintaining their home-rolled solution?
 
 When making these estimations, it's impossible to know with high accuracy _exactly_ how long any activities take.  That's not your goal.
 Rather than exactness, you should strive to _**set a worst-case bound**_ on these estimates.
@@ -66,12 +66,12 @@ Once you have your worst-case bounds you can value your cross-team project outpu
 ## Commentary
 
 Despite the trappings of rigor, this process does not yield an exact way to measure cross-team project output.
-In-practice, though, it does give a framework by which you can make a sound decision at how to fund this work.
+In-practice, however, it does give a framework by which you can make a sound decision at how to fund this work.
 After having good, reasonable data according to the above explanation, you should fund dedicated development hours toward running the project up to _**at least**_ of the lesser of the following three levels:
 
 1.  The raw hours saved by the formula above.  Since we're all sure that the formula will produce a number that is below the true number of hours saved, you can have confidence that funding the project up to that point is a sure win for you.
-1.  The amount of time that it takes to support inner sourced contributions to cross-team projects.  Since the contributor would likely have done the work anyway in a one-off fashion, it is worth it to fund the time it takes to faciliate their work going into a shared location.
-1.  Whatever feels good to you.  One intentional side-effect of having a valuation formula is that it  naturally forces measurement of the key points of usage that provide value to consumers.
+1.  The amount of time that it takes to support inner sourced contributions to cross-team projects.  Since the contributor would likely have done the work anyway in a one-off fashion, it is worth it to fund the time it takes to facilitate their work going into a shared location.
+1.  Whatever feels good to you.  One intentional side effect of having a valuation formula is that it  naturally forces measurement of the key points of usage that provide value to consumers.
 Those measurements can be understood and consumed in their raw form to provide you with a gut-feel idea of how valuable is the project.
 
 Some may be concerned about the lack of accuracy in this valuation approach.  It's okay for this process to not give an exact measurement.  It just needs to be accurate enough to accomplish 2 purposes:

patterns/2-structured/praise-participants.md

@@ -5,7 +5,7 @@ Praise Participants
 ## Patlet
 
 After an inner source contribution, it's important to thank the contributor for their time and effort.
-This pattern gives guidance that not only effectively acknowledges the contribution but also endgenders further engagement from the contributor and others.
+This pattern gives guidance that not only effectively acknowledges the contribution but also engenders further engagement from the contributor and others.
 
 ## Problem
 
@@ -21,7 +21,7 @@ A pattern in this area makes it easy to do and ensures that the message comes ac
 
 ## Forces
 
-* You are busy, which makes it easy to forget some of the soft touches like praise and thanks.
+* You are busy, which makes it easy to forget some soft touches like praise and thanks.
 * You may not be someone that is comfortable in social situations or good with words.
 * Peer recognition is very important to job satisfaction and career development.
 
@@ -31,14 +31,14 @@ It feels good to anyone to be recognized by others.
 In a professional setting, increased recognition is also an avenue to increased influence and growth.
 Any time someone gives to your inner source project, recognize them with a sincere and qualified "thank you".
 
-For non-trivial contributions (all code contributions and also significant time contributions), say thank you via the following mechanisms:
+For non-trivial contributions (all code contributions and significant time contributions), say thank you via the following mechanisms:
 
 1. Call out the person by name in any chat location (e.g. _Slack_) where you organize your project activity.  Let everyone know what they did and thank them publicly.  Example:
 
 > Everyone @here give a high-five to @andrew.clegg for updating the _rcs-viewer_ to the latest version of the _hebo-client_ (https://github.com/rcs/rcs-viewer/pull/81).
 Thanks for helping keep this library up-to-date, Andy!
 
-2. Send an email to them and their manager (cc'd) privately thanking them for the contribution.
+2. Email them and their manager (cc'd) privately thanking them for the contribution.
 For code contributions often-times you can just forward the merge notification mail.  Example:
 
 > Hi, Andy, I want to thank you again for making this update.
@@ -49,7 +49,7 @@ Thanks for solving your own problem in a way that also makes the _rcs-viewer_ be
 
 Feedback like this leaves the contributor with a fantastic feeling and ready to come back for more.
 Combining **both** forms of thanks gives them recognition in front of their peers (breadth) and in front of their direct manager (depth).
-There's a subtle encouragement for those peers in chat to consider contributing themselves and for that manager to look for appropriate circumstances to encourage their other direct reports to do the same.
+There's a subtle encouragement for those peers in chat to consider contributing themselves and for that manager to look for appropriate circumstances to encourage their other direct reports doing the same.
 Additionally, awareness of the inner source project spreads to the manager, who may have previously not known of the team's use and involvement with it.
 
 One caveat - keep it real.

patterns/2-structured/project-setup/communication-tooling.md

@@ -6,9 +6,11 @@ Communication Tooling
 
 An InnerSource project is being used outside the original development team but
 users are having trouble getting help and getting in touch with the project
-team. The idea is to setup and document standard communication tooling that
+team. The idea is to set up and document standard communication tooling that
 allows for discussions to become visible, archived and searchable.
 
+Test
+
 ## Context
 
 A team depends on another team's component. It would like to make contributions
@@ -39,9 +41,9 @@ The goal when streamlining communication channels for InnerSource projects
 should be to align communication around topics, not around certain sets of
 people:
 
-- The project should have it's own issue tracker where structured communication, decision making and progress tracking can happen transparently for all host team members but also for downstream users and contributors to follow.
-- The project should have one or more discussion channels that come with less rigid a structure. Typically this will be mailing lists, online forums or even archived chat channels. Usually it is enough to start with just one channel for the project, if traffic increases too much it's helpful to split discussions around project usage from discussions around project development.
-- In addition the project should have one private channel where sensitive communication can happen between [Trusted Committers](../trusted-committer.md) - e.g. adding further Trusted Committers to the host team. This channel should be used with great care such that communication defaults to open and is kept private only under very rare circumstances.
+- The project should have its own issue tracker where structured communication, decision-making and progress tracking can happen transparently for all host team members but also for downstream users and contributors to follow.
+- The project should have one or more discussion channels that come with less rigid a structure. Typically, this will be mailing lists, online forums or even archived chat channels. Usually it is enough to start with just one channel for the project, if traffic increases too much it's helpful to split discussions about project usage from discussions about project development.
+- In addition, the project should have one private channel where sensitive communication can happen between [Trusted Committers](../trusted-committer.md) - e.g. adding further Trusted Committers to the host team. This channel should be used with great care such that communication defaults to open and is kept private only under very rare circumstances.
 
 While communication can happen outside of written channels, as much information
 as possible should be brought back to the asynchronous channels.
@@ -71,7 +73,7 @@ the project.
 
 Answering questions in those channels means that not only other team members
 can listen in and provide additional information, it also means that other
-users with the same question see (or later on find) the previous answer leading
+users with the same question see (or later find) the previous answer leading
 to a lower need to repeat explanations.
 
 ## Known Instances

patterns/2-structured/project-setup/issue-tracker.md

@@ -10,13 +10,13 @@ The InnerSource host team fails to make not only plans and progress but also con
 
 A team develops a component that many teams in the organization depend on. It
 uses a standard issue tracker for tracking open bugs and feature requests.
-However the context in each entry is very limited. As a result potential
+However, the context in each entry is very limited. As a result potential
 contributors have no way of knowing what change exactly each issue is talking
 about.
 
 ## Context
 
-The InnerSource project tooling is all setup. However the project issue tracker
+The InnerSource project tooling is all setup. However, the project issue tracker
 is mainly used for sharing progress. In InnerSource projects there are many more
 use cases that an issue tracker can be used for that make remote, asynchronous
 communication easier.
@@ -25,7 +25,7 @@ communication easier.
 
 - Contributors would like to understand whether the feature that they are missing is already on the roadmap. With a lot of context missing in issues though it is impossible to decide whether existing issues match the contributing team's needs.
 - As a result a lot of duplicate issues are being opened that the host team has to deal with.
-- As context in open issues is so limited contributors are unable to help the host team by implementing some of the easier issues that are open already. As a result a lot of work remains in the hands of the host team.
+- As context in open issues is so limited contributors are unable to help the host team by implementing some easier issues that are open already. As a result a lot of work remains in the hands of the host team.
 - With a strong focus on verbal communication it is impossible to discern after a couple months or years why a certain feature was being chosen for implementation. As a result refactorings, in particular simplifying the component becomes an exercise in project archaeology and brain picking of people who remember what was discussed.
 
 ## Solution
@@ -36,14 +36,14 @@ development but also during the planning phase of new features:
 - For bugs, planned features and feature ideas create separate issues. In each of those include as much information as possible so that potential external contributors are able to understand the context. Ideally, in particular for easier changes, include enough information for external contributors to support the host team by implementing the functionality in question.
 - Potentially use the issue tracker as a channel to ask questions. This is in particular helpful if you are lacking other communication sources to tackle user questions.
 - Make use of tags and categories in order to distinguish issues used for different purposes.
-- For starting a brain storming session asynchronously, open an issue for gathering ideas. When discussion is starting to calm down, summarize the points identified in this issue in a separate document. Post that for review as a pull request to drill deeper into individual points that still need clarification. The resulting document can be used to publish the results in other appropriate channels as well as for future reference.
+- For starting a brainstorming session asynchronously, open an issue for gathering ideas. When discussion is starting to calm down, summarize the points identified in this issue in a separate document. Post that for review as a pull request to drill deeper into individual points that still need clarification. The resulting document can be used to publish the results in other appropriate channels as well as for future reference.
 - Most issue tracker implementations allow for issue templates. Make use of those not only to collect commonly needed information for bug reports but also include hints about what kind of information is needed for the other usage types.
 
 ## Resulting Context
 
 - Making more use of the project's issue tracker for communication enables external contributors to follow along and make better decisions on what to contribute.
 - A focus on structured written communication enables host team members to participate remotely.
-- Consistently communicating in writing means that passive documentation on project decisions accumulates as a by product instead of needing added attention.
+- Consistently communicating in writing means that passive documentation on project decisions accumulates as a by-product instead of needing added attention.
 - Consistently using public communication channels leads to more humans following a discussion. This means that there are more knowledgeable humans that can answer questions, chime in on open issues, or point out flaws in planned features that would otherwise be found only much later.
 - Moving discussions to a public discussion medium creates an opportunity for potential future contributors to lurk, follow along, get comfortable and learn the ways of the project long before they have the first need to get involved.