Suggesting changes to new "Walk the InnerSource talk" pattern

README.md

@@ -94,6 +94,7 @@ Our mission
 * [Internal Developer Platform](/patterns/1-initial/internal-developer-platform.md) - *As InnerSource adoption increases throughout an organisation, it is not unusual that project teams start to face inefficiencies in scaling their efforts due to fragmented tooling, environments, and workflows. An Internal Developer Platform (IDP) provides a way to tackle this type of challenges through a centralized, self-service system that standardizes development environments and integrates tools to enhance consistency, collaboration, and developer productivity.*
 * [Document Architecture Decisions](/patterns/1-initial/document-architecture-decisions.md) - *InnerSource contributors often face challenges in grasping the system's design rationale, which can result in misalignment between maintainers, contributors, and stakeholders — potentially discouraging participation. To enhance decision-making and transparency, we recommend capturing architecture decisions and their consequences in a lightweight, accessible format to streamline onboarding, clarify decisions, and support long-term project sustainability.*
 * [InnerSource Incentives and Disincentives](/patterns/1-initial/incentives-and-disincentives.md) - *Lack of awareness for incentives as well well as disincentives for InnerSource contribution decrease the chances of an InnerSource project receiving contributions; this is addressed by sharing a comprehensive list of potential incentives and disincentives.
+* [Walk the InnerSource talk](/patterns/1-initial/walk-the-innersource-talk.md) - *Teams across the organization are encouraged to adopt InnerSource principles such as working openly, sharing code, and collaborating transparently. But, if the team behind the InnerSource initiative doesn’t follow these practices themselves, it undermines credibility and adoption. Therefore, this team should lead by example: documenting their decisions as code, working in the open, and treating their work as an InnerSource project to build trust and show others how it’s done.*
 
 <!--
 NOTE: The 'Initial' Patterns below don't have a Patlet yet, which is essential for readers to quickly browse our patterns.

patterns/1-initial/walk-the-innersource-talk.md

@@ -17,7 +17,7 @@ organization. However, if the team itself does not adhere to these principles, o
 rhetoric rather than a transformative practice. Without leading by example, adoption and trust in InnerSource
 initiatives may suffer.
 
-## Story (optional)
+## Story
 
 At Siemens, when the InnerSource journey began, many of the early contributors were deeply inspired by the Open Source
 culture, several were also active participants in community projects. For them, setting up an InnerSource platform
@@ -49,8 +49,8 @@ are often used to working behind closed doors. Decision-making happens in meetin
 scattered, and ownership is unclear. Shifting to transparent, open collaboration requires both cultural change and a
 reevaluation of existing workflows.
 - Working in the open can feel scary - when everything is public, people might hold back from contributing because they worry their work isn't perfect enough. This fear of not being "good enough" can stop many valuable ideas from being shared.
-- People in central roles may fear scrutiny, overload from unsolicited input, or loss of control. Additionally, moving
-towards open collaboration demands more discipline in documentation, async communication, and community management -
+- People in central roles may fear scrutiny, overload from unsolicited input, or loss of control.
+- Moving towards open collaboration demands more discipline in documentation, async communication, and community management -
 skills not always prioritized in internal tooling teams.
 
 ### What are the trade-offs?
@@ -59,14 +59,11 @@ skills not always prioritized in internal tooling teams.
   increases acceptance, especially when people feel included in the process. However, it also requires a mindset shift:
   embracing open discussion, being comfortable with disagreement, and being willing to justify decisions in public and
   potentially critical forums.
-
 - **Speed vs. Quality**: working transparently can slow things down in the short term compared to quick, closed
   decision-making. However, this slower pace often leads to higher-quality outcomes: better-informed decisions, fewer
   misunderstandings, and solutions that are easier to maintain.
-
 - **Effort vs. Reuse**: documenting decisions, maintaining contribution guidelines, and curating issues takes time. But
 this investment leads to higher reusability, easier onboarding, and better scaling of knowledge.
-
 - **Risk vs. Trust**: opening up work may expose mistakes or half-finished ideas. But by showing authentic work in
 progress, teams build credibility and foster trust across organizational boundaries.
 
@@ -76,6 +73,13 @@ expectations, improves trust in the initiative, and helps shift the broader orga
 
 ## Solutions
 
+Rather than **telling** the teams in your organization how to practice InnerSource, find ways to **show** them how to do it.
+
+This role-modelling of the desired behaviors can be done by any team. However the more central that team is, i.e. the more touch points it has with other teams,
+the more effective this role-modelling will be as it disseminates the InnerSource behaviors into many different teams and parts of the organization.
+
+Therefore, we recommend to identify some central teams (e.g. platform teams, DevEx teams, enablement teams, or maybe even the team behind the InnerSource initiative to do this role-modelling.
+
 ✅ Verified Resolutions
 
 These have been successfully applied in real-world InnerSource initiatives (including at Siemens) and are known to help
@@ -123,18 +127,15 @@ Committer Base" or "InnerSource Project Lifecycle Management" to ensure sustaina
 
 ## Known Instances
 
-- At Siemens, the experts behind the InnerSource initiative applied the same principles they advocated, developing key
+- **Siemens** - The experts behind the InnerSource initiative applied the same principles they advocated, developing key
 assets such as documentation portals and contribution tooling transparently in shared repositories. Discussions about
 governance, onboarding, and platform features were handled openly using issue trackers and pull requests. This visible
 commitment to openness not only boosted trust among developers but also encouraged other teams to adopt similar
 practices, accelerating InnerSource adoption organically across departments.
 
-## Status (optional until merging)
+## Status
 
-> General pattern status is stored in GitHub's Label tagging - see any pull request. Note that this GitHub label tagging
-  becomes less visible once the pattern is finalized and merged, so having some information in this field is helpful.
-  You might store other related info here, such as review history: "Three of us reviewed this on 2/5/17 and it needs
-  John's expertise before it can go further."
+- Initial
 
 ## Author(s)
 
@@ -150,3 +151,10 @@ practices, accelerating InnerSource adoption organically across departments.
 - Ercan Uçan (Siemens AG)
 - Fabio Huser (Siemens AG)
 - Max Wittig (Siemens AG)
+
+## Alias
+
+- Show, don't tell
+- Lead by example
+- Dogfooding the InnerSource behaviors
+- Role-modelling the InnerSource behaviors