Das Interview zum Thema "Erfahrungen mit Wiki-Software"

	Ina Müller-Schmoß	Stefan Waidele
Kürzel:	InaMS	StW
Website:	kreative-strukturen.de	stefan.waidele.info
	Reto Stauss	Trau Dich!
Kürzel:	RetoS	Platz für Dich
Website:	nachhaltigBeobachtet

Bei diesem Interview kann jeder mitmachen! Wer Fragen, Zwischenfragen, Antworten hat oder ganz andere Aspekte die zum Thema passen, beleuchten will, kann dies hier tun.

Einfach auf „Bearbeiten“ klicken, in der Tabelle oben ein Kürzel anlegen und dann im entsprechenden Abschnitt losschreiben. Immer mit dem eigenen Kürzel vor jedem Absatz, damit hinterher klar ist, wer was gesagt hat. Und am besten auch darauf achten, dass die Aussagen der anderen TeilehmerInnen nicht „zerhackt“ werden. Sonstige Regeln? Die des gesunden Menschenverstandes: Seid nett zueinander; geht mit anderen so um, wie Ihr es gerne für Euch selbst auch hättet; nichts Illegales oder Anstößiges. Stellt Euch vor, wir sitzen gemütlich im Wohnzimmer beisammen und reden miteinander.

• Technische Vorkenntnisse
  

StW: Technisch betrachtet, ist ein Wiki nur eine Webseite wie jede andere auch. Wer ZIP-Archive auspacken und Dateien auf seinen Webserver hochladen kann (oder wer jemanden kennt, der das für einen tut) ist eigentlich schon ganz gut gerüstet.

• Infrastruktur: Server, Software, Domain
  

StW: Bei Free-Burma speziell war es natürlich vorteilhaft, dass ich die technische Infrastruktur schon komplett bereit hatte: Ich hatte einen Webserver, einen Domainnamen vor den ich „free-burma“ setzen konnte, und das Einrichten von Wikis habe ich auch schon einige Male erledigt. So hatte ich einen „Geschwindigkeitsvorteil“, der bei dieser schnellen Aktion wichtig war.

• Kenntniss der Abläufe:
  

StW: Ich musste nicht „alles über Burma“ wissen, aber ich musste sehen: Hier kommt ein dynamischer Prozess in Bewegung, der (wegen der Kürze der Zeit und auch wegen der Beschaffenheit der Zielgruppe) nicht zentral gesteuert werden kann. Man muss erkennen, ob das Werkzeug Wiki für die Aufgabe geeignet ist, oder nicht.

• Die Wahl des Werkzeugs:
  

StW: Wie sagen die Amerikaner: „If the only tool you have is a hammer, everything looks like a nail.“ - Wenn man nur einen Hammer hat, sieht alles aus wie ein Nagel.
Ein Wiki ist meistens dann geeignet, wenn mehrere Leute an Texten zusammenarbeiten wollen und am Ende ein gemeinsames Ergebnis stehen soll. (z.B. stellen wir hier dieses Interview ein, das man nicht nur lesen kann, sondern bei dem man selbst auch mitwirken kann.) Soll hingegen ein Ablauf dokumentiert werden, und die Teilnehmer wollen einzelne Momentaufnahmen machen, so ist wahrscheinlich ein Blog besser geeignet. (z.B. Reiseblog zur Dokumentation einer Urlaubsreise)

• Wiki-Kultur:
  

StW: Bei einer so sehr auf Öffentlichkeit ausgelegten Aktion war es auch wichtig, dass ich mit der „Wiki-Kultur“ vertraut und somit auf Situationen, die speziell bei Wikis auftreten können, vorbereitet bin. So habe ich die Veränderungen im Wiki regelmäßig überprüft, um sicherzustellen, dass nichts Illegales oder Extremistischen eingestellt wurde.
Auch wäre es möglich gewesen, dass Gegner der Aktion die Texte gelöscht hätten. Dann wäre schnelles Eingreifen notwendig gewesen. (Mit „Gegnern“ meine ich nicht diejenigen, die diese Aktion kritisiert haben, sondern „politische Gegner der Freiheit in Burma“ oder auch „Trolle“, also Leute, die einfach des Effektes wegen stören).

