• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

Das neue BSDForen.de Wiki

Yamagi

Possessed With Psi Powers
Mitarbeiter
Themenstarter #1
Hallo BSDForen.de,
seit praktisch dem Anbeginn aller Zeiten ist das BSDForen.de-Wiki ein Teil unser Community. In den letzten Jahren ist es allerdings mehr und mehr eingeschlafen. Zwar blieben die Zugriffszahlen recht konstant, neue Beiträge gab es bis auf wenige Ausnahmen jedoch nicht mehr. Anfang September starteten wir daher eine Umfrage zur Nutzung des Wikis: https://www.bsdforen.de/threads/nutzung-des-bsdforen-wikis.35165/ Das Ergebnis bestätigte unsere Vermutung, dass das Interesse am Wiki recht gering ist. Aber auch, dass der Wunsch besteht es weiterzuführen.

Nun ist es leider so, dass das Wiki - ob nun genutzt oder nicht - uns Arbeit macht. Es benötigt ein Jail, einen Webserver mit PHP, die Software selbst und ihre Plugins müssen aktuell gehalten werden und so weiter. Für ein Projekt mit relativ geringem Interesse ist das nicht mehr zu rechtfertigen, die Arbeitszeit ist an anderen Stellen besser investiert. Dazu kommen zwei Punkte, die wir vor der internen Diskussion und der Diskussion zur oben verlinkten Umfrage gar nicht im Blickfeld hatten:
  • Einmal ist dort die Sache mit der Registrierung. Wir können, aus bitterer Erfahrung, das Wiki nicht zur allgemeinen Registrierung öffnen. Es ist nur eine Frage der Zeit, bis ein Spammer den Weg hinein findet und es verwüstet. Den Spam rückstandslos rauszukratzen ist viel Arbeit. Wenn es ständig vorkommt, sogar frustrierende Arbeit. Aus dem gleichen Grund können wir den Login nicht an einen Forenaccount binden. Denn auch ins Forum kommen immer wieder Spammer, anders als im Wiki sind sie da aber mit buchstäblich einem Klick zu entfernen. Ohne eine allgemeine Registrierung ist das Wiki aber zum Tod verurteilt. Denn den Weg sich im Forum zu registrieren und einem Moderator eine Privatnachricht mit Bitte um einen Wiki-Account zu schreiben, geht verständlicherweise kaum jemand.
  • Das Wiki kommt aus einer Zeit, in der es ein deutsches und ein englisches Internet gab. Die offiziellen Dokumentationsprojekte waren auf Englisch, nicht alle deutschen Nutzer konnten die Sprache. Daher war das Wiki als deutschsprachige Quelle sehr willkommen. Nun wird die offizielle Dokumentation aller BSDs aber schon seit Jahren teilweise oder ganz ins Deutsche übersetzt und es gibt Dienste wir DeepL oder Google Translate. [0] Das führt zu der Frage, ob die ins Wiki gesteckte Arbeit nicht in den offiziellen Dokumentationsprojekten besser investiert wäre. Wir tendieren zu einem "Ja."
Zusammenfassend haben wir uns entschlossen, das Wiki in seiner Struktur und seinem Workflow ins Jahr 2019 zu bringen. Nahezu alle Dokumentation wird heute in einer einfachen Markupsprache wie Markdown, AsciiDoc oder Restructured Text geschrieben und automatisch in statisches HTML gerendert. Es ist gut für uns Admins, statisches HTML ist wesentlich angenehmer als eine komplette Wikisoftware zu handhaben und es ist für Nutzer gut, sie müssen nicht noch das über die Jahre immer weniger verbreitetere Dokuwiki-Markup lernen.

Das BSDForen.de-Wiki ist daher ab sofort auf Github und Github-Pages gehostet:
  • Der Quellcode in Restructured Text findet sich unter https://github.com/bsdforen/wiki. Beitragen kann jeder der mag mit dem ganz normalen Github-Workflow. Das Repository in den eigenen Account klonen, die Änderung vornehmen und committen, anschließend ein Pull Request stellen. Schon ist (nach einer kurzen Prüfung) eurer Beitrag in unserem Wiki.
  • Der Quellcode wird per Sphinx in statisches HTML gerendert und wie gehabt unter https://wiki.bsdforen.de bereitgestellt. Natürlich kann man es sich selbst rendern und lokal nutzen.
