Cleanup overview of patterns in Level 1

README.md

@@ -57,34 +57,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)
+* [Get Contributions Despite Silo Thinking](patterns/1-initial/get-contributor-despite-silo.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

@@ -42,5 +42,5 @@ _needs work...?_
 * Katrina Novakovic (RedHat)
 
 # Status
-Drafted at the 2019 Spring InnerSource Commons Summit in Galway - 10 April 2019
-
+* Initial
+* Drafted at the 2019 Spring InnerSource Commons Summit in Galway - 10 April 2019

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

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

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

@@ -1,6 +1,9 @@
 ## Title
 Discover Your InnerSource
 
+## Patlet
+TBD
+
 ## Also Known As
 * Not looking for stuff internally
 * Don't bother looking
@@ -58,7 +61,8 @@ 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
+* Initial
+* Brainstormed pattern idea in progress
 
 ## Authors
 * Georg Grutter

patterns/1-initial/get-contributor-despite-silo.md

@@ -0,0 +1,105 @@
+## 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
+
+## Acknowledgements

patterns/1-initial/improve-findability.md

@@ -56,9 +56,8 @@ 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
 

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.
@@ -79,7 +79,7 @@ Continued monitoring of these metrics will help middle management and developers
 
 ## State
 
-Unproven
+Initial
 
 ## Authors
 

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

@@ -2,6 +2,9 @@
 * Junkyard styled inner sourcing
 * Finding but deciding not to use the internal component
 
+## Patlet
+TBD
+
 ## Context
 Two situations:
 
@@ -25,7 +28,9 @@ Two situations:
 * 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
+
+* Initial
+* Brainstormed pattern idea in progress
 
 ## Authors
 * Georg Grutter

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  

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

@@ -67,9 +67,9 @@ Partially validated. Validated means this has been seen to work in similar scena
 
 ## Status
 
-Unproven (not reviewed)
-
-Old Status: Pattern Idea - Draft In Progress
+* Initial
+* Old Status: Unproven (not reviewed)
+* Old Status: Pattern Idea - Draft In Progress
 
 ## Author
 

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

@@ -70,9 +70,9 @@ Partially validated. Validated means this has been seen to work in similar scena
 
 ## Status
 
-Unproven (not reviewed)
-
-Old Status: Pattern Idea - Draft In Progress
+* Initial
+* Old Status: Unproven (not reviewed)
+* Old Status: Pattern Idea - Draft In Progress
 
 ## Author
 

patterns/1-initial/share-your-code-to-get-more-done.md

@@ -52,9 +52,9 @@ TBD
 
 ## Status
 
-Unproven
-
-Old status: Idea
+* Initial
+* Old status: Unproven
+* Old status: Idea
 
 ## Author
 

patterns/1-initial/shared-code-repo-different-from-build-repo.md

@@ -4,7 +4,7 @@ Repo for Shared Code Different from Repo the Product Org Uses in its Build
 
 ## Patlet
 
-TBD
+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.
 
 ## Problem
 
@@ -26,6 +26,8 @@ Continuous integration, not only to with testing but also in production (aligns
 
 Ideally, overhead is minimized or eliminated. Or integrate the shared code repository in the production build.  
 
+## Known Instances
+
 ## Status
 
 Unproven