StW: Wie schon gesagt: Wikis sind überall dort geeignet, wo mehrere Leute zusammen an Texten arbeiten. Die jeweils aktuellen Versionen dieser Texte sind wichtig - der zeitliche Ablauf ist zwar nachzuvollziehen, steht jedoch nicht im Mittelpunkt.

StW: Speziell bei der Planung von Projekten sind folgende Eigenschaften hilfreich:

• Geringe Anforderungen an die Bedienung:
  

StW: Klickt man auf „Editieren/Bearbeiten“, hat man einen Text vor sich, den man verändern kann und dann klickt man auf „Speichern“. Das ist schon alles. Es bestehen auch Funktionen für Fortgeschrittene, aber diese sind zur grundlegenden Bedienung nicht notwendig.

• Sanfter Einstieg ins Projekt möglich:
  

StW: Nicht jeder will sofort eine ganze „Doktorarbeit“ ins Wiki stellen. Aber aufgrund der einfachen Bedienung ist es jedem möglich kleine Verbesserungen direkt selbst vorzunehmen. Die Korrektur von Rechtschreibfehlern ist hierfür ein gutes Beispiel. Wer einen Fehler in einem Text entdeckt, darf (und sollte) ihn direkt verbessern.
Wer den Einstieg über die Korrektur von „Vertippern“ gefunden hat, wagt sich bald auch an die Grammatik oder fügt den einen oder anderen Satz hinzu, um den Text besser verständlich zu machen. Und schon hat man das Helferpotential besser genutzt.

• Es ist immer die aktuelle Version der Texte verfügbar:
  

StW: Die aktuelle Version ist immer an der gleichen Stelle verfügbar. Änderungen werden direkt eingepflegt. Es entsteht kein „Informationsstau“ oder gar Chaos wie es bei der Kommunikation per E-Mail passieren kann.

• Änderungen sind nachvollziehbar (und können Rückgängig gemacht werden):
  

StW: Auf historische Versionen kann jederzeit zurückgegriffen werden. Vergleiche zum aktuellen Stand sind gut möglich. Fehler können somit korrigiert werden. Per E-Mail oder RSS kann man über jede Änderung informiert werden.

• Zugriffskontrolle:
  

StW: Die ursprünglichen Wikis waren so konzipiert, dass jeder anonym die Seiten verändern konnte. Dies ist bei den aktuellen Systemen immer noch möglich, kann aber auch verhindert werden. Je nach Software kann man bestimmte Seiten nur speziellen Nutzergruppen zugänglich machen. Geschickt eingesetzt, kann somit die Einstiegsschwelle auch gesenkt werden, indem man in manchen Bereichen anonymen Nutzern die Mitarbeit gestattet (z.B. Wunschliste oder Ideenkiste). Andererseits kann man Bereiche auch so schützen, dass nur Administratoren diese überhaupt lesen dürfen (z.B. E-Mailadressen der Mitarbeiter).

StW: Es gibt eine Menge von verschiedenen Wiki-Programmen. Für meine Projekte verwende ich DokuWiki. Ich denke, das könnte man als Empfehlung werten :)

StW: Ich schätze an DokuWiki vor allem die geringen Systemanforderungen, den Funktionsumfang und die Möglichkeiten, das System an meine Bedürfnisse anpassen zu können.

StW: Es gibt reichlich Wiki-Software, die nichts kostet. Eine Übersicht über die verschiedenen Systeme findet man auf englisch (mit Funktionsvergleich) unter wikimatrix.org oder auf deutsch (nach Programiersprachen geordnet) bei der Wikipedia: http://de.wikipedia.org/wiki/Liste_von_Wiki-Software.

StW: Mit den ebenfalls erhältlichen „Enterprise Wiki Systemen“ habe ich mich noch nicht auseinandergesetzt, jedoch kann ich die im Bericht der Computerwoche aufgezählten Argumente gegen freie Systeme nicht nachvollziehen.

StW: Für die ersten Schritte reicht jedenfalls ein kostenloses System.