Warum Github, Github Pages und Sphinx? Ganz einfach. Die Mehrzahl Nutzer - egal ob Entwickler oder Administratoren - hat heute einen Github-Account, es muss also kein weiterer Account irgendwo angelegt werden. Der Workflow ist bekannt, viele Nutzer haben bereits Erfahrung mit ihm. Sphinx wiederum ist einfach einzurichten, nahezu unabhängig vom Betriebssystem und wiederum weit verbreitet. Das von Sphinx verwendete Restructured Text lässt sich direkt 1:1 an vielen anderen Stellen verwenden. Ist es nicht möglich, kann man es per Pandoc in nahezu jedes erdenkliche andere Format konvertieren.

Last but not least vielen Dank an @foxit, der das Dokuwiki teilweise automatisch und teilweise manuell in Restructured Text konvertiert und in ein Sphinx-Projekt umgebaut hat. Das war gute Arbeit!

Viele Grüße,
das BSDForen.de-Team


0: Ältere Semester erinnern sich vielleicht noch an den hier auf BSDForen.de koordinierten Versuch FreeBSDs Dokumentation zu übersetzen. Das muss so um 2005 gewesen sein.
 
#3
Moin!
Dann ist es so! :-/ (Bei github & Co bin ich leider raus. Die Debatte habe ich nicht verfolgen können. (Sorry!) Im Wiki selbst las ich nichts. :-/ )
Kann bitte der (bisherige) Inhalt zum Herunterladen bereitgestellt werden? Im Zweifelsfall bitte als Anhang an vater at bsd.services senden.
 

foxit

Well-Known Member
#4
Bravo, ein sehr moderner Ansatz!
Danke. Es erschien und als "die beste" Lösung für unser Wiki.

Auch von meiner Seite nochmals Danke an alle die geholfen haben!

Das Wiki ist natürlich noch lange nicht "fertig". Es gibt einige Seiten, die wirklich stark veraltet sind. Daher würden wir uns natürlich freuen, wenn ihr uns dabei unterstützen würdet, dass Wiki wieder aktuell zu halten und die alten Artikel aussortiert bzw. überarbeitet :)
 
#5
Danke. Es erschien und als "die beste" Lösung für unser Wiki.
Die Frage ist für was.
Das Wiki ist natürlich noch lange nicht "fertig". Es gibt einige Seiten, die wirklich stark veraltet sind. Daher würden wir uns natürlich freuen, wenn ihr uns dabei unterstützen würdet, dass Wiki wieder aktuell zu halten und die alten Artikel aussortiert bzw. überarbeitet :)
Gibt es irgendwo ein Plan? (Wie wird was als "aktuell für FreeBSD 12" gekennzeichnet? Was ist "der roter Faden"? (Oder wird erwartet sich Inhalt durch Finden mit textliche Suche von Wörtern in den einzelnen Seiten auffindbar zu machen? (Wie bequem ist das für vergleichsweise Unerfahrene?))) Schwierig!
Worauf ich hinaus will: Eine "anderes" Wiki schafft (leider) nicht direkten Willen zum inhaltlichen Arbeiten. (Das lässt sich nur durch organisierte Revision (Überprüfung) lösen.)
 

foxit

Well-Known Member
#7
Einer der Gründe steht oben:
Es benötigt ein Jail, einen Webserver mit PHP, die Software selbst und ihre Plugins müssen aktuell gehalten werden und so weiter.
Alles Sachen, die wir jetzt nicht mehr benötigen. Weiter ist die Markup Sprache von DokuWiki nicht wirklich verbreitet. Markdown und RestructuredText wird hingegen sehr häufig genutzt.
Gibt es irgendwo ein Plan? (Wie wird was als "aktuell für FreeBSD 12" gekennzeichnet?
Das wäre über Tags machbar. Aber es gibt hier auch noch andere Varianten.
Worauf ich hinaus will: Eine "anderes" Wiki schafft (leider) nicht direkten Willen zum inhaltlichen Arbeiten
Das ist vermutlich richtig aber es war immer ein Problem bzw. Hindernis, dass man einen seperaten Account dafür benötigt hat (siehe Posting 1). Wenn du Ideen hast, wie wir unsere Member dazu bringen mehr ins Wiki beizutragen, bitte immer her damit!

Uns ging es im ersten Schritt einfach mal darum, die Basis des Wikis auf einen aktuellen, technischen Stand zu setzen.
 
#8
Den kannst du dir mit git klonen: git clone https://github.com/bsdforen/wiki.git Oder direkt als ZIP herunterladen: https://github.com/bsdforen/wiki/archive/master.zip
Dank dir! :-) (Das war mir klar.)
Ich meinte den direkten Inhalt vom Dokuwiki (also das Verzeichnis der Textdateien). Da war ja noch ein wenig mehr. (Aus meiner Sicht kann auch auf die Historie verzichtet werden.)
Als "illustrierendes" Beispiel (meines Wunsches) kann vielleicht der Link dienen: https://www.dokuwiki.org/tips:backup_script#one-time_backup
 

