Zweck

Die Konventionen sollen eine grobe Anleitung sein, welche Konstrukte für welche Anwendung "normal" verwendet werden. Je nach Nutzungsart und Konfiguration eines Wikis können diese Konventionen unterschiedlich ausfallen. Dementsprechend sollen hier nur Anwendungen und alle möglichen Konventionen vorgestellt werden. Eine feste Lösung muss von den Nutzern jedes einzelnen Wikis selbst fest gelegt werden.

Beispiele für Umsetzung

Ihr könnt euch die Umsetzung bei den bereits existierenden Wikis anschauen. Zum Beispiel findet sich auf der Seite HilfeWiki/Konvention die für dieses Wiki gültige Konvention.

Mitarbeit

Normal ist in einem Wiki die Mitarbeit aller erwünscht. Es wird am Anfang schwierig sein die Nutzer dafür zu öffnen, das sie selbst überall mitarbeiten sollen bzw. das ihre Inhalte auch von jemanden anderen angefasst werden können. Die AktuellenÄnderungen und die Info Seite zu jeder Seite helfen alles zu verfolgen.

Soll auch jeder vermeinliche Rechtschreibfehler auf den Unterseiten eines Projekts korrigieren mit dem er nix zu tun hat? Darf man auf der ToDo Liste von jemaden einfach Sachen hinzufügen wenn man findet das er das mal machen sollte?

Inhalt

Abkürzungen

Verweise

• Links auf andere Wikiseiten sind immer in zweifache eckige Klammern [[ ]] zu setzen.

Sprache

Bei Wikis die allgemein verständlich sind sollte Fachbegriffe erklärt oder sogar vermieden werden. Bei einem Wiki das genau für ein Fachthema ausgerichtet ist, muss man auch die Begriffe verwenden können.

Struktur

Benennung von Seiten

• Umlaute in Seitentiteln sind erlaubt und erwünscht.

• Leerzeichen sind nicht erlaubt. Ersetzt sie bitte mit einem Unterstrich _.

• Doppelpunkte in Seitentiteln haben erzeugen InterWiki Links und sind daher nicht erlaubt.

Umbenennen von Seiten

Beim Umbenennem von Seiten muss man berücksichtigen das alte Verweise dann nicht mehr auf die Seite mit dem neuen Titel zeigen. MoinMoin versucht zwar umgezogene Seiten wieder zu finden und bietet Seiten mit ähnlichem namen an, das ist aber keine perfekte Lösung. Um zumindest alle Verweise innerhalb eines Wikis zu finden ist folgendes Vorgehen hilfreich:

• SeiteBeispiel soll umbenannt werden in SeiteBeispielNeu

• umzubenennende SeiteBeispiel besuchen

• Seiten die darauf verweisen suchen
  • auf den Titel im oberen Bereich klicken
  • -oder -

  • Suchen nach linkto:"SeiteBeispiel"

• alle Seiten die aufgelistet werden editieren und den Verweis auf den neuen Namen SeiteBeispielNeu abändern

Hierarchie

Eine geschachtelte Struktur von Seiten darf nur verwendet werden, wenn es von der Bennenung her nötig bzw. sinnvoll ist. Dazu ein Beispiel:

Im AStA-Wiki gibt es eine eigene Seite für das BAföG-Referat und das Wohnreferat, beide Referate sind allerdings Teil des Sozialreferats. Dementsprechend gibt es zu den Themen der Referate nicht die Seite

Sozial

mit den Unterseiten

Sozial/BAföG
Sozial/Wohnen

sondern

BAföG
Wohnen

sind eigene Seiten in der obersten Hierarchie Ebene, genau so wie Sozial wobei von dort aus natürlich auf die beiden zugehörigen Seiten verwiesen wird.

Die Unterseiten werden nur dazu genutzt allgemeine Seitennamen in der oberen Ebene zu vermeiden, die für mehrere Themen verwendet werden könnten. Wieder am Beispiel:

Das o.g. Wohnreferat möchte eine Seite für seine ToDo Liste und seine Rechenschaftsberichte haben. Es verwendet dafür nicht die Seiten mit den folgenden Namen in der obersten Hirarchie

Rechenschaftsberichte
ToDo

sondern fügt diese Seiten in die eigene Hierarchie ein, weil auch andere Bereiche "Rechenschaftsberichte" oder ToDos haben werden:

Wohnen/Rechenschaftsberichte
Wohnen/ToDo

Dies soll unter anderem auch wilde Konstruktionen und Lange Seitennamen unnötig machen, wie Rechenschaftsbericht_des_Wohnreferats_aus_2009; diese Seite sollte eher so verlinkt sein: Wohnreferat/Rechenschaftsbericht/2009

Standardisierte Unterseiten