RetoS: Wer für das Selbst-Management ein leichtes, aber komplettes Wiki verwenden möchte, der sollte sich mal TiddlyWiki ansehen. Kommt ohne Installation aus, da es komplett auf einer einzigen javascript-basierenden HTML-Seite, welche einfach um Browser aufgerufen wird, aufsetzt. Mehr bei Wikipedia oder auf der Website.

StW: Ja, solche „Ein-Personen-Wikis“ sind nicht schlecht, um mit der Arbeitsweise vertraut zu werden. Ich selbst habe sie nicht erwähnt, da sie eben genau das sind: Ein Personen Wikis, und damit zur Zusammenarbeit mehrerer Leute nicht geeignet. Aber ja: Zum schnellen ausprobieren, oder als persönlicher Zettelkasten sind die sicher prima.

StW: (Jetzt „intraviewe“ ich mich schon selbst!) Neben dem erwähnten TiddlyWiki ist sicher auch Wiki-in-a-Jar interessant, über das ich im Toolblog gelesen habe. Es hat eine „Taggingfunktion“, das bedeutet, man kann einzelne Seiten (oder Karteikarten) verschlagworten. (Furchtbares Wort, oder?) Über die vergebenen Schlagworte/Tags kann man dann aus unterschiedlichen Richtungen an die eigenen Notizen herangehen.

Frage von Claudia (Sammelmappe), eingetragen von StW.

StW: Das war für uns bei LinuxBasics.org einer der Gründe, warum wir uns für DokuWiki entschieden haben: Wir wollten für den Fall eines späteren Wechsels des Systems nicht auch noch mit internen Strukturen und Datenbanken auseinandersetzen. Da DokuWiki die Texte auch als normale Textdateien speichert, hat man da einiges an Möglichkeiten, das ganze einigermaßen automatisch in andere Systeme reinzubringen. (Wobei ich zugeben muss: Wir hätten uns da selbst Programme geschrieben, die diese Textdateien in das eventuelle „Zielsystem“ gebracht hätten - also nicht wirklich was für Leute, die so wenig wie möglich mit der Technik behelligt werden wollen :)

StW: Generell ist der Wechsel von einem CMS auf ein anderes immer problematisch. (CMS: Content Management System - und genau das sind Blogs und Wikis ja auch). Wenn die Entwickler eine entsprechende Import- bzw. Exportfunktion vorgesehen haben ist alles Wunderschön - wenn nicht, dann nicht.
Wenn man jedoch beim gleichen System bleibt, aber auf einen anderen Server umziehen will, dann ist die Sache einfacher: Die Rohdaten (Dateien oder Datenbank) speichern (Backup) und auf dem neuen Server wieder einspielen (Restore) und es sollte gut sein.

StW: Aber es lohnt sich auf jeden fall vorher ein wenig mit den verschiednen Systemen zu spielen - weshalb wir ja dabei sind hier auf der Spielwiese entsprechende Möglichkeiten zu schaffen. Denn wenn man das Programm schon ein wenig kennengelernt hat, dann ist die Wahrscheinlichkeit, dass ein Wechsel notwendig wird viel kleiner.

StW: Das ist das Programm, das hier auf dem Webserver läuft. Die Wiki-Software. Siehe oben.

StW: Wikipedia hat eine schöne, gut verständliche Zusammenfassung der Eigenschaften, die Homepage findet sich hier.

StW: Bei längerfristigen Projekten ist darauf zu achten, dass man sich am Anfang die Zeit nimmt, eine Struktur des ganzen Wikis zu erarbeiten. Eine oft gestellte Frage bei Wikis lautet: „Auf welcher Seite soll ich diese Information hinzufügen?“. Und wenn eine neue Seite erstellt werden soll, dann herrscht oft Unsicherheit, wie diese genannt werden soll. Diese Unsicherheit lässt sich durch klare (und dokumentierte) Strukturen vermeiden.

Anm:InaMS Ich liebe klare Strukturen.

StW: Wikis sind vom Design her voll auf Flexibilität ausgelegt. Dies kann aber auch dazu führen, dass Wikis unübersichtlich werden. Hier ist es dann notwendig, Seiten aufzuteilen, zusammenzulegen oder in der Hierachie zu verschieben. Immer im Wissen: Man kann nichts wirklich kaputt machen - die alte Version ist immer noch abrufbar.

