Adds a pattern draft for making governance levels explicit. (#281)

Adds a pattern draft for making governance levels explicit.

This adds a pattern for making several levels of openess wrt. governance levels
explicit to project contributors. Inspired by several versions of Open Source
project governance (e.g. single vendor with full control, foundation hosted with
vendor neutrality as a goal etc.) this pattern tries to translate these versions
into an InnerSource context.

Co-authored-by: Sebastian Spier <[email protected]>

Author: MaineC

README.md

@@ -76,6 +76,7 @@ The below lists all known patterns. They are grouped into three [maturity levels
 * [Reluctance to Receive Contributions](patterns/1-initial/reluctance-to-accept-contributions.md) - *Core owner of shared asset is reluctant to take contributions due to the required maintenance that comes with them. Summary pattern that lays out four children patterns with three to be defined.*
 * [Include Product Owners](patterns/1-initial/include-product-owners.md) - *Engaging and educating Product Owners about InnerSource can help them modify their actions (e.g., in the space of KPIs) to help InnerSource collaboration work better.*
 * [Assisted Compliance](patterns/1-initial/assisted_compliance.md) - *Helping repo owners be compliant by writing their CONTRIBUTING.md for them as a pull request.*
+* [Transparent 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.*
 
 #### Donuts (needing a solution)
 

patterns/1-initial/governance-levels.md

@@ -0,0 +1,72 @@
+## 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](../2-structured/trusted-committer.md) 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
+
+Initial (Early draft)