Fixing merge conflict in README

Author: spier

.github/workflows/link-checker-prs.yml

@@ -21,7 +21,7 @@ jobs:
 
       - name: Get changed files
         id: changed-files
-        uses: tj-actions/changed-files@v45
+        uses: tj-actions/changed-files@v46
 
       - name: Filter markdown files only
         run: |

.lycheeignore

@@ -12,4 +12,5 @@ https://m.dotdev.co/how-to-write-a-readme-that-rocks-bc29f279611a
 https://www.chathamhouse.org/about-us/chatham-house-rule
 https://www.linkedin.com/in
 # from source-code-inventory.md / no longer reachable but we want to keep the link in the pattern in case we find it again.
-https://github.com/trieshard/source-strategy-assessment/blob/master/framework.md
+https://github.com/trieshard/source-strategy-assessment/blob/master/framework.md
+https://dl.acm.org/doi/10.5555/3158161.3158175

README.md

@@ -93,7 +93,8 @@ Our mission
 * [Circle Communities](/patterns/1-initial/circle-communities.md) - *InnerSource adoption is slow in organizations due to limited understanding, engagement, and contextual relevance. Circle Communities address this by fostering synchronous conversations that build connections, close knowledge gaps, and cultivate collaboration and continuous learning.*
 * [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.
+* [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.*
 * [Require InnerSource before Open Source](/patterns/1-initial/innersource-before-open-source.md) - *Maintaining and managing open source projects can be challenging for organizations, due to a lack of internal infrastructure and people with the knowledge of the required collaboration practices. By requiring projects to be InnerSource before becoming open source, teams have time to establish the necessary internal support, governance, and collaboration skills needed for successful community engagement.*
 
 <!--

meta/boardreports/2020-12.md

@@ -46,7 +46,7 @@
 - Process existing content from pull requests and Google group into our repository
 - Evaluate ideas to further facilitate collection of pattern content (e.g. through automation), channel ongoing discussions into pattern-work and attract more contributors, e.g. by lowering the barriers of entry for them.
 - Onboard further trusted committers
-- Review the current list of trusted committers. Some of them don’t seem to be active anymore and likely receive a lot of github notifcations and emails from us that they don't need. (do we have an offboarding process for TCs?)
+- Review the current list of trusted committers. Some of them don’t seem to be active anymore and likely receive a lot of github notifications and emails from us that they don't need. (do we have an offboarding process for TCs?)
 - Level up some patterns to higher maturity levels. e.g. the [InnerSource Portal](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/innersource-portal.md) has multiple known instances and even a reference implementation now, so it could be brought to maturity "Validated" relatively easily.
 
 ## Last Committer Addition

meta/boardreports/2021-01.md

@@ -60,7 +60,7 @@
     - Level up some patterns to higher maturity levels. e.g. the [InnerSource Portal](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/innersource-portal.md) has multiple known instances and even a reference implementation now, so it could be brought to maturity "Validated" relatively easily.
 - Process / Maintenance
     - Onboard further trusted committers
-    - Review the current list of trusted committers. Some of them don’t seem to be active anymore and likely receive a lot of github notifcations and emails from us that they don't need. (do we have an offboarding process for TCs?)
+    - Review the current list of trusted committers. Some of them don’t seem to be active anymore and likely receive a lot of github notifications and emails from us that they don't need. (do we have an offboarding process for TCs?)
     - Process existing content from PRs and Google group into our repository (once that is done we can focus on the contribution process via the GitHub repo exclusively)
 
 ## Last Committer Addition

meta/pattern-system.md

@@ -78,12 +78,12 @@ our InnerSource pattern system.
 
 Takashi Iba has published an article in the ACM Digital Library from PLoP 2016:
 [A pattern language for creating pattern languages: 364 patterns for pattern
-mining, writing, and symbolizing](https://dl.acm.org/citation.cfm?id=3158175&CFID=831673585&CFTOKEN=74341142&qualifier=LU1011674)
+mining, writing, and symbolizing](https://dl.acm.org/doi/10.5555/3158161.3158175)
 
 - for those without ACM DL access, there is [an earlier draft of the paper from
 PLoP 2016](http://www.hillside.net/plop/2016/papers/three/26.3.pdf).
 
-## Candiate Classifications
+## Candidate Classifications
 
 This section shall serve to collect individual proposals for systems of ISC
 patterns. Contribute away ;)
@@ -196,7 +196,7 @@ talk "InnerSource 101 and The Apache Way"[1] as a way to characterize patterns:
 * Community
 * Meritocracy
 
-And in addition, this would have some ortogonal techniques to work on building
+And in addition, this would have some orthogonal techniques to work on building
 a proper transparency (for instance) that could go from the infrastructure to
 be used to monitoring the process and produce surveys, training and other
 actions.
@@ -244,7 +244,7 @@ potential characterization based on the companies structure?
 
 I like a lot of the other planes suggestions.  Wanted to add one more - the point in the lifecycle of the InnerSource project.  Does this pattern apply to:
 
-* Pre-launch (prepration to launch) an InnerSource project?
+* Pre-launch (preparation to launch) an InnerSource project?
 * Launch (initial kick-off)?
 * Initial growth?
 * Broad adoption?

meta/pattern-template.md

@@ -82,5 +82,5 @@ Though optional, most patterns should list who helped in their creation.
 
 ## Alias (optional)
 
-If this pattern is also known under a different name than what is listed unter **Title**, please list those alternative titles here.
+If this pattern is also known under a different name than what is listed under **Title**, please list those alternative titles here.
 e.g. if the pattern is named after the problem it solves, a helpful alias might be one that describes the solution that is applied.

pattern-categorization/package-lock.json

@@ -71,7 +71,7 @@ The InnerSource program does not live up to its expectations because middle mana
 
 * Empowering Middle Management - InnerSource readiness checklist; Middle Management should partner with their developers. What are the opportunities out there. Can we come up with justification for you to spend any time on this (how does this tie together with our KPIs)
 
-* If the organzation is doing Agile development, during release planning, time and resources for InnerSource practices should be built into sprints.
+* If the organization is doing Agile development, during release planning, time and resources for InnerSource practices should be built into sprints.
 
 * **1 step back, 3 steps forward** (aka "the tax"): If my team contributes, what's the tax (in terms of time/resources)?
   * Finding opportunities for contribution

patterns/1-initial/change-the-middle-management-mindset.md

@@ -71,7 +71,7 @@ Important elements of the solution are:
   - How to collect feedback effectively on the ADR/TDR from diverse stakeholders, ensuring a broad range of input.
   - How to incorporate the feedback and adjust the ADR/TDR as needed.
   - How to move the ADR/TDR towards a conclusion or final decision (e.g., with sign-off from relevant maintainers or decision-makers).
-  - The use of appropriate tools, considering that non-technical stakeholders may not have direct access to source control or specialized software. Publish the decsions to a website or wiki.
+  - The use of appropriate tools, considering that non-technical stakeholders may not have direct access to source control or specialized software. Publish the decisions to a website or wiki.
 - **A commitment to iterating on the ADR/TDR templates and process**:
   - Regularly refining the ADR/TDR templates and associated processes based on feedback and the evolving needs of the organization.
 
@@ -180,7 +180,7 @@ The ADR/TDR approach also carries risks that a team want to acknowledge:
 
 ## Rationale
 
-InnerSource projects that want to achieve high participation rates and make the best possible decisions for everybody involved need to find ways to create participatory format for all system components, tools and workflows. Michael Nygard announced 2011 the idea to document architecture decision with a simple markdown template and shared it with a simple git project. Today this **ADR tool** is well proven and a many of teams around the globe use **Architecture Desicion Records (ADRs)** to document there design desicions.
+InnerSource projects that want to achieve high participation rates and make the best possible decisions for everybody involved need to find ways to create participatory format for all system components, tools and workflows. Michael Nygard announced 2011 the idea to document architecture decision with a simple markdown template and shared it with a simple git project. Today this **ADR tool** is well proven and a many of teams around the globe use **Architecture Decision Records (ADRs)** to document there design decisions.
 
 Another important aspect of defining architectural decisions is documenting consequences. In Technical Debt Records, Dr. Michael Stal explores the systematic tracking and management of technical debt in software development using **Technical Debt Records (TDRs)**. Similar to how Architecture Design Records (ADRs) capture architectural decisions, TDRs document trade-offs in code quality made to accelerate delivery. The TDRs provides a detailed template for documenting technical debt, and Christoph Kappel  introduces a record tool to streamline the process of ADRs and TDRs.