fix: MD022 space around heading

Author: nschonni

.markdownlint.json

@@ -4,7 +4,6 @@
     "MD007": false,
     "MD013": false,
     "MD014": false,
-    "MD022": false,
     "MD024": false,
     "MD025": false,
     "MD026": false,

meta/FAQ.md

@@ -1,14 +1,18 @@
 This is a list of frequently asked questions about InnerSource Patterns
 
 ## What are the different parts of a pattern? What do they mean?
+
 * See the [pattern template](pattern-template.md) (in the *meta* subdirectory)
 
 ## Why use a patterns approach to InnerSource?
+
 * It abstracts information from known instances of proven solutions so that other people/companies can understand not only what was done by why it worked and how to adapt it to their own situations.
 
 ## How do you use the pattern?
+
 * Each organization has its own history (*context*) and culture (a source of *forces*) and even goals, so using a pattern to solve their problems will generally require adaptation of that pattern. Try to identify things about your situation that are unique and apply those as makes sense to the *Context* and *Forces* identified in the pattern. See if these additional constraints might require changes to the *Solution* to ensure that the pattern will work.
 * Patterns can also be used as a short-hand when discussing InnerSource programs across organizational boundaries.
 
 ## I'd like to consult with the IS Patterns community; do I need to have participating members sign NDAs?
