Wikipedia und PR: Manchmal muss man das Selbstverständliche betonen

Mit der Wikipedia ist das ja so eine Sache: Mittlerweile haben die meisten Unternehmen mitbekommen, dass dies eine der wichtigsten Plattformen im Web ist – und machen sich so ihre Gedanken, ob es für sie nicht auch einen Artikel geben sollte oder – gibt es schon einen – ob dieser nicht schmeichelhafter ausfallen sollte. Und weil jeder mit einem Knopfdruck mitschreiben kann, ist im Zweifel schnell schöngeschrieben. Das ist für manche Unternehmen und PR-Agenturen so ähnlich wie das Rauchen auf dem Schulklo: Man weiß, dass es nicht ok ist, aber man macht’s halt und riskiert – ja, was eigentlich? In diesem Fall (mindestens) einen Teil der eigenen Reputation und Agenturen noch die des Kunden dazu.

Deshalb hier mal eine klare Ansage der Agentur Shift Communications festgehalten, die in dieser Hinsicht nichts riskiert und von Wikipedia lieber die Finger lässt, obwohl sie regelmäßig entsprechende Wünsche ihrer Kunden vorgetragen bekommt:

“This is why at SHIFT we have a standard policy that we will not create, edit or touch our client’s Wikipedia pages.  Why?  Besides being unethical, it’s against the rules of the Wikipedia playing ground, which ask that content be factual, non-promotional and created and edited by sources other than those working for a company or representing a company.  And duh, we represent!”

Eigentlich ein altes Thema, und die Agentur proklamiert nur das Selbstverständliche. Aber da gerade eben erst die englische PR- und Lobbying-Agentur Bell Pottinger ein größeres Wikipedia-Problem hat, sei heute auch mal das Normale erwähnt. Ach so, was bei den Briten schief lief? Sie fielen auf investigativ arbeitende Journalisten rein und priesen ihre dunklen Wikipedia-Künste. Dieses gegen die Regeln verstoßende Geschäftsgebaren zog muntere Kreise vom Independent bis zu Zeit online und viele andere und ward natürlich ganz schnell im Wikipedia-Artikel zur Agentur vermerkt:

“The company offers services such as lobbying, speech writing, search engine optimisation and “sorting” Wikipedia articles to clients including foreign governments. In December 2011 it came under public scrutiny after managers were secretly recorded talking to fake representatives of the Uzbek government and abusing Wikipedia by removing negative information and replacing it with positive spin.”

Fragt sich nur, wie viele Agenturchefs sich dieser Tage den Schweiß von der Stirn wischen, weil sich ihre Mitarbeiter bisher noch nicht haben ertappen lassen.

Ähnliche Artikel:

ZEIT im Guttenplag-Wiki

Kleine Randnotiz: Von der Inszenierung des Karl-Theodor zu Guttenberg in der aktuellen ZEIT mag man halten, was man möchte. Ganz nett fand ich aber die Entdeckung, dass die Marketing-Leute des Verlags ganz fit sind: Sie haben ein schönes Werbebanner im Guttenplag-Wiki geschaltet. Wenn das keine zielgruppengenaue Werbung ist…

Zielgruppengenaue Werbung

Infopaket: Wikis und Public Relations

Höchste Zeit, auf ein Infopaket hinzuweisen, das ich nebenan bei Agglom zusammengestellt habe: Hier geht’s um die Frage, wie Wikis in der PR (Webslideshow) eingesetzt werden können. Gesammelt habe ich Links zu Fallbeispielen und Erfahrungsberichten sowie zu Artikeln, in denen grundsätzlicher über die Einsatzmöglichkeiten von Wikis diskutiert wird. Besonders wichtig aus PR-Sicht ist natürlich der Umgang mit der Wikipedia. Hierzu gibt es eine eigene Sammlung (Wikipedia & PR, Webslideshow). Beide Sammlungen dienen für Interessierte als einfache Selbstlernpakete.

