Author: mbarkhau
Date: Sat Aug 11 16:25:59 2007
New Revision: 952
Log:
Review ch02 up to "opening closed projects"
Modified:
trunk/de/ch02.xml
Modified: trunk/de/ch02.xml
==============================================================================
--- trunk/de/ch02.xml (original)
+++ trunk/de/ch02.xml Sat Aug 11 16:25:59 2007
@@ -1243,328 +1243,324 @@
<!-- ======================== subsection ============================== -->
<sect2 id="avoid-private-discussions">
-<title>Vermeiden Sie Private Diskussionen</title>
+<title>Vermeide private Diskussionen</title>
<para>Selbst nachdem Sie ein Projekt an die Öffentlichkeit gebracht
-haben, werden Sie und die anderen Gründungsmitglieder manchmal in
-der Lage sein, schwierige Fragen innerhalb eines kleineren Kreises
-durch private Kommunikation lösen zu wollen. Dies gilt besonders für
-die anfangs Tage des Projekts, bei denen es viele wichtige
-Entscheidungen gibt und für gewöhnlich gibt es nur wenige Freiwillige
-die qualifiziert sind sie zu treffen. All die offensichtlichen
-Nachteile öffentlicher Diskussionen, auf Mailing listen, werden
-greifbar vor Ihnen liegen: Die Verzögerung die bei Email Diskussionen
-unvermeidbar ist, die Zeit die erforderlich ist, damit eine Konsens
-gebildet werden kann, die mühe sich mit naiven Freiwilligen
-auseinandersetzen zu müssen, die meinen sie verstünden alle
-Angelegenheiten es aber nicht tun(diese gibt es in jedem Projekt;
-manchmal bringen sie im nächsten Jahr die besten Beiträge, manchmal
-bleiben sie ewig naiv), die Person die nicht versteht, warum Sie nur
-das Problem X lösen wollen, wenn es offensichtlich eine Untermenge
-des größeren Problems Y ist, und so weiter. Die Verlockung diese
-Unterhaltungen hinter geschlossenen Türen zu führen und sie als
-vollendete Tatsache zu präsentieren oder zumindest als nachdrückliche
-Empfehlung einer vereinigten und einflussreichen Wählerkreises, wird
-gewiss groß sein.</para>
-
-<para>Machen Sie es Nicht.</para>
-
-<para>So langsam und mühselig öffentliche Diskussionen auch sein
-mögen sind sie auf lange Sicht immer noch vor zu ziehen. Wichtige
-Entscheidungen privat zu treffen, ist analog zum Versprühen von
-einem Abwehrmittel gegen Freiwillige. Kein Freiwilliger der die Sache
-ernst meint, würde lange in einer Umgebung bleiben, in dem alle
-wichtigen Entscheidungen in einer geheimen Versammlung getroffen
-werden. Desweiteren hat die öffentliche Diskussion den Vorteil, dass
-sie viel länger bestehen wird als die kurzlebige Technische Frage
-um die es ging:
+haben, werden Sie und die anderen Gründungsmitglieder sich manchmal in
+der Lage vorfinden, schwierige Fragen innerhalb eines kleineren Kreises
+durch private Kommunikation lösen zu wollen. Das gilt besonders für die
+Anfangstage des Projekts, bei denen es viele wichtige Entscheidungen
+gibt und für gewöhnlich nur wenige Freiwillige die qualifiziert sind
+sie zu treffen. All die offensichtlichen Nachteile öffentlicher
+Diskussionen, auf E-Mail Verteiler, werden greifbar vor Ihnen liegen:
+Die bei E-Mail Diskussionen unvermeidbare Verzögerung, die für einen
+Konsens erforderliche Zeit, die Mühe sich mit naiven Freiwilligen
+auseinandersetzen zu müssen, die meinen alles zu verstehen (diese gibt
+es in jedem Projekt; manchmal bringen sie im nächsten Jahr die besten
+Beiträge, manchmal bleiben sie ewig naiv), die Person die nicht
+versteht, warum Sie nur das Problem X lösen wollen, wenn es
+offensichtlich eine Untermenge des größeren Problems Y ist, usw. Die
+Verlockung diese Unterhaltungen hinter verschlossenen Türen zu führen
+und sie als vollendete Tatsache zu präsentieren oder zumindest als
+nachdrückliche Empfehlung einer vereinigten und einflussreichen
+Wählergruppe, wird gewiss groß sein.</para>
+
+<para>Mache Sie es Nicht.</para>
+
+<para>So langsam und mühselig öffentliche Diskussionen auch sein mögen,
+sie sind auf lange Sicht immer noch vorzuziehen. Wichtige
+Entscheidungen privat zu treffen, ist analog zum Versprühen von
+Pestizide gegen Freiwillige. Kein Freiwilliger der seine Sache ernst
+meint, würde lange in einer Umgebung bleiben, in dem alle wichtigen
+Entscheidungen von einer geheimen Versammlung getroffen werden.
+Desweiteren hat die öffentliche Diskussion den Vorteil, dass ihre
+positiven Nebenwirkungen sie viel länger fortbesteht als die kurzlebige
+technische Frage um die es geht:
<itemizedlist>
<listitem>
- <para>Die Diskussion wird dabei helfen neue Entwickler zu trainieren
- und zu belehren. Sie können nie wissen wie viele Augen auf die
- Diskussion schauen; selbst wenn die Meisten sich nicht
- beteiligen, kann es sein das viele es im stillen mit verfolgen,
+ <para>Die Diskussion wird dabei helfen neue Entwickler auszubilden
+ und zu unterrichten. Sie können nie wissen wie viele Augen die
+ Diskussion beobachten; selbst wenn die Meisten sich nicht
+ beteiligen, kann es sein das Viele es im Stillen mitverfolgen,
um Informationen über das Projekt zu sammeln.</para>
</listitem>
<listitem>
- <para>Die Diskussion wird <emphasis>Sie</emphasis> in der Kunst
- trainieren, technische Angelegenheiten für Leute zu erklären
- die mit der Software nicht so vertraut sind wie Sie. Dies ist
- eine Fähigkeit, die Übung erfordert und Sie können sie nicht
- erlangen, indem Sie mit denen reden, die bereits das wissen,
- was Sie wissen.</para>
+ <para>Bei der Diskussion werden <emphasis>Sie</emphasis> die Kunst
+ lernen, technische Angelegenheiten für Leute zu erklären die
+ mit der Software nicht so vertraut sind wie Sie. Das ist eine
+ Fähigkeit, die Übung erfordert und Sie können sie nicht
+ erlangen, indem Sie mit Leuten reden die genau soviel wissen
+ wie Sie.</para>
</listitem>
<listitem>
<para>Die Diskussion und Ihre Ergebnisse werden auf ewig in den
öffentlichen Archiven verfügbar sein und es zukünftige
Diskussionen ermöglichen Wiederholungen zu vermeiden. Siehe
- <xref linkend="using-archives"/><phrase output="printed">
- im Kapitel<xref linkend="communications"/></phrase>.</para>
+ <xref linkend="using-archives"/><phrase output="printed"> im
+ Kapitel<xref linkend="communications"/></phrase>.</para>
</listitem>
</itemizedlist>
</para>
-<para>Zuletzt gibt es noch die Möglichkeit, dass jemand auf der Liste
-einen echten Beitrag zu der Diskussion leisten kann, in dem er eine
-Idee an der Sie nie gedacht hätten aufbringt. Es ist schwer zu sagen,
-wie wahrscheinlich dies ist; es hängt einfach nur von der Komplexität
-des Problems und den erforderlichen Kenntnissen ab. Wenn ich aber ein
-Beispiel heranführen darf, würde ich es wagen zu behaupten, dass es
-viel wahrscheinlicher ist, als man es intuitiv erwarten würde. Im
+<para>Zuletzt gibt es noch die Möglichkeit, dass jemand auf dem
+Verteiler einen echten Beitrag zu der Diskussion leisten könnte, indem
+er eine Idee aufbringt, an der Sie nie gedacht hätten. Es ist schwer zu
+sagen, wie wahrscheinlich das ist; es hängt schlicht und einfach davon
+ab, wie komplex das Problem ist und den erforderlichen Kenntnissen ab.
+Wenn ich aber ein Beweis heranführen darf, wage ich zu behaupten, dass
+es viel wahrscheinlicher ist, als man es intuitiv erwarten würde. Im
Subversion Projekt, glaubten wir (die Gründer) mit einer tiefen und
komplexen Reihe von Problemen konfrontiert zu sein, über die wir uns
seit ein paar Monaten viele Gedanken gemacht hatten, und offen gesagt
-zweifelten wir daran, dass irgendjemand auf der neulich eingerichteten
-Mailing Liste etwas wertvolles zu der Diskussion beitragen könnte. Wir
-nahmen also den einfachen Weg und fingen damit an unsere technischen
-Ideen in privaten Emails hin und her zu schlagen, bis ein Beobachter
-des Projekts <footnote><para>We haven't gotten to the section on
-crediting yet, but just to practice what I'll later preach: the
-observer's name was Brian Behlendorf, and it was he who pointed out
-the general importance of keeping all discussions public unless there
-was a specific need for privacy.</para></footnote> davon Wind bekam,
-und uns darum bat, die Diskussion auf die öffentliche Liste zu
-verlagern. Ein wenig die Augen verdrehend, taten wir es-und waren
-erstaunt, mit der Anzahl aufschlussreicher Kommentare und Vorschläge
-die schnell daraus resultierten. In vielen Fällen boten Leute Ideen
-an die uns nie in den Sinn gekommen waren. Es stellte sich heraus,
-dass es ein paar <emphasis>sehr</emphasis> schlaue Leute auf dieser
-Mailing liste waren; sie hatten nur auf den richtigen Köder gewartet.
-Es ist wahr, dass die resultierenden Diskussionen länger dauerten als
-wenn wir die Diskussion privat gehalten hätten, allerdings waren sie
-so viel produktiver, dass die zusätzliche Zeit durchaus wert waren.
-</para>
-
-<para>Ohne in all zu verallgemeinernde Aussagen wie "Die Gruppe ist
-immer schlauer als der Einzelne" herab zu gleiten(wir sind alle genug
-Gruppen begegnet, um es besser zu wissen), muss man doch anerkennen,
-dass es bestimmte Aktivitäten gibt, bei denen Gruppen herausragend
-sind. Ausführliche Beurteilung durch gleichrangige (Peer Review)
-ist einer von ihnen; die schnelle Generierung vieler Ideen ist eine
-Andere. Die Qualität dieser Ideen hängt natürlich von der Qualität der
-Gedanken die in sie hinein gesteckt wurden ab, Sie werden aber nie
-erfahren, welche Denker da draußen sind, wenn Sie sie nicht mit einem
-herausforderndem Problem stimulieren.</para>
-
-<para>Natürlich, gibt es auch Diskussionen die im privaten geführt
-werden müssen; im Buch werden wir durchwegs Beispiele hierfür finden.
-Das leitende Prinzip sollte aber sein:<emphasis>Wenn es keine Grund
-gibt es privat zu halten, sollte es öffentlich sein.</emphasis></para>
-
-<para>Sie müssen aber Einfluss üben um dies in gang zu setzen. Es
-reicht nicht bloß sicher zu stellen, dass Ihre eigen Nachrichten an
-die öffentliche Liste gehen. Sie müssen auch andere dazu bewegen ihre
-unnötigerweise privat gehaltene Unterhaltungen öffentlich zu machen.
-Wenn jemand versucht eine private Diskussion zu starten, und es keinen
-Grund gibt sie privat zu halten, sollten Sie sich verpflichtet fühlen
-sofort eine angemessene übergeordnete Diskussion zu eröffnen. Sie
-sollten nicht ein mal direkt auf das Thema eingehen, bevor Sie nicht
-entweder die Diskussion erfolgreich an einem Öffentlichen Ort gelenkt
-haben oder sichergestellt haben, dass sie doch privat gehalten werden
-sollte. Wenn Sie konsequent so vorgehen, werden Leute es ziemlich
-schnell mitbekommen und standardmäßig die öffentlichen Foren benutzen.
-</para>
+zweifelten wir daran, dass irgendjemand auf dem kürzlich eingerichteten
+E-Mail Verteiler etwas wertvolles zu der Diskussion beizutragen hatte.
+Wir nahmen also den einfachen Weg und fingen an unsere technischen
+Ideen in private E-Mails unter einander auszutauschen, bis ein
+Beobachter des Projekts<footnote><para>Wir haben zwar noch nicht das
+Thema der Namensnennung und Anerkennung, aber um auch zu praktizieren
+was ich später predigen werde: Der Name des Beobachters war Brian
+Behlendorf, und er war es der darauf hingedeutet hat wie wichtig es
+ist, alle Diskussionen öffentlich zu halten, es sei denn es gibt einen
+bestimmten Grund für Geheimhaltung.</para></footnote> davon Wind bekam,
+und uns bat, die Diskussion auf den öffentlichen Verteiler zu
+verlagern. Mit ein klein wenig verdrehten Augen, taten wir es—und
+waren völlig erstaunt über die Anzahl aufschlussreicher Kommentare und
+Vorschläge die schnell daraus resultierten. In vielen Fällen boten
+Leute Ideen an die uns nie in den Sinn gekommen waren. Es stellte sich
+heraus, dass ein paar <emphasis>sehr</emphasis> kluge Köpfe auf diesem
+Verteiler waren; sie hatten nur auf den richtigen Köder gewartet. Es
+ist wahr, dass die resultierenden Diskussionen länger dauerten als wenn
+wir sie privat gehalten hätten, allerdings waren sie so viel
+produktiver, dass es die zusätzliche Zeit in jedem Fall wert war.</para>
+
+<para>Ohne in allzu verallgemeinernde Aussagen wie "Die Gruppe ist
+immer schlauer als der Einzelne" abzugleiten (wir kennen alle genügend
+Gruppen, um es besser zu wissen), muss man doch anerkennen, dass es
+bestimmte Aktivitäten gibt, bei denen Gruppen herausragend sind.
+Ausführliche Gutachten ist eine; schnelle auf viele Ideen zu kommen ist
+eine Weitere. Die Qualität dieser Ideen hängt natürlich davon ab wie
+hochwertig die Gedanken waren die man hineingesteckt hat. Sie werden
+aber nie erfahren, was für geistreiche Denker da draußen sind, wenn Sie
+ihnen keine Herausforderung geben.</para>
+
+<para>Es gibt natürlich auch Diskussionen die man im privaten führen
+muss; hierfür gibt es im ganzen Buch Beispiele. Das Leitprinzip sollte
+aber sein: <emphasis>Wenn es kein Grund gibt es privat zu halten,
+sollte es öffentlich sein.</emphasis></para>
+
+<para>Um das in Gang zu setzen, müssen Sie aber Einfluss üben. Es
+reicht nicht lediglich sicherzustellen, dass Ihre eigen Nachrichten an
+den öffentlichen Verteiler gehen; Sie müssen auch andere dazu bewegen
+ihre unnötig private Unterhaltungen öffentlich zu halten. Wenn jemand
+versucht eine private Diskussion anzufangen, und es keinen Grund gibt
+sie privat zu halten, sollten Sie sich verpflichtet fühlen sofort eine
+angemessene übergeordnete Diskussion zu eröffnen. Sie sollten nicht
+einmal direkt auf das Thema eingehen, bevor Sie nicht entweder die
+Diskussion erfolgreich an einem öffentlichen Ort gelenkt haben oder
+sichergestellt haben, dass sie doch privat gehalten werden sollte. Wenn
+Sie sich konsequent so verhalten, werden Leute es ziemlich schnell
+mitbekommen und gleich die öffentlichen Foren benutzen.</para>
</sect2>
<!-- ======================== subsection ============================== -->
<sect2 id="prevent-rudeness">
-<title>Ersticken Sie Unhöflichkeit im Keim</title>
+<title>Unhöflichkeit im Keim ersticken</title>
-<para>Von Anfang der öffentlichen Existenz Ihres Projektes an, sollten
-Sie keine Toleranz für unhöfliches oder beleidigendes Verhalten in
-seinen Foren zeigen. Keine Toleranz heißt nicht unbedingt die
-technische Durchsetzung, Sie müssen nicht diese Leute von der Mailing
-Liste entfernen wenn Sie einen anderen Teilnehmer "flamen" oder ihnen
-den commit Zugriff entziehen weil sie abfällige Bemerkungen gemacht
-haben. (Theoretisch, werden Sie eventuell auf solche Mittel zurück
-greifen müssen, aber erst nachdem alle anderen Mittel erschöpft sind-
-was per Definition, am Anfang eines Projekts noch nicht der Fall ist.)
-Keine Toleranz bedeutet einfach niemals schlechtes Benehmen unbemerkt
-vorbei gehen zu lassen. Zum Beispiel, wenn jemand eine technische
-Bemerkung, gemischt mit einem Angriff <foreignphrase>ad hominem
-</foreignphrase> gegen einem anderen Entwickler, ist es zwingend
-notwendig, dass ihre Reaktion als <emphasis>erstes</emphasis> den
-Angriff <foreignphrase>ad hominem</foreignphrase> angeht, als separate
-Angelegenheit und erst dann auf den technischen Inhalt eingeht.</para>
+<para>Sie sollten von Anfang an, gleich nachdem Ihr Projekte an die
+öffentlichen geht, null Toleranz gegenüber unhöfliches oder
+beleidigendes Verhalten in ihren Foren zeigen. Keine Toleranz heißt
+nicht unbedingt eine technische Durchsetzung, Sie müssen diese Leute
+von dem Verteiler entfernen wenn Sie einen anderen Teilnehmer "flamen"
+oder ihnen den Commit-Zugriff entziehen weil sie abfällige Bemerkungen
+gemacht haben. (Theoretisch, müssten Sie eventuell auf solche Mittel
+zurückgreifen, aber erst nachdem alle Anderen erschöpft sind—was
+am Anfang eines Projekts per Definition, noch nicht der Fall ist.) Null
+Toleranz bedeutet einfach niemals schlechtes Benehmen unbemerkt
+vorbeiziehen zu lassen. Wenn jemand zum Beispiel eine technische
+Bemerkung, zusammen mit einem <foreignphrase>argumentum ad
+hominem</foreignphrase> gegen einem anderen Entwickler, ist es zwingend
+notwendig, dass Ihre Reaktion als <emphasis>erstes</emphasis> den
+persönlichen Angriff anspricht, als separate Angelegenheit und erst
+dann auf den technischen Inhalt eingeht.</para>
-<para>Leider ist es sehr leicht und all zu üblich, dass konstruktive
+<para>Leider ist es sehr leicht und allzu üblich, dass konstruktive
Diskussionen in destruktive "flame wars" ausarten. Menschen werden
Sachen sagen die sie nie von Angesicht zu Angesicht sage würden. Die
Themen dieser Diskussionen verstärken nur diesen Effekt: Bei
technischen Angelegenheiten, fühlen Menschen oft, dass es nur eine
richtige Antwort zu den meisten Fragen gibt und dass eine
-Meinungsverschiedenheit zu dieser Antwort nur durch die Ignoranz oder
+Meinungsverschiedenheit zu ihrer Antwort nur durch die Ignoranz oder
Dummheit des Anderen erklärt werden kann. Es ist ein kurzer Weg den
-technischen Vorschlag einer Person bescheuert zu nennen bis zu die
-Person selber bescheuert zu nennen. Tatsächlich ist es oft schwer zu
-unterscheiden, wo die technische Diskussion aufhört und der Angriff
-auf den Charakter anfängt, was auch ein Grund ist weshalb drastische
-Maßnahmen oder Bestrafungen keine gute Idee sind. Statt dessen, wenn
-Sie es auftreten sehen, schreiben Sie eine Nachricht die nachdrücklich
-darauf hinweist wie wichtig es ist die Unterhaltung in einem
-freundlichen Ton zu halten, ohne dabei jemand zu beschuldigen
-absichtlich giftig gewesen zu sein. Solche "Guter Bulle" Nachrichten
-neigen unglücklicherweise dazu sich nach einer Vorschullehrerin die
-eine Klasse über gutes Benehmen belehrt anzuhören:</para>
+technischen Vorschlag einer Person als bescheuert zu bezeichnen bis man
+die Person selber bescheuert nennt. Tatsächlich ist es oft schwer zu
+unterscheiden, wo die technische Diskussion aufhört und die persönliche
+Beleidigung anfängt, was auch ein Grund ist warum drastische Maßnahmen
+oder Bestrafungen nicht angebracht sind. Sie sollten statt dessen wenn
+Sie darauf stoßen, eine Nachricht schreiben die nachdrücklich darauf
+hinweist wie wichtig es ist die Unterhaltung in einem freundlichen Ton
+zu führen, ohne dabei jemand zu beschuldigen absichtlich giftig gewesen
+zu sein. Leider hören sich diese "Guter Bulle" Nachrichten meistens
+wie die Predigt einer Vorschullehrerin an, die ihre Klasse über gutes
+Benehmen belehrt:</para>
<blockquote>
- <para><emphasis>Als erstes lasst uns bitte mit den unter
- Umständen gegen andere gerichtete Bemerkungen aufhören;
- zum Beispiel den Entwurf der Sicherheitsschicht von J als
- "naiv und ignorant gegenüber den Grundprinzipien der
- Computer Sicherheit" zu bezeichnen. Das mag stimmen oder auch
- nicht, in jedem Fall ist es aber keine Art eine Diskussion zu
- führen. J hat seinen Vorschlag mit guter Absicht getan. Wenn
- es Fehler aufweist, weise darauf hin und wir werden sie
- beheben oder einen neuen Entwurf finden. Ich denke M hatte
- recht als er sagte, dass...</emphasis></para>
+ <para><emphasis>Lasst uns bitte zuerst mit den u.U. ad hominem
+ Bemerkungen aufhören; den Entwurf der Sicherheitsschicht von J
+ als "naiv und ignorant gegenüber allen Grundprinzipien der
+ Sicherheit in der Informatik" zu bezeichnen. Ob das so stimmet
+ oder nicht, es ist in jedem Fall keine Art eine Diskussion zu
+ führen. J hat seinen Entwurf mit guter Absicht vorgeschlagen.
+ Wenn es Fehler aufweist, weise darauf hin und wir werden sie
+ beheben oder einen neuen Entwurf suchen. Ich bin mir sicher, dass
+ M niemand persönlich beleidigen wollte, aber er hat sich
+ unglücklich ausgedrückt, und wie versuchen hier konstrutiv zu
+ bleiben.</emphasis></para>
+
+ <para><emphasis>Und jetzt zu dem Entwurf. Ich denke M hatte recht
+ als er sagte, dass...</emphasis></para>
</blockquote>
-<para>So gestelzt sich solche Antworten auch anhören, haben sie doch
-einen bemerkbaren Effekt. Wenn Sie beständig auf solches Verhalten
-hin deuten aber keine Entschuldigung verlangen von der angreifenden
-Partei fordern, lassen Sie ihnen die Möglichkeit sich ab zu regen und
-ihre bessere Seite zu zeigen, indem sie sich das nächste mal
-anständiger benehmen-und sie werden es. Einer der Geheimnisse
-erfolgreich gegen solches Verhalten vor zu gehen, ist niemals die
-untergeordnete Diskussion zum Hauptthema werden zu lassen. Es sollte
-immer nur ein neben Thema bleiben, ein kurzes Vorwort zum Hauptteil
-Ihrer Antwort. Weisen Sie im vorbeigehen darauf hin dass "wir schen
-hier nicht so erledigen", aber gehen Sie dann weiter zum echten
-Inhalt, damit Sie Leuten immer etwas was zum Thema gehört, worauf sie
-Antworten können geben. Wenn jemand Protest einlegt, dass sie die
-Zurechtweisung zu unrecht ausgesprochen wurde, sollten Sie sich nicht
-zu einen Streit darüber verleiten lassen. Antworten Sie entweder nicht
-darauf (wenn Sie denken sie wollen nur Dampf ab lassen und keine
-Antwort erfordern), oder entschuldigen Sie sich für die Übertriebene
-Reaktion und das es schwer ist Nuancen in einer Email heraus zu lesen
-und gehen Sie dann wieder auf das Hauptthema ein. Bestehen Sie niemals
-auf eine Antwort, ob Privat oder Öffentlich, von jemand der sich
-unangemessen benommen hat. Wenn sie sich von alleine entscheiden sich
-zu entschuldigen, großartig, aber es von ihnen zu verlangen würde nur
-Bitterkeit verursachen.</para>
-
-<para>Das übergeordnete Ziel ist gute Umgangsformen als eine Verhalten
-der inneren Gruppe gesehen werden. Das hilft dem Projekt, da Entwickler
-durch "flame wars" vertrieben werden können (selbst von Projekten die
-sie mögen und unterstützen). Es mag sein das Sie nicht ein mal wissen,
-dass sie vertrieben wurden; es kann sein das sich jemand auf der
-Mailing Liste herumtreibt und bemerkt, dass man eine dicke Haut braucht,
-um an dem Projekt teil zu nehmen und sich dagegen entscheiden sich
-daran zu beteiligen. Foren freundlich zu halten ist auf lange Sicht
-eine Überlebensstrategie und es ist einfacher zu machen, wenn ein
-Projekt noch klein ist. Wenn es einmal ein Teil der Kultur ist, werden
-Sie nicht der einzige sein der sich bemüht. Das Verhalten wird von jedem
-gepflegt werden.</para>
+<para>So gestelzt sich solche Antworten auch anhören, sie haben doch
+eine messbare Wirkung. Wenn Sie immer wieder auf solches Verhalten
+hindeuten aber keine Entschuldigung von der angreifenden Partei
+fordern, lassen Sie ihnen die Möglichkeit sich abzuregen und ihre
+bessere Seite zu zeigen, indem sie sich beim nächsten mal anständiger
+benehmen—und das werden sie. Einer der Geheimnisse erfolgreich
+gegen solches Verhalten vorzugehen, ist niemals die untergeordnete
+Diskussion zum Hauptthema werden zu lassen. Es sollte immer nur
+nebenbei erwähnt werden, ein kurzes Vorwort Ihrer eigentlichen Antwort.
+Weisen Sie im vorbeigehen darauf hin dass "die Sachen anders laufen",
+aber gehen Sie dann weiter zum echten Inhalt, damit Leuten immer zum
+Thema haben, worauf sie Antworten können. Wenn jemand Protest einlegt,
+dass sie die zu Unrecht zurechtgewiesen wurde, sollten Sie sich nicht
+in ein Streit verzetteln lassen. Antworten Sie entweder garnicht (wenn
+Sie denken die Person will nur Dampf ablassen und es ist keine Antwort
+erforderlich), oder entschuldigen Sie sich für die Übertriebene
+Reaktion und das es schwer ist Nuancen in einer E-Mail herauszulesen
+und gehen Sie dann wieder auf das eigentliche Thema ein. Bestehen Sie
+niemals auf eine Antwort, privat oder öffentlich, von jemand der sich
+unangemessen verhalten hat. Wenn sie sich von alleine entschuldigen,
+ist das großartig, aber es von ihnen zu verlangen würde nur
+Verbitterung heraufbeschwören.</para>
+
+<para>Das übergeordnete Ziel ist dass gute Umgangsformen zu einem
+wesentlichen Merkmal der der inneren Gruppe wird. Das hilft dem
+Projekt, da Entwickler durch "flame wars" vertrieben werden können
+(sogar von Projekten die sie mögen und unterstützen). Es kann
+passieren, dass Sie ihre Vertreibung nicht einmal mittbekommen; wenn
+sich jemand auf dem Verteiler umschaut und mitkriegt was für eine dicke
+Haut man braucht um an dem Projekt teilzunehmen, wird er sich vieleicht
+entscheiden sich nicht zu beteiligen. Foren freundlich zu halten ist
+auf lange Sicht eine Überlebenstaktik und es ist einfacher zu machen,
+solange das Projekt noch klein ist. Sobald es zu einem Teil der Kultur
+geworden ist, werden Sie nicht die einzige sein die sich darum bemüht.
+Das Verhalten wird von allen gepflegt werden.</para>
</sect2>
<!-- ======================== subsection ============================== -->
<sect2 id="code-review">
-<title>Üben Sie Demonstrativ Code Review</title>
+<title>Code Review</title>
-<para>Einer der besten Wege eine produktive Entwicklergemeinschaft zu
-fördern, ist Leute dazu zu bringen gegenseitig Ihren Code an zu
-schauen. Dies effektiv zu gewährleisten, erfordert ein wenig
-technische Infrastruktur-insbesondere sollten commit Emails an
-geschaltet werden; siehe <xref linkend="commit-emails"/> für weitere
-Details. Der Effekt den commit Emails haben ist, dass jedes mal wenn
-jemand ein Änderung an dem Quellcode commited, eine Email mit dem
-zugehörigen Kommentar des Autors und den Diffs (siehe
-<xref linkend="vc-vocabulary-diff"/>, im Kapitel <xref
linkend="vc-vocabulary"/>).
-<firstterm>Code Review</firstterm> bedeutet diese Commit Emails
-durch zu gehen, wenn sie herein kommen und nach Bugs und möglichen
-Verbesserungen zu suchen. <footnote><para>Auf diese Weise wird
-zumindest in Open Source Projekten Code Review Praktiziert. In
-zentralisierteren Projekten, kann "Code Review" auch mehrere Leute die
-gemeinsam durch ausgedrucktem Code durchgehen und nach bestimmten
-Problemen und Mustern suchen, bedeuten.</para></footnote></para>
+<para>Einer der besten Möglichkeiten eine produktive
+Entwicklergemeinschaft zu fördern, ist Leute zu überreden sich
+gegenseitig Ihren Code anzuschauen. Das effektiv zu gewährleisten,
+erfordert einwenig technische Infrastruktur—insbesondere sollten
+Commit E-Mails angeschaltet werden; siehe
+<xref linkend="commit-emails"/> für weiteres darüber. Commit E-Mails
+sorgen dafür, dass auf jede Änderung an dem Quellcode, eine E-Mail
+folgt, mit dem zugehörigen Kommentar des Autors und den Diffs (siehe
+<xref linkend="vc-vocabulary-diff"/> im Kapitel
+<xref linkend="vc-vocabulary"/>). <firstterm>Code Review</firstterm>
+heißt diese Commit E-Mails beim Eintreffen auch durchzulesen und nach
+Fehler sowie mögliche Verbesserungen zu suchen. <footnote><para>Auf
+diese Weise wird zumindest in Open Source Projekten Code Review
+Praktiziert. Für zentralisierte Projekte, kann "Code Review" auch
+bedeuten, dass mehrere Personen gemeinsam den ausgedruckten Code
+durchgehen und nach bestimmten Problemen und Mustern
+suchen.</para></footnote></para>
-<para>Code Review dient mehreren Zwecken gleichzeitig. Es ist das
+<para>Code Review hat dient mehreren Zwecken gleichzeitig. Es ist das
offensichtlichste Beispiel für "Peer Review" in der Open Source
-Welt und hilft direkt dabei die Qualität der Software zu erhalten.
-Jeder Bug der in einem Stück Software ausgeliefert wird, kam dadurch
-zustande, dass es committed wurde und nicht bemerkt wurde; deshalb,
-werden weniger Bugs ausgeliefert werden, je mehr Augen auf die Commits
-schauen. Aber Code Review dient auch einem indirektem Zweck: Es gibt
-Leuten die Bestätigung, dass was sie tun, etwas bedeutet, denn man
-würde sich nicht die Zeit nehmen über einen Commit zu schauen, wenn
-es einem nicht interessieren würde, welchen Effekt er hat. Menschen
-tun ihr bestes, wenn sie wissen, dass andere sich die Zeit nehmen es
-auszuwerten.</para>
-
-<para>Reviews sollte öffentlich sein. Selbst in der Situation, dass
-ich im selben Physikalischen Raum mit anderen Entwicklern gesessen
-habe und einer von uns einen Commit gemacht hat, achten wir darauf
-den Review nicht verbal im Raum zu führen, sondern es an die
-Entwickler Mailing Liste zu schicken. Jeder profitiert davon den
-Review Vorgang zu sehen. Leute verfolgen die Erläuterungen und finden
-darin manchmal Mängel und selbst wenn sie es nicht tun, erinnert es
-sie immer noch daran, dass Code Review eine erwartete regelmäßige
-Aktivität ist, wie das Geschirr spülen oder den Rasen mähen.</para>
-
-<para>Wir im Subversion Projekt hatten es uns zu Anfang nicht zur
-Gewohnheit gemacht, regelmäßig Code Reviews zu machen. Es gab keine
-Garantie, dass jeder commit werden durchgesehen würde, auch wenn man
-manchmal über eine Änderung schauen würde, wenn man besonders an dem
-Bereich des Codes interessiert war. Es schlichen sich Bugs ein die
-wirklich hätte gesehen werden sollen und müssen. Ein Entwickler namens
-Greg Stein, der den Wert von vorhergehender Arbeit kannte, entschied
-sich ein Beispiel zu setzen, indem er jede Zeile von
-<emphasis>jedem einzelnen Commit</emphasis> welches in das Repository
-ging, sich anschaute. Auf jedem Commit, den irgend jemand machte,
-folgte bald von Greg eine Email an die Entwickler Liste, welche den
-Commit zerlegte, mögliche Probleme analysierte und ab und zu ein Lob
-für ein besonders cleveres Stück Code. Auf der Stelle fing er an Bugs
-und nicht Optimale Programmierpraktiken zu finden die sonst durch
-gerutscht wären ohne jemals bemerkt zu werden. Wohlgemerkt beschwerte
-er sich nie, dass er der einzige war der für jeden Commit einen Code
-Review machte, auch wenn es einen nicht unwesentlichen Teil seiner
-Zeit in Anspruch nahm, er lobte aber jedes Mal als er die Gelegenheit
-bekam die Vorteile von Code Reviews. Ziemlich bald, fingen andere an,
-ich selbst eingeschlossen, regelmäßig commits anzuschauen. Was war
-unsere Motivation? Es war nicht, dass Greg uns bewusst durch Schande
-dazu gebracht hat. Er hatte bewiesen, dass Code Reviews einer
-wertvoller weg ist, seine Zeit zu verbringen und dass man so viel zu
-einem Projekt beitragen kann, indem man den Änderungen anderer
-durchsieht, wie indem man selber neuen Code schreibt. Als er das ein
-mal demonstriert hat, wurde es zum erwarteten Verhalten, so weit
-sogar, dass wenn auf einem Commit keine Reaktion folgte es dazu
-führte, dass der Committer anfing sich sorgen zu machen und sogar auf
-der Liste nach fragte, ob nicht jemand die Zeit gefunden hatte drüber
-zu schauen. Später bekam Greg einen Job der ihn nicht so viel Zeit
-für Subversion ließ und er musste mit den regelmäßigen Code Reviews
-aufhören. Aber bis zu dem Zeitpunkt, war die Angewohnheit so weit
-bei uns anderen integriert, als ob es nie anders gewesen war.</para>
-
-<para>Fangen Sie ab dem aller ersten Commit damit an Reviews zu
-machen. Die Probleme die am einfachsten durch das Durchsehen der
-Diffs zu erwischen sind, sind Schwachstellen in der Sicherheit,
-Speicher Lecks ungenügende Kommentare oder Dokumentation der API,
-off-by-one Fehler, caller/callee discipline mismatches, und andere
-Probleme, die ein Minimum an umgebenden Kontext erfordern um sie zu
-finden. Selbst Angelegenheiten von größerem Umfange, wie z.B.
-wiederholte Muster nicht an einer Stelle zu abstrahieren, werden
-leichter erkennbar, nachdem man regelmäßig die Reviews gemacht hat,
-da vergangene Diffs darüber über den Review derzeitiger Diffs
-informierten.</para>
+Welt und hilft unmittelbar die Qualität der Software zu erhalten. Jeder
+Fehler der in einer Software ausgeliefert wird kam zustande, indem es
+committed wurde und nicht bemerkt wurde; es werden umso weniger Fehler
+in einer veröffentlichten Version, je mehr Augen auf die Commits
+gerichtet sind. Code Review dient aber auch einem indirekten Zweck: Es
+gibt Leute die Bestätigung, dass ihre Arbeit etwas bedeutet, denn man
+würde sich nicht die Zeit nehmen über einen Commit zu schauen, wenn es
+einem nicht interessiert, welche Auswirkungen er hat. Menschen geben
+sich bei ihrer Arbeit am meisten Mühe wenn sie wissen, dass Andere sich
+die Zeit nehmen es auszuwerten.</para>
+
+<para>Jeder Review sollte öffentlich gemacht werden. Selbst wenn ich
+im selben Physikalischen Raum mit anderen Entwicklern bin und einer von
+uns einen Commit macht, achten wir darauf den Review nicht verbal im
+Raum zu führen, sondern es an den Entwickler Verteiler zu schicken.
+Jeder profitiert davon wenn der Review sichtbar ist. Leute folgen den
+Erläuterungen und finden darin manchmal Mängel und selbst wenn sie es
+nicht tun, erinnert es sie immer noch daran, dass Code Review eine
+erwartete regelmäßige Aktivität ist, wie Geschirrspülen oder
+Rasenmähen.</para>
+
+<para>Im Subversion Projekt hatten wir am Anfang nicht diese
+Angewohnheit. Es gab keine Garantie, dass jeder Commit überprüft wurde,
+obwohl wenn man manchmal über eine Änderung schauen würde, wenn man
+besonders an einem Bereich vom Quellcode interessiert war. Es schlichen
+sich Fehler ein die man eigentlich hätte sehen sollen und müssen. Ein
+Entwickler namens Greg Stein, der aus seiner vorherigen Arbeit den Wert
+von Code Review kannte, entschied sich ein Beispiel zu setzen, indem er
+sich jede Zeile von <emphasis>jedem einzelnen Commit</emphasis> an die
+Repository anschaute. Auf jedem Commit, den irgendjemand machte, folgte
+bald eine E-Mail von Greg an den Entwickler Verteiler, indem er den
+Commit sizierte, mögliche Probleme analysierte und ab und zu Lob
+aussprach, für besonders cleveren Code. Auf der Stelle fing er an
+Fehler und nicht optimale Programmierpraktiken zu entdecken die
+ansonsten durchgerutscht wären, ohne je bemerkt zu werden. Er beschwerte
+sich Wohlgemerkt nie, dass er der einzige war der Code Review betrieb,
+auch wenn es keinen unwesentlichen Teil seiner Zeit in Anspruch nahm,
+er lobte bei jeder Gelegenheit die Vorteile von Code Review. Ziemlich
+bald fingen Andere an, ich eingeschlossen, regelmäßig Commits zu
+überprüfen. Was war unsere Motivation? Greg hatte uns nicht bewusst
+durch Schande dazu gebracht. Er hatte bewiesen, dass Code Review eine
+wertvolle Zeitinvestition ist und dass man genau soviel zu einem
+Projekt beitragen kann, indem man die Änderungen anderer durchsieht,
+wie wenn man selber neuen Code schreibt. Als er das demonstriert hatte,
+wurde es zum erwarteten Verhalten. Das ging sogar soweit, dass wenn auf
+einem Commit keine Reaktion folgte es dazu führte, dass man sich als
+Committer sich sorgen machte und sogar auf dem Verteiler nachfragte, ob
+nicht jemand die Zeit gefunden hatte es sich anzuschauen. Später bekam
+Greg eine Arbeit der ihm nicht so viel Zeit für Subversion ließ und er
+musste mit dem regelmäßigen Code Review aufhören. Aber bis dahin, war
+die Angewohnheit so weit integriert, als ob es nie anders gewesen
+wäre.</para>
+
+<para>Fangen Sie Code Review ab dem allerersten Commit an. Die Probleme
+die man am einfachsten beim Durchsehen der Diffs erkennen kann, sind
+Sicherheitslücken, Speicherlecks ungenügende Kommentierung oder
+Dokumentation der API, off-by-one Fehler, caller/callee
+Ungleichgewichte und andere Probleme, deren Entdeckung keinen großen
+umgebenden Kontext erfordern. Selbst Angelegenheiten von größerem
+Umfange, wie z.B. häufige Muster nicht an einer Stelle zu abstrahieren,
+werden leichter erkennbar nachdem man Code Review regelmäßig die
+betreibt, da die man sich an vergangene Diffs Erinnert.</para>
<!-- todo: Andrew Stellman suggested putting a checklist of what to
look for in code review here. That might be a good idea. -->
-<para>Machen Sie sich keine sorgen, dass Sie nichts finden, was Sie
-kommentieren können, oder weil Sie nicht genug über alle Bereiche des
-Codes wissen. Es wird für gewöhnlich irgend etwas über einen Commit zu
-sagen geben; selbst wenn Sie nichts bedenkliches finden, kann es sein,
-dass Sie etwas zum loben finden. Das wichtige ist, jedem der
-Commited klar zu machen, dass was sie machen gesehen und verstanden
-wird. Natürlich befreit Code Review die Programmierer nicht von der
-Verantwortung ihre Änderungen vor dem Commit, durch zu sehen und zu
-testen; keiner sollte sich auf Code Review verlassen um Fehler zu
-finden, die er von alleine hätte finden müssen.</para>
+<para>Machen Sie sich keine sorgen, dass Sie nichts finden worüber Sie
+etwas sagen könnten, oder dass Sie nicht genug über alle Bereiche des
+Codes wissen. Es gibt meißtens irgendetwas über jeden beliebigen Commit
+zu sagen; selbst wenn Sie nichts bedenkliches finden kann es sein, dass
+Sie etwas Lobenswertes finden. Das wichtige ist, jedem der Committer
+klar wird, dass ihre Arbeit gesehen und verstanden wird. Natürlich
+befreit Code Review die Programmierer nicht von der Verantwortung ihre
+Änderungen vor dem Commit zu überprüfen und zu testen; keiner sollte
+sich auf Code Review verlassen um Fehler zu finden, die er von alleine
+hätte finden müssen.</para>
</sect2>
_______________________________________________
Producingoss-translators mailing list
[email protected]
http://www.red-bean.com/mailman/listinfo/producingoss-translators
