## 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
