Adapting heading level in these patterns to h2 (##)

Author: spier

patterns/1-initial/balancing-openness-and-security.md

@@ -1,4 +1,4 @@
-# Title
+## Title
 
 Balancing Openness and Security
 
@@ -7,41 +7,41 @@ Balancing Openness and Security
 While InnerSource flourishes in environments with a high degree of shared code, Security/Legal prefers the limitation of source code access to only those that need it.
 By making Security/Legal part of the team, introducing explicit sharing levels and security policies for shared repositories, as well as defining what qualifies as sensitive information, code sharing can be facilitated while minimizing the associated risks.
 
-# Problem
+## Problem
 
 A successful InnerSource program needs openness and transparency (e.g. access to code, issues, documentation, and roadmap), while good security practice is to minimize access, following the [principle of least privilege][principle-of-least-privilege]. How to balance and address these seemingly contradicting requirements?
 
-# Story
+## Story
 
 Most organizations developing proprietary software will have source code that they do not want to leave the organization, as this may harm their business. Think what would happen when the major competitors would have access to their latest features and would know what they are working on next.
 
 Even when the source code management system is not compromised from the outside, malicious employees or interns could leak code to the competition. Or think about gaining access to sensitive systems and services using credentials that are hard-coded in source code. Or injection of malicious code into a product’s codebase.
 
 Restricting access typically reduces the risk of these things from happening, but at the same time hampers collaboration and re-use.
 
-# Context
+## Context
 
 - The organization has an InnerSource Program Office (ISPO), or a similar group, steering the success of the InnerSource initiative in the organization. One of their goals is to stimulate maximum openness and transparency in the organization.
 - The organization has a Security Team constraining unnecessary data access to prevent the organization from data-leakage and malicious code injection.
 - The Security Team, ISPO, and Engineering teams are not regularly talking with each other.
 - "Closed Source" is the default in the organization when creating new repositories, i.e. only the team owning/maintaining the code has access to the given repo.
 - "Shared Source" within the organization isn’t common practice. Organizational teams aren’t familiar with what code or information should or shouldn’t be placed in shared repositories.
 
-# Forces
+## Forces
 
 - A successful InnerSource program needs openness and transparency (e.g. access to code, issues, documentation, and roadmap)
 - Good security practice is to minimize access, following the [principle of least privilege][principle-of-least-privilege].
 - The Security Team is more familiar with security principles at conceptual level than security practices at operation level. Some of the security policy is good at concept but hard to execute at operation level.
 - Engineering Teams focus more on service/product development or knowledge sharing than on measures for data protection. While it is easy for Engineering Teams to decide to close or open the repository, they are usually not willing to spend time on judging how to reach a balance between both. Or to refactor their code in order to be able to share more.
 - No one-fit-all guideline or rules to judge what data or process is to be secured or not. That much depends on data sensitivity and overall security policy/infrastructure.
 
-# Solutions
+## Solutions
 
 To reduce the misalignment and possible misunderstanding between the teams involved, it is key to bring everybody together so that they can express their goals and concerns, and develop shared language together.
 
 After that they can decide as a group how to drive the execution of the specific goals, and what to do to reduce the risks that were identified.
 
-## Setup
+### Setup
 
 Start by bringing (representatives from) Engineering, Security, Legal, and the ISPO together, to discuss the goals of the InnerSource initiative, as well as any security concerns.
 
@@ -55,13 +55,13 @@ Some helpful practices are:
     - **SHARED** - inner source: accessible for all software developers in the organization
     - **CLOSED** - closed source: only accessible to named individuals in the organization
 
-## Execution
+### Execution
 
 How to allow for a greater amount of SHARED code in the organizations depends a lot on the specific business domain, related regulations, and concerns identified in the initial meetings of the InnerSource task force as mentioned above.
 
 Following are some practices that have proven to be helpful in reducing security concerns and allowing for a greater amount of SHARED code.
 
-### Security Training and SCM Setup
+#### Security Training and SCM Setup
 
 - Employee training about security awareness and individual responsibility
 - Enhanced security measures or policies on source code management (SCM) system to prevent malicious access to shared repositories and reduce the impact of the same:
@@ -76,12 +76,12 @@ Following are some practices that have proven to be helpful in reducing security
     - downloading source code from new devices
     - downloading a great amount of source code in the monitoring period.
 
-### Split out the 'secret sauce' into separate repos
+#### Split out the 'secret sauce' into separate repos
 
 Separate highly specific, differentiating code (the 'secret sauce') from code that is considered commodity in the organization (e.g. infrastructure, platform, and UI components).
 By placing them in separate repositories, you increase your chances of offering the commodity code as SHARED repos, while the 'secret sauce' may stay CLOSED.
 
-### Prevent sensitive information in shared repositories
+#### Prevent sensitive information in shared repositories
 
 Build up agreed security requirement of InnerSource, such as:
 
@@ -92,7 +92,7 @@ Build up agreed security requirement of InnerSource, such as:
 - Leverage secrets scanning tools to scan the target repositories (including code, test cases, and helper scripts) for confidential data such as accounts, passwords, access tokens, keys, and other sensitive data.
 - Keep repositories CLOSED, but expose metadata about the projects (i.e. through an [InnerSource Portal][innersource-portal]), and create some kind of access request workflow. This way you could still give people access to the code, but not open it to everyone by default. *(Note: The full model is described under **Extension: An Additional Sharing Level**)*
 
-### Extension: An Additional Sharing Level
+#### Extension: An Additional Sharing Level
 
 In some cases, introducing additional sharing levels might be appropriate. Use cases include:
 
@@ -118,7 +118,7 @@ Repositories with RESTRICTED sharing level are included in the [central catalog]
 - RESTRICTED repos will likely get fewer contributions due to the additional step to access the code. Where possible, INTERNAL repos should be preferred.
 - It is possible to use a tool that automatically adds the `README.md` and some other metadata to an internal repository in GitHub, allowing the GitHub search feature to include this data in the search results.
 
-# Sketch
+## Sketch
 
 ```
 Example Repository Sharing Levels
@@ -137,7 +137,7 @@ Example Repository Sharing Levels
 └──────┘
 ```
 
-# Resulting Context
+## Resulting Context
 
 InnerSource adoption in an organization will often [start as an experiment][start-as-an-experiment], with a small number of SHARED repositories.
 
@@ -149,32 +149,32 @@ With the increased confidence and lessons learned from this experiment, the task
 
 Most importantly, the changes implemented through this pattern lead to more code being shared between teams, and closed source will no longer be the obvious default.
 
-# Known Instances
+## Known Instances
 
 * Philips
 * Verizon
 
-# Status
+## Status
 
 - Initial
 
-# Authors
+## Authors
 
 - Bart Golsteijn
 - Jack Yang
 - Sebastian Spier
 
-# Acknowledgements
+## Acknowledgements
 
 - Conley Rogers
 
-# Alias
+## Alias
 
 - Secure Discoverability
 - Secure Code Sharing
 - Secure InnerSource
 
-# Notes (internal)
+## Notes (internal)
 
 *These notes are meant for internal use within the InnerSource Commons Patterns Working Group only.*
 

patterns/1-initial/code-consumers.md

@@ -1,12 +1,12 @@
-# Title
+## Title
 
 Code Consumers
 
 ## Patlet
 
 When a team opens their code for InnerSource reuse, they lose visibility into who is consuming it, making it hard to communicate vulnerabilities, gauge adoption, or retire deprecated components. Lightweight mechanisms such as dependency scanning, voluntary registration, or opt-in mailing lists restore that visibility without adding friction for consumers.
 
-# Problem
+## Problem
 
 There's several reasons why we might want to know who's using (consuming) our code. We can't do the following:
 
@@ -16,18 +16,18 @@ There's several reasons why we might want to know who's using (consuming) our co
 * encourage others to use a project - by showing how many users there already are
 * survey users for feedback
 
-# Context
+## 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
+## 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
+## Solutions
 
 The following are potential solutions that have been proposed to this problem:
 
@@ -37,21 +37,21 @@ The following are potential solutions that have been proposed to this problem:
 * Audit code clones/artifact downloads
 * Incentivise/Offer users a mailing list/update stream to which they can subscribe
 
-# Resulting Context
+## Resulting Context
 
 TBD
 
-# Known Instances
+## Known Instances
 
 TBD
 
-# Authors
+## Authors
 
 * Georg Grütter (Robert Bosch GmbH)
 * Raimund Hook (EXFO Inc)
 * Katrina Novakovic (RedHat)
 
-# Status
+## Status
 
 * Initial
 * Drafted at the 2019 Spring InnerSource Commons Summit in Galway - 10 April 2019

patterns/1-initial/explicit-shared-ownership.md

@@ -1,28 +1,28 @@
-# Title
+## Title
 
 Explicit Shared Ownership
 
 ## Patlet
 
 A software component that several teams depend on has grown to the point where owners are no longer capable of taking full ownership. There is confusion who to involve for changes. Sharing ownership explicitly and making expected behavior visible removes ambiguity. Writing a contributions document creates a natural way to evolve ownership.
 
-# Problem
+## Problem
 
 An organization is already using InnerSource best practices in several teams. The architecture of the software offered has grown organically.
 
 While talking about code ownership and accountability, teams notice that there is a component that is in a worrying state: Developed by an original team of authors it has grown it's userbase way beyond what the original team can handle. From time to time others step up to help out, however there is no formal process established. As a result, conflicts arise around who should do the work, and who should decide on project direction.
 
 Simply forking the component would lead to a lot of duplication and wasted effort. Therefore the involved teams are looking for a less intrusive solution to the issue.
 
-# Context
+## Context
 
 - Teams are working independently but are providing one common platform as a service.
 
 - The software they are working on has been evolving for a long time. Engineers working on sub-modules have changed over time.
 
 - One component is in widespread use but ownership is unclear.
 
-# Forces
+## Forces
 
 - Ownership of one component is unclear.
 
@@ -31,13 +31,13 @@ Simply forking the component would lead to a lot of duplication and wasted effor
 - There may be people dependent on the module that are not yet known.
 There often is fear around maintenance efforts arising from unwanted attribution to the project.
 
-# Solution
+## Solution
 
 Use the issue/ pull-request mechanics that work so well for code modifications to modify the way the component is developed:
 
 A volunteer creates an issue in the component's repository highlighting the apparent unclarity or even lack of ownership. Subsequently a volunteer (can be the same person) creates a suggestion for how the project should be developed going forward including a proposed list of initial [Trusted Committers](../2-structured/trusted-committer.md). This suggestion is posted to the project's documentation (e.g. it's `README.md` file) as a pull request. This pull request is left open and shared with all people affected by the change. Feedback can be given and integrated asynchronously. Development of the final state is transparent for everyone.
 
-# Resulting Context
+## Resulting Context
 
 There is an initial team of [Trusted Committers](../2-structured/trusted-committer.md) committed to the component.
 
@@ -47,7 +47,7 @@ The entire decision process backing the result is transparent and can be influen
 
 There is a proven way to adjust the setup in the future.
 
-# Status
+## Status
 
 Initial (early draft)