Hallo Andre, *,
On Sunday 30 January 2005 11:11, Andre Schnabel wrote:
> ich beschr�nke mich hier mal auf ein Thema ;-)
klar, warum nicht?
> Thomas Hackert schrieb:
> >1. Wenn mehrere Leute sich zu einer �bersetzung zusammenfinden,
> > w�re es nicht sinnvoll, das der Initiator die F�den in der Hand
> > h�lt (sprich: Er ruft auf der [EMAIL PROTECTED] Mitstreiter auf. Per PM
> > werden dann die Originaldokumente unter den �bersetzern
> > aufgeteilt. Die anderen �bersetzer senden dann dem
> > Ursprungs�bersetzer ihre Teile zu, die der Initiator dann
> > wieder verschmelzt und ins issue h�ngt, und sich Korrekturleser
> > sucht ....).
> Absolut. Das war das, was ich ganz am Anfang der �bersetzerei mal
> damit meinte, dass wir jemanden brauchen, der das "managed".
> Allerdings l�sst sich hier eine Aufteilung schwer von einem
> "Manager" fastlegen. Man kann im Voraus schlecht planen, wer
> wirklich an einer Aufgabe arbeitet, selbst wenn sich Freiwillige
> melden, arbeiten nachher nur wenige dran (was keine Kritig sein
> soll, sondern in der Natur der freiwilligen Mitarbeit in der
> Freiziet liegt).
Ich meinte es hingegen bei jeder einzelnen �bersetzung, dass einer
der �bersetzer bzw. der Initiator dann die F�den in der Hand h�lt.
Einen "Manager" f�r alle anstehenden �bersetzungen zu finden, wird
meiner Meinung nach sehr schwer ... :(
> F�r eine Konkrete Aufgabe (wie den Installer) ist es aus meiner
> Sicht das Beste, wenn derjenige am meisten dran arbeitet auch das
> Management mit macht (und um hilfe schreit, wenn er damit nicht
> zurecht kommt).
So h�ndel ich das mit meinen �bersetzungen auch. Mein Hintergedanke
war - neben der �bersichtlichkeit der issues - auch noch, das ich
als �bersetzer dann z.T. mit 3-4 verschiedenen Versionen von
Korrekturlesern den �berblick verloren hatte und dann (gute!)
�nderungen verloren gingen, weil zwischenzeitlich wieder eine neue
Korrektur eingetroffen war. Und damit kannst du dir wahrscheinlich
dann noch betroffene Korrekturleser vergraulen ... :(
> >2. Entsprechend dem Vorgehen sollte es dann nat�rlich mit den
> >Korrekturlesern laufen. Der erste, der sich meldet, schnappt
> > sich das Originaldokument. Der folgende bekommt dann die
> > korrigierte Fassung vom ersten Korrekturleser und reicht sie an
> > den n�chsten weiter. Falls dann noch n�tig wird das Dokument
> > dann an den vierten weitergereicht, sonst wird es wieder an den
> > ersten Korrekturleser bzw. dem Originalautoren geschickt und
> > ins issue geh�ngt. Hintergrund ist, dass mir aufgefallen war,
> > dass u.a. bei der �bersetzung des "Installers" ja bei einigen
> > Leuten der �berblick fl�ten ging, da ja nachher eine ganze
> > Menge an Versionen im issue hingen. So w�rde das doch der
> > �bersichtlichkeit dienen, oder nicht?
> Jein.
> Wenn die Kette funktioniert,
... und hier liegt meiner Meinung nach das Problem ....
> ist das Ergebnis tats�chlich
> �bersichtlicher. Wenn aber die kette unterbrochen wird (und der
> "Manager" in dem Moment auch noch ausf�llt oder nicht kurzfristig
> regieren kann) kann es passieren, dass die Arbeit verloren ist.
> (Mindestens ein Arbeitsschritt geht verloren, es ist aber auch
> schon passiert, dass die ganze Arbeit stecken geblieben ist, ewig
> auf einen Arbeitsschritt geartet wurde).
Die Idee von mir war eigentlich, eine Kette �berhaupt erst einmal zu
starten. Ich fand das Managen von verschiedenen Versionen einer
�bersetzung z.T. zeitaufwendiger als das �bersetzen selbst ... :(
Zudem kommt bei mir ja auch noch das nicht so schnell reagieren
k�nnen wie gewollt / ben�tigt hinzu ...
> Ich denke, die einzelnen Arbeitsst�nde sollten schon auf einem
> Issue abgelegt werden. Was im konkreten Fall des Installers h�tte
> anders gemacht werden k�nnen:
Es war ja nicht nur beim Installer. Hattest du nicht auch in einem
anderen issue den �berblick �ber die aktuellste �bersetzung
verloren (ist jetzt nicht b�se gemeint ... ;) )?
> - statt den Issue von der Entwicklung zur �bersetzung zuzuweisen
> und dann wieder zur�ck, h�tte ein eigener "�bersetzungs-Issue"
> (Task) ge�ffnet werdenk�nnen, der den "Entwicklungs-Issue"
> (patch) blockt . W�hrend der �bersetzung gehen die Zwischenst�nde
> auf den �bersetzungs-Issue. Wenn die �bersetzung fertig ist, geht
> die fertige Datei auf den Entwicklungs-Issue
> - Gr�ssere Diskussionen sollten auf den Issues vermiden werden.
> Dort sollte nicht mehr als ein kuerzer Hinweis zum Arbeitsstand /
> n�chsten Schritten erschienen, evtl. noch wichtige
> Randbedingungen. Diskusionsn, wer mitarbeitet, �ber Verfahren ...
> sollte auf den Mailinglisten passieren.
+1
> Das sind aber keine starren regeln, nur Vorschl�ge. Im Endeffekt
> lief es garnicht so schlecht, daf�r, dass es die erste
> �bersetzung war, die wir am Code gemacht haben ;-)
+1 ... ;)
Bis dann
Thomas.
--
Every paper published in a respectable journal should have a preface
by the author stating why he is publishing the article, and what
value he sees in it. I have no hope that this practice will ever
be adopted.
-- Morris Kline
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
