Move patterns to new folders

README.md

@@ -20,59 +20,67 @@ Our mission in this working group
 
 ## List of Patterns
 
-The below lists all known patterns. They are grouped into four stages of maturity.
-
-### Reviewed Patterns (proven and reviewed)
-
-* [30 Day Warranty](30-day-warranty.md) - *a pattern for getting a reluctant code-owning team to accept code submissions from outside their team.*
-* [Common Requirements](common-requirements.md) - *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.*
-* [Contracted Contributor](contracted-contributor.md) - *Associates wanting to contribute to InnerSource are discouraged from doing so by their line management. Relief is provided by formal contracts and agreements.*
-* [Dedicated Community Leader](dedicated-community-leader.md) - *Select people with both communications and technical skills to lead the communities to ensure success in starting an InnerSource initiative.*
-* [Gig Marketplace](gig-marketplace.md) - *Establish a marketplace by creating an intranet website that lists specific InnerSource project needs as "Gigs" with explicit time and skill requirements. This will enable managers to better understand their employee’s time commitment and professional benefits thereby increasing the likelihood of garnering approval to make InnerSource contributions.*
-* [InnerSource License](innersource-license.md) - *Two legal entities that belong to the same organization want to share software source code with each other but they are concerned about the implications in terms of legal liabilities or cross-company accounting. An **InnerSource License** provides a reusable legal framework for the sharing of source code within the organization. This opens up new collaboration options, and makes the rights and obligations of the involved legal entities explicit.*
-* [InnerSource Portal](innersource-portal.md) - *Create an intranet website that indexes all available InnerSource project information. This will enable potential contributors to more easily learn about projects that might interest them and for InnerSource project owners to attract an outside audience.*
-* [Praise Participants](praise-participants.md) - *Thank contributors effectively to engender further engagement from them and to encourage others to contribute*
-* [Review Committee](review-committee.md) - *A formal review committee is setup within an org to "officiate" particular inner source projects with resources, etc.*
-* [Service vs. library: It's inner source, not inner deployment](service-vs-library.md) - *Teams in a DevOps environment may be reluctant to work across team boundaries on common code bases due to ambiguity over who will be responsible for responding to service downtime. The solution is to realize that often it's
-possible to either deploy the same service in independent environments with separate escalation chains in the event of service downtime or factor a lot of shared code out into one library and collaborate on that.*
-* [Trusted Committer](project-roles/trusted-committer.md) - *Many inner-source projects will find themselves in a situation where they consistently receive feedback, features, and bug-fixes from contributors. In these situations project maintainers seek ways to recognize and reward the work of the contributor above and beyond single contributions.*
+The below lists all known patterns. They are grouped into three [maturity levels](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/meta/contributor-handbook.md#maturity-levels).
+
+### Maturity Level 3: Validated
+
+*Note: We don't have patterns in this stage yet, but are [actively working on leveling up patterns](https://github.com/InnerSourceCommons/InnerSourcePatterns/issues/186) into this maturity.*
+
+### Maturity Level 2: Structured
 
-### Reviewed Pattern Ideas (not yet proven but reviewed)
+#### Reviewed Patterns (proven and reviewed)
 
-* [Modular Code](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](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.*
+* [30 Day Warranty](patterns/2-structured/30-day-warranty.md) - *a pattern for getting a reluctant code-owning team to accept code submissions from outside their team.*
+* [Common Requirements](patterns/2-structured/common-requirements.md) - *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.*
+* [Contracted Contributor](patterns/2-structured/contracted-contributor.md) - *Associates wanting to contribute to InnerSource are discouraged from doing so by their line management. Relief is provided by formal contracts and agreements.*
+* [Dedicated Community Leader](patterns/2-structured/dedicated-community-leader.md) - *Select people with both communications and technical skills to lead the communities to ensure success in starting an InnerSource initiative.*
+* [Gig Marketplace](patterns/2-structured/gig-marketplace.md) - *Establish a marketplace by creating an intranet website that lists specific InnerSource project needs as "Gigs" with explicit time and skill requirements. This will enable managers to better understand their employee’s time commitment and professional benefits thereby increasing the likelihood of garnering approval to make InnerSource contributions.*
+* [InnerSource License](patterns/2-structured/innersource-license.md) - *Two legal entities that belong to the same organization want to share software source code with each other but they are concerned about the implications in terms of legal liabilities or cross-company accounting. An **InnerSource License** provides a reusable legal framework for the sharing of source code within the organization. This opens up new collaboration options, and makes the rights and obligations of the involved legal entities explicit.*
+* [InnerSource Portal](patterns/2-structured/innersource-portal.md) - *Create an intranet website that indexes all available InnerSource project information. This will enable potential contributors to more easily learn about projects that might interest them and for InnerSource project owners to attract an outside audience.*
+* [Praise Participants](patterns/2-structured/praise-participants.md) - *Thank contributors effectively to engender further engagement from them and to encourage others to contribute*
+* [Review Committee](patterns/2-structured/review-committee.md) - *A formal review committee is setup within an org to "officiate" particular inner source projects with resources, etc.*
+* [Service vs. library: It's inner source, not inner deployment](patterns/2-structured/service-vs-library.md) - *Teams in a DevOps environment may be reluctant to work across team boundaries on common code bases due to ambiguity over who will be responsible for responding to service downtime. The solution is to realize that often it's
+possible to either deploy the same service in independent environments with separate escalation chains in the event of service downtime or factor a lot of shared code out into one library and collaborate on that.*
+* [Trusted Committer](patterns/2-structured/trusted-committer.md) - *Many inner-source projects will find themselves in a situation where they consistently receive feedback, features, and bug-fixes from contributors. In these situations project maintainers seek ways to recognize and reward the work of the contributor above and beyond single contributions.*
 
-### Pattern Drafts (proven, not yet fully reviewed)
+#### Pattern Drafts (proven, not yet fully reviewed)
 
 * [Assisted Compliance](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/74) - *Helping repo owners be compliant by writing their CONTRIBUTING.md for them as a pull request.*
-* [Cross-Team Project Valuation](crossteam-project-valuation.md) - *It's hard to sell the value of cross-team, inner sourced projects that don't provide a direct impact on company revenue. Here's a data-driven way to represent your project that both articulates its value and amplifies it.*
+* [Cross-Team Project Valuation](patterns/2-structured/crossteam-project-valuation.md) - *It's hard to sell the value of cross-team, inner sourced projects that don't provide a direct impact on company revenue. Here's a data-driven way to represent your project that both articulates its value and amplifies it.*
 * [Reluctance to Receive Contributions](https://docs.google.com/document/d/13QDN-BpE_BixRFVGjao32n4Ctim0ROXAHbBWMBOijb4/edit) - *Core owner of shared asset is reluctant to take contributions due to the required maintenance that comes with them.*
 * [What Before How or Services Documentation](https://docs.google.com/document/d/1_N1wsQeDusfIcNy-O2ZXenY3PL7ZbvkUDRZxGUuegZw/edit?usp=drive_web) - *A lack of common understanding between different management tiers creates funding barriers and increases the risk that solutions will not deliver required business outcomes.*
-* [Overcome Acquisition Based Silos - Developers](overcome-acquisition-based-silos-developer.md)
-* [Overcome Acquisition Based Silos - Managers](overcome-acquisition-based-silos-manager.md)
+* [Overcome Acquisition Based Silos - Developers](patterns/2-structured/overcome-acquisition-based-silos-developer.md)
+* [Overcome Acquisition Based Silos - Managers](patterns/2-structured/overcome-acquisition-based-silos-manager.md)
 * [Open Source Trumps InnerSource](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/46) - *People find the InnerSource project but, after all things are considered, even if the InnerSource component meets their needs, they still go with the open source component.*
 * [Overcoming Project Management Time Pressures](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/47) - *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.*
-* [Start as Experiment](start-as-experiment.md) - *An inner source initiative is considered but not started, because management is unsure about its outcome and therefore unwilling to commit to the investment.*
+* [Start as Experiment](patterns/2-structured/start-as-experiment.md) - *An inner source initiative is considered but not started, because management is unsure about its outcome and therefore unwilling to commit to the investment.*
 * [Include Product Owners](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/71) - *Key Performance Indicators (KPIs) for Product Owners are primarily product focused, and don't consider areas such as collaborative development. This results in a lower level of engagement with inner source projects.*
-* [Provide standard base documentation through a README](project-setup/base-documentation.md)
+* [Provide standard base documentation through a README](patterns/2-structured/project-setup/base-documentation.md)
+* [Issue tracker use cases](patterns/2-structured/project-setup/issue-tracker.md)
+
+### Maturity Level 1: Initial
+
+#### 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.*
 
-### Pattern Ideas (not yet proven; brainstormed)
+#### Pattern Ideas (not yet proven; brainstormed)
 
-* [Discover Your InnerSource](discover-your-innersource.md)
-* [Junkyard Styled Inner Sourcing](junkyard-styled-innersourcing.md)
-* [Shared Code Repo Different from Build Repo](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](developer-incentive-alignment-for-innersource-contribution.md)
-* [Change the Developers Mindset](change-the-developers-mindset.md)
-* [Share Your Code to Get More Done - Likely Contributors Variant](share-your-code-to-get-more-done.md)
-* [Introducing Metrics in InnerSource](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.*
+* [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.*
 
-### Pattern Donuts (needing a solution)
+#### Pattern Donuts (needing a solution)
 
-* [How to Defeat the Hierarchical Constraints](defeat-hierarchical-constraints.md)
+* [How to Defeat the Hierarchical Constraints](patterns/1-initial/defeat-hierarchical-constraints.md)
 * [Project Management Time Pressures](https://github.com/InnerSourceCommons/InnerSourcePatterns/pull/47)
-* [Organizational Mindset Change](organizational-mindset-change.md)
-* [Donut 8: Not Invented Here](https://github.com/InnerSourceCommons/innersourcecommons.org/wiki/Donut-8:-Not-invented-here)
-* [Bad Weather For Liftoff](bad-weather-for-liftoff.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)
 
 ## What are InnerSource Patterns?

start-as-experiment.md → patterns/2-structured/start-as-experiment.md

@@ -16,7 +16,7 @@ investment.
 
 ## Context
 
-The company is considering to leverage InnerSource to increase the efficiency
+The company is considering InnerSource to increase the efficiency
 of collaboration on software projects. However, most managers are not familiar
 with the Open Source working model and are instead accustomed to hierarchical,
 top-down control style management. The idea of InnerSource is very popular with
@@ -32,7 +32,7 @@ or are actively developing Open Source software.
   and if many projects are likely to rely on it, a decision to shut it down
   will be very unpopular and therefore hard to make. The perceived resulting
   loss of control might deter some managers to even start with InnerSource.
-- Implementing InnerSource style working models are often a radically departure
+- Implementing InnerSource style working models are often a radical departure
   from previously practiced working models. It is therefore likely, that
   existing, mandatory processes are no longer applicable and that appropriate
   governing processes are missing. The result might be that one has to operate
@@ -43,12 +43,11 @@ or are actively developing Open Source software.
 ## Solution
 
 Declare the InnerSource initiative as a time limited experiment. Define and
-communicate the criteria for projects to join the InnerSource experiment. The
-criteria should be chosen such that they maximize the chances of building a
-healthy InnerSource community around the selected InnerSource projects. They
-should also help to ensure that the setting of the projects is such that they
-can later be used to gain externally valid insights into the effects of
-applying InnerSource. Examples for such criteria are
+communicate the criteria for projects to join the InnerSource experiment. Choose
+criteria that will maximize the chances of building a healthy A set of criteria is 
+a good one if the insights generated from it within the context of the experiment 
+can intuitively be applied to contexts involving other potential InnerSource projects.
+Examples for such criteria are:
 
 - Sufficient geographical distribution of developers
 - Sufficient departmental mix of developers,
@@ -70,7 +69,7 @@ their value contributions.
 
 Managers are able to kick start InnerSource for the following reasons:
 
-- The experimental setup eases the need of managers to scrutinize the
+- The experimental setup eases the need for managers to scrutinize the
   InnerSource program numbers in the same way that they would for typical
   projects.
 - The possibility of failure of the experiment is understood and accepted. The
@@ -80,8 +79,8 @@ Managers are able to kick start InnerSource for the following reasons:
 - In case of success, the data gathered during the experiment will allow
   managers to make a longer lasting commitment to InnerSource.
 
-Participants in the InnerSource experiment are now conscious of the fact that
-they have to prove to management that InnerSource yields the promised benefits.
+Participants in the InnerSource experiment are now conscious that they have to 
+prove to management that InnerSource yields the promised benefits.
 It will therefore help to focus work on those activities which provide the most
 demonstrable value thus increasing the chances of success.