StW: Auch ist es von Vorteil, sich mit den unauffälligeren Funktionen zu beschäftigen, wie „Backlinks“, „Index“ und der „Zusammenfassung“.

• Backlinks - diese Funktion zeigt an, welche anderen Seiten im Wiki auf die aktuelle Seite hinweisen.
• Index - Zeigt als Inhaltsverzeichniss alle Seiten im Wiki an.
• Zusammenfassung - Nur eine kleine Textbox unterhalb des großen Editors. Hier kann man beschreiben, was man an der Seite geändert hat. Dieser Text wird dann im Bearbeitungsverlauf („Ältere Versionen“ bzw. „Page History“) angezeigt und erleichtert so das wiederfinden von bestimmten Arbeitsschritten. (Als Beispiel: Der Verlauf dieser Seite)

StW: Diese Funktionen sind bei allen Wiki-Programmen verfügbar, werden aber eventuell anders genannt.

StW: Je nach System gibt es auch weitere Funktionen:

• Automatisches Erstellen von Google-Sitemaps
• Erzeugung von „schönen URLs“ (also http://spielwiese.stots.de/interview statt http://spielwiese.stots.de/doku.php?page=interview)
• Integration von eigenen Designs (auch Skins oder Themes genannt)
• …

StW: Auch wenn wir hier in einen Bereich der Konfiguration vordringen, der nicht mehr „so nebenbei“ erledigt wird, ist es für langfristige Projekte ratsam, diese Dinge möglichst früh anzugehen. Speziell das Format der URLs sollte nämlich nicht geändert werden, da sonst viele Lesezeichen oder Links von anderen Seiten nicht mehr funktionieren könnten.

Auch sollte es eine Person oder eine Gruppe von Leuten geben, die sich um die Moderation des Wikis kümmern.
StW: Bei Free-Burma habe ich genau genommen gar keine eigenen Ideen eingebracht. Ich habe die Gedanken, die in den Blog-Kommentaren vorkamen ins Wiki übertragen, habe mich ein wenig um die Seitenstruktur gekümmert, und die Übersetzungen angefangen. Hauptsächlich habe ich „Beispiele“ gegeben, an denen sich die anderen Teilnehmer orientieren konnten - oder auch nicht. Wenn sich in einem Bereich eine bessere Struktur herauskristalisierte, habe ich diese auf die anderen Bereiche übertragen.

StW: Da man bei solchen Arbeiten massiv „an den Gedanken anderer“ tätig wird, ist es von Vorteil, wenn man zumindest zeitweise diese Moderatorenrolle annimmt, und nicht eigene Gedanken dazumischt. Bei längerfristigen Projekten sollten also Moderatoren feststehen, die sich auch trauen, massive Veränderungen am Text vorzunehmen.

StW: Es gibt in jedem Wiki eine Kerngruppe, die editiert. Dies ist jedoch keine Frage des Dürfens (Berechtigung), sondern des Trauens (Mut haben).

StW: Dazu muss man sich bewusst machen, dass Änderungen im Wiki etwas sehr „intimes“ und gleichzeitig etwas sehr „öffentliches“ sind. Wer im Wiki mehr tut als nur Rechtschreibfehler zu korrigieren (hey, das ist super wichtig!), der bringt seine Gedanken ein und vermengt diese mit den Gedanken anderer.

StW: Bei einem Telefonat sagt jeder seine Meinung, man tauscht sich aus, zwei Personen und gut ist. Wenn der Hörer aufgelegt wird, kann man sich das alles nocheinmal anders überlegen. Bei einem Kommentar im Blog ist die Sache schon öffentlicher: „Die ganze Welt“ kann lesen, was man denkt. Einerseits schüchtert das ein, denn man wird ja auf seine Meinung festgelegt. Andererseits kommt die innere Stimme die sagt: „Wie eingebildet bist Du eigentlich, dass Du denkst, hier etwas sinnvolles beitragen zu können!“ Und genau dieses Dilemma verstärkt sich noch, wenn die eigene Meinung nicht mehr nur zusätzlich zum Blogposting erscheint, sondern direkt in den Wiki-Artikel selbst mit einfließt.

StW: Generell kann man jedoch sagen: Wenn die Betreiber eines Wikis Schreibrechte anbieten und zum Editieren einladen, dann kann man dieses Angebot auch gerne annehmen. Man muss ja nicht sofort die ganze Seite umgraben, sondern kann sich mit kleineren Änderungen an die „Community“ herantasten. Rechtschreibfehler korrigieren, einzelne Sätze zum besseren Verständniss hinzufügen, eine neue Seite mit den eigenen Gedanken hinzufügen. Mit der Zeit fühlt man sich wohler und traut sich auch größere Änderungen vorzunehmen.

StW: Generell sollte man darauf achten, dass man die Seite verbessert. Dann ist so ziemlich alles erlaubt. Außer dem, was verboten ist, also illegales usw., oder dem was nicht zum Thema gehört.

StW: Meistens haben die Projekte, die Wikis anbieten auch Richtlinien, an die man sich dann halten sollte. Aber das sagt einem ja schon die Höflichkeit, dass ich im Vegetarier-Wiki keine Metzgereiwerbung hinterlasse, oder?

StW: Auch Copyright-Fragen gehören in diese Rubrik. Da jeder Autor das Copyright zu seinen Texten hat, sollte man bei öffentlichen Wikis entsprechende Regelungen treffen. Bei LinuxBasics.org wurde der Text auf dem Speichern-Knopf von „Save“ in „Contribute under the terms of the GPL“ geändert um sicherzustellen, dass die Anleitungen unter dieser Lizenz weiterverwendet werden dürfen.

StW: Auch gibt es natürlich die Möglichkeit, ein Wiki-System als CMS zu verwenden, also Eingabehilfe zur Präsentation mehr oder weniger statischer Seiten. Diese Seiten sind dann aber in meinen Augen keine Wikis mehr, sondern benutzen nur Wiki-Technologie.

StW: Ja.

StW: Wiki ist Kollaboration. Warum neue Ideen den anderen vorenthalten? Oder nur mit einigen wenigen besprechen. Rein ins Wiki, viele Augen sehen besser, und viele Köpfe können mehr aus jeder Idee machen. Dafür sind Wikis da. Wenn dann etwas „gefestigtes“ entstehen soll, dann kann man ja die Gedanken aus dem Wiki nehmen, und in ein Blog oder eine „normale“ Webseite tun. Aber Wikis sind Spielwiesen für Ideen.

Anm: InaMS: …und ich liebe Ideen-Spielwiesen.

StW: Das Thema „Vandalismus bei Wikis“ ist überbewertet. Ich arbeite seit vier Jahren mit öffentlichen Wikis, und hatte bis jetzt nur zwei kleine Zwischenfälle. Bei einem wurde ich selbst tätig; beim Burma-Wiki wurde der „Smiley“ durch die “Wiki-Selbstheilung” (also durch die Korrektur anderer, die das Wiki lesen) auch schnell wieder ohne mein Zutun entfernt.

StW: Es ist jedoch unbedingt notwendig die Änderungen in einem Wiki im Auge zu behalten und falls notwendig, einzuschreiten. Dies sollte der oben beschriebene Moderator tun.

StW: Die Werkzeuge, die ihm dabei zur Verfügung stehen sind Benachrichtigungen per RSS oder E-Mail, sobald sich eine Seite verändert, sowie die Versionsverwaltung, mit der die korrekte Version der Seite wieder hergestellt werden kann.

StW: Ein klassischer Text zum Thema „Warum Wikis funktionieren“ geht auch speziell auf das Thema Vandalismus ein: http://moinmo.in/WhyWikiWorks#head-55cd16532c0ec490d7ae3f696de8e0a20f00c85f. Aber der ganze Text ist lesenswert. Es wird nicht nur erklärt „Warum Wikis funktionieren“ und auch „Warum Wikis nicht so gut funktionieren wie wir uns das vorstellen“ - leider auf englisch: http://moinmo.in/WhyWikiWorks

StW: Gar nicht :)

