Activity

1. github-actions

   added

   Type - TranslationTranslating patterns into other languagesTranslating patterns into other languages

   on Dec 1, 2023
2. github-actions commented on Jan 1, 2024

   

   github-actionsBot

   on Jan 1, 2024 – with GitHub Actions

   Author

   More 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 29 days.

   # diff --git a/patterns/2-structured/30-day-warranty.md b/patterns/2-structured/30-day-warranty.md
   # index 7c2ab75..ce93a1b 100644
   # --- a/patterns/2-structured/30-day-warranty.md
   # +++ b/patterns/2-structured/30-day-warranty.md
   @@ -34,7 +34,7 @@ Address the fears of both the receiving and the contributing teams by establishi
    
    Note that the warranty period could be 45, 60, or 100 days too. The duration may vary based upon the constraints of the project, the software life cycle of the project, commitments to customers, and other factors.
    
   -In addition it helps to provide clear [contribution guidelines](./project-setup/base-documentation.md), spelling out the expectations of the receiving team and the contributing team.
   +In addition it helps to provide clear [contribution guidelines](./base-documentation.md), spelling out the expectations of the receiving team and the contributing team.
    
    ![30 Day Warranty](../../assets/img/thirtydaywarranty.jpg)
    

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

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

   # diff --git a/patterns/2-structured/base-documentation.md b/patterns/2-structured/base-documentation.md
   # new file mode 100644
   # index 0000000..bd20b82
   # --- /dev/null
   +++ b/patterns/2-structured/base-documentation.md
   @@ -0,0 +1,161 @@
   +## Title
   +
   +Standard Base Documentation
   +
   +## Patlet
   +
   +New contributors to an InnerSource project have a hard time figuring out who
   +maintains the project, what to work on, and how to contribute. Providing
   +documentation in standard files like `README.md`/`CONTRIBUTING.md`/`COMMUNICATION.md` enables a
   +self service process for new contributors, so that they can find the answers to
   +the most common questions on their own.
   +
   +## Problem
   +
   +A team wants to share either a freshly started or a preexisting project with
   +the wider organization and receive contributions to it. Potential contributors
   +often are lost: They are failing to identify the team's preferred communication
   +channels. They have trouble quickly making a judgment about whether a new
   +feature makes sense to be added or not. They have a hard time understanding
   +exactly which colleagues are currently actively maintaining the project.
   +
   +## Context
   +
   +A project is to be shared with others as an InnerSource project. In order for
   +others to be able to understand what the project is about as well as how to
   +contribute, the project needs to provide some base level documentation. So far
   +the project is lacking either all documentation or some aspects needed for users
   +to try it out in a self-service manner as well as for contributors to get up to
   +speed quickly.
   +
   +## Forces
   +
   +- The project was converted into an InnerSource project only recently. Before, users were either only internal or on-boarded in personal face-to-face sessions. Equally, people working on the project went through personal on-boarding sessions which do not scale with growing numbers of contributors or remote contributors. As a result, self service documentation is lacking.
   +- The project was newly created as an InnerSource project. However the host team lacks experience with InnerSource. As a result they need guidance on which information to include in their documentation, where to put that documentation so others can find it and which types of readers to address in their documentation.
   +- The project was converted into an InnerSource project only recently, the host team has limited experience with InnerSource. As a result, existing documentation addresses a lot of technical aspects. It does not cover communication, coordination, information needed to facilitate transparent planning.
   +- The project was converted into an InnerSource project only recently. As a result, a lot of implicit knowledge that exists within the team is neither written down nor obvious to contributors.
   +- A lack of documentation leads to potential contributors taking a long time to get setup and get started. Producing documentation (and keeping it up to date) requires a time investment. Even if the host team relies on contributors to help with lacking documentation, those contributions still need time to review.
   +- Project members are spending a lot of time answering getting started questions. Maintaining a comprehensive database of what could be considered support questions requires a lot of time and effort though.
   +- Different teams within the organization have diverging standards for how to format source code and which software patterns to use. As a result contributions often end up getting re-written to a large part or even entirely. Standardizing all of that and enforcing the standard often would require a lot of time and work.
   +- The added work for repeated explanations and re-writes diminishes the usefulness of the InnerSource approach.
   +- Frequent escalations due to extra work and delays due to re-writes lead to a big cheese situation.
   +
   +## Solution
   +
   +Address the need for clearer documentation for new contributors. The goal when
   +creating this documentation should be to make getting started as much a self
   +service process as possible with frequently asked questions answered in standard
   +documentation format.
   +
   +### README.md
   +
   +If it does not yet exist, create a `README.md` for your project. It should
   +contain:
   +
   +* The [mission of the project](https://producingoss.com/en/producingoss.html#mission-statement) in as a concise format as possible. It should answer what the project's purpose is and enable contributors to make a good first guess whether a suggested feature will likely be in scope for the project, or not.
   +* A "Getting Started" section for downstream users of the project. It should explain how to setup/ integrate the project artifacts as well as an explanation of some of the first typical steps for first time users.
   +* Deeper documentation for project users - or a link to that.
   +* Documentation needed for making modifications to the project - or a link to that.
   +* Documentation on how to contribute to the project - or a link to that.
   +* A "Getting involved" section that explains which public, archived, linkable communication channels the project uses. This should include a link to the project issue tracker, but also to any further discussion media used.
   +* A "Who we are" section explaining who the [Trusted Committers](trusted-committer.md) behind the project are - with an explanation that instead of contacting these people privately the public communication channels above should be used for communication.
   +* An explanation of what the criteria are for the project to turn contributors into Trusted Committers - if that path exists.
   +
   +![README.md](../../assets/img/standard-base-documentation/README-for-users.png)
   +
   +### CONTRIBUTING.md
   +
   +If the explanation of the steps to make a contribution are too involved, create
   +a separate `CONTRIBUTING.md` document. This document should answer frequently
   +asked questions that contributors have asked in the past. There is no need to
   +provide a comprehensive book up front. Rather, share information that has proven
   +needed by contributors. Likely it will touch upon one or more of the following
   +topics:
   +
   +* How to checkout the project source code from version control.
   +* How to make modifications to the project (potentially including information on coding guidelines).
   +* How to build the project.
   +* How to run tests to make sure the above modifications aren't introducing new bugs.
   +* How to submit your modifications back to the project.
   +* Some information on which turnaround time to expect for modifications made.
   +
   +![CONTRIBUTING.md](../../assets/img/standard-base-documentation/CONTRIBUTING-for-contributors.png)
   +
   +### COMMUNICATION.md
   +
   +Create a separate `COMMUNICATION.md` document. Link this document to your `README.md` so comprehensive contact information can be provided and not take up the extra space in your README. This document should answer frequently
   +asked questions about communicating with your team that contributors need to know. The goal is to streamline communications so users and contributors reach out to the correct person through a single channel. This reduces unnecessary distractions for team members and organizes communications so they do not get lost.
   +
   +Sections in the `COMMUNICATION.md` include points of contact for incoming communications and information about outgoing communications from the project's ownership team. See some examples below.
   +
   +Points of contact for incoming communication and how to contact those users:
   +
   +* Reporting a bug
   +* Following up on a PR
   +* Feature requests
   +* Questions about documentation
   +* Escalations
   +
   +How and when the team communicates outbound with users and how to get added to those communications:
   +
   +* Planned and unplanned outages
   +* Feature releases
   +* Code freezes
   +* Breaking changes
   +
   +There are many of good examples for how to write a `README.md` and what kind
   +of information to include in a `CONTRIBUTING.md` file in various open source projects.
   +Pages like [how to write a readme that rocks](https://m.dotdev.co/how-to-write-a-readme-that-rocks-bc29f279611a),
   +[Open Source Guide from GitHub](https://opensource.guide/) as well as
   +the book [Producing Open Source](https://producingoss.com/en/producingoss.html)
   +all have valuable information on what kind of information to provide. While
   +Producing Open Source does not have a chapter on writing a good README per se,
   +the [Getting Started chapter](https://producingoss.com/en/producingoss.html#starting-from-what-you-have)
   +does provide a fairly extensive list of things that fellow host team members,
   +users and contributors will need. InnerSource projects likely will not cover all
   +of those aspects right from the start, the list itself is helpful for
   +inspiration for what one could cover.
   +
   +In addition to that, this pattern comes with three very basic templates to get you
   +started right away: [README-template.md](templates/README-template.md),
   +[CONTRIBUTING-template.md](templates/CONTRIBUTING-template.md), and [COMMUNICATION-template.md](templates/COMMUNICATION-template.md).
   +
   +## Resulting Context
   +
   +* The time for contributors to get up to speed is significantly reduced.
   +* Time spent on answering initial questions for [Trusted Committers](trusted-committer.md) is significantly reduced, leaving them more time to work on other tasks.
   +* Escalations due to misunderstandings and misalignment are significantly reduced.
   +
   +## Known Instances
   +
   +* Europace AG - See blog post [InnerSource: Adding base documentation](https://tech.europace.de/post/innersource-base-documentation/)
   +* Paypal Inc.
   +* Mercado Libre - create a documentation site that contains how to get started with InnerSource and also define the basic artifacts that a repository must have to be InnerSource (README, CONTRIBUTING, CODING_GUIDELINES, etc).
   +* Analog Devices Inc.
   +* Airbus
   +
   +## Authors
   +
   +* Isabel Drost-Fromm
   +
   +## Acknowledgments
   +
   +* Katie Schueths - for adding the `COMMUNICATION.md` concept
   +
   +## Alias
   +
   +Provide standard base documentation through a README
   +
   +## Status
   +
   +* Structured
   +* Drafted in December 2019.
   +
   +## References
   +
   +* [README-template.md](templates/README-template.md) and
   +* [CONTRIBUTING-template.md](templates/CONTRIBUTING-template.md)
   +
   +## Credits
   +
   +[Web](https://storyset.com/web) and [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 37 days.

   # diff --git a/patterns/2-structured/innersource-license.md b/patterns/2-structured/innersource-license.md
   # index 54b5c55..169ea8a 100644
   # --- a/patterns/2-structured/innersource-license.md
   # +++ b/patterns/2-structured/innersource-license.md
   @@ -32,6 +32,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.
    
    ## Solutions
    
   @@ -51,6 +52,12 @@ The license simplifies the conversations within our organization about sharing s
    
    ## Known Instances
    
   +- **DB Systel**
   +- **Robert Bosch GmbH**
   +- **Airbus**
   +
   +## DB Systel
   +
    DB Systel created their own InnerSource License, see [DB Inner Source License][db-inner-source-license]. They used the [EUPL][eupl], as that offered an open source like starting point, and then worked out the constraints and additional rules required in their specific organizational context.
    
    The first legal entities (companies) within the DB AG are using their InnerSource License.
   @@ -66,6 +73,8 @@ The mentioned collaboration challenges include:
    
    It is worth mentioning that so far the software shared under this InnerSource license is mostly tooling, infrastructure, and tools lower in the stack.
    
   +## Airbus
   +
    Airbus created ad hoc InnerSource licenses to enable InnerSource way of working within a large part of the group.
    
    ## 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 37 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
    
3. github-actions commented on May 1, 2024

   

   github-actionsBot

   on May 1, 2024 – with GitHub Actions

   Author

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

   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
    

   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
    
4. github-actions commented on Jun 1, 2024

   

   github-actionsBot

   on Jun 1, 2024 – with GitHub Actions

   Author

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

   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
    
5. github-actions commented on Jul 1, 2024

   

   github-actionsBot

   on Jul 1, 2024 – with GitHub Actions

   Author

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

   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
    

   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
    
6. github-actions commented on Aug 1, 2024

   

   github-actionsBot

   on Aug 1, 2024 – with GitHub Actions

   Author

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

   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
    

   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
    
7. github-actions commented on Sep 1, 2024

   

   github-actionsBot

   on Sep 1, 2024 – with GitHub Actions

   Author

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

   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!

   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
    

   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.
8. github-actions commented on Oct 1, 2024

   

   github-actionsBot

   on Oct 1, 2024 – with GitHub Actions

   Author

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

   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.

   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
    

   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!
9. github-actions commented on Nov 1, 2024

   

   github-actionsBot

   on Nov 1, 2024 – with GitHub Actions

   Author

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

   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!

   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
    

   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.
10. github-actions commented on Dec 1, 2024

    

    github-actionsBot

    on Dec 1, 2024 – with GitHub Actions

    Author

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

    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!

    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
     

    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.
11. github-actions commented on Jan 1, 2025

    

    github-actionsBot

    on Jan 1, 2025 – with GitHub Actions

    Author

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

    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!

    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

    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.
12. github-actions commented on Feb 1, 2025

    

    github-actionsBot

    on Feb 1, 2025 – with GitHub Actions

    Author

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

    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
     

    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.

    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!

    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
13. github-actions commented on Mar 1, 2025

    

    github-actionsBot

    on Mar 1, 2025 – with GitHub Actions

    Author

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

    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

    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!

    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
     

    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.
14. github-actions commented on Apr 1, 2025

    

    github-actionsBot

    on Apr 1, 2025 – with GitHub Actions

    Author

    More 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 6 days.

    # diff --git a/patterns/2-structured/review-committee.md b/patterns/2-structured/review-committee.md
    # index f27d793..1252af2 100644
    # --- a/patterns/2-structured/review-committee.md
    # +++ b/patterns/2-structured/review-committee.md
    @@ -41,7 +41,7 @@ Company A wants to introduce its first InnerSource initiative. Most managers in
     
     ## Known Instances
     
    -* BIOS at Robert Bosch GmbH (in the early stages of adoption, only - 2009-2012)
    +* 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 6 days.

    # diff --git a/patterns/2-structured/start-as-experiment.md b/patterns/2-structured/start-as-experiment.md
    # index b5ddcac..13451ae 100644
    # --- a/patterns/2-structured/start-as-experiment.md
    # +++ b/patterns/2-structured/start-as-experiment.md
    @@ -53,9 +53,9 @@ 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.
    -- Siemens started their [InnerSource Platform](https://about.gitlab.com/customers/siemens/) code.siemens.com from a single department with a few hundred users. Over the years they scaled it to a company-wide service with 50,000 active users.
    +- **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.
    +- **Siemens** started their [InnerSource Platform](https://about.gitlab.com/customers/siemens/) code.siemens.com from a single department with a few hundred users. Over the years they scaled it to a company-wide service with 50,000 active users.
     
     ## 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 6 days.

    # diff --git a/patterns/2-structured/maturity-model.md b/patterns/2-structured/maturity-model.md
    # index 629c2e4..cfc66dd 100644
    # --- a/patterns/2-structured/maturity-model.md
    # +++ b/patterns/2-structured/maturity-model.md
    @@ -210,10 +210,10 @@ long term.
     
     ## Known Instances
     
    -* Entelgy
    -* Zylk
    -* Bitergia
    -* Airbus
    +* **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 6 days.

    # diff --git a/patterns/2-structured/group-support.md b/patterns/2-structured/group-support.md
    # index 9bf4920..71c154c 100644
    # --- a/patterns/2-structured/group-support.md
    # +++ b/patterns/2-structured/group-support.md
    @@ -69,7 +69,7 @@ Feeling part of a group and being given some structure and responsibility genera
     
     ## Known Instances
     
    -* WellSky
    +* **WellSky**
     
     ## 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 6 days.

    # diff --git a/patterns/2-structured/issue-tracker.md b/patterns/2-structured/issue-tracker.md
    # index 1de6c76..17bb85d 100644
    # --- a/patterns/2-structured/issue-tracker.md
    # +++ b/patterns/2-structured/issue-tracker.md
    @@ -49,8 +49,8 @@ development but also during the planning phase of new features:
     
     ## Known Instances
     
    -* Europace AG - See blog post [Issue Use Cases](https://tech.europace.de/post/using-issues-for-asking-questions-and-tracking-work/)
    -* Siemens manages work on their InnerSource Platform in a fully transparent way. Therefore the work on the InnerSource Platform itself is organized as an InnerSource project. This includes tracking enhancements and bugs, as well as marketing, communication activities and support requests from users.
    +* **Europace AG** - See blog post [Issue Use Cases](https://tech.europace.de/post/using-issues-for-asking-questions-and-tracking-work/)
    +* **Siemens** manages work on their InnerSource Platform in a fully transparent way. Therefore the work on the InnerSource Platform itself is organized as an InnerSource project. This includes tracking enhancements and bugs, as well as marketing, communication activities and support requests from users.
     
     ## Authors
     

    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 110 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 6 days.

    # diff --git a/patterns/2-structured/dedicated-community-leader.md b/patterns/2-structured/dedicated-community-leader.md
    # index 8f5235d..2799d3e 100644
    # --- a/patterns/2-structured/dedicated-community-leader.md
    # +++ b/patterns/2-structured/dedicated-community-leader.md
    @@ -58,8 +58,8 @@ 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.
    +* 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
     

    Contracted Contributor (patterns/2-structured/contracted-contributor.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 6 days.

    # diff --git a/patterns/2-structured/contracted-contributor.md b/patterns/2-structured/contracted-contributor.md
    # index 0790f67..eba1510 100644
    # --- a/patterns/2-structured/contracted-contributor.md
    # +++ b/patterns/2-structured/contracted-contributor.md
    @@ -83,7 +83,7 @@ A formal contracting is also beneficial for contributors and communities:
     
     ## Known Instances
     
    -- BIOS at Robert Bosch GmbH
    +- BIOS at **Robert Bosch GmbH**
     
     ## Status
     

    Trusted Committer (patterns/2-structured/trusted-committer.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 6 days.

    # diff --git a/patterns/2-structured/trusted-committer.md b/patterns/2-structured/trusted-committer.md
    # index 085513c..b826f19 100644
    # --- a/patterns/2-structured/trusted-committer.md
    # +++ b/patterns/2-structured/trusted-committer.md
    @@ -123,12 +123,10 @@ there is a plan for responsible stewardship.
     
     ## Known Instances
     
    -This has been tried and proven successful at:
    -
    -- Nike
    -- PayPal
    -- Mercado Libre - adds a section in the `CONTRIBUTING.md` file to inform who the Trusted Committers are.
    -- Robert Bosch GmbH - we didn't call the role 'Trusted Committer' but we had this role at the beginning of our InnerSource journey. Trusted Committers would be funded for 100 % of their time to be able to focus on this role.
    +- **Nike**
    +- **PayPal**
    +- **Mercado Libre** - adds a section in the `CONTRIBUTING.md` file to inform who the Trusted Committers are.
    +- **Robert Bosch GmbH** - we didn't call the role 'Trusted Committer' but we had this role at the beginning of our InnerSource journey. Trusted Committers would be funded for 100 % of their time to be able to focus on this role.
     
     ![Trusted Committer section in CONTRIBUTING.md of Mercado Libre](../../assets/img/mercadolibre-trusted-committers.png "Trusted Committer section in CONTRIBUTING.md of Mercado Libre")
     

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

    # diff --git a/patterns/2-structured/communication-tooling.md b/patterns/2-structured/communication-tooling.md
    # index b2abf51..b0605ee 100644
    # --- a/patterns/2-structured/communication-tooling.md
    # +++ b/patterns/2-structured/communication-tooling.md
    @@ -74,10 +74,10 @@ to a lower need to repeat explanations.
     
     ## Known Instances
     
    -* Europace AG
    -* Paypal Inc.
    -* Mercado Libre
    -* Siemens makes extensive use of communication channels accessible to all employees for all user questions and discussions around code.siemens.com, InnerSource and Open Source.
    +* **Europace AG**
    +* **Paypal Inc.**
    +* **Mercado Libre**
    +* **Siemens** makes extensive use of communication channels accessible to all employees for all user questions and discussions around code.siemens.com, InnerSource and Open Source.
     
     ## Authors
     

    Cross-Team Project Valuation (patterns/2-structured/crossteam-project-valuation.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 6 days.

    # diff --git a/patterns/2-structured/crossteam-project-valuation.md b/patterns/2-structured/crossteam-project-valuation.md
    # index 96b89c8..dd2adfd 100644
    # --- a/patterns/2-structured/crossteam-project-valuation.md
    # +++ b/patterns/2-structured/crossteam-project-valuation.md
    @@ -92,7 +92,7 @@ They will provide a head-and-shoulders improvement in on-the-ground results over
     
     ## Known Instances
     
    -* Nike
    +* **Nike**
     
     ## 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 6 days.

    # diff --git a/patterns/2-structured/praise-participants.md b/patterns/2-structured/praise-participants.md
    # index 12d176b..7836f81 100644
    # --- a/patterns/2-structured/praise-participants.md
    # +++ b/patterns/2-structured/praise-participants.md
    @@ -71,9 +71,9 @@ Overdoing it may feel insincere and mechanical and defeat your purpose in reachi
     
     ## Known Instances
     
    -* Nike (multiple projects)
    -* 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)
    -* Siemens awards successful InnerSource projects and contributors at their yearly internal InnerSource Summit.
    +* **Nike** (multiple projects)
    +* **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)
    +* **Siemens** awards successful InnerSource projects and contributors at their yearly internal InnerSource Summit.
     
     ## 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 6 days.

    # diff --git a/patterns/2-structured/innersource-license.md b/patterns/2-structured/innersource-license.md
    # index bc031e9..c085653 100644
    # --- a/patterns/2-structured/innersource-license.md
    # +++ b/patterns/2-structured/innersource-license.md
    @@ -55,6 +55,7 @@ The license simplifies the conversations within our organization about sharing s
     - **Robert Bosch GmbH**
     - **Airbus**
     - **GovTech (Singapore Government)**
    +- **Siemens** has developed their own InnerSource license alongside other necessary legal agreements between subsidiaries.
     
     ### DB Systel
     

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

    # diff --git a/patterns/2-structured/innersource-portal.md b/patterns/2-structured/innersource-portal.md
    # index 0473fd5..823af86 100644
    # --- a/patterns/2-structured/innersource-portal.md
    # +++ b/patterns/2-structured/innersource-portal.md
    @@ -108,6 +108,7 @@ It is a good solution for a portal with a few dozen projects, though.
     * **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.
    +* **Siemens** has set up an internal portal that provides documentation for InnerSource maintainers, contributors, users and their managers. It also serves as an entry point to explore available projects and gives hints to improve project visibility.
     
     ## References
     

    Service vs. Library (patterns/2-structured/service-vs-library.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 6 days.

    # diff --git a/patterns/2-structured/service-vs-library.md b/patterns/2-structured/service-vs-library.md
    # index 51bde3c..7370bb1 100644
    # --- a/patterns/2-structured/service-vs-library.md
    # +++ b/patterns/2-structured/service-vs-library.md
    @@ -72,9 +72,9 @@ Related to this pattern is the [30 Day Warranty](30-day-warranty.md) pattern tha
     
     ## Known Instances
     
    -* Europace AG
    -* Flutter Entertainment: A [Flutter InnerSource application](https://innersource.flutter.com/sdlc/) has a shared code "service" repository with cross-team contribution and CI pipeline to build and publish a shared release artifact. Each adopting team has a "deployment config" repository defining their own deployment. This is driven by varying regulatory requirements, service and incident management practices and infrastructure skill sets in different areas of the business.
    -* WellSky (see [Continuous InnerSource in Production - 5 Times](https://www.youtube.com/watch?v=loSTj4yIG9Q&pp=ygUkY29udGludW91cyBpbm5lcnNvdXJjZSBpbiBwcm9kdWN0aW9u))
    +* **Europace AG**
    +* **Flutter Entertainment**: A [Flutter InnerSource application](https://innersource.flutter.com/sdlc/) has a shared code "service" repository with cross-team contribution and CI pipeline to build and publish a shared release artifact. Each adopting team has a "deployment config" repository defining their own deployment. This is driven by varying regulatory requirements, service and incident management practices and infrastructure skill sets in different areas of the business.
    +* **WellSky** (see [Continuous InnerSource in Production - 5 Times](https://www.youtube.com/watch?v=loSTj4yIG9Q&pp=ygUkY29udGludW91cyBpbm5lcnNvdXJjZSBpbiBwcm9kdWN0aW9u))
     
     ## 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 6 days.

    # diff --git a/patterns/2-structured/30-day-warranty.md b/patterns/2-structured/30-day-warranty.md
    # index b21ab81..9f60805 100644
    # --- a/patterns/2-structured/30-day-warranty.md
    # +++ b/patterns/2-structured/30-day-warranty.md
    @@ -46,10 +46,10 @@ In addition it helps to provide clear [contribution guidelines](./base-documenta
     
     ## Known Instances
     
    -- 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 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)
    +- **PayPal** Tried this and it was proven successful.
    +- **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** 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
     

    Gig Marketplace (patterns/2-structured/gig-marketplace.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 6 days.

    # diff --git a/patterns/2-structured/gig-marketplace.md b/patterns/2-structured/gig-marketplace.md
    # index 7e2ae37..69552cb 100644
    # --- a/patterns/2-structured/gig-marketplace.md
    # +++ b/patterns/2-structured/gig-marketplace.md
    @@ -60,7 +60,7 @@ When used in combination with the InnerSource Portal pattern, the Gig Marketplac
     ## Known Instances
     
     * A large financial services organization has used the creation of an InnerSource Gig Marketplace website to foster their InnerSource program.
    -* SAP implemented the Gig Marketplace pattern - a new InnerSource program was added to the internal job platform where positions and similar offerings can be posted.
    +* **SAP** implemented the Gig Marketplace pattern - a new InnerSource program was added to the internal job platform where positions and similar offerings can be posted.
     * The Gig Marketplace pattern has been proven to work extremely well with the associated [InnerSource Portal](./innersource-portal.md) pattern in this context.  The InnerSource Portal increases awareness of specific projects currently underway while the Gig Marketplace advertises tasks of a certain type available to be worked on within those projects.
     
     ## 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 6 days.

    # diff --git a/patterns/2-structured/repository-activity-score.md b/patterns/2-structured/repository-activity-score.md
    # index 9aadaec..73c26a5 100644
    # --- a/patterns/2-structured/repository-activity-score.md
    # +++ b/patterns/2-structured/repository-activity-score.md
    @@ -114,9 +114,9 @@ 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](./base-documentation.md) and the [InnerSource License](./innersource-license.md).
    -* Siemens includes repository activity in their InnerSource project quality score. Maintainers can use the quality score to improve their project and communicate their score via badges.
    +* **SAP** - 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](./base-documentation.md) and the [InnerSource License](./innersource-license.md).
    +* **Siemens** includes repository activity in their InnerSource project quality score. Maintainers can use the quality score to improve their project and communicate their score via badges.
     
     ## Status
     

    Document your Guiding Principles (patterns/2-structured/document-your-guiding-principles.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 6 days.

    # diff --git a/patterns/2-structured/document-your-guiding-principles.md b/patterns/2-structured/document-your-guiding-principles.md
    # index 9fbd159..7224d6b 100644
    # --- a/patterns/2-structured/document-your-guiding-principles.md
    # +++ b/patterns/2-structured/document-your-guiding-principles.md
    @@ -121,10 +121,10 @@ All Trusted Committers of a project are published.
     
     ## Known Instances
     
    -* Europace AG
    -* GitHub
    -* Robert Bosch GmbH
    -* Siemens' InnerSource strategy is built upon the guiding principles of Documentation, Workflow, Transparency, Continuous Integration and Culture which are detailed in their InnerSource portal.
    +* **Europace AG**
    +* **GitHub**
    +* **Robert Bosch GmbH**
    +* **Siemens'** InnerSource strategy is built upon the guiding principles of Documentation, Workflow, Transparency, Continuous Integration and Culture which are detailed in their InnerSource portal.
     
     ### Europace AG
     

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

    # diff --git a/patterns/2-structured/base-documentation.md b/patterns/2-structured/base-documentation.md
    # index dd2a864..9004df8 100644
    # --- a/patterns/2-structured/base-documentation.md
    # +++ b/patterns/2-structured/base-documentation.md
    @@ -128,12 +128,12 @@ started right away: [README-template.md](templates/README-template.md),
     
     ## Known Instances
     
    -* Europace AG - See blog post [InnerSource: Adding base documentation](https://tech.europace.de/post/innersource-base-documentation/)
    -* Paypal Inc.
    -* Mercado Libre - create a documentation site that contains how to get started with InnerSource and also define the basic artifacts that a repository must have to be InnerSource (README, CONTRIBUTING, CODING_GUIDELINES, etc).
    -* Analog Devices Inc.
    -* Airbus
    -* Siemens automatically creates a checklist issue for every new InnerSource project to make maintainers aware of mandatory requirements (e.g. business approval, license & copyright, export control, contributing guidelines, maintainer maturity) as well as best practices (e.g. documentation as code, semantic versioning, continuous integration/deployment).
    +* **Europace AG** - See blog post [InnerSource: Adding base documentation](https://tech.europace.de/post/innersource-base-documentation/)
    +* **Paypal Inc.**
    +* **Mercado Libre** - create a documentation site that contains how to get started with InnerSource and also define the basic artifacts that a repository must have to be InnerSource (README, CONTRIBUTING, CODING_GUIDELINES, etc).
    +* **Analog Devices Inc.**
    +* **Airbus**
    +* **Siemens** automatically creates a checklist issue for every new InnerSource project to make maintainers aware of mandatory requirements (e.g. business approval, license & copyright, export control, contributing guidelines, maintainer maturity) as well as best practices (e.g. documentation as code, semantic versioning, continuous integration/deployment).
     
     ## Authors
     
15. spier

    closed this as completedon Apr 5, 2025