Zuvor jedoch noch ein paar ergänzende Überlegungen: Grundsätzlich ist der Einsatz von Wikis in vielen Organisationen erst einmal eine Frage des Wissensmanagements. Hierzu gibt es eine fast uferlose Literatur und entsprechend viele Studien. Sehr schnell ist man dann bei der Diskussion um Enterprise 2.0. Und natürlich kann diskutiert werden, im Einzelfall das Intranet schlicht durch ein Wiki zu ersetzen. Damit das Ganze nicht ausufert, habe ich nur einzelne Quellen aufgenommen, die den Blick in diese Richtungen lenken. Entscheidend ist aus meiner Sicht, dass sich in der Praxis zu diesem Thema Vertreter unterschiedlicher Herkunft zusammentun. Denn gerade beim Wiki-Einsatz werden die engen Wechselwirkungen zwischen Arbeitsprozessen bzw. Wissensmanagement und Unternehmenskultur besonders deutlich – und gerade beim letzten Punkt kommen die Kommunikationsexperten ins Spiel. Ebenso übrigens auch, wenn es um die Kommunikation zu einem Wiki geht.

Eine interne Wiki-Anwendung, die besonders nahe liegt, ist natürlich die innnerhalb von Kommunikationsabteilungen. Gerade wenn man es mit laufend anderen Themen zu tun hat (z.B. durch Anfragen von Journalisten), kann ein Wiki viel intere Recherche und Abstimmerei ersparen. Auch Texte (Presseinfos, Artikel, Imagetexte etc.) lassen sich im Wiki wunderbar schreiben bzw. abstimmen. Ob das so gemacht wird, weiß ich nicht. Mir ist zwar bekannt, dass einige PR-Agenturen Wikis einsetzen, auf Erfahrungsberichte von Kommunikationsabteilungen bin ich jedoch bisher nicht gestoßen.

Etwas weniger wahrgenommen werden in der Diskussion die Möglichkeiten, Wikis auch in der externen Kommunikation einzusetzen. Doch Wikis zu Städten oder touristischen Zielen, zu komplexen Produkten etc. zeigen, dass sie auf einfache Weise Community-Building und einen Nutzen für die Stakeholder zusammenbringen und Kommunikationsziele untersützen können.

Und dass das wichtigste Wiki im Netz, die Wikipedia, im Auge behalten werden sollte, dürfte sowieso klar sein. Ob allen jedoch bekannt ist, dass man Artikel dort sehr einfach beobachten kann, wenn man einen Account hat und angemeldet ist, bezweifle ich. Sehr viel schwieriger ist allerdings die Frage, ob PR-Leute selbst Hand anlegen sollen oder dürfen, um Artikel in der Wikipedia (um-) oder neu zu schreiben. Dass das gewaltig nach hinten losgehen kann, hat sich mehrfach gezeigt. Doch die Beispiele und die Diskussion dazu ist im Wikipedia & PR-Paket.

Damit das Selbstlernen etwas leichter fällt, hier noch ein paar Kontrollfragen:

  • Was sind Voraussetzungen für den erfolgreichen Einsatz von Wikis? (intern und extern)
  • Weshalb könnten Wikis für die Kommunikation von Nonprofit-Organisationen besonders geeignet sein?
  • Wie sind die Risiken eines eigenen Editierens in der Wikipedia einzuschätzen?
  • Was empfiehlt Wikipedia-Gründer Jimmy Wales Agenturen und Unternehmen?

So, nun wünsche ich viel Spaß und hoffe, das Ganze ist ein bisschen nützlich.

P.S.: Beide Pakete dürfen natürlich gern ergänzt werden.

Ähliche Artikel im Textdepot:

Sites: Das Wiki von Google – erste Erfahrungen

So, wie versprochen fasse ich mal ein paar Eindrücke von Google Sites zusammen. Damit hat Google vor kurzem sein umfangreiches Angebot an Online-Services um eine Wiki-Funktionalität ergänzt. Genau genommen ist Google Sites Bestandteil von Google Apps, einem Paket, das einige der bekannten Google-Anwendungen (z.B. Docs, Mail, Kalender, Talk) zusammenfasst. Wie neulich erwähnt, habe ich mich (ich gebe zu: mit ein bisschen Bauchschmerzen) entschieden, die Sites im nächste Woche beginnenden Sommersemester für unseren PR-Schwerpunkt einzusetzen – anstatt der an unserer Hochschule sonst verwendeten eLearning-Plattform Blackboard.

