diff --git a/README.md b/README.md index 8567b440..681a2384 100644 --- a/README.md +++ b/README.md @@ -14,7 +14,7 @@ Currently, the four sections to the learning path are: 1. [Contributor](http://innersourcecommons.org/learn/learning-path/contributor/) 1. [Product Owner](http://innersourcecommons.org/learn/learning-path/product-owner/) 1. [Project Leader](https://innersourcecommons.org/learn/learning-path/project-leader/) - + There is also the [workbook](workbook/), a collection of questions and answers on based on the videos and articles for people to check their knowledge against after consuming the material. New sections and segments may be added at any time via the [contribution] process. @@ -25,7 +25,7 @@ The InnerSource Learning Path is produced via the [InnerSource Commons] communit We coordinate our work in the [#learning-path] _Slack_ channel. We track our tasks and discuss their status openly using our GitHub project [Kanban board]. -Typically, a card bundles tasks about one artifact (e.g. written articles accompanying one learning path section) or small milestones (e.g. finishing the post production of one section). +Typically, a card bundles tasks about one artifact (e.g. written articles accompanying one learning path section) or small milestones (e.g. finishing the post production of one section). You can infer whether a task is currently actively developed or under review based on the card's column in the [Kanban board]. ## Trusted Committers @@ -67,7 +67,7 @@ workbook/0n-section-name.asciidoc // Contains the part of the workbook matching After material is finished the scripts will be used to film videos. Each video should be about 5min in length. Each article should be about a page long. -The idea is that a person could receive a link to an article or video and watch or read it without having to set aside time in advance to do so. +The idea is that a person could receive a link to an article or video and watch or read it without having to set aside time in advance to do so. Videos, articles, and workbooks will be published at _learning.oreilly.com_ and also at _innersourcecommons.org_. ## How to Get Involved diff --git a/introduction/03-how-works.asciidoc b/introduction/03-how-works.asciidoc index 94e7f3de..1b7ebcd3 100644 --- a/introduction/03-how-works.asciidoc +++ b/introduction/03-how-works.asciidoc @@ -43,4 +43,5 @@ More engineering time stays focused on producing code that solves company proble === Additional Resources +* The host team can be represented by the https://patterns.innersourcecommons.org/p/core-team[Core Team] pattern. * The https://patterns.innersourcecommons.org/p/trusted-committer[Trusted Committer] pattern. diff --git a/introduction/05-principles.asciidoc b/introduction/05-principles.asciidoc index 8d6320f7..095e8558 100644 --- a/introduction/05-principles.asciidoc +++ b/introduction/05-principles.asciidoc @@ -41,7 +41,7 @@ This means that guest teams should be able to have an understanding of: * Decision making of the host team When possible, the above should be communicated clearly and in detail, from teams' internal definitions of items to special-case scenarios specific to the project. -This communication should be done in a manner that can be easily queried and understood to those that are not part of the core team. +This communication should be done in a manner that can be easily queried and understood to those that are not part of the host team. === Prioritized Mentorship diff --git a/introduction/07-faq.asciidoc b/introduction/07-faq.asciidoc index 845e83d0..5a108306 100644 --- a/introduction/07-faq.asciidoc +++ b/introduction/07-faq.asciidoc @@ -24,7 +24,7 @@ It depends on how far you're going. You'll probably be going a lot further than image::https://user-images.githubusercontent.com/9609562/151901209-52b3468b-dedd-4319-9ca3-38b6b2bcfaf5.png[If you want to go fast, go alone. If you want to go far, go together] === Will we just be reviewing PRs all day every day? -If so then your core team is understaffed. A healthy team is staffed so that there is time for assisting contributors and making core contributions yourself. +If so then your https://patterns.innersourcecommons.org/p/core-team[core team] is understaffed. A healthy team is staffed so that there is time for assisting contributors and making core contributions yourself. You can mitigate this by setting expectation, potentially via SLAs. If contributors expect PR reviews within an hour, maybe you will be stuck reviewing PRs all the time, but if you set an SLA of 1 day or 1 week, this won't be the case. diff --git a/introduction/de/03-how-works-de.asciidoc b/introduction/de/03-how-works-de.asciidoc index ee678443..0e371a69 100644 --- a/introduction/de/03-how-works-de.asciidoc +++ b/introduction/de/03-how-works-de.asciidoc @@ -28,13 +28,13 @@ Bei kleinen, einfacheren Projekten füllt oft eine einzelne Person _sowohl_ die Basierend auf diesen Rollen können wir nun den InnerSource-Prozesses grob skizzieren. * Das Gastteam, beziehungsweise konkret ein Mitglied des Gastteams, fragt eine Funktion vom Host-Team an. -* Der Product Owner stellt sicher, dass User Stories entsprechend dem Feature Request erstellt werden: Entweder vom Guest Team oder vom Host Team. +* Der Product Owner stellt sicher, dass User Stories entsprechend dem Feature Request erstellt werden: Entweder vom Guest Team oder vom Host Team. Diese Userstories beschreiben das gewünschte Feature so wie es sich das Gastteam vorstellt. Die User Stories enthalten auch all jene Details, auf die das Host Team vor Annahme der Änderung Wert legt. Beispiele für solche Details sind Besonderheiten in der Architektur, Coding Conventions, die Verwendung spezifischer Bibliotheken, Contracts hinsichtlich Daten usw. * Unterstützt vom Trusted Committer, sendet der Contributor den Pull-Request, um das angefragte Feature zu implementieren. -Zu beachten ist, dass bei diesen Schritten kein bestimmter Prozess für Koordination oder Priorisierung der Teams vorrausgesetzt wird. +Zu beachten ist, dass bei diesen Schritten kein bestimmter Prozess für Koordination oder Priorisierung der Teams vorrausgesetzt wird. InnerSource geht davon aus, dass Teams bereits über vorhandene Organisationsmethoden verfügen, und bietet einen Rahmen für die Zusammenarbeit, wenn ein Gastteam Code zu einem Project beitragen möchte. Dieser Weg der Zusammenarbeit birgt Vorteile für das Gastteam. Es erhält die Funktionalität, die es benötigt zum rechten Zeitpunkt und ohne die Verpflichtung, die langfristige Wartung der Lösung zu übernehmen. @@ -44,4 +44,5 @@ In letzter Konsequenz fließt mehr Zeit in Code, der die eigentlichen Unternehme === Zusätzliche Ressourcen +* Das Hostteam wird normalerweise durch das Muster https://patterns.innersourcecommons.org/p/core-team[Core Team] dargestellt. * Die Mustervorlage https://patterns.innersourcecommons.org/p/trusted-committer[Trusted Committer]. diff --git a/introduction/de/05-principles-de.asciidoc b/introduction/de/05-principles-de.asciidoc index 70dc90d8..1628be05 100644 --- a/introduction/de/05-principles-de.asciidoc +++ b/introduction/de/05-principles-de.asciidoc @@ -41,7 +41,7 @@ Dies bedeutet, dass Gastteams in der Lage sein sollten, folgendes zu verstehen: * Entscheidungsfindungsprozess des Hostteams Wenn möglich, sollte das obige klar und detailliert kommuniziert werden, von den internen Definitionen der verbleibenden Arbeit bis hin zu projektspezifischen Spezialszenarien. -Diese Kommunikation sollte auf eine Weise erfolgen, sodass die Information für diejenigen, die nicht Teil des Kernteams sind, leicht gefunden and nachvollzogen werden kann. +Diese Kommunikation sollte so erfolgen, dass sie für Personen, die nicht zum Gastgeberteam gehören, leicht abgefragt und verstanden werden kann. === Priorisierte Betreuung @@ -54,7 +54,7 @@ Es ist wichtig, dass Mentoring für potentielle Contributoren vom Hostteam prior Das Hostteam sollte sich bemühen, sich ausreichend Zeit für die Betreuung der Contributor des Gastteams zu nehmen - ganz speziell zu dem Zeitpunkt zu dem der Contributor es benötigt - und nicht, wenn es für das Hostteam bequem ist. Manchmal kann es für Entwickler im Hostteam ein Kulturwandel sein, Zeit zu investieren um anderen beim Schreiben von Quellecode zu helfen, anstatt selbst zu entwickeln. Diese Art des Mentorings ist sowohl für den einzelnen Mitarbeiter des Gastteams als auch für den Gastgeber wertvoll, und es lohnt sich den Aufwand zu betreiben. -Es erweist sich auf lange Sicht als vorteilhaft für beide Seiten. +Es erweist sich auf lange Sicht als vorteilhaft für beide Seiten. Durch die Verbesserung des Quellcodes bildet oder verbessert der Mitarbeiter die Beziehungen innerhalb einer Organisation, die sonst möglicherweise nicht existiert hätten. Open Source erkennt diesen Punkt sofort und betrachtet es als eine Ehre, den Status eines Trusted Committers für ein Projekt zu erreichen. diff --git a/introduction/es/03-how-works-es.asciidoc b/introduction/es/03-how-works-es.asciidoc index 40c74618..3c87be2e 100644 --- a/introduction/es/03-how-works-es.asciidoc +++ b/introduction/es/03-how-works-es.asciidoc @@ -38,4 +38,5 @@ Finalmente, se invierte más tiempo de ingeniería en producir código que resue === Recursos adicionales +* El equipo anfitrión generalmente está representado por el patrón https://patterns.innersourcecommons.org/p/core-team[Core Team]. * El patrón del https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/patterns/2-structured/trusted-committer.md[Trusted Committer]. diff --git a/introduction/es/05-principles-es.asciidoc b/introduction/es/05-principles-es.asciidoc index 8905cc3a..15d78096 100644 --- a/introduction/es/05-principles-es.asciidoc +++ b/introduction/es/05-principles-es.asciidoc @@ -42,8 +42,7 @@ Esto significa que el equipo contribuidor debe entender: * Proceso de decisión del equipo anfitrión Cuando sea posible, todo lo anterior debe ser comunicado de forma clara y detallada, desde las definiciones internas a escenario con casos especiales específicos del proyecto. -Esta comunicación debe ser hecha de una forma que pueda ser fácilmente transmitida y comprendida por aquellos que no son parte del núcleo central del equipo. - +Esta comunicación debe realizarse de manera que pueda ser consultada y entendida fácilmente por aquellos que no forman parte del equipo anfitrión. === Mentorización priorizada diff --git a/introduction/fr/03-how-works-fr.asciidoc b/introduction/fr/03-how-works-fr.asciidoc index 185964f3..c18012f2 100644 --- a/introduction/fr/03-how-works-fr.asciidoc +++ b/introduction/fr/03-how-works-fr.asciidoc @@ -43,4 +43,5 @@ Plus de temps d'ingénierie est consacré à la production de code qui résout l === Ressources supplémentaires +* L'équipe hôte est généralement représentée selon le modèle d'une https://patterns.innersourcecommons.org/p/core-team[Core Team] * Le modèle du https://patterns.innersourcecommons.org/p/trusted-committer[Trusted Committer (en)]. diff --git a/introduction/fr/05-principles-fr.asciidoc b/introduction/fr/05-principles-fr.asciidoc index 55587df8..cd12e8db 100644 --- a/introduction/fr/05-principles-fr.asciidoc +++ b/introduction/fr/05-principles-fr.asciidoc @@ -41,7 +41,7 @@ Cela signifie que les équipes invitées doivent être en mesure de comprendre : * La prise de décision de l'équipe hôte Dans la mesure du possible, les éléments ci-dessus doivent être communiqués clairement et en détail, depuis les définitions internes des équipes jusqu'aux scénarios de cas particuliers propres au projet. -Cette communication doit être faite d'une manière qui peut être facilement interrogée et comprise par ceux qui ne font pas partie de l'équipe principale. +Cette communication doit être effectuée de manière à ce qu'elle puisse être facilement consultée et comprise par ceux qui ne font pas partie de l'équipe hôte. === Mentorat hiérarchisé diff --git a/introduction/it/03-how-works-it.asciidoc b/introduction/it/03-how-works-it.asciidoc index 0bb60eb8..fa7be439 100644 --- a/introduction/it/03-how-works-it.asciidoc +++ b/introduction/it/03-how-works-it.asciidoc @@ -43,4 +43,5 @@ Più tempo di progettazione rimane focalizzato sulla produzione del codice che r === Additional Resources +* Il team ospitante è solitamente rappresentato dal modello https://patterns.innersourcecommons.org/p/core-team[Core Team]. * Il pattern del https://patterns.innersourcecommons.org/p/trusted-committer[Trusted Committer]. diff --git a/introduction/it/05-principles-it.asciidoc b/introduction/it/05-principles-it.asciidoc index 4a3cc728..0951965f 100644 --- a/introduction/it/05-principles-it.asciidoc +++ b/introduction/it/05-principles-it.asciidoc @@ -15,11 +15,11 @@ Andiamo a dare un'occhiata ad ognuno di questi principi con maggiore dettaglio. === Apertura La configurazione di un progetto open abilita una contribuzione senza attriti. -I progetti dovrebbero essere ispezionabili e ben documentati attraverso i file il README.md e CONTRIBUTING.md. +I progetti dovrebbero essere ispezionabili e ben documentati attraverso i file il README.md e CONTRIBUTING.md. Chiunque all'interno dell'organizzazione dovrebbe poter trovare un determinato progetto e proseguire senza una quantità eccessiva di guida diretta da parte dei membri dell'host team. -Le informazioni per contattare l'host team dovrebbero essere diffuse su tutti i canali che hanno senso per il progetto. +Le informazioni per contattare l'host team dovrebbero essere diffuse su tutti i canali che hanno senso per il progetto. Le intenzioni dell'host team di accettare contribuzioni InnerSource al loro progetto dovrebbero essere condivise attraverso i canali aziendali opportuni per sensibilizzare. -In particolare in contesti più piccoli potresti voler impostare un "broadcast" regolare riguardo il lavoro InnerSource che il tuo team sta facendo. +In particolare in contesti più piccoli potresti voler impostare un "broadcast" regolare riguardo il lavoro InnerSource che il tuo team sta facendo. In contesti più larghi, comunque, tale broadcast potrebbe creare molto rumore, e potrebbe essere più appropriato essere sicuri che il progetto sia accessibile attraverso uno strumento di facile da usare. Ricorda, l'obiettivo è la consapevolezza all'utilizzo di canali appropriati che funzionano nella TUA azienda. @@ -39,7 +39,7 @@ Questo significa che il guest team dovrebbe essere in grado di comprendere: * Il processo decizionale dell'host team Quanto possibile, quanto descritto sopra dovrebbe essere comunicato chiaramente ed in dettaglio, dalle definizioni interne degli elementi dei team a specifici scenari di casi speciali del progetto. -Questa comunicazione dovrebbe essere fatta in maniera tale che possa essere facilmente ricercata e compresa a tutti quelli che non fanno parte del core team. +Questa comunicazione dovrebbe essere effettuata in modo da poter essere facilmente interrogata e compresa da coloro che non fanno parte del team ospitante. === Tutoraggio prioritizzato diff --git a/introduction/ja/03-how-works-ja.asciidoc b/introduction/ja/03-how-works-ja.asciidoc index 3f3fce3b..eafa426f 100644 --- a/introduction/ja/03-how-works-ja.asciidoc +++ b/introduction/ja/03-how-works-ja.asciidoc @@ -44,4 +44,5 @@ https://innersourcecommons.org/ja/learn/learning-path/trusted-committer[_Trusted === その他のリソース +* ホストチームは通常、https://patterns.innersourcecommons.org/p/core-team[_コアチーム_] パターンで表されます。 * https://patterns.innersourcecommons.org/p/trusted-committer[Trusted Committer] パターン diff --git a/introduction/ja/05-principles-ja.asciidoc b/introduction/ja/05-principles-ja.asciidoc index 01fda969..d8b72602 100644 --- a/introduction/ja/05-principles-ja.asciidoc +++ b/introduction/ja/05-principles-ja.asciidoc @@ -41,7 +41,7 @@ InnerSourceのコントリビューションを彼らのプロジェクトに受 * ホストチームの意思決事項 可能であれば、上記については、チームのアイテムの内部定義から、プロジェクト固有の特殊ケースのシナリオに至るまで、明確かつ詳細に伝えるべきです。 -このコミュニケーションは、コアチーム以外の人も簡単に照会や理解ができる方法で行われるべきです。 +このコミュニケーションは、ホストチーム以外の人も簡単に照会や理解ができる方法で行われるべきです。 === 優先的なメンターシップ diff --git a/introduction/pt-br/03-how-works-pt-br.asciidoc b/introduction/pt-br/03-how-works-pt-br.asciidoc index 3a5ad792..e03badcf 100644 --- a/introduction/pt-br/03-how-works-pt-br.asciidoc +++ b/introduction/pt-br/03-how-works-pt-br.asciidoc @@ -43,4 +43,6 @@ Mais tempo de engenharia permanece focado na produção de código que resolve o === Recursos Adicionais -* O padrão https://patterns.innersourcecommons.org/p/trusted-committer[Trusted Committer]. \ No newline at end of file +* A equipe anfitriã pode ser representada pelo padrão https://patterns.innersourcecommons.org/pt-br/p/core-team[Equipe Central]. + +* O padrão https://patterns.innersourcecommons.org/p/trusted-committer[Trusted Committer]. diff --git a/introduction/pt-br/05-principles-pt-br.asciidoc b/introduction/pt-br/05-principles-pt-br.asciidoc index f15d2b02..12e0b29c 100644 --- a/introduction/pt-br/05-principles-pt-br.asciidoc +++ b/introduction/pt-br/05-principles-pt-br.asciidoc @@ -41,7 +41,8 @@ Isso significa que as equipes convidadas devem entender: * Tomada de decisão da equipe anfitriã Quando possível, o acima deve ser comunicado de forma clara e detalhada, desde as definições internas dos itens das equipes até cenários de casos especiais específicos do projeto. -Essa comunicação deve ser feita de forma que possa ser facilmente consultada e compreendida por quem não faz parte da equipe principal. +Esta comunicação deve ser feita de forma que possa ser facilmente consultada e compreendida por quem não faz parte da equipe anfitriã. + === Mentoria Priorizada diff --git a/introduction/pt-br/07-faq-pt-br.asciidoc b/introduction/pt-br/07-faq-pt-br.asciidoc index c8568a8e..7008b1e1 100644 --- a/introduction/pt-br/07-faq-pt-br.asciidoc +++ b/introduction/pt-br/07-faq-pt-br.asciidoc @@ -24,7 +24,8 @@ Depende de quão longe você está indo. Você provavelmente irá muito mais lon image::https://user-images.githubusercontent.com/9609562/151901209-52b3468b-dedd-4319-9ca3-38b6b2bcfaf5.png[Se você quer ir rápido, vá sozinho. Se quer ir longe, vá acompanhado] === Estaremos apenas revisando PRs o dia todo, todos os dias? -Nesse caso, sua equipe principal está com falta de pessoal. Uma equipe saudável é composta de forma que haja tempo para ajudar os colaboradores e fazer contribuições essenciais. +Nesse caso, sua https://patterns.innersourcecommons.org/p/core-team[equipe central] está com falta de pessoal. Uma equipe saudável é composta de forma que haja tempo para ajudar os colaboradores e fazer contribuições essenciais. + Você pode mitigar isso definindo a expectativa, possivelmente por meio de SLAs. Se os contribuidores esperam revisões de PR em uma hora, talvez você fique parado revisando PRs o tempo todo, mas se você definir um SLA de 1 dia ou 1 semana, esse não será o caso. diff --git a/introduction/ru/03-how-works-ru.asciidoc b/introduction/ru/03-how-works-ru.asciidoc index c2f8f029..2fd0e1a6 100644 --- a/introduction/ru/03-how-works-ru.asciidoc +++ b/introduction/ru/03-how-works-ru.asciidoc @@ -18,7 +18,7 @@ Эта аналогия с посещением дома метафорически показывает, как команды должны взаимодействовать между собой, когда одна команда отправляет гостевой код хозяевам репозитория. Теперь рассмотрим механику InnerSource. -Для начала представим ключевых лиц процесса. +Для начала представим ключевых лиц процесса. * https://innersourcecommons.org/learn/learning-path/product-owner[_Product Owner_] или Владелец Продукта. Определяет функционал, который команда хозяев готова принять от гостевых команд. * https://innersourcecommons.org/learn/learning-path/contributor[_Contributor_] или Контрибьютор. Член гостевой команды, который отправляет код на ревью команде хозяев. @@ -30,7 +30,7 @@ * Владелец продукта убеждается в том, что задачи по созданию функционала созданы в трекере гостевой командой или хозяевами. Описание требуемого функционала соответствует тому, что запросила гостевая команда, а также содержит информацию от команды хозяев по тому, как выглядит решение, которое будет принято в общую кодовую базу. Например, описаны возможные архитектурные ограничения, кодовые конвенции, использованые зависимости и контракты и тому подобное. -* С поддержкой Trusted Committer, Контрибьютор оформляет код в виде Pull Request-а, где реализует необходимый функционал. +* С поддержкой Trusted Committer, Контрибьютор оформляет код в виде Pull Request-а, где реализует необходимый функционал. Обратите внимание, что шаги не описывают конкретную организацию рабочего процесса или способ приоритизации запросов. InnerSource предполагает, что в команде существуют устоявшиеся принципы работы и представляет решение, как совместить эти принципы с поступающими гостевыми контрибьюциями. @@ -42,4 +42,5 @@ InnerSource предполагает, что в команде существу === Дополнительные ресурсы +* Команда-хозяин обычно представлена ​​шаблоном https://patterns.innersourcecommons.org/p/core-team[Core Team]. * https://patterns.innersourcecommons.org/p/trusted-committer[Trusted Committer] паттерн. diff --git a/introduction/ru/05-principles-ru.asciidoc b/introduction/ru/05-principles-ru.asciidoc index 289031bd..2c23fa0a 100644 --- a/introduction/ru/05-principles-ru.asciidoc +++ b/introduction/ru/05-principles-ru.asciidoc @@ -41,12 +41,12 @@ * Принимаемых решений командой-владельцем По возможности, вся информация должна в подробностях распространяться по компании, начиная с объяснения использованных терминов и заканчивая особыми сценариями использования, специфичными для проекта. -Коммуникация должна осуществляться таким образом, чтобы её можно было легко прочесть и понять тем, кто не является частью основной команды. +Эта коммуникация должна осуществляться таким образом, чтобы она могла быть легко запрошена и понята теми, кто не входит в состав принимающей команды. === Приоритетное менторство _Менторство_ с помощью https://innersourcecommons.org/learn/learning-path/trusted-committer[_Trusted Commiters_] гостевых контрибьюторов – один из основных аспектов InnerSource. -Важность работы с https://innersourcecommons.org/learn/learning-path/contributor[_Контрибьюторами_] из гостевых команд повышается и они получают достаточное количество информации о проекте и репозитории для его успешного изменения. +Важность работы с https://innersourcecommons.org/learn/learning-path/contributor[_Контрибьюторами_] из гостевых команд повышается и они получают достаточное количество информации о проекте и репозитории для его успешного изменения. В процессе этого они начинают лучше понимать способ работы хост-команды как со стороны обычного потребителя, так и представителя проекта. С течением времени и опытом, коммитеры могут получить бошее продвинутую роль в проекте — роль Trusted Committer. diff --git a/introduction/zh/03-how-works-zh.asciidoc b/introduction/zh/03-how-works-zh.asciidoc index ffdc26fb..3c9eff63 100644 --- a/introduction/zh/03-how-works-zh.asciidoc +++ b/introduction/zh/03-how-works-zh.asciidoc @@ -17,4 +17,6 @@ 这个选项对调用团队很有效，因为他们在需要的时候获得了所需的功能，而无需承担解决方案的长期维护负担。这对于维护团队来说是有效的，因为他们能够更好地拓展和服务他们的消费者。它适用于整个公司，因为共享问题的解决方案最终都在共享的、集中维护的位置，任何人都可以使用它们。更多的工程时间集中于生成解决公司问题的代码，而不是花费在特性协商和问题升级过程中。 === 额外的资源 - * https://patterns.innersourcecommons.org/p/trusted-committer[Trusted Committer] 的模式。 + +* 主办团队通常以 https://patterns.innersourcecommons.org/p/core-team[主导团队] 模式表示。 +* https://patterns.innersourcecommons.org/p/trusted-committer[Trusted Committer] 的模式。 diff --git a/introduction/zh/05-principles-zh.asciidoc b/introduction/zh/05-principles-zh.asciidoc index c97d9af8..5c378b33 100644 --- a/introduction/zh/05-principles-zh.asciidoc +++ b/introduction/zh/05-principles-zh.asciidoc @@ -31,7 +31,7 @@ * 主导团队的决策 在可能的情况下，从团队对项目的内部定义到特定于项目的特殊情况场景，都应该清晰而详细地传达上述内容。 -这种沟通应该以一种容易被非核心团队成员查询和理解的方式进行。 +此沟通应以一种易于查询和理解的方式进行，以便那些不属于主导团队的人员能够理解。 === 优先辅导 通过 https://innersourcecommons.org/zh/learn/learning-path/trusted-committer[_Trusted Committers_] ，从维护团队到调用团队的 _辅导（Mentorship）_ 是InnerSource的一个关键方面。