search

InnerSourceCommons / InnerSourcePatterns

Proven approaches that can guide you through applying open source best practices within your organization
https://patterns.innersourcecommons.org
Creative Commons Attribution Share Alike 4.0 International
744 stars 181 forks source link

🇯🇵 Japanese: Content Consistency Issue #553

Closed github-actions[bot] closed 1 year ago

github-actions[bot] commented 1 year ago

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 there is an update to content/en. It compares the git update history to let you know what updates are overdue. The issue should be closed when the update is complete.

(patterns/2-structured/review-committee.md) - Original File(en): [patterns/2-structured/review-committee.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/review-committee.md) - Translated File(ja): [translation/ja/patterns/review-committee.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/translation/ja/patterns/review-committee.md) - [Diff on GitHub](https://github.com/yuhattor/innersourcecommons.org/compare/...1d27905fb09e29631795c8953fe8a141d7f40d34) - Days since overdue updates: 39 days ```diff # diff --git a/patterns/2-structured/review-committee.md b/patterns/2-structured/review-committee.md # index a0d72f0..e1a47e4 100644 # --- a/patterns/2-structured/review-committee.md # +++ b/patterns/2-structured/review-committee.md @@ -4,7 +4,7 @@ Review Committee ## Patlet -The InnerSource working model is a radical departure from more traditional approaches, for developers and managers alike. By establishing a review committee as an interface between the InnerSource initiative and all senior managers of business units participating in it, the latter are more likely to familiarise themselves with the initiative and support it, as it affords them a certain level of oversight and control without fostering micromanagement. +The InnerSource working model is a radical departure from more traditional approaches, for developers and managers alike. By establishing a review committee as an interface between the InnerSource initiative and all senior managers of business units participating in it, the latter are more likely to familiarize themselves with the initiative and support it, as it affords them a certain level of oversight and control without fostering micromanagement. ## Problem ```
(patterns/2-structured/praise-participants.md) - Original File(en): [patterns/2-structured/praise-participants.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/praise-participants.md) - Translated File(ja): [translation/ja/patterns/praise-participants.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/translation/ja/patterns/praise-participants.md) - [Diff on GitHub](https://github.com/yuhattor/innersourcecommons.org/compare/...1d27905fb09e29631795c8953fe8a141d7f40d34) - Days since overdue updates: 39 days ```diff # diff --git a/patterns/2-structured/praise-participants.md b/patterns/2-structured/praise-participants.md # index 27dc7ae..1027104 100644 # --- a/patterns/2-structured/praise-participants.md # +++ b/patterns/2-structured/praise-participants.md @@ -77,7 +77,7 @@ Overdoing it may feel insincere and mechanical and defeat your purpose in reachi * Russ Rutledge -## Acknowledgements +## Acknowledgments * [Todd Lisonbee](https://github.com/tlisonbee) for encouraging to "keep it real". * [Isabel Drost-Fromm](https://github.com/MaineC) for [this extra explanation](https://youtu.be/h3MPewsk5PU?t=357) of a "qualified" thank you. ```
(patterns/2-structured/document-your-guiding-principles.md) - Original File(en): [patterns/2-structured/document-your-guiding-principles.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/document-your-guiding-principles.md) - Translated File(ja): [translation/ja/patterns/document-your-guiding-principles.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/translation/ja/patterns/document-your-guiding-principles.md) - [Diff on GitHub](https://github.com/yuhattor/innersourcecommons.org/compare/...1d27905fb09e29631795c8953fe8a141d7f40d34) - Days since overdue updates: 39 days ```diff # diff --git a/patterns/2-structured/document-your-guiding-principles.md b/patterns/2-structured/document-your-guiding-principles.md # index 18a80b9..01c423d 100644 # --- a/patterns/2-structured/document-your-guiding-principles.md # +++ b/patterns/2-structured/document-your-guiding-principles.md @@ -4,21 +4,21 @@ Document your Guiding Principles ## Patlet -The usual InnerSource explanation of "applying open source best practices inside an organisation" does not work well with people lacking an open source background. +The usual InnerSource explanation of "applying open source best practices inside an organization" does not work well with people lacking an open source background. As a remedy the most important principles of InnerSource get documented and published widely. ## Problem -The organisation is trying to roll out InnerSource at a larger scale. +The organization is trying to roll out InnerSource at a larger scale. The initiative started among open source enthusiasts. The goal is now to get buy-in from people that are lacking open source experience. For that audience the typical slogan of "applying open source best practices" is no longer sufficient to transport the message of what InnerSource is, which problems it solves and which tools it uses for solving these issues. -As a result InnerSource adoption in the organisation slows down. +As a result InnerSource adoption in the organization slows down. Teams develop diverging ideas of what the goals of InnerSource is about and how to best implement it leading to confusion when contributors are starting to cross team boundaries. ## Story -Early experiments in an organisation have shown that open source collaboration best practices can be beneficial. +Early experiments in an organization have shown that open source collaboration best practices can be beneficial. The next step now is to move the initiative to teams and individuals lacking a deep background in open source. The goal now is to clearly communicate the goals of the InnerSource initiative @@ -32,27 +32,27 @@ as well as a clear path towards achieving these goals. ## Forces * Teams have trouble communicating exactly what the important aspects of InnerSource are. -* People lacking open source experience fail to understand what it means to bring open source best practices into the organisation. +* People lacking open source experience fail to understand what it means to bring open source best practices into the organization. * On a daily basis teams trying to follow InnerSource best practices have a hard time deciding if what they are doing is inline with general InnerSource values. ## Solution -Those driving the InnerSource initiative in the organisation need to help the teams and individuals that are lacking a deep background in open source, and therefore have a less intuitive understanding of InnerSource. +Those driving the InnerSource initiative in the organization need to help the teams and individuals that are lacking a deep background in open source, and therefore have a less intuitive understanding of InnerSource. Clarity should be provided to teams and individuals by documenting these two areas: -1. **Purpose** - Why does the organisation want to adopt InnerSource? +1. **Purpose** - Why does the organization want to adopt InnerSource? 2. **Principles** - Which InnerSource principles will help to address these challenges? The following sections provide more details about both of these, meant as possible starting points to document them for your organization. -### Why does the organisation want to adopt InnerSource? +### Why does the organization want to adopt InnerSource? -In the past InnerSource has proven to be successful to solve several issues commonly found in organisations. +In the past InnerSource has proven to be successful to solve several issues commonly found in organizations. However which organizational challenges does your organization hope to improve upon using InnerSource? -Instead of going for generalizations, try to exactly identify the solutions that match the challenges of your organisation - preferably with those affected by the change you want to see. +Instead of going for generalizations, try to exactly identify the solutions that match the challenges of your organization - preferably with those affected by the change you want to see. Some challenges that others have addressed by following InnerSource best practices: @@ -71,9 +71,9 @@ Once teams understand which problems InnerSource will help them address, the nex Based on basic open source development principles the following guidelines have been proven successful: -(1) Code must be transparently hosted within the organisation +(1) Code must be transparently hosted within the organization -Source code, documentation, data relevant for project development must be available and easy to find for anyone in the organisation. +Source code, documentation, data relevant for project development must be available and easy to find for anyone in the organization. (2) Contributions over feature requests @@ -84,7 +84,7 @@ Projects provide contribution guidelines to avoid friction. (3) Mistakes are opportunities for learning -With work visible across the entire organisation any mistake is visible to everyone. +With work visible across the entire organization any mistake is visible to everyone. As a result a culture must be established in which mistakes are opportunities for learning instead of failure that should be avoided at all cost. (4) Written over verbal communication @@ -104,7 +104,7 @@ Previous communication needs to be stored in a way that can easily be searched. Two caveats though: 1. This does not replace structured documentation. It can serve as a starting point to collect structured documentation though. -2. There are exceptions to the rule of everything being written and accessible to the entire organisation: People related discussions as well as security related discussions are sensitive and should not be held in public. +2. There are exceptions to the rule of everything being written and accessible to the entire organization: People related discussions as well as security related discussions are sensitive and should not be held in public. (6) Reward Trusted Committership @@ -114,10 +114,10 @@ All Trusted Committers of a project are published. ## Resulting Context -* Organisation members understand which challenges they can address by applying InnerSource best practices. -* Organisation members lacking prior open source experience understand the basic values and principles of InnerSource projects. -* Organisation members lacking prior open source experience are able to check their daily activities against a set of common established values. -* The organisation's development practices become more similar to open source projects thus making it easier for organisation members to participate in open source projects. +* Organization members understand which challenges they can address by applying InnerSource best practices. +* Organization members lacking prior open source experience understand the basic values and principles of InnerSource projects. +* Organization members lacking prior open source experience are able to check their daily activities against a set of common established values. +* The organization's development practices become more similar to open source projects thus making it easier for organization members to participate in open source projects. ## Known Instances @@ -127,8 +127,8 @@ All Trusted Committers of a project are published. ### Europace AG -The InnerSource principles listed in the Solution above are mostly based on Europace's experience. -For more details see [Europace InnerSource Prinzipien](https://tech.europace.de/post/europace-inner-source-prinzipien/) (in German). +The InnerSource principles listed in the Solution section above are mostly based on Europace's experience. +See [details](https://tech.europace.de/post/europace-inner-source-prinzipien/) (in German). ### GitHub @@ -206,7 +206,7 @@ Structured * Isabel Drost-Fromm * Georg Grütter -## Acknowledgements +## Acknowledgments * Zack Koppert - for sharing GitHub's approach in the Known Instances ```
(patterns/2-structured/contracted-contributor.md) - Original File(en): [patterns/2-structured/contracted-contributor.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/contracted-contributor.md) - Translated File(ja): [translation/ja/patterns/contracted-contributor.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/translation/ja/patterns/contracted-contributor.md) - [Diff on GitHub](https://github.com/yuhattor/innersourcecommons.org/compare/...1d27905fb09e29631795c8953fe8a141d7f40d34) - Days since overdue updates: 39 days ```diff # diff --git a/patterns/2-structured/contracted-contributor.md b/patterns/2-structured/contracted-contributor.md # index d36043f..0790f67 100644 # --- a/patterns/2-structured/contracted-contributor.md # +++ b/patterns/2-structured/contracted-contributor.md @@ -31,12 +31,12 @@ initiative and partake in periodic reviews until there is proof it yields the expected results (see [Review Committee](review-committee.md)). Top level management has announced their support for InnerSource on various company-internal meetings. -However, top-level management has not yet empowered or incentivised mid-level +However, top-level management has not yet empowered or incentivized mid-level managers to allow or even motivate their employees to participate in cross-divisional InnerSource activities. In addition to that, the capacity of every associate is usually allocated to non InnerSource projects for 100 % of their working time. Cross organizational collaboration is not yet the norm and -line managers usually do not have targets outside of their own organisation. +line managers usually do not have targets outside of their own organization. Contributions to InnerSource projects are expected to be made during working hours, not during free time. @@ -46,7 +46,7 @@ hours, not during free time. - Line managers and HR will, by default, judge the performance of their subordinates against their business units goals, which might not be aligned with the goals of the InnerSource community. - The less executive air cover a line manager perceives he has, the less likely is he or she to have his or her staff participate in InnerSource activities which contribute to another business unit. - The less transparency and control a line manager has of work done by one of her subordinates, the less likely is she to allow her to contribute. -- The less formally work in InnerSource is managed and organised, the less likely a line manager who is accustomed to formal processes is to sign off on one of her employees contributing to InnerSource. +- The less formally work in InnerSource is managed and organized, the less likely a line manager who is accustomed to formal processes is to sign off on one of her employees contributing to InnerSource. - The more time an associate spends on contributions to an InnerSource project which does not benefit his day-to-day work, the more will the workload for his teammates in his business unit increase. - Individual contributors will likely consider participating in InnerSource as an opportunity to enhance their professional network within the company and to gain knowledge and experience in the technical area of her contributions. @@ -93,7 +93,7 @@ A formal contracting is also beneficial for contributors and communities: - Georg Grütter (Robert Bosch GmbH) -## Acknowledgements +## Acknowledgments - Diogo Fregonese (Robert Bosch GmbH) - Robert Hansel (Robert Bosch GmbH) ```
(patterns/2-structured/repository-activity-score.md) - Original File(en): [patterns/2-structured/repository-activity-score.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/repository-activity-score.md) - Translated File(ja): [translation/ja/patterns/repository-activity-score.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/translation/ja/patterns/repository-activity-score.md) - [Diff on GitHub](https://github.com/yuhattor/innersourcecommons.org/compare/...1d27905fb09e29631795c8953fe8a141d7f40d34) - Days since overdue updates: 39 days ```diff # diff --git a/patterns/2-structured/repository-activity-score.md b/patterns/2-structured/repository-activity-score.md # index 81c24c3..c7d6990 100644 # --- a/patterns/2-structured/repository-activity-score.md # +++ b/patterns/2-structured/repository-activity-score.md @@ -46,7 +46,7 @@ The repository activity score is a numeric value that represents the (GitHub) ac In addition, it considers activity parameters like last update and creation date of the repo to give young projects with a lot of traction a boost. Projects with contributing guidelines, active participation stats, and issues (public backlog) receive a higher ranking as well. -All of this can be fetched and calculated automatically using the result set of the [GitHub search API](https://docs.github.com/en/rest/search#search-repositories) and [GitHub statistics API](https://docs.github.com/en/rest/metrics/statistics). Other code versioning systems like BitBucket, Gitlab, Gerrit can be integrated as well if a similar API is available. +All of this can be fetched and calculated automatically using the result set of the [GitHub search API](https://docs.github.com/en/rest/search#search-repositories) and [GitHub statistics API](https://docs.github.com/en/rest/metrics/statistics). Other code versioning systems like Bitbucket, GitLab, Gerrit can be integrated as well if a similar API is available. The code below assumes the variable `repo` contains an entity fetched from the GitHub `search` API and the `participation` object contains an entity from the GitHub `stats/participation` API. @@ -114,7 +114,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 InnerSourceCommons 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). +* 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). ## Status @@ -124,7 +124,7 @@ The repository activity score is a simple calculation based on the GitHub API. I [Michael Graf (SAP)](mailto:mi.graf@sap.com) -## Acknowledgements +## Acknowledgments Thank you to the InnerSource Commons Community for lightning-fast advice, and a lot of helpful input to feed this pattern! Especially: ```
(patterns/2-structured/innersource-license.md) - Original File(en): [patterns/2-structured/innersource-license.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/innersource-license.md) - Translated File(ja): [translation/ja/patterns/innersource-license.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/translation/ja/patterns/innersource-license.md) - [Diff on GitHub](https://github.com/yuhattor/innersourcecommons.org/compare/...1d27905fb09e29631795c8953fe8a141d7f40d34) - Days since overdue updates: 39 days ```diff # diff --git a/patterns/2-structured/innersource-license.md b/patterns/2-structured/innersource-license.md # index 37e199b..1183ea4 100644 # --- a/patterns/2-structured/innersource-license.md # +++ b/patterns/2-structured/innersource-license.md @@ -37,7 +37,7 @@ At the time of sharing the source code, it can not be reliably predicted what th Creating an **InnerSource License** customized to the needs of the organization in question (and their legal entities). This license needs to be generic enough to be applied to the most important inter-company relationships. -It is important to write the InnerSource License such that it truly allows for OpenSource-like collaborations across the boundaries of the involved legal entities. Therefore the 4 freedoms of free software should be integrated into the license. +It is important to write the InnerSource License such that it truly allows for open source style collaboration across the boundaries of the involved legal entities. Therefore the 4 freedoms of free software should be integrated into the license. The License is written as a formal legal document, and can be used as part of contracts between the legal entities to govern the code sharing agreements. ```
(patterns/2-structured/innersource-portal.md) - Original File(en): [patterns/2-structured/innersource-portal.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/innersource-portal.md) - Translated File(ja): [translation/ja/patterns/innersource-portal.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/translation/ja/patterns/innersource-portal.md) - [Diff on GitHub](https://github.com/yuhattor/innersourcecommons.org/compare/...845cb29a542fd4383c2d1771ce9499f387bc8ab3) - Days since overdue updates: 10 days ```diff # diff --git a/patterns/2-structured/innersource-portal.md b/patterns/2-structured/innersource-portal.md # index a12e28a..e291f8d 100644 # --- a/patterns/2-structured/innersource-portal.md # +++ b/patterns/2-structured/innersource-portal.md @@ -75,7 +75,7 @@ A [reference implementation](https://github.com/SAP/project-portal-for-innersour ![Santander InnerSource Portal](../../assets/img/santander_portal.png "Banco Santander InnerSource Portal") -* **Airbus** deployed the [SAP portal](https://github.com/SAP/project-portal-for-innersource) with minor modifications to match Airbus graphical identity. In addition, the [Python crawler](https://github.com/zkoppert/innersource-crawler) was patched to work with GitHub Enterprise instances. +* **Airbus** used the [SAP Portal](https://github.com/SAP/project-portal-for-innersource) as a Proof of Concept. It is now using the [Bazaar plugin](https://github.com/backstage/backstage/blob/master/plugins/bazaar/README.md) of [Backstage](https://backstage.io) as the latter became the official developer experience tool internally. It provides a convenient self-registering capability for all the divisions. * **Mercado Libre** use an instance of the [SAP portal](https://github.com/SAP/project-portal-for-innersource) to discover existing InnerSource projects within the organization. ```
(patterns/2-structured/trusted-committer.md) - Original File(en): [patterns/2-structured/trusted-committer.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/trusted-committer.md) - Translated File(ja): [translation/ja/patterns/trusted-committer.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/translation/ja/patterns/trusted-committer.md) - [Diff on GitHub](https://github.com/yuhattor/innersourcecommons.org/compare/...1d27905fb09e29631795c8953fe8a141d7f40d34) - Days since overdue updates: 39 days ```diff # diff --git a/patterns/2-structured/trusted-committer.md b/patterns/2-structured/trusted-committer.md # index 3d04eca..085513c 100644 # --- a/patterns/2-structured/trusted-committer.md # +++ b/patterns/2-structured/trusted-committer.md @@ -141,7 +141,7 @@ This has been tried and proven successful at: - [Fernando Freire] -## Acknowledgements +## Acknowledgments - [Russell Rutledge] - [Loren Sanz] ```
(patterns/2-structured/transparent-cross-team-decision-making-using-rfcs.md) - Original File(en): [patterns/2-structured/transparent-cross-team-decision-making-using-rfcs.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/transparent-cross-team-decision-making-using-rfcs.md) - Translated File(ja): [translation/ja/patterns/transparent-cross-team-decision-making-using-rfcs.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/translation/ja/patterns/transparent-cross-team-decision-making-using-rfcs.md) - [Diff on GitHub](https://github.com/yuhattor/innersourcecommons.org/compare/...1d27905fb09e29631795c8953fe8a141d7f40d34) - Days since overdue updates: 39 days ```diff # 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 4847082..f21de97 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 @@ -60,7 +60,7 @@ Important elements of the solution are: ### Examples/Templates - [Rust][rust] is a good Open Source example of RFC template and process, and has been the basis for many other RFC processes. -- [Genericised BBC iPlayer & Sounds RFC template](templates/rfc.md), originally based on the [Rust][rust] template +- [Generalized BBC iPlayer & Sounds RFC template](templates/rfc.md), originally based on the [Rust][rust] template ## Resulting Context @@ -69,7 +69,7 @@ Implementing an RFC-like process has proven to be valuable, as it makes the cros Observable positive effects: - **democratization of the decision making process** for decisions that impact many teams (also offloading team leads from that burden) -- **a open asynchronous communication method** that works well across multiple teams and geos +- **a open asynchronous communication method** that works well across multiple teams and geographies - **empowers individuals and teams** to effect large scale change - **record of decisions made** for people to refer back to for context - **scales impact of experienced engineers** as they can contribute to solutions asynchronously and remotely, rather than needing to be present in a meeting ```
(patterns/2-structured/dedicated-community-leader.md) - Original File(en): [patterns/2-structured/dedicated-community-leader.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/dedicated-community-leader.md) - Translated File(ja): [translation/ja/patterns/dedicated-community-leader.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/translation/ja/patterns/dedicated-community-leader.md) - [Diff on GitHub](https://github.com/yuhattor/innersourcecommons.org/compare/...1d27905fb09e29631795c8953fe8a141d7f40d34) - Days since overdue updates: 39 days ```diff # diff --git a/patterns/2-structured/dedicated-community-leader.md b/patterns/2-structured/dedicated-community-leader.md # index 19e6ce3..91f3c3d 100644 # --- a/patterns/2-structured/dedicated-community-leader.md # +++ b/patterns/2-structured/dedicated-community-leader.md @@ -73,7 +73,7 @@ Dedicated Community Manager - Georg Grütter (Robert Bosch GmbH) - Diogo Fregonese (Robert Bosch GmbH) -## Acknowledgements +## Acknowledgments - Tim Yao - Padma Sudarsan ```
(patterns/2-structured/crossteam-project-valuation.md) - Original File(en): [patterns/2-structured/crossteam-project-valuation.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/crossteam-project-valuation.md) - Translated File(ja): [translation/ja/patterns/crossteam-project-valuation.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/translation/ja/patterns/crossteam-project-valuation.md) - [Diff on GitHub](https://github.com/yuhattor/innersourcecommons.org/compare/...1d27905fb09e29631795c8953fe8a141d7f40d34) - Days since overdue updates: 39 days ```diff # diff --git a/patterns/2-structured/crossteam-project-valuation.md b/patterns/2-structured/crossteam-project-valuation.md # index 1fede7c..96b89c8 100644 # --- a/patterns/2-structured/crossteam-project-valuation.md # +++ b/patterns/2-structured/crossteam-project-valuation.md @@ -15,7 +15,7 @@ Here's a data-driven way to represent your project that both articulates its val ## Problem Cross-team projects can potentially have a very large impact on the company yet are difficult to represent in a data-driven fashion. -As a result, it is easy and common to either pursue projects that does not provide real value or to underfund what would otherwise produce great value. +As a result, it is easy and common to either pursue projects that do not provide real value or to underfund what would otherwise produce great value. ## Forces @@ -49,7 +49,7 @@ The idea is for the group of experts to be able to say to each other, "We don't Specifically, you should estimate a _maximum_ reasonable time to consume your project output and _minimum_ reasonable times for consumers to otherwise home-roll, use and maintain their own solutions. One note about cost of "rolling your own solution" (home-roll). The cost to home-roll a solution is NOT necessarily (very unlikely, in fact) the same as the cost of making a shared solution. -Oftentimes for the same functionality the modularity and quality involved in building a cross-team, shared solution makes it a noticeably higher investment than a quick, hardcoded implementation used just once. +Oftentimes for the same functionality the modularity and quality involved in building a cross-team, shared solution makes it a noticeably higher investment than a quick, hard-coded implementation used just once. ### Formula @@ -58,9 +58,9 @@ Once you have your worst-case bounds you can value your cross-team project outpu ``` [Time Saved] - [Time Invested] -([Count of New Onboardings] * [Cost to Home-Roll] * [Percent Useful Functionality] + [Count of Usages] * [Maintenance Cost Per Use]) - ([Count of New Onboardings] * [Cost to Onboard]) +([Count of New On-boardings] * [Cost to Home-Roll] * [Percent Useful Functionality] + [Count of Usages] * [Maintenance Cost Per Use]) - ([Count of New On-boardings] * [Cost to On-board]) -[Count of New Onboardings] * ([Cost to Home-Roll] * [Percent Useful Functionality] - [Cost to Onboard]) + [Count of Usages] * [Maintenance Cost Per Use] +[Count of New On-boardings] * ([Cost to Home-Roll] * [Percent Useful Functionality] - [Cost to On-board]) + [Count of Usages] * [Maintenance Cost Per Use] ``` ### Commentary @@ -81,7 +81,7 @@ Some may be concerned about the lack of accuracy in this valuation approach. It 1. Help those involved to know what areas of cross-team effort are higher priority to pursue based on their value. In-practice, as long as these valuations are within an order-of-magnitude of reality and one-another, they are sufficiently accurate to fill these purposes. -They will provide a head-and-shoulders improvement in on-the-ground results over the ad-hoc valuations (and resultant effects) described in the **Problem** section at the beginning of this document. +They will provide a head-and-shoulders improvement in on-the-ground results over the ad hoc valuations (and resultant effects) described in the **Problem** section at the beginning of this document. ## Resulting Context @@ -103,6 +103,6 @@ They will provide a head-and-shoulders improvement in on-the-ground results over * Russ Rutledge -## Acknowledgement +## Acknowledgments * Jeremiah Wright for teaching me to think about cross-team projects as an internal business dealing in the currency of developer time. ```
(patterns/2-structured/30-day-warranty.md) - Original File(en): [patterns/2-structured/30-day-warranty.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/30-day-warranty.md) - Translated File(ja): [translation/ja/patterns/30-day-warranty.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/translation/ja/patterns/30-day-warranty.md) - [Diff on GitHub](https://github.com/yuhattor/innersourcecommons.org/compare/...1d27905fb09e29631795c8953fe8a141d7f40d34) - Days since overdue updates: 39 days ```diff # diff --git a/patterns/2-structured/30-day-warranty.md b/patterns/2-structured/30-day-warranty.md # index b1a37d1..7c2ab75 100644 # --- a/patterns/2-structured/30-day-warranty.md # +++ b/patterns/2-structured/30-day-warranty.md @@ -54,7 +54,7 @@ In addition it helps to provide clear [contribution guidelines](./project-setup/ - Cedric Williams -## Acknowledgement +## Acknowledgments - Dirk-Willem van Gulik - Padma Sudarsan ```
(patterns/2-structured/core-team.md) - Original File(en): [patterns/2-structured/core-team.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/core-team.md) - Translated File(ja): [translation/ja/patterns/core-team.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/translation/ja/patterns/core-team.md) - [Diff on GitHub](https://github.com/yuhattor/innersourcecommons.org/compare/...1d27905fb09e29631795c8953fe8a141d7f40d34) - Days since overdue updates: 39 days ```diff # diff --git a/patterns/2-structured/core-team.md b/patterns/2-structured/core-team.md # index 84c6504..e621395 100644 # --- a/patterns/2-structured/core-team.md # +++ b/patterns/2-structured/core-team.md @@ -20,7 +20,7 @@ This could be due to things like: Some possible causes: * Poor documentation (again). * Frequent bugs. - * Unintuitive setup. + * Nonintuitive setup. ## Story @@ -35,7 +35,7 @@ It's clearly due for an overhaul (e.g. refactoring, testing, documentation, etc. * Many teams need the project. * The project has significant tech debt. * Slow adoption and iteration on the project. -* There is not a owner or maintainer who takes reponsibility for the project and contribution ecosystem as a whole. +* There is not a owner or maintainer who takes responsibility for the project and contribution ecosystem as a whole. ## Forces @@ -53,7 +53,7 @@ Here are some specific examples: * Production bugs * Documentation -* Onboarding tutorials and examples +* On-boarding tutorials and examples * Automated testing * CI/CD * Local environment ```
(patterns/2-structured/service-vs-library.md) - Original File(en): [patterns/2-structured/service-vs-library.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/service-vs-library.md) - Translated File(ja): [translation/ja/patterns/service-vs-library.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/translation/ja/patterns/service-vs-library.md) - [Diff on GitHub](https://github.com/yuhattor/innersourcecommons.org/compare/...1d27905fb09e29631795c8953fe8a141d7f40d34) - Days since overdue updates: 39 days ```diff # diff --git a/patterns/2-structured/service-vs-library.md b/patterns/2-structured/service-vs-library.md # index 8779615..6e33c53 100644 # --- a/patterns/2-structured/service-vs-library.md # +++ b/patterns/2-structured/service-vs-library.md @@ -24,12 +24,12 @@ reluctant to join forces even if there is significant overlap in requirements. ## Context * Teams are working in a micro-services environment. -* They are organised in fully functional DevOps teams: Each team is responsible for their contributions end-to-end, including maintenance, on-call and customer support. +* They are organized in fully functional DevOps teams: Each team is responsible for their contributions end-to-end, including maintenance, on-call and customer support. * A team is tasked with providing a service to their downstream customers that is fairly similar to an existing service built by another team. ## Forces -* Organisational escalation paths may be different for each of the teams. +* Organizational escalation paths may be different for each of the teams. * Members of each team may be unwilling to answer on-call support for errors that do not affect their own downstream customers. * Severity levels for the same types of errors may be different across team boundaries due to different SLA definitions per team/customer relationship. * Teams may have different security or regulatory constraints governing their deployments. @@ -51,7 +51,7 @@ Deployment configurations can be included as separate projects in your InnerSour ## Resulting Context -Teams are willing to collaborate, benefitting from sharing the work of +Teams are willing to collaborate, benefiting from sharing the work of implementing the business logic. A service that originally was built specifically to work in one environment is @@ -61,10 +61,10 @@ Both teams get to know their respective escalation policy and deployment setup, potentially identifying improvements for their own setup. The likelihood that changes are needed and made in the shared source code -increases, leading to more frequent opportunities to refine, improve and optimise +increases, leading to more frequent opportunities to refine, improve and optimize the implementation. -Encourages incremental operational standardisation in release packaging, telemetry, health/readiness endpoints and so on as the teams realise they can more efficiently maintain this in the shared code if they agree on standard conventions. +Encourages incremental operational standardization in release packaging, telemetry, health/readiness endpoints and so on as the teams realize they can more efficiently maintain this in the shared code if they agree on standard conventions. ## See also @@ -73,7 +73,7 @@ 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 artefact. 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. +* 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. ## Status @@ -84,7 +84,7 @@ Related to this pattern is the [30 Day Warranty](30-day-warranty.md) pattern tha * Isabel Drost-Fromm * Rob Tuley -## Acknowledgements +## Acknowledgments Thank you Tobias Gesellchen for review internal to Europace AG. ```
(patterns/2-structured/maturity-model.md) - Original File(en): [patterns/2-structured/maturity-model.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/maturity-model.md) - Translated File(ja): [translation/ja/patterns/maturity-model.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/translation/ja/patterns/maturity-model.md) - [Diff on GitHub](https://github.com/yuhattor/innersourcecommons.org/compare/...1d27905fb09e29631795c8953fe8a141d7f40d34) - Days since overdue updates: 39 days ```diff # diff --git a/patterns/2-structured/maturity-model.md b/patterns/2-structured/maturity-model.md # index e9ce8c0..8e41062 100644 # --- a/patterns/2-structured/maturity-model.md # +++ b/patterns/2-structured/maturity-model.md @@ -96,7 +96,7 @@ When working in host teams mistakes will automatically be widely visible. In ord For silos to be reduced colleagues need to be comfortable sharing feedback openly. One easy way to support that is to use the same communication principles across hierarchies. -Ideally you will end up with proper communication channels that are known by anyone in the organization - with channels focussed on different goals (announcements, user support, development channels, infra discussions, etc.). Some of the best practices you will establish as your InnerSource projects mature: Adoption of netiquette guidelines, opening a proven set of standard channels (which are being archived, publicly accessible, searchable) for each new InnerSource project. +Ideally you will end up with proper communication channels that are known by anyone in the organization - with channels focused on different goals (announcements, user support, development channels, infra discussions, etc.). Some of the best practices you will establish as your InnerSource projects mature: Adoption of netiquette guidelines, opening a proven set of standard channels (which are being archived, publicly accessible, searchable) for each new InnerSource project. * CF-0: There are no processes nor established channels. Some members of the organization share materials via private channels or discussions. * CF-1: The organization is in the process of establishing internal guidelines and channels for encouraging diverse points of view about company/departmental decisions, so that anyone belonging to the organization can use them. Some members of the organization share decision-making materials informally using unofficial platforms. Leaders maintain at least one clear and direct channel for organization members to share opinions constructively on some matters relevant to their work. @@ -139,12 +139,12 @@ Having a baseline of shared values makes it easier to work across team boundarie * SP-0: No sharing culture nor written policies. * SP-1: Some members of the organization unite to define values and principles, but are not clearly supported when they do. -* SP-2: Members of the organization collectively document shared visions and agreements like mission statements and codes of conduct, make them easily accessible, and reference them often. Onboarding materials and orientation rituals provide adequate context for helping new members understand how the organization will benefit from their contributions. +* SP-2: Members of the organization collectively document shared visions and agreements like mission statements and codes of conduct, make them easily accessible, and reference them often. On-boarding materials and orientation rituals provide adequate context for helping new members understand how the organization will benefit from their contributions. * SP-3: Shared values and principles inform decision-making, conflict resolution, and assessment processes among members of the organization, who reference these values and principles consistently in both verbal and written formats. **Feel part of the Organization** -One of the possible reasons for introducing InnerSource into organisations can be increased engagement. This point tracks how engagement is changing while adopting InnerSource. +One of the possible reasons for introducing InnerSource into organizations can be increased engagement. This point tracks how engagement is changing while adopting InnerSource. * PA-0: Low engagement, no collaboration and people do not feel comfortable sharing with others. * PA-1: Members of the organization feel comfortable sharing their thoughts and opinions without fear of retribution, but only in familiar domains. People understand that the best ideas win, and leadership responsibilities accrue to people with histories of contribution and commitment. @@ -164,7 +164,7 @@ In order to drive adoption, extrinsic motivators can be used to increase cross t **Monitoring Policies** -InnerSource projects need a means for self assessment. Metrics can be one aspect to facilitate this assessment. Also, in organisations with a mature InnerSource adoption level we expect adoption of the method to be tracked based on clear, agreed upon metrics. +InnerSource projects need a means for self assessment. Metrics can be one aspect to facilitate this assessment. Also, in organizations with a mature InnerSource adoption level we expect adoption of the method to be tracked based on clear, agreed upon metrics. * MP-0: No existing monitoring policies at any level in the organization. * MP-1: Metrics are important for certain teams, and they start using them in an isolated way. @@ -175,7 +175,7 @@ InnerSource projects need a means for self assessment. Metrics can be one aspect Not only should feature development be owned by InnerSource teams - support and maintenance is also part of the teams core tasks. -* SM-0: Support given by the core dev or support team. A business contract guaranties the support. There is no knowledge about the product outside the team. +* SM-0: Support given by the core development or support team. A business contract guaranties the support. There is no knowledge about the product outside the team. * SM-1: There are rules and regulations to formalize the support on the product, given by a dedicated supporting team. * SM-2: Support for InnerSource contributions is formalized through InnerSource patterns like [30 Day Warranty](./30-day-warranty.md) or [Service vs. Library](./service-vs-library.md). * SM-3: There are rules and regulations to formalize the support on the product, given by a mature community. @@ -195,7 +195,7 @@ InnerSource comes with explicit roles. While in early stages some patterns may b * RO-0: There are no specific roles helping InnerSource adoption. Only common development roles are present: developer, analyst, tester, etc. * RO-1: Occasionally some individuals and teams contribute to other projects. These are technical contributions, where the user/contributor role is seen. For some teams, it can be identified at least one member being a technical reference, who explains the development process to other development team members. He/she could be a candidate for covering the trusted committer role. -* RO-2: An InnerSource Officer role is in charge of governance and support, including processes, etc. Identifies the education needs and ensures it is provided to the organization. Leads and mentors the organization in the engagement in IS projects. Is the first formal step in the way, defining the IS vision and roadmap. The organization has defined a trusted committer role, being a point of contact/reference not only for dev team members but also for external contributors. There is a standard process describing how to contribute to the community, contributor role is present. Data Scientist role is in charge of managing the traces of activity left by the InnerSource initiative, needed to measure the IS evolution. Trusted committer role will evolve to a more technical profile, and a community manager will be in charge of "energizing" the community, being his main responsibility to attract and retain new developers/users (contributors/community members). +* RO-2: An InnerSource Officer role is in charge of governance and support, including processes, etc. Identifies the education needs and ensures it is provided to the organization. Leads and mentors the organization in the engagement in IS projects. Is the first formal step in the way, defining the IS vision and roadmap. The organization has defined a trusted committer role, being a point of contact/reference not only for development team members but also for external contributors. There is a standard process describing how to contribute to the community, contributor role is present. Data Scientist role is in charge of managing the traces of activity left by the InnerSource initiative, needed to measure the IS evolution. Trusted committer role will evolve to a more technical profile, and a community manager will be in charge of "energizing" the community, being his main responsibility to attract and retain new developers/users (contributors/community members). * RO-3: Evangelists are moving inside organization, to let others know about the current work, what InnerSource does and how to do it, and help others to understand and become part of the initiative. Non technical contributors appear. ## Resulting Context @@ -221,7 +221,7 @@ long term. * Jorge * Nerea -## Acknowledgements +## Acknowledgments * Alexander Andrade (special thanks for the spelling fixes) ```
(patterns/2-structured/common-requirements.md) - Original File(en): [patterns/2-structured/common-requirements.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/common-requirements.md) - Translated File(ja): [translation/ja/patterns/common-requirements.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/translation/ja/patterns/common-requirements.md) - [Diff on GitHub](https://github.com/yuhattor/innersourcecommons.org/compare/...1d27905fb09e29631795c8953fe8a141d7f40d34) - Days since overdue updates: 39 days ```diff # diff --git a/patterns/2-structured/common-requirements.md b/patterns/2-structured/common-requirements.md # index c13899b..0381be2 100644 # --- a/patterns/2-structured/common-requirements.md # +++ b/patterns/2-structured/common-requirements.md @@ -56,7 +56,7 @@ A related challenge (and possible new pattern) is a circular story-writing exerc ## Known Instances -* Large telecom provider +* Large telecommunications provider ## Status @@ -66,7 +66,7 @@ A related challenge (and possible new pattern) is a circular story-writing exerc Robert Hanmer -## Acknowledgements +## Acknowledgments * Manrique Lopez * Daniel Izquierdo ```
(patterns/2-structured/start-as-experiment.md) - Original File(en): [patterns/2-structured/start-as-experiment.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/start-as-experiment.md) - Translated File(ja): [translation/ja/patterns/start-as-experiment.md](https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/translation/ja/patterns/start-as-experiment.md) - [Diff on GitHub](https://github.com/yuhattor/innersourcecommons.org/compare/...1d27905fb09e29631795c8953fe8a141d7f40d34) - Days since overdue updates: 39 days ```diff # diff --git a/patterns/2-structured/start-as-experiment.md b/patterns/2-structured/start-as-experiment.md # index 12844e4..53326df 100644 # --- a/patterns/2-structured/start-as-experiment.md # +++ b/patterns/2-structured/start-as-experiment.md @@ -63,7 +63,7 @@ Finally, starting as an experiment makes it much easier to sidestep regulations - Georg Grütter (Robert Bosch GmbH) -## Acknowledgements +## Acknowledgments - Jason Zink (Robert Bosch GmbH) - Diogo Fregonese (Robert Bosch GmbH) ```
yuhattor commented 1 year ago

New one is created: https://github.com/InnerSourceCommons/InnerSourcePatterns/issues/562