Bug in Content Consistency Checker

[spier]

The GHA workflow to check the translation content consistency should open a new issue for each language.

However for the language pt-br it did not do that. Instead it attached a comment to a completely different issue.
See: #625

Likely a bug in .github/workflows/i18n-consistency-checker.yaml

This is the workflow run that created the faulty comment:
https://github.com/InnerSourceCommons/InnerSourcePatterns/actions/runs/7053945955/job/19201955600

[spier]

The code tries to identify the issue, to which it should add a comment, by searching for issues with a given title:
See:
https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/main/.github/workflows/i18n-consistency-checker.yaml#L77

I suspect we have to modify this search to make sure that it always returns the correct issue.

Hunches

• search in the title only
• use a phrase search (i.e. quotation marks around the title string)

Also note that in in #586 we already want to make changes to this GHA. So these two issues might collide.

[spier]

This is the search that is run

$ gh issue list -S "is:issue is:open :brazil: Brazilian Portuguese: Content Consistency Issue"

Showing 1 of 1 issue in InnerSourceCommons/InnerSourcePatterns that matches your search

#625  Quarterly Metrics: Board Report 2023-11  community metrics  about 5 hours ago

This shows that an entirely wrong issue is returned.

I think we have to search like this:

$ gh issue list -S "is:issue is:open in:title ':brazil: Brazilian Portuguese: Content Consistency Issue'"
no issues match your search in InnerSourceCommons/InnerSourcePatterns

This looks correct, as no issue with that title exists.

Trying some searches that should return results now:

$ gh issue list -S "is:issue is:open in:title ':jp: Japanese: Content Consistency Issue'"

Showing 2 of 2 issues in InnerSourceCommons/InnerSourcePatterns that match your search

#627  :jp: Japanese: Content Consistency Issue  Type - Translation  about 12 hours ago
#584  :jp: Japanese: Content Consistency Issue  Type - Translation  about 1 month ago

$ gh issue list -S "is:issue is:open in:title ':cn: Chinese: Content Consistency Issue'"

Showing 2 of 2 issues in InnerSourceCommons/InnerSourcePatterns that match your search

#628  :cn: Chinese: Content Consistency Issue  Type - Translation  about 12 hours ago
#583  :cn: Chinese: Content Consistency Issue  Type - Translation  about 1 month ago

This looks correct. Going forward these searches should only return a single issue maximum, as at any given time only a single issue with the given title should be open.

