Author: mbarkhau Date: Sun Aug 12 13:37:30 2007 New Revision: 962 Log: finished review of ch02
Modified: trunk/de/ch02.xml Modified: trunk/de/ch02.xml ============================================================================== --- trunk/de/ch02.xml (original) +++ trunk/de/ch02.xml Sun Aug 12 13:37:30 2007 @@ -1566,81 +1566,80 @@ <!-- ======================== SECTION ============================== --> <sect2 id="opening-closed-projects"> -<title>Wenn Sie ein Vorher Geschlossenes Projekt Öffnen, Seien Sie -Sensibel für den Umfang der Veränderungen.</title> +<title>Beim öffnen ehemals geschlossener Projekt, achte auf den Umfang +der Änderungen</title> -<para>Wenn Sie ein existierendes Projekt öffnen, welches bereits -aktiver Entwickler hat, die an einer Closed Source Umgebung -gewohnt sind, stellen Sie sicher, dass jeder versteht, dass eine -große Veränderung auf Sie zukommt-und stellen Sie sicher, dass -Sie wissen wie es sich aus Ihrer Sicht anfühlen wird.</para> - -<para>Versuchen Sie sich vorzustellen, wie die Situation für sie -aussieht: vorher wurden Code und Design Entscheidungen mit einer -Gruppe anderer Programmierer getroffen, die alle mehr oder weniger -gleich gut die Software kannten, die alle den gleichen Druck von der -Verwaltung zu spüren bekamen und die alle gegenseitig ihre Stärken -und Schwächen kannten. Jetzt verlangen Sie von ihnen ihren Code für -die Prüfung durch irgend welche Fremde frei zu geben, die ihre -Meinungen nur auf Grund von Code bilden werden, ohne zu wissen welcher -geschäftlicher Druck zu bestimmten Entscheidungen gezwungen hat. Diese -Fremde werden viele Fragen stellen, Fragen die vorhandene Entwickler -aufrütteln werden, wenn Sie feststellen müssen, dass die Dokumentation -an der sie so hart gearbeitet haben <emphasis>immer noch</emphasis> -unzureichend ist (was unvermeidbar ist). Um dem ganzen noch ein -Sahnehäubchen zu geben sind die Neuankömmlinge unbekannte, -Gesichtslose Wesen. Wenn einer ihrer Entwickler sich bereits im -Bezug auf seine Programmierfähigkeiten unsicher ist, stellen Sie sich -vor, wie es ihn verbittern wird, wenn die Neuankömmlinge auf Mängel im -Code den er geschrieben hat hinweisen und schlimmer noch es vor seinen -Kollegen tun. Es sei denn Sie haben ein Mannschaft perfekter -Programmierer, ist es Unvermeidbar-tatsächlich wird es am Anfang -wahrscheinlich allen passieren. Nicht weil sie schlechte Programmierer -sind; sondern weil jedes Projekt, welches eine über einer bestimmten -Größe wächst, Bugs hat und der Peer Review wird manche dieser Bugs -bemerken (siehe <xref linkend="code-review"/> -<phrase output="printed"> in einem früheren Abschnitt dieses Kapitels -</phrase>). Gleichzeitig werden die neuen Freiwilligen selbst nicht -so sehr dieser Prüfung unterliegen da sie keinen Code selbst -beisteuern können bis sie mehr mit dem Projekt vertraut sind. Für Ihre -Entwickler kann es sich so anfühlen als ob die ganze Kritik immer nur -herein kommt und nie nach außen geht. Es besteht deshalb die Gefahr, -dass sich eine Belagerungsmentalität unter den alten Händen -einstellt.</para> - -<para>Der beste Weg dies zu verhindern, ist alle zu warnen, was auf -Sie zukommt, erklären Sie es ihnen, sagen Sie ihnen, dass das erste -Unbehagen völlig normal ist und versichern Sie ihnen das alles besser -wird. Manche dieser Warnungen sollten im privaten geschehen, vor das -Projekt geöffnet wird. Sie könnten es aber auch hilfreich finden, die -Leute auf der Mailing List daran zu erinnern, dass es für das Projekt -eine neue Art der Entwicklung ist und dass die Anpassung eine weile -dauern wird. Das beste was Sie machen können ist als gutes Beispiel -voran zu gehen. Wenn Sie sehen, dass Ihre Entwickler nicht genügend -Newbie-Fragen beantworten, hilft es nicht es ihnen zu sagen, dass sie -mehr beantworten sollen. Sie mögen kein gutes Gefühl dafür haben, wann -eine Reaktion gerechtfertigt ist, oder es kann sein dass Sie nicht -wissen wie sie die Arbeit am Code gegen der neuen Bürde der externen -Kommunikation priorisieren sollen. Der beste Weg sie dazu zu bringen -sich zu beteiligen, ist sich selber zu beteiligen. Seien auf der -öffentlichen Mailing List anwesend und beantworten Sie ein paar Fragen. -Wenn Sie nicht genügend Erfahrung haben um die Fragen decken zu können, -geben Sie es für alle sichtbar an einem anderen Entwickler weiter, der -die Erfahrung dazu hat— und achten Sie darauf, dass er darauf -zurück antwortet oder zumindest eine Reaktion gibt. Natürlich wird es -für die älteren Entwickler verlockend sein, in private Diskussionen -zu verfallen, schließlich sind sie daran gewohnt. Stellen Sie sicher -dass Sie auf der internen Mailing List sind, auf der das passieren -könnte, damit Sie darum bitten können, dass diese Diskussionen sofort -auf die öffentlichen listen verlagert werden können.</para> +<para>Wenn Sie ein bestehendes Projekt öffnen, welches bereits aktive +Entwickler hat, die an einer Umgebung mit geschlossenem Code gewohnt +sind, sorgen Sie dafür, dass allen klar ist, dass eine große +Veränderung auf Sie zukommt—und versuchen Sie sich so weit wie +möglich in ihre Lage zu versetzen.</para> + +<para>Versuchen Sie sich die Situation aus ihrer Sicht vorzustellen: +vorher wurden Entscheidungen über Code und Architechtur in einer Gruppe +von Programmierern getroffen, die sich alle mehr oder weniger gleich +gut mit der Software auskannten, die alle den gleichen Druck von der +Verwaltung zu spüren bekamen und die alle ihre gegenseitigen Stärken +und Schwächen kannten. Jetzt verlangen Sie von ihnen ihren Code +freizugeben nur damit irgend welche Fremde es auseinandernehmen, es +untersuchen und ihre Meinungen allein anhand von Quellcode bilden, ohne +zu wissen welcher geschäftlicher Druck Sie zu bestimmten Entscheidungen +gezwungen hat. Diese Fremde werden viele Fragen stellen, Fragen die +vorhandene Entwickler aufrütteln werden, wenn Sie feststellen müssen, +dass die Dokumentation an der sie so hart gearbeitet haben +<emphasis>immer noch</emphasis> lückenhaft ist (das ist unvermeidbar). +Um dem ganzen noch ein Sahnehäubchen zu geben, sind die Neulinge +unbekannte, gesichtslose Wesen. Wenn einer Ihrer Entwickler sich seiner +Programmierfähigkeiten unsicher ist, stellen Sie sich vor wie es ihn +erst verbittern wird, wenn die Neulinge auf Mängel im Code hinweisen, +den er geschrieben hat, schlimmer noch vor seinen Kollegen. Wenn Sie +keine Mannschaft perfekter Programmierer haben, ist sowas +unvermeidlich—tatsächlich wird es am Anfang wahrscheinlich allen +passieren. Nicht weil sie schlechte Programmierer sind; sondern weil +jedes Projekt über einer bestimmten Größe Fehler beinhaltet und die +Überprüfung durch die Gemeinschaft wird manche dieser Fehler aufdecken +(siehe <xref linkend="code-review"/> <phrase output="printed"> früher +in diesem Kapitel</phrase>). Gleichzeitig werden die neuen Freiwilligen +selber nicht so sehr dieser Prüfung unterliegen da sie selber noch +keinen Code beisteuern können, bis sie mehr mit dem Projekt vertraut +sind. Für Ihre Entwickler kann kann das so sein als ob die ganze Kritik +immer nur auf sie gerichtet ist und nie nach außen geht. Es besteht +deshalb die Gefahr, dass sich unter den alten Händen eine +Belagerungsmentalität einstellt.</para> + +<para>Am besten kann man das verhindern, indem man alle vorwarnt, was +auf Sie zukommt, es ihnen erklärt, ihnen sagt, dass ein anfängliches +Unbehagen völlig normal ist und sie zu versichern, dass es mit der Zeit +besser wird. Manche dieser Warnungen sollten privat geschehen, vor das +Projekt geöffnet wird. Es könnte aber auch hilfreich sein, die Leute +auf dem E-Mail Verteiler zu erinnern, dass es für das Projekt eine neue +Art der Entwicklung ist und dass die Anpassung eine gewisse Zeit +brauchen werden. Das beste was Sie machen können ist als gutes Beispiel +voranzugehen. Wenn Sie sehen, dass Ihre Entwickler nicht genügend +Fragen der neuen Freiwilligen beantworten, nützt es nichts ihnen zu +sagen, dass sie mehr antworten sollen. Es mag sein, dass sie kein gutes +Gefühl dafür haben, wann eine Reaktion gerechtfertigt ist, oder es kann +sein dass Sie nicht wissen wie sie Arbeit am Code gegen der neuen Bürde +der externen Kommunikation priorisieren sollen. Man kann sie am ehesten +dazu überreden sich zu beteiligen, indem man sich selber beteiligt. +Beobachten Sie den öffentlichen Verteiler und beantworten Sie ein paar +Fragen. Wenn Sie nicht genügend Erfahrung haben um die Fragen zu +beantworten, sollten Sie es für alle sichtbar an einem anderen +Entwickler weitergeben, der die nötige Erfahrung hat—und achten +Sie darauf, dass er eine Antwort oder zumindest eine Reaktion gibt. +Natürlich wird es für die älteren Entwickler verlockend sein, in +private Diskussionen zu verfallen, schließlich sind sie daran gewohnt. +Beobachten Sie desshalb auch den Verteiler im Betrieb und bitten Sie +ggf. darum darum, dass diese Diskussionen gleich auf den öffentlichen +Verteiler verlagert werden.</para> <para>Es gibt andere, langfristige Bedenken beim öffnen vorher geschlossener Projekte. <xref linkend="social-infrastructure"/> untersucht Techniken um bezahlte und unbezahlte Entwickler erfolgreich zu mischen und <xref linkend="legal"/> behandelt die nötige rechtliche -Sorgfalt, beim öffnen von privatem Code, welches unter Umständen -Software beinhaltet, dass von anderen Parteien oder geschrieben wurde -oder ihnen "gehört".</para> +Sorgfalt beim öffnen von privatem Code, welches u.U. Software +beinhaltet, dass von anderen Parteien geschrieben wurde oder ihnen +"gehört".</para> </sect2> @@ -1651,112 +1650,109 @@ <sect1 id="announcing"> <title>Bekanntmachung</title> -<para>Wenn das Projekt vorzeigbar ist—nicht perfekt, lediglich -vorzeigbar— sind Sie dazu bereit es der Welt bekannt zu machen. -Tatsächlich ist dies ein relativ einfacher Prozess: gehen Sie nach -<ulink url="http://freshmeat.net/"/>, klicken Sie auf <guimenuitem> -Submit</guimenuitem> in der oberen Navigations Leiste, und füllen Sie -das Formular aus welches Ihr Projekt bekannt zu machen. Freshmeat ist -der Ort, auf den jeder schaut für neue Projekt Ankündigungen. Sie -müssen dort nur ein paar Augen erwischen, damit die Nachricht mittels -Mundpropaganda verbreitet wird.</para> +<para>Sobald das Projekt in einem vorzeigbarem Zustand ist—nicht +perfekt, lediglich vorzeigbar— sind Sie bereit es der Welt +bekanntzumachen. Tatsächlich geht das relativ einfach: Gehen Sie auf +<ulink url="http://freshmeat.net/"/>, klicken Sie in der oberen +Navigationsleiste auf <guimenuitem>Submit</guimenuitem> und füllen Sie +das Formular aus um Ihr Projekt bekanntzumachen. Freshmeat ist der Ort +auf dem alle schauen für Ankündigungen über neue Projekte. Sie müssen +dort nur ein paar Augen erwischen und ihre Nachricht wird sich ab da +über Mundpropaganda weiterverbreiten.</para> -<para>Wenn Sie Mailing Listen oder Newsgroups kennen, auf denen eine +<para>Wenn Sie E-Mail Verteiler oder Newsgroups kennen, auf denen eine Ankündigung Ihres Projekts zu Thema passen würde und von Interesse -wäre, dann machen Sie dort einen Eintrag, aber seien Sie vorsichtig, -genau <emphasis>einen</emphasis> Eintrag pro Forum zu machen, und -richten Sie die Leute auf Ihre eigenen Foren wenn für Diskussionen -die daran anschließen (indem Sie die <systemitem>Reply-to</systemitem> -Einstellung setzen). Die Einträge sollten kurz sein, und gleich zur -Sache kommen:</para> +wäre, dann machen Sie dort einen Eintrag, achten Sie aber darauf genau +<emphasis>einen</emphasis> Eintrag pro Forum zu machen, und weisen Sie +die Leute auf Ihre eigenen Foren für weitere Diskussionen die daran +anschließen (indem Sie den <systemitem>Reply-to</systemitem> +Header setzen). Die Einträge sollten kurz und prägnant sein:</para> <screen> -To: [EMAIL PROTECTED] -Subject: [ANN] Scanley Volltext indizierungs Projekt -Reply-to: [EMAIL PROTECTED] - -Dies ist eine einmaliger Eintrag um die Gründung des Scanly Projekts, -bekannt zu machen, welches eine Open Source Volltextindizierungs- und -Suchmaschine ist, mit einer reichen API für die Benutzung durch -Programmierer um Suchfunktionen für große Sammlungen von Text-Dateien -zur Verfügung zu stellen. Scanley ist funktionierender Code, wird -aktiv entwickelt und ist auf der suche nach Entwickler und Beteiligte -zum Testen. +An: [EMAIL PROTECTED] +Betreff: [ANN] Das Scanley Projekt für Volltext Indizierung +Antwort-An: [EMAIL PROTECTED] + +Diese Nachricht ist ein einmaliger Eintrag über die Gründung des Scanly +Projekts, eine Open Source Volltextindizierungs- und Suchmaschine, mit +einer reichen API für Programmierer die Suchfunktionen für große Mengen +an Text implementieren wollen. Der Code von Scanley läuft, wird aktiv +entwickelt und wir suchen sowohl nach Entwickler als auch Beteiligte +die Testen wollen. -Home page: http://www.scanley.org/ +Webseite: http://www.scanley.org/ Funktionen: - Durchsucht Klartext, HTML, und XML - Suche nach Wörter oder Ausdrücken - (geplant) Unscharfe suche - (geplant) Inkrementelle Aktualisierung der Indizes - - (geplant) Indexierung entfernter Webseiten + - (geplant) Indizierung von Webseiten -Anforderungen: - - Python 2.2 oder höher - - Genügend Festplatten Speicher um die Indizes zu speichern (ca doppelter - Speicherplatz, der ursprünglichen Daten) +Vorraussetzungen: + - Python 2.2 oder neuer + - Genügend Festplattenplatz für di Indizes (ca. 2x die Größe der + ursprünglichen Daten) -Mehr Informationen, finden Sie auf scanley.org. +Weiteres finden Sie auf scanley.org. Vielen Dank, --J. Zufall +-H. Mustermann </screen> <para>(Siehe <xref linkend="publicity"/><phrase output="printed"> im Kapitel <xref linkend="communications"/></phrase> für Ratschläge -zur Bekanntmachung anderer Releases und Ereignisse Ihres Projekts.) -</para> +über die Bekanntmachung neuer Versionen und andere Ereignisse in Ihrem +Projekt.)</para> -<para>Es gibt eine andauernde Diskussion in der Free Software -Gemeinschaft darüber, ob es nötig ist ein Projekt mit laufendem Code -anzufangen, oder ob ein Projekt davon profitieren kann, selbst -während der Entwurfs und Diskussionsphase geöffnet zu werden. -Ich dachte früher, dass es der wichtigste Faktor wäre, mit laufendem -Code anzufangen, dass es das war was die erfolgreichen Projekte von -dem Spielzeug trennt und dass ernst zu nehmende Entwickler nur etwas -anfassen würden, was bereits etwas greifbares machte.</para> - -<para>Es stellte sich heraus, dass dies nicht der Fall ist. In dem -Subversion Projekt, fingen wir mit einem Entwurfs Dokument an, ein -Kern interessierter und gut verbundener Entwickler, viel Fanfare und -überhaupt <emphasis>keinen</emphasis> laufenden Code. Zu meiner -völligen Überraschung, erhielt das Projekt von Anfang an aktive -Freiwillige anzulocken und bis wir tatsächlich etwas laufendes hatten, -waren bereits eine ziemliche Menge freiwilliger Entwickler beteiligt. -Subversion ist da nicht das einzige Beispiel; das Mozilla Projekt -wurde auch ohne laufenden Code gestartet und es ist jetzt ein -erfolgreicher Web Browser.</para> - -<para>Angesichts solcher Beweise, muss ich von meiner Feststellung -zurücktreten, dass Laufender Code absolut notwendig ist um ein -Projekt zu starten. Laufender Code ist immer noch eines der besten -Grundlagen für Erfolg, und eine gute Grundregel wäre so lange zu -warten, bis Sie es haben, bevor Sie das Projekt Bekannt geben. Es -mag allerdings Umstände geben bei dem eine frühere Bekanntmachung -Sinn macht. Ich denke, dass zumindest eine gut ausgearbeitetes -Entwurfs Dokument, oder irgend einer Art Code Framework notwendig ist -—Natürlich mag es auf Grund von öffentlichen Rückmeldungen -überarbeitet werden, aber muss etwas festes sein, etwas greifbareres -als gute Absichten, wo Leute sich reinbeissen können.</para> - -<para>Wenn Sie die Bekanntmachung machen, erwarten Sie jedoch keinen -Schar Freiwilliger gleich danach. Für gewöhnlich ist das Resultat -einer Bekanntmachung, dass Sie ein paar beiläufige Anfragen bekommen, -noch ein paar melden sich auf der Mailing List an, abgesehen davon, -geht alles so ziemlich wie bisher weiter. Mit der Zeit aber werden -Sie eine stätige Zunahmen der Beiträge bemerken, sowohl von neuen -Beteiligten, so wie von Benutzern. Die Bekanntmachung ist lediglich -das Pflanzen eines Samenkorns. Es kann eine lange Zeit dauern, bis -die Nachricht sich verbreitet hat. Wenn das Projekt konsequent -diejenigen Belohnt, die sich Beteiligen, wird sich die Nachricht -verbreiten, da Menschen mit einander teilen wollen, wenn sie etwas -gutes gefunden haben. Wenn alles gut geht, wird die Dynamik der -exponenziellen Kommunikationsnetze langsam das Projekt, in eine -komplexe Gemeinschaft verwandeln, indem Sie nicht unbedingt den Namen -von jedem kennen und nicht länger jede Unterhaltung mit verfolgen -können. In den nächsten Kapiteln, geht es darum in solch einer -Umgebung zu arbeiten.</para> +<para>Es gibt eine noch laufende Diskussion in Open Source Gemeinschaft +darüber, ob es nötig ist, dass ein Projekt schon am Anfang laufenden +Code hat oder ob es einem Projekt hilft, selbst während des Entwurfs +offen zu sein. Ich dachte früher, dass es am aller wichtigsten war mit +laufendem Code anzufangen, dass man so erfolgreiche Projekte von dem +Spielzeug unterscheiden konnte und dass ernstzunehmende Entwickler nur +etwas anfassen würden, was was auch schon etwas handfestes +machte.</para> + +<para>Wie es sich herausstellte, war das nicht der Fall. Beim +Subversion Projekt, fingen wir mit einem Entwurf an, ein Kern +interessierter und miteinander vertraute Entwickler, viel Fanfare und +<emphasis>garkeinen</emphasis> laufenden Code. Zu meiner völligen +Überraschung, schaffte es das Projekt von Anfang an aktive Freiwillige +anzulocken und bis wir tatsächlich etwas laufendes hatten, waren +bereits eine ziemliche Menge freiwilliger Entwickler beteiligt. +Subversion ist da nicht das einzige Beispiel; das Mozilla Projekt wurde +auch ohne laufendem Code angefangen und ist heute ein erfolgreicher und +beliebter Web Browser.</para> + +<para>Angesichts solcher Beweise, muss ich von meiner ursprünglichen +Behauptung zurücktreten, dass laufender Code absolut notwendig ist um +ein Projekt anzufangen. Trotzdem ist laufender Code immer noch eines +der besten Grundlagen für Erfolg, und eine gute Grundregel wäre mit der +Bekanntgabe zu warten, bis Sie welchen haben. Es mag allerdings +Umstände geben bei denen eine frühere Bekanntmachung Sinn macht. Ich +denke, dass zumindest eine gut ausgearbeiteter Entwurf, oder irgend +ein Grundgerüst für den Code notwendig ist—es kann natürlich +passieren, dass es wegen öffentliche Rückmeldungen überarbeitet wird, +aber es muss handfestes geben, etwas eher greifbares als gute +Absichten, wo sich Leute reinhängen können.</para> + +<para>Wenn Sie die Ankündigung machen, sollten Sie jedoch nicht gleich +darauf ein Schar Freiwilliger erwarten. Für gewöhnlich ist das Resultat +einer Bekanntmachung, dass Sie nebenbei ein paar Anfragen bekommen, es +melden sich ein paar auf dem Verteiler an, abgesehen davon geht alles +so ziemlich wie bisher weiter. Mit der Zeit aber werden Sie eine +stätige Zunahmen der Beiträge bemerken, sowohl von neuen Beteiligten, +sowie von Benutzern. Die Ankündigun ist lediglich das Pflanzen eines +Samenkorns. Es kann brauchen, bis die Nachricht sich verbreitet hat. +Wenn das Projekt konsequent diejenigen Belohnt, die sich Beteiligen, +wird sich die Nachricht verbreiten, denn Menschen wollen miteinander +teilen was sie gutes finden. Wenn alles gut läuft, wird die Dynamik der +exponenziellen Kommunikationsnetze das Projekt langsam in eine komplexe +Gemeinschaft verwandeln, indem Sie nicht unbedingt den jeden Namen +kennen und nicht länger jede Unterhaltung mitverfolgen können. In den +nächsten Kapiteln, geht es um die Arbeit in einer solchen +Umgebung.</para> </sect1> _______________________________________________ Producingoss-translators mailing list [email protected] http://www.red-bean.com/mailman/listinfo/producingoss-translators
