-
Notifications
You must be signed in to change notification settings - Fork 193
[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
Changes from all commits
985bc7e
8615d5d
a53a78e
6666157
5df151f
408c35b
295be6b
7b0fbb8
33c20e6
452a237
b7a95de
1548569
fb5d6ac
dc838fd
c3501ca
ae7e10f
011ee5d
4951866
e992138
39514d0
bfca5f6
8f1ef4c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,118 @@ | ||
## Title | ||
|
||
Governance Level Guided Project Setup | ||
|
||
## Patlet | ||
spier marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
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 | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe 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. There was a problem hiding this comment. Choose a reason for hiding this commentThe 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" | ||
|
||
spier marked this conversation as resolved.
Show resolved
Hide resolved
|
||
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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"?
There was a problem hiding this comment.
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.