fix: MD009 trailing whitespace

Leaves trailing doublespace that is used as newlines

Author: nschonni

.markdownlint.json

@@ -2,7 +2,6 @@
     "default": true,
     "MD004": false,
     "MD007": false,
-    "MD009": false,
     "MD012": false,
     "MD013": false,
     "MD014": false,

meta/boardreports/2020-10-details.md

@@ -1,7 +1,7 @@
 # InnerSource Patterns WG - Report for governance meeting 2020-10
 
 **Details Section**
- 
+
 ## Project Activity - Describe the overall activity in the project over the past quarter.
 
 Here are some more detailed numbers as mentioned in short-form.
@@ -10,10 +10,10 @@ Here are some more detailed numbers as mentioned in short-form.
 
 #### Entirely new & merged: 5
 
-- RFCs #204 @tsadler1988 @spier @mainec 
+- RFCs #204 @tsadler1988 @spier @mainec
 - InnerSource Activity Score @michadelic SAP #189 @newmexicokid @spier
 - InnerSource License #147
-- Pattern Overview Mindmap: @feiwan2000 (very popular!) 
+- Pattern Overview Mindmap: @feiwan2000 (very popular!)
 - Europace sponsored: Mechanics and tooling recommendations #124, #123 #121 @mainec @rrutledge @martinklewitz @newmexicokid @sjn
 
 #### Entirely new & open: 2
@@ -29,7 +29,7 @@ Here are some more detailed numbers as mentioned in short-form.
 
 #### Progress on existing PRs: 8
 
-- #95 (almost done, @gruetter), #46 (#216, @gruetter) #120 #84 #78 #74 #71 #64 
+- #95 (almost done, @gruetter), #46 (#216, @gruetter) #120 #84 #78 #74 #71 #64
 
 ### Technical contributions: about 8
 
@@ -39,7 +39,7 @@ Here are some more detailed numbers as mentioned in short-form.
 
 ### Cleanup, Fixing & Migration: a lot
 
-- Fixing countless typos, broken links and inconsistent templates/documentation: @spier 
+- Fixing countless typos, broken links and inconsistent templates/documentation: @spier
 - Spelling, typos, examples #176, #175 @jpatrao
 - Typos, small improvements @stingrayza, @michadelic @funzinator
 

meta/boardreports/2020-10.md

@@ -15,9 +15,9 @@
 ## Project Activity - Describe the overall activity in the project over the past quarter.
 
 - New process proposal by @maxcapraro, discussion (@spier @mainec @newmexicokid @lenucksi) and successful adoption (initial, structured, validated, goal: faster first contribution, see contributor handbook)
