fix: MD032 space around lists

Author: nschonni

.markdownlint.json

@@ -9,7 +9,6 @@
     "MD026": false,
     "MD029": false,
     "MD030": false,
-    "MD032": false,
     "MD033": false,
     "MD034": false,
     "MD036": false,

README.md

@@ -11,6 +11,7 @@ You are already using InnerSource in your company and want to share your ideas a
 ## Mission Statement
 
 Our mission in this working group
+
 - Collect and document agreed upon best practices of how to do InnerSource - in the form of patterns
 - Continuously publish the most mature patterns as an ebook
 

meta/pattern-system.md

@@ -79,6 +79,7 @@ our InnerSource pattern system.
 Takashi Iba has published an article in the ACM Digital Library from PLoP 2016:
 [A pattern language for creating pattern languages: 364 patterns for pattern
 mining, writing, and symbolizing](https://dl.acm.org/citation.cfm?id=3158175&CFID=831673585&CFTOKEN=74341142&qualifier=LU1011674)
+
 - for those without ACM DL access, there is [an earlier draft of the paper from
 PLoP 2016](http://www.hillside.net/plop/2016/papers/three/26.3.pdf).
 
@@ -242,6 +243,7 @@ potential characterization based on the companies structure?
 ### Russ Rutledge
 
 I like a lot of the other planes suggestions.  Wanted to add one more - the point in the lifecycle of the InnerSource project.  Does this pattern apply to:
+
 * Pre-launch (prepration to launch) an InnerSource project?
 * Launch (initial kick-off)?
 * Initial growth?

meta/pattern-template.md

@@ -43,6 +43,7 @@ Explains why this is the right solution; using totally different words WHY this
 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...".
 

patterns/1-initial/code-consumers.md

@@ -9,6 +9,7 @@ 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
 * kill off code - knowing where (or if) it is used
@@ -29,6 +30,7 @@ The act of opening code allows people to use it without letting you know.
 # 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
 * Search for identifiers/markers in source control

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

@@ -25,16 +25,19 @@ TBD
 ## 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.
  * Asking developers to push code early and often is met with extreme resistance, accusations of micro-management, or claims that such a practice would slow velocity.
  * Existing practice commonly leads to duplicated work, missed requirements, or frequent gaps in the software or process.
 
 2. Need to retain developer talent
+
  * Managers focus heavily on tasks or velocity for developers rather than providing mentorship. Developers view helping or mentoring others as the job of Management, or something “I don’t get paid to do.” Career progression, or other ‘upward mobility paths’ (to receive a raise, for example) are not clearly identified in the organization.
  * Existing job descriptions, promotion tracks or compensation bands are opaque or hard to get from the organization’s HR department, resulting in a mixed understanding of job responsibilities. This puts additional pressure on performance review or improvement plans because HR, developers and managers don’t have shared a shared understanding of roles or expectations.
  * 'Home growing' developer talent - encouraging career growth within the company - is far cheaper for organizations in the long run than hiring from outside. Studies show employee retention increases as new opportunities, challenges, and paths for learning are introduced.
 
 3. Maintaining the product development lifecycle
+
  * Keeping the status quo is encouraged or reinforced with existing product/project management processes and expectations. Developers and managers are reticent to make changes for fear of putting deadlines or product/business unit goals at risk (note that these often have financial implications for the company and individual). Working on one’s own individual contributions is seen as doing one’s part to protect this lifecycle; efforts outside one’s own individual contributions is seen as disruptive.
  * Product/Business unit pressures
  * HR - existing resource allocation plans & patterns

patterns/1-initial/improve-findability.md

@@ -31,6 +31,7 @@ Historically, the company does not have a culture of sharing code across silos.
 ## Solution
 
 To help improve findability for inner source projects:
+
 - Provide guidelines for applying clear, meaningful naming conventions to projects, and reinforce the importance of avoiding cryptic code names.
 - Include keywords in project descriptions.
 - Apply tagging to repositories (validated).

patterns/1-initial/overcome-acquisition-based-silos-developer.md

@@ -38,11 +38,13 @@ Make the acquired teams feel secure in the new environment by
 1. Establish a neutral (well-respected) governance committee _across both companies_ that selects from the different options across these silos to converge and integrate. (_validated_).
 
 2. Come up with rational rules for managing code redundancy as a result of acquisition (_validated_)
+
  - Joint effort between two teams to bring new software into existing platforms. (_validated_)
  - If allowable/controllable, initial software selection not tied to job security. (_not validated_)
  - Same ground rules as above for determining tooling platforms. (_validated_)
 
 3. Giving developers and middle management good on-boarding training and mentoring with InnerSourcing as part of it. (_not validated_)
+
  - Clear guidance on how to bring their software onto existing platform. (_not validated_)
  - Definition of roles including Contributor and Trusted Committer. (_not validated_)
 
@@ -51,6 +53,7 @@ Make the acquired teams feel secure in the new environment by
 5. Give them time to get comfortable with the new environment - a generous, realistic grace period for ramping on new company procedures/processes. Not uncommon for this period to be up to a year but there must be a mutually agreed-to deadline. Being "fully integrated" requires a certain level of representation among Trusted Committers from both companies. (_validated_)
 
 6. Minimum commitment for face to face engagement between the two teams.
+
  - can be representative team from acquiring company meet with team.
  - potential Trusted committers from acquired company can meet with parent company.
 

patterns/1-initial/overcome-acquisition-based-silos-manager.md

@@ -41,11 +41,13 @@ Make the acquired teams feel secure in the new environment by
 1. Establish a neutral (well-respected) governance committee _across both companies_ that selects from the different options across these silos to converge and integrate. (_validated_).
 
 2. Come up with rational rules for managing code redundancy as a result of acquisition (_validated_)
+
  - Joint effort between two teams to bring new software into existing platforms. (_validated_)
  - If allowable/controllable, initial software selection not tied to job security. (_not validated_)
  - Same ground rules as above for determining tooling platforms. (_validated_)
 
 3. Giving developers and middle management good on-boarding training and mentoring with InnerSourcing as part of it. (_not validated_)
+
  - Clear guidance on how to bring their software onto existing platform. (_not validated_)
  - Definition of roles including Contributor and Trusted Committer. (_not validated_)
 
@@ -54,6 +56,7 @@ Make the acquired teams feel secure in the new environment by
 5. Give them time to get comfortable with the new environment - a generous, realistic grace period for ramping on new company procedures/processes. Not uncommon for this period to be up to a year but there must be a mutually agreed-to deadline. Being "fully integrated" requires a certain level of representation among Trusted Committers from both companies. (_validated_)
 
 6. Minimum commitment for face to face engagement between the two teams.
+
  - can be representative team from acquiring company meet with team.
  - potential Trusted committers from acquired company can meet with parent company.
 

patterns/1-initial/overcoming-project-management-time-pressures.md

@@ -19,6 +19,7 @@ Customer deadlines and delivery commitments for feature content do not change.
 - Aggressive roadmaps for delivery
 - Project management concern that engagement will lead to missed deadlines
 - Project management concern that Code contribution and/or mentoring may lead to dilution of subject matter expert time spent on their own projects (other teams may require their time).
+
 + Elimination of rewriting common code saves time (write once, use many times)
 + Crowd-based testing and debugging saves time (and improves quality)
 + The collaboration and synergy of inner sourcing can generate new, innovative features  .