<> = Allgemeine Möglichkeiten für eine Konvention eines Wikis bei der StuVe = = 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. In der folgenden Liste sollen alle verfügbaren Konventionen gesammelt werden. Sind sie nicht global, also ohne Anmeldung in dem entsprechenden Wiki lesbar, erstellt bitte eine Unterseite nach dem Schema: {{{/Konvention_Wikiname}}}. * Computer-Wiki: [[HilfeWiki/Konvention]] * AStA-Wiki: noch nicht veröffentlicht. = 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 vermeintliche Rechtschreibfehler auf den Unterseiten eines Projekts korrigieren mit dem er nix zu tun hat? Darf man auf der ToDo Liste von jemanden 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. * Bei Verweisen ist es möglich an Stelle des Ziels einen anderen Text anzeigen zu lassen ({{{[[ziel|link-text]]}}}) . Je nach Nutzung geht damit dann aber auch Information verloren. Wenn man bspw. auf eine Unterseite in einem bestimmten Bereich verlinkt, und dann als Link Text eine Beschreibung des Themas angibt, dann wird die Struktur vor den Nutzer versteckt. Es sollte für ein Wiki fest gelegt werden, ob die Link Ziele allgemein versteckt werden dürfen oder nicht. * Beispiel: * Struktur sichtbar: {{{[[Druck/Kostenstelle]]}}} * Struktur hinter Beschreibung versteckt: {{{[[Druck/Kostenstelle|Druck beim KIZ über Kostenstelle]]}}} * Natürlich kann man in der Beschreibung besser darstellen was sich hinter einem Link verbindet. Allerdings ist die Frage ob man das für alle Links konsistent durchsetzen kann. Eine Mischung aus beidem ist natürlich einfach möglich: * Struktur und Beschreibung sichtbar: {{{ * [[Druck/Kostenstelle]]: Druck beim KIZ über Kostenstelle}}} == 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 Umbenennen 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. = Achtung! = * 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 auch 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 Hierarchie" {{{ Veranstaltungen/FeBo/2008 }}} === Pro === === Kontra === * Verlinken wird ab der 3. Eben immer komplizierter. * Widerspricht 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 Hierarchie angeordnet aber z.B. würde darauf von der Seite Veranstaltungen aus verlinkt. == Möglichkeit 2 == "Hierarchie nur wenn vom Benennen her nötig/sinnig" {{{ AStA/Tagesordnung }}} === Pro === * Man muss (vor allem bei länger werdenden Seitentiteln) nicht immer den ganzen Linktext schreiben, von der Elternseite her ist ein kurzer Link möglich. * Die Zugehörigkeit wird aus der Hierarchie 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.