-- Processing of existing content from wiki and existing PRs into publishable repo content, large scale cleanup, migration and fixing, all ongoing for the foreseeable future. 
+- Processing of existing content from wiki and existing PRs into publishable repo content, large scale cleanup, migration and fixing, all ongoing for the foreseeable future.
 - Great work towards content rendering (e.g. website, initial PDFs) in progress @spier @dizquerdo (https://innersourcecommons.gitbook.io/innersource-patterns-staging/v/book/)
-- Conference activity, more, interesting pattern activity on Slack leading to new patterns 
+- Conference activity, more, interesting pattern activity on Slack leading to new patterns
 - Patterns office-hours concept try out, some success, dual time-zone meeting concept successfully in use in marketing wg
 
 ### Pattern-work

meta/boardreports/2020-11.md

@@ -17,7 +17,7 @@
 
 - 1 new contributor in the reporting period (@WillemJiang)
 - Challenges:
-  - PRs with minor changes stay open for extended periods. This prevents quick incremental quality improvements. This might also demotivate contributors, as giving them a sense of success would be a way to keep them engaged in the project. Examples: [#213](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/213), [#222](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/222), [#230](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/230), [#232](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/232) 
+  - PRs with minor changes stay open for extended periods. This prevents quick incremental quality improvements. This might also demotivate contributors, as giving them a sense of success would be a way to keep them engaged in the project. Examples: [#213](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/213), [#222](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/222), [#230](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/230), [#232](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/232)
   - Also the longer a PR stays open, the higher the chances that that PR will go stale i.e. the author does not have time anymore to see the PR through. Examples of said risk are [13 PRs](https://github.com/InnerSourceCommons/InnerSourcePatterns/pulls?q=is%3Apr+is%3Aopen+created%3A%3C2020) that have been created prior to 2020, many even in 2017. Bringing these PRs to a stage where they can either be discontinued (i.e. closed) or approved+merged has proven difficult.
 - Activity and trusted committer diversity is too low to sustain the project in the long run on a high activity level. (Low activity evolution is sustainable.)
 

meta/boardreports/2020-12.md

@@ -17,7 +17,7 @@
 
 - 2 new and new-ish contributors in the reporting period ([@WillemJiang](https://github.com/WillemJiang), [@MelindaMalmgren](https://github.com/MelindaMalmgren))
 - Challenges: (same as in the [last report](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/meta/boardreports/2020-11.md#projectcommunity-status-and-health))
-  - PRs with minor changes stay open for extended periods. This prevents quick incremental quality improvements. This might also demotivate contributors, as giving them a sense of success would be a way to keep them engaged in the project. Examples: [#213](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/213), [#222](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/222), [#230](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/230), [#232](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/232) 
+  - PRs with minor changes stay open for extended periods. This prevents quick incremental quality improvements. This might also demotivate contributors, as giving them a sense of success would be a way to keep them engaged in the project. Examples: [#213](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/213), [#222](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/222), [#230](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/230), [#232](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/232)
   - Also the longer a PR stays open, the higher the chances that that PR will go stale i.e. the author does not have time anymore to see the PR through. Examples of said risk are [13 PRs](https://github.com/InnerSourceCommons/InnerSourcePatterns/pulls?q=is%3Apr+is%3Aopen+created%3A%3C2020) that have been created prior to 2020, many even in 2017. Bringing these PRs to a stage where they can either be discontinued (i.e. closed) or approved+merged has proven difficult.
 - Activity and trusted committer diversity is too low to sustain the project in the long run on a high activity level. (Low activity evolution is sustainable.)
 

meta/contributor-handbook.md

@@ -14,7 +14,7 @@ We have defined three maturity levels for patterns: The higher a pattern's matur
 | 2 | Structured | Contains a complete pattern that it is not properly validated yet (e.g. because it only synthesizes an idea or the experiences from one instead of three organizations). | A few days / weeks |
 | 3 | Validated | The pattern is validated (e.g. because three or more instances exists and are synthesized by the pattern) and its writing is of high quality. | A few months |
 
-For the first pattern you contribute, you should aim for maturity levels `1: Initial` or `2: Structured`. 
+For the first pattern you contribute, you should aim for maturity levels `1: Initial` or `2: Structured`.
 
 If you want to help promoting a pattern one maturity level up, we suggest to first create an issue to discuss the matter and see if someone else is working on that already. After that, you can create a pull request with the necessary changes.
 
@@ -27,26 +27,26 @@ Patterns (or other documents) of level 1 are stored in the directory `/patterns/
 
 - Validation requirements:
   - N/A
- 
+
 - Content requirements:
   - The document is readible & comprehensible for other parties (not just for the author(s))
   - The author(s) contribute the contents according to the [license](../LICENSE.txt) & are allowed to do so
   - Thoughts and contents by third parties are quoted / referenced explicitly
 
- 
+
 ### Requirements: Level 2 - Structured
 
 Patterns of level 2 are stored in the directory `/patterns/2-structured`.
 
 - Validation requirements:
-  - Is validated by at least one known instance 
+  - Is validated by at least one known instance
     - Alternatively: key elements of the pattern have been validated in separate contexts and, in consequence, it is justified to believe the full solution will function
- 
+
 - Content requirements:
   - Complies with the [patterns format](pattern-template.md)
   - Complies with *basic style guide*(#) - *Oops! We have not yet developed this*
- 
- 
+
+
 ### Requirements: Level 3 - Validated
 
 Patterns of level 3 are stored in the directory `/patterns/3-validated`.
@@ -55,7 +55,7 @@ Patterns of level 3 are stored in the directory `/patterns/3-validated`.
   - Is validated by at least three known instances
   - Considers all known instances to the best of working group members' knowledge
   - Community agreement (via lazy consensus of trusted committers) on correctness of contents
- 
+
 - Content requirements:
   - Uses & has no conflicts with working group terminology (defined by glossary / implicit usage) - *Oops! We have not yet developed this.*
   - Fits & has no conflicts with existing patterns (of this maturity level or higher)

meta/innersource-spelling.md

@@ -10,7 +10,7 @@ We encourage you to use the word as a proper noun (like “We use InnerSource in
 
 We favor the spelling **InnerSource**, for the following reasons:
 
-1. That’s the way Tim O’Reilly [spelled it in 2000][opengl_1200] (he was into Perl and camel-case was a thing). Also see the [Foreword of the Adopting InnerSource book][foreword_AdoptingInnerSource] for more of Tim O’Reilly's own words on the topic. 
+1. That’s the way Tim O’Reilly [spelled it in 2000][opengl_1200] (he was into Perl and camel-case was a thing). Also see the [Foreword of the Adopting InnerSource book][foreword_AdoptingInnerSource] for more of Tim O’Reilly's own words on the topic.
 2. If you set up side-by-side Google searches for “Inner Source” and “InnerSource” you will find that you get more hits on the former term, by only 1% of them have anything to do with what we call InnerSource. The latter term will be 100% cogent to your inquiry.
 3. The OSI was [denied trademark on the term “open source”][no-open-source-trademark] because it was made up of two common and unrelated terms. “InnerSource” on the other hand is a new word.
 

meta/pattern-system.md

@@ -1,8 +1,8 @@
-# InnerSource Pattern System 
+# InnerSource Pattern System
 
 ## About
 
-This document shall serve to define a system with which we organize our 
+This document shall serve to define a system with which we organize our
 patterns using a limited set of classifications.
 
 ## Related Work
@@ -12,14 +12,14 @@ patterns using a limited set of classifications.
 From the Authors of the classic GoF book "Design Patterns":
 
 > Design patterns vary in their granularity and level of abstraction. Because
-> there are many design patterns, we need a way to organize them. 
+> there are many design patterns, we need a way to organize them.
 
 They classify patterns so that they "can refer to families of related patterns."
 The authors also suspect that this classification will make "learning the
 catalog" faster. They Classify patterns according to two criteria: Purpose and
 Scope. They introduce the following classes of purpose in their book:
 
-- Creational, 
+- Creational,
 - Structural and
 - Behavioral.
 
@@ -47,14 +47,14 @@ The second criterion categorizes the problems solved by the patterns:
 
 - _From Mud to Structure_,
 - _Distributed Systems_,
-- _Interactive Systems_, 
+- _Interactive Systems_,
 - _Adaptable Systems_,
 - _Structural Decomposition_,
-- ... 
+- ...
 
 you get the point.
 
-In addition to this, he postulates a number of properties, a pattern system 
+In addition to this, he postulates a number of properties, a pattern system
 must exhibit. According to Buschmann, a pattern system
 
 - should be simple and easy to learn,
@@ -84,17 +84,17 @@ PLoP 2016](http://www.hillside.net/plop/2016/papers/three/26.3.pdf).
 
 ## Candiate Classifications
 
-This section shall serve to collect individual proposals for systems of ISC 
+This section shall serve to collect individual proposals for systems of ISC
 patterns. Contribute away ;)
 
 ### Georg Grütter
 
 I propose we use a classification of the problem, a pattern tries to solve as
-the main criteria for organizing our list of patterns. The following 
+the main criteria for organizing our list of patterns. The following
 classifications come to mind:
 
-- 1. Getting started with InnerSource 
-- 2. Getting sustainable middle management buy-in and support 
+- 1. Getting started with InnerSource
+- 2. Getting sustainable middle management buy-in and support
 - 3. Getting buy-in of developers
 - 4. Fostering contributions
 - 5. Interfacing with traditional, non-InnerSource projects

patterns/1-initial/developer-incentive-alignment-for-innersource-contribution.md

@@ -22,7 +22,7 @@ TBD
 * The organization wants to create more alignment between work efforts and external motivation without relying directly on financial rewards or quotas.  
 * The organization is comfortable with a personnel management and/or professional development style that is organic or “bottom-up” as opposed to traditional training or development programs run through HR (even as task management or velocity is managed in a more top-down fashion).
 
-## Forces   
+## Forces
 
 1. Existing attitudes and developer culture
  * Team-centric behaviour is not evident. Developers of all levels tend to focus mostly on their own contributions. When stories are assigned, work is often done ‘locally’ and not pushed up or checked in until the end of the sprint.
@@ -52,9 +52,9 @@ TBD
 * Moving up the ladder requires taking on more responsibility for mentoring, reviewing code, and bringing in contributions
 * Developers may choose not to move up the ladder because of a preference for certain types of contributions ("I like just writing code" vs "I want to have a bigger impact on the team")
 * relevant Skills & experience are associated with advancing titles/roles - Moving up the ladder also requires developing the social skills necessary for mentorship
-* Job Descriptions/Roles can be easily associated/assimilated into employee review systems or other HR programs (comp/bonus structures, etc)     
+* Job Descriptions/Roles can be easily associated/assimilated into employee review systems or other HR programs (comp/bonus structures, etc)
 
-## Resulting Context    
+## Resulting Context
 
 * culture has been shifted from contribution culture to learning culture
 * devs & pms believe time spent mentoring and reviewing is equally, if not more so, valuable to time spent coding
@@ -73,6 +73,6 @@ Unproven
 
 Old status: brainstormed solution
 
-## Author   
+## Author
 
 Jory Burson

patterns/1-initial/introducing-metrics-in-innersource.md

@@ -29,7 +29,7 @@ If there's a change in the C-level, metrics might be helpful to convince them th
 
 People do not like to be tracked or measured.
 
-There is no canonical monitoring infrastructure for the software development process. Furthermore, such infrastructure is hard to build 
+There is no canonical monitoring infrastructure for the software development process. Furthermore, such infrastructure is hard to build
 or to get funding for.
 
 There is not a culture of software development metrics.