Skip to content
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion patterns/1-initial/governance-levels.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
## Title

Transparent Governance Levels
Common Language
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


## Patlet

Expand Down