wisydb
commented
5 years ago Ich fände es evtl. sinnvoll bestimmte Seiten, speziell für Entwickler hier bei Github zu haben (Installation, REST-Schnittstelle, DB-Struktur). Dazu besteht die Möglichkeit einen Wiki anzulegen (s. Navigatonsleiste). Es wäre also wiederum ein Wiki, etwas hübscher als aktuell und an einer Stelle, an der man sowas finden will. Aber mehr als die paar Seiten sehe ich nicht und bereits die REST-Schnittstelle (welche die am meisten nachgefragte für Externe ist) ist bereits für unseren Anwendungsfall serverbezogen (welche Domains/Sandboxen aufzurufen sind). Hier bei Github würde man dagegen im allgemeinen bleiben, was dazu führt, dass die betroffenen Externen doch wieder nachfragen müssen, welche Adressen sie nun konkret aufrufen müssen. Es kann also nur ein allgemeineres Duplikat sein, ebenso was die Installationsanleitung angeht (diese ist bisher nur ein rudimentärer Text, den ich aus Eigentinteresse mal für mich in Stichworten angelegt habe).
Wollte man das ganze bisherige Wiki in ein anderes Format bringen und inhaltlich Trennen müsste man sich nach einem noch konkreten Ziel fragen außer Zielgruppentrennung und Ansichtsverbesserung - bisher kommen die Leute damit zurecht und die Zielgruppen überschneiden sich: Entwickler müssen manchmal Menü-/Portaleinstellungen vornehmen, Redaktionen müssen manchmal DBMix-ini-Dateien anlegen usw. D.h. man kann es nicht sauber trennen. Was die .ini-Dateien z.B. angeht bin ich auch nicht sicher, ob ein solcher Text, der 1:1 in eine Datei übertragen werden muss, nicht in anderen Systemen mehr verstümmelt wird - oder man muss die Redaktionen erst in Code-Schreibmodus usw. schulen.
Jede Lösung der Überführung in ein anderes System muss zudem einen automatischen Import aller Seiten ermöglichen (bis auf die 2-4 ganz oben erwähnten Anleitungen), weil es sich um rund 6.000 Seiten handelt: https://b2b.kursportal.info/index.php?title=Spezial:Alle_Seiten&from=API Wer das wie manuell stemmen will ist die Frage oder die Leute müssen über Monate immer an zwei Stellen suchen. Gut, viele dieser Seiten sind nur Importdokumentationen, die leicht als "Importe" zu subsumieren sind. Aber trotzdem nicht ohne.
Dagegen hielte ich für sinnvoll:
-
Eine Aktualisierung der Wiki-Software (in Absprache mit B.P., ob etwas dagegen spricht)
-
Den sehr alten Versuch einer besseren inhaltlichen Gruppierung zu aktualisieren: https://b2b.kursportal.info/index.php?title=Arbeitswegweiser :-)
-
Jedem Titel eine Jahreszahl bzw. Jahreszahl-Zeitraum hinzufügen (falls nicht über Kategorien zu lösen), damit man auf den ersten Blick bei einer Suche sieht, auf wann sich ein Artikel bezieht. So etwas wie "Aktuelle Überarbeitung zu XYZ" ist natürlich wenig vorteilhaft - wenn 10 Jahre alt.
-
Eine Verschlagwortung aller Seiten (hier gibt es bei Wikipedia "Kategorien"), ob das in MediaWiki einfach aktivierbar ist oder etwas zusätzlich zu installieren ist weiß ich nicht. Inhaltlich kann man auch ohne Detail-Kenntnis des konkreten Inhalts viel zuordnen. Das hielte ich auch für eine Voraussetzung, bevor man die Datensätze in ein anderes System importiert.
Was spricht gegen Gitbook:
-
Das aktuelle Wiki kann jeder ergänzen. Allein für die aktuell teilnehmenden müssten wir aber schon mind. 300$/Monat bezahlen: https://www.gitbook.com/pricing Es sei denn, wir bekommen den Non-Profi-Discount (was durchaus sein kann, aber wie lange? Und was, wenn die in 3 Jahren finden, Gitbook wirft nicht genug Profit ab?)
-
Datenschutz: auf Grund der Menge der Seiten haben wir unser Wiki, wie bemerkt, erst mal pauschal zugangsbeschränkt, bei einer Überführung müsste man jeden Inhalt nochmals prüfen, ggf. Einverständnis der dokumentierten und dokumentierenden Personen einholen, eine AuftragsDV.-Vertrag abschließen und Ausland ist auch nicht so optimal in dieser Hinsicht...
Ich bin sehr wohl dankbar für die Anregung! Aber wollte selber mal das für und wieder abwägen... Die größere Dringlichkeite scheint mir aber die Auffindbarkeit im Wiki zu erhöhen und die Leute dazu anzuhalten (nicht Euch!), überhaupt sinnvoll zu dokumentieren sowie veraltete Inhalte ggf. zu löschen.
Mittel- bis langfristig sollte man die WISY-Dokumentation unter https://b2b.kursportal.info überarbeiten und in ein für die jeweiligen Zielgruppen (Redakteure, Entwickler) passendes Format bringen.
(Unter https://www.gitbook.com/book/svenkaemper/wisypedia/details hatte ich exemplarisch einmal ein paar Seiten aus dem aktuellen WISY-Wiki angelegt: einfach auf „Read“ klicken, um zur Browserversion des Buchs zu gelangen)