Add a pattern for making shared ownership explicit. #321
Conversation
In cases where projects are already owned by multiple teams but without clear explicit Trusted Committers this pattern can help to bootstrap an initial set of TCs.
MaineC added 1-initial MaineC requested review from NewMexicoKid, cewilliams, lenucksi and spier as code owners 
lenucksi left a comment
lenucksi left a comment There was a problem hiding this comment.
Thanks for this excellent write-up @MaineC, you beat me to writing it up.
I can only confirm all of what is written up here as a really common pattern.
I did add a few notes on additional observations.
As a hint: Reviewing would be a lot easier if individual sentences would start on individual lines given the GH review tooling.
| | ||
| Use the issue/ pull-request mechanics that work so well for code modifications to modify the way the component is developed: | ||
| | ||
| A volunteer creates an issue in the component's repository highlighting the apparent unclarity or even lack of ownership. Subsequently a volunteer (can be the same person) creates a suggestion for how the project should be developed going forward including a list of initial Trusted Committers. This suggestion is posted to the project's documentation (e.g. it's README.md file) as a pull request. This pull request is left open and shared with all people affected by the change. Feedback can be given and integrated asynchronously. Development of the final state is transparent for everyone. |
There was a problem hiding this comment.
I agree, but think we should include the need to address the waves past the technical experts (i.e. line management etc.) resulting in making this more explicit to not block this sensible and outcome driven approach. In other words: Hint that there might be a need to handle the cheeses-of-all-sizes-game.
There was a problem hiding this comment.
What is the cheeses-of-all-sizes-game? Is that an English idiom that I should know?
There was a problem hiding this comment.
https://innersourcecommons.org/documents/books/InnerSourceChecklist.pdf ... the big cheese story is explained on page 11 of this book. It comes up in several learning path trainings as well.
Feel free to commit those right away, anyone with commit access to this repo should have write access to the PR branch. (If not, let me know and I'll try to change that.)
Thanks for the hint. This is coming just in time as I'm about to write another pattern. I'll (try to) remember that before submitting it for review here. |
spier left a comment
spier left a comment There was a problem hiding this comment.
Great start @MaineC. I left some comments and suggestions.
Some general thoughts:
- how does this relate to how ownership is transitioned to a new maintainer in Open Source?
- how to determine whether shared ownership should be preferred over handing over responsibilities of the repo to a single team? (e.g. one of the teams that are depend on the component)
| | ||
| Use the issue/ pull-request mechanics that work so well for code modifications to modify the way the component is developed: | ||
| | ||
| A volunteer creates an issue in the component's repository highlighting the apparent unclarity or even lack of ownership. Subsequently a volunteer (can be the same person) creates a suggestion for how the project should be developed going forward including a list of initial Trusted Committers. This suggestion is posted to the project's documentation (e.g. it's README.md file) as a pull request. This pull request is left open and shared with all people affected by the change. Feedback can be given and integrated asynchronously. Development of the final state is transparent for everyone. |
There was a problem hiding this comment.
What is the cheeses-of-all-sizes-game? Is that an English idiom that I should know?
| Hi @MaineC. I merged and resolved a couple of feedback comments that I considered non-controversial. I was wondering if there is any other help that I can provide to get a first version of this merged and shared with a wider audience? |
Co-authored-by: Sebastian Spier <github@spier.hu>
Co-authored-by: Johannes Tigges <lenucksi@users.noreply.github.com>
spier left a comment
spier left a comment There was a problem hiding this comment.
Great next version again!
My only open question is how this pattern is connected to CONTRIBUTING.md.
If we can resolve that, then this pattern would be good be merged as Initial from my point of view.
As usual, thanks for spending the time to write this up!
Co-authored-by: Sebastian Spier <github@spier.hu>
Co-authored-by: Sebastian Spier <github@spier.hu>
Co-authored-by: Sebastian Spier <github@spier.hu>
In my experience this is handled different going from project to project. What I have seen at Apache is a more structured approach that I believe would also make sense to adopt in an InnerSource setting. Instead of leaving downstream users in the dark as to whether projects are still active or not, here's what is done there:
Before that happens, the project is nudged regularly to recruit new helping hands. Depending on the project those efforts may or may not be successful.
At the end of the day this is specific to the situation at hand. In my experience this is something that those teams are well able to solve once the situation has been made transparent and stakeholders informed (in most cases they already know about the situation anyway). |
| As all inline comments are resolved now, I am opting to merge this pattern. Thank you for the great contribution @MaineC. I am expecting that many more companies would know this situation, so I am curious to hear what other people will have to add to this in the future. |
| When merging the PR I noticed the intro text of this PR:
This is a great pitch for using the pattern actually. I am wondering if and how this could be worked into the pattern itself. |
3 participants
In cases where projects are already owned by multiple teams but without clear explicit Trusted Committers this pattern can help to bootstrap an initial set of TCs.