Author: mbarkhau
Date: Tue Jul 24 06:13:23 2007
New Revision: 849
Log:
Continued ch08
Modified:
trunk/de/ch08.xml
Modified: trunk/de/ch08.xml
==============================================================================
--- trunk/de/ch08.xml (original)
+++ trunk/de/ch08.xml Tue Jul 24 06:13:23 2007
@@ -1578,131 +1578,143 @@
<!-- ======================== SECTION ============================== -->
<sect1 id="committers">
-<title>Committers</title>
+<title>Committer</title>
-<para>As the only formally distinct class of people found in all open
-source projects, committers deserve special attention here.
-Committers are an unavoidable concession to discrimination in a system
-which is otherwise as non-discriminatory as possible. But
-"discrimination" is not meant as a pejorative here. The function
-committers perform is utterly necessary, and I do not think a project
-could succeed without it. Quality control requires, well, control.
-There are always many people who feel competent to make changes to a
-program, and some smaller number who actually are. The project cannot
-rely on people's own judgement; it must impose standards and grant
-commit access only to those who meet them<footnote><para>Note that the
-commit access means something a bit different in decentralized version
-control systems, where anyone can set up a repository that is linked
-into the project, and give themselves commit access to that
-repository. Nevertheless, the <emphasis>concept</emphasis> of commit
-access still applies: "commit access" is shorthand for "the
-right to make changes to the code that will ship in the group's next
-release of the software." In centralized version control systems,
-this means having direct commit access; in decentralized ones, it
-means having one's changes pulled into the main distribution by
-default. It is the same idea either way; the mechanics by which it is
-realized are not terribly important.</para></footnote>. On the other
-hand, having people who can commit changes directly working
-side-by-side with people who cannot sets up an obvious power dynamic.
-That dynamic must be managed so that it does not harm the
-project.</para>
+<para>Als die einzig wesentlich ausgeprägte Gruppe von Personen die in
+allen Open Source Projekten gefunden werden kann, verdienen Committer
+hier besondere Aufmerksamkeit. Committer sind ein unvermeidliches
+Zugeständniss an die Diskriminierung, bei einem System, welches
+ansonsten so diskriminierungsfrei wie möglich ist. "Diskriminierung" ist
+hier aber nicht herabsetzend gemeint. Die Funktion die Committer
+ausüben ist ganz und gar unerlässlich, und ich denke nicht, dass ein
+Projekt ohne es erfolgreich wäre. Qualitätskontrolle erfordert, nun ja,
+Kontrolle. Es gibt immer viele Leute die meinen sie wären qualifiziert
+Änderungen an einer Anwendung zu machen, und irgend eine kleinere
+Anzahl, die es auch wirklich sind. Das Projekt, kann sich nicht auf das
+eigene Urteilsvermögen der Leute verlassen; es muss Normen auferlegen,
+und nur denen Commit Berechtigung geben, die sie erfüllen<footnote>
+<para>Beachten Sie dass commit Zugriff bei einem dezentralisierten
+Versionsverwaltungssystem ein klein wenig was anderes bedeutet, da jeder
+seine eigene Repository aufsetzen kann, welche mit dem des Projekts
+verbunden ist, und sich selber zu dieser Repository Zugriff geben.
+Nichtsdestotrotz gilt das <emphasis>konzept</emphasis> vom commit
+Zugriff, trotzdem noch: "Commit Zugriff" ist Kurz für "das Recht
+Änderungen an dem Code zu machen, welches in der nächsten Version der
+Software ausgeliefert wird". In zentralisierten Systemen bedeutet es,
+direkten Commit Zugriff zu haben; bei dezentralisierten Systemen
+bedeutet es, dass die Änderungen standardmäßig in die Repository des
+Projekts geladen werden. So oder so, ist es das gleiche; die Mechanik,
+mit dem es realisiert wird, ist nicht sonderlich wichtig.</para>
+</footnote>. Andererseits, entsteht ein Machtverhältniss zwischen Leuten
+die direkt Änderungen committen können, die direkt beben Leuten die es
+nicht können. Dieses Verhältniss muss so verwaltet werden, dass es dem
+Projekt nicht schadet.</para>
<para>In <xref linkend="electorate"/><phrase output="printed">
-in <xref linkend="social-infrastructure"/></phrase>, we already
-discussed the mechanics of considering new committers. Here we will
-look at the standards by which potential new committers should be
-judged, and how this process should be presented to the larger
-community.</para>
+im Kapitel <xref linkend="social-infrastructure"/></phrase>, haben wir
+beteits die Mechanismen besprochen, wie neue Committer in Betracht
+kommen. Hier werden wir uns die Normen anschauen, nach denen neue
+Committer beurteilt werden sollten, und wie dieser Vorgang der weiteren
+Gemeinschaft präsentiert werden sollte.</para>
<!-- ======================== subsection ============================== -->
<sect2 id="choosing-committers">
-<title>Choosing Committers</title>
+<title>Auswahl von Committer</title>
-<para>In the Subversion project, we choose committers primarily on the
-Hippocratic Principle: <emphasis>first, do no harm</emphasis>. Our
-main criterion is not technical skill or even knowledge of the code,
-but merely that the committer show good judgement. Judgement can mean
-simply knowing what not to take on. A person might post only small
-patches, fixing fairly simple problems in the code; but if the patches
-apply cleanly, do not contain bugs, and are mostly in accord with the
-project's log message and coding conventions, and there are enough
-patches to show a clear pattern, then an existing committer will
-usually propose that person for commit access. If at least three
-people say yes, and no one objects, then the offer is made. True, we
-might have no evidence that the person is able to solve complex
-problems in all areas of the code base, but that does not matter: the
-person has made it clear that he is capable of at least judging
-his own abilities. Technical skills can be learned (and taught),
-but judgement, for the most part, cannot. Therefore, it is the one
-thing you want to make sure a person has before you give him commit
-access.</para>
-
-<para>When a new committer proposal does provoke a discussion, it is
-usually not about technical ability, but rather about the person's
-behavior on the mailing lists or in IRC. Sometimes someone shows
-technical skill and an ability to work within the project's formal
-guidelines, yet is also consistently belligerent or uncooperative in
-public forums. That's a serious concern; if the person doesn't
-seem to shape up over time, even in response to hints, then we won't
-add him as a committer no matter how skilled he is. In a
-volunteer group, social skills, or the ability to "play well in the
-sandbox", are as important as raw technical ability. Because
-everything is under version control, the penalty for adding a
-committer you shouldn't have is not so much the problems it could
-cause in the code (review would spot those quickly anyway), but that
-it might eventually force the project to revoke the person's commit
-access—an action that is never pleasant and can sometimes be
-confrontational.</para>
-
-<para>Many projects insist that the potential committer demonstrate a
-certain level of technical expertise and persistence, by submitting
-some number of nontrivial patches—that is, not only do these
-projects want to know that the person will do no harm, they want to
-know that she is likely to do good across the code base. This is
-fine, but be careful that it doesn't start to turn committership into
-a matter of membership in an exclusive club. The question to keep in
-everyone's mind should be "What will bring the best results for the
-code?" not "Will we devalue the social status associated with
-committership by admitting this person?" The point of commit access
-is not to reinforce people's self-worth, it's to allow good changes to
-enter the code with a minimum of fuss. If you have 100
-committers, 10 of whom make large changes on a regular basis, and the
-other 90 of whom just fix typos and small bugs a few times a year,
-that's still better than having only the 10.</para>
+<para>In dem Subversion Projekt, wählen wir Committer hauptsächlich nach
+dem Hippokratischen Prinzip: <emphasis>Erstens, richte keinen Schaden an
+</emphasis>. Unser Hauptkriterien sind nicht technische Fähigkeiten oder
+auch nur Kentniss vom Code, sondern lediglich, dass der Committer
+eingutes Urteilsvermögen zeigt. Urteilsvermögen, kann auch einfach nur
+bedeuten, was man nicht angehen soll. Eine Person könnte nur kleine
+Patches einreichen, relativ kleine Probleme in dem Code beheben; aber
+wenn die Patches sich sauber anwenden lassen, keine Bugs enthalten, und
+weitestgehend mit den Richtlinien des Projekts, über die Formatierung
+von Komentare und Code übereinstimmen, und es genügend Patches gibt, um
+ein klares muster zu zeigen, dann wird ein vorhandener Committer ihn für
+gewöhnlich als Kandidat für Commit Zugriff vorschlagen. Wenn mindestens
+drei Personen zustimmen und es keine Gegenstimmen gibt, wird ein Angebot
+unterbreitet. Zugegeben, wir werden keine Beweise haben, dass die Person
+in der Lage ist komplexe Probleme in allen Bereichen des Quellcodes zu
+lösen, aber das macht keinen Unterschied: Die Person hat klar gemacht,
+dass sie zumindest in der Lage ist ihre eigenen Fähigkeiten
+einzuschätzen. Technische Fähigkeiten können gelernt (und angelernt)
+werden, für Urteilsvermögen gilt das im wesentlichen nicht. Desshalb ist
+es die eine Sache, bei dem Sie sicher gehen wollen, dass die Person sie
+besitzt, vor Sie ihm commit Zugriff geben.</para>
+
+<para>Wenn ein neuer Committer vorgeschlagen wird, geht es für
+gewöhnlich nicht um technischen Fähigkeiten, sondern um das Verhalten
+der Person auf den Email Verteilern oder im IRC. Manchmal zeigt jemand
+technisches Können, und die Fähigkeit innerhalb der formalen Richtlinien
+des Projekts zu arbeiten, ist jedoch in den öffentlichen Foren immer
+Streitlustig oder nicht kooperativ. Das ist ein ernstes Bedenken; wenn
+die Person sich mit der Zeit nicht bessert, selbst als reaktion auf
+Andeutungen, werden wir ihn keinen Commit Zugriff geben, egal wie
+Talentiert er ist. In einer Gruppe von Freiwilligen, sind soziale
+Kompetenzen, oder die Fähigkeit "gut im Sandkasten zu spielen", genau so
+wichtig wie die rohen technischen Fähigkeiten. Da alles unter
+Versionsverwaltung steht, sind die Nachteile einen Committer
+hinzuzufügen den Sie lieber nicht hätten, nicht so sehr die Probleme
+die es im Code bereiten könnte (Code Überprüfungen sollten das sowieso
+schnell aufdecken), sondern dass es irgendwann das Projekt dazu zwingen
+könnte die commit Berechtigung wegzunehmen—etwas, was niemals
+angenehm ist und manchmal Auseinandersetzungen provoziert.</para>
+
+<para>Viele Projekte bestehen darauf, dass der potentielle Committer
+einen gewissen Grad an technischen Kentnissen und Ausdauer vorweist,
+indem er eine gewisse Anzahl nicht trivialer Patches
+einreicht—diese Projekte wollen also nicht nur wissen, dass die
+Person keinen Schaden anrichten wird, sondern auch das er sich
+wahrscheinlich im gesamten Quellcode bewähren wird. Das ist völlig in
+Ordnung, seien Sie aber vorsichtig, dass die Commit Berechtigung
+nicht anfängt, sich in die Mitgliedschft in einem Exklusiven Club, zu
+verwandeln. Die Frage die in allen Köpfen sein sollte ist "Was wird die
+besten Ergebnisse für den Code liefern?" nicht "Werden wir den sozialen
+Status veringern, der mit Commit Berechtigung in Zusammenhang gebracht
+wird, wenn wir diese Person aufnehmen"? Der Sinn von Commit Zugriff, ist
+nicht den Selbstwert der Leute zu unterstützen, es ist um Änderungen an
+den Code zu erlauben, mit möglichst wenigen Umständen. Wenn Sie 100
+Committer haben, von denen 10 regelmäßig große Änderungen machen, und
+die anderen 90 von denen nur Tippfehler und kleine und kleine Fehler
+ein paar mal im Jahr beheben, ist das immer noch besser als nur die 10
+zu haben.</para>
</sect2>
<!-- ======================== subsection ============================== -->
<sect2 id="revoking-committers">
-<title>Revoking Commit Access</title>
+<title>Widerruf von Commit Zugriff</title>
-<para>The first thing to be said about revoking commit access is: try
-not to be in that situation in the first place. Depending on whose
-access is being revoked, and why, the discussions around such an
-action can be very divisive. Even when not divisive, they will be a
-time-consuming distraction from productive work.</para>
-
-<para>However, if you must do it, the discussion should be had
-privately among the same people who would be in a position to vote for
-<emphasis>granting</emphasis> that person whatever flavor of commit
-access they currently have. The person herself should not be
-included. This contradicts the usual injunction against secrecy, but
-in this case it's necessary. First, no one would be able to speak
-freely otherwise. Second, if the motion fails, you don't necessarily
-want the person to know it was ever considered, because that could
-open up questions ("Who was on my side? Who was against me?") that
-lead to the worst sort of factionalism. In certain rare
-circumstances, the group may want someone to know that revocation of
-commit access is or was being considered, as a warning, but this
-openness should be a decision the group makes. No one should ever, on
-her own initiative, reveal information from a discussion and ballot
-that others assumed were secret.</para>
-
-<para>Once someone's access is revoked, that fact is unavoidably
-public (see
-<xref linkend="commit-access-openness"/><phrase output="printed">
-later in this chapter</phrase>), so try to be as tactful as you can in
-how it is presented to the outside world.</para>
+<para>Das erste was zu der Rücknahme von Commit Zugriff gesagt werden
+muss ist: Versuchen Sie möglichst gar nicht erst in die Lage zu geraten.
+Abhängig davon, wessen Zugriff zurückgezogen wird, und warum, können die
+Diskussionen um solche Maßnahmen sehr geteilt sein. Selbst wenn sie
+nicht geteilt sind, können sie eine sehr zeitaufwendige Ablenkung von
+der produktiven Arbeit sein.</para>
+
+<para>Wenn Sie es jedoch tun müssen, sollte die Diskussion im privaten
+mit den selben Personen geführt werden, die ein Stimmrecht für die
+<emphasis>Gewährung</emphasis> des Zugriffs haben, welche diese Person
+gerade hat. Die Person selber sollte nicht mit einbezogen werden. Das
+wirderspricht die gewöhnliche Vorschrift gegen die Geheimhaltung, ist
+aber in diesem Fall notwendig. Erstens, könnte sonst keiner frei reden.
+Zweitens, wenn der Antrag fehlschlägt, wollen Sie nicht unbedingt, dass
+die Person weiß, dass es überhaupt zur Debatte stand, da es Fragen
+aufwerfen könnte ("Wer war auf meiner Seite? Wer war gegen mich?") die
+zu der schlimmsten Art von Parteibildung führen. Unter bestimmten
+seltenen Umständen, kann die Gruppe jemandem sagen wollen, dass der
+Widerruf in Betracht gezogen wird oder wurde, als Warnung, diese
+Offenheit sollte aber eine Entscheidung der Gruppe sein. Keiner sollte
+jemals aus Eigeninitiative jemandem Informationen aus einer Diskussion
+und einer Wahl preisgeben, von denen andere angenommen haben, dass sie
+Geheim waren.</para>
+
+<para>Nachdem der Zugriff widerrufen wurde, ist diese Tatsache
+zwangsläufig öffentlich (siehe <xref linkend="commit-access-openness"/>
+<phrase output="printed"> später in diesem Kapitel</phrase>), also
+versuchen Sie so Taktvoll wie möglich zu sein, in der Art wie Sie es der
+Öffentlichkeit präsentieren.</para>
</sect2>
_______________________________________________
Producingoss-translators mailing list
[email protected]
http://www.red-bean.com/mailman/listinfo/producingoss-translators
