Author: mbarkhau Date: Wed Sep 26 10:27:43 2007 New Revision: 1220 Log: Continued ch05
Modified: trunk/de/ (props changed) trunk/de/ch05.xml Modified: trunk/de/ch05.xml ============================================================================== --- trunk/de/ch05.xml (original) +++ trunk/de/ch05.xml Wed Sep 26 10:27:43 2007 @@ -916,23 +916,23 @@ Freiwillige für unrühmliche Tätigkeiten wie das Testen zu finden und zum Anderen weil Leute annehmen, dass eine große Nutzergemeinschaft auch eine gute Test Abdeckung mit sich bringt. Performance und Skalierbarkeit -sind sogar ein Gebiet wofür Freiwillige oftmals sowieso unzureichende -Hardware Ressourcen zur Verfügung stehen.</para> +sind sogar ein Gebiet wofür Freiwillige oftmals sowieso nicht die +nötige Hardware zur Verfügung steht.</para> -<para>Die Annahme, viele Nutzer auch viele Tester sind, ist nicht ganz -ohne Grundlage. Es macht sicherlich wenig Sinn, Personen einzustellen -die Grundfunktionen auf der üblichen Zielumgebungen überprüfen: Die -dortigen Fehler werden ohnehin beim normalen Betrieb, schnell von -gewöhnlichen Nutzern gefunden. Da Nutzer aber lediglich versuchen ihre -Arbeit zu erledigen, setzen Sie sich nicht bewusst auf der Suche nach -ungewöhnliche Grenzfälle in der Funktionalität der Software zu -entdecken, und werden wahrscheinlich bestimmte Fehler unentdeckt lassen. -Bei einem Fehler der sich leicht umgehen lässt, werden Sie sogar eher -im Stillen diese Abhilfe implementieren ohne sich die Mühe zu machen -den Fehler zu melden. Am heimtückischsten kann der Umgang Ihrer Kunden -(diejenigen die <emphasis>Ihr</emphasis> Interesse antreiben) mit der -Software sein, welches statistisch ein ganz anderer sein kann als das -Verhalten eines beliebig anderen Nutzers.</para> +<para>Die Annahme, dass viele Nutzer auch viele Tester sind, ist nicht +ganz ohne Grundlage. Es macht sicherlich wenig Sinn, Personen +einzustellen die Grundfunktionen auf der üblichen Zielumgebungen +überprüfen: Die dortigen Fehler werden ohnehin beim normalen Betrieb, +schnell von gewöhnlichen Nutzern gefunden. Da Nutzer aber lediglich +versuchen ihre Arbeit zu erledigen, setzen Sie sich nicht bewusst auf +der Suche nach ungewöhnliche Grenzfälle in der Funktionalität der +Software zu entdecken, und werden wahrscheinlich bestimmte Fehler +unentdeckt lassen. Bei einem Fehler der sich leicht umgehen lässt, +werden Sie sogar eher im Stillen diese Abhilfe implementieren ohne sich +die Mühe zu machen den Fehler zu melden. Am heimtückischsten kann der +Umgang Ihrer Kunden (die Quelle von <emphasis>Ihrem</emphasis> +Interesse) mit der Software sein, dass statistisch ganz anderers +aussehen kann als das Verhalten eines beliebig anderen Nutzers.</para> <para>Eine professionelle Testgruppe kann solche Fehler genau so gut in freier, wie in proprietärer Software aufdecken. Die Herausforderung ist, @@ -948,92 +948,88 @@ (zum Beispiel um die interne Priorität eines Vorfalls anzuheben, oder seine Lösung für einen bestimmten Kunden anzusetzen). Für gewöhnlich sind solche Anmerkungen vertraulich—manchmal werden sie nicht -einmal dem Kunden gezeigt. Aber selbst wenn sie nicht vertraulich sind, -für das öffentliche Projekt uninteresant und die Öffentlichkeit sollte -deshalb nicht davon abgelenkt werden.</para> +einmal dem Kunden gezeigt. Aber selbst diese Daten nicht vertraulich +sind für das öffentliche Projekt uninteresant und sollte deshalb nicht +von ihnen abgelenkt werden.</para> -<para>Die Meldung des Bugs <emphasis>an und für sich</emphasis> ist -für die Öffentlichkeit dennoch wichtig. Tatsächlich ist eine Bug Meldung +<para>Die Meldung des <emphasis>eigentlichen</emphasis> Fehlers, ist +für die Öffentlichkeit dennoch wichtig. Tatsächlich ist eine Bug-Meldung von Ihrer Test Abteilung in mancherlei Hinsicht wertvoller als die der üblichen Benutzer, da die Test Abteilung nach Sachen Ausschau hält, die andere Nutzer nicht interesieren. Angesichts der Tatsache, dass Sie diese Fehler aus keiner anderen Quelle erfahren werden, sollten sie es -unbedingt aufbewahren und es dem öffentlichen Projekt zur Verfügung +unbedingt aufbewahren, und es dem öffentlichen Projekt zur Verfügung stellen.</para> <para>Um das zu erreichen, kann entweder die Abteilung zur -Qualitätssicherung die Meldungen direkt in den öffentlichen Bug -Tracker eintragen, wenn sie sich dabei wohl fühlen, oder ein -Vermittler (für gewöhnlich einer der Entwickler) kann die internen -Meldungen der Test Abteilung zu dem Öffentlichen Tracker "übersetzen". -Übersetzen bedeutet in diesem Zusammenhang den Bug so zu beschreiben, -dass es keine Bezüge auf Kundenspezifische Informationen hat (sofern -der Kunde dem Zustimmt, kann die Anleitung um den Fehler zu -reproduzieren natürlich auch Kundendaten beinhalten).</para> - -<para>Es ist leicht vorzuziehen, dass die Abteilung zur -Qualitätssicherung die Meldungen direkt in den öffentlichen Tracker -einträgt. Das gibt der Öffentlichkeit eine direktere Wertschätzung der -Beteiligung Ihrer Firma an dem Projekt: Nützliche Bug Meldungen tragen -genau so zu der Glaubwürdigkeit Ihrer Organization wie jeder andere -technische Beitrag es tun würde. Es gibt Entwickler auch einen direkten -Draht um mit der Test Abteilung zu kommunizieren. Wenn die interne -Abteilung zur Qualitätssicherung zum Beispiel den Bug Tracker -beobachtet, kann ein Entwickler eine Änderung committen, welches einen -Bug im Bezug auf die Skalierbarkeit behebt (welches der Entwickler -selber nicht überprüfen kann, da er nicht die nötigen Ressourcen hat), -und dann eine Anmerkung der Meldung beifügen, mit der Bitte and das -Qualitätssicherungsteam zu überprüfen, ob es die gewünschte Wirkung -hatte. Stellen Sie sich auf ein wenig Widerstand von einigen -Entwicklern ein; Programmierer haben die Angewohnheit -Qualitätssicherung allerhöchstens als ein notwendiges übel zu erachten. -Das Qualitätssicherungsteam kann das leicht überwinden, indem es -wesentliche Fehler findet und nachvollziehbare Meldungen abgibt; wenn -ihre Meldungen andererseits nicht mindestens so gut sind, wie denen -aus der gewöhnlichen Gemeinschaft, dann hat es keinen Sinn, dass sie -direkt mit dem Entwicklungsteam zusammenwirken.</para> - -<para>So oder so, sollte sobald es die Öffentliche Meldung gibt, die -interne Meldung was technische Inhalte angeht, nur noch auf die -öffentliche Verweisen. Die Verwaltung und bezahlte Entwickler können -weiterhin, was interne firmen spezifische Angelegenheiten angeht bei -bedarf Anmerkungen beifügen, sollten aber die öffentliche Meldung -für Informationen nutzen, welche allen zur Verfügung stehen sollten. -</para> - -<para>Sie sollten sich bei diesem Verfahren auf einen erhöhten Aufwand -einstellen. Zwei Meldungen für einen Bug in stand zu halten, bedeutet -natürlich mehr Arbeit als eine. Der Vorteil ist, dass viel mehr -Programmierer die Meldung sehen werden und ihrer Lösung beitragen +Qualitätssicherung die Meldungen direkt in den öffentlichen Bug-Tracker +eintragen, wenn sie sich dabei wohl fühlen, oder ein Vermittler +(gewöhnlich einer der Entwickler) kann die internen Meldungen der Test +Abteilung zu dem Öffentlichen Tracker "übersetzen". Übersetzen bedeutet +in diesem Zusammenhang den Bug so zu beschreiben, dass es keine Bezüge +auf Kundenspezifische Informationen hat (sofern der Kunde dem Zustimmt, +kann die Anleitung um den Fehler zu reproduzieren natürlich auch +Kundendaten beinhalten).</para> + +<para>Der Eintrag in den Tracker sollte vorzugsweise von der Abteilung +zur Qualitätssicherung gemacht werden. So kann die Öffentlichkeit die +Beteiligung Ihrer Firma besser sehen und würdigen: Nützliche +Bug-Meldungen tragen ebenso zum guten Ruf Ihrer Organization bei, wie +jeder andere technische Beitrag. Es gibt freiwillige Entwickler auch +einen direkten Draht um mit der Test Abteilung zu kommunizieren. Wenn +diese Abteilung den Bug-Tracker beobachtet, kann ein Entwickler eine +Änderung machen um z.B. einen Skalierbarkeits Bug zu beheben (der +Entwickler selber kann die Korrektur nicht überprüfen, da er nicht die +nötigen Ressourcen hat), und anschließend dem Ticket eine Anmerkung +anhängen, mit der Bitte an die Qualitätssicherung, zu überprüfen, ob es +die gewünschte Wirkung hatte. Stellen Sie sich auf den Widerstand +einiger Entwickler ein; Programmierer haben die Angewohnheit +Qualitätssicherung, allerhöchstens als ein notwendiges übel zu +erachten. Die Test-Abteilung kann das leicht überwinden, indem sie +schwerwiegende Fehler findet und nachvollziehbare Tickets schreibt; +wenn ihre Tickets andererseits nicht mindestens so gut sind, wie denen +von der übrigen Gemeinschaft, hat es keinen Sinn, dass sie direkt mit +den Entwicklern zusammenwirken.</para> + +<para>So oder so, sollte sobald es den Öffentlichen Ticket gibt, der +interne Ticket im Bezug auf technische Inhalte, nur noch auf den +öffentlichen Verweisen. Der Betrieb kann weiterhin, Anmerkungen +firmenspezifischer Angelegenheiten bei bedarf beifügen, sollten aber +Informationen die allen zur Verfügung stehen sollten in das öffentliche +Ticket schreiben.</para> + +<para>Sie sollten sich bei diesem Verfahren auf einen höheren Aufwand +einstellen. Die Pflege von zwei Tickets für einen Bug, bedeutet +natürlich mehr Arbeit als eins. Der Vorteil ist, dass viel mehr +Programmierer den Ticket sehen werden und ihre Lösungen beitragen können.</para> </sect2> <!-- ======================== subsection =========================== --> <sect2 id="subsidize-legal"> -<title>Rechtsberatung und Schutz</title> +<title>Rechtliche Beratung und Schutz</title> <para>Gesellschaften, ob profitorientiert oder nicht, sind fast die -einzigen die jemals in freien Software Projekten komplexe rechtliche -Angelegenheiten Aufmerksamkeit widmen. Einzelne Entwickler verstehen -oft die Nuancen verschiedener Open Source Lizenzen, haben aber im -allgemeinen nicht die Zeit oder Ressourcen um Urheber-, Marken- und -Patentrecht im Detail zu verfolgen. Wenn Ihre Firma eine -Rechtsabteilung hat, kann sie einem Projekt helfen, indem sie den -Urheberrechtlichen Stand des Quellcodes überprüft und den Entwicklern -hilft, mögliche Patent und Markenrechtliche Angelegenheiten zu -verstehen. Die genauen Ausprägungen die diese Hilfe annehmen kann -werden in <xref linkend="legal"/> diskutiert. Die Hauptsache ist -sicherzustellen, dass wenn zwischen der Rechtsabteilung und der -Entwicklergemeinschaft eine Kommunikation stattfindet, falls überhaupt, -sie mit gegenseitiger Anerkennung für die äußerst unterschiedlichen -Welten aus dem die beiden Parteien kommen abläuft. Gelegentlich können -diese beiden Gruppen an einander vorbei reden, wenn die verschiedenen -Gruppen von fachspezifischen Wissen, welches die anderen nicht haben, -ausgehen. Eine gute Strategie ist es, einen Verbindungsmann zu haben -(meistens ein Entwickler, ansonsten einen Anwalt mit technische -Fachkenntnisse) welcher zwischen beide so lange steht und übersetzt wie -nötig.</para> +einzigen, die bei einem freien Software Projekt, für komplexe +rechtliche Angelegenheiten, irgendwelche Aufmerksamkeit aufbringen. +Einzelne Entwickler verstehen oft die Nuancen verschiedener +Open-Source Lizenzen, haben im allgemeinen aber weder Zeit noch +Ressourcen um Urheber-, Marken- und Patentrecht, im Detail zu verfolgen. +Wenn Ihre Firma eine Rechtsabteilung hat, kann sie einem Projekt +helfen, indem sie den Urheberrechtlichen Stand des Quellcodes überprüft +und den Entwicklern hilft, mögliche Patent und Markenrechtliche +Angelegenheiten zu verstehen. Die genauen Ausprägungen die diese Hilfe +annehmen kann werden in <xref linkend="legal"/> diskutiert. Die +Hauptsache ist bei einer Kommunikation zwischen der Rechtsabteilung +und der Entwicklergemeinschaft sicherzustellen, dass sie die äußerst +unterschiedlichen Welten, aus denen beide Parteien kommen gegenseitig, +Anerkennen. Gelegentlich können diese beiden Gruppen aneinander +vorbeireden, wenn sie von fachspezifischem Wissen ausgehen, welches die +anderen Partei nicht hat. Es ist eine gute Strategie, eine +Verbindungsperson zu haben (meistens ein Entwickler, oder ein Anwalt +mit technische Fachkenntnisse) die so lange wie nötig zwischen beide +steht und übersetzt.</para> </sect2> @@ -1042,48 +1038,48 @@ <title>Dokumentation und Benutzerfreundlichkeit</title> <para>Die Dokumentation und Benutzerfreundlichkeit sind beides wohl -bekannte Schwachstellen in Open Source Projekten, obwohl ich denke, -dass der Unterschied zu proprietärer Software im Falle der -Dokumentation, sehr oft hochgespielt wird. Trotzdem ist es empirisch -wahr, dass es viel Open Source Software an einer erstklassigen -Dokumentation und einer Untersuchung ihrer Benutzerfreundlichkeit +bekannte Schwachstellen in Open-Source Projekten, obwohl ich denke, +dass der Unterschied zu proprietärer Software, im Falle der +Dokumentation, oftmals hochgespielt wird. Die Erfahrung zeigt trotzdem, +dass es Open-Source Software meistens an einer erstklassigen +Dokumentation, sowie einer Untersuchung ihrer Benutzerfreundlichkeit mangelt.</para> <para>Wenn Ihre Gesellschaft helfen will, diese Lücken für ein Projekt -zu füllen, ist wahrscheinlich das beste was Sie machen können, Leute -einzustellen, die <emphasis>nicht</emphasis> regelmäßige Entwickler im -Projekt sind, aber in der Lage sein werden mit den Entwicklern -produktiv zusammen zu arbeiten. Regelmäßige Entwickler nicht -einzustellen ist aus zwei Gründen gut: Erstens, entziehen Sie dem -Projekt dadurch keine Entwicklerzeit; zweitens, diejenigen die am -nächsten zu der Software sind, sind im allgemeinen sowieso die Falschen -um Dokumentation zu schreiben oder um die Nutzerfreundlichkeit zu -untersuchen, da sie Schwierigkeiten haben die Software aus der Sicht -eines Außenstehenden zu sehen.</para> - -<para>Es wird allerdings immer noch nötig sein, dass wer auch immer an -den Problemen arbeitet, mit den Entwicklern kommuniziert. Finden Sie -Leute, die genügend technische Kenntnisse haben, um mit den Entwicklern -zu kommunizieren, aber nicht so weit experten mit der Software sind, -dass sie kein Einfühlungsvermögen für gewöhnliche Benutzer haben.</para> - -<para>Ein Benutzer auf einer mittleren Stufe ist wahrscheinlich die -richtige Person um ein gutes Buch zu schreiben. Tatsächlich, bekam ich -nachdem ich die erste Version dieses Buches veröffentlicht hatte, eine -Email von einem Open Source Entwickler namens Dirk Reiners:</para> +zu füllen, sollten Sie wahrscheinlich am ehesten Leute einzustellen, +die üblicherweise <emphasis>nicht</emphasis> am Projekt mitentwickeln, +aber dennoch in der Lage sein werden mit den Entwicklern produktiv +zusammenzuarbeiten. Leute einzustellen die keine gewöhnlichen +Entwickler sind, ist aus zwei Gründen gut: Erstens, entziehen Sie dem +Projekt dadurch keine Entwicklerzeit; zweitens, diejenigen die der +Software am nächsten sind, sollten im allgemeinen sowieso nicht die +Dokumentation schreiben oder die Benutzerfreundlichkeit untersuchen, +da sie Schwierigkeiten haben die Software aus der Sicht eines +Außenstehenden zu betrachten.</para> + +<para>Eine Kommunikation zwischen diesen beiden parteien wird +allerdings immer noch nötig sein. Finden Sie Leute, die genügend +technische Kenntnisse haben, um mit den Entwicklern zu kommunizieren, +aber nicht so weit experten mit der Software sind, dass sie kein +Einfühlungsvermögen für gewöhnliche Benutzer haben.</para> + +<para>Ein halbwegs erfahrener Benutzer ist wahrscheinlich die richtige +Person um eine gute Dokumentation zu schreiben. Ich bekam nach der +ersten Veröffentlichung dieses Buchs, sogar eine E-Mail von einem +Open-Source Entwickler namens Dirk Reiners:</para> <screen> -Eine Bemerkung im Bezug auf Geld::Dokumentation und +Eine Anmerkung im Bezug auf Geld::Dokumentation und Benutzerfreundlichkeit: Als wir etwas Geld übrig hatten und uns -entschieden, dass eine Einleitung für Anfänger das wichtigste war was -wir brauchten, stellten wir einen mittelmäßig erfahrenen Benutzer ein, -um es zu schreiben. Seine Einweihung in das System war nicht so lange -her, sodass er sich an die Probleme erinnern konnte, er hatte es aber -geschafft an sie vorbei zu kommen und wusste wie er sie beschreiben -konnte. Das ermöglichte es ihm etwas zu schreiben, dass nur kleinerer -Korrekturen durch die Hauptentwickler benötigte was Sachen anging, die -er nicht richtig aufgefasst hatte, aber dennoch die 'offensichtlichen' -Sachen abdeckte, welche die Entwickler übersehen hätten. +entschieden, dass eine Einleitung für Anfänger das wichtigste war, +stellten wir einen halbwegs erfahrenen Benutzer ein. Er war erst +kürzlich in das System eingewiesen worden, sodass er sich an seine +Probleme erinnern konnte, er hatte es aber daran vorbei geschafft und +konnte sie dementsprechend beschreiben. Er konnte dadurch etwas +schreiben, dass von den Hauptentwicklern nur wenige Korrekturen +bedurfte, bei Sachen die er nicht richtig aufgefasst hatte. Trotzdem +konnte er das 'Offensichtliche' abdeckten, dass die Entwicklern +übersehen hätten. Sein Fall war noch besser, da es seine Aufgabe gewesen war einen Haufen anderer Personen (Studenten) in das System einzuführen, also _______________________________________________ Producingoss-translators mailing list [email protected] http://www.red-bean.com/mailman/listinfo/producingoss-translators
