Merge branch 'main' of https://github.com/caldeirav/InnerSourcePatterns

book/en/toc.md

@@ -34,7 +34,7 @@ Instead edit toc_template.md
 * [InnerSource Portal](../../patterns/2-structured/innersource-portal.md) - Potential contributors cannot easily discover InnerSource projects that they are interested in. By creating an intranet website that indexes all available InnerSource project information you enable contributors to learn about projects that might interest them and InnerSource project owners to attract an outside audience.
 * [Issue Tracker Use Cases](../../patterns/2-structured/issue-tracker.md) - The InnerSource host team fails to make not only plans and progress but also context for changes transparent. This is solved by increasing the use cases for the project issue tracker to also serve brainstorming, implementation discussion, and feature design.
 * [Maturity Model](../../patterns/2-structured/maturity-model.md) - Teams have started adopting InnerSource. The practice is spreading to multiple departments. However, the understanding of what constitutes an InnerSource project varies. The solution is to provide a maturity model to allow for teams to go through a self check and discover patterns and practices that they are not yet aware of.
-* [Praise Participants](../../patterns/2-structured/praise-participants.md) - After an inner source contribution, it's important to thank the contributor for their time and effort. This pattern gives guidance that not only effectively acknowledges the contribution but also engenders further engagement from the contributor and others.
+* [Praise Participants](../../patterns/2-structured/praise-participants.md) - When you receive an InnerSource contribution, it's important to thank the contributor for their time and effort. Extending your gratiutude not only effectively acknowledges the contribution but also engenders further engagement from the contributor and others. Praising contributors' positive contributions to your InnerSource project motivates those contributors (and their managers) to continue investing in the effort.
 * [Repository Activity Score](../../patterns/2-structured/repository-activity-score.md) - Potential contributors want to find active InnerSource projects in need of their help. By calculating a repository activity score for each project, a ranked list of projects can be created (e.g. on the InnerSource Portal), so that potential contributors can more easily determine which project they want to contribute to.
 * [Review Committee](../../patterns/2-structured/review-committee.md) - The InnerSource working model is a radical departure from more traditional approaches, for developers and managers alike. By establishing a review committee as an interface between the InnerSource initiative and all senior managers of business units participating in it, the latter are more likely to familiarize themselves with the initiative and support it, as it affords them a certain level of oversight and control without fostering micromanagement.
 * [Service vs. Library](../../patterns/2-structured/service-vs-library.md) - Teams in a DevOps environment may be reluctant to work across team boundaries on common code bases due to ambiguity over who will be responsible for responding to service downtime. The solution is to realize that often it's possible to either deploy the same service in independent environments with separate escalation chains in the event of service downtime or factor a lot of shared code out into one library and collaborate on that.

book/zh/toc.md

@@ -31,13 +31,16 @@ Instead edit toc_template.md
 * [内源门户网站](../../translation/zh/patterns/innersource-portal.md) - 潜在的贡献者很难找到他们感兴趣的内源项目。你可以通过创建一个索引所有可用的内源项目信息的内部网站，可以让贡献者了解他们可能感兴趣的项目，也可以让内源项目的负责人发展外部受众。
 * [利用RFC进行透明的跨团队决策](../../translation/zh/patterns/transparent-cross-team-decision-making-using-rfcs.md) - 内源项目如果想实现高参与率，并为每个参与者做出最好的决定，就需要想办法在整个软件生命周期中建立易于参与式的环境。发布内部征求意见稿（RFC）文件，可以在设计过程的早期就进行讨论，并促进在参与各方在高参与度下建立解决方案的机会。
 * [基准级的文档](../../translation/zh/patterns/base-documentation.md) - 内源项目的新贡献者很难搞清楚谁在维护这个项目，该做什么，以及如何贡献。在标准文件中提供文档，如README.md/CONTRIBUTING.md，可以为新的贡献者提供一个自助服务流程，这样他们就可以自己找到最常见问题的答案。
