diff --git a/introduction/02-problems-solved.asciidoc b/introduction/02-problems-solved.asciidoc index 76417457..5101e67d 100644 --- a/introduction/02-problems-solved.asciidoc +++ b/introduction/02-problems-solved.asciidoc @@ -9,12 +9,12 @@ An example could be a user experience that depends on an API service to retrieve This situation is common in a large enterprise where a single team producing software may have dozens or hundreds of consumers. When consuming teams need many features, producing teams normally have some sort of requirements and prioritization process to decide which features they will work on. -For critical feature requests that are not prioritized for immediate work, the consuming team may commonly choose one of 3 options, each of which come with their own drawbacks. +For critical feature requests that are not prioritized for immediate work, the consuming team may commonly choose one of 3 options, each of which comes with their own drawbacks. . *Wait it out*. The consuming team may do nothing and limp along without the requested functionality. This option requires the least amount of work on their side. Depending on the benefit of the feature request, waiting might be just fine. - However, it may come with real amounts of pain, especially if the requested functionalty is never delivered. + However, it may come with real amounts of pain, especially if the requested functionality is never delivered. . *Workaround*. A consuming team that doesn't want to wait may do extra work somewhere else to compensate for the absence of their requested feature. This extra work may come as change in the consuming project. Alternatively, they may create a new project that meets their needs and replaces their use of all or part of the producing team's system (code/project duplication). @@ -26,10 +26,10 @@ For critical feature requests that are not prioritized for immediate work, the c This option sounds attractive for the consuming team because they get the requested feature without doing the work to implement or maintain it. It is still a drag on the team, though, because it necessarily diverts some of their attention and work to the non-engineering task of escalation. Additionally, this option does not scale as there are only so many times that a consumer can escalate feature requests before damaging their credibility. -Escalation is similarly disruptive (even more so) for the producing team, who are taken out of their normal workflow and prioritization methods to deal with the escalated feature request. +Escalation is similarly disruptive (even more so) for the members of the producing team, who are taken out of their normal workflow and prioritization methods to deal with the escalated feature request. This discussion sets the stage for InnerSource. -InnerSource applies to the same type of situation where a consuming team is unable to get what needs via feature request. +InnerSource applies to the same type of situation where a consuming team is unable to get what it needs via feature request. InnerSource provides a way for the teams to gain the benefits of _wait it out_, _workaround_, and _escalate_ without the associated drawbacks. InnerSource also provides a general improvement to engineering culture as engineers have the chance to work with a wider variety of new technologies and people. diff --git a/introduction/05-principles.asciidoc b/introduction/05-principles.asciidoc index eee375f2..e53643cf 100644 --- a/introduction/05-principles.asciidoc +++ b/introduction/05-principles.asciidoc @@ -22,7 +22,7 @@ Anyone within an organization should be able to find a desired project and ramp Host team contact information should be prevalent with as many channels as makes sense for the project. Host team intentions to accept InnerSource contributions to their project should be shared through relevant organization channels to raise awareness. Particularly in smaller settings you may want to establish a regular "broadcast" on the InnerSource work your team is doing. -In larger settings, however, such broadcast may create a lot of noise, and it may be more approproate to make sure the project is discoverable in a easy-to-use tool. +In larger settings, however, such broadcast may create a lot of noise, and it may be more appropriate to make sure the project is discoverable in a easy-to-use tool. Remember, the goal is awareness use the appropriate channels that work in YOUR company. By no means is the above an exhaustive list. diff --git a/introduction/de/01-introduction.asciidoc b/introduction/de/01-introduction.asciidoc new file mode 100644 index 00000000..8c9fda88 --- /dev/null +++ b/introduction/de/01-introduction.asciidoc @@ -0,0 +1,12 @@ +== Einführung + +Diese Learningpath Serie bietet eine Einführung in InnerSource. +InnerSource ist die Anwendung von Open-Source-Praktiken und -Prinzipien auf die Softwareentwicklung im Unternehmen. +Die InnerSource-Software bleibt dabei Eigentum des Unternehmens. Jeder Mitarbeiter kann sie nutzen und Verbesserungen oder Erweiterungen beitragen. +Diese Strategie ermöglicht eine breite und effektive Zusammenarbeit und führt zu Software, die sich schnell auf die sich ändernden Anforderungen der verschiedenen internen +Stakeholder einstellen und anpassen lässt. + +Diese Serie zeigt auf, wie Du Situationen erkennst, in denen die Anwendung von InnerSource Praktiken vorteilhaft sind. +Wir werden beispielhaft skizzieren, wie InnerSource in diesen Situationen helfen kann. +Du wirst mit Begriffen vertraut gemacht, die im Zusammenhang mit InnerSource verwendet werden. +Wir werden außerdem die wichtigsten InnerSource-Prinzipien aufzählen, und Vorteile nennen, die sich bei einer effektiven Anwendung ergeben. diff --git a/introduction/de/02-problems-solved.asciidoc b/introduction/de/02-problems-solved.asciidoc new file mode 100644 index 00000000..9d22568b --- /dev/null +++ b/introduction/de/02-problems-solved.asciidoc @@ -0,0 +1,40 @@ +== Welche Probleme löst InnerSource? +InnerSource fördert und belohnt die Zusammenarbeit und die Wiederverwendung von Code. +Jeder Mitarbeiter, unabhängig von seiner Position in der Organisationsstruktur eines Unternehmens, kann teilnehmen. +Dieser Ansatz unterscheidet sich von dem in traditionellen Organisationen, in denen Ideen und Produkte in der Regel innerhalb der Grenzen der internen Unternehmenshierarchie und ihrer Silos gefangen bleiben. +Lass uns eine Situation untersuchen, die ein Beispiel für diesen neuen Ansatz gibt. + +Stell Dir vor, zwei Teams desselben Unternehmens liefern separate Softwareteile, wobei die Software eines Teams abhängig von der Software des anderen Teams ist. +Ein Beispiel könnte eine Benutzerführung sein, die von einem API-Dienst abhängt, um Daten abzurufen und anzuzeigen. +Diese Situation ist in einem großen Unternehmen üblich, da ein einzelnes Team das Software produziert, Dutzende oder Hunderte von Verbrauchern haben kann. + +Wenn konsumierende Teams viele Funktionen benötigen, haben produzierende Teams normalerweise bestimmte Anforderungen und Priorisierungsprozesse, um zu entscheiden, an welchen Funktionen sie arbeiten. +Bei kritischen Funktionsanforderungen, die für die sofortige Arbeit nicht priorisiert sind, kann das konsumierende Team üblicherweise eine von drei Optionen auswählen, wobei jede ihre eigenen Nachteile hat. + +. *Abwarten.* Das konsumierende Team kann nichts tun und ohne die angeforderte Funktionalität nur bedingt Fortschritte erzielen. +Diese Option erfordert den geringsten Arbeitsaufwand auf der Seite der Konsumenten. +Abhängig vom Nutzen der Funktionsanforderung kann das Warten in Ordnung sein. +Es kann jedoch zu erheblichen Schwierigkeiten kommen, insbesondere wenn die angeforderte Funktion nie geliefert wird. + +. *Problemumgehung.* Ein konsumierendes Team das nicht warten möchte, kann an einer anderen Stelle zusätzliche Arbeit leisten, um das Fehlen der angeforderten Funktion zu kompensieren. +Diese zusätzliche Arbeit schlägt sich typischerweise als Änderung im konsumierenden Projekt nieder. +Alternativ könnte man ein neues Projekt erstellen, das den Anforderungen entspricht und die Verwendung des gesamten oder eines Teils des Codes des Produktionsteams ersetzt (Code- / Projektduplizierung). +Diese Strategie ermöglicht es dem konsumierenden Team, die angeforderte Funktion aus eigener Kraft zu erhalten. Dies hat jedoch mehrere Nachteile. +.. Alle Veränderungen die vom Verbraucherteam ausgeführt werden, stehen anderen Verbrauchern mit derselben Funktionsanforderung nicht zur Verfügung. +.. Das konsumierende Team hat sich unbeabsichtigt darauf eingelassen, die langfristige Pflege des neu geschriebenen Codes zu übernehmen, obwohl die Thematik ausserhalb der Kernteamkompetenz des Teams liegt. +.. Das Unternehmen dupliziert im Laufe der Zeit Projekte und Code im selben Problembereich. + +*Eskalation.* Das konsumierende Team nimmt möglicherweise kein "Nein" als Antwort hin und wendet sich stattdessen an jemanden in der Managementhierarchie der Produzenten, um das produzierende Team zu beeinflussen (oder zu zwingen), die gewünschte Arbeit zu erledigen. +Diese Option klingt für das konsumierende Team attraktiv, da es die angeforderte Funktion erhält, ohne die Arbeit zur Implementierung oder Wartung investieren zu müssen. +Es ist jedoch immernoch eine Belastung für das Team, da es notwendigerweise einen Teil ihrer Aufmerksamkeit und Arbeit auf die nicht-technische Aufgabe der Eskalation lenkt. +Darüber hinaus lässt sich diese Option nicht skalieren, da ein Verbraucher nur begrenzt Feature-Anfragen eskalieren kann, bevor er seine Glaubwürdigkeit verliert. +Die Eskalation ist für das Produktionsteam ebenfalls störend, da es aus seinen normalen Workflow- und Priorisierungsmethoden herausgezogen wird, um die eskalierte Funktionsanforderung zu bearbeiten. + +Einen Ausweg aus dieser Situation bietet InnerSource. +Es ist eine gute Lösung für die oben beschriebene Situation, in der ein konsumierendes Team nicht in der Lage ist, die Funktionsanforderungen selbst zu erfüllen. +InnerSource bietet den Teams die Vorteile der oben beschriebenen Strategien des _Abwartens_, der _Problemumgehung_ und der _Eskalation_, ohne die damit verbundenen Nachteile. + +InnerSource bietet auch eine allgemeine Verbesserung der Arbeitskultur, da Mitarbeiter die Möglichkeit haben, mit einer größeren Vielfalt neuer Technologien in Kontakt zu kommen und mit einem größeren Kreis Kollegen zusammen zu arbeiten. +Entwickler beraten einander und lernen voneinander wenn sie Ideen und Lösungen zwischen verschiedenen Unternehmenssilos austauschen. +Teams können interne Lösungen für Standardprobleme wiederverwenden. + Auf diese Weise können sie sich auf für das Unternehmen gewinnbringendere Aufgaben konzentrieren. diff --git a/introduction/de/03-how-works.asciidoc b/introduction/de/03-how-works.asciidoc new file mode 100644 index 00000000..1723db19 --- /dev/null +++ b/introduction/de/03-how-works.asciidoc @@ -0,0 +1,47 @@ +== Wie funktioniert InnerSource? + +Nehmen wir folgendes Szenario an: Team A verwendet Software, die von Team B produziert wird. +Team A übermittelt Anforderungen an Team B, aber Team B ist stark ausgelastet und kann diese nicht rechtzeitig implementieren. +InnerSource ermögicht Team A, anstatt einer Anforderung, einen PullRequest mit der eigenen Implementierung an Team B zu schicken. +Das heißt, Team A implementiert die Funktion direkt in der Software von Team B und sendet einen PullRequest mit den Codeänderungen. +Team B überprüft dann den übermittelten Code, überarbeitet ihn gegebenenfalls in enger Partnerschaft mit Team A und integriert die Änderungen sobald sie den Anforderungen entsprechen. + +In diesem Beispiel nennen wir Team A das _Guest_-Team und Team B das _Host_-Team. +Die Begriffe _Guest_ und _Host_ legen eine Situation nahe, die dem Empfang eines Besuchers im Haus entspricht. +In dieser Situation wollen die meisten Menschen ein guter Gastgeber sein. +Haben sich Gäste angekündigt, sorgen Gastgeber für eine einladende Atmosphäre. +Die Besucher werden an der Tür begrüßt und herein gebeten. +Sie können die Einrichtungen und Räume nutzen, die sich in den öffentlichen Bereichen des Zuhauses befinden. +Es kann ein paar Regeln geben, um deren Befolgung Gäste gebeten werden. +Auf der anderen Seite wollen Gäste meist respektvoll und sorgsam mit dem Zuhause des Gastgeber umgehen. +Sie sind vorsichtig mit den Gegenständen im Haus und folgen den Regeln für die Dauer ihres Aufenthalts. +Werden die Grenzen von Etikette und höflichen Umgangsformen überschritten, sollten diese Gäste sich nicht wundern, wenn sie keine erneute Einladung erhalten. +Diese Konzepte rund um einen Besuch sind eine Metapher für Einstellung und Verhalten von Teams in den Rollen Gastgeber (Host) und Gast (Contributor). + +Werfen wir einen genaueren Blick darauf, wie der InnerSource-Prozess funktioniert. +Bevor wir in das Thema tiefer einsteigen, schauen wir uns einige wichtige Rollen in den Gast- und Gastgeberteams an. +Zunächst legt der https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/product-owner/01-opening-article.asciidoc[_Product Owner_] fest, welche Funktionen das Hostteam als Beitrag zu akzeptieren bereit ist. +Der https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_Contributor_] ist die Person im Gastteam, die den Codebeitrag einreicht, welcher dann durch das Hostteam geprüft und ggf. akzeptiert wird. +Der https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/trusted-committer/01-introduction.asciidoc[_Trusted Committer_] steht dem Hostteam als zusätzliche Unterstützung für Review- und Mentoringaufgaben bei, um letztendlich den Contributor mit seinem Pullrequest zu unterstützen. +Bei kleinen, einfacheren Projekten füllt oft eine einzelne Person _sowohl_ die Rolle des Product Owners als auch die des Trusted Committer aus. + +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. +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. +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. +Dieser Weg funktioniert für das Gastgeberteam, weil es in der Lage ist, besser zu skalieren und seine Kunden besser zu bedienen. +Dies funktioniert für das Unternehmen in der Gesamtheit, weil Lösungen für gemeinsame Probleme an einem gemeinsamen, zentral gepflegten Ort jedem zur Verfügung gestellt werden. +In letzter Konsequenz fließt mehr Zeit in Code, der die eigentlichen Unternehmensprobleme löst, anstatt in Verhandlungen über Features oder in Eskalationsprozesse. + +=== Zusätzliche Ressourcen + +* Die Mustervorlage https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/project-roles/trusted-committer.asciidoc[Trusted Committer]. diff --git a/introduction/de/04-benefits.asciidoc b/introduction/de/04-benefits.asciidoc new file mode 100644 index 00000000..94237037 --- /dev/null +++ b/introduction/de/04-benefits.asciidoc @@ -0,0 +1,31 @@ +== Worin liegen die Vorteile von InnerSource? + +Die Zusammenarbeit mit Hilfe von InnerSource bietet viele Vorteile. +InnerSource bietet einem Unternehmen eine skalierbare Strategie für *Gastteams, um Features zu dem Zeitpunkt zu erhalten, zu dem sie diese benötigen*, ohne langfristig auch die Wartung übernehmen zu müssen. +Das Unternehmen als Ganzes gewinnt, da die Gastteams die so gewonnene Zeit anderen Aufgaben widmen können. + +Während dieses Ergebnis ein glänzender Vorteil von InnerSource ist, gibt es für Hosts, die regelmäßig InnerSource-Beiträge erhalten, ebenfalls viele Vorteile. +Denken Sie daran, dass der Product Owner im Hostteam im Rahmen des InnerSource-Prozesses von Anfang an entscheidet, ob die bereitgestellten Funktionen gut und wünschenswert sind für das Project. +Somit kann das Hostteam durch die Anwendung von InnerSource-Prinzipien *Hilfe bei der Erstellung eines besseren Produkts* für seine Verbraucher erhalten! + +*InnerSource bietet dem Hostteam eine skalierbare Strategie* zur Erfüllung unterschiedlicher Funktionsanforderungen die von seinen verschiedenen Nutzern/Kunden vorgebracht werden. +Angesichts der festen Arbeitskapazität der Vollzeitmitglieder des Hostteams ist es wahrscheinlich, dass die Roadmaps der Nutzer zuweilen sehr (oder sogar unangemessen) viel zusätzliche Arbeit für das Hostteam bedeutet. +Ohne InnerSource führt diese Situation leicht zu einem gestressten, überlasteten Team, das sich mit vielen (fremden) Featureanfragen befasst, die ggf. über seine Führungskräfte eskaliert worden sind. + +Wenn das Hostteam jedoch nach InnerSource Prinzipien arbeitet, werden die, zum Erstellen dieser Funktionen erforderlichen, technischen Lösungen in Form von Gastbeiträgen, gemäß der Priorität des Gastteams, erbracht. +*InnerSource wird somit zu einem Multiplikator* mit dem das Hostteam in Zeiten hoher Nachfrage vorübergehend mehr Funktionalität liefern kann als seine eigentliche Teamgröße indiziert. +Wenn die Welle der Nachfragen beendet ist, reduziert sich der Teamdurchsatz auf ein normales Niveau ohne dass die Anzahl der Mitarbeiter oder die Arbeitsaufgaben im Team verändert werden müssen. +Das bedeutet, mit InnerSource kann Entwicklungsenergie organisch dorthin fließen, wo das Unternehmen sie zu einem bestimmten Zeitpunkt benötigt. + +Neben der einfachen Verbesserung der Funktionalität die das Hostteam erzielen kann, bieten regelmäßige InnerSource-Beiträge dem Hostteam *bessere Einsicht in Anforderungen und eine bessere Ausrichtung der Prioritäten auf alle seine Nutzer*. +Ein Hostteam kann mit größtem Aufwand Anforderungen für Ihr Produkt sammeln, wenn jedoch der Nutzer selbst die jeweilige Anforderung einreicht, sind die Chancen erheblich höher, dass die daraus resultierende Änderung genau auf die Bedürfnisse des Nutzers abgestimmt ist. +Weiterhin gilt, während es möglicherweise nur ein einziges Gastteam die Änderung einreicht, ist dieses Team wahrscheinlich auch repräsentativ für andere Nutzer. + +Zusätzlich zu den oben aufgezeigten Vorteilen, bietet diese Art der Zusammenarbeit auch eine Chance zur Weiterbildung der https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[Contributors], während sie mit ihnen arbeiten und von ihnen als https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/trusted-committer/01-introduction.asciidoc[Trusted Committers] lernen. +Diese Interaktionen helfen den Mitwirkenden in zu lernen und zu wachsen, was zu letztendlich zu einer *höheren Arbeitszufriedenheit* führt. +Weiterhin wird im Allgemeinen die Projektdokumentation schrittweise verbessert, um Gastbeiträge in großem Maßstab zu ermöglichen und zu fördern. +Natürlich ist auch nicht zu vergessen, dass sich die Mitwirkenden am Projekt des Hostteams beteiligt fühlen. +Diese positive Erfahrung führt dann dazu, dass sie ihren Kollegen oder anderen Teams dieses Projekt empfehlen. +Die Mitarbeiter des Gastteams verstehen das Projekt besser und können Fragen dazu beantworten, wodurch das Hostteam von diesem Teil der Arbeit entlastet wird. +All dies führt im Laufe der Zeit dazu, dass immer mehr Mitarbeiter nach Ideen aus dem gesamten Unternehmen suchen. +Letztendlich hift dieses Verhalten und die teamübergreifende Ausrichtung im Laufe der Zeit die *traditionellen Silos in Unternehmen abzubauen*. diff --git a/introduction/de/05-principles.asciidoc b/introduction/de/05-principles.asciidoc new file mode 100644 index 00000000..631e40cb --- /dev/null +++ b/introduction/de/05-principles.asciidoc @@ -0,0 +1,70 @@ +== InnerSource-Prinzipien + +Jedes Unternehmen, Team, Projekt und Individuum ist verschieden. +Aus diesem Grund variiert die genaue Anwendung der InnerSource-Konzepte von Situation zu Situation. +Im Mittelpunkt stehen jedoch immer vier Prinzipien. Sie bilden das Fundament jeder erfolgreichen Anwendung von InnerSource. +Diese Prinzipien sind inspiriert durch erfolgreiche Open Source-Projekte und sind erforderlich damit InnerSource die zuvor beschriebenen Vorteile erzielt. + +Die Prinzipien sind: + +* *Offenheit* +* *Transparenz* +* *Focus auf Mentoring* +* *Freiwilliger Codebeitrag* + +Schauen wir uns jedes dieser Prinzipien genauer an. + +=== Offenheit + +Die Offenheit eines Projekts ermöglicht reibungslose Teilnahme. +Projekte sollten leicht auffindbar und gut über die Dateien README.md und CONTRIBUTING.md im Stammverzeichnis (Root) des Repos dokumentiert sein. +Jeder innerhalb einer Organisation sollte in der Lage sein, ein gewünschtes Projekt zu finden und ohne übermäßige weitere Hilfe durch die Mitglieder des Hostteams mit der Arbeit zu beginnen. +Das Hostteam sollte über genau jene Kanäle erreichbar sein wie es für das Projekt sinnvoll ist. +Die Absichten des Hostteams InnerSource-Beiträge zu seinem Projekt anzunehmen, sollten über relevante Organisationskanäle mitgeteilt werden, um das Bewusstsein dafür zu erhöhen. +Insbesondere in kleineren Organizations möchten Sie möglicherweise regelmäßig über die InnerSource-Arbeit Ihres Teams berichten. +In größeren Unternehmen/Organizationen können solche Berichte/Nachrichten jedoch überwaltigend sein und es ist möglicherweise angemessener, sicherzustellen, dass das Projekt z.B. in einem benutzerfreundlichen Tool leicht auffindbar ist. +Denken Sie daran, das Ziel ist es, die Kanäle zu nutzen, die in IHREM Unternehmen am besten funktionieren. + +Die obige Liste ist keineswegs erschöpfend. +Die Offenheit eines Projekts hängt in der Regel direkt davon ab wie erfolgreich ein Projekt in Bezug auf InnerSource ist. +Je offener es ist, desto weniger Hindernisse werden für potenzielle Mitwirkende geschaffen. +Je weniger offen es ist, desto schwieriger wird es für jemanden ausserhalb des Hostteams, einen Beitrag zu leisten. + +=== Transparenz + +Damit Gastteams einen sinnvollen Beitrag zu einem Projekt leisten können, muss sich das Hostteam transparent verhalten. +Dies bedeutet, dass Gastteams in der Lage sein sollten, folgendes zu verstehen: + +* Das Projekt / Repo und seine Ziele +* Noch offene Feature Requests +* Fortschritte bei der Entwicklung von Features +* 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. + +=== Priorisierte Betreuung + +_Mentorship_ vom Hostteam zum Gastteam durch https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/trusted-committer/01-introduction.asciidoc[Trusted Committers] ist ein Schlüsselaspekt von InnerSource. +https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[Contributors] in Gastteams sind auf dem neuesten Stand, sodass sie genug über das Projekt / Repo des Host-Teams wissen um es erfolgreich verändern zu können. +Dabei lernen sie die Software des Hostteams sowohl als genereller Nutzer als auch als Botschafter für das Projekt / die Software besser verstehen. +Diese einzelnen Mitarbeiter können im Laufe der Zeit und mit wachsender Erfahrung eine breitere Rolle im Projekt als Trusted Committer zu übernehmen. + +Es ist wichtig, dass Mentoring für potentielle Contributoren vom Hostteam priorisiert wird. +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. +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. + +=== Freiwilliger Codebeitrag + +Das Wort _freiwillig_ bedeutet, dass das Engagement von Gast- und Hostteams in InnerSource aus freiem Willen erfolgt. +Das Gastteam spendet freiwillig Code an das Hostteam und das Hostteam akzeptiert ihn freiwillig. +Diese Opt-in-Natur bedeutet, dass jedes Team sicher sein muss, dass sein Engagement einen Mehrwert für die Ziele des anderen darstellt. +Niemals muss ein Hostteam einen Beitrag annehmen, der nicht mit dem endgültigen Ziel übereinstimmt. +Niemals muss ein Gastteam einen Beitrag einreichen, der letztendlich das Erreichen seiner eigenen Ziele und Prioritäten nicht fördert. + +Das Wort _Code_ betont, dass die Zusammenarbeit zwischen Gast und Host bis zum Code reicht. +Die Beteiligung der Gäste in Form von Bug Reports, Aktualisieren von Anforderungen, Korrigieren von Dokumentation usw. sind sehr wertvoll. Jedoch muss die Zusammenarbeit letztlich bis hin zur Entwicklung reichen, um die oben diskutierten positiven Effekte zu erzielen. diff --git a/introduction/de/06-conclusion.asciidoc b/introduction/de/06-conclusion.asciidoc new file mode 100644 index 00000000..96931c2b --- /dev/null +++ b/introduction/de/06-conclusion.asciidoc @@ -0,0 +1,13 @@ +== Schlusswort + +In dieser Serie haben wir eine Einführung in InnerSource gegeben. +InnerSource wendet Open Source Praktiken und Prinzipien auf die firmeninterne Softwareentwicklung an. +Es bietet Nutzern eine zusätzliche Option, speziell wenn Produktionsteams nicht in der Lage sind, ein erforderliches Requirement im notwendigen Zeitraum zu liefern. +Erfolgreiche InnerSource Projekte betreffen https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/product-owner/01-opening-article.asciidoc[_Produkt Owner_] und https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/trusted-Committer/01-Introduction.asciidoc [_Trusted Committer_] vom *Hostteam* sowie ein https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc [_Contributor_] vom *Gastteam*. +Richtig betriebenes InnerSource bietet beiden teilnehmenden Teams viele Vorteile. +Die Schlüsselprinzipien, nach denen gut geführte InnerSource Projekte funktionieren, sind *freiwilliger Code-Beitrag* und *Mentoring Fokus*. + +Während diese Serie einen allgemeinen Überblick über InnerSource enthält, gibt es viele weitere wichtige Details, um InnerSource in Ihrem Team erfolgreich zu praktizieren. +Wenn Sie über Entwicklungen in InnerSource und die damit verbundenen Best Practices auf dem laufenden gehalten werden möchten, laden wir Sie herzlich zu den http://innersourcecommons.org [InnerSource Commons] ein. +Weiterhin betreibt die InnerSource Commons Foundation einen Slack-Kanal, sowie eine InnerSource Working Group die sich mit erfolgreichen InnerSource Patterns befasst, und veranstaltet jedes Jahr mehrere Treffen. +Ihre Teilnahme an den InnerSource Commons ist eine großartige Möglichkeit, um mit den neuesten Entwicklungen in InnerSource auf dem laufenden zu bleiben.