chore: fix typos in pattern system and board reports (#816)

pstoeckle · web-flow · commit 9118b190d1f5 · 2025-05-07T17:25:00.000+02:00
diff --git a/meta/boardreports/2020-12.md b/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
diff --git a/meta/boardreports/2021-01.md b/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
diff --git a/meta/pattern-system.md b/meta/pattern-system.md
@@ -83,7 +83,7 @@ mining, writing, and symbolizing](https://dl.acm.org/citation.cfm?id=3158175&CFI
 - 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?
diff --git a/meta/pattern-template.md b/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.
diff --git a/patterns/1-initial/change-the-middle-management-mindset.md b/patterns/1-initial/change-the-middle-management-mindset.md
@@ -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
diff --git a/patterns/1-initial/document-architecture-decisions.md b/patterns/1-initial/document-architecture-decisions.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.
 
diff --git a/patterns/1-initial/innersource-hackathon.md b/patterns/1-initial/innersource-hackathon.md
@@ -45,7 +45,7 @@ For those new to InnerSource or any technology/methodology, there is a need for
 
 Organize a company-wide hackathon focused on InnerSource. An InnerSource hackathon provides a safe space for engineers to try and contribute to InnerSource projects without any presumption and prejudice. It could be a 1 or 2 day event.
 
-It can preferrable be organized by InnerSource Program Office (ISPO), if it exists in the organization or by the Open Source Program Office (OSPO), if OSPO also drives InnerSource within the company. It can also be organized by other common service organizations too, if need be. Basically a central team or a group of individuals, who believe in InnerSource, can organize the hackathon.
+It can preferable be organized by InnerSource Program Office (ISPO), if it exists in the organization or by the Open Source Program Office (OSPO), if OSPO also drives InnerSource within the company. It can also be organized by other common service organizations too, if need be. Basically a central team or a group of individuals, who believe in InnerSource, can organize the hackathon.
 
 All engineers in the organization can participate in the hackathon. The participants can be new to InnerSource, or InnerSource practitioners already. They can participate individually or as a team. Participating as a team also provides a safe environment, for example, those are new to InnerSource can team up InnerSource practitioners.
 
