Cleanup overview of patterns in Level 1 (#254)

* Remove the extra group "Reviewed Pattern Ideas (not yet proven but reviewed)".
Also adapt status in the patterns accordingly.

Rational: 
by definition the 1-Initial patterns don't have a Known Instance yet, i.e. they are not proven. Therefore we don't need an extra group to state this.

* Move all patterns that have a patlet already out of the extra group "Pattern Ideas (not yet proven; brainstormed)".
Those pattern are similar in quality to the ones that we already list in "### Maturity Level 1: Initial", so they don't have to be in an extra group.

* Move remaining patterns from sub-group "Pattern Ideas (not yet proven; brainstormed)" to "Maturity Level 1: Initial".
Also updating the Status in the patterens themselves.

Rational:
* These patterns were not all that different from the ones directl in "Maturity Level 1: Initial".
* Often times they don't have a solution yet, or just a brainstormed solution.
* Many of them don't have a Patlet, likely because they were written at a time when the Pattern Template didn't ask for that yet

* update links to point to files, rather than to PRs

* port the  Donut pattern from old PR #38 into this, so that we can link to the Donut pattern directly, rather than to the PR. Also adapted pattern slightly to fit the current Pattern template better.

* various other smaller fixes

Co-authored-by: Georg Grütter <gruetter@gmail.com>

Author: spier

README.md

@@ -58,34 +58,28 @@ possible to either deploy the same service in independent environments with sepa
 ### Maturity Level 1: Initial
 
 * [Transparent Cross-Team Decision Making using RFCs](patterns/1-initial/transparent-cross-team-decision-making-using-rfcs.md) - *InnerSource projects that want to achieve high participation rates and make the best possible decisions for everybody involved need to find ways to create participatory systems throughout the full software lifecycle. Publishing internal Requests for Comments (RFCs) documents allows for discussions early on in the design process, and increases the chances to build solutions with a high degree of commitment from all involved parties.*
-
-#### Reviewed Pattern Ideas (not yet proven but reviewed)
-
 * [Modular Code](patterns/1-initial/modular-code.md) - *Management does not want to spend the extra resources needed to develop modular components and make them available in a visible repository for others to use.*
 * [Improve Findability](patterns/1-initial/improve-findability.md) - *People can't find the internally developed solutions that they need due to poor naming conventions. This causes frustration in finding inner source solutions and a reduction in code reuse.*
 * [Overcoming Project Management Time Pressures](patterns/1-initial/overcoming-project-management-time-pressures.md) - *Project management believes timeline pressure and commitments on feature content does not allow for developers to spend the time needed to develop shareable code and provide support.*
-
-#### Pattern Ideas (not yet proven; brainstormed)
-
+* [Introducing Metrics in InnerSource](patterns/1-initial/introducing-metrics-in-innersource.md) - *Involve all stakeholders in designing and interpreting metrics to measure the current status in terms of health and performance of the InnerSource initiative.*
+* [Shared Code Repo Different from Build Repo](patterns/1-initial/shared-code-repo-different-from-build-repo.md) - *Deal with the overhead of having shared code in a separate repository that isn't the same as the project-specific one that is tied to production builds.*
 * [InnerSource Portal - Hygiene](patterns/1-initial/innersource-portal-hygiene.md) - *Allow generation of an official badge for projects intending to be recognised as InnerSource project within your company.*
 * [Overcome Acquisition Based Silos - Developers](patterns/1-initial/overcome-acquisition-based-silos-developer.md)
 * [Overcome Acquisition Based Silos - Managers](patterns/1-initial/overcome-acquisition-based-silos-manager.md)
 * [Discover Your InnerSource](patterns/1-initial/discover-your-innersource.md)
 * [Junkyard Styled Inner Sourcing](patterns/1-initial/junkyard-styled-innersourcing.md)
-* [Shared Code Repo Different from Build Repo](patterns/1-initial/shared-code-repo-different-from-build-repo.md) - *Deal with the overhead of having shared code in a separate repository that isn't the same as the project-specific one that is tied to production builds.*
 * [Incentive Alignment](patterns/1-initial/developer-incentive-alignment-for-innersource-contribution.md)
 * [Change the Developers Mindset](patterns/1-initial/change-the-developers-mindset.md)
 * [Share Your Code to Get More Done - Likely Contributors Variant](patterns/1-initial/share-your-code-to-get-more-done.md)
-* [Introducing Metrics in InnerSource](patterns/1-initial/introducing-metrics-in-innersource.md) - *Involve all stakeholders in designing and interpreting metrics to measure the current status in terms of health and performance of the InnerSource initiative.*
 * [Code Consumers](patterns/1-initial/code-consumers.md)
 
-#### Pattern Donuts (needing a solution)
+#### Donuts (needing a solution)
 
 * [How to Defeat the Hierarchical Constraints](patterns/1-initial/defeat-hierarchical-constraints.md)
-* [Project Management Time Pressures](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/47)
+* [Project Management Time Pressures](patterns/1-initial/overcoming-project-management-time-pressures.md)
 * [Organizational Mindset Change](patterns/1-initial/organizational-mindset-change.md)
 * [Bad Weather For Liftoff](patterns/1-initial/bad-weather-for-liftoff.md)
-* [Get Contributions Despite Silo Thinking](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/38)
+* [Incentive mechanisms to foster voluntary contribution](patterns/1-initial/incentive-mechanisms-for-voluntary-contribution.md)
 
 ## What are InnerSource Patterns?
 

patterns/1-initial/change-the-developers-mindset.md

@@ -51,10 +51,11 @@ TBD
 
 ## Status
 
-Unproven
-
-Old status: Pattern Idea
+* Initial
+* Old status: Unproven
+* Old status: Pattern Idea
 
 ## See Also
 
-This pattern has been moved for discussion at https://github.com/InnerSourceCommons/InnerSourcePatterns/issues/39
+This pattern has been moved for discussion at
+https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/63

patterns/1-initial/code-consumers.md

@@ -1,56 +1,57 @@
-# Title
-
-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
-* kill off code - knowing where (or if) it is used
-* encourage others to use a project - by showing how many users there already are
-* 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
-* Search for identifiers/markers in source control
-* Audit code clones/artifact downloads
-* 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
+# Title
+
+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
+* kill off code - knowing where (or if) it is used
+* encourage others to use a project - by showing how many users there already are
+* 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
+* Search for identifiers/markers in source control
+* Audit code clones/artifact downloads
+* 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
+
+* Initial
+* Drafted at the 2019 Spring InnerSource Commons Summit in Galway - 10 April 2019

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

@@ -72,9 +72,9 @@ TBD
 
 ## Status  
 
-Unproven
-
-Old status: brainstormed solution
+* Initial
+* Old status: Unproven
+* Old status: brainstormed solution
 
 ## Author
 

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

@@ -2,6 +2,10 @@
 
 Discover Your InnerSource
 
+## Patlet
+
+TBD
+
 ## Also Known As
 
 * Not looking for stuff internally
@@ -53,7 +57,7 @@ Make it easy to find the reusable code.
 * Encourage (and reward) owners of reusable code to use the same search engine to continually search for products that are candidates for use and adoption of the reusable code but not currently doing so.
 * Consider creating a marketplace for marketing InnerSource programs (management can use this mechanism to know which InnerSource projects to fund, but seeing how the marketplace reacts).
 
-## Known instances
+## Known Instances
 
 ## Resulting Context
 
@@ -66,11 +70,12 @@ Make it easy to find the reusable code.
 
 ## Status
 
-Brainstormed pattern idea in progress
+* Initial
+* Brainstormed pattern idea in progress
 
 ## Authors
 
-* Georg Grutter
+* Georg Gruetter
 * Erin Bank
 * Padma Sudarsan
 * Tim Yao

patterns/1-initial/improve-findability.md

@@ -57,13 +57,12 @@ None known as of yet---this is a pattern idea until it is proven.
 
 ## Status
 
-Unproven
-
-Brainstormed pattern idea reviewed 2017-03-11.
+* Initial  
+* Brainstormed pattern idea reviewed 2017-03-11.
 
 ## Authors
 
-- Georg Grutter (Robert Bosch GmbH)
+- Georg Gruetter (Robert Bosch GmbH)
 - Diogo Fregonese (Robert Bosch GmbH)
 - Erin Bank (CA Technologies)
 - Padma Sudarsan (Nokia)

patterns/1-initial/incentive-mechanisms-for-voluntary-contribution.md

@@ -0,0 +1,107 @@
+## Title
+
+Incentive mechanisms to foster voluntary contribution
+
+## Patlet
+
+TBD
+
+## Problem
+
+In hierarchical and silo-organized organizations, getting voluntary contributions in InnerSource
+projects can be challenging. It is crucial to create mechanisms to incentivize managers to foster
+voluntary contributions. Consider the following story:
+
+Company A has started an InnerSource initiative. Their InnerSource concept expected to have
+associates voluntarily contributing to InnerSource projects, regardless of topic and regardless of
+home-business-unit alignment.
+
+After some time in activity, the core team realizes that their InnerSource project is not getting
+voluntary contributions. While engaging with potential individual contributors, the
+core team (pattern link) has consistently learned that the contributors in question were
+not allowed to contribute or have their participation in InnerSource projects rejected by
+their respective line managers. The reasons presented by management are:
+
+- the lack of strategic alignment between the InnerSource project goal and the business unit product/service portfolio,
+- managers have planned their developer's capacity 100% to the home business units projects.
+
+So, the management is not motivated to provide their scarce developer capacity to the
+InnerSource project.
+
+As a result, the total number of contributors remained restricted to the core team and the
+project cannot build a community of developers. Furthermore, contributions mostly originated
+in the same business unit the Dedicated Community Leader (link to Dedicated Community Leader)
+belonged to. Innovation did not happen in the expected scale. Top management is no longer
+convinced that InnerSource yields the expected benefits and abandons the initiative altogether.
+
+## Context
+
+- The InnerSource initiative is sponsored (budget) by top level management.
+- The managers (middle-management) have their bonus directly depending
+only on business units results under their responsibility
+- The capacity of every associate is usually planned by their superiors
+and 100% allocated to the home business unit projects
+- Cross organizational collaboration is not the norm.
+- Contributions to InnerSource projects are expected to be made during working
+  hours.
+
+## Forces
+
+- Managers of business units are held accountable for their results. Reducing
+  the capacity of an associate contributing to an InnerSource project rather
+  than the goals of the business unit will make it harder for them to reach or
+  exceed their goals.
+- The more time an associate spends on contributions to an InnerSource project
+  which does not benefit his day-to-day work, the more will the workload for
+  his teammates in his business unit increase.
+- The individual contributor would like to participate to enhance his
+  professional network within the company and gain knowledge and experience
+  with both the InnerSource method and the technical area he makes a
+  contribution to.
+
+## (Possible) Solution
+
+- The top management sets and communicates a corporate strategy where development
+  capacity are to be planned and committed to a maximum of 85% to home business units projects
+- A central funded formal contracting mechanisms, where line managers get
+  refunded by the percentage of associates work time in InnerSource is in place.
+- Managers (middle-management) have a percentage of their bonus associated to
+  contribution and the results of InnerSource projects not directly related/sponsored
+  by their business units.
+- Utilize any existing engineering-wide bonus that allots some percentage of each employee's
+  bonus to be aligned with Inner Source interactions. It could be # of commits, or commits +
+  issues + documentation + chat interaction, etc. Utilize some kind of personally-linked
+  statistic to fill, for example, 15% of each employees bonus. Note that this encourages
+  after-hours type work more-so than regular work-week hours, but if combined with other
+  solutions above, could hit the issue from multiple angles. (used partially @ RedHat)
+
+## Resulting Context
+
+- The top management communication of the strategic decision to plan and commit
+  85% of developers capacity and have 15% buffer for other company initiatives,
+  for instance InnerSource projects, shows their support and sets a clear sign
+  that InnerSource is part of the corporate goal and get executive air cover.
+- Allocation of corporate funds to business units for reimbursement of
+  development capacity makes easier for business units to contribute to InnerSource
+  projects without to commit their cost center budget.
+- Setting the bonus of middle-management partially depending on contributions and the success
+  of InnerSource projects, motivates managers to encourage their developers participate on those
+  projects
+- With a stable group of contributors, it is more likely that some of them will
+  eventually achieve trusted committer status and the InnerSource project will be able
+  to establish a healthy community around their project.
+
+## Status
+
+* Initial
+
+## Authors
+
+* Diogo Fregonese (Robert Bosch GmbH)
+* Georg Gruetter (Robert Bosch GmbH)
+* Robert Hansel (Robert Bosch GmbH)
+* Nick Yeates
+
+## Alias
+
+Get Contributions Despite Silo Thinking

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

@@ -78,7 +78,7 @@ Continued monitoring of these metrics will help middle management and developers
 
 ## State
 
-Unproven
+Initial
 
 ## Authors
 

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

@@ -3,6 +3,10 @@
 * Junkyard styled inner sourcing
 * Finding but deciding not to use the internal component
 
+## Patlet
+
+TBD
+
 ## Context
 
 Two situations:
@@ -31,11 +35,12 @@ Two situations:
 
 ## Status
 
-Brainstormed pattern idea in progress
+* Initial
+* Brainstormed pattern idea in progress
 
 ## Authors
 
-* Georg Grutter
+* Georg Gruetter
 * Erin Bank
 * Padma Sudarsan
 * Tim Yao

patterns/1-initial/modular-code.md

@@ -51,6 +51,6 @@ Time is spent making the shared code modular so it can be reused.
 
 ## Status
 
-Unproven
+Initial
 
 ## Author