Doch zunächst will ich kurz meine Anforderungen, die ich in diesem Fall an ein Wiki habe, erklären: Was ich wollte, ist ein schnell einsetzbares, gehostetes Wiki, das ohne ungewohnte Syntax gefüllt und einfach strukturiert werden kann. Im letzten Semester hat unser bisher verwendetes pmWiki einige Studenten und mich doch gelegentlich genervt (Probleme mit dem Editor, keine Diskussionsmöglichkeit in der Standardinstallation etc.). Weitere wichtige Anforderungen: Da wir mit dem PR-Wiki bereits über ein öffentliches Wiki verfügen, soll das aufzubauende Wiki nur für die jeweiligen Studenten und Dozenten zugänglich sein. Diese Abgeschlossenheit hat zwei Gründe:

  • Erstens soll darin das Management von Semesterprojekten abgewickelt werden, d.h. darin werden auch halbwegs vertrauliche (bei weitem aber keine streng geheimen) Informationen gespeichert (z.B. ToDo-Listen).
  • Zweitens habe ich festgestellt, dass ein nicht-öffentlicher Raum Studierende zu wesentlich intensiverer Zusammenarbeit im Wiki motiviert als ein öffentliches Wiki.

Doch nun endlich zu Google Sites. Bevor man sich dafür entschließt, ein wichtiger Hinweis: Man sollte sich wirklich klar werden, ob man die Nutzungsbedingungen von Google annehmen kann/möchte. Hierzu empfehle ich die Lektüre von Mediendidaktik zum Thema und die Diskussion bei Michael Kerres (Kommentare beachten). Ich bin jedenfalls zu dem Entschluss gekommen, es wagen zu können.

Gut, also zur Registrierung. Ich gebe ja zu, dass ich da erst ein wenig herumgepfuscht habe, da mir der Zusammenhang mit den Google Apps nicht gleich klar war. Und das ist für mich ein zentraler Kritikpunkt: Google will mit den Sites wohl nicht irgendwelche Privatleute ansprechen, die die Idee haben, mal ein Wiki einzurichten, sondern eine bereits bestehende Gruppe – z.B. ein Unternehmen, einen Verein, eine Schule oder Universität gewinnen. Und die sollen möglichst gleich den ganzen Google-Segen erhalten. Zur Anmeldung benötigt man eine Mailadresse einer Institution bzw. eine eigene Domain. Wer sich damit anmeldet, richtet das Ding für seine Institution ein – ich habe keine Ahnung, ob man damit für seinen gesamten Laden weitere Anmeldungen blockiert, vermute das aber. Wenn dem so ist, sind Probleme vorprogrammiert, die Google natürlich elegant auf die Institutionen abwälzt. Ok, das Ganze hat auch Vorteile, auf die ich hier aber jetzt nicht weiter eingehen möchte – wie auch auf die Google Apps insgesamt.

Wie arbeitet es sich denn nun mit den Sites? Kurz und bündig: “Gut”. Wie immer bei Google bin ich mit der Bedienung auf Anhieb klar gekommen, und einige Funktionen sind mir positiv aufgefallen:

  • Es gibt ein paar Templates. Ich habe da nicht lange ausprobiert, sondern gleich eines gefunden, das mir geeignet schien. Es sieht u.a. eine Navigationsleiste vor, die ich editieren kann. Bei manchen Wikis muss man sowas erst über Umwege basteln.
  • Eine Sitemap wird automatisch erzeugt.
  • Jede Seite kann wie in einem Blog kommentiert werden. Sicher, das ist Geschmacksache – mir gefällt’s besser als eine eigene Kommentarseite
  • Auf jeder Seite gibt es eine Uploadmöglichkeit für Dokumente. Das geht nicht bei allen gehosteten Wikis. 10 GB Speicherplatz sollten ein Weilchen genügen.
  • Für jede neue Seite kann ich entscheiden, wo diese genau platziert werden soll (z.B. als Unterseite).
  • Unterseiten werden am Fuß einer Seite automatisch verlinkt.
  • Normale Wiki-Seiten sind mit dem WYSIWG-Editor problemlos zu bearbeiten.
  • Ganz prima: Es gibt unterschiedliche Seitentypen: reine Wiki-Seiten (deren Layout lässt sich mit dem Editor auch auf zweispaltig umstellen), Announcements, Listen (gut geeignet für kleine Projekte, da gestaltbar und mit Prioritäten versehbar), Mashup-Seiten (= Dashboards in der Google-Sprache), und Download-Seiten (= File Cabinets). Letztere sind sehr gut geeignet, wenn man mehrere Dokumente zentral hochladen möchte. Man kann dann von beliebigen Seiten auf die einzelnen Dokumente linken, den Nutzern aber auch die gesamte Download-Seiten anbieten, auf denen alle Dokumente auf einen Blick zu sehen sind.
  • Man kann unterschiedliche Dokumente aus dem Google-Universum (Präsentationen, Spreadsheets etc.) und so genannte Gadgets (Kalender, Feeds etc.) integrieren. Diese können direkt im Wiki angesehen werden, ähnlich wie auch Videos von YouTube und Google.
  • Rollenbasierte Nutzung: Die Einladung von Mitarbeitern bzw. weiteren Administratoren hat bisher reibungslos geklappt. Einstellen lässt sich für jede Seite, ob sie öffentlich, für alle im Wiki Registrierten oder nur ausgewählte Nutzer zugänglich sein soll. Dabei kann nochmal unterschieden werden, ob die Nutzer die Seite nur sehen oder auch bearbeiten können.
  • [Ergänzung, 12.3.08]: Als admin bekomme ich auf Wunsch per Mail Änderungen im Wiki sofort zugeschickt. Die Änderungen werden farblich hervorgehoben, Uhrzeit und Autor sind auch festgehalten.

