🇩🇪 Traslate host and core team references

Author: rmarting

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.