Meiner Meinung nach ist der Review Prozess für neue Tutorials ineffizient und undurchsichtig.

Im Augenblick scheint der Ablauf ungefähr wie folgt zu sein:

1. User sendet PM mit Link zum Tutorial an Phobeus
2. Phobeus postet einen Link zum Tutorial irgendwo in einem internen Forum
3. DGL Member haben die Gelegenheit darauf zu antworten (1 Woche)
4. Phobeus sammelt die Anmerkungen und schickt sie per PM an den User
5. User arbeitet die Anmerkungen ein
6. Phobeus gibt sein ok damit irgendein Lektor das ganze lesen kann
7. Lektor liest das Tutorial und gibt dann letztlich sein ok

Zeit bis das Tutorial online ist: 2 Wochen?

Vor allem die Tatsache das alles über eine Person (Phobeus) zu laufen scheint kostet unnötig Zeit.
Warum darf man normale Artikel einfach so erstellen, Tutorials aber nicht?
Meiner Meinung nach sollte das so ablaufen:

1. User schreibt Tutorial auf einer Unterseite seiner Benutzerseite im Wiki (ggf. mit einem "Entwurf"-Tag)
2. User postet Link in einem Review-Unterforum (nur sichtbar für Mitglieder)
3. JEDES registrierte Mitglied kann Anmerkungen einbringen, kleinere Tippfehler werden sofort im Wiki korrigiert. Der Tutorialschreiber kann sofort darauf eingehen und das Tutorial verbessern.
4. Sobald mindestens ein DGL-Team-Mitglied das Tutorial gelesen hat und keine größeren Anmerkungen kommen darf das Tutorial in die Tutorialseite aufgenommen werden und wird in den News als "Entwurf" mit Verweis auf den Thread im Review-Forum angekündigt.
5. Spätere Anmerkungen können immer noch eingearbeitet werden. ES IST EIN WIKI, kein gedrucktes Buch!

Zeit bis das Tutorial online ist: 1-2 Tage!

_________________
Yeah!

Der Hintergrund ist eigentlich klar... ein Tutorial ist kein Wiki-Artikel. Während ein Artikel einen bestimmten Sachverhalt versucht zu erklären, wird der Leser bei einem Tutorial an die Hand genommen und bei der Einführung eines Themas begleitet. Spricht dieser jemand dann mit mehreren unterschiedlichen Stimmen, kann dies mitunter eher verwirrend als förderlich sein. Dies ist der Grund, wieso wir einen besonderen Schutzstatus auf die Tutorials erhalten und auch das Editieren (außer Rechtschreibfehler und Co) unterbinden. Den gerade im Gegensatz zu einer wissenschaftlichen Facharbeit, geht es mitunter nicht nur um einen Faktentransfer.

Der Hintergrund, dass die Kommunikation über eine Person abgewickelt wird hat mitunter auch einen Grund. Nicht immer gibt es ein Go für eine Veröffentlichung oder es gibt mitunter auch eine schärfe Kritik als nur ein paar Passagen weiter zu beleuchten. Und man sollte nicht aus den Augen verlieren, dass es viele unterschiedliche Typen Menschen gibt, die auf Kritik auf unterschiedliche Art und Weise reagieren. Einige finden es definitiv einschüchternd, wenn sie einen Text plötzlich gegen mehrere Seiten verteidigen müssen und nach und nach etwas nachrutscht. Andere leben plötzlich irgendwelche Antipathien aus, die sich dann weniger ersichtlich an anderer Stelle im Forum entladen etc. etc. Von daher erfolgt die Abgabe der Kritiken auch meist anonym bzw. über eine Person, da sich somit auf das wesentliche konzentriert werden kann... der Kritik selbst. Das ist kein starres System und wenn eine einzelne Person sehr viel kritisiert und ich nichts verstehe, werde ich einen Teufel tun die stille Post in der Mitte zu spielen.