/ToDo
/Diskussion
/Kalender

Diese Seitennamen sollten für die entsprechende Anwendung genutzt werden, um die Kollaboration zu vereinfachen, indem jeder der an dem Thema mitarbeiten will z.B. einfach die ToDo-Liste findet und nicht erst über den Link zur Unterseite /was es hier noch zu tun gibt stolpern muss. Natürlich muss man für die o.g. Anwendungen nicht immer eine Unterseite erstellen, sondern kann auch getrost nur einen eigenen Abschnitt auf der entsprechenden Seite erstellen.

Benutzerseite

Auf der eigenen Seite und den Unterseiten kann man tun und lassen, was man will. Auch kann man hier Rechte selbsständig vergeben; siehe hier Wiki/AdminDoku und hier HelpOnAutoAdmin.

Seitenquelltext

Der Quelltext einer Seite ist sauber und übersichtlich zu halten und die Leserlichkeit dieses "unformatierten" Textes hat Vorrang. Siehe auch Überschrift "GUI Editor" weiter unten.

Zusätzliches

Kalender

TODO die Verwendung von Kalendern.

Include

TODO Verwenden des Include-Makros zum Einbinden von anderen Seiten; Kenntlich machen, wo editiert werden muss.

GUI Editor

Editieren mit dem GUI-Editor erfolgt auf eigenen Gefahr. Es kann beim Verwenden des GUI-Editors dazu kommen, dass der Quelltext für das Editieren in diesem praktisch unlesbar wird. Der Quelltext ist aber der kleinste gemeinsame Nenner für die Editierung im Wiki und hat somit Vorrang vor dem Editieren in der GUI.

Stichpunkte, die hier noch bearbeitet werden müssen (tbd)

• Verbergen eines Wikilinks hinter einem besser lesbaren / schöneren Namen z.B.[[/Kostenstelle|Druck beim KIZ über Kostenstelle]]

Achtung!

• Umbenennen von Seiten erfordert leider immmer ein durchsuchen des ganzen Wikis auf evtl. andere Verlinkungen.
• Postulat: einfache Regeln (3 Stück oder so) mit ein paar Bsp., damit jeder nutzer die neue Konvention leicht verstehen kann.
• tbd

Seitennamen

Möglichkeit 1

"Leerzeichenersatz"

Hausbeck_Treffen

Pro

Kontra

Möglichkeit 2

"Prosa"

Einstiegsportal IT-Themen

Pro

• Klar lesbar, keine umständlichen individuellen Konstruktionen.

• Wenn jeder die eckigen Klammern  [[ ]]  benutzt, kein Problem.

Kontra

• In manchen Broweser Adressleisten sind die Leerzeichen nicht schön anzuschaun, aber wollen wir dann acuh auf Umlaute und Co. verzichten?

Möglichkeit 3

"Camelwords / Binnenmajuskeln"

BestellenHuss

Pro

• Funktioniert auch ohne eckige Klammern.

Kontra

• Konstuktion eines passenden CamelWords ist oft umständlich.

• Viele finden es beim editieren sowieso viel angenehmer alles Links in eckige Klammern zu setzen, um diese wiederzufinden, was den eigentlichen Vorteil von CamelWords wieder aufhebt.

Struktur

Möglichkeit 1

"Starke Hirachie"

Veranstaltungen/FeBo/2008

Pro

Kontra

• Verlinken wird ab der 3. Eben immer komplizierter.

• Wiederspricht der eigentlichen Idee eines Wikis, verlinkung entsteht durch Hinweise im Text / auf anderen Seiten, so wäre die FeBo oben eigentlich ganz oben in der Hirachie angeordnet aber z.B. würde darauf von der Seite Veranstaltungen aus verlinkt.

Möglichkeit 2

"Hirachie nur wenn vom Benennen her nötig/sinnig"

AStA/Tagesordnung

Pro

• Man muss (vor allem bie länger werdenenden Seitentiteln) nicht immer den ganzen Linktext schreiben, von der Elternseite her ist ein kurzer Link möglich.
• Die Zugehörigkeit wird aus der Hirachie klar, es muss nicht ein aufwendiger Titel in der obersten Ebene gesucht werden.

Kontra

Möglichkeit 3

"komplett Flache Struktur" (als alternative zu Möglichkeit 2)

AStATagesordnung

Pro

Kontra

• Man braucht ein eher umständliches Schema, um alle Seiten nachvollziehbar zu benennen.

Seitenquelltext

• Hier sollte nicht alles in einer Wurscht geschrieben werden, eine oder mehrere Leerzeilen vor und nach Überschriften Schaden nicht und erhöhen die Lesbarkeit, um Absätze im Fließtext zu generieren muss man einfach eine Leerzeile lassen.