Author: mbarkhau Date: Tue Jul 24 11:23:13 2007 New Revision: 850 Log: Continued ch08
Modified: trunk/de/ch08.xml trunk/de/words.txt Modified: trunk/de/ch08.xml ============================================================================== --- trunk/de/ch08.xml (original) +++ trunk/de/ch08.xml Tue Jul 24 11:23:13 2007 @@ -1720,119 +1720,130 @@ <!-- ======================== subsection ============================== --> <sect2 id="partial-committers"> -<title>Partial Commit Access</title> +<title>Eingeschränkter Commit Zugriff</title> -<para>Some projects offer gradations of commit access. For example, -there might be contributors whose commit access gives them free rein -in the documentation, but who do not commit to the code itself. -Common areas for partial commit access include documentation, -translations, binding code to other programming languages, -specification files for packaging (e.g., RedHat RPM spec files, -etc.), and other places where a mistake will not result in a problem for -the core project.</para> - -<para>Since commit access is not only about committing, but about -being part of an electorate (see -<xref linkend="electorate"/><phrase output="printed"> in -<xref linkend="social-infrastructure"/></phrase>), -the question naturally arises: what can the partial committers vote -on? There is no one right answer; it depends on what sorts of partial -commit domains your project has. In Subversion we've kept things -fairly simple: a partial committer can vote on matters confined -exclusively to that committer's domain, and not on anything else. -Importantly, we do have a mechanism for casting advisory votes -(essentially, the committer writes "+0" or "+1 (non-binding)" -instead of just "+1" on the ballot). There's no reason to silence -people entirely just because their vote isn't formally binding.</para> - -<para>Full committers can vote on anything, just as they can commit -anywhere, and only full committers vote on adding new committers of -any kind. In practice, though, the ability to add new partial -committers is usually delegated: any full committer can "sponsor" a -new partial committer, and partial committers in a domain can often -essentially choose new committers for that same domain (this is -especially helpful in making translation work run smoothly).</para> - -<para>Your project may need a slightly different arrangement, -depending on the nature of the work, but the same general principles -apply to all projects. Each committer should be able to vote on -matters that fall within the scope of her commit access, and not on -matters outside that, and votes on procedural questions should default -to the full committers, unless there's some reason (as decided by the -full committers) to widen the electorate.</para> - -<para>Regarding enforcement of partial commit access: it's often -best <emphasis>not</emphasis> to have the version control system -enforce partial commit domains, even if it can. See -<xref linkend="vc-authz"/><phrase output="printed"> in -<xref linkend="technical-infrastructure"/></phrase> for the -reasons why.</para> +<para>Manche Projekte bieten eine Abstufung bei der Commit Berechtigung +an. Es kann zum Beispiel Freiwillige geben, die freien Zugriff auf die +Dokumentation habem, die aber nicht an den Code selber committen können. +Häufige Bereiche für den Teilzugriff sind unter anderem die +Dokumentation, Übersetzungen, Code für die Anbindung anderer +Programiersprachen, bestimmte Dateien um Packete zu erstellen (z.B. +Dateien spezifisch zum RPM von RedHat usw.), sowie andere Orte, an denen +ein Fehler nicht zu einem großen Problem für das Projekt werden wird. +</para> + +<para>Da es beim Commit Zugriff nicht nur darum geht Änderungen zu +machen, sonderan auch einen Teil der Wahlberechtigten zu sein (siehe +<xref linkend="electorate"/><phrase output="printed"> im Kapitel +<xref linkend="social-infrastructure"/></phrase>), stellt sich natürlich +die Frage: Worüber können Teilberechtigte Committer abstimmen? Es gibt +keine eine richtige Antwort; es hängt davon ab, welche Arten von +Bereichen Ihr Projekt mit Teilzugriff hat. In Subversion, haben wir +alles relativ einfach gehalten: Ein Committer mit Teilzugriff, kann über +Angelegenheiten abstimmen, die exclusiv mit seinem Bereich zu tun haben +und auf nichts anderes. Wichtig dabei, ist dass wir eine Möglichkeit +haben, um beratende Stimmen abgeben können (im Wesentlichen, schreibt +der Committer "+0" oder "+1 (nicht-bindend)" statt einer einfachen +"+1" Stimme). Es gibt keinen Grund Leute komplett zum Schweigen zu +bringen, nur weil ihre Stimme nicht formal bindend ist.</para> + +<para>Vollständig Commit Berechtigte können über alles abstimmen, genau +so wie sie überall committen können, und nur Vollberechtigte können über +die Aufnahmen von neuen Committern jedweder Art abstimmen. In der +Praxis, wird die Fähigkeit neue Teilberechtigte aufzunehmen, jedoch +weitergegeben: Jeder Vollberechtigter kann für einen neuen +Teilberechtigten "bürgen", und Teilberechtigte Committer können im +wesentlichen neue Committer für den gleichen Bereich wählen (das ist +besonders hilfreich, damit die Übersetzungsarbeit glatt verläuft). +</para> + +<para>Ihr Projekt kann eine etwas andere Anordnung erfordern, abhängig +von der Natur der Arbeit, die selben allgemeinen Prinzipien gelten aber +für alle Projekte. Jeder Committer sollte über Angelegenheiten abstimmen +können, die in dem Bereich fallen auf den er Zugriff hat, und nicht auf +solche die außerhalb davon liegen, und Wahlen über Generelle Abläufe, +sollten automatisch auf die vollen Committer gehen, es sei denn es gibt +einen Grund (welcher von den vollen Committern entschieden wurde) um den +Wahlkreis auszuweiten.</para> + +<para>Was die Druchsetzung des Teilzugriffs angeht: Es ist of am besten, +wenn das Versionsverwaltungssystem <emphasis>nicht</emphasis> den +Teilzugriff erzwingt, selbst wenn es dazu in der Lage ist. Siehe +<xref linkend="vc-authz"/><phrase output="printed"> im Kapitel +<xref linkend="technical-infrastructure"/></phrase> für weiteres über +die Gründe dafür.</para> </sect2> <!-- ======================== subsection ============================== --> <sect2 id="dormant-committers"> -<title>Dormant Committers</title> +<title>Untätige Committer</title> -<para>Some projects automatically remove people's commit access if -they go a certain amount of time (say, a year) without committing -anything. I think this is usually unhelpful and even -counterproductive, for two reasons.</para> - -<para>First, it may tempt some people into committing acceptable but -unnecessary changes, just to prevent their commit access from -expiring. Second, it doesn't really serve any purpose. If the -main criterion for granting commit access is good judgement, then why -assume someone's judgement would deteriorate just because he's away -from the project for a while? Even if he completely vanishes for -years, not looking at the code or following development discussions, -when he reappears he'll <emphasis>know</emphasis> how out of touch -he is, and act accordingly. You trusted his judgement before, so -why not trust it always? If high school diplomas do not expire, then -commit access certainly shouldn't.</para> - -<para>Sometimes a committer may ask to be removed, or to be explicitly -marked as dormant in the list of committers (see -<xref linkend="commit-access-openness"/><phrase output="printed"> -below</phrase> for more about that list). In these cases, the project -should accede to the person's wishes, of course.</para> +<para>Manche Projekte entfernen den Zugriff auf die Repository nach +einer gewissen Zeit (sagen wir, ein Jahr) ohne einen Commit. Ich denke +dass das meistens nicht hilfreich ist und sogar aus zwei gründen +kontraproduktiv ist.</para> + +<para>Erstens, kann es Leute dazu verleiten annehmbare aber unnötige +Änderungen zu committen, nur um zu verhindern, dass ihr commit Zugriff +abläuft. Zweitens, dient es keinen wirklichen Zweck. Wenn die +Hauptkriterium um Leuten Commit Zugriff zu gewähren ein gutes +Urteilsvermögen ist, warum sollte man annehmen, dass das Urteilsvermögen +von jemand verfällt, nur weil er eine weile lang von dem Projekt weg +war? Selbst wenn er komplett über Jahre verschwindet, sich nicht den +Code anschaut, oder die Diskussionen über die Entwicklung mitverfolgt, +wird er wenn er wieder auftaucht <emphasis>wissen</emphasis> wie fremd +er der Sache ist und sich entsprechend verhalten. Sie haben sein +Urteilsvermögen vorher vertraut, warum sollten Sie es nicht immer +vertrauen? Wenn ein Diplom nicht abläuft, dann sollte es der commit +Zugriff auch nicht.</para> + +<para>Manchmal wird ein commiter darum bitten entfernt zu werden, oder +in der Auflistung der Committer explizit als abwesend markiert zu +werden (siehe <xref linkend="commit-access-openness"/><phrase +output="printed"> weiter unten</phrase> für weiteres über diese Liste). +In solchen Fällen, sollten das Projekt natürlich den Wünschen der Person +nachkommen.</para> </sect2> <!-- ======================== subsection ============================== --> <sect2 id="commit-access-openness"> -<title>Avoid Mystery</title> +<title>Vermeiden Sie Geheimnisse</title> -<para>Although the discussions around adding any particular new -committer must be confidential, the rules and procedures themselves -need not be secret. In fact, it's best to publish them, so people -realize that the committers are not some mysterious Star Chamber, -closed off to mere mortals, but that anyone can join simply by posting -good patches and knowing how to handle herself in the community. -In the Subversion project, we put this information right in the -developer guidelines document, since the people most likely to be -interested in how commit access is granted are those thinking of -contributing code to the project.</para> - -<para>In addition to publishing the procedures, publish the -actual <emphasis>list</emphasis> of committers. The traditional place -for this is a file called <filename>MAINTAINERS</filename> -or <filename>COMMITTERS</filename> in the top level of the project's -source code tree. It should list all the full committers first, -followed by the various partial commit domains and the members of each -domain. Each person should be listed by name and email address, -though the address can be encoded to prevent spam (see -<xref linkend="address-hiding"/><phrase output="printed"> in -<xref linkend="technical-infrastructure"/></phrase>) if the -person prefers that.</para> - -<para>Since the distinction between full commit and partial commit -access is obvious and well defined, it is proper for the list to make -that distinction too. Beyond that, the list should not try to -indicate the informal distinctions that inevitably arise in a project, -such as who is particularly influential and how. It is a public -record, not an acknowledgments file. List committers either in -alphabetical order, or in the order in which they arrived.</para> +<para>Auch wenn die Diskussionen um die Aufnahme eines bestimmten neuen +Committers geheim gehalten werden sollte, müssen die Regeln und Abläufe +selber nicht gehiem seit. Es ist sogar am besten, wenn sie +veröffentlicht werden, damit Leute erkennen, dass committer nicht irgend +eine mysteriöse mit Prominenz gefüllte Kammer ist, die für +Normalsterbliche verschlossen ist, sondern dass jeder einfach eintreten +kann indem er gute Patches einreicht, und sich weiß in der Gemeinschaft +zu verhalten. In dem Subversion Projekt, stellen wir diese Information +direkt in dem Dokument der Entwicklerrichtlinien, da diejenigen die am +ehesten daran interesiert sind commit Zugriff zu bekommen, solche sind +die darüber nachdenken Code zu dem Projekt beizutragen.</para> + +<para>Zusätzlich zu der Veröffentlichung der Richtlinien, sollten Sie +die <emphasis>Liste</emphasis> der Committer veröffentlichen. Der +traditionelle Ort hierfür ist eine Datei namens <filename>MAINTAINERS +</filename> oder <filename>COMMITTERS</filename> im obersten +Verzeichniss des Quellcodes vom Projekt. Es sollte zuerst alle vollen +commit Berechtigten auflisten, gefolgt von verschiedenen Bereichen +und die zugehörigen teilberechtigten Committer. Jede Person sollte mit +Namen und Email Adresse aufgeführt sein, wobei die Adresse kodiert sein +darf, um Spam zu verhindern (siehe <xref +linkend="address-hiding"/><phrase output="printed"> im Kapitel <xref +linkend="technical-infrastructure"/></phrase>) wenn die Person das +bevorzugt.</para> + +<para>Da die Unterscheidung zwischen voll und teilzugriff auf die +Repository offensichtlich und gut definiert ist, ist es auch angemessen, +wenn diese Liste diese Unterscheidung auch macht. Darüber hinaus, sollte +die Liste nicht versuchen die informellen unterschiede anzudeuten, die +sich zwangsläufig in einem Projekt ergeben, wie wer besonders +einflussreich ist und wie. Es ist ein öffentliches Protokoll, keine +Datei für Anerkennungen. Listen Sie die Commiter in alphabetischer +Reihenfolge auf, oder in so wie sie angekommen sind.</para> </sect2> @@ -1841,137 +1852,151 @@ <!-- ======================== SECTION ============================== --> <sect1 id="credit"> -<title>Credit</title> +<title>Anerkennung</title> -<para>Credit is the primary currency of the free software world. -Whatever people may say about their motivations for participating in a -project, I don't know any developers who would be happy doing all -their work anonymously, or under someone else's name. There are -tangible reasons for this: one's reputation in a project roughly -governs how much influence one has, and participation in an open -source project can also indirectly have monetary value, because -some employers now look for it on resumés. There are also -intangible reasons, perhaps even more powerful: people simply want to -be appreciated, and instinctively look for signs that their work was -recognized by others. The promise of credit is therefore one of best -motivators the project has. When small contributions are -acknowledged, people come back to do more.</para> - -<para>One of the most important features of collaborative development -software (see <xref linkend="technical-infrastructure"/>) is that -it keeps accurate records of who did what, when. Wherever possible, -use these existing mechanisms to make sure that credit is distributed -accurately, and be specific about the nature of the contribution. -Don't just write "Thanks to J. Random <[EMAIL PROTECTED]>" if -instead you can write "Thanks to J. Random <[EMAIL PROTECTED]> -for the bug report and reproduction recipe" in a log message.</para> - -<para>In Subversion, we have an informal but consistent policy of -crediting the reporter of a bug in either the issue filed, if there is -one, or the log message of the commit that fixes the bug, if not. A -quick survey of Subversion commit logs up to commit number 14525 shows -that about 10% of commits give credit to someone by name and email -address, usually the person who reported or analyzed the bug fixed by -that commit. Note that this person is different from the developer -who actually made the commit, whose name is already recorded -automatically by the version control system. Of the 80-odd full and -partial committers Subversion has today, 55 were credited in the -commit logs (usually multiple times) before they became committers -themselves. This does not, of course, prove that being credited was a -factor in their continued involvement, but it at least sets up an -atmosphere in which people know they can count on their contributions -being acknowledged.</para> - -<para>It is important to distinguish between routine acknowledgment -and special thanks. When discussing a particular piece of code, or -some other contribution someone made, it is fine to acknowledge their -work. For example, saying "Daniel's recent changes to the delta code -mean we can now implement feature X" simultaneously helps people -identify which changes you're talking about and acknowledges Daniel's -work. On the other hand, posting solely to thank Daniel for the delta -code changes serves no immediate practical purpose. It doesn't add -any information, since the version control system and other mechanisms -have already recorded the fact that he made the changes. Thanking -everyone for everything would be distracting and ultimately -information-free, since thanks are effective largely by how much they -stand out from the default, background level of favorable comment -going on all the time. This does not mean, of course, that you should -never thank people. Just make sure to do it in ways that tend not to -lead to credit inflation. Following these guidelines will -help:</para> +<para>Anerkennung ist die hauptsächliche Währung in der Welt der freien +Software. Was immer Leute über ihre Motive für die Beteiligung an einem +Projekt sagen, ich kenne keine Entwickler die glücklich damit wären, +ihre ganze Arbeit anonym zu verrichten, oder unter dem Namen von jemand +anderem. Es gibt hierfür konkrete Gründe: Der Ruf innerhalb von einem +Projekt diktiert ungefähr wievile Einfluss man hat, und die Beteiligung +an einem Open Source Projekt kann auch einen indirekten Finanziellen +Wert haben, weil manche Arbeitgeber bei einer Bewerbun mittlerweile +danach ausschau halten. Es gibt auch vielleicht sogar noch stärkere +immaterielle Gründe: Menschen wollen einfach geschätzt werden, und +suchen instinktiv nach Zeichen, dass ihre Arbeit von anderen anerkannt +wird. Das Versprechen von Anerkennung ist desshalb eines der besten +Motivationen, die ein Projekt hat. Wenn kleine Beiträge anerkennung +finden, kommen Leute zurück um mehr zu machen.</para> + +<para>Einer der wichtigsten Funktionen von Software für die +gemeinschaftliche Entwicklung (siehe <xref +linkend="technical-infrastructure"/>) ist dass es genaue Protokolle +darüber führt, wer was wann gemacht hat. Überall wo es möglich ist, +sollten Sie bereits vorhandene Mechanismen benutzen um sicher zu +stellen, dass diese Anerkennung genau verteilt wird, und seien Sie +spezifisch, über die Natur des Beiträgs. Schreiben Sie nicht einfach +"Danke an H. Mustermann <[EMAIL PROTECTED]>" wenn Sie statt +dessen "Danke an H. Mustermann<[EMAIL PROTECTED]> für die +Bug Meldung und die Anleitung zur Reproduktion" in einem Kommentar +schreiben könnten.</para> + +<para>Bei Subversion haben wir eine informelle aber stetige Richtlinie, +denjenigen der den Bug gemeldet hat entweder in dem zugehörigen Ticket +zu würdigen oder wenn nicht, in dem Commit Kommentar der Änderung die +den Bug behebt. Eine kurze Stidie der Kommentar in der Subversion +Repository ergibt, dass mit 14525 ungefähr 10% der Änderungen jemanden +beim Namen und Email Adresse würdigt, üblicherweise die Person, welche +den Bug gemeltet oder untersucht hat welcher durch die Änderung behoben +wurde. Achten Sie darauf, dass diese Person eine andere ist als der +Entwickler ist, derjenige welcher den Commit gemacht hat, dessen Name +bereits automatisch vom Versionsverwaltungssystem erfasst wird. Von den +parr in die 80 Voll- und Teil- Commit berechtigten die Subversion heute +hat, wurden 55 in den commit Kommentaren (meistens mehrere male) vor sie +selber Committer wurden, gewürdigt. Das beweist natürlich nicht, dass +die Anerkennung ein Grund für die weitere Beteiligung war, baut aber +zumindest eine Atmosphäre auf, in dem Leute darauf zählen können, dass +ihre Beiträge gewürdigt werden.</para> + +<para>Es ist wichtig zu unterscheiden, zwischen gewöhnliche Anerkennung +und besondere Danksagungen. Wenn ein bestimmter Codeteil, oder irgend +ein anderer Beitrag den jemand geleistet hat, diskutiert wird, ist es in +ordnung ihre Arbeit zu würdigen. Wenn Sie zum Beispiel sagen "Die +kürzlichen Änderungen von Daniel an dem Delta Code bedeuten, dass wir +jetzt Funktion X implementieren können" hilft es Leute zu erkennen, um +welche Änderungen es sich dreht, und es würdigt gleichzeitig die Arbeit +von Daniel. Es dient andererseits keinen direkten praktischen Zweck, +Daniel nur für seine Änderungen an dem Delta Code zu danken. Es fügt +keine Informationen hinzu, da das Versionsverwaltungssystem und andere +Mechanismen die Tatsache aufgezeichnet hat, wer die Änderungen gemacht +hat. Jeden für alles zu danken, wäre ablenkend und würde letztendlich +frei von Informationen, da Danksagungen in so weit effektiv sind, wie +sehr sie aus den üblichen positiven Kommentaren herausragen, welche die +ganze Zeit ablaufen. Das bedeutet natürlich nicht, dass Sie niemals +Leuten danken sollten. Sorgen Sie einfach dafür, dass Sie es auf Arten +tun, die nicht zu einer Inflation der Anerkennung führen. Diese +Richtlinien zu folgen, wird helfen:</para> <itemizedlist> - <listitem><para>The more ephemeral the forum, the more free you - should feel to express thanks there. For example, - thanking someone for their bugfix in passing during an IRC - conversation is fine, as is an aside in an email devoted - mainly to other topics. But don't post an email solely to - thank someone, unless it's for a truly unusual feat. - Likewise, don't clutter the project's web pages with - expressions of gratitude. Once you start that, it'll - never be clear when or where to stop. And - <emphasis>never</emphasis> put thanks into comments in the - code; that would only be a distraction from the primary - purpose of comments, which is to help the reader - understand the code.</para> + <listitem><para>Je flüchtiger das Forum, desto freier sollten Sie + Ihren Dank ausdrücken. Jemand zum Beispiel im Vorbeigehen, + während einer Unterhaltung im IRC, für ihren Bugfix zu + danken, ist in Ordnung, genau so wie eine beiläufige + Erwähnung in einer Email die hauptsächlich anderen Themen + gewidmet ist. Schreiben Sie aber keine Email alleine um + jemanden zu Danken, es sei denn es ist für eine wirklich + ausergewöhnliche Leistung. Sie sollten gleichermaßen, nicht + die Webseiten des Projekts mit Ausdrücken von Dankbarkeit + verunstalten. Wenn Sie erst einmal damit anfangen, wird es + nie klar sein, wan oder wo man aufhören soll. Und schreiben + Sie <emphasis>niemals</emphasis> Danksagungen in den + Kommentaren des Codes; das würde nur von dem + hauptsächlichen Sinn der Kommntare ablenken, nämlich zum + besseren Verständniss des Codes.</para> </listitem> - <listitem><para>The less involved someone is in the project, the - more appropriate it is to thank her for something she - did. This may sound counterintuitive, but it fits with - the attitude that expressing thanks is something you do - when someone contributes even more than you thought she - would. Thus, to constantly thank regular contributors for - doing what they normally do would be to express a lower - expectation of them than they have of themselves. If - anything, you want to aim for the opposite effect!</para> - - <para>There are occasional exceptions to this rule. It's - acceptable to thank someone for fulfilling his expected - role when that role involves temporary, intense efforts - from time to time. The canonical example is the release - manager, who goes into high gear around the time of each - release, but otherwise lies dormant (dormant as a release - manager, in any case—he may also be an active - developer, but that's a different matter). - </para> + <listitem><para>Je weniger jemand mit dem Projekt zu tun hat, desto + angemessener ist es sie für etwas zu danken, was sie + gemacht hat. Das mag sich nicht eingängig anhören, passt + aber mit der Einstellung zusammen, dass Sie Lob ausdrücken + sollten, wenn jemand mehr beiträgt als Sie es gedacht + hätten. Es würde desshalb eine geringere Erwartung an + Personen ausdrücken, als sie selber an sich haben, wenn Sie + sich ständig für regelmäßige Beiträge bedanken, die sie + normerweise machen. Wenn überhaupt, wollen Sie das + engegengesetzte Ergebnis erzielen!</para> + + <para>Es gibt ab und zu Ausnahmen zu dieser Regel. Man kann + jemanden dafür danken seine Rolle zu erfüllen, wenn diese + Rolle von Zeit zu Zeit temporäre, intensive Anstrenungnen + erfordert. Das kanonische Beispiel ist der Versionsverwalter + welcher in einen hohen Gang wechselt, ungefähr um die Zeit + der Veröffentlichung einer neuen Verion, ansonsen aber + untätig ist (zumindest untätig als + Versionsverwalter—er kann auch als Entwickler aktiv + sein, aber das ist eine andere Angelegenheit).</para> </listitem> - <listitem><para>As with criticism and crediting, gratitude should - be specific. Don't thank people just for being great, - even if they are. Thank them for something they did that - was out of the ordinary, and for bonus points, say - exactly why what they did was so great.</para> + <listitem><para>Genau so wie Kritik und Anerkennung, sollte + Dankbarkeit so spezifisch wie möglich sein. Danken Sie Leute + nicht einfach dafür, dass sie Toll sind, selbst wenn das der + Fall ist. Danken Sie sie für etwas, dass ausergewöhnlich war + und es gibt zusätzliche Punkte, wenn Sie auch noch genau + sagen warum was sie gemacht haben so toll war.</para> </listitem> </itemizedlist> -<para>In general, there is always a tension between making sure that -people's individual contributions are recognized, and making sure the -project is a group effort rather than a collection of individual -glories. Just remain aware of this tension and try to err on the -side of group, and things won't get out of hand.</para> +<para>Im allgemeinen, gibt es immer eine Spannung dazwischen zu +gewärleiten, dass die einzelnen Beiträge anerkannt werden, und sicher zu +stellen, dass das Projekt eher eine gemeinsame Anstrenung ist als eine +Ansammlung einzelner Prachten ist. Bleiben Sie einfach im Klaren über +diese Spannung und versuchen Sie sich auf die Seite der Gruppe zu +halten, und Sachen werden nicht ausarten.</para> </sect1> <!-- ======================== SECTION ============================== --> <sect1 id="forks"> -<title>Forks</title> +<title>Abspaltungen</title> <para>In <xref linkend="forkability"/><phrase output="printed"> -in <xref linkend="social-infrastructure"/></phrase>, we saw how -the <emphasis>potential</emphasis> to fork has important effects on -how projects are governed. But what happens when a fork actually -occurs? How should you handle it, and what effects can you expect it -to have? Conversely, when should you <emphasis>initiate</emphasis> a -fork?</para> - -<para>The answers depend on what kind of fork it is. Some forks are -due to amicable but irreconcilable disagreements about the direction -of the project; perhaps more are due to both technical disagreements -and interpersonal conflicts. Of course, it's not always possible to -tell the difference between the two, as technical arguments may -involve personal elements as well. What all forks have in common is -that one group of developers (or sometimes even just one developer) -has decided that the costs of working with some or all of the others -now outweigh the benefits.</para> +im Kapitel <xref linkend="social-infrastructure"/></phrase>, haben wir +gesehen, wie das <emphasis>Potential</emphasis> für eine Abspaltung (en. +Fork) wichtige Auswirkungen darauf hat, wie ein Projekt geführt wird. +Was passiert aber, wenn eine Abspaltung wirklich stattfindet? Wie +sollten Sie damit umgehen, und welche Auswirkungen können Sie davon +erwarten? Wann sollten Sie umgekehrt, eine Abspaltung +<emphasis>anstoßen</emphasis>?</para> + +<para>Die Antworten hängen davon ab, um welche Art von Abspaltung es +sich handelt. Manche Abspaltungen sind aufgrund von freundlichen aber +unüberbrückbare Meinungsverschiedenheiten, über die Richtung des +Projekts; mehr sind vielleicht sowohl auf technische Argumente als auch +auf zwischenmenschliche Konflikte zurückzuführen. Natürlich ist es nicht +immer möglich, den Unterschied zwischen den beiden zu erkennen, da +technische Argumente auch persönliche Anteile beinhalten können. Alle +Abspaltungen haben gemeinsam, dass eine Gruppe von Entwicklern (oder +manchmal auch nur ein Entwickler) sich entschieden haben, dass die +Kosten mit manchen oder alle anderen Entwicklern zu arbeiten, jetzt +schwerer wiegen als der Nutzen.</para> <para>Once a project forks, there is no definitive answer to the question of which fork is the "true" or "original" project. People Modified: trunk/de/words.txt ============================================================================== --- trunk/de/words.txt (original) +++ trunk/de/words.txt Tue Jul 24 11:23:13 2007 @@ -31,6 +31,9 @@ einen Commit machen (alternative noun form) einchecken (german developer slang) +commit access: +Commit Zugriff + copyright: Urheberrecht @@ -57,6 +60,8 @@ verbessern ausmerzen (to fix a bug) +fork: +Abspaltung forkability: die Möglichkeit ein neues Projekt abzuspalten _______________________________________________ Producingoss-translators mailing list [email protected] http://www.red-bean.com/mailman/listinfo/producingoss-translators