Und Hand aufs Herz... eine Woche Reaktionszeit ist mitunter keine schlechte Sache. Bitte vergesse nicht, dass es hier etliche Leute gibt, die weder Schüler noch Studenten mehr sind und entsprechend nicht in der Lage sind sich binnen ein paar Tagen sinnvoll (!) mit einem Tutorial auseinander zu setzen. Immerhin soll eben im Gegensatz zu einem Artikel eine gewisse Qualität eingehalten werden oder verhindert werden, dass es nach einem Announce mehrere Nachkorrekturen gibt. Das ist frustrierend für Author und interessierten Lesern. Das der Review-Prozess meist inzwischen im Wiki abläuft ist dabei eher ein praktische Entwicklung. Ursprünglich (und ich favorisiere es weiterhin) ging es nur über echte Dokumente.

Den:

Genau an dieser Stelle würde es et absurdum geführt werden, zumindest dann, wenn es nur 1-2 Tage Review gibt. Das entspräche keiner Kontrolle mehr, sondern nur noch einem Durchwinken bei dem vermutlich nahezu gar kein Feedback mehr beigetragen würde. (Eben weil nur ein Bruchteil überhaupt eine solche Reaktionszeit bieten kann.) Und... in all den Jahren kann ich Dir auch eines vergewissern... wenn es Kritik und Angriffspunkte gibt (und die sind definitiv bei jedem Text möglich), wird sich eine Gruppe von max. 3 Leuten hinabwagen bis in die tiefste philosophische Ebene und sich irgendwann eher in Formalfragen verfangen (und ich verweise auch nochmal auf die unterschiedlichen charakterlichen Typen...). Das Review erfolgt momentan eben nicht durch die Mitglieder, sondern durch das Team. Dieses fühlt sich zum einen eher genötigt auch am Review-Prozess teilzuhaben und verfügen meist zumindest über ein Spezialgebiet in denen sie mitreden können. Zudem gibt es eine geschützte Umgebung, wo man auch mitunter einmal jemanden sagen kann: Vielen Dank für deinen Beitrag, aber der Text weist solch erhebliche Mängel auf, dass wir ihn nicht als Tutorial veröffentlichen würden. (und das gab es mitunter bereits). Meinst Du nicht, dass es gerade jenen so besser bekommen würde als dies in einer öffentlichen Diskussion zu "erfahren"? Wir versuchen die Leute zu ermutigen Mitzumachen und ich habe auch schon oft gesagt, dass wenn jemand ein Tutorial schreiben will... nicht erst auf uns zugehen muss, wenn ein vollständiger Text besteht, sondern ruhig bereits dann, wenn nur eine Idee besteht. (So kann man Schwerpunkte finden oder ggf. auch versuchen zu verhindern, dass sich identische Themen finden).

Das zweistufige Review dient vor allem dazu den Frust der Korrekturleser zu minimieren. Die sind meist nämlich nicht begeistert davon den Text häufiger lesen zu müssen bei dem Textpassagen an unterschiedlicher Stelle hängt etc. Das erste Review bezieht sich daher auf Inhalte oder struktuelle Schwächen und soll die Möglichkeit geben auch ganz Passagen ggf. neu am Reißbrett zeichnen zu können. Im zweiten Schritt geht dann jemand drüber, der meist nicht bisher direkt etwas mit dem Text zu tun hatte (also einer der Hauptkritiker war) und sich dann auch wirklich nur noch auf die Rechtschreibung konzentriert ohne bei jedem Satz noch prüfen zu müssen, ob dies inhaltlich überhaupt Sinn macht (oder gar den Code angucken, der meist das größten Potenzial für Fehler enthält, falsches C&P aus falschen Code zu einer viel zu späten Zeit z.B. ).

Ich hoffe, dass ich ein wenig das "Warum" erklären konnte. Das mag in Sachen Geschwindigkeit nicht unbedingt konkurrenzfähig sein, aber sowohl DGL als auch ich sind keine Kinder des Web 2.0