+* [小组支持](../../translation/zh/patterns/group-support.md) - 如果某个团队或个人不再支持 InnerSource 项目怎么办？ 由一群感兴趣的个人组成小组来保持项目活跃。
 * [成熟度模型](../../translation/zh/patterns/maturity-model.md) - 各个团队已经开始采用内源。这种做法正在向多个部门蔓延。然而，人们对什么是内源项目的理解各不相同。解决方案是提供一个成熟度模型，让团队通过自我检查，发现他们还没有意识到的模式和做法。
 * [服务 vs. 库](../../translation/zh/patterns/service-vs-library.md) - 由于对服务宕机责任的模糊不清，DevOps团队都不太愿意基于公共代码进行跨团队工作。 解决办法是让大家认识到通常情况下：要么在独立的环境中部署相同的服务，在服务宕机时有独立的问题处理兜底机制；要么将大量的共享代码纳入一个库，大家在此基础上进行协作。
+* [标准发布流程](../../translation/zh/patterns/release-process.md) - 如果团队不确定 InnerSource 项目的成熟度，他们可能会犹豫是否采用该项目。为了解决该问题，一致的发布说明和已发布制品至关重要。这些做法展示了对项目的坚定承诺，为用户提振了信心，并向他们保证了对可持续和管理良好的软件的持续承诺。
 * [核心团队](../../translation/zh/patterns/core-team.md) - 即使一个内源项目被广泛应用，但也可能因为项目难以协作而阻碍项目的贡献和使用。 建立一个核心团队，专门负责处理项目的基本事务。 他们的工作可以确保贡献者能够增加和使用满足他们自己使用场景需要的特性。
 * [签约贡献者](../../translation/zh/patterns/contracted-contributor.md) - 想为内源做贡献的同事被他们的直线管理层劝阻。正式的合同和协议为这种困境提供援助。
 * [记录你的指导原则](../../translation/zh/patterns/document-your-guiding-principles.md) - 通常内源对 "在组织内部应用开源最佳实践 "的解释对缺乏开源背景的人来说效果并不好。 作为一种补救措施，内源最重要的原则被记录下来并广泛宣传。
 * [评审委员会](../../translation/zh/patterns/review-committee.md) - 对于开发人员和管理人员来说，内源的工作模式与更多的传统方法截然不同。通过建立一个评审委员会，作为内源计划和所有参与该计划的业务部门高级管理人员之间的接口，后者更有可能更加熟悉并支持该计划，因为评审委员会为他们提供了一定程度的监督和控制，而不会助长微管理。
 * [跨团队的项目评估](../../translation/zh/patterns/crossteam-project-valuation.md) - 要推销跨团队的内源项目的价值是很难的，因为这些项目并没有对公司的收入产生直接影响。 这里有一个数据驱动的方法来展示和凸显你的项目价值。
+* [通过扩展实现可持续增长](../../translation/zh/patterns/extensions-for-sustainable-growth.md) - InnerSource 项目收到了太多的贡献，这会导致维护变得困难。通过在核心项目之外提供扩展机制，维护者可以用最小的成本和维护开销扩展项目功能。
 * [问题追踪器使用案例](../../translation/zh/patterns/issue-tracker.md) - 内源东道主团队不仅没有使计划和进展，而且也没有将变化背景信息变透明。这可以通过增加项目问题跟踪器的使用案例来解决，它也可以为头脑风暴、实施讨论和功能设计服务。
 * [零工市场](../../translation/zh/patterns/gig-marketplace.md) - 建立一个市场，创建一个内部网站，将特定的内源项目需求列为 "任务"，并提出明确的时间和技能要求。 这将使管理人员能够更好地了解员工的时间承诺和专业利益，从而增加获得批准做出内源贡献的可能性。
 

meta/boardreports/2024-05.md

@@ -0,0 +1,3 @@
+# InnerSource Patterns WG - Report for Board Meeting 2024-05
+
+The Patterns WG did not submit a report to this Board Meeting, due to a lack of time.

meta/boardreports/2024-08.md

