Inhaltsverzeichnis

  1. Informationen für Wiki Betreuer, Stammtisch Admins
    1. Interessante Seiten
    2. Ansprechpartner
    3. Schema
    4. Information eurer Nutzer
    5. Nutzer und Rechte
      1. ACLs
        1. ACL Konfiguration
      2. ACL Erweiterungen
        1. autoadmin
        2. acl_hierarchic
          1. Konsequenzen
          2. Nutzungsbeispiele
      3. root Nutzer
      4. Gruppen
      5. einheitliche Benutzerbasis zwischen Wikis
    6. Inhalt
      1. MeineStartSeite
      2. Konvention
      3. Urheberrecht
      4. alte Inhalte
      5. Dateiformate
      6. jährliche Wikis
      7. Backup
      8. Haftung
      9. Kommerz
      10. Suchmaschinen
      11. Quota
      12. Stil / CMS / Website
      13. Logo
    7. Abos / Benachrichtigung
    8. Wiki Lebenszyklus
      1. Archiv

Informationen für Wiki Betreuer, Stammtisch Admins

Interessante Seiten

Diese Seiten gibt es jeweils automatisch in jedem Wiki. Sie enthalten hilfreiche und interessante Informationen zum Wiki:

OrphanedPages

AbandonedPages

WantedPages

PageHits

PageSize

oder die deutschsprachigen Äquvalente:

VerwaisteSeiten

AufgegebeneSeiten

GesuchteSeiten

SeitenZugriffe

SeitenGröße

Ansprechpartner

Für die unten genannten Aufgaben muss pro Wiki ein Ansprechpartner definiert werden. Von Seiten des AStA ist es nicht möglich diese Unterstuetzung zur Verfuegung zu stellen -- wir wissen nicht, wer Mitglied ist und sind auch nicht auf den Mailinglisten / Sitzungen anwesend. Meldet euch bitte falls sich der Ansprechpartner ändert, damit wir das in unserer Liste aktualiseren können und wir euch auch erreichen können.

Ihr seid dafür zuständig die Anfragen euer Nutzer zu beantworten. Falls ihr Fragen habt ist euer Ansprechpartner das Computerreferat (<stuve DOT UNDDASHIERSCHREIB ICH NUR WEGEN DER SPAMBOTS GRRRRR computer AT uni-ulm DOT de>).

Schema

Für die URLs der Wikis gibt es ein Schema. Das Arbeiten mit einem Schema soll die Administration vereinfachen.

Information eurer Nutzer

Nutzer und Rechte

ACLs

Der Zugriff von Nutzer wir über ACLs geregelt. Siehe HilfeZuAccessControlLists .

ACL Konfiguration

Wir geben folgende Konfiguration als Standard vor: 

    acl_rights_before = u"root,AdminGroup:read,write,delete,revert,admin"
    acl_rights_default = u"WikiGroup:read,write,delete,revert"

Das heißt es werden zwei Gruppen vorgegeben.

Und es wird ein Nutzer vorgegeben:

Natürlich können wir die Konfiguration nach euren Wünschen anpassen.

ACL Erweiterungen

autoadmin

Zwei Erweiterungen sind optional möglich. Standardmässig wird für alle Wikis autoadmin geladen: 

    from MoinMoin.security.autoadmin import SecurityPolicy

Das ermöglicht, dass Nutzer unterhalb ihres eigenen Bereichs ACLs setzen können. Bspw. private Bereiche.

<!> Dazu ist es aber nötig das der Nutzer in der AutoAdminGroup ist. Wir empfehlen normal einfach die WikiGroup in die AutoAdminGroup aufzunehmen. 

#acl AdminGroup:admin,read,write WikiGroup:read
 * WikiGroup

acl_hierarchic

Es gibt auch die Möglichkeit 

    acl_hierarchic = True

zu konfigurieren.

Damit bekommen ACLs eine hierachische Bedeutung, d.h. das man durch den Schutz einer Seite auch allen Seite/UnterSeiten erschlägt. Siehe HilfeZuAccessControlLists#Hierarchische_ACL-Verarbeitung

Konsequenzen

Da damit alle bereits konfigurierten ACLs in einem Wiki eine andere Bedeutung bekommen, sollte man sich vor dem Anlegen eines Wikis überlegen ob man diese Option benötigt. Wenn natürlich niemand ACLs verwendet hat, dann hat die Änderung keine akute Auswirkung. Insgesamt wird die Nutzung und die Bedeutung von ACLc mit dieser Option wesentlich komplexer. Wenn Nutzer sowieso schon Probleme mit der Seitenstruktur haben, wird es dadurch nicht besser.