[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.

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 22 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
 

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 150 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

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 17 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
 

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 33 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
 

Group Support (patterns/2-structured/group-support.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 150 days.

# diff --git a/patterns/2-structured/group-support.md b/patterns/2-structured/group-support.md
# index 12396aa..9bf4920 100644
# --- a/patterns/2-structured/group-support.md
# +++ b/patterns/2-structured/group-support.md
@@ -80,7 +80,7 @@ Structured
 [Russell R. Rutledge][]
 
 [Russell R. Rutledge]: https://github.com/rrrutledge
-[Standard Base Documentation]: ../2-structured/project-setup/base-documentation.md
-[Communication Tooling]: ../2-structured/project-setup/communication-tooling.md
+[Standard Base Documentation]: ../2-structured/base-documentation.md
+[Communication Tooling]: ../2-structured/communication-tooling.md
 [Trusted Committer]: ../2-structured/trusted-committer.md
 [Core Team]: ../2-structured/core-team.md

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 119 days.

# diff --git a/patterns/2-structured/innersource-portal.md b/patterns/2-structured/innersource-portal.md
# index 141d2fb..e362a61 100644
# --- a/patterns/2-structured/innersource-portal.md
# +++ b/patterns/2-structured/innersource-portal.md
@@ -52,10 +52,39 @@ Key properties of the portal are:
 
 When launching the portal, a communications campaign promoting the addition of InnerSource data files or meta-data to code repositories should be considered, to bolster the number of projects displayed within the portal.
 
+### Implementations
+
+#### SAP Project Portal
+
 A [reference implementation](https://github.com/SAP/project-portal-for-innersource) of an InnerSource portal is available on GitHub and open for contributions. It lists all InnerSource projects of an organization in an interactive and easy to use way. Projects can self-register using a dedicated GitHub topic and provide additional metadata.
 
 ![Example of an InnerSource Portal](../../assets/img/portal-overview.png "Example of an InnerSource Portal")
 
+#### Wiki
+
+As a simple way to start, you can set aside a page on an internal wiki for listing out available projects.
+An easy way to display this information is in a table with columns giving just a little bit of extra information about the projects.
+Try to have just enough columns so that viewers can determine if they want to learn more about the project, but no more.
+Too much information will make the page overwhelming and difficult to use.
+Individuals and teams can self-add their projects to the page.
+
+Here is a sample set of columns:
+
+* **Name**.  Name of the project (optionally linked to its homepage).
+* **Brief Description**.  Explaining the purpose of the project (which problem does it solve?)
+* **Technology Pre-requisites**.  You must use these technologies in order to on-board to the project.
+* **Getting Started**.  Link to instructions on how to start using the project.
+* **Chat**.  Link to a chat channel to ask questions about the project.
+* **Host Team**.  Seeing if a team is behind the project can help others to have the confidence to use it.
+* **Production Since**.  How long as the project been used in a production environment?  Seeing this information is a rough proxy for its maturity.
+* **Contribution**.  Link to instructions on how to contribute to the project.
+
+This solution doesn't allow for a fancy display - it is just a wiki table.
+If it's important for you to have a snazzy-looking UI, then this idea won't work for you.
+Additionally, if you end up with a lot of projects (e.g. nearing 100),
+this solution won't scale to allow the search and filtering or auto-updating of project entries that you'll probably need.
+It is a good solution for a portal with a few dozen projects, though.
+
 ## Resulting Context
 
 * The InnerSource Portal has enabled InnerSource project owners to advertise their projects to an organization-wide audience.  Due to this increased visibility they are attracting much larger communities of contributors than ever before.
@@ -78,6 +107,7 @@ A [reference implementation](https://github.com/SAP/project-portal-for-innersour
 * **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.
 * **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.
 
 ## References
 

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 150 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

Standard Release Process (patterns/2-structured/release-process.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 150 days.

# diff --git a/patterns/2-structured/release-process.md b/patterns/2-structured/release-process.md
# index 9ee5188..ae46068 100644
# --- a/patterns/2-structured/release-process.md
# +++ b/patterns/2-structured/release-process.md
@@ -53,7 +53,7 @@ A good example of quality release notes can be found [here](https://github.com/j
 
 Teams who come across your project will see published release notes and gain confidence in your tool. Published artifacts also make using your product easier and quicker to adopt. Having well-defined and visible processes such as these also help with cross-team collaboration and new contributors. Folks can be confident that their contributions are made available and distributed in a reasonable amount of time with a clear usage path.
 
-Release notes are also a great opportunity to [praise participants](praise-participants.md)! As we know, [documentation is extremely important](project-setup/base-documentation.md) for new folks looking to get involved with your project. Praising outside teammates for contributions, including documentation and release notes, is a great way to foster community and grow your user base.
+Release notes are also a great opportunity to [praise participants](praise-participants.md)! As we know, [documentation is extremely important](base-documentation.md) for new folks looking to get involved with your project. Praising outside teammates for contributions, including documentation and release notes, is a great way to foster community and grow your user base.
 
 ## Known Instances
 

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 158 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
 

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 158 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
 

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 22 days.

# diff --git a/patterns/2-structured/praise-participants.md b/patterns/2-structured/praise-participants.md
# index 026179c..1394732 100644
# --- a/patterns/2-structured/praise-participants.md
# +++ b/patterns/2-structured/praise-participants.md
@@ -68,7 +68,7 @@ Overdoing it may feel insincere and mechanical and defeat your purpose in reachi
 ## Known Instances
 
 * Nike (multiple projects)
-* SAP - see: [InnerSource: First Contribution Explored](https://community.sap.com/t5/open-source-blogs/innersource-first-contribution-explored/ba-p/13644916)
+* SAP - InnerSource initiatives like the Dojo and Everest projects are elevated by the 'Praise Participants' pattern, where the SAP Appreciate program plays a key role in fostering a culture of gratitude and recognition, driving innovation and collaboration to new heights. See: [InnerSource: First Contribution Explored](https://community.sap.com/t5/open-source-blogs/innersource-first-contribution-explored/ba-p/13644916)
 
 ## Status
 

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 22 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
 

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 146 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
 

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 37 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

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 150 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
 

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 158 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
 

[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.

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 64 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
 

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 53 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
 

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 53 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
 

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 181 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
 

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 189 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
 

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 68 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

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 189 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
 

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 177 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
 

Group Support (patterns/2-structured/group-support.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 181 days.

# diff --git a/patterns/2-structured/group-support.md b/patterns/2-structured/group-support.md
# index 12396aa..9bf4920 100644
# --- a/patterns/2-structured/group-support.md
# +++ b/patterns/2-structured/group-support.md
@@ -80,7 +80,7 @@ Structured
 [Russell R. Rutledge][]
 
 [Russell R. Rutledge]: https://github.com/rrrutledge
-[Standard Base Documentation]: ../2-structured/project-setup/base-documentation.md
-[Communication Tooling]: ../2-structured/project-setup/communication-tooling.md
+[Standard Base Documentation]: ../2-structured/base-documentation.md
+[Communication Tooling]: ../2-structured/communication-tooling.md
 [Trusted Committer]: ../2-structured/trusted-committer.md
 [Core Team]: ../2-structured/core-team.md

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 189 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
 

Standard Release Process (patterns/2-structured/release-process.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 181 days.

# diff --git a/patterns/2-structured/release-process.md b/patterns/2-structured/release-process.md
# index 9ee5188..ae46068 100644
# --- a/patterns/2-structured/release-process.md
# +++ b/patterns/2-structured/release-process.md
@@ -53,7 +53,7 @@ A good example of quality release notes can be found [here](https://github.com/j
 
 Teams who come across your project will see published release notes and gain confidence in your tool. Published artifacts also make using your product easier and quicker to adopt. Having well-defined and visible processes such as these also help with cross-team collaboration and new contributors. Folks can be confident that their contributions are made available and distributed in a reasonable amount of time with a clear usage path.
 
-Release notes are also a great opportunity to [praise participants](praise-participants.md)! As we know, [documentation is extremely important](project-setup/base-documentation.md) for new folks looking to get involved with your project. Praising outside teammates for contributions, including documentation and release notes, is a great way to foster community and grow your user base.
+Release notes are also a great opportunity to [praise participants](praise-participants.md)! As we know, [documentation is extremely important](base-documentation.md) for new folks looking to get involved with your project. Praising outside teammates for contributions, including documentation and release notes, is a great way to foster community and grow your user base.
 
 ## Known Instances
 

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 53 days.

# diff --git a/patterns/2-structured/praise-participants.md b/patterns/2-structured/praise-participants.md
# index 026179c..1394732 100644
# --- a/patterns/2-structured/praise-participants.md
# +++ b/patterns/2-structured/praise-participants.md
@@ -68,7 +68,7 @@ Overdoing it may feel insincere and mechanical and defeat your purpose in reachi
 ## Known Instances
 
 * Nike (multiple projects)
-* SAP - see: [InnerSource: First Contribution Explored](https://community.sap.com/t5/open-source-blogs/innersource-first-contribution-explored/ba-p/13644916)
+* SAP - InnerSource initiatives like the Dojo and Everest projects are elevated by the 'Praise Participants' pattern, where the SAP Appreciate program plays a key role in fostering a culture of gratitude and recognition, driving innovation and collaboration to new heights. See: [InnerSource: First Contribution Explored](https://community.sap.com/t5/open-source-blogs/innersource-first-contribution-explored/ba-p/13644916)
 
 ## Status
 

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 48 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
 

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 181 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

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 150 days.

# diff --git a/patterns/2-structured/innersource-portal.md b/patterns/2-structured/innersource-portal.md
# index 141d2fb..e362a61 100644
# --- a/patterns/2-structured/innersource-portal.md
# +++ b/patterns/2-structured/innersource-portal.md
@@ -52,10 +52,39 @@ Key properties of the portal are:
 
 When launching the portal, a communications campaign promoting the addition of InnerSource data files or meta-data to code repositories should be considered, to bolster the number of projects displayed within the portal.
 
+### Implementations
+
+#### SAP Project Portal
+
 A [reference implementation](https://github.com/SAP/project-portal-for-innersource) of an InnerSource portal is available on GitHub and open for contributions. It lists all InnerSource projects of an organization in an interactive and easy to use way. Projects can self-register using a dedicated GitHub topic and provide additional metadata.
 
 ![Example of an InnerSource Portal](../../assets/img/portal-overview.png "Example of an InnerSource Portal")
 
+#### Wiki
+
+As a simple way to start, you can set aside a page on an internal wiki for listing out available projects.
+An easy way to display this information is in a table with columns giving just a little bit of extra information about the projects.
+Try to have just enough columns so that viewers can determine if they want to learn more about the project, but no more.
+Too much information will make the page overwhelming and difficult to use.
+Individuals and teams can self-add their projects to the page.
+
+Here is a sample set of columns:
+
+* **Name**.  Name of the project (optionally linked to its homepage).
+* **Brief Description**.  Explaining the purpose of the project (which problem does it solve?)
+* **Technology Pre-requisites**.  You must use these technologies in order to on-board to the project.
+* **Getting Started**.  Link to instructions on how to start using the project.
+* **Chat**.  Link to a chat channel to ask questions about the project.
+* **Host Team**.  Seeing if a team is behind the project can help others to have the confidence to use it.
+* **Production Since**.  How long as the project been used in a production environment?  Seeing this information is a rough proxy for its maturity.
+* **Contribution**.  Link to instructions on how to contribute to the project.
+
+This solution doesn't allow for a fancy display - it is just a wiki table.
+If it's important for you to have a snazzy-looking UI, then this idea won't work for you.
+Additionally, if you end up with a lot of projects (e.g. nearing 100),
+this solution won't scale to allow the search and filtering or auto-updating of project entries that you'll probably need.
+It is a good solution for a portal with a few dozen projects, though.
+
 ## Resulting Context
 
 * The InnerSource Portal has enabled InnerSource project owners to advertise their projects to an organization-wide audience.  Due to this increased visibility they are attracting much larger communities of contributors than ever before.
@@ -78,6 +107,7 @@ A [reference implementation](https://github.com/SAP/project-portal-for-innersour
 * **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.
 * **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.
 
 ## References
 

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 181 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

[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.

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 98 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

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 219 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
 

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 83 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
 

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 78 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
 

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 94 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
 

Group Support (patterns/2-structured/group-support.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 211 days.

# diff --git a/patterns/2-structured/group-support.md b/patterns/2-structured/group-support.md
# index 12396aa..9bf4920 100644
# --- a/patterns/2-structured/group-support.md
# +++ b/patterns/2-structured/group-support.md
@@ -80,7 +80,7 @@ Structured
 [Russell R. Rutledge][]
 
 [Russell R. Rutledge]: https://github.com/rrrutledge
-[Standard Base Documentation]: ../2-structured/project-setup/base-documentation.md
-[Communication Tooling]: ../2-structured/project-setup/communication-tooling.md
+[Standard Base Documentation]: ../2-structured/base-documentation.md
+[Communication Tooling]: ../2-structured/communication-tooling.md
 [Trusted Committer]: ../2-structured/trusted-committer.md
 [Core Team]: ../2-structured/core-team.md

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 219 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
 

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 207 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
 

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 219 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
 

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 211 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
 

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 83 days.

# diff --git a/patterns/2-structured/praise-participants.md b/patterns/2-structured/praise-participants.md
# index 026179c..1394732 100644
# --- a/patterns/2-structured/praise-participants.md
# +++ b/patterns/2-structured/praise-participants.md
@@ -68,7 +68,7 @@ Overdoing it may feel insincere and mechanical and defeat your purpose in reachi
 ## Known Instances
 
 * Nike (multiple projects)
-* SAP - see: [InnerSource: First Contribution Explored](https://community.sap.com/t5/open-source-blogs/innersource-first-contribution-explored/ba-p/13644916)
+* SAP - InnerSource initiatives like the Dojo and Everest projects are elevated by the 'Praise Participants' pattern, where the SAP Appreciate program plays a key role in fostering a culture of gratitude and recognition, driving innovation and collaboration to new heights. See: [InnerSource: First Contribution Explored](https://community.sap.com/t5/open-source-blogs/innersource-first-contribution-explored/ba-p/13644916)
 
 ## 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 180 days.

# diff --git a/patterns/2-structured/innersource-portal.md b/patterns/2-structured/innersource-portal.md
# index 141d2fb..e362a61 100644
# --- a/patterns/2-structured/innersource-portal.md
# +++ b/patterns/2-structured/innersource-portal.md
@@ -52,10 +52,39 @@ Key properties of the portal are:
 
 When launching the portal, a communications campaign promoting the addition of InnerSource data files or meta-data to code repositories should be considered, to bolster the number of projects displayed within the portal.
 
+### Implementations
+
+#### SAP Project Portal
+
 A [reference implementation](https://github.com/SAP/project-portal-for-innersource) of an InnerSource portal is available on GitHub and open for contributions. It lists all InnerSource projects of an organization in an interactive and easy to use way. Projects can self-register using a dedicated GitHub topic and provide additional metadata.
 
 ![Example of an InnerSource Portal](../../assets/img/portal-overview.png "Example of an InnerSource Portal")
 
+#### Wiki
+
+As a simple way to start, you can set aside a page on an internal wiki for listing out available projects.
+An easy way to display this information is in a table with columns giving just a little bit of extra information about the projects.
+Try to have just enough columns so that viewers can determine if they want to learn more about the project, but no more.
+Too much information will make the page overwhelming and difficult to use.
+Individuals and teams can self-add their projects to the page.
+
+Here is a sample set of columns:
+
+* **Name**.  Name of the project (optionally linked to its homepage).
+* **Brief Description**.  Explaining the purpose of the project (which problem does it solve?)
+* **Technology Pre-requisites**.  You must use these technologies in order to on-board to the project.
+* **Getting Started**.  Link to instructions on how to start using the project.
+* **Chat**.  Link to a chat channel to ask questions about the project.
+* **Host Team**.  Seeing if a team is behind the project can help others to have the confidence to use it.
+* **Production Since**.  How long as the project been used in a production environment?  Seeing this information is a rough proxy for its maturity.
+* **Contribution**.  Link to instructions on how to contribute to the project.
+
+This solution doesn't allow for a fancy display - it is just a wiki table.
+If it's important for you to have a snazzy-looking UI, then this idea won't work for you.
+Additionally, if you end up with a lot of projects (e.g. nearing 100),
+this solution won't scale to allow the search and filtering or auto-updating of project entries that you'll probably need.
+It is a good solution for a portal with a few dozen projects, though.
+
 ## Resulting Context
 
 * The InnerSource Portal has enabled InnerSource project owners to advertise their projects to an organization-wide audience.  Due to this increased visibility they are attracting much larger communities of contributors than ever before.
@@ -78,6 +107,7 @@ A [reference implementation](https://github.com/SAP/project-portal-for-innersour
 * **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.
 * **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.
 
 ## References
 

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 211 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

Standard Release Process (patterns/2-structured/release-process.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 211 days.

# diff --git a/patterns/2-structured/release-process.md b/patterns/2-structured/release-process.md
# index 9ee5188..ae46068 100644
# --- a/patterns/2-structured/release-process.md
# +++ b/patterns/2-structured/release-process.md
@@ -53,7 +53,7 @@ A good example of quality release notes can be found [here](https://github.com/j
 
 Teams who come across your project will see published release notes and gain confidence in your tool. Published artifacts also make using your product easier and quicker to adopt. Having well-defined and visible processes such as these also help with cross-team collaboration and new contributors. Folks can be confident that their contributions are made available and distributed in a reasonable amount of time with a clear usage path.
 
-Release notes are also a great opportunity to [praise participants](praise-participants.md)! As we know, [documentation is extremely important](project-setup/base-documentation.md) for new folks looking to get involved with your project. Praising outside teammates for contributions, including documentation and release notes, is a great way to foster community and grow your user base.
+Release notes are also a great opportunity to [praise participants](praise-participants.md)! As we know, [documentation is extremely important](base-documentation.md) for new folks looking to get involved with your project. Praising outside teammates for contributions, including documentation and release notes, is a great way to foster community and grow your user base.
 
 ## Known Instances
 

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 211 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

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 83 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
 

[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.

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 242 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

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 250 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
 

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 114 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
 

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 125 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
 

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 250 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
 

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 238 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
 

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 114 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
 

Standard Release Process (patterns/2-structured/release-process.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 242 days.

# diff --git a/patterns/2-structured/release-process.md b/patterns/2-structured/release-process.md
# index 9ee5188..ae46068 100644
# --- a/patterns/2-structured/release-process.md
# +++ b/patterns/2-structured/release-process.md
@@ -53,7 +53,7 @@ A good example of quality release notes can be found [here](https://github.com/j
 
 Teams who come across your project will see published release notes and gain confidence in your tool. Published artifacts also make using your product easier and quicker to adopt. Having well-defined and visible processes such as these also help with cross-team collaboration and new contributors. Folks can be confident that their contributions are made available and distributed in a reasonable amount of time with a clear usage path.
 
-Release notes are also a great opportunity to [praise participants](praise-participants.md)! As we know, [documentation is extremely important](project-setup/base-documentation.md) for new folks looking to get involved with your project. Praising outside teammates for contributions, including documentation and release notes, is a great way to foster community and grow your user base.
+Release notes are also a great opportunity to [praise participants](praise-participants.md)! As we know, [documentation is extremely important](base-documentation.md) for new folks looking to get involved with your project. Praising outside teammates for contributions, including documentation and release notes, is a great way to foster community and grow your user base.
 
 ## Known Instances
 

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 114 days.

# diff --git a/patterns/2-structured/praise-participants.md b/patterns/2-structured/praise-participants.md
# index 026179c..1394732 100644
# --- a/patterns/2-structured/praise-participants.md
# +++ b/patterns/2-structured/praise-participants.md
@@ -68,7 +68,7 @@ Overdoing it may feel insincere and mechanical and defeat your purpose in reachi
 ## Known Instances
 
 * Nike (multiple projects)
-* SAP - see: [InnerSource: First Contribution Explored](https://community.sap.com/t5/open-source-blogs/innersource-first-contribution-explored/ba-p/13644916)
+* SAP - InnerSource initiatives like the Dojo and Everest projects are elevated by the 'Praise Participants' pattern, where the SAP Appreciate program plays a key role in fostering a culture of gratitude and recognition, driving innovation and collaboration to new heights. See: [InnerSource: First Contribution Explored](https://community.sap.com/t5/open-source-blogs/innersource-first-contribution-explored/ba-p/13644916)
 
 ## Status
 

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 242 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

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 129 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

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 250 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
 

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 242 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
 

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 109 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
 

Group Support (patterns/2-structured/group-support.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 242 days.

# diff --git a/patterns/2-structured/group-support.md b/patterns/2-structured/group-support.md
# index 12396aa..9bf4920 100644
# --- a/patterns/2-structured/group-support.md
# +++ b/patterns/2-structured/group-support.md
@@ -80,7 +80,7 @@ Structured
 [Russell R. Rutledge][]
 
 [Russell R. Rutledge]: https://github.com/rrrutledge
-[Standard Base Documentation]: ../2-structured/project-setup/base-documentation.md
-[Communication Tooling]: ../2-structured/project-setup/communication-tooling.md
+[Standard Base Documentation]: ../2-structured/base-documentation.md
+[Communication Tooling]: ../2-structured/communication-tooling.md
 [Trusted Committer]: ../2-structured/trusted-committer.md
 [Core Team]: ../2-structured/core-team.md

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 211 days.

# diff --git a/patterns/2-structured/innersource-portal.md b/patterns/2-structured/innersource-portal.md
# index 141d2fb..e362a61 100644
# --- a/patterns/2-structured/innersource-portal.md
# +++ b/patterns/2-structured/innersource-portal.md
@@ -52,10 +52,39 @@ Key properties of the portal are:
 
 When launching the portal, a communications campaign promoting the addition of InnerSource data files or meta-data to code repositories should be considered, to bolster the number of projects displayed within the portal.
 
+### Implementations
+
+#### SAP Project Portal
+
 A [reference implementation](https://github.com/SAP/project-portal-for-innersource) of an InnerSource portal is available on GitHub and open for contributions. It lists all InnerSource projects of an organization in an interactive and easy to use way. Projects can self-register using a dedicated GitHub topic and provide additional metadata.
 
 ![Example of an InnerSource Portal](../../assets/img/portal-overview.png "Example of an InnerSource Portal")
 
+#### Wiki
+
+As a simple way to start, you can set aside a page on an internal wiki for listing out available projects.
+An easy way to display this information is in a table with columns giving just a little bit of extra information about the projects.
+Try to have just enough columns so that viewers can determine if they want to learn more about the project, but no more.
+Too much information will make the page overwhelming and difficult to use.
+Individuals and teams can self-add their projects to the page.
+
+Here is a sample set of columns:
+
+* **Name**.  Name of the project (optionally linked to its homepage).
+* **Brief Description**.  Explaining the purpose of the project (which problem does it solve?)
+* **Technology Pre-requisites**.  You must use these technologies in order to on-board to the project.
+* **Getting Started**.  Link to instructions on how to start using the project.
+* **Chat**.  Link to a chat channel to ask questions about the project.
+* **Host Team**.  Seeing if a team is behind the project can help others to have the confidence to use it.
+* **Production Since**.  How long as the project been used in a production environment?  Seeing this information is a rough proxy for its maturity.
+* **Contribution**.  Link to instructions on how to contribute to the project.
+
+This solution doesn't allow for a fancy display - it is just a wiki table.
+If it's important for you to have a snazzy-looking UI, then this idea won't work for you.
+Additionally, if you end up with a lot of projects (e.g. nearing 100),
+this solution won't scale to allow the search and filtering or auto-updating of project entries that you'll probably need.
+It is a good solution for a portal with a few dozen projects, though.
+
 ## Resulting Context
 
 * The InnerSource Portal has enabled InnerSource project owners to advertise their projects to an organization-wide audience.  Due to this increased visibility they are attracting much larger communities of contributors than ever before.
@@ -78,6 +107,7 @@ A [reference implementation](https://github.com/SAP/project-portal-for-innersour
 * **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.
 * **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.
 
 ## References
 

[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.

Group Support (patterns/2-structured/group-support.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 273 days.

# diff --git a/patterns/2-structured/group-support.md b/patterns/2-structured/group-support.md
# index 12396aa..9bf4920 100644
# --- a/patterns/2-structured/group-support.md
# +++ b/patterns/2-structured/group-support.md
@@ -80,7 +80,7 @@ Structured
 [Russell R. Rutledge][]
 
 [Russell R. Rutledge]: https://github.com/rrrutledge
-[Standard Base Documentation]: ../2-structured/project-setup/base-documentation.md
-[Communication Tooling]: ../2-structured/project-setup/communication-tooling.md
+[Standard Base Documentation]: ../2-structured/base-documentation.md
+[Communication Tooling]: ../2-structured/communication-tooling.md
 [Trusted Committer]: ../2-structured/trusted-committer.md
 [Core Team]: ../2-structured/core-team.md

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 160 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

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 281 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 7 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!

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 156 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
 

Standard Release Process (patterns/2-structured/release-process.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 273 days.

# diff --git a/patterns/2-structured/release-process.md b/patterns/2-structured/release-process.md
# index 9ee5188..ae46068 100644
# --- a/patterns/2-structured/release-process.md
# +++ b/patterns/2-structured/release-process.md
@@ -53,7 +53,7 @@ A good example of quality release notes can be found [here](https://github.com/j
 
 Teams who come across your project will see published release notes and gain confidence in your tool. Published artifacts also make using your product easier and quicker to adopt. Having well-defined and visible processes such as these also help with cross-team collaboration and new contributors. Folks can be confident that their contributions are made available and distributed in a reasonable amount of time with a clear usage path.
 
-Release notes are also a great opportunity to [praise participants](praise-participants.md)! As we know, [documentation is extremely important](project-setup/base-documentation.md) for new folks looking to get involved with your project. Praising outside teammates for contributions, including documentation and release notes, is a great way to foster community and grow your user base.
+Release notes are also a great opportunity to [praise participants](praise-participants.md)! As we know, [documentation is extremely important](base-documentation.md) for new folks looking to get involved with your project. Praising outside teammates for contributions, including documentation and release notes, is a great way to foster community and grow your user base.
 
 ## Known Instances
 

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 281 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
 

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 281 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
 

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 140 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 269 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
 

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 273 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

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 145 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
 

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 273 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
 

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 5 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.

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 145 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
 

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 273 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

[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.

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 311 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
 

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 303 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
 

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 175 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
 

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 299 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
 

Standard Release Process (patterns/2-structured/release-process.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 303 days.

# diff --git a/patterns/2-structured/release-process.md b/patterns/2-structured/release-process.md
# index 9ee5188..ae46068 100644
# --- a/patterns/2-structured/release-process.md
# +++ b/patterns/2-structured/release-process.md
@@ -53,7 +53,7 @@ A good example of quality release notes can be found [here](https://github.com/j
 
 Teams who come across your project will see published release notes and gain confidence in your tool. Published artifacts also make using your product easier and quicker to adopt. Having well-defined and visible processes such as these also help with cross-team collaboration and new contributors. Folks can be confident that their contributions are made available and distributed in a reasonable amount of time with a clear usage path.
 
-Release notes are also a great opportunity to [praise participants](praise-participants.md)! As we know, [documentation is extremely important](project-setup/base-documentation.md) for new folks looking to get involved with your project. Praising outside teammates for contributions, including documentation and release notes, is a great way to foster community and grow your user base.
+Release notes are also a great opportunity to [praise participants](praise-participants.md)! As we know, [documentation is extremely important](base-documentation.md) for new folks looking to get involved with your project. Praising outside teammates for contributions, including documentation and release notes, is a great way to foster community and grow your user base.
 
 ## Known Instances
 

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 186 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
 

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 35 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.

Group Support (patterns/2-structured/group-support.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 303 days.

# diff --git a/patterns/2-structured/group-support.md b/patterns/2-structured/group-support.md
# index 12396aa..9bf4920 100644
# --- a/patterns/2-structured/group-support.md
# +++ b/patterns/2-structured/group-support.md
@@ -80,7 +80,7 @@ Structured
 [Russell R. Rutledge][]
 
 [Russell R. Rutledge]: https://github.com/rrrutledge
-[Standard Base Documentation]: ../2-structured/project-setup/base-documentation.md
-[Communication Tooling]: ../2-structured/project-setup/communication-tooling.md
+[Standard Base Documentation]: ../2-structured/base-documentation.md
+[Communication Tooling]: ../2-structured/communication-tooling.md
 [Trusted Committer]: ../2-structured/trusted-committer.md
 [Core Team]: ../2-structured/core-team.md

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 190 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 170 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
 

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 303 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

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 303 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 311 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
 

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 37 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!

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 311 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
 

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 175 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
 

[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 342 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 217 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 206 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 342 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 68 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 334 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 342 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
 

Group Support (patterns/2-structured/group-support.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 334 days.

# diff --git a/patterns/2-structured/group-support.md b/patterns/2-structured/group-support.md
# index 12396aa..9bf4920 100644
# --- a/patterns/2-structured/group-support.md
# +++ b/patterns/2-structured/group-support.md
@@ -80,7 +80,7 @@ Structured
 [Russell R. Rutledge][]
 
 [Russell R. Rutledge]: https://github.com/rrrutledge
-[Standard Base Documentation]: ../2-structured/project-setup/base-documentation.md
-[Communication Tooling]: ../2-structured/project-setup/communication-tooling.md
+[Standard Base Documentation]: ../2-structured/base-documentation.md
+[Communication Tooling]: ../2-structured/communication-tooling.md
 [Trusted Committer]: ../2-structured/trusted-committer.md
 [Core Team]: ../2-structured/core-team.md

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 334 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 221 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 201 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 330 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 66 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 334 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

Standard Release Process (patterns/2-structured/release-process.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 334 days.

# diff --git a/patterns/2-structured/release-process.md b/patterns/2-structured/release-process.md
# index 9ee5188..ae46068 100644
# --- a/patterns/2-structured/release-process.md
# +++ b/patterns/2-structured/release-process.md
@@ -53,7 +53,7 @@ A good example of quality release notes can be found [here](https://github.com/j
 
 Teams who come across your project will see published release notes and gain confidence in your tool. Published artifacts also make using your product easier and quicker to adopt. Having well-defined and visible processes such as these also help with cross-team collaboration and new contributors. Folks can be confident that their contributions are made available and distributed in a reasonable amount of time with a clear usage path.
 
-Release notes are also a great opportunity to [praise participants](praise-participants.md)! As we know, [documentation is extremely important](project-setup/base-documentation.md) for new folks looking to get involved with your project. Praising outside teammates for contributions, including documentation and release notes, is a great way to foster community and grow your user base.
+Release notes are also a great opportunity to [praise participants](praise-participants.md)! As we know, [documentation is extremely important](base-documentation.md) for new folks looking to get involved with your project. Praising outside teammates for contributions, including documentation and release notes, is a great way to foster community and grow your user base.
 
 ## Known Instances
 

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 206 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
 

[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
 

Group Support (patterns/2-structured/group-support.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/group-support.md b/patterns/2-structured/group-support.md
# index 12396aa..9bf4920 100644
# --- a/patterns/2-structured/group-support.md
# +++ b/patterns/2-structured/group-support.md
@@ -80,7 +80,7 @@ Structured
 [Russell R. Rutledge][]
 
 [Russell R. Rutledge]: https://github.com/rrrutledge
-[Standard Base Documentation]: ../2-structured/project-setup/base-documentation.md
-[Communication Tooling]: ../2-structured/project-setup/communication-tooling.md
+[Standard Base Documentation]: ../2-structured/base-documentation.md
+[Communication Tooling]: ../2-structured/communication-tooling.md
 [Trusted Committer]: ../2-structured/trusted-committer.md
 [Core Team]: ../2-structured/core-team.md

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

Standard Release Process (patterns/2-structured/release-process.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/release-process.md b/patterns/2-structured/release-process.md
# index 9ee5188..ae46068 100644
# --- a/patterns/2-structured/release-process.md
# +++ b/patterns/2-structured/release-process.md
@@ -53,7 +53,7 @@ A good example of quality release notes can be found [here](https://github.com/j
 
 Teams who come across your project will see published release notes and gain confidence in your tool. Published artifacts also make using your product easier and quicker to adopt. Having well-defined and visible processes such as these also help with cross-team collaboration and new contributors. Folks can be confident that their contributions are made available and distributed in a reasonable amount of time with a clear usage path.
 
-Release notes are also a great opportunity to [praise participants](praise-participants.md)! As we know, [documentation is extremely important](project-setup/base-documentation.md) for new folks looking to get involved with your project. Praising outside teammates for contributions, including documentation and release notes, is a great way to foster community and grow your user base.
+Release notes are also a great opportunity to [praise participants](praise-participants.md)! As we know, [documentation is extremely important](base-documentation.md) for new folks looking to get involved with your project. Praising outside teammates for contributions, including documentation and release notes, is a great way to foster community and grow your user base.
 
 ## Known Instances
 

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
 

[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.

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 395 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
 

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 403 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
 

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 267 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
 

Group Support (patterns/2-structured/group-support.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 395 days.

# diff --git a/patterns/2-structured/group-support.md b/patterns/2-structured/group-support.md
# index 12396aa..9bf4920 100644
# --- a/patterns/2-structured/group-support.md
# +++ b/patterns/2-structured/group-support.md
@@ -80,7 +80,7 @@ Structured
 [Russell R. Rutledge][]
 
 [Russell R. Rutledge]: https://github.com/rrrutledge
-[Standard Base Documentation]: ../2-structured/project-setup/base-documentation.md
-[Communication Tooling]: ../2-structured/project-setup/communication-tooling.md
+[Standard Base Documentation]: ../2-structured/base-documentation.md
+[Communication Tooling]: ../2-structured/communication-tooling.md
 [Trusted Committer]: ../2-structured/trusted-committer.md
 [Core Team]: ../2-structured/core-team.md

Standard Release Process (patterns/2-structured/release-process.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 395 days.

# diff --git a/patterns/2-structured/release-process.md b/patterns/2-structured/release-process.md
# index 9ee5188..ae46068 100644
# --- a/patterns/2-structured/release-process.md
# +++ b/patterns/2-structured/release-process.md
@@ -53,7 +53,7 @@ A good example of quality release notes can be found [here](https://github.com/j
 
 Teams who come across your project will see published release notes and gain confidence in your tool. Published artifacts also make using your product easier and quicker to adopt. Having well-defined and visible processes such as these also help with cross-team collaboration and new contributors. Folks can be confident that their contributions are made available and distributed in a reasonable amount of time with a clear usage path.
 
-Release notes are also a great opportunity to [praise participants](praise-participants.md)! As we know, [documentation is extremely important](project-setup/base-documentation.md) for new folks looking to get involved with your project. Praising outside teammates for contributions, including documentation and release notes, is a great way to foster community and grow your user base.
+Release notes are also a great opportunity to [praise participants](praise-participants.md)! As we know, [documentation is extremely important](base-documentation.md) for new folks looking to get involved with your project. Praising outside teammates for contributions, including documentation and release notes, is a great way to foster community and grow your user base.
 
 ## Known Instances
 

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 262 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
 

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 129 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!

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 403 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
 

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 20 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 5c46178..d267f50 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
@@ -99,6 +99,7 @@ Also for decision making outside of pure software design decisions, transparent
 - **Uber** - According to this blog post by Gergely Orosz: [Scaling Engineering Teams via RFCs: Writing Things Down][uber].
 - **Google Design Docs** - As described in this blog post by Malte Ubl [Design Docs at Google][google]
 - **DAZN** (10/2021) - One way that DAZN makes technical decisions is via RFCs. RFCs are used for decisions that apply to engineering-wide processes only! The RFCs live in a GitHub repository, and technical standards are then gradually adopted within their tools and by their engineers. An RFC can be raised by any engineer, and voted on by all engineers. If upvotes exceed downvotes, the RFC is adopted. It’s worth noting, that the RFC voting process hasn’t yet been “stress-tested” by any contentious decisions. - As described in this blog post by Lou Bichard: [Building A DX Team: Lessons Learned][dazn]
+- **SAP** (03/2024) - SAP has a mature tool-assisted process for document review across teams. It is primarily used for the review of Architecture Decision Records (ADR) originating from cross-team work done on the Cross-Product Architecture collaboration model. Some noteworthy implementation differences from this pattern: The review process is not easily available for decisions on small projects. Also, the documents are not restricted to InnerSource projects only. - As described in the blog post [Cross-Product Architecture: Embracing Conway's Law for Better Software Architecture][sap-cpa].
 
 ## Status
 
@@ -124,3 +125,4 @@ Structured
 [bbc]: https://www.youtube.com/watch?v=U6zlghE0HcE
 [google]: https://www.industrialempathy.com/posts/design-docs-at-google/
 [dazn]: https://medium.com/dazn-tech/building-a-dx-team-lessons-learned-4a66446088bc
+[sap-cpa]: https://community.sap.com/t5/technology-blogs-by-sap/cross-product-architecture-embracing-conway-s-law-for-better-software/ba-p/13648600

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 403 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 278 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
 

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 395 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

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 127 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.

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 395 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

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 282 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

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 391 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
 

[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.

Standard Release Process (patterns/2-structured/release-process.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 426 days.

# diff --git a/patterns/2-structured/release-process.md b/patterns/2-structured/release-process.md
# index 9ee5188..ae46068 100644
# --- a/patterns/2-structured/release-process.md
# +++ b/patterns/2-structured/release-process.md
@@ -53,7 +53,7 @@ A good example of quality release notes can be found [here](https://github.com/j
 
 Teams who come across your project will see published release notes and gain confidence in your tool. Published artifacts also make using your product easier and quicker to adopt. Having well-defined and visible processes such as these also help with cross-team collaboration and new contributors. Folks can be confident that their contributions are made available and distributed in a reasonable amount of time with a clear usage path.
 
-Release notes are also a great opportunity to [praise participants](praise-participants.md)! As we know, [documentation is extremely important](project-setup/base-documentation.md) for new folks looking to get involved with your project. Praising outside teammates for contributions, including documentation and release notes, is a great way to foster community and grow your user base.
+Release notes are also a great opportunity to [praise participants](praise-participants.md)! As we know, [documentation is extremely important](base-documentation.md) for new folks looking to get involved with your project. Praising outside teammates for contributions, including documentation and release notes, is a great way to foster community and grow your user base.
 
 ## Known Instances
 

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 434 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
 

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 434 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
 

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 426 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
 

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 426 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

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 422 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 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 293 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
 

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 309 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
 

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 158 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.

Group Support (patterns/2-structured/group-support.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 426 days.

# diff --git a/patterns/2-structured/group-support.md b/patterns/2-structured/group-support.md
# index 12396aa..9bf4920 100644
# --- a/patterns/2-structured/group-support.md
# +++ b/patterns/2-structured/group-support.md
@@ -80,7 +80,7 @@ Structured
 [Russell R. Rutledge][]
 
 [Russell R. Rutledge]: https://github.com/rrrutledge
-[Standard Base Documentation]: ../2-structured/project-setup/base-documentation.md
-[Communication Tooling]: ../2-structured/project-setup/communication-tooling.md
+[Standard Base Documentation]: ../2-structured/base-documentation.md
+[Communication Tooling]: ../2-structured/communication-tooling.md
 [Trusted Committer]: ../2-structured/trusted-committer.md
 [Core Team]: ../2-structured/core-team.md

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 160 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!

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 426 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

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 298 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
 

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 313 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

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 51 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 5c46178..d267f50 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
@@ -99,6 +99,7 @@ Also for decision making outside of pure software design decisions, transparent
 - **Uber** - According to this blog post by Gergely Orosz: [Scaling Engineering Teams via RFCs: Writing Things Down][uber].
 - **Google Design Docs** - As described in this blog post by Malte Ubl [Design Docs at Google][google]
 - **DAZN** (10/2021) - One way that DAZN makes technical decisions is via RFCs. RFCs are used for decisions that apply to engineering-wide processes only! The RFCs live in a GitHub repository, and technical standards are then gradually adopted within their tools and by their engineers. An RFC can be raised by any engineer, and voted on by all engineers. If upvotes exceed downvotes, the RFC is adopted. It’s worth noting, that the RFC voting process hasn’t yet been “stress-tested” by any contentious decisions. - As described in this blog post by Lou Bichard: [Building A DX Team: Lessons Learned][dazn]
+- **SAP** (03/2024) - SAP has a mature tool-assisted process for document review across teams. It is primarily used for the review of Architecture Decision Records (ADR) originating from cross-team work done on the Cross-Product Architecture collaboration model. Some noteworthy implementation differences from this pattern: The review process is not easily available for decisions on small projects. Also, the documents are not restricted to InnerSource projects only. - As described in the blog post [Cross-Product Architecture: Embracing Conway's Law for Better Software Architecture][sap-cpa].
 
 ## Status
 
@@ -124,3 +125,4 @@ Structured
 [bbc]: https://www.youtube.com/watch?v=U6zlghE0HcE
 [google]: https://www.industrialempathy.com/posts/design-docs-at-google/
 [dazn]: https://medium.com/dazn-tech/building-a-dx-team-lessons-learned-4a66446088bc
+[sap-cpa]: https://community.sap.com/t5/technology-blogs-by-sap/cross-product-architecture-embracing-conway-s-law-for-better-software/ba-p/13648600

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 434 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
 

[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.

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 450 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
 

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 462 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
 

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 462 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
 

Group Support (patterns/2-structured/group-support.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 454 days.

# diff --git a/patterns/2-structured/group-support.md b/patterns/2-structured/group-support.md
# index 12396aa..9bf4920 100644
# --- a/patterns/2-structured/group-support.md
# +++ b/patterns/2-structured/group-support.md
@@ -80,7 +80,7 @@ Structured
 [Russell R. Rutledge][]
 
 [Russell R. Rutledge]: https://github.com/rrrutledge
-[Standard Base Documentation]: ../2-structured/project-setup/base-documentation.md
-[Communication Tooling]: ../2-structured/project-setup/communication-tooling.md
+[Standard Base Documentation]: ../2-structured/base-documentation.md
+[Communication Tooling]: ../2-structured/communication-tooling.md
 [Trusted Committer]: ../2-structured/trusted-committer.md
 [Core Team]: ../2-structured/core-team.md

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 454 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 79 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 5c46178..d267f50 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
@@ -99,6 +99,7 @@ Also for decision making outside of pure software design decisions, transparent
 - **Uber** - According to this blog post by Gergely Orosz: [Scaling Engineering Teams via RFCs: Writing Things Down][uber].
 - **Google Design Docs** - As described in this blog post by Malte Ubl [Design Docs at Google][google]
 - **DAZN** (10/2021) - One way that DAZN makes technical decisions is via RFCs. RFCs are used for decisions that apply to engineering-wide processes only! The RFCs live in a GitHub repository, and technical standards are then gradually adopted within their tools and by their engineers. An RFC can be raised by any engineer, and voted on by all engineers. If upvotes exceed downvotes, the RFC is adopted. It’s worth noting, that the RFC voting process hasn’t yet been “stress-tested” by any contentious decisions. - As described in this blog post by Lou Bichard: [Building A DX Team: Lessons Learned][dazn]
+- **SAP** (03/2024) - SAP has a mature tool-assisted process for document review across teams. It is primarily used for the review of Architecture Decision Records (ADR) originating from cross-team work done on the Cross-Product Architecture collaboration model. Some noteworthy implementation differences from this pattern: The review process is not easily available for decisions on small projects. Also, the documents are not restricted to InnerSource projects only. - As described in the blog post [Cross-Product Architecture: Embracing Conway's Law for Better Software Architecture][sap-cpa].
 
 ## Status
 
@@ -124,3 +125,4 @@ Structured
 [bbc]: https://www.youtube.com/watch?v=U6zlghE0HcE
 [google]: https://www.industrialempathy.com/posts/design-docs-at-google/
 [dazn]: https://medium.com/dazn-tech/building-a-dx-team-lessons-learned-4a66446088bc
+[sap-cpa]: https://community.sap.com/t5/technology-blogs-by-sap/cross-product-architecture-embracing-conway-s-law-for-better-software/ba-p/13648600

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 462 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
 

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 454 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

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 188 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!

Standard Release Process (patterns/2-structured/release-process.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 454 days.

# diff --git a/patterns/2-structured/release-process.md b/patterns/2-structured/release-process.md
# index 9ee5188..ae46068 100644
# --- a/patterns/2-structured/release-process.md
# +++ b/patterns/2-structured/release-process.md
@@ -53,7 +53,7 @@ A good example of quality release notes can be found [here](https://github.com/j
 
 Teams who come across your project will see published release notes and gain confidence in your tool. Published artifacts also make using your product easier and quicker to adopt. Having well-defined and visible processes such as these also help with cross-team collaboration and new contributors. Folks can be confident that their contributions are made available and distributed in a reasonable amount of time with a clear usage path.
 
-Release notes are also a great opportunity to [praise participants](praise-participants.md)! As we know, [documentation is extremely important](project-setup/base-documentation.md) for new folks looking to get involved with your project. Praising outside teammates for contributions, including documentation and release notes, is a great way to foster community and grow your user base.
+Release notes are also a great opportunity to [praise participants](praise-participants.md)! As we know, [documentation is extremely important](base-documentation.md) for new folks looking to get involved with your project. Praising outside teammates for contributions, including documentation and release notes, is a great way to foster community and grow your user base.
 
 ## Known Instances
 

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 321 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
 

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 341 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 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 186 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.

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 326 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
 

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 454 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
 

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 337 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