Promoting Governance Levels pattern to Structured

[spier]

Now that this pattern has received its 2nd org confirming the applicability of the pattern (see #764), let's push this pattern to the next maturity level "Structured".

Checklist

from the Contributor Handbook:

• Is validated by at least 1 (one) known instance
• Uses the format described in the Pattern Template - validated in parts by Check: Pattern Syntax Validation
• Follows the Pattern Style Guide
• The title of the pattern is memorable, concise, and descriptive of what the pattern is about. For further tips see Naming Patterns.
• The pattern links to related patterns of this level or higher.
• Links from the pattern to outside resources are working and are referencing a trusted resource - whether links are working is verified by Check: Links
• The pattern is added to at least one phase of the InnerSource Program Mind Map.
  • Status: I added to pattern to one area of the mind map already, just to show how it might work. We should update this before we push the pattern live.
• Spelling & Styles checks pass - see Check: Spelling & Styles

Extras

possibly porting these back to the contributor handbook after this

• URL of the pattern is memorable / the filename will be part of the URL
• add some more visuals here from Add image visualizing the four governance levels #474 (or this gDrive file)
• review the Patlet (still talks about 'common language' rather than 'governance levels')
• rename 'core core development team' to 'host team' to prevent confusion with the Core Team pattern

History

It might help to review previous PRs related to this pattern:

• pattern creation: Adds a pattern draft for making governance levels explicit. #281
• improvements incl adding Flutter Entertainment as known instance: Extending Governance Levels #357
• adding BBC as known instance: Add BBC to users of the Governance Levels pattern #764

[spier]

A question to @MaineC, @tsadler1988, @robtuley, @rrrutledge:

Is what the Governance Levels pattern calls "distributed ownership" the same as what the pattern Group Support describes? If yes, then we could add links from one pattern to the other.

My initial take:
While the group support pattern describes a different reason for this ownership model to emerge, otherwise it seems to be the same concept.

[MaineC]

I think the group support pattern, as well as the explicit shared ownership pattern

https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns%2F1-initial%2Fexplicit-shared-ownership.md

both describe ways to establish shared ownership, while this pattern here describes shared ownership itself.

For this pattern, to make it easier to understand, you could add the open source analogy to each level:

Bug reports welcome: shared source (non OSS)
Contributions welcome: single vendor OSS
Shared ownership: vendor neutral OSS

We had these parallels in the original PR discussion but somehow didn't move them to the pattern itself.

[spier]

We had these parallels in the original PR discussion but somehow didn't move them to the pattern itself.

@MaineC I could not find this. Can you point me to it?

This is an interesting case of doing forensics of how the pattern has developed over time :)

[spier]

@robtuley we are finally pushing this pattern to the next stage of maturity, which will also mean that we will get it published in our online book 🥳

I just saw here that Flutter has a new visual for the pyramid, which I would like to integrate into the pattern:
https://innersource.flutter.com/how/pyramid/

Would that be ok?

Also are there any new experience with this approach at Flutter that you would like to add to the pattern?

[MaineC]

@MaineC I could not find this. Can you point me to it?

My brain betrayed me here - apparently in one of the refinements of the pattern we did move the information I thought was only available as PR comment into the pattern itself...

[MaineC]

https://github.com/search?q=repo:InnerSourceCommons/InnerSourcePatterns%20governance%20levels&type=pullrequests#issuecomment-765274307 ... for pattern archaeology - that comment may once have held interesting information, except now it's on a dying platform, so not sure if the snippets I linked can still be reached.

[MaineC]

http://www.joelwest.org/Papers/WestOMahony2008-WP.pdf ... Found the related/ linked paper...

[spier]

@tsadler1988 just realized that your talk Ownership in a DevOps and InnerSource environment - Tom Sadler (BBC) is actually from 2023. Did the BBC make new experiences with the Distributed Ownership model you want to add to this pattern?

[spier]

@MaineC is your org an adopter of this pattern? i.e. do you want to add your org to the Known Instances?

[MaineC]

@spier sure, you can also add Europace AG to the list of users. It's fairly central for us actually as it helps potential contributors with what they can expect from the project they depend on.

[tsadler1988]

I think the group support pattern, as well as the explicit shared ownership pattern...

In my mind, those 2 patterns (and maybe others too, such as Core Team) are specific InnerSource governance/operating/ownership models, whereas this pattern is about communicating those differing models, and raising awareness of which ones are in use by which projects.

Side note - I do wonder if we could classify these models into a few groups e.g. (from hardest to softest ownership):

• Core team + contributors - no TCs outside core team
• Core team + TCs
• Distributed/shared ownership with mandatory participation from teams/individuals involved
• Distributed/shared ownership with optional participation via internal communities

Note it's also possible to slice a project up folder by folder and apply different models as necessary.

EDIT: I realised I'm describing what's already covered by the Pyramid, just slightly differently.

@tsadler1988 just realized that your talk Ownership in a DevOps and InnerSource environment - Tom Sadler (BBC) is actually from 2023. Did the BBC make new experiences with the Distributed Ownership model you want to add to this pattern?

https://www.youtube.com/watch?v=qiaWbu8czPc is my latest talk on ownership, but I don't think I go into detail except to say it's still fairly new but working well so far.

Internally, we've been reviewing this exact thing over the past few weeks so we do have more to share, but there's no talk or blog to reference. Happy to share some insights, let me know and we can discuss elsewhere.

Also, would it be helpful to incorporate some of the diagrams I use? E.g.

[spier]

So much great input in your last comment @tsadler1988!

Let's find a way to work this into this pattern. For that we don't need a blog post as reference either. Most of the time a pattern is written based on the experience of 1-2 organizations anyways, and then further generalized as more different orgs contribute to the pattern (if that happens).

Therefore I have added you to the authors of the pattern already, to make sure that you get props for all of your contributions to this topic.

Do you want to have a chat one of these days about what you discovered at the BBC related to these governance levels?

[MaineC]

I really like the images you created - including the added step splitting write access and project direction.

[spier]

@tsadler1988 and @MaineC I did some more rounds on the pattern.

You can see the latest version in our staging site for the patterns:
https://innersourcecommons.gitbook.io/innersource-patterns-staging/p/governance-levels

Maybe seeing it this version with a bit more layout makes it easier for you to review it again with fresh eyes :)

Especially curious if you have ideas for where in the mindmap this pattern should be place.

[spier]

I think this is as good as it gets for now.

I went back and forth about which name/title to use for this pattern but eventually I staid at what we already had.

Maybe we could rename this to "Governance Framework" in the future. However then we would have to describe what makes this a framework i.e. besides defining the levels, what else is required?