StW: Nein Ernsthaft: Das gleichzeitige Bearbeiten eines Dokumentes ist wohl noch eine der großen Herausforderungen der EDV: Ich starte „meine“ Bearbeitung und lade den ursprünglichen Text in den Editor. Du startes „Deine“ Bearbeitung und lädst den gleich Text in Deinen Editor. Jeder nimmt seine Änderungen vor, und derjenige, der zuletzt auf speichern klickt, hat gewonnen.

StW: Per “Locking“ verhindern alle Wikisysteme dieses Problem des “verlorenen Updates“. Das bedeutet, solange ein Benutzer eine Seite im Wiki bearbeitet, kann kein anderer diese verändern. Dies ist vor allem bei großen Seiten, die von vielen Leuten genutzt werden, ein Problem. Hier hilft es, eine Seite in mehrere Detailseiten aufzutrennen.

StW: Manche Wikisysteme erlauben auch das gleichzeitige Bearbeiten von verschiedenen Seitenabschnitten (meist von Überschrift zu Überschrift) - jedoch ist dies eine eher selten anzutreffende Eigenschaft. MediaWiki versucht, einander nicht betreffende Änderungen automatisch zusammenzuführen. Jedoch reichte für meine Einsatzzwecke das klassische Locking der ganzen Seite aus.