CommanderZed

OpenBSD User
Mitarbeiter
#9
Hi

Das neue Wiki wird ja 1:1 aus den git-daten über das Sphinx erstellt. git clone (oder das zip) + konfiguriertes sphinx ist quasi ein "komplett-download".

Alternativ könntest du mit ftp / wget o.ä. vermutlich auch 1:1 die html-seiten kopieren.
 
#10
Einer der Gründe steht oben:

Alles Sachen, die wir jetzt nicht mehr benötigen. Weiter ist die Markup Sprache von DokuWiki nicht wirklich verbreitet. Markdown und RestructuredText wird hingegen sehr häufig genutzt.
Selbstverständlich! (Ich meinte aber nicht die technische Gründe, den Aufwand ein Dokuwiki an sich zu betreiben. Aber auch der standardmäßige "doofe" Syntax von Dokuwiki wäre, wie beispielsweise auch das Theme, was ja auch verändert wurde, kann angepasst werden. (Damit ich nicht falsch verstanden werde: Dokuwiki finde ich auch nicht toll.))

Ich meine aber das Arbeiten an den Inhalten. (Was ist das Ziel?)
Der Zweck, dass Menschen einfach (organisiert) Inhalte finden, war nicht zu erkennen. Das ändert (änderte) sich nicht durch (den Aufwand für) den Wechsel der "Engine".

Das wäre über Tags machbar. Aber es gibt hier auch noch andere Varianten.
Jo! Dazu hatte ich schon im vorherigen Wiki was grob (konzeptionell) vorbereitet. (Leider kann ich gerade nicht mehr darauf verweisen. :-D )

Das ist vermutlich richtig aber es war immer ein Problem bzw. Hindernis, dass man einen seperaten Account dafür benötigt hat (siehe Posting 1).
Sind ja ohnehin alle auf "diesem" Github. (Die Debatte erspare ich uns wohl einfach am besten.)

Wenn du Ideen hast, wie wir unsere Member dazu bringen mehr ins Wiki beizutragen, bitte immer her damit!
  • Sinn und Zweck vom Wiki benennen! (Dabei sollte eine klare Abgrenzung zum Forum gemacht sein.) Welche Art von Artikeln soll es geben?
  • Nicht nur das Wiki als "Wurmfortsatz" vom Forum sehen! (Wenn wer berichtet etwas mit BSD eingerichtet zu haben, dann "doof" fragen wie das gemacht wurde und anstatt um eine "normale" weitere Antwort zu bitten, einfach auf einen initialen Artikel im Wiki verweisen.)
  • Am Ende der Debatte (Thread) vor dem Schließen das Ergebnis ins Wiki "kippen" (lassen).
  • (Nicht bei Github, sondern auf eigener Infrastruktur, betreiben!)
  • Zentrale Seiten erstellen (und pflegen), die alle Themenbereiche abdecken (wobei auf bestehende Inhalte, aber auch fehlende Inhalte, verwiesen wird)!
  • Nach "best practice" (oder "good practice") für übliche oder spezielle Szenarien fragen (und entsprechend dokumentieren lassen)!
  • Debatten (Threads) zu (den) veralteten Inhalten aufmachen!
  • Standardmäßige (beispielhafte) Konstrukte für Seiten bereitstellen!
  • Hilfe zum "richtigen" (einheitlichen) "Wording" und Formatieren bereitstellten!
  • "Gärtnerinnen" (wie beispielsweise mich) zügig mit Berechtigungen bewerfen!

Uns ging es im ersten Schritt einfach mal darum, die Basis des Wikis auf einen aktuellen, technischen Stand zu setzen.
Jo! (WYSIWYG-Editor ist schon nett. ;-) :-p :-) )
 
#11
Hi

Das neue Wiki wird ja 1:1 aus den git-daten über das Sphinx erstellt. git clone (oder das zip) + konfiguriertes sphinx ist quasi ein "komplett-download".

Alternativ könntest du mit ftp / wget o.ä. vermutlich auch 1:1 die html-seiten kopieren.
Eben leider nicht!
Kleines Beispiel: Wo sind die Inhalte, die in wiki: (Ordner wiki) oder user: (Ordner user) und jeweild darunter liegende Seiten (Dateien)? (Den Rest, der eben nicht so richtig eingeordnet war, habe ich nicht im Kopf.)
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
Themenstarter #14
@vater, es ist immer leicht Dinge einzufordern und Neuerungen abzulehnen. Aber wie so oft gibt es auch eine andere Seite der Medaille:

BSDForen ist ein reines Privat- oder Hobby-Projekt. Alle vom Team engagieren sich hier in ihrer Freizeit. Und das bedeutet, dass die Anzahl Stunden, die jeder von uns pro Monat investieren kann, irgendwo begrenzt ist. Wir haben Familien, Freunde, andere Hobbies. Dazu arbeiten wir alle auf die eine oder andere Art in der IT. Wenn man schon 8 bis 10 Stunden im Büro an der Kiste sitzt, ist die Begeisterung am Abend noch mal für 2 bis 4 Stunden das Gleiche zu machen sehr gering.

Das soll nicht als Geheult verstanden werden. Wir machen es schließlich gerne. Würden wird es nicht tun, gäbe es BSDForen.de schon lange nicht mehr. Aber es bedeutet zwangsläufig, dass wir uns überlegen müssen, wo wir die uns zur Verfügung stehende Zeit investieren. Und das Wiki fraß viel Zeit. Alleine die Arbeit die Wiki-Software und die Unmengen darin hängenden Plugins aktuell zu halten, sollte man nicht unterschätzen. Nun ist das Wiki aber seit Jahren de facto tot gewesen. Die Anzahl Änderungen in den letzten Jahren ließen sich an 10 Fingern und 10 Zehen abzählen, im Wiki-Forum drehen sich die Diskussionen um alle möglichen Projekte, aber nicht um das Wiki und das Feedback auf unsere Umfrage war auch gering. Bezeichnend ist auch, dass @foxit vor einem guten Jahr das Wiki per Brechstange auf PHP 7 portiert hatte. Dabei waren Dinge kaputtgegangen, u.a. fehlten hinterher einige Plugins, wodurch einige Seiten nicht mehr sauber renderten. Das ist meines Wissens niemals jemanden aufgefallen.

Die Umfrage hat zwei Dinge gezeigt. Einmal, dass Interesse daran besteht, dass die Inhalte des Wikis verfügbar bleiben. Dann, dass sich kaum ausreichend Nutzer an der Pflege beteiligen würden, um es am Leben zu halten. Sphinx ist in unseren Augen eine gute Lösung um alle Meinungen unter einem Hut zu bekommen. Wir sparen massiv Zeit, da wir keine Wiki-Software mehr supporten müssen. Die Inhalte sind leicht zugänglich für Jedermann erreichbar. Und es dürfte für die meisten Nutzer einfacher sein Inhalte beizutragen, als es bisher der Fall war.
 
#15
@Yamagi : Jo! (Meinerseits soll das auch kein Geheule sein. Eher möge es als (seltenes) Interesse zum Wiki verstanden werden. Und vielen lieben Dank für all deine (eure) Mühen.)

Zur Bewertung meiner "Wünsche" kannst du auch gern - sofern dir verfügbar - meine Gedanken zum Wiki (im früheren Wiki) einsehen. (Die "Probleme" sah ich gleichermaßen.)

Meine (leider pessimistische) Einschätzung ist nur, dass mit "dem neuen Wiki" aber eben genau diese notwendige (inhaltliche) Überarbeitung nicht kommen wird. (Der Fehler meinerseits ist, dass ich die Debatte im Forum nicht mitbekam (nicht verfolgte). Ähnlich war das sicherlich zu meinen Ideen zum Wiki (im Wiki).)

Im Übrigen hätte ich wohl sonst einen key bereitgestellt, um anzubieten mit (die Jail samt Paketen) zu verwalten.
(Gag am Rande: Dokumentation zum eigenen Betrieb von Diensten gibt es ja auch nicht, oder?)

Eine Debatte zur (fehlenden) Zweckmäßigkeit für "Unmengen darin hängenden Plugins" und daraus folgenden Problemen und gar Dokuwiki selbst braucht es nicht.

Trollig (aber voller Liebe) könnte ich ja fragen, ob es eine Dokumentation für eine zentrale Kontenverwaltung (LDAP oder anderer foo) gibt (oder sie beim Erstellen wer schreiben mag). Ich würde dann gitea, gitlab oder was (für py-sphinx oder auch nicht) in einer bereitgestellten Jail installieren und anbinden. :-p :-*

Möge sich kein Mensch gestresst fühlen. :-)

Für die Bereitstellung von alle Seiten, die (beim früheren Wiki) existierten, wäre ich dankbar. :-)
 

pit234a

