Promoting Governance Levels pattern to Structured (#765)

* Adding terminology to the open source analogies
* Splitting up the different rights that the people get in each of the operating models, to make them easier to compare.
* Adding alternative names for each level
* Adding new visual from Flutter
* Adding Alias section
* Adding Tom Sadler and Sebastian Spier to the authors
* Adding pattern to the mindmap (can be added in added in other areas as well)
* Adding Europace as a known instance
* Re-creating markmap and screenshot
* Use the term 'governance levels' consistently throughout the pattern. Clearly call out the aliases to this term.
* Moving the description of how this pattern relates to open source to the Rationale section. That also works better because the reader already knows about the governance level names by the time they read the Rationale (which is referring to these names as well).
* Adding 'Shared Write Access' as 4th governance level again. Adding images that support the explanation of the levels.
* Use 'host team' intead of 'core development team' to prevent confusion with Core team pattern
* Update Patlet

Author: spier

README.md

@@ -58,6 +58,7 @@ Our mission
 * [Extensions for Sustainable Growth](/patterns/2-structured/extensions-for-sustainable-growth.md) - *An InnerSource project is receiving too many contributions, making maintenance difficult. By offering an extension mechanism outside of the core project, the maintainers enable scaling of project capabilities with minimal cost and maintenance overhead.*
 * [Standard Release Process](patterns/2-structured/release-process.md) - *Teams may hesitate to adopt an InnerSource project if they are unsure of its maturity. To address this, consistent release notes and published artifacts are crucial. These practices showcase a strong dedication to the project, instilling confidence and assuring users of ongoing commitment to sustainable and well-managed software.*
 * [Group Support](patterns/2-structured/group-support.md) - *What happens if a team or individual no longer supports an InnerSource project? Keep the project alive by forming a group of interested individuals.*
+* [Explicit Governance Levels](patterns/2-structured/governance-levels.md) - *Different teams within an organization use InnerSource practices in varying ways, leading to confusion and inefficiencies due to inconsistent expectations of collaboration and contribution rights. Establish centrally documented governance levels that define the extent of influence contributing teams can have on a project, improving clarity for contributors and host teams alike.*
 
 ### Maturity Level 1: Initial
 
@@ -71,7 +72,6 @@ Our mission
 * [Include Product Owners](patterns/1-initial/include-product-owners.md) - *Engaging and educating Product Owners about InnerSource can help them modify their actions (e.g., in the space of KPIs) to help InnerSource collaboration work better.*
 * [Assisted Compliance](patterns/1-initial/assisted_compliance.md) - *Helping repo owners be compliant by writing their CONTRIBUTING.md for them as a pull request.*
 * [Open Source Trumps InnerSource](patterns/1-initial/open-source-trumps-innersource.md) - *Developers disregard InnerSource projects because they consider open source projects to be superior. Introducing a required evaluation of InnerSource projects before choosing an open source project increases the likelihood of the InnerSource projects to be adopted.*
-* [Transparent Governance Levels](patterns/1-initial/governance-levels.md) - *There are projects in multiple stages of InnerSource adoption. Contributors get confused when working with projects that are at different stages.*
 * [Governance Level Guided Project Setup](/patterns/1-initial/governance-based-project-setup.md) - *Before publishing their first InnerSource project, a team wants to choose an appropriate Governance Level but is unsure about the impact of the different levels on their daily doing. A dedicated list of resources (best practices, recommended patterns, target maturity levels) provides specific guidance to the team and helps them to make an educated decision.*
 * [Contained InnerSource](patterns/1-initial/contained-innersource.md) - *Apply InnerSource methods to facilitate collaboration in a cross-divisional project but don't invest in soliciting contributions from outside of that project.*
 * [Good First Project](patterns/1-initial/good-first-project.md) - *An InnerSource program has been launched at an organization, and to get off to a successful start it requires some good first projects that lend themselves to InnerSource-style development. Assessing the InnerSource-readiness (fitness) of the candidate projects can help in selecting projects that have the potential to help demonstrate the power of InnerSource.*

assets/img/flutter-pyramid.svg

@@ -27,6 +27,7 @@ Instead edit toc_template.md
 * [Cross-Team Project Valuation](../../patterns/2-structured/crossteam-project-valuation.md) - It's hard to sell the value of cross-team InnerSource projects that don't provide a direct impact on company revenue. Here's a data-driven way to represent your project that both articulates its value and amplifies it.
 * [Dedicated Community Leader](../../patterns/2-structured/dedicated-community-leader.md) - Select people with both communications and technical skills to lead the communities to ensure success in starting an InnerSource initiative.
 * [Document your Guiding Principles](../../patterns/2-structured/document-your-guiding-principles.md) - The usual InnerSource explanation of "applying open source best practices inside an organization" does not work well with people lacking an open source background. As a remedy the most important principles of InnerSource get documented and published widely.
+* [Explicit Governance Levels](../../patterns/2-structured/governance-levels.md) - Different teams within an organization use InnerSource practices in varying ways, leading to confusion and inefficiencies due to inconsistent expectations of collaboration and contribution rights. Establish centrally documented governance levels that define the extent of influence contributing teams can have on a project, improving clarity for contributors and host teams alike.
 * [Extensions for Sustainable Growth](../../patterns/2-structured/extensions-for-sustainable-growth.md) - An InnerSource project is receiving too many contributions, making maintenance difficult. By offering an extension mechanism outside of the core project, the maintainers enable scaling of project capabilities with minimal cost and maintenance overhead.
 * [Gig Marketplace](../../patterns/2-structured/gig-marketplace.md) - Establish a marketplace by creating an intranet website that lists specific InnerSource project needs as "Gigs" with explicit time and skill requirements.  This will enable managers to better understand their employee’s time commitment and professional benefits thereby increasing the likelihood of garnering approval to make InnerSource contributions.
 * [Group Support](../../patterns/2-structured/group-support.md) - What happens if a team or individual no longer supports an InnerSource project? Keep the project alive by forming a group of interested individuals.

assets/img/governance-levels/1.png

@@ -4,4 +4,4 @@ source "https://rubygems.org"
 
 git_source(:github) {|repo_name| "https://github.com/#{repo_name}" }
 
-gem 'commonmarker'
+gem 'commonmarker', "0.18.2"

assets/img/governance-levels/2.png

@@ -30,6 +30,10 @@
 
 ##### [Issue Tracker Use Cases](https://patterns.innersourcecommons.org/p/issue-tracker)
 
+#### Language around project governance is ambiguous
+
+##### [Explicit Governance Levels](https://patterns.innersourcecommons.org/p/governance-levels)
+
 ## Adopt
 
 ### Valuation Challenges
@@ -92,6 +96,10 @@
 
 ##### [Transparent Cross-Team Decision Making using RFCs](https://patterns.innersourcecommons.org/p/transparent-cross-team-decision-making-using-rfcs)
 
+#### Level of influence for contributing teams is unclear
+
+##### [Explicit Governance Levels](https://patterns.innersourcecommons.org/p/governance-levels)
+
 #### Project without an owner/maintainer
 
 ##### [Core Team](https://patterns.innersourcecommons.org/p/core-team)