StW: Das kommt auf die Wiki-Software an, die zum Einsatz kommen soll. Aber ganz generell braucht man:

• Webspace - Wenn man nicht nur von innerhalb des eigenen Firmennetzwerkes auf das Wiki zugreifen will, dann muss dieses aus dem „großen weiten Internet“ erreichbar sein. Man muss nicht gleich einen ganzen Server mieten, ein günstiges Hostingangebot reicht aus, solange bei diesem die nachfolgenden Punkte gegeben sind.
• PHP - Die meisten Wiki-Systeme sind in PHP programmiert. Diese Programmiersprache wird in den meisten Hostingpaketen angeboten, so dass diese Anforderung meist kein großes Problem darstellt. Wenn das Wiki-System der eigenen Wahl eine andere Sprache vorraussetzt, dann muss natürlich diese auf dem Webserver installiert sein.
• MySQL - Viele Wikis speichern die Seiten nicht selbst in einzelnen Dateien, sondern in einer Datenbank ab. MySQL ist ein solches Datenbankprogramm, das sich im Hintergrund um eine effiziente Ablage kümmert. Manche Wiki-Systeme brauchen diese Komponente nicht, andere unterstützen auch andere Datenbanken wie PostgreSQL oder Oracle.

StW: Eigentlich war's das schon. Wer also eine Webseite online hat, der hat normalerweise auch schon die Voraussetzungen für den Betrieb eines Wikis abgedeckt.

StW: Gibt es Bücher über Wikis? Vielleicht sollte ich eines schreiben :)

StW: Ich kann jedem empfehlen, Wikis einfach auszuprobieren. Direkt hier auf der Spielwiese oder auf dem eigenen Rechner. Man kann Wikis auch alleine nutzen, sozusagen als Zettelkasten. So kann man sich mit der Technik vertraut machen, und wenn dann eine Situation auftaucht, in der ein Wiki sinnvoll ist, dann kann man dies erkennen und einsetzen.

StW: Wer schon im Internet über ein Wiki gestolpert ist, dass ihn vom Thema interessiert, der sollte den Mut aufbringen und dort mitarbeiten: Wie schon gesagt: Rechtschreibfehler sind gute Übungsfelder für Anfänger. Ich habe absichtlich einige in meine Antworten eingebaut - mal schauen, wer die meisten findet :)

Anm: InaMS (ach so und ich korrigiere gerade fleißig.) - StW: Und ich habe mir solche Mühe gegeben… - Wären die Fehler wirklich absichtlich gemacht worden, könnte ich Deine Korrekturen ganz leicht wieder rückgängig machen! :)

StW: Auch wenn ich mich wiederhole: Mein großer Tip zum Thema Wiki: „Trau Dich!“

StW: Hier habe ich doch noch einen tollen Link zum Video: “Wikis in plain english“ - wie der Name schon sagt auf englisch.

Die Hauptprobleme bei der Free-Burma-Aktion waren:

• Extreme Eile - Die Geschwindigkeit und Dynamik war zwar auch ein ganz wichtiger Vorteil, aber die Koordination wurde dadurch erschwert.
• Keiner wollte Chef sein, aber viele wollten einen, der sagt wo es lang geht.
• Das vorhandene Planungsinstrument (Wiki) wurde nicht von allen angenommen.