@@ -0,0 +1,63 @@
+# InnerSource Patterns WG - Report for Board Meeting 2024-08
+
+## Meta
+
+* Reporting Period: 2024-05..2024-07
+* [merged PRs](https://github.com/InnerSourceCommons/InnerSourcePatterns/pulls?q=is%3Apr+closed%3A2024-05..2024-07+is%3Amerged)
+* [opened issues](https://github.com/InnerSourceCommons/InnerSourcePatterns/issues?q=is%3Aissue+created%3A2024-05..2024-07+is%3Aopen)
+
+## Engagement
+
+NOTE: no comparison to previous quarter as we did not submit a report then.
+
+The [patterns book][] is the way InnerSource practices are captured and shared. Recent web analytics:
+
+* total traffic on the patterns book (tracking_id: `G-QL1S8MW5D9`)
+  * 15,021 views total
+  * 1,897 users
+* Most popular patterns:
+  * Core Team
+  * Maturity Model
+  * InnerSource Portal
+  * 30 Day Warranty
+  * Standard Base Documentation
+* traffic for translations:
+  * Japanese (/v/ja) - no data in Google Analytics. no idea why.
+  * Chinese (/v/zh) - 545
+  * Brazilian Portuguese (/v/pt-br) - 358
+  * Galician (/v/gl) - 68
+
+## Changes
+
+Changes are contributed via the [InnerSourcePatterns][] repository:
+
+* new patterns:
+  * [Code of Conduct](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/1-initial/code-of-conduct.md) - thank you [rmarting](https://github.com/rmarting)
+  * [InnerSource Hackathon](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/1-initial/innersource-hackathon.md) - thank you [spriya-m](https://github.com/spriya-m)
+  * [Trusted Committer and Contributor Retrospectives](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/patterns/1-initial/cross-team-retrospectives.md) - thank you [MaineC](https://github.com/MaineC)
+  * especially exciting because the first two came from new or infrequent contributors
+* translations
+  * nothing new
+* additions of Known Instances (applications of our patterns in the wild)
+  * GitHub to new Code of Conduct pattern. Thank you @zkoppert
+* some additions to the glossary. still very few entries in the glossary, however we now [published](https://patterns.innersourcecommons.org/appendix/glossary) it in the patterns book. maybe that we motivate us to extend it.
+* would like to do one round of cleanup of old PRs/issues that are unlikely to still be implemented as they are stale for too long
+
+## Things to come
+
+* (still) toying with the idea to add [Adopters pages](https://innersourcecommons.gitbook.io/innersource-patterns-staging/v/adopters-test/adopters/adopters) to our book. Goal: showcase the organizations and the patterns they use more prominently in our book. Looking for feedback! More [details here](https://github.com/InnerSourceCommons/InnerSourcePatterns/issues/623).
+* Some PRs are stuck. Reason is mostly that I (@spier) have less time to review things or communication with the contributor stopped somewhere
+
+## Trusted Committers (Community)
+
+* Last [Trusted Committer][] added was [@yuhattor](https://github.com/yuhattor) (added 2022-07-21)
+* Trusted Committer candidates in the pipeline: No
+* Finding new contributors and further trusted committers continues to be the main challenge of the InnerSource Patterns project
+
+## Next Goals
+
+Same as previous Board report.
+
+[patterns book]: https://patterns.innersourcecommons.org/
+[InnerSourcePatterns]: https://github.com/InnerSourceCommons/InnerSourcePatterns/
+[Trusted Committer]: https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/TRUSTED-COMMITTERS.md

patterns/1-initial/innersource-hackathon.md

@@ -14,12 +14,14 @@ The company wants to adopt InnerSource as software development methodology but o
 
 ### Scenario 1: Challenges in scaling beyond the early adopters
 
-The senior leadership believes in InnerSource and wants to drive it throughout the company. The engineers who are familiar with open source principles and/or understand the benefits of InnerSource are the early adopters. There is success with these initial pilot project and teams. Now the next step is to drive it across the company. There might be reluctance from engineering teams due to various factors like:
+The senior leadership believes in InnerSource and wants to drive it throughout the company. The engineers who are familiar with open source principles and/or understand the benefits of InnerSource are the early adopters. There is success with these initial pilot project and teams.
 
-* not familiar with InnerSource and being ignorant to know about it
+Now the next step is to drive it across the company. There might be reluctance from engineering teams due to various factors like:
+
+* not familiar with InnerSource or open source practices
 * not enough time to prioritize InnerSource, given the regular work deliverables
-* relunctance to changing ways of working when everything works well already
-* perception that InnerSource requires more work and responsibilities
+* reluctance to changing ways of working when everything works well already
+* unclear return on investment for the upfront setup costs that an InnerSource project takes
 
 ### Scenario 2: Challenges in getting contributions and building community around InnerSource projects