From 61d62813198255f13078550401187562d3634cbe Mon Sep 17 00:00:00 2001 From: Arno Mihm Date: Mon, 24 Feb 2020 10:04:00 -0800 Subject: [PATCH 01/30] first batch of "Introduction" translations to DE --- introduction/02-problems-solved.asciidoc | 8 +- introduction/de_de/01-introduction.asciidoc | 12 +++ .../de_de/02-problems-solved.asciidoc | 38 ++++++++ introduction/de_de/03-how-works.asciidoc | 95 +++++++++++++++++++ 4 files changed, 149 insertions(+), 4 deletions(-) create mode 100644 introduction/de_de/01-introduction.asciidoc create mode 100644 introduction/de_de/02-problems-solved.asciidoc create mode 100644 introduction/de_de/03-how-works.asciidoc 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/de_de/01-introduction.asciidoc b/introduction/de_de/01-introduction.asciidoc new file mode 100644 index 00000000..05b94ddd --- /dev/null +++ b/introduction/de_de/01-introduction.asciidoc @@ -0,0 +1,12 @@ +== Einführung + +Diese Weiterbildungsserie 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, kann jedoch von jedem Mitarbeiter des Unternehmens genutzt, verbessert und erweitert werden. +Diese Strategie ermöglicht eine breite und effektive Zusammenarbeit und produziert Software, die sich schnell auf die sich ändernden Anforderungen der verschiedenen internen +Stakeholder einstellen und anpassen lässt. + +Diese Serie zeigt auf, wie Sie Situationen erkennen in denen die Anwendung von InnerSource Praktiken vorteilhaft sind. +Wir werden beispielhaft skizzieren wie InnerSource in diesen Situationen helfen kann und +Sie werden mit Begriffen vertraut gemacht die im Zusammenhang mit InnerSource verwendet werden. +Wir werden weiterhin die wichtigsten Prinzipien auf denen InnerSource basiert aufzählen, und Vorteile nennen, die sich bei einer effektiven Anwendung der vorgestellten Praktiken ergeben. \ No newline at end of file diff --git a/introduction/de_de/02-problems-solved.asciidoc b/introduction/de_de/02-problems-solved.asciidoc new file mode 100644 index 00000000..c6122d41 --- /dev/null +++ b/introduction/de_de/02-problems-solved.asciidoc @@ -0,0 +1,38 @@ +Welche Probleme löst InnerSource? +InnerSource fördert und belohnt die Zusammenarbeit und die Wiederverwendung von Code mit jedem, unabhängig von seiner Position in der Organisationsstruktur eines Unternehmens. +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. +Lassen Sie uns eine Situation untersuchen, die ein Beispiel für diesen neuen Ansatz gibt. + +Stellen Sie sich 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 ihrer Seite als Konsumer. +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önnen Sie ein neues Projekt erstellen das ihren 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 uebernehmen obwohl die Thematik ausserhalb der Kernteamkompetenz des Teams liegt. +.. Das Unternehmen bekommt im Laufe der Zeit doppelte 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 zu erfordern. +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 so oft Feature-Anfragen eskalieren kann, bevor seine Glaubwürdigkeit beeinträchtigt wird. +Die Eskalation ist für das Produktionsteam ähnlich störend (umso mehr) da es aus seinen normalen Workflow- und Priorisierungsmethoden herausgenommen wird um die eskalierte Funktionsanforderung zu bearbeiten. + +Diese Diskussion bereitet die Bühne für InnerSource. +InnerSource 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 Ingenieurkultur, da Ingenieure die Möglichkeit haben, mit einer größeren Vielfalt neuer Technologien und Mitarbeiter zu arbeiten. +Entwickler lehren einander und lernen voneinander wenn sie Ideen und Lösungen zwischen verschiedenen Unternehmenssilos austauschen. +Ingenieure und Teams können interne Lösungen für Standartprobleme wiederverwenden, sodass sie sich auf lukrativere Aufgaben für das Unternehmen konzentrieren können. \ No newline at end of file diff --git a/introduction/de_de/03-how-works.asciidoc b/introduction/de_de/03-how-works.asciidoc new file mode 100644 index 00000000..1726daca --- /dev/null +++ b/introduction/de_de/03-how-works.asciidoc @@ -0,0 +1,95 @@ +== How does InnerSource work? + +Let's say that team A uses software produced by team B. +Team A submits a feature request to team B, but team B isn't able to implement that feature in time for team A. +In an InnerSource setting, if team A can't get this feature request then it submits a pull request instead. +That is to say team A implements the feature directly in team B's software and submits a pull request with the code changes. +Team B partners to review and accept the submitted code. + +In this example, we call team A the _Guest_ team and team B the _Host_ team. +The terms _Guest_ and _Host_ suggest a situation analogous to receiving a visitor in the home. +In that situation, most people want to be a good host. +They ensure that things are kept neat and tidy in anticipation of their guests' arrival. +Visitors are greeted at the door and invited in. +They can use the features and utilities that are in the home's public areas. +There may be a few house rules that guests are asked to follow. +Similarly, most guests want to show respect for the home and their host. +They're careful with the items in the house and follow the rules for the duration of their stay. +They may hope for or expect a return invitation as long as they've been courteous and polite. +These concepts around a home visit are a metaphor for the attitude and behaviors that teams should bring as one hosts another making a guest contribution to the codebase. + +Let's take a closer look at how the mechanics of the InnerSource process can work. +To aid in this explanation, we'll name a few key individuals on the guest and host teams. +First, the https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/product-owner/01-opening-article.asciidoc[_Product Owner_] determines what functionality the host team is willing to accept as a contribution. +The https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_Contributor_] is the individual on the guest team that submits the code contribution for review by the host team. +The https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/trusted-committer/01-introduction.asciidoc[_Trusted Committer_] represents the host team in providing any timely support and mentorship that the contributor needs to successfully submit the pull request. +On small, grass roots efforts a single person often fills _both_ the product owner and trusted committer roles. + +With those definitions, here is the basic outline of an InnerSource contribution. + +* Guest team or contributor requests a feature from the host team. +* Product owner ensures that user stories representing the feature request are created, either by members of the guest team or host team. +These stories should describe the requested feature in terms agreeable to the guest team. +They also list any details from the host team on how the feature should be delivered in order for the work to be accepted. +Examples of such details include architecture constraints, coding conventions, dependency usages, data contracts, etc. +* Supported by the trusted committer, the contributor submits the pull request to implement the requested feature. + +Note that these steps do not assume a specific system for the general organization of a team's time or priorities. InnerSource assumes that teams already have existing methods of organization and provides a framework of how to use them to work together where there is a guest team desiring to contribute code to a host. + +This option works well for the guest team because they get the functionality they need when they need it without taking on the long-term burden of maintenance of the solution. +It works for the host team because they are able to better scale and serve their consumers. +It works for the company at-large because solutions to shared problems end up in shared, centrally-maintained locations where anyone can use them. +More engineering time stays focused on producing code that solves company problems rather than the mechanics of the feature negotiation and escalation process. + +=== Additional Resources + +* The https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/project-roles/trusted-committer.asciidoc[Trusted Committer] pattern. + + +== Wie funktioniert InnerSource? + +Angenommen, Team A verwendet Software, die von Team B produziert wird. +Team A sendet eine Funktionsanforderung an Team B, aber Team B kann diese Funktion nicht rechtzeitig für Team A implementieren. +In einer InnerSource Umgebung kann Team A anstatt einer Feature-Anforderung auch alternativ einen PullRequest an Team B zur Integration schicken. +Das heißt, Team A implementiert die Funktion direkt in der Software von Team B und sendet einen PullRequest mit den Codeänderungen. +In enger Partnerschaft überprüft Team B dann den übermittelten Code und ggf. akzeptiert die Aenderungen wenn sie den Anforderungen enpricht. + +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. +In Erwartung der Ankunft ihrer Gäste, sorgen Sie dafür, dass die Dinge sauber in bester Ordnung sind. +Die Besucher werden an der Tür begrüßt und herein gebeten. +Sie können die Funktionen und Räume nutzen, die sich in den öffentlichen Bereichen des Hauses befinden. +Es kann ein paar Hausregeln geben, die Sie gebeten werden zu befolgen. +Ebenso wollen die meisten Gäste Respekt vor dem Zuhause und ihrem Gastgeber zeigen. +Sie sind vorsichtig mit den Gegenständen im Haus und folgen den Regeln für die Dauer ihres Aufenthalts. +Sie können auf eine erneute Einladung hoffen, solange sie sich gut benommen haben und höflich waren. +Diese Konzepte rund um einen Hausbesuch sind eine Metapher für die Einstellung und das Verhalten das Teams an den Tage legen sollten wenn der eine der Gastgeber (Host) ist, und der andere ein Gast (Contributor) ist der einen Gastbeitrag (Contribution) zur Codebasis leistet. + +Werfen wir einen genaueren Blick darauf, wie der InnerSource-Prozess funktioniert. +Befor wir in das Thema tiefer einsteigen, lassen sie uns einige wichtige Rollen in den Gast- und Gastgeberteams vorstellen. +Zunächst bestimmt https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/product-owner/01-opening-article.asciidoc[_Product Owner_], 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, eingfacheren Projekten füllt oft eine einzelne Person _sowohl_ die Rolle des Produktbesitzers als auch die des Trusted Committer aus. + +Basierend auf diesen Definitionen folgt nun der eine grobe Skizze des InnerSource-Prozesses. + +* Gastteam oder ein Mitglied des Gastteams fragt eine Funktion vom Host-Team an. +* Der Produktbesitzer stellt sicher, dass die Featureanforderungen gemaess des Entwicklungsprozzesses des Hostteams erstellt werden, entweder von Mitgliedern des Gastteams oder Mitgliedern des Gastgeberteams. +Diese Documentation geschieht meist in der Form von Userstories, welche die gewünschte Funktion und Rahmenbedingungen beschreiben, die das Gastteam akzeptiert hat. +Sie listet auch alle Details aus Sicht des Host-Teams auf, z.B. wie eine Funktion geschrieben und eingereicht werden soll damit der Code akzeptiert werden kann. +Beispiele für solche Details sind Architektureinschränkungen, Codierungskonventionen, Abhängigkeitsverwendungen, Datenverträge usw. +* Unterstützt vom vertrauenswürdigen Committer, sendet der Mitwirkende den PullRequest, um die angefragte Funktion zu implementieren. + +Beachten Sie, dass bei diesen Schritten kein bestimmtes System für die allgemeine Organisation der Zeit oder der Prioritäten eines Teams angenommen 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 funktioniert gut für das Gastteam, da es die Funktionalität erhält die es benötigt, wenn sie sie benötigt, und ohne die Notwendigkeit 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 Verfuegung gestellt werden. +Letzlich steht mehr Zeit für die Erstellung von Code zur Verfügung, der die wirklichen Unternehmensprobleme löst, anstatt sie zur Verhandlung über Features oder für Eskalationsprozesse zu verwenden. + +=== Zusätzliche Ressourcen + +* Die Mustervorlage https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/project-roles/trusted-committer.asciidoc[Trusted Committer]. \ No newline at end of file From 674c32c3d1cb39e3ec110787c36af3aad41a0ca9 Mon Sep 17 00:00:00 2001 From: Arno Mihm Date: Mon, 24 Feb 2020 10:23:00 -0800 Subject: [PATCH 02/30] removed english text in german translation --- introduction/de_de/03-how-works.asciidoc | 48 ------------------------ 1 file changed, 48 deletions(-) diff --git a/introduction/de_de/03-how-works.asciidoc b/introduction/de_de/03-how-works.asciidoc index 1726daca..eadb3ae4 100644 --- a/introduction/de_de/03-how-works.asciidoc +++ b/introduction/de_de/03-how-works.asciidoc @@ -1,51 +1,3 @@ -== How does InnerSource work? - -Let's say that team A uses software produced by team B. -Team A submits a feature request to team B, but team B isn't able to implement that feature in time for team A. -In an InnerSource setting, if team A can't get this feature request then it submits a pull request instead. -That is to say team A implements the feature directly in team B's software and submits a pull request with the code changes. -Team B partners to review and accept the submitted code. - -In this example, we call team A the _Guest_ team and team B the _Host_ team. -The terms _Guest_ and _Host_ suggest a situation analogous to receiving a visitor in the home. -In that situation, most people want to be a good host. -They ensure that things are kept neat and tidy in anticipation of their guests' arrival. -Visitors are greeted at the door and invited in. -They can use the features and utilities that are in the home's public areas. -There may be a few house rules that guests are asked to follow. -Similarly, most guests want to show respect for the home and their host. -They're careful with the items in the house and follow the rules for the duration of their stay. -They may hope for or expect a return invitation as long as they've been courteous and polite. -These concepts around a home visit are a metaphor for the attitude and behaviors that teams should bring as one hosts another making a guest contribution to the codebase. - -Let's take a closer look at how the mechanics of the InnerSource process can work. -To aid in this explanation, we'll name a few key individuals on the guest and host teams. -First, the https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/product-owner/01-opening-article.asciidoc[_Product Owner_] determines what functionality the host team is willing to accept as a contribution. -The https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[_Contributor_] is the individual on the guest team that submits the code contribution for review by the host team. -The https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/trusted-committer/01-introduction.asciidoc[_Trusted Committer_] represents the host team in providing any timely support and mentorship that the contributor needs to successfully submit the pull request. -On small, grass roots efforts a single person often fills _both_ the product owner and trusted committer roles. - -With those definitions, here is the basic outline of an InnerSource contribution. - -* Guest team or contributor requests a feature from the host team. -* Product owner ensures that user stories representing the feature request are created, either by members of the guest team or host team. -These stories should describe the requested feature in terms agreeable to the guest team. -They also list any details from the host team on how the feature should be delivered in order for the work to be accepted. -Examples of such details include architecture constraints, coding conventions, dependency usages, data contracts, etc. -* Supported by the trusted committer, the contributor submits the pull request to implement the requested feature. - -Note that these steps do not assume a specific system for the general organization of a team's time or priorities. InnerSource assumes that teams already have existing methods of organization and provides a framework of how to use them to work together where there is a guest team desiring to contribute code to a host. - -This option works well for the guest team because they get the functionality they need when they need it without taking on the long-term burden of maintenance of the solution. -It works for the host team because they are able to better scale and serve their consumers. -It works for the company at-large because solutions to shared problems end up in shared, centrally-maintained locations where anyone can use them. -More engineering time stays focused on producing code that solves company problems rather than the mechanics of the feature negotiation and escalation process. - -=== Additional Resources - -* The https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/project-roles/trusted-committer.asciidoc[Trusted Committer] pattern. - - == Wie funktioniert InnerSource? Angenommen, Team A verwendet Software, die von Team B produziert wird. From 02a658eeffa7ae074eeedef8b76e2b7e65728d44 Mon Sep 17 00:00:00 2001 From: Arno Mihm Date: Mon, 24 Feb 2020 11:50:50 -0800 Subject: [PATCH 03/30] Introduction article 4 translated to german --- introduction/de_de/04-benefits.asciidoc.txt | 31 +++++++++++++++++++++ 1 file changed, 31 insertions(+) create mode 100644 introduction/de_de/04-benefits.asciidoc.txt diff --git a/introduction/de_de/04-benefits.asciidoc.txt b/introduction/de_de/04-benefits.asciidoc.txt new file mode 100644 index 00000000..3733849d --- /dev/null +++ b/introduction/de_de/04-benefits.asciidoc.txt @@ -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 zu übernehmen. +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äßige InnerSourcebeiträge erhalten, ebenfalls viele Vorteile. +Denken Sie daran, dass der Product Owner im Hostteam im Rahmen des InnerSourceprozesses von Anfang an entscheidet ob die bereitgestellten Funktionen gut und wünschenswert sind für das Project sind. +Somit kann mit InnerSource das Host-Team *Hilfe bei der Erstellung eines besseren Produkts* für seine Verbraucher erhalten! + +*InnerSource bietet dem Host-Team eine skalierbare Strategie* zur Erfüllung unterschiedlicher Anforderungen für Funktionen die von seinen verschiedenen Kunden vorgebracht werden. +Angesichts der festen Arbeitskapazität der Vollzeitmitglieder des Hostteams ist es wahrscheinlich, dass die kombinierten Geschäftspläne der Verbraucher zuweilen sehr (oder sogar unangemessen) viel Arbeit für das Host-Team bedeutet. +Ohne InnerSource führt diese Situation leicht zu einem gestressten, überlasteten Team, das sich mit vielen (fremden) Feature-Anfragen befasst, die ggf. über seine Führungskräfte eskaliert worden sind. + +Wenn das Host-Team jedoch nach InnerSource Prinzipien arbeitet, werden die zum Erstellen dieser Funktionen erforderlichen technischen Loesungen in Form von Gastbeiträgen gemaess der Priorität für das Gastteam erbracht. +*InnerSource wird zu einem Multiplikator* mit dem das Hostteam in Zeiten hoher Nachfrage vorübergehend mehr Funktionalität liefern kann als seine 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. +Mit InnerSource kann die Entwicklungsaufwand organisch dorthin fließen, wo das Unternehmen es zu einem bestimmten Zeitpunkt benötigt. + +Neben der einfachen Verbesserung der Funktionalität die das Host-Team erzielen kann, bieten regelmäßige InnerSourcebeiträ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 ist das die Änderung einreicht, ist dieses Team wahrscheinlich auch repräsentativ für viele andere Nutzer. + +Zusätzlich zu dieser oben aufgezeigten Vorteilen, bietet diese Art der Zusammenarbeit auch eine allgemeine Weiterbildung von https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[contributors], während sie mit ihnen arbeiten und von ihnen lernen https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/trusted-committer/01-introduction.asciidoc[trusted committers]. +Diese Interaktionen helfen den Mitwirkenden in ihrer Karriere zu lernen und zu wachsen, was zu letztendlich zu einer *höheren Arbeitszufriedenheit* führt. +Weiterhin wird im allgemeinen die Projektdokumentation verbessert, um Gastbeiträge in großem Maßstab zu ermöglichen und zu fördern. +Nicht zu vergessen ist, dass sich die Mitwirkenden am Projekt des Hostteams beteiligt fühlen. +Dies ist etwas, dass sie ihren Kollegen oder neuen Teams empfehlen denen sie beitreten. +Sie verstehen das Projekt besser und können Fragen dazu beantworten, wodurch das Host-Team von dieser Teil der Arbeit entlastet wird. +Im Laufe der Zeit suchen immer mehr Mitarbeiter nach Ideen aus dem gesamten Unternehmen. +Dieses Verhalten und die teamübergreifende Ausrichtung helfen der im Laufe der Zeit die *traditionellen Silos in Unternehmen abzubauen*. \ No newline at end of file From 4fd44f1e51886b28df62dffb8be6c8be237393b7 Mon Sep 17 00:00:00 2001 From: Arno Mihm Date: Mon, 24 Feb 2020 13:28:47 -0800 Subject: [PATCH 04/30] FIxed wordings and phrases in article 4 (DE) --- introduction/de_de/04-benefits.asciidoc.txt | 38 ++++++++++----------- 1 file changed, 19 insertions(+), 19 deletions(-) diff --git a/introduction/de_de/04-benefits.asciidoc.txt b/introduction/de_de/04-benefits.asciidoc.txt index 3733849d..80572fd3 100644 --- a/introduction/de_de/04-benefits.asciidoc.txt +++ b/introduction/de_de/04-benefits.asciidoc.txt @@ -1,31 +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 zu übernehmen. +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äßige InnerSourcebeiträge erhalten, ebenfalls viele Vorteile. +Während dieses Ergebnis ein glänzender Vorteil von InnerSource ist gibt es für Hosts die regelmäßige InnerSourcebeiträge erhalten ebenfalls viele Vorteile. Denken Sie daran, dass der Product Owner im Hostteam im Rahmen des InnerSourceprozesses von Anfang an entscheidet ob die bereitgestellten Funktionen gut und wünschenswert sind für das Project sind. -Somit kann mit InnerSource das Host-Team *Hilfe bei der Erstellung eines besseren Produkts* für seine Verbraucher erhalten! +Somit kann das Hostteam durch die Anwendung von InnerSourceprinzipien *Hilfe bei der Erstellung eines besseren Produkts* für seine Verbraucher erhalten! -*InnerSource bietet dem Host-Team eine skalierbare Strategie* zur Erfüllung unterschiedlicher Anforderungen für Funktionen die von seinen verschiedenen Kunden vorgebracht werden. -Angesichts der festen Arbeitskapazität der Vollzeitmitglieder des Hostteams ist es wahrscheinlich, dass die kombinierten Geschäftspläne der Verbraucher zuweilen sehr (oder sogar unangemessen) viel Arbeit für das Host-Team bedeutet. -Ohne InnerSource führt diese Situation leicht zu einem gestressten, überlasteten Team, das sich mit vielen (fremden) Feature-Anfragen befasst, die ggf. über seine Führungskräfte eskaliert worden sind. +*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 kombinierten Geschäftspläne 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 Host-Team jedoch nach InnerSource Prinzipien arbeitet, werden die zum Erstellen dieser Funktionen erforderlichen technischen Loesungen in Form von Gastbeiträgen gemaess der Priorität für das Gastteam erbracht. -*InnerSource wird zu einem Multiplikator* mit dem das Hostteam in Zeiten hoher Nachfrage vorübergehend mehr Funktionalität liefern kann als seine 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. -Mit InnerSource kann die Entwicklungsaufwand organisch dorthin fließen, wo das Unternehmen es zu einem bestimmten Zeitpunkt benötigt. +Wenn das Hostteam jedoch nach InnerSource Prinzipien arbeitet, werden die zum Erstellen dieser Funktionen erforderlichen technischen Lösungen in Form von Gastbeiträgen gemäss der Priorität des Gastteam 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 die Entwicklungsaufwand organisch dorthin fließen, wo das Unternehmen es zu einem bestimmten Zeitpunkt benötigt. -Neben der einfachen Verbesserung der Funktionalität die das Host-Team erzielen kann, bieten regelmäßige InnerSourcebeiträge dem Hostteam *bessere Einsicht in Anforderungen und eine bessere Ausrichtung der Prioritäten auf alle seine Nutzer*. +Neben der einfachen Verbesserung der Funktionalität die das Hostteam erzielen kann, bieten regelmäßige InnerSourcebeiträ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 ist das die Änderung einreicht, ist dieses Team wahrscheinlich auch repräsentativ für viele andere Nutzer. +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 dieser oben aufgezeigten Vorteilen, bietet diese Art der Zusammenarbeit auch eine allgemeine Weiterbildung von https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contributor/01-introduction-article.asciidoc[contributors], während sie mit ihnen arbeiten und von ihnen lernen https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/trusted-committer/01-introduction.asciidoc[trusted committers]. +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 ihrer Karriere zu lernen und zu wachsen, was zu letztendlich zu einer *höheren Arbeitszufriedenheit* führt. -Weiterhin wird im allgemeinen die Projektdokumentation verbessert, um Gastbeiträge in großem Maßstab zu ermöglichen und zu fördern. -Nicht zu vergessen ist, dass sich die Mitwirkenden am Projekt des Hostteams beteiligt fühlen. -Dies ist etwas, dass sie ihren Kollegen oder neuen Teams empfehlen denen sie beitreten. -Sie verstehen das Projekt besser und können Fragen dazu beantworten, wodurch das Host-Team von dieser Teil der Arbeit entlastet wird. -Im Laufe der Zeit suchen immer mehr Mitarbeiter nach Ideen aus dem gesamten Unternehmen. -Dieses Verhalten und die teamübergreifende Ausrichtung helfen der im Laufe der Zeit die *traditionellen Silos in Unternehmen abzubauen*. \ No newline at end of file +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 ist, dass sich die Mitwirkenden am Projekt des Hostteams beteiligt fühlen. +Diese positive Erfahrung führt dann dazu, dass sie ihren Kollegen oder ihren neuen Teams dies Projekte empfehlen. +Die Mitarbieter des Gastteams verstehen das Projekt besser und können Fragen dazu beantworten, wodurch das Hostteam von dieser 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*. \ No newline at end of file From caca0ef7b14dff1ecfce2417f41e6d1df5391dd7 Mon Sep 17 00:00:00 2001 From: Arno Mihm Date: Mon, 24 Feb 2020 13:39:43 -0800 Subject: [PATCH 05/30] rename language folder to "de" to match ISO639-1 --- introduction/{de_de => de}/01-introduction.asciidoc | 0 introduction/{de_de => de}/02-problems-solved.asciidoc | 0 introduction/{de_de => de}/03-how-works.asciidoc | 0 introduction/{de_de => de}/04-benefits.asciidoc.txt | 0 4 files changed, 0 insertions(+), 0 deletions(-) rename introduction/{de_de => de}/01-introduction.asciidoc (100%) rename introduction/{de_de => de}/02-problems-solved.asciidoc (100%) rename introduction/{de_de => de}/03-how-works.asciidoc (100%) rename introduction/{de_de => de}/04-benefits.asciidoc.txt (100%) diff --git a/introduction/de_de/01-introduction.asciidoc b/introduction/de/01-introduction.asciidoc similarity index 100% rename from introduction/de_de/01-introduction.asciidoc rename to introduction/de/01-introduction.asciidoc diff --git a/introduction/de_de/02-problems-solved.asciidoc b/introduction/de/02-problems-solved.asciidoc similarity index 100% rename from introduction/de_de/02-problems-solved.asciidoc rename to introduction/de/02-problems-solved.asciidoc diff --git a/introduction/de_de/03-how-works.asciidoc b/introduction/de/03-how-works.asciidoc similarity index 100% rename from introduction/de_de/03-how-works.asciidoc rename to introduction/de/03-how-works.asciidoc diff --git a/introduction/de_de/04-benefits.asciidoc.txt b/introduction/de/04-benefits.asciidoc.txt similarity index 100% rename from introduction/de_de/04-benefits.asciidoc.txt rename to introduction/de/04-benefits.asciidoc.txt From 683d4ef4214dacf6703ac58d9c591113fc2c9e63 Mon Sep 17 00:00:00 2001 From: Arno Mihm Date: Mon, 24 Feb 2020 15:26:08 -0800 Subject: [PATCH 06/30] Article 5 type fix and German translation --- introduction/05-principles.asciidoc | 2 +- introduction/de/05-principles.asciidoc.txt | 70 ++++++++++++++++++++++ 2 files changed, 71 insertions(+), 1 deletion(-) create mode 100644 introduction/de/05-principles.asciidoc.txt 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/05-principles.asciidoc.txt b/introduction/de/05-principles.asciidoc.txt new file mode 100644 index 00000000..015414a2 --- /dev/null +++ b/introduction/de/05-principles.asciidoc.txt @@ -0,0 +1,70 @@ +== InnerSource-Prinzipien + +Jedes Unternehmen, Team, Projekt und Individuum ist verschieden. +Aus diesem Grund variiert die genaue Anwendung der InnerSourcekonzepte von Situation zu Situation. +Im Mittelpunkt stehen in jeden Fall jedoch vier Prinzipien, die das Fundament jeder erfolgreichen Anwendung von InnerSource bilden. +Diese Prinzipien sind inspiriert durch erfolgreiche Open Source-Projekte und sind erforderlich damit InnerSource die zuvor beschriebenen Vorteile erzielt. + +Die Prinzipien sind: + +* *Offenheit* +* *Transparenz* +* *Priorisierte Betreuung* +* *Freiwilliger Codebeitrag* + +Schauen wir uns jedes dieser Prinzipien genauer an. + +=== Offenheit + +Die Konfiguration eines offenen 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 Arbiet zu beginnen. +Die Kontaktinformationen des Hostteams sollten in allen Kanälen zur Verfügung stehen die für das Projekt sinnvoll sind. +Die Absichten des Hostteams InnerSourcebeiträge zu seinem Projekt anzunehmen, sollten über relevante Organisationskanäle mitgeteilt werden, um das Bewusstsein darum to erhöhen. +Insbesondere in kleineren Organizations möchten Sie möglicherweise regelmäßig über die InnerSourcearbeit 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 Funktionsanforderungen +* Fortschritte bei den Funktionentwicklungen +* 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 die Schulung für potentielle Contributors vom Hostteam priorisiert wird. +Das Hostteam sollte sich bemühen sich ausreichend Zeit für die Betreuung der Mitarbeiter des Gastteams zu nehmen - ganz speziell zu dem Zeitpunkt zu dem der Mitarbeiter es benötigt - und nicht, wenn es für das Hostteam bequem ist. +Manchmal kann es für Ingenieure im Hostteam ein Kulturwandel sein, Zeit zu investiern um anderen beim Codieren zu helfen, anstatt selbst zu codieren. +Diese Art der Schulung/Betreuung 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 Codes 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 erste Wort _Freiwillinger_ 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 am Öffnen von Problemenmeldungen, Aktualisieren von Anforderungen, Korrigieren von Dokumenten usw. ist eine gute Sache, jedoch muss die Zusammenarbeit im Endeffekt bis hin zur Code Entwicklung reichen um die oben diskutierten positiven Effekte zu erzielen. From 7deb593d877df09bd3d1838946854033d817b1f6 Mon Sep 17 00:00:00 2001 From: Arno Mihm Date: Mon, 24 Feb 2020 15:46:05 -0800 Subject: [PATCH 07/30] Translation of article 6 to German --- introduction/de/06-conclusion.asciidoc.txt | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 introduction/de/06-conclusion.asciidoc.txt diff --git a/introduction/de/06-conclusion.asciidoc.txt b/introduction/de/06-conclusion.asciidoc.txt new file mode 100644 index 00000000..69d03add --- /dev/null +++ b/introduction/de/06-conclusion.asciidoc.txt @@ -0,0 +1,13 @@ +== Schusswort + +Auf 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 eine erforderliche Funktionsanforderung im notwendingen Zeitraum zu liefern. +Erfolgreiche InnerSource umfasst 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 betriebene InnerSource bietet beiden teilnehmenden Teams viele Vorteile. +Die Schlüsselprinzipien, nach denen gut geführte InnerSource funktioniert, sind *freiwilliger Code-Beitrag* und *priorisierte Schulung/Betreuung*. + +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 mit den Entwicklungen in InnerSource und seine besten Praktiken auf dem laufenden bleiben möchten, laden wir Sie herzlich zu den http://innersourcecommons.org [dem InnerSource Commons] ein. +Weiterhin betreibt die InnerSource Commons einen Slack-Kanal, eine InnerSource Arbeitsgruppe die sich mit erfolgreichen Zusammenarbeitsmustern 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. \ No newline at end of file From 52cfa06e1e5b6bd3d0d9a400bcbd30262816bbcc Mon Sep 17 00:00:00 2001 From: Arno Mihm Date: Mon, 24 Feb 2020 15:48:32 -0800 Subject: [PATCH 08/30] fixed file extensions --- .../de/{04-benefits.asciidoc.txt => 04-benefits.asciidoc} | 0 .../de/{05-principles.asciidoc.txt => 05-principles.asciidoc} | 0 .../de/{06-conclusion.asciidoc.txt => 06-conclusion.asciidoc} | 0 3 files changed, 0 insertions(+), 0 deletions(-) rename introduction/de/{04-benefits.asciidoc.txt => 04-benefits.asciidoc} (100%) rename introduction/de/{05-principles.asciidoc.txt => 05-principles.asciidoc} (100%) rename introduction/de/{06-conclusion.asciidoc.txt => 06-conclusion.asciidoc} (100%) diff --git a/introduction/de/04-benefits.asciidoc.txt b/introduction/de/04-benefits.asciidoc similarity index 100% rename from introduction/de/04-benefits.asciidoc.txt rename to introduction/de/04-benefits.asciidoc diff --git a/introduction/de/05-principles.asciidoc.txt b/introduction/de/05-principles.asciidoc similarity index 100% rename from introduction/de/05-principles.asciidoc.txt rename to introduction/de/05-principles.asciidoc diff --git a/introduction/de/06-conclusion.asciidoc.txt b/introduction/de/06-conclusion.asciidoc similarity index 100% rename from introduction/de/06-conclusion.asciidoc.txt rename to introduction/de/06-conclusion.asciidoc From 73bd3bba1fbbddd50a68af3c86136b683fd12014 Mon Sep 17 00:00:00 2001 From: Arno Mihm Date: Wed, 11 Mar 2020 23:01:48 -0700 Subject: [PATCH 09/30] fixes based on feeback MaineC, part 1 --- introduction/de/01-introduction.asciidoc | 8 ++++---- introduction/de/02-problems-solved.asciidoc | 15 ++++++++------- 2 files changed, 12 insertions(+), 11 deletions(-) diff --git a/introduction/de/01-introduction.asciidoc b/introduction/de/01-introduction.asciidoc index 05b94ddd..7f039887 100644 --- a/introduction/de/01-introduction.asciidoc +++ b/introduction/de/01-introduction.asciidoc @@ -1,12 +1,12 @@ == Einführung -Diese Weiterbildungsserie bietet eine Einführung in InnerSource. +Diess 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, kann jedoch von jedem Mitarbeiter des Unternehmens genutzt, verbessert und erweitert werden. Diese Strategie ermöglicht eine breite und effektive Zusammenarbeit und produziert Software, die sich schnell auf die sich ändernden Anforderungen der verschiedenen internen Stakeholder einstellen und anpassen lässt. -Diese Serie zeigt auf, wie Sie Situationen erkennen in denen die Anwendung von InnerSource Praktiken vorteilhaft sind. -Wir werden beispielhaft skizzieren wie InnerSource in diesen Situationen helfen kann und -Sie werden mit Begriffen vertraut gemacht die im Zusammenhang mit InnerSource verwendet werden. +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 weiterhin die wichtigsten Prinzipien auf denen InnerSource basiert aufzählen, und Vorteile nennen, die sich bei einer effektiven Anwendung der vorgestellten Praktiken ergeben. \ No newline at end of file diff --git a/introduction/de/02-problems-solved.asciidoc b/introduction/de/02-problems-solved.asciidoc index c6122d41..b76bf70e 100644 --- a/introduction/de/02-problems-solved.asciidoc +++ b/introduction/de/02-problems-solved.asciidoc @@ -1,9 +1,9 @@ Welche Probleme löst InnerSource? InnerSource fördert und belohnt die Zusammenarbeit und die Wiederverwendung von Code mit jedem, unabhängig von seiner Position in der Organisationsstruktur eines Unternehmens. 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. -Lassen Sie uns eine Situation untersuchen, die ein Beispiel für diesen neuen Ansatz gibt. +Lass uns eine Situation untersuchen, die ein Beispiel für diesen neuen Ansatz gibt. -Stellen Sie sich vor, zwei Teams desselben Unternehmens liefern separate Softwareteile, wobei die Software eines Teams abhängig von der Software des anderen Teams ist. +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. @@ -17,7 +17,7 @@ Es kann jedoch zu erheblichen Schwierigkeiten kommen, insbesondere wenn die ange . *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önnen Sie ein neues Projekt erstellen das ihren Anforderungen entspricht und die Verwendung des gesamten oder eines Teils des Codes des Produktionsteams ersetzt (Code- / Projektduplizierung). +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 uebernehmen obwohl die Thematik ausserhalb der Kernteamkompetenz des Teams liegt. @@ -30,9 +30,10 @@ Darüber hinaus lässt sich diese Option nicht skalieren da ein Verbraucher nur Die Eskalation ist für das Produktionsteam ähnlich störend (umso mehr) da es aus seinen normalen Workflow- und Priorisierungsmethoden herausgenommen wird um die eskalierte Funktionsanforderung zu bearbeiten. Diese Diskussion bereitet die Bühne für InnerSource. -InnerSource 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. +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 Ingenieurkultur, da Ingenieure die Möglichkeit haben, mit einer größeren Vielfalt neuer Technologien und Mitarbeiter zu arbeiten. -Entwickler lehren einander und lernen voneinander wenn sie Ideen und Lösungen zwischen verschiedenen Unternehmenssilos austauschen. -Ingenieure und Teams können interne Lösungen für Standartprobleme wiederverwenden, sodass sie sich auf lukrativere Aufgaben für das Unternehmen konzentrieren können. \ No newline at end of file +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. \ No newline at end of file From d3e5296dba75568df4a6a01adf9fe86667cee3a7 Mon Sep 17 00:00:00 2001 From: Arno Mihm Date: Wed, 11 Mar 2020 23:33:24 -0700 Subject: [PATCH 10/30] additional fixes as suggested by MaineC, part 1 --- introduction/de/01-introduction.asciidoc | 4 +-- introduction/de/02-problems-solved.asciidoc | 28 ++++++++++----------- 2 files changed, 16 insertions(+), 16 deletions(-) diff --git a/introduction/de/01-introduction.asciidoc b/introduction/de/01-introduction.asciidoc index 7f039887..7236e44c 100644 --- a/introduction/de/01-introduction.asciidoc +++ b/introduction/de/01-introduction.asciidoc @@ -1,6 +1,6 @@ == Einführung -Diess Learningpath Serie bietet eine Einführung in InnerSource. +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, kann jedoch von jedem Mitarbeiter des Unternehmens genutzt, verbessert und erweitert werden. Diese Strategie ermöglicht eine breite und effektive Zusammenarbeit und produziert Software, die sich schnell auf die sich ändernden Anforderungen der verschiedenen internen @@ -9,4 +9,4 @@ 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 weiterhin die wichtigsten Prinzipien auf denen InnerSource basiert aufzählen, und Vorteile nennen, die sich bei einer effektiven Anwendung der vorgestellten Praktiken ergeben. \ No newline at end of file +Wir werden außerdem die wichtigsten InnerSource-Prinzipien aufzählen, und Vorteile nennen, die sich bei einer effektiven Anwendung ergeben. \ No newline at end of file diff --git a/introduction/de/02-problems-solved.asciidoc b/introduction/de/02-problems-solved.asciidoc index b76bf70e..f96cfdf2 100644 --- a/introduction/de/02-problems-solved.asciidoc +++ b/introduction/de/02-problems-solved.asciidoc @@ -1,35 +1,35 @@ -Welche Probleme löst InnerSource? +== Welche Probleme löst InnerSource? InnerSource fördert und belohnt die Zusammenarbeit und die Wiederverwendung von Code mit jedem, unabhängig von seiner Position in der Organisationsstruktur eines Unternehmens. 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. +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. +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 ihrer Seite als Konsumer. +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. +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 uebernehmen obwohl die Thematik ausserhalb der Kernteamkompetenz des Teams liegt. -.. Das Unternehmen bekommt im Laufe der Zeit doppelte Projekte und Code im selben Problembereich. +.. 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 zu erfordern. +*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 so oft Feature-Anfragen eskalieren kann, bevor seine Glaubwürdigkeit beeinträchtigt wird. -Die Eskalation ist für das Produktionsteam ähnlich störend (umso mehr) da es aus seinen normalen Workflow- und Priorisierungsmethoden herausgenommen wird um die eskalierte Funktionsanforderung zu bearbeiten. +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. -Diese Diskussion bereitet die Bühne für InnerSource. +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. From d0dcf672d72843e1c50bcd4dbdb54d0817e816fd Mon Sep 17 00:00:00 2001 From: Johannes Tigges Date: Tue, 17 Mar 2020 13:51:56 +0100 Subject: [PATCH 11/30] Update introduction/de/03-how-works.asciidoc Co-Authored-By: Isabel Drost-Fromm --- introduction/de/03-how-works.asciidoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/introduction/de/03-how-works.asciidoc b/introduction/de/03-how-works.asciidoc index eadb3ae4..295eaf9f 100644 --- a/introduction/de/03-how-works.asciidoc +++ b/introduction/de/03-how-works.asciidoc @@ -4,7 +4,7 @@ Angenommen, Team A verwendet Software, die von Team B produziert wird. Team A sendet eine Funktionsanforderung an Team B, aber Team B kann diese Funktion nicht rechtzeitig für Team A implementieren. In einer InnerSource Umgebung kann Team A anstatt einer Feature-Anforderung auch alternativ einen PullRequest an Team B zur Integration schicken. Das heißt, Team A implementiert die Funktion direkt in der Software von Team B und sendet einen PullRequest mit den Codeänderungen. -In enger Partnerschaft überprüft Team B dann den übermittelten Code und ggf. akzeptiert die Aenderungen wenn sie den Anforderungen enpricht. +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. @@ -44,4 +44,4 @@ Letzlich steht mehr Zeit für die Erstellung von Code zur Verfügung, der die wi === Zusätzliche Ressourcen -* Die Mustervorlage https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/project-roles/trusted-committer.asciidoc[Trusted Committer]. \ No newline at end of file +* Die Mustervorlage https://github.com/InnerSourceCommons/InnerSourcePatterns/blob/master/project-roles/trusted-committer.asciidoc[Trusted Committer]. From 2e0bf7899428f18579a30613a8bc3e0c946c99f8 Mon Sep 17 00:00:00 2001 From: Johannes Tigges Date: Tue, 17 Mar 2020 13:56:38 +0100 Subject: [PATCH 12/30] Update introduction/de/03-how-works.asciidoc Co-Authored-By: Isabel Drost-Fromm --- introduction/de/03-how-works.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/introduction/de/03-how-works.asciidoc b/introduction/de/03-how-works.asciidoc index 295eaf9f..d1d71927 100644 --- a/introduction/de/03-how-works.asciidoc +++ b/introduction/de/03-how-works.asciidoc @@ -9,7 +9,7 @@ Team B überprüft dann den übermittelten Code, überarbeitet ihn gegebenenfall 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. -In Erwartung der Ankunft ihrer Gäste, sorgen Sie dafür, dass die Dinge sauber in bester Ordnung sind. +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 Funktionen und Räume nutzen, die sich in den öffentlichen Bereichen des Hauses befinden. Es kann ein paar Hausregeln geben, die Sie gebeten werden zu befolgen. From 4112b89b9dd3493cb7bc6d1f89514215b2b34e0a Mon Sep 17 00:00:00 2001 From: Johannes Tigges Date: Tue, 17 Mar 2020 13:57:03 +0100 Subject: [PATCH 13/30] Update introduction/de/03-how-works.asciidoc Co-Authored-By: Isabel Drost-Fromm --- introduction/de/03-how-works.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/introduction/de/03-how-works.asciidoc b/introduction/de/03-how-works.asciidoc index d1d71927..82fdc265 100644 --- a/introduction/de/03-how-works.asciidoc +++ b/introduction/de/03-how-works.asciidoc @@ -11,7 +11,7 @@ Die Begriffe _Guest_ und _Host_ legen eine Situation nahe, die dem Empfang eines 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 Funktionen und Räume nutzen, die sich in den öffentlichen Bereichen des Hauses befinden. +Sie können die Einrichtungen und Räume nutzen, die sich in den öffentlichen Bereichen des Zuhauses befinden. Es kann ein paar Hausregeln geben, die Sie gebeten werden zu befolgen. Ebenso wollen die meisten Gäste Respekt vor dem Zuhause und ihrem Gastgeber zeigen. Sie sind vorsichtig mit den Gegenständen im Haus und folgen den Regeln für die Dauer ihres Aufenthalts. From 9fa4646ebba406bdc73d636c64ad755f1c0ed65c Mon Sep 17 00:00:00 2001 From: Johannes Tigges Date: Tue, 17 Mar 2020 13:59:34 +0100 Subject: [PATCH 14/30] Update introduction/de/03-how-works.asciidoc Co-Authored-By: Isabel Drost-Fromm --- introduction/de/03-how-works.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/introduction/de/03-how-works.asciidoc b/introduction/de/03-how-works.asciidoc index 82fdc265..e32d9b5c 100644 --- a/introduction/de/03-how-works.asciidoc +++ b/introduction/de/03-how-works.asciidoc @@ -12,7 +12,7 @@ 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 Hausregeln geben, die Sie gebeten werden zu befolgen. +Es kann ein paar Regeln geben, um deren Befolgung Gäste gebeten werden. Ebenso wollen die meisten Gäste Respekt vor dem Zuhause und ihrem Gastgeber zeigen. Sie sind vorsichtig mit den Gegenständen im Haus und folgen den Regeln für die Dauer ihres Aufenthalts. Sie können auf eine erneute Einladung hoffen, solange sie sich gut benommen haben und höflich waren. From 0d43b7b37b5ee6b2332ccca6b3ac6de57b9d94e7 Mon Sep 17 00:00:00 2001 From: Johannes Tigges Date: Tue, 17 Mar 2020 13:59:46 +0100 Subject: [PATCH 15/30] Update introduction/de/06-conclusion.asciidoc Co-Authored-By: Isabel Drost-Fromm --- introduction/de/06-conclusion.asciidoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/introduction/de/06-conclusion.asciidoc b/introduction/de/06-conclusion.asciidoc index 69d03add..f2bd1b1b 100644 --- a/introduction/de/06-conclusion.asciidoc +++ b/introduction/de/06-conclusion.asciidoc @@ -4,10 +4,10 @@ Auf 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 eine erforderliche Funktionsanforderung im notwendingen Zeitraum zu liefern. Erfolgreiche InnerSource umfasst 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 betriebene InnerSource bietet beiden teilnehmenden Teams viele Vorteile. +Richtig betriebenes InnerSource bietet beiden teilnehmenden Teams viele Vorteile. Die Schlüsselprinzipien, nach denen gut geführte InnerSource funktioniert, sind *freiwilliger Code-Beitrag* und *priorisierte Schulung/Betreuung*. 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 mit den Entwicklungen in InnerSource und seine besten Praktiken auf dem laufenden bleiben möchten, laden wir Sie herzlich zu den http://innersourcecommons.org [dem InnerSource Commons] ein. Weiterhin betreibt die InnerSource Commons einen Slack-Kanal, eine InnerSource Arbeitsgruppe die sich mit erfolgreichen Zusammenarbeitsmustern 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. \ No newline at end of file +Ihre Teilnahme an den InnerSource Commons ist eine großartige Möglichkeit, um mit den neuesten Entwicklungen in InnerSource auf dem laufenden zu bleiben. From 00a258e6d05d3a0eb728b91f701520facf10f784 Mon Sep 17 00:00:00 2001 From: Johannes Tigges Date: Tue, 17 Mar 2020 14:04:08 +0100 Subject: [PATCH 16/30] Update introduction/de/06-conclusion.asciidoc Co-Authored-By: Isabel Drost-Fromm --- introduction/de/06-conclusion.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/introduction/de/06-conclusion.asciidoc b/introduction/de/06-conclusion.asciidoc index f2bd1b1b..938cf2c8 100644 --- a/introduction/de/06-conclusion.asciidoc +++ b/introduction/de/06-conclusion.asciidoc @@ -7,7 +7,7 @@ Erfolgreiche InnerSource umfasst https://github.com/InnerSourceCommons/InnerSour Richtig betriebenes InnerSource bietet beiden teilnehmenden Teams viele Vorteile. Die Schlüsselprinzipien, nach denen gut geführte InnerSource funktioniert, sind *freiwilliger Code-Beitrag* und *priorisierte Schulung/Betreuung*. -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. +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 mit den Entwicklungen in InnerSource und seine besten Praktiken auf dem laufenden bleiben möchten, laden wir Sie herzlich zu den http://innersourcecommons.org [dem InnerSource Commons] ein. Weiterhin betreibt die InnerSource Commons einen Slack-Kanal, eine InnerSource Arbeitsgruppe die sich mit erfolgreichen Zusammenarbeitsmustern 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. From b998d3d1481c509f1db6583bee6787c3bd264f3c Mon Sep 17 00:00:00 2001 From: Johannes Tigges Date: Tue, 17 Mar 2020 14:05:07 +0100 Subject: [PATCH 17/30] Update introduction/de/06-conclusion.asciidoc Co-Authored-By: Isabel Drost-Fromm --- introduction/de/06-conclusion.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/introduction/de/06-conclusion.asciidoc b/introduction/de/06-conclusion.asciidoc index 938cf2c8..09156b88 100644 --- a/introduction/de/06-conclusion.asciidoc +++ b/introduction/de/06-conclusion.asciidoc @@ -8,6 +8,6 @@ Richtig betriebenes InnerSource bietet beiden teilnehmenden Teams viele Vorteile Die Schlüsselprinzipien, nach denen gut geführte InnerSource funktioniert, sind *freiwilliger Code-Beitrag* und *priorisierte Schulung/Betreuung*. 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 mit den Entwicklungen in InnerSource und seine besten Praktiken auf dem laufenden bleiben möchten, laden wir Sie herzlich zu den http://innersourcecommons.org [dem InnerSource Commons] ein. +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 einen Slack-Kanal, eine InnerSource Arbeitsgruppe die sich mit erfolgreichen Zusammenarbeitsmustern 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. From 78babb9607114fb6dbc1ce1999c414dd8b7bbda9 Mon Sep 17 00:00:00 2001 From: Johannes Tigges Date: Tue, 17 Mar 2020 14:10:56 +0100 Subject: [PATCH 18/30] Update introduction/de/01-introduction.asciidoc Co-Authored-By: Maximilian Capraro --- introduction/de/01-introduction.asciidoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/introduction/de/01-introduction.asciidoc b/introduction/de/01-introduction.asciidoc index 7236e44c..deb037fe 100644 --- a/introduction/de/01-introduction.asciidoc +++ b/introduction/de/01-introduction.asciidoc @@ -2,11 +2,11 @@ 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, kann jedoch von jedem Mitarbeiter des Unternehmens genutzt, verbessert und erweitert werden. +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 produziert 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. \ No newline at end of file +Wir werden außerdem die wichtigsten InnerSource-Prinzipien aufzählen, und Vorteile nennen, die sich bei einer effektiven Anwendung ergeben. From c79f6ee164b99a9f678b9e7c7b37099ec5c1b168 Mon Sep 17 00:00:00 2001 From: Johannes Tigges Date: Tue, 17 Mar 2020 14:11:24 +0100 Subject: [PATCH 19/30] Update introduction/de/01-introduction.asciidoc Co-Authored-By: Maximilian Capraro --- introduction/de/01-introduction.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/introduction/de/01-introduction.asciidoc b/introduction/de/01-introduction.asciidoc index deb037fe..833bd353 100644 --- a/introduction/de/01-introduction.asciidoc +++ b/introduction/de/01-introduction.asciidoc @@ -3,7 +3,7 @@ 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 produziert Software, die sich schnell auf die sich ändernden Anforderungen der verschiedenen internen +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. From dfeb367d9a74e01192dc095397fbe138e22820c4 Mon Sep 17 00:00:00 2001 From: Johannes Tigges Date: Tue, 17 Mar 2020 14:13:05 +0100 Subject: [PATCH 20/30] Update introduction/de/04-benefits.asciidoc Co-Authored-By: Maximilian Capraro --- introduction/de/04-benefits.asciidoc | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/introduction/de/04-benefits.asciidoc b/introduction/de/04-benefits.asciidoc index 80572fd3..2bd244fa 100644 --- a/introduction/de/04-benefits.asciidoc +++ b/introduction/de/04-benefits.asciidoc @@ -10,7 +10,7 @@ Somit kann das Hostteam durch die Anwendung von InnerSourceprinzipien *Hilfe be *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 kombinierten Geschäftspläne 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. +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äss der Priorität des Gastteam 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. @@ -28,4 +28,4 @@ Natürlich ist auch nicht zu vergessen ist, dass sich die Mitwirkenden am Projek Diese positive Erfahrung führt dann dazu, dass sie ihren Kollegen oder ihren neuen Teams dies Projekte empfehlen. Die Mitarbieter des Gastteams verstehen das Projekt besser und können Fragen dazu beantworten, wodurch das Hostteam von dieser 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*. \ No newline at end of file +Letztendlich hift dieses Verhalten und die teamübergreifende Ausrichtung im Laufe der Zeit die *traditionellen Silos in Unternehmen abzubauen*. From 4f44ca7884e3c5d7fce26cd779888a1510dbc89e Mon Sep 17 00:00:00 2001 From: Johannes Tigges Date: Tue, 17 Mar 2020 14:16:21 +0100 Subject: [PATCH 21/30] Update introduction/de/05-principles.asciidoc Co-Authored-By: Maximilian Capraro --- introduction/de/05-principles.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/introduction/de/05-principles.asciidoc b/introduction/de/05-principles.asciidoc index 015414a2..8ba2b64f 100644 --- a/introduction/de/05-principles.asciidoc +++ b/introduction/de/05-principles.asciidoc @@ -2,7 +2,7 @@ Jedes Unternehmen, Team, Projekt und Individuum ist verschieden. Aus diesem Grund variiert die genaue Anwendung der InnerSourcekonzepte von Situation zu Situation. -Im Mittelpunkt stehen in jeden Fall jedoch vier Prinzipien, die das Fundament jeder erfolgreichen Anwendung von InnerSource bilden. +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: From 5d3d3452f45b981785d4460a65243d0dbb97b892 Mon Sep 17 00:00:00 2001 From: Johannes Tigges Date: Tue, 17 Mar 2020 14:27:09 +0100 Subject: [PATCH 22/30] Apply suggestions from code review Co-Authored-By: Maximilian Capraro Co-Authored-By: Isabel Drost-Fromm --- introduction/de/04-benefits.asciidoc | 22 ++++++++--------- introduction/de/05-principles.asciidoc | 34 +++++++++++++------------- introduction/de/06-conclusion.asciidoc | 8 +++--- 3 files changed, 32 insertions(+), 32 deletions(-) diff --git a/introduction/de/04-benefits.asciidoc b/introduction/de/04-benefits.asciidoc index 2bd244fa..1996d57e 100644 --- a/introduction/de/04-benefits.asciidoc +++ b/introduction/de/04-benefits.asciidoc @@ -4,28 +4,28 @@ 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äßige InnerSourcebeiträge erhalten ebenfalls viele Vorteile. -Denken Sie daran, dass der Product Owner im Hostteam im Rahmen des InnerSourceprozesses von Anfang an entscheidet ob die bereitgestellten Funktionen gut und wünschenswert sind für das Project sind. -Somit kann das Hostteam durch die Anwendung von InnerSourceprinzipien *Hilfe bei der Erstellung eines besseren Produkts* für seine Verbraucher erhalten! +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 kombinierten Geschäftspläne der Nutzer zuweilen sehr (oder sogar unangemessen) viel zusätzliche Arbeit für das Hostteam bedeutet. +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äss der Priorität des Gastteam 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 die Entwicklungsaufwand organisch dorthin fließen, wo das Unternehmen es zu einem bestimmten Zeitpunkt benötigt. +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 InnerSourcebeiträge dem Hostteam *bessere Einsicht in Anforderungen und eine bessere Ausrichtung der Prioritäten auf alle seine Nutzer*. +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 ihrer Karriere 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 ist, dass sich die Mitwirkenden am Projekt des Hostteams beteiligt fühlen. -Diese positive Erfahrung führt dann dazu, dass sie ihren Kollegen oder ihren neuen Teams dies Projekte empfehlen. -Die Mitarbieter des Gastteams verstehen das Projekt besser und können Fragen dazu beantworten, wodurch das Hostteam von dieser Teil der Arbeit entlastet wird. +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 index 8ba2b64f..53adacb2 100644 --- a/introduction/de/05-principles.asciidoc +++ b/introduction/de/05-principles.asciidoc @@ -1,7 +1,7 @@ == InnerSource-Prinzipien Jedes Unternehmen, Team, Projekt und Individuum ist verschieden. -Aus diesem Grund variiert die genaue Anwendung der InnerSourcekonzepte von Situation zu Situation. +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. @@ -16,19 +16,19 @@ Schauen wir uns jedes dieser Prinzipien genauer an. === Offenheit -Die Konfiguration eines offenen Projekts ermöglicht reibungslose Teilnahme. +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 Arbiet zu beginnen. -Die Kontaktinformationen des Hostteams sollten in allen Kanälen zur Verfügung stehen die für das Projekt sinnvoll sind. -Die Absichten des Hostteams InnerSourcebeiträge zu seinem Projekt anzunehmen, sollten über relevante Organisationskanäle mitgeteilt werden, um das Bewusstsein darum to erhöhen. -Insbesondere in kleineren Organizations möchten Sie möglicherweise regelmäßig über die InnerSourcearbeit 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. +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. +Je weniger offen es ist, desto schwieriger wird es für jemanden ausserhalb des Hostteams, einen Beitrag zu leisten. === Transparenz @@ -36,12 +36,12 @@ Damit Gastteams einen sinnvollen Beitrag zu einem Projekt leisten können, muss Dies bedeutet, dass Gastteams in der Lage sein sollten, folgendes zu verstehen: * Das Projekt / Repo und seine Ziele -* Noch offene Funktionsanforderungen -* Fortschritte bei den Funktionentwicklungen +* 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. +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 @@ -50,21 +50,21 @@ https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/contri 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 die Schulung für potentielle Contributors vom Hostteam priorisiert wird. +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 Mitarbeiter des Gastteams zu nehmen - ganz speziell zu dem Zeitpunkt zu dem der Mitarbeiter es benötigt - und nicht, wenn es für das Hostteam bequem ist. -Manchmal kann es für Ingenieure im Hostteam ein Kulturwandel sein, Zeit zu investiern um anderen beim Codieren zu helfen, anstatt selbst zu codieren. -Diese Art der Schulung/Betreuung ist sowohl für den einzelnen Mitarbeiter des Gastteams als auch für den Gastgeber wertvoll, und es lohnt sich den Aufwand zu betreiben. +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 Codes bildet oder verbessert der Mitarbeiter die Beziehungen innerhalb einer Organisation, die sonst möglicherweise nicht existiert hätten. +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 erste Wort _Freiwillinger_ bedeutet, dass das Engagement von Gast- und Hostteams in InnerSource aus freiem Willen erfolgt. +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 am Öffnen von Problemenmeldungen, Aktualisieren von Anforderungen, Korrigieren von Dokumenten usw. ist eine gute Sache, jedoch muss die Zusammenarbeit im Endeffekt bis hin zur Code Entwicklung reichen um die oben diskutierten positiven Effekte zu erzielen. +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 index 09156b88..4f5f7831 100644 --- a/introduction/de/06-conclusion.asciidoc +++ b/introduction/de/06-conclusion.asciidoc @@ -1,9 +1,9 @@ -== Schusswort +== Schlusswort -Auf dieser Serie haben wir eine Einführung in InnerSource gegeben. +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 eine erforderliche Funktionsanforderung im notwendingen Zeitraum zu liefern. -Erfolgreiche InnerSource umfasst 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*. +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 funktioniert, sind *freiwilliger Code-Beitrag* und *priorisierte Schulung/Betreuung*. From 2986b077148249821d0492a2d4b3d4bbe126c17e Mon Sep 17 00:00:00 2001 From: Johannes Tigges Date: Tue, 17 Mar 2020 14:31:48 +0100 Subject: [PATCH 23/30] Apply suggestions from code review Co-Authored-By: Maximilian Capraro Co-Authored-By: Isabel Drost-Fromm --- introduction/de/02-problems-solved.asciidoc | 5 +-- introduction/de/03-how-works.asciidoc | 34 ++++++++++----------- 2 files changed, 20 insertions(+), 19 deletions(-) diff --git a/introduction/de/02-problems-solved.asciidoc b/introduction/de/02-problems-solved.asciidoc index f96cfdf2..9d22568b 100644 --- a/introduction/de/02-problems-solved.asciidoc +++ b/introduction/de/02-problems-solved.asciidoc @@ -1,5 +1,6 @@ == Welche Probleme löst InnerSource? -InnerSource fördert und belohnt die Zusammenarbeit und die Wiederverwendung von Code mit jedem, unabhängig von seiner Position in der Organisationsstruktur eines Unternehmens. +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. @@ -36,4 +37,4 @@ InnerSource bietet den Teams die Vorteile der oben beschriebenen Strategien des 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. \ No newline at end of file + 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 index e32d9b5c..77cdc97c 100644 --- a/introduction/de/03-how-works.asciidoc +++ b/introduction/de/03-how-works.asciidoc @@ -13,34 +13,34 @@ Haben sich Gäste angekündigt, sorgen Gastgeber für eine einladende Atmosphär 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. -Ebenso wollen die meisten Gäste Respekt vor dem Zuhause und ihrem Gastgeber zeigen. +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. -Sie können auf eine erneute Einladung hoffen, solange sie sich gut benommen haben und höflich waren. -Diese Konzepte rund um einen Hausbesuch sind eine Metapher für die Einstellung und das Verhalten das Teams an den Tage legen sollten wenn der eine der Gastgeber (Host) ist, und der andere ein Gast (Contributor) ist der einen Gastbeitrag (Contribution) zur Codebasis leistet. +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. -Befor wir in das Thema tiefer einsteigen, lassen sie uns einige wichtige Rollen in den Gast- und Gastgeberteams vorstellen. -Zunächst bestimmt https://github.com/InnerSourceCommons/InnerSourceLearningPath/blob/master/product-owner/01-opening-article.asciidoc[_Product Owner_], welche Funktionen das Hostteam als Beitrag zu akzeptieren bereit ist. +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, eingfacheren Projekten füllt oft eine einzelne Person _sowohl_ die Rolle des Produktbesitzers als auch die des Trusted Committer aus. +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 Definitionen folgt nun der eine grobe Skizze des InnerSource-Prozesses. +Basierend auf diesen Rollen können wir nun den InnerSource-Prozesses grob skizzieren. -* Gastteam oder ein Mitglied des Gastteams fragt eine Funktion vom Host-Team an. -* Der Produktbesitzer stellt sicher, dass die Featureanforderungen gemaess des Entwicklungsprozzesses des Hostteams erstellt werden, entweder von Mitgliedern des Gastteams oder Mitgliedern des Gastgeberteams. -Diese Documentation geschieht meist in der Form von Userstories, welche die gewünschte Funktion und Rahmenbedingungen beschreiben, die das Gastteam akzeptiert hat. -Sie listet auch alle Details aus Sicht des Host-Teams auf, z.B. wie eine Funktion geschrieben und eingereicht werden soll damit der Code akzeptiert werden kann. -Beispiele für solche Details sind Architektureinschränkungen, Codierungskonventionen, Abhängigkeitsverwendungen, Datenverträge usw. -* Unterstützt vom vertrauenswürdigen Committer, sendet der Mitwirkende den PullRequest, um die angefragte Funktion zu implementieren. +* 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. -Beachten Sie, dass bei diesen Schritten kein bestimmtes System für die allgemeine Organisation der Zeit oder der Prioritäten eines Teams angenommen 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 funktioniert gut für das Gastteam, da es die Funktionalität erhält die es benötigt, wenn sie sie benötigt, und ohne die Notwendigkeit die langfristige Wartung der Lösung zu übernehmen. +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 Verfuegung gestellt werden. -Letzlich steht mehr Zeit für die Erstellung von Code zur Verfügung, der die wirklichen Unternehmensprobleme löst, anstatt sie zur Verhandlung über Features oder für Eskalationsprozesse zu verwenden. +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 From bed0dfaed2011dab8889b31d8adba1d5230383f0 Mon Sep 17 00:00:00 2001 From: Arno M Date: Wed, 1 Apr 2020 18:00:14 -0700 Subject: [PATCH 24/30] Update introduction/de/06-conclusion.asciidoc Co-Authored-By: Isabel Drost-Fromm --- introduction/de/06-conclusion.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/introduction/de/06-conclusion.asciidoc b/introduction/de/06-conclusion.asciidoc index 4f5f7831..67fd600b 100644 --- a/introduction/de/06-conclusion.asciidoc +++ b/introduction/de/06-conclusion.asciidoc @@ -5,7 +5,7 @@ InnerSource wendet Open Source Praktiken und Prinzipien auf die firmeninterne So 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 funktioniert, sind *freiwilliger Code-Beitrag* und *priorisierte Schulung/Betreuung*. +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. From 311ee8b966987164e7c75b66fc6c9bd9c71833d0 Mon Sep 17 00:00:00 2001 From: Arno M Date: Wed, 1 Apr 2020 18:01:12 -0700 Subject: [PATCH 25/30] Update introduction/de/06-conclusion.asciidoc Co-Authored-By: Isabel Drost-Fromm --- introduction/de/06-conclusion.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/introduction/de/06-conclusion.asciidoc b/introduction/de/06-conclusion.asciidoc index 67fd600b..96931c2b 100644 --- a/introduction/de/06-conclusion.asciidoc +++ b/introduction/de/06-conclusion.asciidoc @@ -9,5 +9,5 @@ Die Schlüsselprinzipien, nach denen gut geführte InnerSource Projekte funktion 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 einen Slack-Kanal, eine InnerSource Arbeitsgruppe die sich mit erfolgreichen Zusammenarbeitsmustern befasst, und veranstaltet jedes Jahr mehrere Treffen. +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. From 44d2f0fc760d90858a4e83714203dc0d17663d52 Mon Sep 17 00:00:00 2001 From: Arno M Date: Wed, 1 Apr 2020 18:01:54 -0700 Subject: [PATCH 26/30] Update introduction/de/01-introduction.asciidoc Co-Authored-By: Maximilian Capraro --- introduction/de/01-introduction.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/introduction/de/01-introduction.asciidoc b/introduction/de/01-introduction.asciidoc index 833bd353..8c9fda88 100644 --- a/introduction/de/01-introduction.asciidoc +++ b/introduction/de/01-introduction.asciidoc @@ -1,7 +1,7 @@ == 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. +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. From dbfc4fe3aeaec85190640af0c45db6920354e563 Mon Sep 17 00:00:00 2001 From: Arno M Date: Wed, 1 Apr 2020 18:08:51 -0700 Subject: [PATCH 27/30] Update introduction/de/04-benefits.asciidoc Co-Authored-By: Maximilian Capraro --- introduction/de/04-benefits.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/introduction/de/04-benefits.asciidoc b/introduction/de/04-benefits.asciidoc index 1996d57e..94237037 100644 --- a/introduction/de/04-benefits.asciidoc +++ b/introduction/de/04-benefits.asciidoc @@ -12,7 +12,7 @@ Somit kann das Hostteam durch die Anwendung von InnerSource-Prinzipien *Hilfe b 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äss der Priorität des Gastteam erbracht. +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. From 897421c7050791c01715d17bd42f309c52553cd2 Mon Sep 17 00:00:00 2001 From: Arno M Date: Wed, 1 Apr 2020 18:25:29 -0700 Subject: [PATCH 28/30] Update introduction/de/03-how-works.asciidoc Co-Authored-By: Maximilian Capraro --- introduction/de/03-how-works.asciidoc | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/introduction/de/03-how-works.asciidoc b/introduction/de/03-how-works.asciidoc index 77cdc97c..1723db19 100644 --- a/introduction/de/03-how-works.asciidoc +++ b/introduction/de/03-how-works.asciidoc @@ -1,8 +1,8 @@ == Wie funktioniert InnerSource? -Angenommen, Team A verwendet Software, die von Team B produziert wird. -Team A sendet eine Funktionsanforderung an Team B, aber Team B kann diese Funktion nicht rechtzeitig für Team A implementieren. -In einer InnerSource Umgebung kann Team A anstatt einer Feature-Anforderung auch alternativ einen PullRequest an Team B zur Integration schicken. +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. From 50fb60889c723248a9a8a7468e4be2e8423e32f5 Mon Sep 17 00:00:00 2001 From: Arno Mihm Date: Wed, 1 Apr 2020 18:36:49 -0700 Subject: [PATCH 29/30] Fixed per maxcapraro's comment/suggestion #Pleas enter the commit message for your changes. Lines starting --- introduction/de/05-principles.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/introduction/de/05-principles.asciidoc b/introduction/de/05-principles.asciidoc index 53adacb2..5ce90b52 100644 --- a/introduction/de/05-principles.asciidoc +++ b/introduction/de/05-principles.asciidoc @@ -9,7 +9,7 @@ Die Prinzipien sind: * *Offenheit* * *Transparenz* -* *Priorisierte Betreuung* +* *Focus auf Mentoring* * *Freiwilliger Codebeitrag* Schauen wir uns jedes dieser Prinzipien genauer an. From 4608b8999e44248a887e27626cf3f76b9e2df444 Mon Sep 17 00:00:00 2001 From: Johannes Tigges Date: Thu, 2 Apr 2020 19:30:03 +0200 Subject: [PATCH 30/30] Update introduction/de/05-principles.asciidoc Co-Authored-By: Isabel Drost-Fromm --- introduction/de/05-principles.asciidoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/introduction/de/05-principles.asciidoc b/introduction/de/05-principles.asciidoc index 5ce90b52..631e40cb 100644 --- a/introduction/de/05-principles.asciidoc +++ b/introduction/de/05-principles.asciidoc @@ -51,7 +51,7 @@ Dabei lernen sie die Software des Hostteams sowohl als genereller Nutzer als auc 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 Mitarbeiter des Gastteams zu nehmen - ganz speziell zu dem Zeitpunkt zu dem der Mitarbeiter es benötigt - und nicht, wenn es für das Hostteam bequem ist. +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.