+
 * You could do that, but be aware that the vast majority of IS Patterns meetings are held under the [Chatham House Rule](https://www.chathamhouse.org/chatham-house-rule) that should provide sufficient protection to enable a productive discussion.

meta/pattern-template.md

@@ -1,50 +1,65 @@
 ## Title
+
 Short Title Here
 
 ## Patlet
+
 Concise 1-2 sentence description of the problem and solution. Readers may quickly review dozens of these patlets to discover and browse the larger library of patterns. From http://wiki.c2.com/?PatLet
 
 ## Problem
+
 What is the problem - crisp definition of the problem. Short description, usually not more than a couple sentences, that describes what the issues and challenges are. Be careful not to morph into information found in other sections below.
 
 ## Story (optional)
+
 Sometimes there is a story that helps people understand the pattern better.
 
 ## Context
+
 Where does the problem exist? What are the pre-conditions? **Unchangeable** before the solution goes into place. The content here is often tied to the applicability of the pattern for other readers: "Do I have this same particular situation?"
 
 ## Forces
+
 What makes the problem difficult? What are the trade-offs? These are constraints that **can be changed** at a cost. The solution might change one or more of these forces in order to solve the problem, while also in-turn changing the context.
 
 ## Sketch (optional)
+
 visual illustration
 
 ## Solutions
+
 Verified resolutions and possible resolutions to the problem.
 
 ## Resulting Context
+
 What is the situation after the problem has been solved? The original context is changed indirectly by way of the solution. Often this section can include discussion of the next possible Patterns/problems introduced. This section can be short in content - the solution may not introduce new problems or change much context.
 
 ## Rationale (optional)
+
 Explains why this is the right solution; using totally different words WHY this solution balances these forces and this context to solve this problem. Can expand on what-if's or theories.
 
 ## Known Instances (optional)
+
 Where has this been seen before? Helps to reinforce that this is a REAL pattern and that you match the context.
 
 May mention:
 * A particular business
 * Anonymized instances ex: "3 companies have proven that this is a good solution" or "A large financial services org...".
 
 ## Status (optional until merging)
+
 General pattern status is stored in GitHub's Label tagging - see any pull request. Note that this GitHub label tagging becomes less visible once the pattern is finalized and merged, so having some information in this field is helpful.
 
 You might store other related info here, such as review history: "Three of us reviewed this on 2/5/17 and it needs John's expertise before it can go further."
 
 ## Author(s) (optional)
+
 Often, this is yourself; If you need to, find someone in the InnerSource Commons to be the nominal author (As Told To); Could also be no-one if you do not want to take on authorship (common with a donut looking for a solution)
 
 ## Acknowledgements (optional)
+
 Include those who assisted in helping with this pattern - both for attribution and for possible future follow up. Though optional, most patterns should list who helped in their creation.
 
 ## Alias (optional)
+
 If this pattern is also known under a different name than what is listed unter **Title**, please list those alternative titles here. e.g. if the pattern is named after the problem it solves, a helpful alias might be one that describes the solution that is applied.

pattern-categorization/innersource-program-mind-map.md

@@ -1,47 +1,91 @@
 # [InnerSource Program](https://innersourcecommons.gitbook.io/innersource-patterns/v/book/toc)
+
 ## Begin
+
 ### [Start as an Experiment](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/start-as-experiment.md)
+
 ### [Dedicated Community Manager](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/dedicated-community-leader.md)
+
 ### Project Setup
+
 #### [Standard Base Documentation](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/project-setup/base-documentation.md)
+
 #### [Communication Tooling](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/project-setup/communication-tooling.md)
+
 #### [Issue Tracker Use Cases](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/project-setup/issue-tracker.md)
 
 ## Adoption
+
 ### Valuation Challenges
+
 #### How to measure a project's business value
+
 ##### [Cross-Team Project Valuation](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/crossteam-project-valuation.md)
+
 ### Cultural Challenges
+
 #### Unrecognized effort
+
 ##### [Praise Participants](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/praise-participants.md)
+
 ##### [Trusted Committer](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/trusted-committer.md)
+
 ### Technical Challenges
+
 #### Not meeting everyone's needs
+
 ##### [Common Requirements](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/common-requirements.md)
+
 #### Fear of shared support responsibility
+
 ##### [Service vs. Library](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/service-vs-library.md)
+
 ### Organizational Challenges
+
 #### Discouragement of contributing resource
+
 ##### [Contracted Contributor](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/contracted-contributor.md)
+
 #### Rejection of accepting contribution
+
 ##### [30 Day Warranty](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/30-day-warranty.md)
+
 #### Radical change of management
+
 ##### [Review Committee](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/review-committee.md)
+
 #### Fear of shared support responsibility
+
 ##### [Service vs. Library](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/service-vs-library.md)
+
 #### Not enough maintainers to scale
+
 ##### [Trusted Committer](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/trusted-committer.md)
+
 ### Cross Legal Entities Challenges
+
 #### Concern on legal liabilities or cross-company accounting
+
 ##### [InnerSource License](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/innersource-license.md)
+
 ## Grow
+
 ### Discovery Challenges
+
 #### Can't find matching projects
+
 ##### [Gig Marketplace](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/gig-marketplace.md)
+
 ##### [InnerSource Portal](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/innersource-portal.md)
+
 #### Difficult to find active projects
+
 ##### [Repository Activity Score](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/repository-activity-score.md)
+
 ## Scale
+
 ### Self Education/Improvement Challenges
+
 #### Not aware of InnerSource best practices
+
 ##### [Maturity Model](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/maturity-model.md)

patterns/1-initial/code-consumers.md

@@ -3,9 +3,11 @@
 Code Consumers
 
 # Patlet
+
 TBD
 
 # Problem
+
 There's several reasons why we might want to know who's using (consuming) our code. We can't do the following:
 * notify downstream users/projects of found (fixed?) vulnerabilities
 * audit flow of IP
@@ -14,15 +16,18 @@ There's several reasons why we might want to know who's using (consuming) our co
 * survey users for feedback
 
 # Context
+
 This is a general issue that affects potentially all InnerSource (and open source!) projects.
 The act of opening code allows people to use it without letting you know.
 
 # Forces
+
 * The harder it is to download/integrate the project, the less it will be adopted (forcing people to give information when they use it adds barriers)
 * Not all projects may want you to know what they're using (tightly closed source/top secret downstream project)
 * Putting in callback/call home routines into projects may introduce distrust in downstream projects and users
 
 # Solutions
+
 The following are potential solutions that have been proposed to this problem:
 * Scan all output artifacts for known signatures (manifests/npm/includes etc)
 * Voluntary disclosure/signup upon installation/using
@@ -31,15 +36,19 @@ The following are potential solutions that have been proposed to this problem:
 * Incentivise/Offer users a mailing list/update stream to which they can subscribe
 
 # Resulting Context
+
 _needs work..?_
 
 # Known Instances
+
 _needs work...?_
 
 # Authors
+
 * Georg Grütter (Robert Bosch GmbH)
 * Raimund Hook (EXFO Inc)
 * Katrina Novakovic (RedHat)
 
 # Status
+
 Drafted at the 2019 Spring InnerSource Commons Summit in Galway - 10 April 2019

patterns/1-initial/discover-your-innersource.md

@@ -1,17 +1,21 @@
 ## Title
+
 Discover Your InnerSource
 
 ## Also Known As
+
 * Not looking for stuff internally
 * Don't bother looking
 * Find it Inside
 
 ## Context
+
 * Software component(s) are available internally but users can't easily find these.
 * This problem is more likely to occur in large, federated companies where different organizational units operate as silos.
 * Historically, the company does not have a culture of sharing code across silos.
 
 ## Discussion on
+
 * Comments may appear in the timeline but not with the file once it is edited (github)?
 * https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/60
 * If only X knew what X knew; the internal search engine is bad. No one can find anything because it is difficult to add things  to the search index.
@@ -22,9 +26,11 @@ Discover Your InnerSource
 * The company traditionally has been bad at sharing across silos (people don't have the culture of sharing).
 
 ## Problem
+
 People don't bother looking for internally developed solutions - they might not find the repo at all or be aware of its existence.
 
 ## Forces
+
 * No good internal search engine (or not connected to git repositories; and difficult to make this change happen)
 * Users may not know there are common places to find internally developed solutions.
 * People don't expect to find solutions internally.
@@ -35,6 +41,7 @@ People don't bother looking for internally developed solutions - they might not
     - if someone put out a SW internally, the expectation is that they wouldn't have time to support it (vs. open source options)
 
 ## Solution
+
 Make it easy to find the reusable code.
 
 * Pull in Repo names, descriptions and README.md files into the search engine assuming that a search engine exists. Note: a one-stop-shop kind of search engine for all relevant communication and documentation is difficult to attain. Even when using Github's enterprise offering, people often deploy additional systems like wikis to host content orthogonal to what is in the code repositories, slack channels (or IRC), mailing lists (or even nntp servers), some place to store stuff written down in office formats, search over personal e-mail etc. Several of these systems come with search built-in, but integrating this content in one search box or even just deploying a federated search engine across all sources often doesn't come off-the-shelf.
@@ -49,6 +56,7 @@ Make it easy to find the reusable code.
 ## Known instances
 
 ## Resulting Context
+
 * Internal components are easily visible
 * Developers looking for code can search for it and find it quickly.
 * Developers are now looking internally for software components
@@ -57,13 +65,16 @@ Make it easy to find the reusable code.
 * See [Improved Findability](improve-findability.md) (aka Poor Naming Conventions or Badly Named Piles) as a related pattern.
 
 ## Status
+
 Brainstormed pattern idea in progress
 
 ## Authors
+
 * Georg Grutter
 * Erin Bank
 * Padma Sudarsan
 * Tim Yao
 
 ## Acknowledgements
+
 * Contributions from Russ Rutledge, Ofer Hermoni and Robert Hanmer

patterns/1-initial/junkyard-styled-innersourcing.md

@@ -1,17 +1,21 @@
 ## Title
+
 * Junkyard styled inner sourcing
 * Finding but deciding not to use the internal component
 
 ## Context
+
 Two situations:
 
 * SW component not designed for reuse because the schedule was too tight and did not allow for the extra effort needed
 * Did not have the knowledge or training to create components that can b reused.
 
 ## Problem
+
 * How do you encourage people to share whatever code they write?
 
 ## Forces
+
 * People don't share something so others can use it; they only share it for the sake of sharing. They wouldn't mind if no one uses it (a bit of a graveyard: "InnerSource is where modules go to die")
 * A developer might be a person who likes to share their code; one that likes others to read it (and maybe comment on it. But mostly they like to write code. "Hey, I wrote this nifty gzorp and you might like it (but its no skin off my nose if you don't)"
 * the code is crap
@@ -21,13 +25,16 @@ Two situations:
 * How do we politely take their freely offered code and harden it or otherwise prepare it for production without having the original contributor feel like we are saying their code is crap?
 
 ## Solution
+
 * Support all contributions to the shared repository.
 * Provide some sort of grading (Alexander marked his patterns with 0, 1 or 2 stars depending upon how convinced he was that it was a good pattern), so that the reader can be aware of what to expect. But how to do that without insulting the contributor? (solution: engage them in the process -- have 2 scores, what they think, and what users think or how many times its been used)
 
 ## Status
+
 Brainstormed pattern idea in progress
 
 ## Authors
+
 * Georg Grutter
 * Erin Bank
 * Padma Sudarsan

patterns/2-structured/common-requirements.md

@@ -1,16 +1,21 @@
 ## Title
+
 Common Requirements
 
 ## Patlet
+
 Common code in a shared repository isn't meeting the needs of all the project-teams that want to use it; this is solved through requirements alignment and refactoring.
 
 ## Problem
+
 The common code in the shared repository isn't meeting the needs of all the projects that want to use it.  
 
 ## Context
+
 Many projects are trying to use common code.  There is a shared repository that all the projects access.  This pattern applies if there is a Strong Code Owner [pattern to be written] or if there is weak code ownership, or no Benevolent Sponsor [pattern to be written]. Someone (or some project) wrote the code in the first place and contributed it to the repository. The common code is a small percentage of the overall deliverable from any of the projects.  Each project has its own delivery schedule, set of deliverables and customers.
 
 ## Forces
+
 The project that made the code available has one set of needs. Its needs are similar to what some of the receiving organization wants, but not quite the same.
 Requirements on code should be derivable from real customer needs.  
 
@@ -20,6 +25,7 @@ Many customers want the supplier to help them know what they need. The company h
 Reusing code is an important goal to save the company time and money.  
 
 ## Solution
+
 There are two aspects to solving this problem which should be done in parallel:
 - Align the requirements of the projects so that the code that meets the requirements for one project also meets the needs for the other projects.
 - Refactor the code into smaller pieces for which the many using projects can agree upon requirements.
@@ -31,6 +37,7 @@ In the example presented above, the supplier helps both customers realize that t
 <img alt="Common Requirements" src="/assets/img/CommonReqtsv2.jpg">
 
 ## Resulting Context
+
 This might require negotiating requirements changes with the customer.  The changes might also require involvement by the sales teams and product managers to get alignment on the requirements.  The customer might need incentives, such as discounts, to agree to the changes.
 
 A related pattern (to be written) is a circular story-writing exercise reported at one company employing Inner Sourcing.  
@@ -39,8 +46,10 @@ The developers write a story to solve a problem in one way.
 The program managers rewrite the story to better express their needs---keeping the essence the same. By the time it returns to developers though they don't recognize it as what they wanted to do in the first place and so balk at implementing it.  The solution to this pattern is to have more seats around the planning table so that story modifications are understood across the project not just in the developer or program manager camps.
 
 ## Status
+
 * Structured
 * Old status: Proven
 
 ## Author
+
 Robert Hanmer, 22 Aug 2016, 20 Sept 2016  

patterns/2-structured/contracted-contributor.md

@@ -3,6 +3,7 @@
 Contracted Contributor
 
 ## Patlet
+
 Associates wanting to contribute to InnerSource are discouraged from doing so by their line management. Relief is provided by formal contracts and agreements.
 
 ## Problem