Author: mbarkhau Date: Sun Sep 23 14:41:37 2007 New Revision: 1206 Log: Continued ch05
Modified: trunk/de/ch05.xml Modified: trunk/de/ch05.xml ============================================================================== --- trunk/de/ch05.xml (original) +++ trunk/de/ch05.xml Sun Sep 23 14:41:37 2007 @@ -743,112 +743,107 @@ darüber sind lediglich eine Zierde einer ansonsten technische Diskussion über die Lösung eines Problems.</para> -<para>Dieses Beispiel zeigt einen weiteren Grund warum es gut ist, über -Verträge offen zu sein. Es mag mehrere Organisationen geben, die bei -einem gegebenen Open-Source Projekt Verträge beisteuern, und wenn jeder -weiß, was der andere versucht zu machen, können sie vielleicht ihre -Ressourcen bündeln. Im obigen Fall, ist der größte Finanzier (CollabNet) -in keinster weise an diesen Einzelverträgen beteiligt, aber mit -dem Wissen, dass jemand anderes bestimmte Bug Fixes fördert wird es -CollabNet ermöglicht, seine Ressourcen auf andere Bugs zu richten, was -zu einer größeren Effizienz für das Projekt im gesamten führt.</para> - -<para>Werden andere Entwickler es übel nehmen, dass manche für die -Arbeit am Projekt bezahlt werden? Im allgemeinen, nein, insbesondere -wenn diejenigen die bezahlt werden sowieso anerkannte, geachtete -Mitglieder der Gemeinschaft sind. Keiner erwartet, dass Auftragsarbeit -gleichmäßig auf die commiter aufgeteilt wird. Leute verstehen wie -wichtig dauerhafte Beziehungen sind: Die Ungewissheiten die mit -Auftragsarbeit verbunden sind, sind derart, dass wenn man jemanden -gefunden hat, mit dem man zuverlässig arbeiten kann, man nur -widerwillig zu einer anderen Person wechseln würde, nur der -Gerechtigkeit halber. Stellen Sie sich das so vor: Wenn Sie das erste -mal jemand wählen wird es ganz klar keine Beschwerden geben, denn -schließlich mussten Sie ja <emphasis>irgendjemand</emphasis> wählen -— es ist nicht Ihre Schuld, dass Sie nicht alle beauftragen -können. Später, wenn Sie die selbe Person ein zweites mal beauftragen, -ist das einfach nur vernünftig: Sie kennen ihn schon, das letzte mal -war erfolgreich, warum sollten Sie ein unnötiges Risiko eingehen? -Deßhalb ist es völlig natürlich ein zwei Leute in der Gemeinschaft zu -haben an denen man sich wenden kann, anstatt die Arbeit gleichmäßig zu -verteilen.</para> +<para>Dieses Beispiel zeigt einen weiteren Grund offen über Verträge zu +reden. Es mag mehrere Organisationen geben, die bei einem Open-Source +Projekt Verträge beisteuern, und wenn jeder über die Arbeit des anderen +bescheid weiß, können sie vielleicht ihre Ressourcen bündeln. Im obigen +Fall, ist der größte Finanzier (CollabNet) in keinster weise an diesen +Einzelverträgen beteiligt, aber mit dem Wissen, dass jemand anderes +bestimmte Bug Fixes fördert, wird CollabNet ermöglicht sich auf andere +Fehler zu konzentrieren, und insgesamt die Effizienz im Projekt zu +erhöhen.</para> + +<para>Nehmen es andere Entwickler es den beauftragten Mitgliedern übel, +dass sie für die Arbeit am Projekt bezahlt werden? Im allgemeinen nein, +insbesondere wenn diejenigen die bezahlt werden sowieso anerkannte, +geachtete Mitglieder der Gemeinschaft sind. Keiner erwartet, dass +Auftragsarbeit gleichmäßig auf die Beteiligten aufgeteilt wird. Leute +verstehen wie wichtig dauerhafte Beziehungen sind: Die Ungewissheiten +bei Auftragsarbeit sind derart, dass wenn man einen zuverlässigen +Geschäftspartner gefunden hat, man nur widerwillig zu jemand anderen +wechselt, nur der Gerechtigkeit halber. Sie können es sich so +vorstellen: Wenn Sie das erste mal jemand wählen wird es bestimmt keine +Beschwerden geben, denn schließlich mussten Sie ja +<emphasis>irgendjemand</emphasis> wählen— Sie können schließlich +nicht alle beauftragen. Wenn Sie später dieselbe Person ein zweites mal +beauftragen, ist das nur vernünftig: Sie kennen ihn schon, der letzte +Auftrag verlief erfolgreich, warum sollten Sie ein unnötiges Risiko +eingehen? Es ist deßhalb ganz natürlich ein-zwei Leute in der +Gemeinschaft zu haben an denen man sich wenden kann, anstatt die Arbeit +gleichmäßig aufzuteilen.</para> <sect2 id="community-review-acceptance"> -<title>Beurteilung und Annahme von Änderungen</title> +<title>Kritik und Annahme von Änderungen</title> <para>Die Gemeinschaft ist trotzdem wichtig für den Erfolg der -Auftragsarbeit. Ihre Beteiligung beim Entwurfs und Bewertungsablauf, -darf nicht beiläufig geschehen. Es muss als ein Teil der Arbeit -aufgefasst werden, und komplett vom Auftragnehmer einbezogen werden. -Betrachten Sie die Prüfung durch die Gemeinschaft nicht als ein -Hindernis welches überwunden werden mus — sondern als eine -kostenlose Platform für Entwürfe, sowie Fragen und Antworten. Es ist -ein Vorteil, welches aggressiv nachgegangen werden sollten und nicht -lediglich geduldet werden sollte.</para> +Auftragsarbeit. Ihre Beteiligung beim Entwurf und der Beurteilung der +Änderung, darf nicht beiläufig geschehen. Sie müssen es als Teil der +Arbeit aufgefassen und vollständig im Auftrag einbeziehen. Betrachten +Sie die Kritik der Gemeinschaft nicht als ein Hindernis das es zu +überwinden gilt—sondern als kostenlose Platform für Entwürfe, +Fragen und Antworten. Es ist ein Vorteil, dem Sie aggressiv nachgehen +und nicht lediglich dulden sollte.</para> <sect3 id="cvs-pserver"> -<title>Fallbeispiel: Das CVS Protokoll zur Passwort Authentifizierung -</title> +<title>Fallbeispiel: Das Protokoll zur Passwort Authentifizierung in +CVS</title> -<para>1995 war ich eine Hälfte einer Partnerschaft, welche technische -Unterstützung und Erweiterung für CVS (das Concurrent Versions System; -siehe <ulink url="http://www.cvshome.org/"/>) anbot. Mein Partner Jim -und ich waren zu dem Zeitpunkt informell für die Instandhaltung von -CVS zuständig. Wir hatten aber nie sorgfältig darüber nachgedacht, wie -wir mit der bereits vorhandenen, größtenteils freiwilligen -Entwicklergemeinschaft von CVS umgehen sollten. Wir nahmen einfach an, -dass sie patches schicken würden, und wir sie anwenden würden, und so -hat es auch im großen und ganzen funktioniert.</para> - -<para>Damals, konnte CVS im Netzwerk nur über Fernzugriff mittels eines -Programms wie <literal>rsh</literal> gemacht werden. Mit dem selben -Passwort für den CVS Zugriff, wie für den Fernzugriff was ein -offensichtliches Sicherheitsrisiko war, und viele Organisationen waren -davon abgetan. Eine bedeutende Anlagebank beauftragte uns einen neuen +<para>1995 war ich an einer Partnerschaft beteiligt für technische +Unterstützung und Erweiterungen an CVS (das Concurrent Versions System; +siehe <ulink url="http://www.cvshome.org/"/>). Mein Partner Jim und ich +waren damals informell für die Instandhaltung von CVS zuständig. Wir +hatten aber nie sorgfältig darüber nachgedacht, wie wir mit der +vorhandenen, größtenteils freiwilligen Entwicklergemeinschaft von CVS +umgehen sollten. Unsere Erwartung war einfach Patches zu bekommen, die +wir anwenden würden, und so war auch weitestgehend der Ablauf.</para> + +<para>Damals konnte man CVS im Netzwerk nur über ein Fernzugriff +Programm wie <literal>rsh</literal> betreiben. Man brauchte dasselbe +Passwort für CVS wie für den Fernzugriff, was ein offensichtliches +Sicherheitsrisiko darstellte und viele Organisationen abschreckte. Eine +bedeutende Anlagebank beauftragte uns einen neuen Authentifizierungsmechanismuss zu implementieren, damit sie vernetztes CVS sicher mit ihren Außenstellen benutzen konnten.</para> -<para>Jim und ich nahmen den Vertrag an und setzten uns hin um das neue -Authentifizierungssystem zu entwerfen. Was wir uns ausdachten war -relativ einfach (die Vereinigten Staaten hatten zu der Zeit -Einschränkungen auf den Export von Kryptographischem Code, also hatte -Kunde Verständnis dafür, dass wir keine Starke Authentifizierung -implementieren konnten), da wir aber nicht erfahren damit waren, solche -Protokolle zu entwerfen, machten wir dennoch einige grobe Fehler, die -einem Experten sofort aufgefallen wären. Diese Ausrutscher wären mit -Leichtigkeit erkannt worden, hätten wir uns die Zeit genommen einen -Vorschlag zu verfassen und es an die anderen Entwickler zur Überprüfung -durchzureichen. Das machten wir aber nie, und es kam uns nicht in den -Sinn, den Entwickler Verteiler als eine Resource welches wir nutzen -konnten zu betrachten. Wir wussten dass Leute wahrscheinlich annehmen -würden, was immer wir auch committeten, und—da wir nicht wussten -was wir nicht wussten —machten wir uns nicht die Mühe, die Arbeit -auf eine sichtbare Art zu erledigen, also Patches häufig ab zu -schicken, kleine, leicht verdauliche Commits zu einem bestimmten Branch -zu machen, usw. Das entstandenen Authentifizierungsprotokoll war nicht -sonderlich gut, und natürlich, als es etabliert wurde, wurde es sehr -schwer es zu verbessern, aufgrund von Bedenken bezüglich der -Kompatibilität.</para> - -<para>Die Wurzel des Problems war nicht unser Mangel an Erfahrung; wir -hätten mit Leichtigkeit lernen können, was nötig war. Das Problem war -unsere Einstellung im Bezug auf die Entwicklergemeinschaft. Wir -betrachteten die Annahme der Änderungen als eine Hürde über die wir -springen mussten, als ein Ablauf mit dem die Qualität der Änderungen -verbessert werden konnte. Da wir zuversichtlich waren, dass alles was -wir tun würden angenommen werden würde (was auch geschah), machten -wir uns wenig mühe andere zu beteiligen.</para> +<para>Jim und ich nahmen den Vertrag fingen an ein Entwurf für das neue +Authentifizierungssystem auszuarbeiten. Unser Entwurf war relativ +einfach (die Vereinigten Staaten hatten damals Einschränkungen auf den +Export von Kryptographischem Code, also hatte der Kunde Verständnis +dafür, dass wir keine Starke Authentifizierung implementieren konnten), +da wir aber keine Erfahrung mit derartigen Protokollen hatten, machten +wir dennoch einige grobe Fehler, die einem Experten sofort aufgefallen +wären. Diese Ausrutscher wären mit Leichtigkeit erkannt worden, hätten +wir uns die Zeit genommen einen Vorschlag zu verfassen und die anderen +Entwickler zur Überprüfung gereicht hätten. Uns kam es nie in den Sinn, +die Entwickler auf dem Verteiler als Resource zu betrachten und machten +alleine weiter. Wir wussten, dass unsere Arbeit, egal wie sie aussah +wahrscheinlich angenommen werden würde, und—da wir nicht wussten +was wir nicht wussten —machten wir uns nicht die Mühe, unsere +Arbeit für alle sichtbar offenzulegen, d.h. häufig Patches ab zu +schicken, kleine, leicht verdauliche Änderungen an einem bestimmten +Branch, usw. Das entstandenen Authentifizierungsprotokoll war nicht +sonderlich gut, und nach seiner etablierung, ließ es sich es natürlich, +aufgrund von Sorgen um die Kompatibilität, nur sehr schwer +verbessern.</para> + +<para>Im Kern lag das Problem nicht an unser Mangel an Erfahrung; wir +hätten das Nötige mit Leichtigkeit lernen können. Das Problem lag an +unsere Einstellung zur Entwicklergemeinschaft. Wir betrachteten die +Annahme der Änderungen als eine Hürde die es zu überwinden galt, nicht +als Ablauf um die Qualität der Änderungen zu verbessern. Wir waren +zuversichtlich, dass jedweder Arbeit von uns angenommen würde (was auch +geschah), und machten uns deshalb wenig mühe um äußere +Beteiligung.</para> </sect3> -<para>Wenn Sie eine Auftragnehmer auswählen, wollen Sie für den Auftrag -offensichtlich jemandem mit den richtigen technischen Fähigkeiten und -Erfahrung. Es ist aber auch wichtig, jemanden zu wählen, der -nachweislich mit den anderen Entwicklern in der Gemeinschaft eine -konstruktive Zusammenarbeit pflegt. So bekommen Sie mehr als nur eine -Person; Sie bekommen einen Agenten, der in der Lage sein wird aus einem -Netzwerk von Fachwissen zu schöpfen, um sicher zu stellen das die -Arbeit auf eine robuste und Wartbare weise gemacht wird.</para> +<para>Bei der Suche nach einem Auftragnehmer, sollten Sie offensichtlich +auf die richtigen technischen Fähigkeiten und Erfahrung achten. Es ist +aber auch wichtig jemanden zu wählen, der nachweislich mit den anderen +Entwicklern in der Gemeinschaft eine konstruktive Zusammenarbeit pflegt. +Sie bekommen dadurch mehr als nur eine Person; Sie bekommen einen +Agenten, der in der Lage sein wird aus einem Netzwerk von Fachwissen zu +schöpfen, um robuste und wartbare Arbeit sicherzustellen.</para> </sect2> @@ -872,35 +867,33 @@ <sect1 id="funding-non-programming"> <title>Finanzierung von Tätigkeiten außer Programmieren</title> -<para>Programmieren ist nur ein Teil der Arbeit welches in eine Open -Source Projekt fließt. Aus Sicht der Freiwilligen im Projekt, ist es -der sichtbarste und glorreichste Teil. Das bedeutet leider, dass -andere Tätigkeiten wie die Dokumentation, formale Tests, usw. -manchmal vernachlässigt werden können, zumindest im Vergleich zu der -Menge an Aufmerksamkeit die sie bei proprietärer Software oftmals -erhalten. Unternehmen sind manchmal in der Lage das auszugleichen, -indem Sie einen Teil ihrer internen Software Entwicklungsinfrastruktur -Open Source Projekten widmen.</para> - -<para>Der Schlüssel das erfolgreich zu machen, ist zwischen den -internen Abläufen der Firma und denen in der Gemeinschaft zu -übersetzen. Solche Übersetzungen sind nicht Mühelos: Oft passen beide -nicht nicht gut zusammen, und die Unterschiede können nur durch -menschliche Eingriffe überwunden werden. Die Firma kann zum Beispiel -einen anderen Bug Tracker verwenden, als das öffentliche Projekt. -Selbst wenn sie beide die gleiche Software dafür benutzen, sind die -Daten die darin gespeichert werden sehr unterschiedlich, da die -Bedürfnisse einer Firma im Bezug auf Bug Tracking sehr viel anders -sind, als die einer freien Software Gemeinschaft. Ein Teil der -Information welches in einem der Tracker anfängt, mag auf den -anderen übertragen werden müssen, wobei vertrauliche Teile entfernt -werden, oder in der anderen Richtung hinzugefügt werden müssen.</para> - -<para>Die Abschnitte die folgen handeln darüber, wie man solche Brücken -aufbaut und in stand hält. Das Endergebnis sollte sein, dass das Open -Source Projekt glatter abläuft, die Gemeinschaft die Investition von -Ressourcen der Firma anerkennt, und trotzdem nicht das Gefühl bekommt, -dass die Firma unangemessen Sachen in Richtung ihrer Ziele lenkt.</para> +<para>Programmieren ist nur ein Teil der Arbeit in einem Open-Source +Projekt. Für Freiwillige im Projekt, ist es der sichtbarste und +glorreichste Teil. Leider können dadurch andere Tätigkeiten wie die +Dokumentation, formale Tests, usw. manchmal vernachlässigt werden, +zumindest im Vergleich zu der Aufmerksamkeit die sie bei proprietärer +Software oftmals erhalten. Unternehmen können das manchmal +auszugleichen, indem Sie einen Teil ihrer internen Infrastruktur für +die Software-Entwicklung, Open-Source Projekten widmen.</para> + +<para>Das Wesentliche für den Erfolg dieser Arbeit, ist die Übersetzung +zwischen den Abläufen in der Firma und denen in der Gemeinschaft. Sie +ist nicht Mühelos: Oft passen beide nicht gut zusammen, und die +Unterschiede können nur durch menschliche Eingriffe überwunden werden. +Die Firma kann beispielsweise einen anderen Bug-Tracker verwenden, als +das öffentliche Projekt. Selbst wenn beide die gleiche Software +benutzen, werden die darin gespeicherten Daten sehr unterschiedlich +sein, da die Anforderungen einer Firma an einem Bug-Tracking ganz andere +sind, als die einer freien Software Gemeinschaft. Eine Information die +in einem Bug-Tracker anfängt, muss vielleicht auf den anderen übertragen +werden, wobei vertrauliche Teile entfernt, oder in umgekehrter Richtung +hinzugefügt werden müssen.</para> + +<para>Die folgenden Abschnitte drehen sich um den Aufbau und die +Instandhaltung solcher Brücken. Das Endergebnis sollte ein +reibungsloser Betrieb im Open-Source Projekt, die Anerkennung der +Investition der Firma durch die Gemeinschaft, ohne das das Gefühl +unangemessen durch die Firma beeinflusst zu werden.</para> <!-- integrate the internal into the development community. If you have salaried developers, for example, use them as a liason. @@ -912,65 +905,61 @@ <!-- ======================== subsection =========================== --> <sect2 id="subsidize-qa"> -<title>Qualitätssicherung (d.h, Professionelles Testen)</title> +<title>Qualitätssicherung</title> -<para>Bei der Entwicklung proprietärer Software, ist es normal -gesonderte Abteilung zu haben, die sich der Qualitätssicherung widmen: -Bugs aufsuchen, Evaluierung der Performance und der Skalierbarkeit, -Überprüfung der Schnittstellen und der Dokumentation, usw. Als -Faustregel, werden diese Aktivitäten von der Gemeinschaft freiwilliger -bei einem freien Software Projekt, nicht so energisch verfolgt. Das -liegt zum Teil daran, dass es schwer ist, freiwillige Arbeit für -unrühmliche Tätigkeiten wie das Testen zu bekommen, teilweise deßhalb -weil Leute annehmen, dass eine große Nutzergemeinschaft zu haben eine -gute Test Abdeckung mit sich bringt, und, im Falle der Performance und -der Skalierbarkeit, z.T. da freiwillige oftmals sowieso keinen Zugang -zu den nötigen Hardware Ressourcen haben.</para> - -<para>Die Annahme, dass viele Nutzer zu haben, das gleich es wie viele -Tester zu haben, ist nicht ganz ohne Grundlage. Es hat sicherlich wenig -Sinn, Personen dem Testen von grundsätzlichen Funktionen in -verbreiteten Umgebungen zuzuweisen: dortige Bugs werden schnell von -Nutzern gefunden werden, im natürlichen Verlauf der Sachen. Da Nutzer -aber lediglich versuchen Arbeit erledigt zu bekommen, setzen Sie sich -nicht bewusst auf die Suche nicht erdachte Grenzfälle in der -Funktionalität der Software zu entdecken, und werden wahrscheinlich -bestimmte Arten von Bugs unentdeckt lassen. Desweiteren, wenn sie einen -Bug finden der sich leicht umgehen lässt, implementieren Sie im Stillen -diese Abhilfe ohne sich die Mühe zu machen den Bug zu melden. Am -heimtückischsten kann sein, dass das Benutzerverhalten Ihrer Kunden -(diejenigen die <emphasis>Ihr</emphasis> Interesse an der Software -Antreiben), sich statistisch sehr von dem Nutzungsverhalten eines -durchschnittlichen Nutzers auf der Strasse unterscheiden kann.</para> - -<para>Ein professionelles Team von Testern kann solche Bugs aufdecken, -und können es genau so gut mit freier Software, wie mit proprietärer -Software. Die Herausforderung ist, die Ergebnisse der Tester, der -Öffentlichkeit in einer nützlichen Form mitzuteilen. Die Abteilungen -fürs testen innerhalb eines Betriebs haben für gewöhnlich ihre eigene +<para>Bei der Entwicklung proprietärer Software, hat man üblicherweise +eine gesonderte Abteilung die sich der Qualitätssicherung widmet: Nach +Fehlern sucht, die Performance und Skalierbarkeit Evaluiert, +Schnittstellen, Dokumentation usw. überprüft. Diese Aktivitäten werden +üblicherweise nicht so energisch von freiwilligen in einem freien +Software Projekt verfolgt. Das liegt teilweise an der Schwierigkeit +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> + +<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>Eine professionelle Testgruppe kann solche Fehler genau so gut in +freier, wie in proprietärer Software aufdecken. Die Herausforderung ist, +die Ergebnisse der Tester, der Öffentlichkeit in einer nützlichen Form +mitzuteilen. Die Test-Abteilungen haben im Betrieb meistens ihre eigene Art Ergebnisse zu melden, mit firmenspezifischem Jargon, oder speziellem Fachwissen über bestimmte Kunden und ihre Datensätze. Solche Berichte -wären für einen öffentlichen Bug Tracker nicht angemessen, sowohl -wegen ihrer Form als auch wegen Bedenken im Bezug auf Vertraulichkeit. -Selbst wenn die interne Bug Tracking Software Ihrer Firma die gleiche -wäre, die von dem öffentlichen Projekt verwendet wird, kann es sein, -dass die Verwaltung Firmenspezifische Kommentare und Änderungen an den -Metadaten der Vorfälle machen muss (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, sind sie von keinem -Interesse für das öffentliche Projekt, und die Öffentlichkeit sollte -deshalb nicht von ihnen abgelenkt werden.</para> - -<para>Die Meldung des Bugs im Kern <emphasis>ist</emphasis> dennoch -wichtig für die Öffentlichkeit. Tatsächlich ist eine Bug Meldung von -Ihrer Test Abteilung in mancherlei Hinsicht wertvoller als eins welches -von den allgemeinen Nutzern, da die Test Abteilung nach Sachen Ausschau -hält, welches andere Nutzer nicht machen werden. Angesichts der -Tatsache, dass Sie diese bestimmte Bug Meldung aus keiner anderen -Quelle bekommen werden, zweifellos bewahren und es dem öffentlichen -Projekt zur Verfügung stellen.</para> +wären auf einen öffentlichen Bug-Tracker unangemessen, sowohl wegen +ihrer Form als auch aus Datenschutz Gründen. Selbst wenn die interne +Bug-Tracking Software Ihrer Firma die gleiche wäre wie im öffentlichen +Projekt, kann es sein, dass die Betriebsverwaltung Firmenspezifische +Kommentare sowie Änderungen an den Metadaten der Vorfälle machen muss +(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> + +<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 +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 +stellen.</para> <para>Um das zu erreichen, kann entweder die Abteilung zur Qualitätssicherung die Meldungen direkt in den öffentlichen Bug _______________________________________________ Producingoss-translators mailing list [email protected] http://www.red-bean.com/mailman/listinfo/producingoss-translators
