Author: mbarkhau
Date: Mon Aug 6 16:39:38 2007
New Revision: 883
Log:
started review of ch02
Modified:
trunk/de/appc.xml
trunk/de/appd.xml
trunk/de/ch02.xml
Modified: trunk/de/appc.xml
==============================================================================
--- trunk/de/appc.xml (original)
+++ trunk/de/appc.xml Mon Aug 6 16:39:38 2007
@@ -260,5 +260,3 @@
sgml-parent-document: ("book.xml" "appendix")
end:
-->
-
-# vim: tw=72
Modified: trunk/de/appd.xml
==============================================================================
--- trunk/de/appd.xml (original)
+++ trunk/de/appd.xml Mon Aug 6 16:39:38 2007
@@ -2,7 +2,7 @@
<title>Beispiel Anleitung für die Meldung von Fehlern</title>
<simplesect>
-# vim: tw=72
+
<para>Dies ist eine leicht bearbetete Kopie der online verfügbaren
Anleitung des Subversion Prokjekts, an neue Benutzer darüber wie Fehler
gemeldet werden sollen. Siehe <xref
Modified: trunk/de/ch02.xml
==============================================================================
--- trunk/de/ch02.xml (original)
+++ trunk/de/ch02.xml Mon Aug 6 16:39:38 2007
@@ -4,14 +4,14 @@
<simplesect>
-<para>Das klassische Modell, wie freie Software Projekte anfangen
-wurde von Eric Raymond, in einem nunmehr berühmten Text über
-Open Source, mit dem Titel <citetitle>The Cathedral and the
-Bazaar</citetitle>, wie folgt beschrieben:</para>
+<para>Das klassische Schema, wonach freie Software Projekte anfangen,
+wurde in einem nunmehr berühmten Text über Open Source, mit dem Titel
+<citetitle>The Cathedral and the Bazaar</citetitle> von Eric Raymond,
+wie folgt beschrieben:</para>
<blockquote>
- <para><emphasis>Jedes gute Stück Software entsteht aus der
- den Bedürfnissen eines Programmierers.</emphasis></para>
+ <para><emphasis>Jede gute Software entsteht aus den Bedürfnissen
+ eines Programmierers.</emphasis></para>
<para>(von <emphasis role="bold"><ulink
url="http://www.catb.org/~esr/writings/cathedral-bazaar/"/>
@@ -21,133 +21,148 @@
<para>Raymond sagte wohlgemerkt nicht, dass Open Source Projekte nur
durch die Bedürfnisse eines Programmierers anfangen. Vielmehr sagte
er, dass <emphasis>gute</emphasis> Software dann entsteht, wenn der
-Programmiere ein persönliches Interesse daran hat, dass das Problem
-gelöst wird, was insofern für freie Software relevant ist, da es sich
-herausstellte, dass die meisten Open Source Projekte aufgrund eines
-persönlichen Bedürfnisses eines Programmierers anfingen.</para>
+Programmiere ein persönliches Interesse daran hat, ein Problem zu lösen;
+was insofern für freie Software relevant ist, da es sich herausstellte,
+dass die meisten Open Source Projekte aufgrund der persönlichen
+Bedürfnisse von Programmierern angefangen wurden.</para>
-<para>Dies ist immer noch der Grund, warum die meisten freien Software
-Projekte anfangen, mittlerweile aber weniger als 1997, als Raymond
+<para>Es ist auch heute noch die Motivation der meisten freien Software
+Projekte, mittlerweile aber weniger als 1997, zu der Zeit als Raymond
diese Worte schrieb. Heute haben wir das Phänomen, dass Organisationen
--auch profit orientierte Firmen-große zentral organisierte Open Source
-Projekte von Grund auf anfangen. Der einzelne Programmierer, der um ein
-lokales Problem zu lösen, ein wenig Code heraus haut und dann
-feststellt, dass das Ergebnis eine breitere Anwendbarkeit hat, ist
-immer noch die Quelle vieler freier Software, es ist aber nicht die
-einzige Geschicht.</para>
-
-<para>Der Punkt den Raymond macht ist aber immer noch Aufschlussreich.
-Die notwendige Bedingung ist, dass die Produzenten der Software ein
-direktes Interesse an seinen Erfolg haben, denn Sie benutzen es
-selbst. Wenn die Software nicht das macht was es machen soll, wird
-die Person oder Organisation die sie produziert, die Unzufriedenheit
-bei der täglichen Arbeit spüren. Das OpenAdapter Projekt zum Beispiel
+—auch profit-orientierte Firmen—große zentral organisierte
+Open Source Projekte von Grund auf anfangen. Der einsame Programmierer
+der ein bisschen Code ausgräbt um ein lokales Problem zu lösen um dann
+festzustellen, dass das Ergebnis eine breitere Anwendbarkeit hat, ist
+immer noch die Quelle einerm menge freier Software, es ist aber nicht
+die einzige Geschichte.</para>
+
+<para>Die Argumentation von Raymond ist aber immer noch Aufschlussreich.
+Diejenigen, welche die Software Produzieren, müssen ein direktes
+Interesse an seinem Erfolg haben, weil sie es selber nutzen. Wenn die
+Software nicht macht was es soll, wird die Person oder Organisation die
+sie produziert, die Unzufriedenheit bei der täglichen Arbeit spüren. Das
+OpenAdapter Projekt zum Beispiel
(<ulink url="http://www.openadapter.org/"/>), welches von der
-Investmentbank Dresdner Kleinwort Wasserstein als Open Source
-Framework zur Integration unterschiedlicher finanzieller
-Informationssysteme gestartet wurde, kann wohl kaum als Bedürfnis
-eines eines einzelnen Programmierers bezeichnet werden. Sondern als
-institutionelles Bedürfnis. Dieses Bedürfnis, entsteht aber direkt
-aus den Erfahrungen der Institution und seine Partner, wenn also die
-Software daran scheitert, ihre Arbeit zu erleichtern, werden sie es
-wissen. Aus diesem Arrangement entsteht gute Software, da Rückmeldungen
-an der richtigen Stelle ankommen. Die Software wird nicht geschrieben
-um an jemand verkauft zu werden, also können sie sich auf <emphasis>
-ihre</emphasis> Probleme konzentrieren. Sie wird geschrieben um ihre
+Investmentbank Dresdner Kleinwort Wasserstein als Open Source Framework
+zur Integration unterschiedlicher finanzieller Informationssysteme
+gestartet wurde, kann wohl kaum als Bedürfnis eines eines einzelnen
+Programmierers bezeichnet werden. Sondern als institutionelles
+Bedürfnis. Dieses Bedürfnis, entsteht aber direkt aus den Erfahrungen
+der Institution und seiner Partner, wenn die Software es also nicht
+schafft ihre Arbeit zu erleichtern, kriegen sie es mit. Aus diesem
+Arrangement entsteht gute Software, da Rückmeldungen an den richtigen
+Stellen ankommen. Die Software wird nicht geschrieben um an jemandem
+verkauft zu werden, also können sie sich auf <emphasis>ihre</emphasis>
+Probleme konzentrieren. Sie wird geschrieben um ihre
<emphasis>eigene</emphasis> Probleme zu lösen um es dann mit allen zu
teilen, so ähnlich als wäre das Problem eine Krankheit und die
-Software die entsprechende Medizin, dessen Verbreitung, dazu gedacht
+Software die entsprechende Medizin, dessen Verbreitung dazu gedacht
ist, die Epidemie auszurotten.</para>
-<para>In diesem Kapitel geht es um die Frage, wie man ein neues
-freies Software Projekt der Welt vorstellt, viele seiner Empfehlungen
-könnten sich aber einer Gesundheitorganisation die Medizin
-verteilt, bekannt vorkommen. Die Ziele sind sich sehr ähnlich: Man
-will klarstellen was die Medizin macht, es in die Hände der richtigen
-Leute bringen, und sicherstellen, dass diejenigen die es erhalten,
-wissen damit umzugehen. Bei der freien Software aber, will man auch
-ein paar der Empfänger dazu bewegen sich an der fortwährenden
-Forschungsarbeit, zur Verbesserung der Medizin, zu beteiligen.</para>
-
-<para>Die Verbreitung freier Software ist eine zweifaltige
-Aufgabe. Die Software muss sowohl Nutzer als auch Entwickler anziehen.
-Diese beiden Erfordernisse stehen einander nicht zwangsläufig
-gegenüber, aber sie machen die anfänglichen Präsentation des Projekts,
-etwas komplexer. Manche Informationen sind für beide Gruppen nützlich,
-manche nur für die eine oder andere. Beide Arten der Information
-sollten das Prinzip der skalierten Präsentation verfolgen; was soviel
-heißt wie, der Detailgrad der in jeder Phase präsentiert wird, sich
-genau decken sollte, mit der Menge an Zeit und der Anstrengung die vom
-Leser aufgebraucht wird. Eine größere Anstrengung sollt auch immer eine
-größere Belohnung zur Folge haben. In dem Fall, dass beide nicht eng
-mit einander korrelieren, werden die Leser schnell die Hoffnung auf
-geben und aufhören ihre Zeit zu investieren.</para>
+<para>In diesem Kapitel geht es um die Frage, wie man ein neues freies
+Software Projekt der Welt vorstellt, viele seiner Empfehlungen würden
+aber einer Gesundheitorganisation die Medizin verteilt, bekannt
+vorkommen. Die Ziele sind sich sehr ähnlich: Man will klarstellen was
+die Medizin macht, es in die Hände der richtigen Leute bringen, und
+sicherstellen, dass diejenigen die es erhalten, wissen damit umzugehen.
+Bei der freien Software will man aber auch ein paar der Empfänger dazu
+bewegen sich an der fortwährenden Forschungsarbeit, zur Verbesserung
+der Medizin, zu beteiligen.</para>
+
+<para>Der Vertrieb freier Software gibt es zwei Aufgaben. Die Software
+muss sowohl Nutzer als auch Entwickler anziehen. Diese beiden
+Anforderungen stehen einander nicht zwangsläufig gegenüber, aber sie
+machen die anfänglichen Präsentation des Projekts, etwas komplexer.
+Manche Informationen sind für beide Gruppen nützlich, manche nur für
+die eine oder andere. Beide Arten der Information sollten das Prinzip
+der skalierenden Präsentation verfolgen; was soviel heißt wie, der
+Detailgrad welcher in jeder Phase präsentiert wird, sollte sich genau
+mit der Menge an Zeit und Anstrengung decken, die vom Leser aufgebracht
+wird. Eine größere Anstrengung sollt auch immer eine größere Belohnung
+zur Folge haben. In dem Fall, dass beide nicht eng mit einander
+korrelieren, werden die Leser schnell die Hoffnung auf geben und
+aufhören ihre Zeit zu investieren.</para>
<para>Die Folgerung hieraus ist, dass <emphasis>das Erscheinungsbild
-Zählt</emphasis>. Insbesondere fällt es Programmierern schwer, dies
-zu glauben. Ihre Liebe zum Wesentlichen gegenüber dem Äußeren geht
-fast bis zum Punkt der professionellen Stolz. Die meisten von uns
-könne mit einem Blick erkennen ob eine Seite eilig zusammengebastelt
-wurde oder ob man sich ernsthafte Gedanken darüber gemacht hat. Dies
-ist das Erste Stück an Information welches Ihr Projekt nach außen
-gibt und den Eindruck den es vermittelt wird sich auf den Rest des
+Zählt</emphasis>. Insbesondere Programmierern fällt es schwer, dies
+zu glauben. Ihre Liebe zum Inhalt über seinem Aussehen gehört fast schon
+zum Berufsethos. Es ist kein Zufall, dass so viele Programmierer für die
+Arbeit der Abteilungen für Marketing und Public Relations eine
+Antipathie hegen, oder dass professionelle Grafiker über manches
+erschrocken sind, worauf programmierer von alleine kommen.</para>
+
+<para>Das ist schade, denn es gibt Situationen, bei dem das Aussehen
+der Inhalt <emphasis>ist</emphasis> und die Präsentation eines Projekts
+ist eines davon. Das erste was ein Besucher zum Beispiel über ein
+Projekt lernt, ist wie seine Webseite aussieht. Diese Information wird
+erfasst, vor irgend ein echter Inhalt auf der Seite verstanden
+wird—vor irgendwas vom Text gelesen wurde oder auf einem der
+Links geklickt wurde. Egal wie ungerecht es sein mag, Leute können sich
+nicht daran hindern sich sofort einen ersten Eindruck zu verschaffen.
+Das Erscheinungsbild der Seite deutet darauf hin, ob man sich beim
+Aufbau der Präsentation des Projekts mühe gemacht hat. Menschen haben
+eine extrem sensibele Antenne dafür wieviel Mühe in etwas investiert
+wurde. Die meisten können mit einem Blick erkennen ob eine Seite eilig
+zusammengebastelt wurde oder ob man sich ernsthafte Gedanken darüber
+gemacht hat. Das ist die Erste Information welches Ihr Projekt nach
+außen gibt und der Eindruck den es vermittelt wird sich auf das übrige
Projekts übertragen.</para>
-<para>Deshalb sollten Sie daran denken, dass obwohl es sich in diesem
+<para>Sie sollten deshalb daran denken, dass obwohl es sich in diesem
Kapitel um Inhaltliches dreht, das Erscheinungsbild auch zählt. Da die
-Seite für zwei Besuchertypen funktionieren muss-Nutzer und Entwickler-,
-muss besonders auf Klarheit und Richtung geachtet werde. Auch wenn hier
-nicht der richtige Ort ist für eine allgemeine Abhandlung über Web
-Design, gibt es ein Prinzip, welches wichtig genug ist um erwähnt zu
-werden, insbesondere wenn die Seite mehrere(falls Überlappende)
-Zielgruppen ansprechen soll: Besucher sollten eine grobe Vorstellung
-davon haben, wo ein Link hinführt bevor sie darauf klicken. Es sollte
-zum Beispiel offensichtlich sein <emphasis>durch den Anblick eines
-Links</emphasis> welches zur Nutzerdokumentation führt, dass es zur
-Dokumentation für Benutzer führt, und nicht etwa zur Entwickler
-Dokumentation. Beim betreiben eines Projekts, geht es zum Teil darum
-Informationen bereitzustellen, aber auch darum ein Gefühl der
-Behaglichkeit an zu bieten. Allein schon die Anwesenheit bestimmter
-grundsätzlichen Angebote, an den erwarteten Stellen, beruhigt Benutzer
-und Entwickler die darüber entscheiden ob sie sich involvieren wollen.
-Es sagt ihnen, dass das Projekt seine Sachen beisammen hat, die Fragen
-die gestellt werden vorausgesehen hat und sich die Mühe gemacht hat
-sie auf eine Art zu beantworten die vom Fragenden so wenig Einsatz wie
-möglich erfordert. Indem das Projekt diese Aura der Bereitschaft, gibt
-es diese Botschaft nach außen: "Du verschwendest deine Zeit nicht,
-wenn du dich beteiligst", was genau die Botschaft ist, die sie hören
-müssen.</para>
+Webseite für zwei Besucherarten geeignet sein muss—Nutzer und
+Entwickler—muss besonders auf Klarheit und Richtung geachtet
+werden. Auch wenn es an dieser Stelle nicht angebracht ist eine
+allgemeine Abhandlung über Web-Design zu geben, gibt es ein Prinzip,
+welches wichtig genug ist um erwähnt zu werden, insbesondere wenn die
+Seite mehrere(falls Überlappende) Zielgruppen ansprechen soll: Besucher
+sollten eine grobe Vorstellung davon haben, wo ein Link hinführt bevor
+sie darauf klicken. Es sollte zum Beispiel <emphasis>beim den Anblick
+eines Links</emphasis> welches zu der Benutzerdokumentation führt
+offensichtlich sein, dass es zur Dokumentation für Benutzer führt, und
+nicht etwa zur Entwickler Dokumentation. Beim betrieb eines Projekts,
+geht es zum Teil darum Informationen bereitzustellen, aber auch darum
+ein Gefühl der Behaglichkeit anzubieten. Allein schon die Anwesenheit
+bestimmter grundsätzlichen Angebote, an den erwarteten Stellen,
+beruhigt Benutzer und Entwickler die sich entscheiden ob sie sich
+beteiligen wollen. Es sagt ihnen, dass das Projekt seine Sachen
+beisammen hat, Fragen die gestellt werden vorausgesehen hat und sich
+die Mühe gemacht hat sie so zu beantworten, dass sie vom Fragenden
+möglichst wenig Einsatz erfordert. Indem das Projekt diese Aura
+vorbereitet zu sein ausstrahlt, sendet es folgende Botschaft nach
+außen: "Du verschwendest deine Zeit nicht, wenn du dich beteiligst",
+und das ist genau die Botschaft, die sie hören müssen.</para>
<!-- ======================== subsection ============================== -->
<sect2 id="look-around">
-<title>Schaue Dich Vorher Um</title>
+<title>Schauen Sie sich Vorher Um</title>
-<para>Es gibt einen wichtigen Warnung, bevor man ein Open Source
-Projekt anfängt:</para>
+<para>Vor Sie ein Open Source Projekt anfangen, gibt es noch einen
+wichtige Warnung:</para>
-<para>Schau dich immer vorher um, ob ein Projekt nicht bereits existiert,
-welches das macht was man möchte. Die Wahrscheinlichkeit ist hoch, dass
-welches Problem Sie auch lösen wollen, es jemand vor ihnen bereits
-gelöst hat. Sollten sie es gelöst haben und ihren Code unter einer freien
-Lizenz gestellt haben, gibt es keinen Grund das Rad neu zu erfinden. Es
-gibt natürlich Außnahmen: Falls sie ein Projekt als Lehr-Erfahrung
-anfangen wollen, wird Ihnen bereits existierender Code nicht weiterhelfen.
-Vielleicht wissen Sie bereits von vornherein, dass Ihr Problem so
-spezifisch ist, dass es mit Sicherheit noch von niemanden gelöst wurde.
-Im allgemeinen gibt es aber kein Grund sich nicht umzuschauen und der
-Lohn kann beträchtlich sein. Sollten die gewöhnlichen Suchmaschinen keine
-brauchbaren Ergebnisse liefern, sollte Sie es bei
-<ulink url="http://freshmeat.net/"/> (eine Nachrichtenseite über Open
-Source Projekte (mehr zu dieser Seite gibt es später), bei
-<ulink url="http://www.sourceforge.net/"/>, oder beim Verzeichnis
-für freie Software der Free Software Foundation's
+<para>Schauen Sie sich vorher um, ob nicht schon ein Projekt existiert,
+welches das macht was Sie haben möchten. Die Wahrscheinlichkeit ist
+hoch, dass welches Problem Sie auch lösen wollen, es jemand vor ihnen
+bereits gelöst hat. Wenn das der Fall ist und ihr Code unter einer
+freien Lizenz gestellt wurde, gibt es keinen Grund das Rad neu zu
+erfinden. Es gibt natürlich Außnahmen: Falls sie ein Projekt als
+Lehr-Erfahrung anfangen wollen, wird Ihnen bereits existierender Code
+nicht weiterhelfen. Vielleicht wissen Sie bereits von vornherein, dass
+Ihr Problem so spezifisch ist, dass es mit Sicherheit noch von keinem
+gelöst wurde. Im allgemeinen gibt es aber keinen Grund sich nicht
+umzuschauen und der Lohn kann beträchtlich sein. Sollten die
+gewöhnlichen Suchmaschinen keine brauchbaren Ergebnisse liefern,
+sollte Sie es bei <ulink url="http://freshmeat.net/"/> (eine
+Nachrichtenseite über Open Source Projekte (mehr zu dieser Seite gibt
+es später), bei <ulink url="http://www.sourceforge.net/"/>, oder beim
+Verzeichnis für freie Software der Free Software Foundation
<ulink url="http://directory.fsf.org/"/> versuchen.</para>
<para>Selbst wenn Sie nicht genau das finden, wonach Sie suchen,
-könnten Sie etwas finden, dass dem so ähnlich ist, dass es mehr Sinn
-macht sich an diesem Projekt zu Beteiligen und die fehlende
-Funktionalität hinzuzufügen, als selbst von vorne an zu fangen.</para>
+könnten Sie etwas derart ähnliches finden, dass es sinnvoller ist
+sich an diesem Projekt zu Beteiligen und es um die fehlende Funktionen
+zu erweitern, als komplett von vorne anzufangen.</para>
</sect2>
@@ -156,57 +171,57 @@
<!-- ========================== SECTION =========================== -->
<sect1 id="starting-from-what-you-have">
-<title>Mit Dem Was Man Hat Anfangen</title>
+<title>Mit dem Vorhandenen anfangen</title>
<para>Sie haben sich umgeschaut, herausgefunden dass es nichts gibt,
-welches ihre Anforderungen erfüllt und sich entschieden ein neues
-Projekt anzufangen.</para>
+was ihre Anforderungen erfüllt und sich entschieden ein neues Projekt
+anzufangen.</para>
<para>Was jetzt?</para>
-<para>Das schwerste beim Beginn eines neune freien Software Projekts
-ist, eine private Vision in eine öffentliche zu verwandeln. Sie oder
-Ihre Organisation mögen sehr wohl wissen was Sie wollen, dieses Ziel
-verständlich für die Welt auszudrücken, ist aber eine beträchtliche
+<para>Das schwerste bei der Gründung eines neuen freien Software
+Projekts ist, die eigene Vision in eine öffentliche zu verwandeln. Sie
+oder Ihre Organisation mögen sehr wohl wissen was Sie wollen, dieses
+Ziel verständlich für die Welt auszudrücken, ist aber eine beträchtliche
Menge Arbeit. Es ist aber unabdingbar, dass Sie sich hierfür die Zeit
nehmen. Sie und die anderen Gründer müssen entscheiden worum es in dem
Projekt wirklich geht, bzw. Sie müssen sowohl über seine Grenzen
-entscheiden, -was es <emphasis>nicht</emphasis> machen wird, als auch
-was es tatsächlich machen wird- und ein Missionsziel verfassen.
+entscheiden—was es <emphasis>nicht</emphasis> machen wird, als auch
+was es tatsächlich machen wird—und ein Missionsziel verfassen.
Dieser Teil ist für gewöhnlich nicht all zu schwer, auch wenn es
manchmal unerwähnt gebliebene Annahmen, sogar Meinungsverschiedenheiten
-über die Natur des Projekts, aufdecken kann, was nicht schlecht sein
+über die Natur des Projekts aufdecken kann, was nichts schlechts sein
muss: Es ist besser diese jetzt aus dem Weg zu Räumen als später. Der
nächste Schritt, ist das Projekt für den öffentlichen verzehr
aufzubereiten, was im Prinzip reine Plackerei ist.</para>
-<para>Dies ist deshalb so mühselig, da es hauptsächlich darum geht
-Sachen zu organisieren und zu dokumentieren, die -"jedem" bereits
-bekannt sind, bzw. jedem der bisher beteiligt war. Für diejenigen die
+<para>Es ist deshalb so mühselig, weil es hauptsächlich darum geht
+Sachen zu organisieren und zu dokumentieren, die jedem bereits bekannt
+sind—d.h "jedem" der bisher beteiligt war. Für diejenigen die
die Arbeit machen, gibt es deshalb keinen direkten Nutzen. Sie
brauchen keine <filename>README</filename> Datei welches einen
-Überblick über das Projekt gibt, noch brauchen sie eine Entwurfs
-Dokument oder ein Handbuch. Sie braucht kein sorgsam ausgelegten
-Codebaum der mit den zwar informell aber weit verbreiteten Standards
-Quellcode Distributionen konform ist. Ihnen ist es egal, wie der
-Quellcode aufgebaut ist, sie sind ja bereits daran gewöhnt, und wenn
-der Code überhaupt läuft, wissen sie schon wie man ihn benutzt. Es
-macht ihnen nicht einmal was aus, wenn die grundsätzlichen Annahmen
-über den Aufbau des Projekts nicht dokumentiert werden, denn das
-kennen sie auch schon.</para>
-
-<para>Andererseits, brauche Neuankömmlinge diese Sachen. Zum Glück
-aber nicht alle auf ein mal. Es ist nicht notwendig, dass Sie jede
-mögliche Quelle zur Verfügung stellen, bevor Sie ein Projekt an die
+Überblick über das Projekt gibt, noch brauchen sie eine Dokument über
+den Aufbau oder ein Handbuch der Software. Sie brauchen kein sorgsam
+aufbereiteten Code der mit den zwar informell aber weit verbreiteten
+Normen für die Veröffentlichung von Quellcode, konform ist. Ihnen ist
+es egal, wie der Quellcode aufgebaut ist, sie sind ja bereits daran
+gewöhnt, und wenn der Code überhaupt läuft, wissen sie schon wie man
+ihn benutzt. Es macht ihnen nicht einmal was aus, wenn die
+grundsätzlichen Annahmen über den Aufbau des Projekts nicht
+dokumentiert werden; das kennen sie ja auch schon.</para>
+
+<para>Für Neulinge sind diese Sachen andererseits sehr wichtig. Zum
+Glück aber nicht alle auf ein mal. Es ist nicht notwendig, dass Sie jede
+mögliche Resource zur Verfügung stellen, vor Sie ein Projekt an die
Öffentlichkeit bringen. In einer perfekten Welt, würde vielleicht
-jedes Projekt, mit einem gründlich durchdachten Design Dokument,
-einen vollständigen Betriebsanleitung (mit besonderen Hinweisen für
-Funktionen die geplant aber noch nicht implementiert sind),
-wunderschön aufbereitetem und portablem Code, welches auf jeder
-Rechenplatform läuft, usw. In Wirklichkeit, wäre es unvertretbar
-Zeitaufwendig und überhaupt ist es Arbeit von der man hoffen kann,
-dass Freiwillige sie aufnehmen werden, sobald das Projekt
-unterwegs ist.</para>
+jedes Projekt, mit einem gründlich durchdachten Architechtur Dokument,
+einer vollständigen Betriebsanleitung (mit besonderen Hinweisen für
+Funktionen die geplant aber noch nicht implementiert sind), wunderschön
+aufbereiteter und portabler Code, der auf jedem Rechner läuft, usw. In
+Wirklichkeit, wäre es unvertretbar Zeitaufwendig all diese Sachen zu
+erledigen und überhaupt ist es Arbeit von der man hoffen kann, dass
+Freiwillige sie aufnehmen werden, sobald das Projekt in gang gebracht
+wurde.</para>
<para>Was jedoch <emphasis>wirklich</emphasis> notwendig ist, ist dass
genug in die Präsentation investiert wird, so dass Neuankömmlinge
_______________________________________________
Producingoss-translators mailing list
[email protected]
http://www.red-bean.com/mailman/listinfo/producingoss-translators