Ich muss ganz ehrlich sagen, dass ich nicht begeistert bin, wenn neue Tutorials im Wiki öffentlich geschrieben werden.
Für mich waren die Tutorials auch immer "Geschenke" an die Community. Und da gehört eine gewissen Überaschung mit dazu. Wenn man die Weihnachtsgeschenke selber bestellt ist das auch irgendwie doof.

Ganz wichtig ist auch der Punkt den Phobeus gebracht hat, mit der Kritik. Das Colorpicking Tutorial war so eine Sache. Da hatten einige im Team andere Vorstellungen als der Schreiber. Wenn wir das jedesmal im Forum breit tragen gibts nur genervte Schreiber die keine Tuts mehr liefern. Das wollen wir aber nicht. Deshalb macht sich das Team intern immer erstmal Gedanken in welche Richtung es gern das Tutorial sehen würde. Beim angesprochenem Tutorial ist das am Ende noch ganz gut gelungen indem man 2 Tutorials mit unterschiedlichem Tiefgang erstellt hat. (Gibts das Tut eigentlich als Wikiartikel oder immer noch nur als PDF?)

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Das vereinfacht aber das Arbeiten enorm, wenn man ein Dokument direkt in dem Medium schreibt für das es gedacht ist. Alternative wäre eine lokale Wiki-Installation (wer hat das schon) oder arbeiten mit der Vorschau-Funktion im Wiki ohne speichern des Artikels. Im letzteren Fall muss man dann ständig umständlich in einer TXT-Datei speichern und selbst für Versionshistorie und Backups sorgen...

Wenn es nur darum geht das die Tutorials nicht öffentlich sind (unsichtbar für Google&Co) könnte man im Wiki die Blacklist-Extension für MediaWiki nutzen. Ich nutze in meinem eigenen Wiki eine modifizierte Version die über Präfixe geht. Man könnte das also so konfigurieren das Artikel mit dem Präfix "Entwurf_" nur noch von registrierten Nutzern oder einer bestimmten Gruppe gelesen werden können.
Ich kann euch diese Extension gerne zukommen lassen. Möglicherweise könnte man das auch so umbauen das nach Kategorien gefiltert wird. So kann man einfach einen Artikel die Kategorie "Entwurf" zuweisen und der Artikel wäre nicht mehr öffentlich lesbar. (=> jeder kann Seiten beliebig freigeben und sperren)


Web 2.0 ist doch sowas von veraltet.....naja, ich will jetzt nicht von Waves anfangen.

Naja, ich kann eure Argumente halbwegs nachvollziehen. Trotzdem, ihr solltet bedenken, dass dieses langsame Verfahren auch wieder Tutorialschreiber "abschreckt" oder zumindest deren Motivation dämpft...wie bei mir zum Beispiel.

_________________
Yeah!

Das vereinfacht aber das Arbeiten enorm, wenn man ein Dokument direkt in dem Medium schreibt für das es gedacht ist. Alternative wäre eine lokale Wiki-Installation (wer hat das schon) oder arbeiten mit der Vorschau-Funktion im Wiki ohne speichern des Artikels. Im letzteren Fall muss man dann ständig umständlich in einer TXT-Datei speichern und selbst für Versionshistorie und Backups sorgen...[/quote]
Nun ne TXT wäre auch eher ungeeignet. Der Vorteil eines Text Processors besteht zumeist darin, dass man meist eine bessere Unterstützung für Rechtschreibprüfungen hat und dies sicherlich den Lektoren auch auffällt. Die Sache mit dem Backup überrascht mich... auch wenn ich mich stets bemühe gewissenvoll Backups zu machen, sollte DGL nicht als sicherer Lagerort angesehen werden. Übrigens: Für OpenOffice gibt es Export-Module nach Wiki


Zumindest für mich überwiegt die "Überraschung" da ein wenig ... weniger. Ich halte es halt eher für problematisch, wenn ein Tutorial in einer Gemeinschaft entsteht, da es dann vermutlich doch als ein nüchterner Artikel besser daher käme.