Weniger gut gefällt mir:

  • Es gibt keine Möglichkeit, Seiten zu sichern bzw. downzuloaden (abgesehen von pdf über das Drucken).
  • Die Mashups haken manchmal, einige gehen gar nicht. Zum Beispiel hatte ich große Probleme RSS-Feeds einzubinden und das erst mal auf irgendwann verschoben. Mein Wunsch wäre, Social Bookmarks bzw. den Feed des bereits vorhandenen Mister-Wong-Gruppenarchivs ins Wiki zu ziehen.
  • Die oben erwähnte Einrichtung über Google Apps

Ambivalent:

  • Links werden von den Google Sites automatisch mit dem Attribut “nofollow” versehen. Hiergegen gibt es gute Argumente. Andererseits: Wenn die Sites als Intranet bzw. als nach außen abgeschlossener Bereich eingesetzt werden sollen, kann ich “nofollow” schon halbwegs nachvollziehen.

Mein Zwischenfazit nach etwa 20 eingerichteten Seiten: Das Arbeiten mit den Sites ist weitgehend problemlos. Die wenigen Dinge, die haken, habe ich bei anderen gehosteten Wikis in diesem Umfang bisher noch nicht gefunden. Statt dessen ist mein Eindruck, dass die Sites selbst ohne diese Funktionen etwas mehr bieten als manche andere Anbieter wie zoho. Besonders gut gefällt mir, dass die Sites zwar als typisches Wiki daher kommen, aber Funktionen haben, die einerseits das Projektmanagement und andererseits die Multimedialität unterstützen können.

Nach den bisherigen Erfahrungen scheinen die Sites also meinen Anforderungen für den Einsatz in der Lehre zu genügen. Nun müssen sie sich im realen Betrieb bewähren. Gut vorstellen kann ich mir auch, dass Vereine damit glücklich werden können. Ob ich die Sites bzw. das Gesamtpaket Google Apps jedoch im Unternehmen einsetzen würde, weiß ich nicht – da gibt es noch ganz andere Pakete, mit denen das verglichen werden müsste. Aber als einfaches, schnell aufsetzbares, kleines Intranet? Schon vorstellbar, meint auch der RSS-Blogger.

Um Missverständnisse zu vermeiden: Dieser Artikel spiegelt keinen systematischen Test oder Vergleich mit anderen Systemen wider, sondern ich schildere subjektive Eindrücke, die ich in den ersten Tagen der Nutzung der Google Sites gewonnen habe.

Weitergehende Lesetipps:

Sprachproblem: Wikis in internationalen Unternehmen

Wer kann helfen? Eine Studentin fragt:

“Ich schreibe meine Abschlussarbeit bei der xy AG. Sie werden bald ein Wiki in ihr Intranet implementieren, welches dann europaweit von allen Mitarbeitern genutzt werden soll. Das große Problem ist die Sprache – Englisch war vorgesehen, aber das würde wahrscheinlich den Beteiligungsgrad der deutschen Mitarbeiter enorm senken, da viele kein oder nur kaum Englisch verstehen und somit kein Teil der englischsprachigen Wiki-Community werden könnten.

