Adds a pattern draft for making governance levels explicit.

README.md

@@ -59,6 +59,7 @@ The below lists all known patterns. They are grouped into three [maturity levels
 * [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.*
 * [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.*
 * [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.*
+* [Governance Levels](patterns/1-initial/governance-levels.md) - *There are projects in multiple stages of InnerSource adoption. Contributors get confused when working with projects that are at different stages.*
 
 ### Maturity Level 1: Initial
 

patterns/1-initial/governance-levels.md

@@ -0,0 +1,76 @@
+## Title
+
+Transparent governance levels
+
+## Context
+
+Several teams are using InnerSource patterns and best practices. However the
+degree to which they welcome not only contributions but give equal collaboration
+rights to contributors differ. As a result there are unmatched expectations,
+confusion and frustration when teams collaborate across team boundaries.
+
+## Problem
+
+For two projects InnerSource best practices have been adopted. Project A
+has a shared ownership model with Trusted Committers from multiple teams.
+Project B is fully owned by one team, only contributions are coming from
+multiple teams. New contributors to either project are regularly confused about
+the level of influence they can gain to the respective project. This leads to
+long discussions, escalations and time lost on clarifications.
+
+## Forces
+
+- For project A shared ownership works well, members coming from multiple teams
+  are working together.
+- For project B the backing team would like to retain a certain level of
+  ownership and control. Sharing ownership with other Trusted Committers outside
+  of the original team is not an option.
+- Contributors want clarity on the level of influence they can gain in an
+  InnerSource project they are involved with.
+- Writing detailed guidelines into each contributions file leads to a lot of
+  text that is hard to understand for engineers.
+
+
+## Solution
+
+Establish standardised building blocks which can be used by projects to signify
+how much influence they are willing to share. Those building blocks can then be
+used in contributing files.
+
+Examples of building blocks:
+
+* Bug reports and issues welcome: People outside the core development team are
+  welcome to read the code. They can submit feature requests and bug reports for
+  things they would like to see changed.
+
+* Contributions welcome: People outside the core development team may use the
+  code, make modifications and feed those modifications back into the projects.
+  Trusted committers are willing to mentor those contributions to a state where
+  they can be accepted or communicate clearly why the proposed change cannot be
+  made.
+
+* Shared write access: In addition to the above people outside the core
+  development team may gain write access to the source repository. Influence on
+  roadmap decisions as well as influence on who else gains write access is
+  restricted to the core development team.
+
+* Shared ownership: Members of different teams collaborate on the project as
+  equal peers. Everyone has the ability to merge code. Everyone has an equal say
+  on the project direction. Everyone has an equal say in who else to add to this
+  group.
+
+
+## Resulting Context
+
+Teams can adopt InnerSource best practices in a step-by-step way. By documenting
+individual steps contributor confusion is avoided.
+
+## Known Instances
+
+TBD
+
+## Status
+
+Early draft
+
+