🇨🇳 Chinese: Content Consistency Issue

[github-actions]

i18n Contents Consistency Issue

The following files may have consistency issues with the English version. Please check and update the files.

This issue is created when any of the English patterns have changed (in folder ). It compares the git update history to let you know what updates are overdue. The issue should be closed when the update is complete.

Maturity Model (patterns/2-structured/maturity-model.md)

For more information, please compare the original file(en) with the translated file. You can view the differences on GitHub. The number of days since overdue updates is 372 days.

# diff --git a/patterns/2-structured/maturity-model.md b/patterns/2-structured/maturity-model.md
# index 8e41062..629c2e4 100644
# --- a/patterns/2-structured/maturity-model.md
# +++ b/patterns/2-structured/maturity-model.md
@@ -213,6 +213,7 @@ long term.
 * Entelgy
 * Zylk
 * Bitergia
+* Airbus
 
 ## Authors
 

Standard Base Documentation (patterns/2-structured/base-documentation.md)

For more information, please compare the original file(en) with the translated file. You can view the differences on GitHub. The number of days since overdue updates is 247 days.

# diff --git a/patterns/2-structured/base-documentation.md b/patterns/2-structured/base-documentation.md
# index bd20b82..7fb1dfd 100644
# --- a/patterns/2-structured/base-documentation.md
# +++ b/patterns/2-structured/base-documentation.md
@@ -137,10 +137,7 @@ started right away: [README-template.md](templates/README-template.md),
 ## Authors
 
 * Isabel Drost-Fromm
-
-## Acknowledgments
-
-* Katie Schueths - for adding the `COMMUNICATION.md` concept
+* Katie Schueths - added the `COMMUNICATION.md` concept
 
 ## Alias
 
@@ -153,8 +150,9 @@ Provide standard base documentation through a README
 
 ## References
 
-* [README-template.md](templates/README-template.md) and
+* [README-template.md](templates/README-template.md)
 * [CONTRIBUTING-template.md](templates/CONTRIBUTING-template.md)
+* [COMMUNICATION-template.md](templates/COMMUNICATION-template.md)
 
 ## Credits
 

30 Day Warranty (patterns/2-structured/30-day-warranty.md)

For more information, please compare the original file(en) with the translated file. You can view the differences on GitHub. The number of days since overdue updates is 236 days.

