Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 22 commits into from
Jan 6, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -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.*
Expand Down
118 changes: 118 additions & 0 deletions patterns/1-initial/governance-based-project-setup.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,118 @@
## Title

Governance Level Guided Project Setup
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Found that title hard to understand. Need to think about a suggestion for a better one.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I fully agree - and: naming is hard :)

Hmm. I think I need help brainstorming here.

Something that puts "capabilities" into the title?

What this pattern does is to pull several separate patterns together into a subsystem. I'm sure there is a term for that kind of text. Maybe @kjstol or @NewMexicoKid can provide some information for that?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe something like "governance level drives maturity needs"?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can improve the title later. Maybe once we find further adopters of the pattern.


## 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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It feels impractical for the readers to take the short codes from here, and look them up in the maturity model.

Unfortunately I don't have a better idea yet either. Maybe our publishing tooling (gitbook) has a solution for this. We can look at this again once we aim to get this pattern published in our book.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm also quite unhappy that we can't sort of link out directly. I included the information here because I believe, it's still valuable to have that link to the maturity model steps.


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
Loading