Extending Governance Levels

[robtuley]

Validate and extend the existing "Governance Levels" initial pattern. Proposed new name ideas in PR discussion.

Direct link to updated governance-levels.md

Changed:

• [x] Add Patlet
• [x] Refactor Context/Problem into more standard Problem/Story
• [x] Re-instate Context
• [x] Review and extend Forces
• [x] Tighten up Solution
• [x] Extend Resulting Context
• [x] Add Known Instance

[lenucksi]

Nice, I like this point. Addition from my side: The academic body of knowledge does qualify both the modes of Project A and Project B as very valid common variations of occurrence of working InnerSource.

The topic identified here is governance of projects. This is similar to open source where you can have modes A and B and the same resulting frustration as licenses do not imply specific governance. Often this is implied not made explicit. Open Source has the efforts of the SFOSC here trying to provide means for that.

I would argue we should not be prescriptive here but enabling and clarifying, enabling people to make informed decisions. Hence I suggest: "Make governance explicit and provide proven governance models for your InnerSource program" as a goal for the pattern. This could work by stating the the governance in the README and possibly provide some approaches to select from in the InnerSource docs for the company.

[spier]

This sounds like a well thought out plan to improve this @robtuley. Nice!

Please let us know how we can best help you.

As part of this we might be able to level-up the pattern to level 2 (Structured).

If we end up doing that, some more points to consider:

• name of the pattern - re-evaluate if the name describes the pattern will, given that level 2 patterns get published in our online book and changing the name after that is a bit more trouble
• visualization - could any visualization/chart/etc support this pattern?

[spier]

@robtuley would you like me to start reviewing the PR already? Or shall I wait until you mark it as "ready for review"? Whatever works best for you :)

[robtuley]

@spier intention is to finish it and mark it ready for review at the weekend. Last weeks just went a bit busy at work so not much space for anything else but this isn't forgotten.

[robtuley]

@spier -- updated to ready to review as I think this is in good shape now.

Naming

I think a better name for this pattern is one of:

• Common Language
• Universal Language
• Standard Language
• Menu of Models

I get where "Transparent Governance Levels" is coming from but it doesn't resonant with me personally. I think it focuses the reader's attention on governance processes rather that the root problem of ambiguous language use between people/teams. For me it becomes easier to govern InnerSource practices however you wish if you have a Common Language to more precisely describe it. But I do see that if you have Transparent Governance Levels in place then that should and will form a common language.

However, from @lenucksi comment earlier -- "The topic identified here is governance of projects" -- I suspect we might not yet be aligned on this point..?

Visualisation

Struggling on this topic -- happy to draw something up but can't think of something that would add value. Any suggestions?

[spier]

Thank you for your work on this pattern @robtuley. I am sure there are some great improvements in there already!

I am to review this in more detail next week. Will also reach out to the community in Slack to see if anybody else has input on this topic.

[spier]

Sorry @robtuley, got swamped with work, and did not get to this yet. But I did not forget about it :)

[robtuley]

Know the feeling @spier chuckle. No problem at all, there's no particular rush and I appreciate the update.

[robtuley]

Right -- revisited this to get it over the line. Think I've covered all outstanding review comments but quite the discussion here so by all means point me to any unresolved points I've missed. I propose to merge as-is, and then follow up with a new PR(s) to:

• tackle the pattern name (ref)
• chase further known instances
• move to structured pattern to publish to book
• tackle any svg problems (or convert to png)

[MaineC]

I really like how this pattern now references the equivalent in the Open Source world - it even comes with specific examples (though likely MongoDB and Elastic should be listed as "formerly Open Source", as both switched license to a proprietary one a long while ago). Tensorflow is a great example, as it is Open Source, but also according to whisper networks said to slow down or reject contributions that only benefit the competitors of the employer of it's current team of maintainers.

One question: What is the reason for using the term "Maintainer" in this document instead of the more common InnerSource term "Trusted Committer"?

[robtuley]

One question: What is the reason for using the term "Maintainer" in this document instead of the more common InnerSource term "Trusted Committer"?

I think the only usage of "Maintainer" in this doc is the reference at the end to our internal Flutter pyramid names. Internally here we use the term "Maintainer" rather than "Trusted Committer" simply for historical reasons -- it was used for a number of years and became part of our common language internally so there seemed no value to change it. In fact we used to use the term "shared development" to refer to InnerSource, but made an explicit effort to change this internally to make wider information easier to find.