Meine Frage an Sie wäre, ob Sie mit solch einer Situation schon einmal Erfahrung gesammelt haben und evtl. Tools oder einen möglichen Lösungsansatz kennen, wie man mit solch einem Problem umgehen könnte?”

Hm, das Problem ist mir so noch nicht bewusst geworden; für mich sind Unternehmen selbstverständlich, die von ihren Mitarbeitern englisch als Geschäftssprache erwarten. Aus meiner Sicht ist eine gemeinsame Sprache Voraussetzung für das Funktionieren des Wiki-Gedankens in Unternehmen. Denn ein Wiki soll ja Leute zusammenbringen, die sich an unterschiedlichsten Stellen im Unternehmen mit ähnlichen Dingen beschäftigen. Sicher gibt es in den Landesgesellschaften eines Konzerns viele Anwendungsmöglichkeiten für einzelne Wikis. Doch dass Wikis ohne gemeinsame Sprache der Beteiligten für eine internationale Vernetzung sorgen können, bezweifle ich – mir fällt zumindest kein Tool bzw. kein Prozess ein, um das wirkungsvoll zu erreichen.

Wie sehen Sie das? Wissen Sie, wie internationale Unternehmen bei der Einführung von Wikis mit dem Sprachproblem umgehen?

Gehostete Wikis: Erste Erfahrungen

Nachdem wir am Studiengang seit längerem mit eigenen Wiki-Installationen arbeiten (v.a. pmWiki, MediaWiki), habe ich vor einer Weile nach gehosteten Alternativen geschaut und mit dreien etwas herumgespielt. Inzwischen habe ich mit Zoho einen klaren Favoriten.

Grundsätzlich ist natürlich die erste Frage, ob man ein Wiki auf dem eigenen Server einrichten möchte, oder ob man ein gehostetes Wiki bevorzugt. Für mich liegen die Unterschiede vor allem in der Frage, wo meine Daten sind. Bei einem Wiki, das auf gemeinsam erarbeiteten Informationen basiert, vielleicht kein dramatisches Problem. Allerdings: Stellt ein Hoster seinen Dienst ein, fragt sich, was mit den erarbeiteten Inhalten passiert. Andererseits erspart ein gehostetes Wiki jeden Installationsaufwand und ist in zwei Minuten startbereit. Ich habe mich dafür entschieden, gehostete Wikis dann einzusetzen, wenn ich sie für zeitlich überschaubare Projekte oder eigene, aber nicht kritische Notizen einsetze.

Ausprobiert habe ich in den letzten Wochen drei gehostete Wikis, nämlich Wikispaces, Bluwiki und Zoho. Ich habe dabei ausschließlich kostenlose Angebote angeschaut. Ist man bereit, ein wenig für das Wiki-Hosting zu bezahlen, sind Backup-Möglichkeiten meines Wissens üblich, dazu hat man dann natürlich noch mehr Funktionen als bei den kostenfreien Varianten.

Am kürzesten habe ich mit Wikispaces gespielt. Das heißt aber nicht, dass es sich um ein schlechtes Angebot handelt. Zunächst zum Thema Abhängigkeit vom Hoster: Wikispaces bietet die Möglichkeit, Inhalte auf einen Knopfdruck zu exportieren (und damit z.B. lokal zu sichern). Außerdem gibt es verschiedene Vorlagen, um das Ganze zu gestalten. Die kostenlose Version hat zwei mögliche Nachteile: Zum einen gibt’s inzwischen nur  noch öffentliche Seiten, zum anderen ist Werbung drauf. (Ausnahme: für Lehrprojekte gibt es kostenlose werbefreie Wikis). Das Wiki selbst funktioniert problemlos, und zur Orientierung gibt es eine Navigation und Tags. Alternativ gibt es auch kostenpflichtige Varianten bei Wikispaces.  Bei ihnen gibt es z.B. die Möglichkeit (ähnlich wie bei Google Docs), die Privatsphäre einzelner Projekte zu steuern. Diese können also ganz privat sein, für eine definierte Arbeitsgruppe oder öffentlich. Auch, wer ein größeres Wiki betreibt, muss bezahlen.