# diff --git a/patterns/2-structured/30-day-warranty.md b/patterns/2-structured/30-day-warranty.md
# index 962301d..b21ab81 100644
# --- a/patterns/2-structured/30-day-warranty.md
# +++ b/patterns/2-structured/30-day-warranty.md
@@ -49,7 +49,7 @@ In addition it helps to provide clear [contribution guidelines](./base-documenta
 - This was tried and proven successful at PayPal.
 - GitHub internally uses this pattern with a modified warranty timeline of 6 weeks.
 - Microsoft recommends this pattern as a principle - teams set their own specific time target matching their needs and confidence.
-- SAP - see: [InnerSource: First Contribution Explored](https://community.sap.com/t5/open-source-blogs/innersource-first-contribution-explored/ba-p/13644916)
+- SAP leverages this pattern in their InnerSource-based Everest project to transform collaboration, ensuring contributions are not just accepted but also supported, enhancing trust and driving forward the culture of shared responsibility and innovation. See: [InnerSource: First Contribution Explored](https://community.sap.com/t5/open-source-blogs/innersource-first-contribution-explored/ba-p/13644916)
 
 ## Authors
 

Start as an Experiment (patterns/2-structured/start-as-experiment.md)

For more information, please compare the original file(en) with the translated file. You can view the differences on GitHub. The number of days since overdue updates is 372 days.

# diff --git a/patterns/2-structured/start-as-experiment.md b/patterns/2-structured/start-as-experiment.md
# index 53326df..56e0c7d 100644
# --- a/patterns/2-structured/start-as-experiment.md
# +++ b/patterns/2-structured/start-as-experiment.md
@@ -54,6 +54,7 @@ Finally, starting as an experiment makes it much easier to sidestep regulations
 ## Known Instances
 
 - Robert Bosch GmbH (globally distributed software development)
+- Airbus: the data science community collaborated on shared Python libraries that eventually lead to a group-wide InnerSource scheme for any software.
 
 ## Status
 

Praise Participants (patterns/2-structured/praise-participants.md)

For more information, please compare the original file(en) with the translated file. You can view the differences on GitHub. The number of days since overdue updates is 98 days.

# diff --git a/patterns/2-structured/praise-participants.md b/patterns/2-structured/praise-participants.md
# index 263408d..b8c32b2 100644
# --- a/patterns/2-structured/praise-participants.md
# +++ b/patterns/2-structured/praise-participants.md
@@ -38,7 +38,8 @@ For non-trivial contributions (all code contributions and significant time contr
 
 (1) Call out the person by name in any chat location (e.g. _Slack_) where you organize your project activity.
 Let everyone know what they did and thank them publicly.
-For example:
+
+Example:
 
 > Everyone @here give a high-five to @andrew.clegg for updating the _rcs-viewer_ to the latest version of the _hebo-client_ (https://github.com/rcs/rcs-viewer/pull/81).
 > Thanks for helping keep this library up-to-date, Andy!

Communication Tooling (patterns/2-structured/communication-tooling.md)

For more information, please compare the original file(en) with the translated file. You can view the differences on GitHub. The number of days since overdue updates is 364 days.

# diff --git a/patterns/2-structured/communication-tooling.md b/patterns/2-structured/communication-tooling.md
# new file mode 100644
# index 0000000..08b1a33
# --- /dev/null
+++ b/patterns/2-structured/communication-tooling.md
@@ -0,0 +1,96 @@
+## Title
+
+Communication Tooling
+
+## Patlet
+
+The users of an InnerSource project have trouble getting help and getting in touch with the host team.
+By consistently using asynchronous communication tooling, the project makes discussions visible, archived and searchable, leading to an improved level of support for users.
+
+## Problem
+
+A team is open to receiving contributions from downstream users of their
+component. Coordination and communication happens in an ad hoc fashion though
+leading to incoherent information being shared, delays in answers received,
+contributors pinging multiple host team members before receiving a definitive
+answer.
+
+## Context
+
+- A team depends on another team's component.
+- It would like to make contributions to that component.
+- Even when it happens in writing, communication happens in a 1-on-1 fashion.
+
+## Forces
+
+- The host team is interested in receiving contributions and willing to mentor contributors.
+- Teams have a strong verbal communication culture and are inexperienced with setting up project specific asynchronous communication channels.
+- Communication channels may be aligned with specific groups that should be reached but not by communication purpose.
+
+## Solution
+
+The host team should provide company-public, archived, searchable, linkable communication channels that anyone in the company can subscribe to, as there are measurable benefits to supporting open, written communications channels.
+
+The goal when streamlining communication channels for InnerSource projects
+should be to align communication around topics, not around certain sets of
+people.
+
+A project should set up the following communication tooling:
+
+1. **a dedicated issue tracker** where structured communication, decision-making and progress tracking can happen transparently for all host team members but also for downstream users and contributors to follow. For further applications of the issue tracker see [Issue Tracker Use Cases](./issue-tracker.md).
+2. **public discussion channel(s)** that come with less rigid a structure. Typically, this will be mailing lists, online forums, Q&A systems or even archived chat channels. Usually it is enough to start with just one channel for the project. If traffic increases too much it is helpful to split discussions about project usage from discussions about project development.
+3. **a private channel** where communication about sensitive topics can happen between [Trusted Committers](./trusted-committer.md) - e.g. adding further Trusted Committers to the host team. This channel should be used with great care such that communication defaults to open and is kept private only under very rare circumstances.
+
+While communication can happen outside of those written channels, as much information as possible should be brought back to the asynchronous channels.
+
+All communication channels should be documented in the project `README.md`. For more details on the use of this file see [Standard Base Documentation](./base-documentation.md).
+
+The host team members need to make an effort to direct questions that they receive personally (e.g. via email or private chat messages) back to official communication channels.
+
+![Recommended Communication Tooling for an InnerSource Project](../../assets/img/communication-tooling/communication-tooling.png)
+
+## Resulting Context
+
+Setting up and consistently using official asynchronous communication channels
+helps create a base level of [passive documentation](https://www.oreilly.com/library/view/understanding-the-innersource/9781491986899/ch04.html) that can be referenced again when similar questions come up again.
+
+With communication happening in the open others can easily follow project
+progress and get active contributing. Others lurking and reading lowers the
+barrier to get involved raising the likelihood of receiving contributions.
+
+With questions being answered in public more people can add their perspective
+leading to a complete picture - this includes not only host team members,
+but also users of the project.
+
+Keeping communication in asynchronous channels allows for participants on
+different schedules - either due to different time zones or due to different
+routines, meeting schedules, team routines - to meaningfully contribute to
+the project.
+
+Answering questions in those channels means that not only other team members
+can listen in and provide additional information, it also means that other
+users with the same question see (or later find) the previous answer leading
+to a lower need to repeat explanations.
+
+## Known Instances
+
+* Europace AG
+* Paypal Inc.
+* Mercado Libre
+
+## Authors
+
+Isabel Drost-Fromm
+
+## Acknowledgment
+
+Sebastian Spier (for the visual)
+
+## Status
+
+* Structured
+* Drafted in December 2019.
+
+## Credits
+
+[People](https://storyset.com/people) illustrations by Storyset

Dedicated Community Leader (patterns/2-structured/dedicated-community-leader.md)

For more information, please compare the original file(en) with the translated file. You can view the differences on GitHub. The number of days since overdue updates is 372 days.

# diff --git a/patterns/2-structured/dedicated-community-leader.md b/patterns/2-structured/dedicated-community-leader.md
# index 91f3c3d..8f5235d 100644
# --- a/patterns/2-structured/dedicated-community-leader.md
# +++ b/patterns/2-structured/dedicated-community-leader.md
@@ -59,6 +59,7 @@ Having excellent and dedicated community leaders is a precondition for the succe
 ## Known Instances
 
 * _BIOS at Robert Bosch GmbH_. Note that InnerSource at Bosch was, for the majority, aimed at increasing innovation and to a large degree dealt with internal facing products. This pattern is currently not used at Bosch for lack of funding.
+* _Airbus_. A data scientist wanted to improve the collaboration with peers in the group and found: i) many developers (beyond data science) wanted that too and were happy someone was taking care of the issue, and ii) support from line manager and middle management to eventually act as the _de facto_ community leader, on top of his regular line of duty.
 
 ## Alias
 

Repository Activity Score (patterns/2-structured/repository-activity-score.md)

For more information, please compare the original file(en) with the translated file. You can view the differences on GitHub. The number of days since overdue updates is 364 days.

# diff --git a/patterns/2-structured/repository-activity-score.md b/patterns/2-structured/repository-activity-score.md
# index 27421a6..dae8f3e 100644
# --- a/patterns/2-structured/repository-activity-score.md
# +++ b/patterns/2-structured/repository-activity-score.md
@@ -115,7 +115,7 @@ The repository activity score is a simple calculation based on the GitHub API. I
 ## Known Instances
 
 * Used in SAP's InnerSource project portal to define the default order of the InnerSource projects. It was first created in July 2020 and is fine-tuned and updated frequently ever since. When proposed to the InnerSource Commons in July 2020, this pattern emerged. Also see [Michael Graf & Harish B (SAP) at ISC.S11 - The Unexpected Path of Applying InnerSource Patterns](https://www.youtube.com/watch?v=6r9QOw9dcQo&list=PLCH-i0B0otNQZQt_QzGR9Il_kE4C6cQRy&index=6).
-* Airbus took a lot of inspiration from this pattern to create an "InnerSource score" that combines the activity score together with checks from the [Standard Base Documentation](./project-setup/base-documentation.md) and the [InnerSource License](./innersource-license.md).
+* Airbus took a lot of inspiration from this pattern to create an "InnerSource score" that combines the activity score together with checks from the [Standard Base Documentation](./base-documentation.md) and the [InnerSource License](./innersource-license.md).
 
 ## Status
 

Common Requirements (patterns/2-structured/common-requirements.md)

For more information, please compare the original file(en) with the translated file. You can view the differences on GitHub. The number of days since overdue updates is 251 days.

# diff --git a/patterns/2-structured/common-requirements.md b/patterns/2-structured/common-requirements.md
# index 0381be2..b2c688e 100644
# --- a/patterns/2-structured/common-requirements.md
# +++ b/patterns/2-structured/common-requirements.md
@@ -16,7 +16,7 @@ The common code in the shared repository isn't meeting the needs of all the proj
 * Someone (or some project) wrote the code in the first place and contributed it to the repository.
 * The common code is a small percentage of the overall deliverable from any of the projects.
 * Each project has its own delivery schedule, set of deliverables and customers.
-* This pattern applies in either of these situations:
+* This pattern applies in any of these situations:
     * there is a **Strong Code Owner** i.e. all changes to the shared repository have to be approved by the repo owner
     * there is **weak code ownership** i.e. no one really owns the code
     * there is **no Benevolent Sponsor** i.e. no organization or executive is providing resources to organize the common code in an InnerSource fashion

InnerSource License (patterns/2-structured/innersource-license.md)

For more information, please compare the original file(en) with the translated file. You can view the differences on GitHub. The number of days since overdue updates is 231 days.

# diff --git a/patterns/2-structured/innersource-license.md b/patterns/2-structured/innersource-license.md
# index 4c8eb6a..bc031e9 100644
# --- a/patterns/2-structured/innersource-license.md
# +++ b/patterns/2-structured/innersource-license.md
@@ -31,7 +31,7 @@ At the time of sharing the source code, it can not be reliably predicted what th
 - Freedom over using the software leads to competition, and spread of ownership
 - There are legal contracts in place which cover the sharing of source code. These contracts are not standardized, so they create additional effort in negotiating and understanding for every project. The existing contracts may also not allow sharing source code in an open enough sense to support a true InnerSource approach.
 - Alternatively, there are no legal contracts in place but source code is shared informally. That might create uncertainty in cases where clarity about ownership and rights and obligations is needed.
-- Choosing a restrictive and/or copyleft license can constitute a barrier for InnerSource adoption. Specifically, limiting publication to the organisation might require a costly relicensing procedure prior to transitioning to Open Source.
+- Choosing a restrictive and/or copyleft license can constitute a barrier for InnerSource adoption. Specifically, limiting publication to the organization might require a costly relicensing procedure prior to transitioning to Open Source.
 
 ## Solutions
 

Review Committee (patterns/2-structured/review-committee.md)

For more information, please compare the original file(en) with the translated file. You can view the differences on GitHub. The number of days since overdue updates is 360 days.

# diff --git a/patterns/2-structured/review-committee.md b/patterns/2-structured/review-committee.md
# index e1a47e4..f27d793 100644
# --- a/patterns/2-structured/review-committee.md
# +++ b/patterns/2-structured/review-committee.md
@@ -30,6 +30,7 @@ Company A wants to introduce its first InnerSource initiative. Most managers in
 - Every InnerSource project is to be given the chance to react to feedback received on one session of the review committee until the next session in order to avoid shutting down the project prematurely.
 - An InnerSource project leader can also present the motion to be shut down on its own initiative on a review committee. The review committee then has to decide whether or not the business units using the software need to be given time to put measures in place to ensure that development and/or maintenance of the codebase continues until an alternative solution to development by the InnerSource community is found (if business relevant or mission critical).
 - The review committee should convene regularly. A cadence of two meetings per year has proven successful.
+- The review committee can become optional, if InnerSource has been widely adopted and understood by the organization.
 
 ![Review Committee Sketch](../../assets/img/review-committee-sketch.jpg)
 
@@ -40,7 +41,7 @@ Company A wants to introduce its first InnerSource initiative. Most managers in
 
 ## Known Instances
 
-* BIOS at Robert Bosch GmbH
+* BIOS at Robert Bosch GmbH (in the early stages of adoption, only - 2009-2012)
 
 ## Status
 

InnerSource Portal (patterns/2-structured/innersource-portal.md)

For more information, please compare the original file(en) with the translated file. You can view the differences on GitHub. The number of days since overdue updates is 96 days.

# diff --git a/patterns/2-structured/innersource-portal.md b/patterns/2-structured/innersource-portal.md
# index e362a61..37e7e4f 100644
# --- a/patterns/2-structured/innersource-portal.md
# +++ b/patterns/2-structured/innersource-portal.md
@@ -104,7 +104,7 @@ It is a good solution for a portal with a few dozen projects, though.
 
 ![Santander InnerSource Portal](../../assets/img/santander_portal.png "Banco Santander InnerSource Portal")
 
-* **Airbus** used the [SAP Portal](https://github.com/SAP/project-portal-for-innersource) as a Proof of Concept. It is now using the [Bazaar plugin](https://github.com/backstage/backstage/blob/master/plugins/bazaar/README.md) of [Backstage](https://backstage.io) as the latter became the official developer experience tool internally. It provides a convenient self-registering capability for all the divisions.
+* **Airbus** used the [SAP Portal](https://github.com/SAP/project-portal-for-innersource) as a Proof of Concept. It is now using the [Bazaar plugin](https://github.com/backstage/community-plugins/blob/main/workspaces/bazaar/plugins/bazaar/README.md) of [Backstage](https://backstage.io) as the latter became the official developer experience tool internally. It provides a convenient self-registering capability for all the divisions.
 * **Mercado Libre** use an instance of the [SAP portal](https://github.com/SAP/project-portal-for-innersource) to discover existing InnerSource projects within the organization.
 * **Mercedes-Benz** is [using](https://opensource.mercedes-benz.com/news/sponsor_innersource_commonsoss) the SAP reference implementation mentioned above for their InnerSource Portal.
 * **WellSky** has a simple _Confluence Wiki_ page were InnerSource and reusable projects are listed.

Issue Tracker Use Cases (patterns/2-structured/issue-tracker.md)

For more information, please compare the original file(en) with the translated file. You can view the differences on GitHub. The number of days since overdue updates is 364 days.

# diff --git a/patterns/2-structured/issue-tracker.md b/patterns/2-structured/issue-tracker.md
# new file mode 100644
# index 0000000..ffbda05
# --- /dev/null
+++ b/patterns/2-structured/issue-tracker.md
@@ -0,0 +1,60 @@
+## Title
+
+Issue Tracker Use Cases
+
+## Patlet
+
+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.
+
+## Problem
+
+A team develops a component that many teams in the organization depend on. It
+uses a standard issue tracker for tracking open bugs and feature requests.
+However, the context in each entry is very limited. As a result potential
+contributors have no way of knowing what change exactly each issue is talking
+about.
+
+## Context
+
+The InnerSource project tooling is all setup. However, the project issue tracker
+is mainly used for sharing progress. In InnerSource projects there are many more
+use cases that an issue tracker can be used for that make remote, asynchronous
+communication easier.
+
+## Forces
+
+- Contributors would like to understand whether the feature that they are missing is already on the roadmap. With a lot of context missing in issues though it is impossible to decide whether existing issues match the contributing team's needs.
+- As a result a lot of duplicate issues are being opened that the host team has to deal with.
+- As context in open issues is so limited contributors are unable to help the host team by implementing some easier issues that are open already. As a result a lot of work remains in the hands of the host team.
+- With a strong focus on verbal communication it is impossible to discern after a couple months or years why a certain feature was being chosen for implementation. As a result refactorings, in particular simplifying the component becomes an exercise in project archaeology and brain picking of people who remember what was discussed.
+
+## Solution
+
+Embrace the "written over verbal" philosophy not only for pure software
+development but also during the planning phase of new features:
+
+- For bugs, planned features and feature ideas create separate issues. In each of those include as much information as possible so that potential external contributors are able to understand the context. Ideally, in particular for easier changes, include enough information for external contributors to support the host team by implementing the functionality in question.
+- Potentially use the issue tracker as a channel to ask questions. This is in particular helpful if you are lacking other communication sources to tackle user questions.
+- Make use of tags and categories in order to distinguish issues used for different purposes.
+- For starting a brainstorming session asynchronously, open an issue for gathering ideas. When discussion is starting to calm down, summarize the points identified in this issue in a separate document. Post that for review as a pull request to drill deeper into individual points that still need clarification. The resulting document can be used to publish the results in other appropriate channels as well as for future reference.
+- Most issue tracker implementations allow for issue templates. Make use of those not only to collect commonly needed information for bug reports but also include hints about what kind of information is needed for the other usage types.
+
+## Resulting Context
+
+- Making more use of the project's issue tracker for communication enables external contributors to follow along and make better decisions on what to contribute.
+- A focus on structured written communication enables host team members to participate remotely.
+- Consistently communicating in writing means that passive documentation on project decisions accumulates as a by-product instead of needing added attention.
+- Consistently using public communication channels leads to more humans following a discussion. This means that there are more knowledgeable humans that can answer questions, chime in on open issues, or point out flaws in planned features that would otherwise be found only much later.
+- Moving discussions to a public discussion medium creates an opportunity for potential future contributors to lurk, follow along, get comfortable and learn the ways of the project long before they have the first need to get involved.
+
+## Known Instances
+
+* Europace AG - See blog post [Issue Use Cases](https://tech.europace.de/post/using-issues-for-asking-questions-and-tracking-work/)
+
+## Authors
+
+Isabel Drost-Fromm
+
+## Status
+
+Structured

Transparent Cross-Team Decision Making using RFCs (patterns/2-structured/transparent-cross-team-decision-making-using-rfcs.md)

For more information, please compare the original file(en) with the translated file. You can view the differences on GitHub. The number of days since overdue updates is 236 days.

# diff --git a/patterns/2-structured/transparent-cross-team-decision-making-using-rfcs.md b/patterns/2-structured/transparent-cross-team-decision-making-using-rfcs.md
# index f21de97..5c46178 100644
# --- a/patterns/2-structured/transparent-cross-team-decision-making-using-rfcs.md
# +++ b/patterns/2-structured/transparent-cross-team-decision-making-using-rfcs.md
@@ -41,7 +41,7 @@ Like with any process, this must be continually improved upon. There may need to
 
 ## Solutions
 
-We chose an RFC-like process for increasing the transparency of our cross-team decision making process (also see [Requests for Comments][requests-for-comments]).
+We chose an RFC-like process for increasing the transparency of our cross-team decision making process (also see IETF's [Requests for Comments][requests-for-comments]).
 
 Important elements of the solution are:
 
@@ -61,6 +61,7 @@ Important elements of the solution are:
 
 - [Rust][rust] is a good Open Source example of RFC template and process, and has been the basis for many other RFC processes.
 - [Generalized BBC iPlayer & Sounds RFC template](templates/rfc.md), originally based on the [Rust][rust] template
+- [jakobo/rfc](https://github.com/jakobo/rfc) outlines how to set up a company-internal RFC process. It contains a [detailed explanation](https://github.com/jakobo/rfc/blob/master/text/0001-using_rfcs.md) of why RFCs are important and an [RFC template](https://github.com/jakobo/rfc/blob/master/0000-template.md) to help you write your first RFC. It contains information such as motivation/rational, guide implementation, a reference implementation, drawbacks, as well as alternatives to the RFC approach. Bonus: The description itself is an RFC, so while reading it you are already getting a sense of how an RFC works.
 
 ## Resulting Context