Author: mbarkhau Date: Wed Jul 25 07:53:24 2007 New Revision: 852 Log: ch08 finished
Modified: trunk/de/ch08.xml trunk/de/words.txt Modified: trunk/de/ch08.xml ============================================================================== --- trunk/de/ch08.xml (original) +++ trunk/de/ch08.xml Wed Jul 25 07:53:24 2007 @@ -1998,200 +1998,229 @@ 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 -will colloquially talk of fork F coming out of project P, as though P -is continuing unchanged down some natural path while F diverges into -new territory, but this is, in effect, a declaration of how that -particular observer feels about it. It is fundamentally a matter of -perception: when a large enough percentage of observers agree, the -assertion starts to become true. It is not the case that there is an -objective truth from the outset, one that we are only imperfectly able to -perceive at first. Rather, the perceptions <emphasis>are</emphasis> -the objective truth, since ultimately a project—or a -fork—is an entity that exists only in people's minds -anyway.</para> - -<para>If those initiating the fork feel that they are -sprouting a new branch off the main project, the perception question -is resolved immediately and easily. Everyone, both developers and -users, will treat the fork as a new project, with a new name (perhaps -based on the old name, but easily distinguishable from it), a separate -web site, and a separate philosophy or goal. Things get messier, -however, when both sides feel they are the legitimate guardians of the -original project and therefore have the right to continue using the -original name. If there is some organization with trademark rights to -the name, or legal control over the domain or web pages, that usually -resolves the issue by fiat: that organization will decide who is the -project and who is the fork, because it holds all the cards in a -public relations war. Naturally, things rarely get that far: since -everyone already knows what the power dynamics are, they will avoid -fighting a battle whose outcome is known in advance, and just jump -straight to the end.</para> - -<para>Fortunately, in most cases there is little doubt as to which is -the project and which is the fork, because a fork is, in essence, a vote -of confidence. If more than half of the developers are in favor of -whatever course the fork proposes to take, usually there is no need to -fork—the project can simply go that way itself, unless it is run -as a dictatorship with a particularly stubborn dictator. On the other -hand, if fewer than half of the developers are in favor, the fork is a -clearly minority rebellion, and both courtesy and common sense -indicate that it should think of itself as the divergent branch rather -than the main line.</para> +<para>Wenn ein Projekt sich spaltet, gibt es keine definitive Antwort +darüber, welche Abspaltung das "echte" oder "ursprüngliche" Projekt war. +Lete werden umgangssprachlich davon sprechen, dass die Abspaltung A aus +dem Projekt P kommt, als ob P weiter seinen natürlichen Lauf nimmt +wärend A in neue Gebiete divergiert, was aber im wesentlichen eine +Aussage darüber ist, wie dieser bestimmte Beobachter das Thema sieht. Es +ist im Grunde genommen eine Frage der Sichtweise: Wenn eine ausreichend +große Gruppe damit übereinstimmt, dann fängt die Behauptung an wahr zu +werden. Es ist nicht so, dass es eine objektive Wahrheit von vornherein +gibt, eine welche wir zunächst zweifelsfrei beobachten können. Sondern +vielmehr, die Auffassungen <emphasis>sind</emphasis> die objektive +Wahrheit, da ein Projekt—oder eine Abspaltung—letztendlich +eine Entität ist, die sowieso nur in den Köpfen der Menschen +existiert.</para> + +<para>Wenn diejenigen, welche die Abspaltung anstoßen das Gefühl haben, +dass sie aus dem Hauptprojekt einen neuen Ast entsprießen, ist die Frage +der Wahrnehmung sofort und einfach beantwortet. Jeder, sowohl die +Entwickler als auch die Nutzer werden die Abspaltung wie ein neues +Projekt behandeln, mit einem neuen Namen (vielleicht auf dem alten Namen +basierend, aber leicht davon zu unterscheiden), einer eigenen Webseite, +und einer anderen Philosopie oder Ziel. Die Sache wird jedoch +verwirrender, wenn beide Seiten der Meinung sind, die legitimen Wächter +des ursprünglichen Projekts zu sein und desshalb ein Recht haben, ein +Recht darauf haben, den ursprünglichen Namen zu benutzen. Wenn es eine +Organization gibt, mit Markenrechte auf den Namen, oder rechtliche +Kontrolle über die Domaine oder Webseiteb, ist die Angelegenheit +über das Recht erledigt: Diese Organization wird entscheiden wer das +Projekt ist und wer die Abspaltung, denn es hällt alle Karten in einem +Krieg um die öffentliche Wahrnehmung. Natürlich kommen die Sachen +meistens nicht so weit: Da jeder bereits weiß, wie die Machtverhältnisse +sind, werden sie es vermeiden eine Schlacht zu kämpfen, dessen Ausgang +sie bereits kennen, und einfach gleich zum Ende springen.</para> + +<para>Zum Glück, gibt es selten Zweifel darüber, welches das Projekt +ist, und welches die Abspaltung, denn eine Abspaltung ist im +wesentlichen eine Vertrauensfrage. Wenn mehr als die hälfte der +Entwickler für welche Richtung die Abspaltung auch immer vorschlägt +sind, gibt es normalerweise keinen Grund eine Abspaltung zu +machen—das Projekt kann einfach selber diese Richtung einschlagen, +es sei denn es wird als Diktatur geführt mit einem besonders sturen +Diktator. Wenn andererseits, weniger als die Hälfte dafür sind, ist die +Abspaltung eindeutig eine Rebellion einer Minderheit, und is ist sowohl +entgegenkommend, als auch vernünftig, dass es sich selber als einen +Zweig sieht, und nicht als den Stamm.</para> <sect2 id="forks-handling"> -<title>Handling a Fork</title> +<title>Umgang Mit Einer Abspaltung</title> -<para>If someone threatens a fork in your project, keep calm and -remember your long-term goals. The mere -<emphasis>existence</emphasis> of a fork isn't what hurts a project; -rather, it's the loss of developers and users. Your real aim, -therefore, is not to squelch the fork, but to minimize these harmful -effects. You may be mad, you may feel that the fork was unjust and -uncalled for, but expressing that publicly can only alienate undecided -developers. Instead, don't force people to make exclusive choices, -and be as cooperative as is practicable with the fork. To start with, -don't remove someone's commit access in your project just because he -decided to work on the fork. Work on the fork doesn't mean that -person has suddenly lost his competence to work on the original -project; committers before should remain committers afterward. Beyond -that, you should express your desire to remain as compatible as -possible with the fork, and say that you hope developers will port -changes between the two whenever appropriate. If you have -administrative access to the project's servers, publicly offer the -forkers infrastructure help at startup time. For example, offer them -a complete, deep-history copy of the version control repository, if -there's no other way for them to get it, so that they don't have to -start off without historical data (this may not be necessary depending -on the version control system). Ask them if there's anything else -they need, and provide it if you can. Bend over backward to show -that you are not standing in the way, and that you want the fork to -succeed or fail on its own merits and nothing else.</para> - -<para>The reason to do all this—and do it publicly—is not -to actually help the fork, but to persuade developers that your side -is a safe bet, by appearing as non-vindictive as possible. In war it -sometimes makes sense (strategic sense, if not human sense) to force -people to choose sides, but in free software it almost never does. In -fact, after a fork some developers often openly work on both projects, -and do their best to keep the two compatible. These developers help -keep the lines of communication open after the fork. They allow your -project to benefit from interesting new features in the fork (yes, the -fork may have things you want), and also increase the chances of a -merger down the road.</para> - -<para>Sometimes a fork becomes so successful that, even though it was -regarded even by its own instigators as a fork at the outset, it -becomes the version everybody prefers, and eventually supplants the -original by popular demand. A famous instance of this was the -GCC/EGCS fork. The <firstterm>GNU Compiler Collection</firstterm> -(<firstterm>GCC</firstterm>, formerly the <firstterm>GNU C -Compiler</firstterm>) is the most popular open source native-code -compiler, and also one of the -most portable compilers in the world. Due to disagreements between the GCC's -official maintainers and Cygnus Software,<footnote><para>Now part of -RedHat (<ulink url="http://www.redhat.com/"/>).</para></footnote> one -of GCC's most active developer groups, Cygnus created a fork of GCC -called <firstterm>EGCS</firstterm>. The fork was deliberately -non-adversarial: the EGCS developers did not, at any point, try to -portray their version of GCC as a new official version. Instead, they -concentrated on making EGCS as good as possible, incorporating patches -at a faster rate than the official GCC maintainers. EGCS gained in -popularity, and eventually some major operating system distributors -decided to package EGCS as their default compiler instead of GCC. At -this point, it became clear to the GCC maintainers that holding on to -the "GCC" name while everyone switched to the EGCS fork would burden -everyone with a needless name change, yet do nothing to prevent the -switchover. So GCC adopted the EGCS codebase, and there is once again -a single GCC, but greatly improved because of the fork.</para> - -<para>This example shows why you cannot always regard a fork as an -unadulteratedly bad thing. A fork may be painful and unwelcome at the -time, but you cannot necessarily know whether it will succeed. -Therefore, you and the rest of the project should keep an eye on it, -and be prepared not only to absorb features and code where possible, -but in the most extreme case to even join the fork if it gains the -bulk of the project's mindshare. Of course, you will often be able to -predict a fork's likelihood of success by seeing who joins it. If the -fork is started by the project's biggest complainer and joined by a -handful of disgruntled developers who weren't behaving constructively -anyway, they've essentially solved a problem for you by forking, and -you probably don't need to worry about the fork taking momentum away -from the original project. But if you see influential and respected -developers supporting the fork, you should ask yourself why. Perhaps -the project was being overly restrictive, and the best solution is to -adopt into the mainline project some or all of the actions -contemplated by the fork—in essence, to avoid the fork by -becoming it.</para> +<para>Wenn jemand droht von ihrem Projekt eine Abspaltung zu machen, +bleiben Sie ruhig und denken Sie an Ihre längerfristigen Ziele. Die +bloße <emphasis>Existenz</emphasis> einer Abspaltung ist es nicht, was +einem Projekt schadet; vielmehr ist es der Verlust von Entwickler und +Nutzer. Ihr echtes Ziel ist es desshalb nicht, die Abspaltung zu +unterdrücken, sondern diese schädlichen Auswirkungen zu minimieren. Sie +können darüber sauer sein, oder der Meinung sein, dass die Abspaltung +nicht gerecht und unprovoziert war, das aber öffentlich äußern kann +einzig und alleine unentschlossene Entwickler entfremden. Statt dessen, +sollten Sie Leute nicht dazu zwingen, exklusive Entscheidungen zu +treffen, und so kooperativ sein, wie es bei einer Abspaltung machbar +ist. Als erstes, sollten Sie nicht die commit Berechtigung zu ihrem +Projekt von jemandem zurücknehmen, der sich entschieden hat an der +Abspaltung zu arbeiten. Arbeit an der Abspaltung bedeutet nicht, dass +die Person plötzlich seine Kompetenz an dem ursprünglichen Projekt zu +arbeiten verloren hat; vorherige Committer sollten auch nacher Committer +sein. Darüber hinaus, sollten Sie Ihr Wunsch ausdrücken, so kompatibel +wie möglich mit der Abspaltung zu bleiben ausdrücken und sagen, dass Sie +hoffen, dass die Entwickler die Änderungen zwischen beiden übernehmen +wenn es angemessen ist. Wenn Sie administrativen Zugriff auf die Server +des Projekts haben, sollten Sie der Abspaltung am Anfang öffentlich +Hilfe bei der Infrastruktur anbieten. Bieten Sie ihnen zum Beispiel, +eine Kopie der Repository an, mit der kompletten Historie, wenn es keine +andere Möglichkeit für sie gibt, dran zu kommen, damit sie nicht ohne +die historischen Daten anfangen müssen (das muss je nach +Versionsverwaltungssystem nicht unbedingt notwendig sein). Fragen Sie +danach, ob es irgend etwas anderes gibt, was sie brauchen und geben Sie +es ihene wenn möglich. Reißen Sie sich ein Bein aus, um zu zeigen, dass +Sie ihnen nicht im Weg stehen, und dass Sie wollen, dass die Abspaltung +nach seinen eigenen Verdiensten Erfolg hat oder Fehl schlägt und sonst +nichts.</para> + +<para>Der Grund all das zu tun—und es öffentlich zu machen— +ist nicht wirklich um der Abspaltung zu helfen, sondern um die Enwickler +zu überreden, dass Ihre Seite eine sichere Sache ist, indem Sie +möglichst nicht als rachsüchtig erscheinen. In einem Krieg machte es +manchmal Sinn (aus strategischer Sicht, wenn auch nicht aus menschlicher +Sicht) Leute dazu zu zwingen eine Seite zu wählen, bei freier Software +macht es jedoch fast niemals Sinn. Nach einer Abspaltung arbeiten manche +Entwickler sogar offen an beiden Projekten, und versuchen ihr +möglichstes um beide kompatibel zu halten. Diese Entwickler helfen die +Kommunikationsphade nach der Abzweigungung offen zu halten. Sie erlauben +es ihrem Projekt von den Interessanten neuen Funktionen in der +Abzweigung zu profitieren (ja, die Abzweigung kann Sachen haben, welche +Sie haben wollen), und später die Wahrscheinlichkeit einer +Zusammenführung vergrößern.</para> + +<para>Manchmal wird eine Abzweigung derart erfolgreich, dass auch wenn +es selbst von seinen Anstiftern zum Beginn als solches angesehen wurde, +es zu der Version wird, die jeder bevorzugt, und letztendlich das +Original aufgrund der großen Nachfrage ersetzt. Ein berühmtes Beispiel +hierfür war die GCC/EGCS Abzweigung. Die <firstterm>GNU Compiler +Collection</firstterm> (<firstterm>GCC</firstterm>, vorher der +<firstterm>GNU C Compiler</firstterm>) ist der beliebteste Open Source +Compiler für nativen Code und auch einer der portabelsten Compiler der +Welt. Aufgrund von Meinungsverschiedenheiten zwischen den Personen die +es offiziell pflegten, und Cygnus Software,<footnote><para>Jetzt ein +Teil von RedHat (<ulink url="http://www.redhat.com/"/>).</para> +</footnote> einer der aktivsten Entwickler von GCC, machte Cygnus eine +Abzweigung von GCC namens <firstterm>EGCS</firstterm>. Die Abzweigung +war absichtlich nicht feindlich gesinnt: Die EGCS Entwickler versuchten +nicht, zu irgend einem Zeitpunkt, ihre Version von GCC als die neue +ofizielle Version darzustellen. Statt dessen, konzentrierten sie sich +darauf, EGCS so gut wie möglich zu machen, und Patches schneller +einzubinden, als die offiziellen Entwickler von GCC. EGCS wurde +beliebter, und irgendwann entschieden sich einige größere Vertreiber von +Betriebssystemen EGCS anstatt von GCC als ihren standard Compiler +auszuliefern. Zu diesem Zeitpunkt, wurde es für alle bei GCC klar, dass +an dem Namen "GCC" festzuhalte, wärend jeder zu der EGCS Abzweigung +wechselte, jedem eine unnötigen Namensänderung auferlegen würde, aber +nichts machen würde, um den Wechsel zu verhindern. GCC übernahm also den +Code von EGCS und es gab wieder eine einzige GCC, nun aber durch die +Abzweigung wesentlich verbessert.</para> + +<para>Dieses Beispiel zeigt, warum Sie eine Abzweigung nicht immer als +etwas ganz und gar schlechtes betrachten können. Eine Abzweigung mag zu +der Zeit etwas schmerzhaft und unwillkommen sein, Sie können aber nicht +unbedingt absehen ob es Erfolg haben wird. Sie und das übrige Projekt +sollten desshalb ein Auge darauf halten, und bereit sein nicht nur alle +Funktionen und Code aufzunehmen, wo es möglich ist, sonder im +extreemsten Fall sogar der Abzweigung beizutreten wenn es den größten +Teil der Aufmerksamkeit des Projekts einnimmt. Sie werden natürlich oft +in der Lage sein den wahrscheinlichen Erfolg einer Abzweigung abzusehen, +jenachdem wer ihm beitritt. Wenn die Abzweigung von dem größten Kläger +im Projekt angefangen wird und von einer Handvoll verärgerten Entwickler +die sich sowieso nicht konstruktiv verhalten haben, haben Sie im +wesentlichen für Sie das Problem, durch die Abzweigung, erledigt, und +Sie müssen sich wahrscheinlich keine Sorgen machen, dass es vom +ursprünglichen Projekt irgend welche Schwung wegnimmt. Wenn Sie jedoch +sehen, wie einflussreiche und geachtete Entwickler die Abzweigung +unterstützen, sollten Sie sich fragen warum. Vielleicht is das Projekt +übermäßig restriktiv gewesen, und die Beste Lösung ist es einige oder +alle Maßnahmen die von der Abzweigung erwägt werden in das Hauptprojekt +einzubinden—im Wesentlich vermeiden Sie die Abspaltung indem Sie +zu ihm werden.</para> </sect2> <sect2 id="forks-initiating"> -<title>Initiating a Fork</title> +<title>Anstoßung einer Abspaltung</title> -<para>All the advice here assumes that you are forking as a last -resort. Exhaust all other possibilities before starting a fork. -Forking almost always means losing developers, with only an uncertain -promise of gaining new ones later. It also means starting out with -competition for users' attention: everyone who's about to download the -software has to ask themselves: "Hmm, do I want that one or the other -one?" Whichever one you are, the situation is messy, because a -question has been introduced that wasn't there before. Some people -maintain that forks are healthy for the software ecosystem as a whole, -by a standard natural selection argument: the fittest will survive, -which means that, in the end, everyone gets better software. This may -be true from the ecosystem's point of view, but it's not true from the -point of view of any individual project. Most forks do not succeed, -and most projects are not happy to be forked.</para> - -<para>A corollary is that you should not use the threat of a fork as -an extremist debating technique—"Do things my way or I'll fork -the project!"—because everyone is aware that a fork that fails -to attract developers away from the original project is unlikely to -survive long. All observers—not just developers, but users and -operating system packagers too—will make their own judgement about -which side to choose. You should therefore appear extremely reluctant -to fork, so that if you finally do it, you can credibly claim it was -the only route left.</para> - -<para>Do not neglect to take <emphasis>all</emphasis> factors into -account in evaluating the potential success of your fork. For -example, if many of the developers on a project have the same -employer, then even if they are disgruntled and privately in favor of -a fork, they are unlikely to say so out loud if they know that their -employer is against it. Many free software programmers like to think -that having a free license on the code means no one company can -dominate development. It is true that the license is, in an ultimate -sense, a guarantor of freedom—if others want badly enough to -fork the project, and have the resources to do so, they can. But in -practice, some projects' development teams are mostly funded by one -entity, and there is no point pretending that that entity's support -doesn't matter. If it is opposed to the fork, its developers are -unlikely to take part, even if they secretly want to.</para> - -<para>If you still conclude that you must fork, line up support -privately first, then announce the fork in a non-hostile tone. Even -if you are angry at, or disappointed with, the current maintainers, -don't say that in the message. Just dispassionately state what led -you to the decision to fork, and that you mean no ill will toward the -project from which you're forking. Assuming that you do consider it a -fork (as opposed to an emergency preservation of the original -project), emphasize that you're forking the code and not the name, and -choose a name that does not conflict with the project's name. You can -use a name that contains or refers to the original name, as long as it -does not open the door to identity confusion. Of course it's fine to -explain prominently on the fork's home page that it descends from the -original program, and even that it hopes to supplant it. Just don't -make users' lives harder by forcing them to untangle an identity -dispute.</para> - -<para>Finally, you can get things started on the right foot by -automatically granting all committers of the original project commit -access to the fork, including even those who openly disagreed with the -need for a fork. Even if they never use the access, your message is -clear: there are disagreements here, but no enemies, and you welcome -code contributions from any competent source.</para> +<para>Alle Ratschläge hier, gehen davon aus, dass Sie als letztes Mittel +eine Abspaltung machen. Nutzen Sie alle anderen Möglichkeiten vor Sie +eine Abspaltung anfangen. Es bedeutet fast immer Entwickler zu +verlieren, lediglich mit einem ungewissen Versprechen, später neue zu +bekommen. Es bedeutet auch mit einem Wettbewerb um die Aufmerksamkeit +der Nutzer anzufangen: Jeder der dabei ist die Software herunterzuladen, +wird sich fragen müssen: "Hmm, will ich diesen oder den anderen?" +Welcher auch immer Sie sind, die Situation ist chaotisch, da eine Frage +entsteht, die vorher nicht da war. Manche Leute behaupten nach dem +üblichen Argument der natürlichen Auslese, dass Abspaltungen für das +Ökosystem der Software als Gesamtes gesund ist: Die Tüchtigsten +überleben, was letztendlich bedeutet, dass jeder bessere Software +bekommt. Das mag aus Sicht des Ökosystems wahr sein, ist aber nicht aus +Sicht eines einzelnen Projekts. Die meisten Abspaltungen sind nicht +erfolgreich und die meisten Projekte sind mit einer Abspaltung nicht +glücklich.</para> + +<para>Damit einher geht, dass Sie die Drohung eine Abspaltung zu machen, +bei einer Debatte nicht als extreme Technik benutzen +sollten—"Macht die Sache auf meine Art, oder ich werde das eine +Abspaltung vom Projekt machen!"—da jeder sich darüber im klaren +ist, dass eine Abspaltung welche es nicht schafft Entwickler von dem +ursprünglichen Projekt anzulocken, wahrscheinlich nicht lange überleben +wird. Alle Beobachter—nicht nur die Entwickler, sondern auch die +Nutzer und die Packet Verwalter der Betriebssysteme—werden ihr +eigenes Urteil darüber machen welche Seite sie wählen. Sie sollten +desshalb sehr abgeneigt zu einer Abspaltung erscheinen, damit wenn Sie +es letztendlich doch machen, Sie glaubhaft behaupten können, dass es +der einzige übrige Weg war.</para> + +<para>Vergessen Sie nicht <emphasis>alle</emphasis> Faktoren bei der +evaluierung des möglichen Erfolgs von Ihrer Abspaltung in erwägung zu +ziehen. Wenn zum Beispiel viele der Entwickler in einem Projekt den +gleiche Arbeitgeber haben, dann werden sie, selbst wenn Sie verärgert +sind, und im privaten für eine Abspaltung sind, es wahrscheinlich nicht +laut sagen, wenn Sie wissen, dass ihr Arbeitgeber dagegen ist. Viele +Programmierer freie Software denken gerne, dass eine freie Lizensierung +des Codes bedeutet, dass keine eine Firma die Entwicklung dominieren +kann. Es ist wahr, dass die Lizenz, im letztendlichen Sinne die +Freiheit garantiert—wen andere dringend genug das Projekt +Abspalten wollen, und die Resourcen dazu haben, können sie das. In der +Praxis sind die Entwicklermannschaften mancher Projekte größtenteils +durch ein Unternehmen finanziert, und es hat keine Sinn so zu tun, als +ob die Unterstützung dieses Unternehmens keinen Unterschied macht. Wenn +es die Abspaltung ablehnt, werden seine Entwickler wahrscheinlich nicht +daran teilnehmen, selbst wenn sie es insgeheime wollen.</para> + +<para>Wenn Sie trotzdem zu dem Schluss kommen, das Sie eine Abspaltung +machen müssen, sollten Sie zunächst im privaten dafür Unterstützung +sammeln, und es dann in einem nicht feintlichen Ton bekannt geben. +Selbst wenn Sie wütend oder entäuscht von den derzeitigen Verwaltern +sind, sollten Sie es nicht in der Nachricht sagen. Halten Sie einfach +leidenschaftslos fest, war Sie zu der Entscheidung geführt hat, und dass +Sie gegenüber dem Projekt von dem Sie abspalten, keine Böswilligkeit +hegen. Angenommen, Sie betrachten es als eine Abspaltung (im Gegensatz +zu einer notgedrungenen Erhaltung des ursprünglichen Projekts), sollten +Sie hervorheben, dass Sie den Code und nicht den Namen Abspalten, und +wählen Sie einen namen, der nicht mit dem des ursprünglichen Projekts +im Konflikt tritt. Sie können einen Namen wählen, welcher den +ursprünglichen beinhaltet oder darauf verweist, so lange es nicht ein +Tor für Verwirrung zwischen beiden aufmacht. Es ist natürlich in Ordnung +markant auf der Webseite der Abspaltung zu erklären, dass es von dem +ursprünglichen Projekt abstammt, und dass es hofft es zu ersetzen. +Machen Sie nur nicht das Leben der Nutzer schwieriger indem Sie sie dazu +zwingen einen Streit um die Identität auseinanderzufuseln.</para> + +<para>Letztlich, können Sie die Sachen einen guten Start geben, indem +Sie automatisch allen Entwicklern des ursprünglichen Projekts commit +Rechte zu der Abspaltung geben, inklusive denen die nicht der +Notwendigkeit einer Abspaltung zustimmten. Selbst wenn sie niemals den +Zugang benutzen, ist Ihre Nachricht klar: Es gibt hier +Meinungsverschiedenheiten, aber keine Feinde, und Sie heißen Beiträge +aus jeder kompetenten Quelle wilkommen.</para> </sect2> Modified: trunk/de/words.txt ============================================================================== --- trunk/de/words.txt (original) +++ trunk/de/words.txt Wed Jul 25 07:53:24 2007 @@ -84,6 +84,10 @@ Verteiler (shorter when context is clear) Mailingliste +maintainer: +Hauptentwickler (?) +Verwalter (?) + to maintain: pflegen warten _______________________________________________ Producingoss-translators mailing list [email protected] http://www.red-bean.com/mailman/listinfo/producingoss-translators