Naja, das ist es was ich meinte. Man muss nicht jedem neuen Trend hinterher laufen... eine gesunde Portition Skeptik hat nur selten geschadet. Die meisten meiner früheren Tutorials sind im Laufe von rund 4 Wochen entstanden und da war die Korrektur (die es früher ja fast nie gab *g) noch überhaupt nicht inbegriffen. Von daher denke ich das Reaktionszeiten um die 3 Wochen noch wirklich prima sind. Das soll nicht heißen, dass sich so mancher Wandel nicht lohnt. Auch das Wiki hat zu Beginn eine Gegenstimme durch mich erhalten, weil ich nicht glaubte, dass das Konzept funktionieren würde. Ich würde einen Teufel tun dies nicht im nachhinein als Fehler zu bezeichnen. Nur ist gerade die Geschwindigkeit und Schnelllebigkeit des Netzes nicht immer nur vom Vorteil.


Es würde mich überraschen, wenn dies wirklich ein Problem darstellt. Sollte dies der Fall sein können sich sicherlich einige Tutorialwillige melden und wir organisieren da ein schnelleres Verfahren. Immerhin gibt es ja mitunter auch bei DGL einige Sachen bei denen man schnell zu einem Ergebnis kommt (nfc). Mit den meisten "Willigen" mit denen ich gesprochen habe (und dies trifft zumeist für die Jüngeren zu) war oftmals eher eine Angst drin etwas abzuliefern, was nicht gut genug ist. Genau jenen würde ich gerne signalisieren, dass eben die Arbeit an einem Tutorial kein Prozess ist bei dem man zwangsläufig alleine bereit steht oder sich eben nicht auch austauschen kann. Ich bin mir z.B. ziemlich sicher, dass mich jeder halbwegs aktive Forenteilnehmer im Fragen rund um Shader problemlos das Wasser reichen kann. Nur weil ich früher ein paar Tutorials geschrieben habe, heißt es nicht, dass ich keine Defizite hätte und man eben nicht auch frischen Wind von anderer Seite zu bekommen. Steht man als Neuer jedoch vor einem alten Monolithen, kann man sich schnell klein vorkommen. (Das gilt natürlich nicht für alle Charaktere). Von daher eher die Betonung auf: Mut zu Taten! Jeder aus dem Team ist (meist) direkt ansprechbar und auch die Community hilft gerne weiter.

Vielleicht erarbeitet man sich ja eben halt mal über 3 Monate lang in ein Thema und versucht dann dazu ein Tutorial abzuliefern bei denen man versucht genau das aufzugreifen, wo man selbst Probleme mit hatte. Ich erinnere mich da mitunter an einige witzige Annektoten, wo wir versuchten im Raum mit ausgeschränkten Armen grafisch darzustellen, wie es eigentlich mit den Matrizen so verhält. Dies erwies sich beim Schreiben jedoch als sehr schwer darstellbar ohne das der Leser verwirrt wurde, wer nun wie darstand. Daraus entstand dann die Idee es an Hand eines Bildschirms zu beschreiben, da dies einfach plastisch für jeden greifbar sein sollte. Ich hoffe eben gerade, dass Zeit nicht das Review ein Motivationskiller ist... und eben gerade auch die dortigen Krtiken nicht als eine an der Person oder der Arbeit verstanden werden. Ich meine... wir haben ein Wiki...

Ich schreibe im Wiki, also im Browser. Und der Browser hat eine Rechtschreibprüfung. Zum Angucken wird die Vorschau-Funktion des Wikis benutzt. Nur zum speichern wird dann eben alles markiert und in eine TXT-Datei kopiert.


Seit ich herausgefunden habe das für OpenOffice 32 * 0.89 manchmal gleich 28,48 (korrekt) ist, manchmal (*) aber auch 28,63 ist, meide ich das wann immer möglich.
Allerdings ist M$ Office noch schlimmer

(*) wenn die 0.89 per WVERWEIS aus einer anderen Tabelle kommt.

_________________
Yeah!