Well-Known Member
#16
Meine (leider pessimistische) Einschätzung ist nur, dass mit "dem neuen Wiki" aber eben genau diese notwendige (inhaltliche) Überarbeitung nicht kommen wird. (Der Fehler meinerseits ist, dass ich die Debatte im Forum nicht mitbekam (nicht verfolgte). Ähnlich war das sicherlich zu meinen Ideen zum Wiki (im Wiki).)
Nunja. Manche Leute ärgern sich über mich, weil ich nicht so recht gelernt habe, diplomatisch zu sein. Das will ich hier mal wieder beweisen und meine Deutung mit drastischen Worten formulieren: Das Wiki war vorher quasi tot und es wird nicht wiederbelebt, sondern nur auf eine moderne und einfacher zu handhabende Plattform gebracht. Es bleibt aber tot.
Ich glaube, das ist gut so und wird dem Ergebnis der Umfrage und dem Verhalten der Nutzer, also Besucher und Anwender, vollkommen gerecht.

Der Wunsch, die alten Inhalte zu erhalten, ist absolut verständlich. Ich erinnere da ein Script von @Kamikaze zur Überwachung von Batterien in Laptops, für das ich erst neulich wieder Bedarf hatte (und zu bequem war, selbst etwas zu friemeln). Nun veralten Scripts ja nicht so schnell, wie fast alle anderen Anwendungen und je mehr Beiträge es davon gibt, desto mehr Arbeit macht ja alleine die Anpassung auf neue Versionen und Lösungen. Wer soll das denn leisten?
Das ist nun ein klein wenig OT, aber ich erinner doch https://www.bsdforen.de/threads/veränderungen-im-team.35206/ ganz genau, wie auch nicht, ist der doch quasi brand-aktuell. Fünf gehen, zwei kommen.
Zwei, die das Forum unlängst irgendwie verlassen haben, waren @holgerw und @ralli. Nach meinem Empfinden beide gleichzeitig, wenigstens zeitnah. Man mag das sehen, wie man will, aber beide haben einen gewissen Elan bewiesen und Projekte gestartet und für die Allgemeinheit dokumentiert. Was da aus der geplanten FreeBSD-Doku von @holgerw wird, weiß ich nicht. Beide hätten vielleicht auch für die Überarbeitung eines Wikis gewonnen werden können. Ist aber nicht mehr. Und wer bleibt?
Keinem einen Vorwurf! Ich selbst bin dafür vollkommen ungeeignet und zwar nicht nur technisch, sondern auch wegen mangelnder Motivation.

Betrachte ich das nüchtern und mit meinem Depri-Blick, dann geht das bsdforen.de schwierigen Zeiten entgegen und man kann einfach nicht verlangen oder erwarten, dass die Leute, die sich hier einsetzen um dieses Forum aufrecht zu erhalten, nun auch noch ein super-Wiki erstellen und pflegen, für das es immer weniger Bedarf und Bereitschaft gibt.
 

medV2

Well-Known Member
#17
Gerade was das Anpassen und Aktualisieren von veralteten oder fehlerhaften Inhalten angeht sehe ich im neuen System Vorteile. Wie schon gesagt ich war jetzt nicht so der Wiki-Schauer aber angenommen ich sehe rein, finde etwas was angepasst werden muss:

Workflow im alten System: Ich schreib ne PN an einen Mod, der muss mich freischalten und mit etwas Glück hab ich in 1-2 Tagen die Rechte. Da habe vielleicht ich dann keine Zeit und das ganze verläuft im Sand.

Jetzt: Pull Request erstellen und die Sache ist für mich erledigt
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
Themenstarter #18

turrican

Well-Known Member
#19
hatte heute nach was im Forum gesucht, wovon ich dachte, ralli hätte da mal was zu geantwortet - und erst dann realisiert: ralli und holgerw sind weg? o_O die beiden hab ich irgendwie verpasst, schade :(
 

sterum

Well-Known Member
#20
Jetzt: Pull Request erstellen und die Sache ist für mich erledigt
Gibt es dazu auch eine Schritt für Schritt Anleitung für jemanden wie mich der noch nie mit Git gearbeitet hat.

Ich möchte nämlich meinen Spiele/Unreal Eintrag ergänzen bzw. richtigstellen ohne das ich mich erst Stundenlang in Git einarbeiten muss.
 

gadean

Well-Known Member
#23
Und falls dir das mit git zu viel ist:
Schritt 1 - 2, dann die Änderungen direkt auf Github vornehmen, Schritt 7
 

sterum

Well-Known Member
#24
Punkte 1 - 6 funktionieren schon mal. Ich werd jetzt mal die Änderungen vornehmen, dann werd ich mich um Punkt 7 kümmern :).