Nutzungsbeispiele
  1. Eine Möglichkeit wäre es das man Projekte die jährlich stattfinden in einem Wiki jeweils in Unterbereiche nach Jahreszahlen sortiert (also /2011, /2012). Man kann die Berechtigungen dann getrennt verwalten -- dazu müssen dann aber auch verschiedenen Gruppen für die unterschiedlichen Jahre angelegt werden (ausser man verwendet es nur um den Schreibzugriff für altes einzuschränken).
  2. Man kann mit dieser Option auch sehr schön ein Wiki gleichzeitig zur Veröffentlichungen von Informationen und zum internen Bearbeiten benutzen. Bspw. könnte man die Einladungen zu Sitzungen als Unterseite von /Einladungen FS-intern entwerfen. Wenn sie dann z.B. über einen grösseren Verteiler geschickt werden sollen "veröffentlicht" man die Einladungen in dem man sie in den Bereich /Offen zieht. Die Veröffentlichung würde hier dann automatisch passiere, in dem für die Seiten jeweils ACLs konfiguriert sind. Die einzelnen Bearbeiter müssen weniger über ACLs nachdenken und die jeweils sichtbare Seitenstruktur ist in sich abgeschlossen.

root Nutzer

Standardmässig gibt es nur einen root Nutzer. Der Unterschied zwischen einem root Nutzer und einem einfachen Mitglied der normalen AdminGroup ist, das der root Nutzer auch alle angelegten Nutzer sehen kann und sich selbst unter deren Namen anmelden kann. Das kann helfen um bspw. die Konvention VornameNachname umzusetzen oder den Nutzern bei ACL Problemen besser zu helfen.

Gruppen

Die Zugehörigkeit zu Gruppen wird über Gruppen Seiten gelöst. Gruppen Seiten haben das Format <name>Group. Siehe auch HilfeZuAccessControlLists#Gruppen . Die Mitglieder einer Gruppen werden einfach auf einer Seite aufgelistet also: 

 * MitgliedEins
 * MitgliedZwei
 * AndereGruppe

Dementsprechend sollten die ACLs der Gruppen Seiten sinnvoll gewählt werden.

Wir empfehlen normal folgende Konstruktion:

In der Standard Konfiguration mit Gruppen gilt: Alle Personen die das Wiki nutzen sollen muessen Nutzer anlegen und deren Name muss der Seite WikiGroup hinzugefuegt werden. Eine Alternative ist zB die WikiGroup ohne ACL zu machen, dann kann jeder in der WikiGroup auch neue Mitglieder hinzufügen.

einheitliche Benutzerbasis zwischen Wikis

Es ist prinzipiell möglich das sich zwei oder mehr Wikis eine Nutzerbasis teilen. Am einfachsten lässt sich das beim Erstellen ein neues Wikis konfigurieren. Im nachinein muss man die beiden bisher getrennten Nutzer zusammen führen oder sich für eine entscheiden.

In der Umsetzung führt das dazu:

Ergebnis: Man muss sich nur einmal einloggen und ein Nutzer gilt für alle Wikis.

Probleme:

Inhalt

MeineStartSeite

    page_front_page = u"MeineStartSeite"

Das heißt das diese Seite angezeigt wird, wenn man das Wiki ohne Seiten Namen aufruft oder man auf das Logo klickt.

Folgendes kann als Hilfe Abschnitt hinzugefügt werden: 

= Wie geht es los? =
 * AktuelleÄnderungen: Sehen Sie, woran gerade gearbeitet wird
 * SeiteFinden: Durchsuchen Sie das Wiki
 * WikiSandkasten: Probieren Sie das Editieren im Wiki aus
 * WikiKurs: Eine Einführung zu Wikis
 * HilfeZurMoinWikiSyntax: Schnellübersicht der Darstellungs- und Textauszeichnungsmöglichkeiten

= Wie man diese Seiten benutzt =
Ein Wiki wird von einer gemeinschaftlichen Idee getragen, jeder kann seinen Beitrag leisten und daran teilhaben:

 * Bearbeiten Sie jede Seite, indem Sie auf "<<GetText(Edit)>>" in der oberen oder unteren Leiste klicken
 * Erstellen Sie einen Link zu einer anderen Seite durch das Aneinanderreihen von groß geschriebenen Worten (z. B. AktuelleÄnderungen)
 * Suchen Sie nach Seiten mit dem Suchfeld oben auf der Seite (Titel- oder Volltextsuche)
 * Auf [[HilfeFürAnfänger]] stehen weitere Hinweise; HilfeInhalt verlinkt auf alle Hilfeseiten.

