[Pattern Draft] governance-based-project-setup (#699)

Create governance-based-project-setup.md

This adds a new pattern to link our Governance Levels with information on what pre-requisits need to be fulfilled to reach the respective governance level.

The pattern looks at several factors:
* Knowledge needed by contributors and host team.
* General advise on project structure.
* Maturity levels that need to be reached.
* Relevant patterns.

---------

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

Author: MaineC

README.md

@@ -72,6 +72,7 @@ Our mission
 * [Assisted Compliance](patterns/1-initial/assisted_compliance.md) - *Helping repo owners be compliant by writing their CONTRIBUTING.md for them as a pull request.*
 * [Open Source Trumps InnerSource](patterns/1-initial/open-source-trumps-innersource.md) - *Developers disregard InnerSource projects because they consider open source projects to be superior. Introducing a required evaluation of InnerSource projects before choosing an open source project increases the likelihood of the InnerSource projects to be adopted.*
 * [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.*
+* [Governance Level Guided Project Setup](/patterns/1-initial/governance-based-project-setup.md) - *Before publishing their first InnerSource project, a team wants to choose an appropriate Governance Level but is unsure about the impact of the different levels on their daily doing. A dedicated list of resources (best practices, recommended patterns, target maturity levels) provides specific guidance to the team and helps them to make an educated decision.*
 * [Contained InnerSource](patterns/1-initial/contained-innersource.md) - *Apply InnerSource methods to facilitate collaboration in a cross-divisional project but don't invest in soliciting contributions from outside of that project.*
 * [Good First Project](patterns/1-initial/good-first-project.md) - *An InnerSource program has been launched at an organization, and to get off to a successful start it requires some good first projects that lend themselves to InnerSource-style development. Assessing the InnerSource-readiness (fitness) of the candidate projects can help in selecting projects that have the potential to help demonstrate the power of InnerSource.*
 * [InnerSource Guidance Group](patterns/1-initial/innersource-guidance-group.md) - *A highly divergent set of development standards in different teams can slow down collaboration between these teams. A InnerSource Guidance Group that establishes broad governance and behavioral guidelines can help to reduce these frictions.*

patterns/1-initial/governance-based-project-setup.md

@@ -0,0 +1,118 @@
+## Title
+
+Governance Level Guided Project Setup
+
+## Patlet
+
+Before publishing their first InnerSource project, a team wants to choose an appropriate Governance Level but is unsure about the impact of the different levels on their daily doing.
+A dedicated list of resources (best practices, recommended patterns, target maturity levels) provides specific guidance to the team and helps them to make an educated decision.
+
+## Problem
+
+A team has decided that they want to publish an InnerSource project. They are trying to decide on a [Governance Level](../1-initial/governance-levels.md) for their project. However lacking practical experience, they need further guidance on the impact each of the levels will have on their daily doing.
+
+## Context
+
+- The team has experience working as contributors to other InnerSource projects.
+- The team would like to publish an InnerSource project themselves but has only limited InnerSource Trusted Committer experience.
+- The team does have enough autonomy to decide on how much time they can invest into supporting the resulting InnerSource project.
+
+## Forces
+
+- Contributors need clarity on what to expect from an InnerSource project in terms of transparency and collaboration opportunities.
+- New Trusted Committers need an understanding of the level of work the future governance level entails.
+- New Trusted Committers may need to communicate expected impact for capacity planning.
+
+## Solution
+
+Support new Trusted Committers with a list of resources targeted at each of the three governance levels.
+
+This solution ties together various resources that are provided by the InnerSource Commons:
+
+- the [Maturity Model](../2-structured/maturity-model.md)
+- **InnerSource Patterns** applicable to each level
+
+Your organization may have additional custom resources relevant for each of these governance levels.
+You may want to link to those in addition to the ones above.
+
+### Governance Level: "Bug Reports and Issues Welcome"
+
+Definition:
+> People outside the core development team may use the code. They can submit feature requests and bug reports for things they would like to see changed.
+
+To reach this level, a team needs to make their source code readable. They need to give write access to their issue tracker.
+
+Ideally the host team goes through the [InnerSource Learning Path](https://innersourcecommons.org/learn/learning-path/) to get a first understanding of the concepts and roles involved.
+
+The relevant levels of the [maturity model](../2-structured/maturity-model.md) are at least:
+
+PP-1, DP-1, DC-1, RS-1, ST-1, CF-1, LS-1, OF-2, CB-2, SP-2, PA-2, RW-1, MP-1, SM-1, CL-1, RO-1
+
+These InnerSource patterns, start by looking at the following ones:
+
+* [Base Documentation](../2-structured/base-documentation.md)
+* [Communication Tooling](../2-structured/communication-tooling.md)
+* [Issue Tracker](../2-structured/issue-tracker.md)
+* [Praise Participants](../2-structured/praise-participants.md)
+* [Standard Release Process](../2-structured/release-process.md)
+* [Trusted Committer](../2-structured/trusted-committer.md)
+* [Improve Findability](../1-initial/improve-findability.md)
+
+### Governance Level: "Contributions Welcome"
+
+Definition:
+> People outside the core development team may use the code. They can also make modifications and submit them to core team for inclusion.
+
+To reach this level, a team needs to give contributors the option to submit pull requests. In addition, contributors need to have clear options to follow the development of the project in order to better understand project direction and established best practices. In addition the host team needs to set aside time for mentoring contributors and giving timely feedback.
+
+The relevant levels of the [maturity model](../2-structured/maturity-model.md) are at least:
+
+PP-2, DP-2, DC-2, RS-3, ST-3, CF-2, LS-2, OF-2, CB-2, SP-2, PA-2, RW-2, MP-2, SM-2, CL-3, RO-2
+
+For InnerSource patterns, start by looking at the following ones (in addition to the ones above):
+
+* [30-day warranty](../2-structured/30-day-warranty.md)
+* [Extensions for Sustainable Growth](../2-structured/extensions-for-sustainable-growth.md)
+* [Review Committee](../2-structured/review-committee.md)
+* [Service vs. Library](../2-structured/service-vs-library.md)
+* [Transparent cross team decision making](../2-structured/transparent-cross-team-decision-making-using-rfcs.md)
+* [Cross team retrospectives](../1-initial/cross-team-retrospectives.md)
+* [Incentive Mechanisms](../1-initial/incentive-mechanisms-for-voluntary-contribution.md)
+* [Include Product Owners](../1-initial/include-product-owners.md)
+* [Reluctance to accept contributions](../1-initial/reluctance-to-accept-contributions.md)
+
+### Governance Level: Shared Ownership
+
+Definition:
+> 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.
+
+To reach this level the host team, mixed of members of different teams in the organization, needs to understand that they are to act as one virtual team. There needs to be alignment of where the project is headed and increased trust between Trusted Committers.
+
+All project decisions need to be taken where they can not only be seen by others but influenced by the entire team of Trusted Committers - even if not everybody can make it to all meetings.
+
+The relevant levels of the [maturity model](../2-structured/maturity-model.md) are at least:
+
+PP-3, DP-3, DC-3, RS-3, ST-3, CF-3, LS-3, OF-3, CB-3, SP-3, PS-3, RW-3, MP-3, SM-3, CL-3, RO-3
+
+For InnerSource patterns, start by looking at the following ones (in addition to the ones above):
+
+* [Group Support](../2-structured/group-support.md)
+* [Explicit Shared Ownership](../1-initial/explicit-shared-ownership.md)
+* [Modular Code](../1-initial/modular-code.md)
+* [Source Repo different from deployment chain](../1-initial/shared-code-repo-different-from-build-repo.md)
+
+## Resulting Context
+
+TBD
+
+## Known Instances
+
+TBD
+
+## Status
+
+- Initial
+
+## Authors
+
+- Isabel Drost-Fromm