Eine Ideale Infrastruktur für die Durchführung solcher Aktionen besteht wahrscheinlich aus folgenden Elementen:

• Ein Webforum/Mailingliste für die Diskussion diverser Fragen - Ich war bis vor kurzem ein ausgesprochener Gegner von Webforen. Seit ich die Möglichkeit entdeckt habe, Foren per RSS zu verfolgen, mag ich diese fast mehr als Mailinglisten.
• Ein Wiki zur Ausarbeitung von Texten - Ab dem Moment in dem es in der Forendiskussion um Formulierungen geht, sollte ein erster Entwurf ins Wiki und dann dort weiterbearbeitet werden.
• Eine „normale Website“ (evt. auf Blog-Basis, muss aber nicht sein) - Hier wird nicht diskutiert, sondern es werden die Ergebnisse der Diskussion verkündet.
• Bekanntmachung in der Blogosphäre, jedoch mit ganz klarer Aussage, die Aktion nicht bei den jeweiligen Blogbeiträgen zu diskutieren, sondern auf den Projektseiten.

StW: Es ist natürlich gut möglich, dass die Free-Burma-Aktion mit all diesem organisierten Zeugs überhaupt nicht abgehoben hätte. Zuviel Verwaltung. Eigentlich hätte die Free-Burma-Aktion gar nicht mehr viel besser ablaufen können - außer der Sache mit der internationalen Vernetzung, die Robert ja schon beweint hat. Aber ich denke dass mehr Organisation das Resultat nicht merklich verbessert hätte. Aber wenn man etwas mittel- bis langfristiges plant, dann sollte man sich die Zeit nehmen, und über die „Infrastruktur“ nachdenken.

StW: Sehr gute. Ich habe die technik in meinem Blog schon beschrieben: http://stefan.waidele.info/2007/05/12/the-making-of-krone-neuenburgcom/ Durch das Zusammenspiel der verschiedenen komponenten habe ich einerseits mein gewünschtes Layout (HTML), die notwendige Navigation (PHP) und die einfache Eingabe von statischen Texten (Wiki) bzw. zeitabhängigen Informationen (Blog).

StW: Als weiteres Beispiel kann ich LinuxBasics.org nennen: Dieses Gemeinschaftsprojekt startete mit Wiki-Webseiten für Anleitungen und zwei Mailinglisten (eine für technische Fragen, die andere für einen Linux-Anfängerkurs). Zusätzlich gab es noch einen IRC-Channel (d.h. Text-Chat) für Echtzeit-Support. Um das Angebot abzurunden kam dann vor kurzem ein Blog dazu, wo wir Anleitungen veröffentlichen, die für normale Anwender gedacht sind („Wie mache ich das?“ anstatt „Wie funktioniert das und warum ist das so?“). Ganz aktuell haben wir unsere Kurs-Mailingliste geschlossen, und führen den Kurs in einem Webforum durch. Wir nutzen also einen ganzen Strauß von Werkzeugen, je nachdem wie die Anforderungen in dem jeweiligen Bereich sind. Dabei ist es egal, ob diese Werkzeugt mit dem Etikett „Web2.0“, „Web1.0“, oder „Gar nicht Web“ daherkommen.

StW: Zusammengehalten werden diese durch eine Suchfunktion, die alle Bereiche der Website durchsucht. Wer also etwas sucht, bekommt Treffer aus dem Wiki, der Mailingliste, dem Forum und dem Blog präsentiert.

StW: Der einzige Nachteil bei einer solchen Mischung ist, dass die Teilnehmer sich bei den verschiedenen Komponenten seperat anmelden müssen: Das Passwort für die Mailing-Listen-Einstellungen ist nicht das selbe wie zum Editieren des Wikis oder zum Nachfragen im Forum. Das ist machmal verwirrend.

StW: Aber ansonsten sind wir mit den jeweiligen Komponenten sehr zufrieden.

StW: Du hast mir eine E-Mail geschickt, und jetzt hast Du eines! ;)

Gern geschehen. Vielen Dank auch an Dich. Es war auch für mich sehr interessant, das alles „zu Papier“ zu bringen.