Um mehr darüber zu erfahren, was ein WikiWikiWeb ist, können Sie DseWiki:WarumWikiFunktioniert lesen.

Dieses Wiki basiert auf [[http://moinmo.in/|MoinMoin]].

Alternativ stellt man den obigen Inhalt unter HilfeWiki zur Verfügung und bindet nur einen kleineren Abschnitt ein: 

= ... Wiki =

== Wiki ==
 * [[HilfeWiki]] Informationen für alle, für die dieses Wiki neu ist
 * [[WikiGroup]] Gruppe der zugangsberechtigten Wiki Accounts
 * [[AdminGroup]] Gruppe der Wiki Admins
 * http://wiki.asta.uni-ulm.de/computer/AdminNachrichten Infos zu Betrieb, Wartungsarbeiten

Konvention

Je nach Nutzung wollt ihr eine Konvention für die Nutzung fest legen. Eine Konvention kann helfen falls ihr viele Nutzer habt, die mit editieren und auch neue Strukturen entstehen. Ob ihr es Konvention oder Regeln nennt ist letztendlich egal. Die Idee ist einfach das man ein paar Dinge fest legt, die sonst noch öfter korrigiert werden oder bei denen es Unstimmigkeiten gibt.

Unter ../Konventionen werden einige Aspekte die man Regeln kann vorgestellt. Wo es von der konkreten Anwendung / Konfiguration abhängt, stellen wir die verschiedenen Optionen etwas zu regeln vor.

Urheberrecht

Ggf. stellt sich ja immer irgendwann mal die Frage inwiefern man Beitraege aus dem Wiki wiederverwenden darf (im naechsten Jahr zB) bzw. jemandem anderen zur Verfuegung stellen darf. Eine minimale Regelung dazu sollte also existieren. Wenn wir es sinnvoll finden hinterlegen wir am Ende der MeineStartSeite: 

~-Die Nutzung der Inhalte ist unter einer Creative Commons Lizenz möglich: http://creativecommons.org/licenses/by-nc-sa/3.0/de/ Die Ersteller und Bearbeiter von Beiträgen erklären durch ihre Nutzung automatisch, dass sie diese unter der obigen Lizenz zur Verfügung stellen.-~

Die Autoren geben damit nicht ihre Urheberrechte auf, sie stellen die Inhalte nur unter dieser Lizenz zur Verfuegung. Sollte jemand die Inhalte ueber die Lizenz hinausgehend nutzen wollen, muesste er mit allen Autoren verhandeln. Natuerlich greift die Urheberschaft erst ab einer gewissen Schaffenshoehe -- jenseits von Checklisten.

Ihr solltet euch natürlich bewusst für eine oder auch keine Lizenz entscheiden.

alte Inhalte

Falls ihr entweder vor der Nutzung des Wikis eine andere Ablage für den gleichen Themenkreis hattet oder für eine Veranstaltung jedes Jahr ein neues Wiki angelegt wird, solltet ihr euch überlegen wie die alten Inhalte intelligent übernommen werden können.

Dateiformate

Allgemein sollte man sich immer darauf einigen welche Formate man zum zusammen arbeiten verwendet. Typischerweise müssen alle Beteiligten die Dateien lesen und bearbeiten können. Damit es beim AStA funktioniert wurde beschlossen das hier nur noch offene Dateiformate verwendet werden dürfen. An Stelle von .doc/.xls Dateien sollen .odt/.ods Dateien verwendet werden. Am besten funktioniert die Bearbeitung entsprechend direkt mit OpenOffice das frei erhältlich ist.

jährliche Wikis

Für wiederkehrende Projekte/Veranstaltungen/Parties sind prinzipiell zwei Wege möglich. Man kann für alle Jahre ein Wiki nutzen, dann muss man innerhalb des Wikis eine verständliche Strukturierung für die Inhalte aus bestimmten Jahren und allgemeingültige Inhalte schaffen. Alternativ kann man jeweils für jedes Jahr ein neues Wiki verwenden. Für diesen Weg wird dann die Jahreszahl an den Veranstaltungsnamen angehängt (also <name><jahr> als Name des Wikis). Jedes Jahr muss dann neu entschieden werden ob wieder ein Wiki gebraucht wird. Für die Übernahme der Informationen aus den früheren Jahren gibt es dann wieder zwei Möglichkeiten. Entweder man überlässt es Personen die einen Zugang im alten und im neuen Wiki haben, dass sie sinnvolle Informationen übernehmen. Oder man verwendet in dem alten und dem neuen Wiki eine einheitliche Nutzerbasis (siehe auch #einheitliche_Benutzerbasis_zwischen_Wikis). Alternativ kann man natürlich auch bewusst keine alten Informationen übernehmen.

Backup

Generell werden Beitraege innerhalb des Wikis mit allen Revisionen abgelegt und sind stets nachvollziehbar. Anhaenge werden davon jedoch nicht erfasst. Wir haben ein taegliches Backup. Sollte ein Anhang mindestens 1 Tag vorhanden sein so befindet er sich zur Zeit noch 40 Tage im Backup. Sollten unsere Systeme zerstört werden lassen sich die Inhalte aus dem Backup wieder herstellen.

Haftung

Generell sind unsere Systeme nicht geeignet um kritische Daten abzulegen und wir uebernehmen keinerlei Garantie fuer die Verfuegbarkeit und Funktionalitat des Systems. Insbesondere seid ihr als Betreiber fuer die Einhaltung von gesetzlichen Regelungen selbst verantwortlich (Urherrechte, Datenschutz, StGB...). Generell gilt für alle Dienstleistungen, deren Nutzung und alle Daten ebenfalls die Benutzerordnung des kiz, das die Anbindung ans Netzwerk und die Unterbringung der Infrastruktur zur Verfügung stellt.

Kommerz

Der Anbieter der Netzwerkanbindung des kiz untersagt in seinen Bedingungen die Nutzung für kommerzielle Zwecke. D.h. man darf zum Beispiel nicht mit dem Wiki öffentlich für ein kommerzielles Angebot werben oder das Wiki für einen kommerziellen Zweck benutzen.

Suchmaschinen

Wir haben eine robots.txt auf unserem Server hinterlegt mit der Suchmaschinen gebeten werden unsere Wikis nicht zu indexieren.

Quota

Fuer den Speicherbereich haben wir ein Quota vorgesehen. Das Wiki ist nicht zum Abspeichern von riesigen Datenmengen vorgesehen (DVD/CD Images, Videos ...). Normalerweise sollte das Quota nie erreicht werden.

Stil / CMS / Website

Der Stil für die Darstellung der Inhalte heisst im englischen "Theme". Im Normalfall können Nutzer den Gestaltung ihrer Oberfläche selbst in den Einstellungen auswählen. Das kann pro Wiki auch abgestellt werden, wofür aber keine sinnvolle Anwendung bekannt ist. Es ist auch möglich das Design pro Wiki standardmässig so zu setzen, dass die ganzen zusätzlichen Felder für den Login nicht erscheinen. Eine Anwendung wäre wohl die Nutzung des Wikis als Website oder einfach CMS. D.h. Nutzer loggen sich dann über einen Link ein den sie haben und die normalen Besucher sehen nur die Seiten.

Wir bieten an das die Wikis mit einem Logo individualisiert werden. Das Logo sollten als .png vorliegen und maximal 100x60 px gross sein.

Abos / Benachrichtigung

Nutzer können über "Abonnieren" Seiten abonnieren. Sie bekommen dann Mails an ihre in ihren Einstellungen hinterlegte eMail Adresse. Es bietet sich an, generell von allen Nutzern eine eMail Adresse zu hinterlegen, auch falls man sie mal erreichen muss. Die Absenderadresse ist: 

    mail_from = u"stuve.wiki@uni-ulm.de"

Diese wie nahezu alle Einstellungen kann pro Wiki angepasst werden. Andererseits ist den Nutzern ja sicher bewusst, dass es sich um automatisierte Mails handelt.

Wiki Lebenszyklus

Solltet ihr das Wiki nicht mehr brauchen, meldet euch bitte umgehend. Der Aufwand alle Wikis in unserer Konfiguration aktuell zu halten ist nicht unerheblich. Sollten wir euren aktuellen Ansprechpartner nicht erreichen koennen und im Wiki findet keine nachvollziehbar relevante Nutzung mehr statt werden wir es entfernen. Es ist vollkommen in Ordnung ein Wiki nur als statische Informations Basis zu nutzen (bspw. alte Veranstaltungen). Aber irgendjemand sollte sich dennoch dafür zuständig fühlen ansonsten weiß irgendwann niemand mehr das es existiert und wie man darauf zugreifen kann.

Archiv

Es ist auch möglich ein Wiki auf "nur-lesen" umzustellen. Änderungen am Inhalt sind dann allgemein nicht mehr möglich. Das bietet sich besonders bei Veranstaltungen an, die für jedes Jahr ein neues Wiki bekommen. Von Vorteil dabei ist, dass die Nutzer nicht aus Versehen im falschen Wiki arbeiten.

Wiki/AdminDoku (zuletzt geändert am 2011-03-13 02:37:25 durch FlorianDufner)