Bluwiki ist dagegen kostenlos und werbefrei. Auch hier gibt es ein paar Skins. Doch entscheidend ist das nicht, sondern es handelt sich um ein sehr schlankes System, das alle Grundfunktionen eines Wikis enthält. Allerdings ist mir das Ganze inzwischen fast etwas zu schlank, denn sobald man mehrere Wikiseiten hat, ist es nicht ganz einfach, Orientierung herzustellen. Eine Navigation oder gar Tagging sind nicht vorgesehen. Ich bin deshalb dazu übergegangen, am Fuß jeder Seite einen Link zur Homepage oder ggf. zu einer anderen Seite manuell einzufügen. Bluwikis sind generell öffentlich, eine Exportfunktion der Inhalte habe ich nicht gefunden. Mein Beispielwiki, in dem ich z.B. mit kleinen Teams Material sammle oder Ergänzungen zu Vorträgen liefere, ist hier.
Der dritte Anbieter, Zoho, bietet nicht nur die Möglichkeit, Wikis einzurichten, sondern ist eine komplette, webbasierte Alternative zu Office – und noch mehr: Da gibt es neben dem Wiki den Writer (Textverarbeitung), eine Applikation für Tabellenkalkulation, eine für Präsentationen, ein virtuelles Notizbuch, ToDo-Listen, Chat- und Meetingmöglichkeiten sowie sogar eine Datenbank. 14 Anwendungen sind es inzwischen. Bisher habe ich nur mit dem Wiki gearbeitet. Und das funktioniert reibungslos. Da gibt es praktisch alle Funktionen, die auch Wikispaces bietet (die Steuerung der Privatheit ist bislang kostenlos; zudem gibt es Navigation, Tagging etc. Ausnahme: Export). Darüber hinaus gibt es eine Sitemap, für jede Wiki-Seite einen RSS-Feed sowie einen Feed, der eine Übersicht aller Änderungen liefert. Zusätzlich gibt es statt separater Diskussionsseiten eine Kommentarfunktion für jede Seite – Geschmacksache, mir gefällt’s. Schließlich bietet der WYSIWYG-Editor von Zoho sehr viele Formatierungsmöglichkeiten (fast schon zu viele), die aber zumindest bei den unterschiedlichen Varianten, um Links zu setzen, sehr hilfreich ist. Ebenfalls sehr schön: Ich kann unter einem Account mehrere Wikis einrichten und dort jeweils andere Zugangsregeln festlegen (also z.B. eines für private Notizen, eines für meine Arbeitsgruppe etc.) Im Moment Zoho noch kostenlos, doch dies dürfte sich im nächsten Jahr ändern. Wenn ich es richtig sehe, wird es aber auch weiterhin eine kostenlose Basisfunktion geben; bestimmte Funktionen (z.B. Backup, weitere Administration) sind jedoch in einem kostenpflichtigen Businesspaket enthalten. Wobei mir auch hierfür die Preise recht moderat erscheinen.

Mein Fazit: Wie gesagt bietet das Zoho-Wiki nach meinem Eindruck am meisten. Dies gilt allein schon für die Wiki-Funktionalität. Überlegt man, darüber hinaus noch mehr webbasierte Anwendungen zu nutzen, hat man sicher eine sehr gute Alternative zur Google-Welt. Ein wenig Geduld braucht allerdings, wer Mitarbeiter in sein Wiki einladen möchte. Im Härtetest mit etwa 20 gleichzeitigen Einladungen hat sich gezeigt, dass in drei Fällen die Anmeldung nicht ganz reibungslos geklappt hat und die Einladung oder die Registrierung nochmal gemacht werden musste. Waren die Mitarbeiter einmal drin, lief aber alles rund. Und was für den Arbeitsalltag wichtig ist: Zoho bietet ohne Installationsaufwand ein für meinen Geschmack wesentlich komfortableres System als zum Beispiel unsere pmWiki-Installationen (Beispiel), die erst mühsam an den Stand der Zeit angepasst werden müssen, aber dabei immer wieder an Grenzen stoßen bzw. einen versierten Admin erfordern.

Zum Schluss noch ein Hinweis: Ich habe die vorgestellten Angebote nicht systematisch getestet, sondern nur berichtet, wie sie sich mir aus Nutzersicht darstellen. Insofern gibt es sicher einige Aspekte, die anderen wichtig sind, ich aber hier nicht diskutiere. Ergänzungen, eigene Erfahrungen etc. sind deshalb natürlich sehr willkommen. Außerdem sollte natürlich jeder, der ein solches Wiki einrichtet, die Nutzungsbedingungen lesen, die habe ich jetzt hier gar nicht berücksichtigt.

Mehr zum Thema: