Minor fix to align Host and Core team references

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

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.

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
 

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.
 

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

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.
 

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

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
 

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)].

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é
 

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

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
 

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[Core Team] パターンで表されます。
 * https://patterns.innersourcecommons.org/p/trusted-committer[Trusted Committer] パターン

introduction/ja/05-principles-ja.asciidoc

@@ -41,7 +41,7 @@ InnerSourceのコントリビューションを彼らのプロジェクトに受
 * ホストチームの意思決事項
 
 可能であれば、上記については、チームのアイテムの内部定義から、プロジェクト固有の特殊ケースのシナリオに至るまで、明確かつ詳細に伝えるべきです。
-このコミュニケーションは、コアチーム以外の人も簡単に照会や理解ができる方法で行われるべきです。
+このコミュニケーションは、ホストチームのメンバーではない人々が容易に問い合わせ、理解できる方法で行われるべきです。
 
 === 優先的なメンターシップ
 

introduction/pt-br/03-how-works-pt-br.asciidoc

@@ -43,4 +43,5 @@ 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].
+* A equipe anfitriã geralmente é representada pelo padrão https://patterns.innersourcecommons.org/p/core-team[Core Team].
+* O padrão https://patterns.innersourcecommons.org/p/trusted-committer[Trusted Committer].

introduction/pt-br/05-principles-pt-br.asciidoc

@@ -41,7 +41,7 @@ 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 aqueles que não fazem parte da equipe anfitriã.
 
 === Mentoria Priorizada
 

introduction/pt-br/07-faq-pt-br.asciidoc

@@ -24,7 +24,7 @@ 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 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.
 
 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.
 

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] паттерн.