Governance Levels Name & Level

[robtuley]

The governance levels pattern I think was previously agreed to move to structured status. This is a PR to do that, and also to double check the name.

Naming

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.

So I would propose changing the name of the pattern to "Common Language".

Move to Structured

I'm not sure how to do this? At a guess...

• move the md file to the patterns/2-structured dir. Rename to new name if one is agreed otherwise stick with same name.
• update README
• something for the ja version?
• ...?

[spier]

Thanks for starting this @robtuley!

General recommendations

The general recommendations for leveling up a pattern are:

• We recommend that you review the Structured (L2) Requirements to understand the quality expectations we have set for the patterns in our book.
• Double check if there were any open discussion points in previous PRs about this pattern. You might built on these discussion points to improve the pattern further.
• Get a review of your PR from somebody with fresh eyes (so not yourself, and best also not the original pattern author). Finding somebody to do the review can sometimes be hard.

Your questions

Some info regarding the specific questions you list above:

move the md file to the patterns/2-structured dir. Rename to new name if one is agreed otherwise stick with same name.

Yes, just this. And yes, if the title changes, the filename should change as well.

update README

Yes. Just moving the pattern to the this section in the README is enough. If the Patlet changes, then we should change that in the README too.

something for the ja version?

Nothing to do here. We don't have a reliable way yet to push content from en to ja. Discussion is ongoing in here.
However it is fine if en and ja don't show the same set of patterns for some time, so nothing to worry about for the purposes of this pattern.

Extras

In addition:

• publishing to the book => nothing to do here, this happens automatically if the file is in the right folder, and your PR here is merged.

That's all that comes to mind for now. But once you continue your work on this PR I am sure we will discover anything that we missed now. And feel free to ask for help in #innersource-patterns at any time as well :)

[spier]

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.

So I would propose changing the name of the pattern to "Common Language".

I can see that argument.

I think that @MaineC originally had a different name as well. Not 100% sure we would have to check git history.

The issue with the title "Common Language" is that it is so generic.

And we are not discussing just any language like contributor or maintainer here. This pattern is specifically about the level of governance/stake/say/agency an InnerSource project is willing to grant to contributors.

So somehow I feel the title should reflect that.

[spier]

Update: I checked, and it looks like the tile was always "transparent governance levels".
See the PR where this pattern was started #281

[MaineC]

And we are not discussing just any language like contributor or maintainer here. This pattern is specifically
about the level of governance/stake/say/agency an InnerSource project is willing to grant to contributors.

Yes, this is where the focus is and why I used this title to begin with. However I'm not a native English speaker, so maybe there is a different term that could be used instead of governance.

Here's what I wanted to express with the three words in the title:

Transparent - could also be explicit. Often the level of openess (?) even in open source is implicit and not written down. Things like "who owns the trademark", "what was written down in foundation bylaws", "is there a document about the decision structure" can all provide clues. But often it is not transparently and explicitly written down - though having that would help downstream users make a better decision about what they are getting themselves into by using that project. The same is true for InnerSource projects: I have seen instances where the host team of Trusted Committers didn't have alignment of how open they wanted to be. I have also seen instances where the project looked like an InnerSource project from the outside from how they work but really they didn't have the bandwidth to deal with contributions. Communicating that to potential contributors does have value and avoids confusion.

governance - an alternative could be openess. What I really wanted to get at though are processes - namely decision processes. At the end of the day it boils down to who can take a final decision and can be held accountable for that decision. In case of "bug reports and issues welcome only" the host team shoulders the entire development work and strategy for the project. In case of "pull requests welcome" contributors can things they want but the final decision on merging and on strategy is with the host team. In case of "shared ownership" also strategic decisions are opened up to people outside of the original host team - and to people who report to different managers/ belong to different business units than the original host team.

levels - that term is there to signify that there are multiple valid ways of using InnerSource best practices. Communication patterns can be valuable to use even if a team never intends to accept any outside code contributions - they will get the benefit of passive documentation, they will become more familiar with working remote first. Opening a project to contributions comes at the cost of having to follow written communication styles more closely and likely decisions taking longer - and at the benefit of adding more hands to the table that can move the project forward. That development continues for shared ownership projects.

Maybe something like "explicit levels of governance openess" would be a title that better captures the above?

[spier]

Somehow I was thinking of agency as a term when reading the above.

agency is the capacity of individuals to have the power and resources to fulfill their potential.

"agency" would also be a good term from a marketing perspective, really hip to us this these days I think :)

Additional the Solution section of this pattern has this definition:

We define InnerSource operating model as a description of how much influence the core development team of a project ist willing to share with contributing teams. Or in other terms, the level of influence a contributing team can gain in the respective project.

"InnerSource operating model" is not a great title either though, as it could mean anything.

How about being almost overly-specific:
"Pre-defined Contributor Agency"

Not 100% happy with this myself actually but leaving it here for you to take a look.

[robtuley]

Naming is hard!

I do get your point about "Common Language" being simply too generic and that this pattern needs to stay focused on the governance structures. I think given this then the existing name is probably close to optimum and reaching around for something different is unnecessary as it feels like we're veering away from a "simple" name and I do think simple is best.

[robtuley]

Closing this as useful discussion but no name change required.

[spier]

Closing this as useful discussion but no name change required.

@robtuley two follow-up questions:

(1) How about calling the pattern "Contribution Governance Levels"?

That way the title would give a clue about the type of governance we are talking about?

(2) Move to Structured

As part of this PR we had planned to move the pattern to Structured.
Do you want to do that in a separate PR now, with or without the name change?