Adds a pattern draft for making governance levels explicit. #281
Conversation
This adds a pattern for making several levels of openess wrt. governance levels explicit to project contributors. Inspired by several versions of Open Source project governance (e.g. single vendor with full control, foundation hosted with vendor neutrality as a goal etc.) this pattern tries to translate these versions into an InnerSource context.
MaineC
requested review from
cewilliams,
gruetter,
lenucksi,
NewMexicoKid,
nyeates and
spier
as code owners
There was a problem hiding this comment.
Great first version @MaineC!
I would be happy to merge that in as a level 1 (Initial) pattern.
I sent some inline suggestions for you to review.
Update:
I just noticed that a Patlet is missing. Maybe you confused Patlet and Context?
| welcome to read the code. They can submit feature requests and bug reports for | ||
| things they would like to see changed. | ||
|
|
||
| * Contributions welcome: People outside the core development team may use the |
There was a problem hiding this comment.
Is "core development team" here the same as "backing team" which you used above?
There was a problem hiding this comment.
I think I'm lacking a good term here: What I'm trying to explain is that there is a difference between a project that is carried forward by individuals working under one line manager, delivering one roadmap vs. a project where individuals from multiple such teams collaborate.
There was a problem hiding this comment.
I see. I don't know the best term here either.
For the time being I would then suggest to just introduce and define a term, likely towards the beginning of the Pattern, and then stick to that term through out the pattern.
As we improve this pattern over time we might come up with another term, possibly influenced by other patterns as well. We may even want to pull such terms that we attribute certain meaning to into a central glossary to help pattern authors and readers to use these terms in a similar manner.
|
Also I committed and resolved some of my own suggestions that were only required to make our Markdownlint check happy :) |
|
@MaineC I took the liberty to resolve/merge some of my suggested edits that I did not consider controversial. Hope I didn't overstep there, so feel free the change them back if you feel strongly about any of them. |
|
Oh - that's what caused those pesky merge conflicts when I tried to push the changes I made according to your review yesterday :/ |
|
Are there any more open suggestions from your side that I should address? |
|
One more caveat: Please leave this pull request open for a few more days, I've asked a few people via Twitter whether they'd have time to add their perspective. Edit: One piece of background to integrate here: https://twitter.com/galoppini/status/1352270671011835905 Edit 2: One very current case where we could draw inspiration from here: https://twitter.com/MaineC/status/1352123851237429248 Edit 3: https://twitter.com/MaineC/status/1351913663020617732 ... this is the origin of this pull request for comparison Any help with integrating the different perspectives welcome. :) |
|
@MaineC only two more suggestions from my end. See: And great job bringing in more people into the conversation! |
Co-authored-by: Sebastian Spier <github@spier.hu>
|
Side note: After going through the paper linked above I believe we can come up with a few more fine-grained patterns along the lines of "If you want to increase contributor engagement, try making your InnerSource project more transparent and more accessible". |
@MaineC this PR looks great to me now. Do you still want to keep it open, or shall I merge it? |
spier
added
the
📖 Type - Content Work
|
@MaineC shall we merge this PR, even if only to get the pattern "out there" in it's initial form and make it easier to link to it? Also do you want to add yourself to the pattern in a |
|
Feel free to merge the pattern. I think we can add additional detail as separate patterns. |
|
@MaineC excellent. Merging now. |
This adds a pattern for making several levels of openess wrt. governance levels
explicit to project contributors. Inspired by several versions of Open Source
project governance (e.g. single vendor with full control, foundation hosted with
vendor neutrality as a goal etc.) this pattern tries to translate these versions
into an InnerSource context.