Das Wiregate und die Dokumentation - Confluence Server BEREIT

[bluegaspode]

Hier ein Draft fürs Inhaltsverzeichnis.

https://bluegaspode.atlassian.net/wi...Community+Doku

Habe versucht die wichtigsten hier im Thread genannten Themen unterzubringen. Hier und da wild ein bißchen Content (ohne Nachbearbeitung) reinkopiert, damit der Prototyp ein bißchen lebensechter aussieht.

Meldet euch an und ergänzt Kapitelnamen. Dann sehen wir gleich, wie die Anarchie im Wiki funktioniert

Unabhängig davon, welche Plattform es später wird - ein Konsens zu Kapiteln kann so vielleicht schon parallel gefunden werden.
Bitte noch keine Mühe in echten Content stecken, solange die Zielplattform nicht festgelegt ist.

[wuestenfuchs]

Wow!

Okay, das sieht wirklich übersichtlich und professionell aus. Wenn elabnet in den Genuss der kostenfreien Open-Source-Lizenz kommen sollte, wär das doch was.

Falls nicht... tja, das wäre wirklich schade. Denn gerade im Open Source-Bereich skalieren die Nutzerzahlen mit der Zeit nach oben. Natürlich gibt es dann immer auch einige "alte" Benutzer, die einige Zeit nichts oder nur wenig machen. Ich halte es problematisch, diesen den Account zu entziehen, nur um aufgrund der Lizenzproblematik wieder Platz für neue Nutzer zu haben.

Sicher, dass es außer Confluence keine gangbaren Alternativen gibt? Auf eine schnelle Google-Suche hin habe ich diesen Artikel hier gefunden, der Confluence mit dem freien Mediawiki und dem ebenfalls freien, darauf aufbauenden BlueSpice vergleicht (die Comments sind auch ganz interessant). Dort werden auch nicht ganz unwichtige Themen wie Vendor Lock-In (die Daten aus der Confluence-Datenbank kriegst du wohl nicht schadlos raus) besprochen.

[wuestenfuchs]

Eine weitere Alternative, ist mir eben erst eingefallen: Dokuwiki. Ich kenne es z.B. vom Zabbix-Wiki her (wer es mal 'live' in Aktion sehen will, klicke auf den Link). Bietet ebenfalls 'out-of-the-box' ein hierarchisches Inhaltsverzeichnis und ist FOSS.

[StefanW]

Wow, ihr seid umwerfend.

Bitte lasst mir noch ein wenig Zeit für die Entscheidung, es ist eine Menge Stuff zum lesen und natürlich auch eine richtungsweisende Entscheidung. Die würde ich auch mit meinen Mitarbeitern zuvor besprechen wollen.

Was das finanzielle angeht, natürlich nehmen wir kostenfrei gerne, aber wenn die Lizenz ein paar EUR kostet, dafür aber administrative Schmerzen vermeidet, ist es am Ende günstiger.

Ich werde mich mal in die Vorschläge einlesen, Erfahrungsberichte und Links lese ich gerne.

Lg

Stefan

[Robert_Mini]

Hier ein Draft fürs Inhaltsverzeichnis.

https://bluegaspode.atlassian.net/wi...Community+Doku

Habe versucht die wichtigsten hier im Thread genannten Themen unterzubringen. Hier und da wild ein bißchen Content (ohne Nachbearbeitung) reinkopiert, damit der Prototyp ein bißchen lebensechter aussieht.

Meldet euch an und ergänzt Kapitelnamen. Dann sehen wir gleich, wie die Anarchie im Wiki funktioniert

Unabhängig davon, welche Plattform es später wird - ein Konsens zu Kapiteln kann so vielleicht schon parallel gefunden werden.
Bitte noch keine Mühe in echten Content stecken, solange die Zielplattform nicht festgelegt ist.

Hab mal das Verzeichnis ein wenig ergänzt, umsortiert etc.
Bin echt erstaunt, wie einfach das Wiki fuktioniert und wie rasch darin Übersicht schaffen kann .

Das ist in jedem Fall motiviertend bei der Doku mitzumachen (mach gleich weiter..)

@Stefan: Wichtig ist die Frage, wie mit den Datenblättern/Infos auf eure Homepage etc. umgegangen wird. Lässt sich zwar rasch einpflegen, muss aber doppelt gewartet werden.

Professionelle Homepage und Community Wiki spießt sich irgendwie. Ich denke alleine rein rechtlich wollt/könnt ihr das Wiki nicht direkt in die Homepage integrieren. Somit ist eine gewissen Doppelgleisigkeit unvermeidbar (hab jetzt mal laut gedacht).

lg
Robert

[fanta2k]

Wow!

Okay, das sieht wirklich übersichtlich und professionell aus. Wenn elabnet in den Genuss der kostenfreien Open-Source-Lizenz kommen sollte, wär das doch was.

Falls nicht... tja, das wäre wirklich schade. Denn gerade im Open Source-Bereich skalieren die Nutzerzahlen mit der Zeit nach oben. Natürlich gibt es dann immer auch einige "alte" Benutzer, die einige Zeit nichts oder nur wenig machen. Ich halte es problematisch, diesen den Account zu entziehen, nur um aufgrund der Lizenzproblematik wieder Platz für neue Nutzer zu haben.

Sicher, dass es außer Confluence keine gangbaren Alternativen gibt? Auf eine schnelle Google-Suche hin habe ich diesen Artikel hier gefunden, der Confluence mit dem freien Mediawiki und dem ebenfalls freien, darauf aufbauenden BlueSpice vergleicht (die Comments sind auch ganz interessant). Dort werden auch nicht ganz unwichtige Themen wie Vendor Lock-In (die Daten aus der Confluence-Datenbank kriegst du wohl nicht schadlos raus) besprochen.

für ne doku gibt es aktuell nix besseres als Confluence.

Wie zuvor geschrieben wäre das einzige noch ein help&Manual, aber nur wenn man die doku selbst intern durchführt und vollständige pdf/winhelp exporte notwendig sind.

mediawiki/dokuwiki sind im professionellen bereich nicht brauchbar (import/export für übersetzungen etc pp).

bei der hosted version gibt es nur einen nachteil, man kann keine eigene domain drauf mappen.

[Robert_Mini]

Meldet euch an und ergänzt Kapitelnamen. Dann sehen wir gleich, wie die Anarchie im Wiki funktioniert

Erledigt .

Können die Kommentare auf den einzelnen Seiten editiert (gelöscht werden)?
Ich würde gerne die Seiten damit (in der Anfangsphase) kommentieren (Kritik , was ist zu tun, Verbesserungsvorschläge, etc.).
Ich denke mit soch gut sichtbaren Kommentaren, werden mehr Mitgestalter angesprochen (und besser als die Kommentare im Text).
Oder gibt's andere Funktionen hierzu?

lg Robert

[Astrafahrer]

Können die Kommentare auf den einzelnen Seiten editiert (gelöscht werden)?

Kommentare (anderer User) können mit entsprechenden Rechten gelöscht oder editiert werden. Das Recht ist aber normalerweise dem Admin vorbehalten. Der "normale" User kann das nicht.

[bluegaspode]

Erledigt .

Erstmal vielen Dank für das Überarbeiten / Ergänzen des Inhaltsverzeichnisses. Ich finde die Struktur richtig gut, und wenn wir diese Seite mit dem vorhandenen Content aufgefüllt haben, wäre das schön ein richtig guter Initialzustand.

Ich denke mit soch gut sichtbaren Kommentaren, werden mehr Mitgestalter angesprochen

Kommentare sind genau dafür da - wenn man sich nicht traut direkt den Artikel zu ergänzen ein paar Hinweise oder Überarbeitungsvorschläge (oder Nachfragen) eben einfach als Kommentar zu hinterlassen (in meiner Demo-Instanz erlaube ich das sogar anonymen Benutzern).

Gelöscht werden können die Kommentare von Nutzern mit der entsprechenden Berechtigung (ähnlich einem Forum). Im Gegensatz zu den Hauptseiten gibt es allerdings keine Historie für die gelöschten Kommentare, daher üblicherweise nicht für jeden Benutzer freigeschaltet.

Es ist aber schon ein üblicher Arbeitsablauf, dass man auch in den Kommentaren ab und zu mal aufräumt, wenn die Ergänzungen im Hauptartikeln vorgenommen wurden und damit die Kommentare überflüssig geworden sind.

[wuestenfuchs]

Professionelle Homepage und Community Wiki spießt sich irgendwie. Ich denke alleine rein rechtlich wollt/könnt ihr das Wiki nicht direkt in die Homepage integrieren. Somit ist eine gewissen Doppelgleisigkeit unvermeidbar (hab jetzt mal laut gedacht).

Hm, ich sehe da weder Unprofessionalität noch rechtliche Probleme. Könntest du das etwas näher beschreiben?

[Robert_Mini]

Hm, ich sehe da weder Unprofessionalität noch rechtliche Probleme. Könntest du das etwas näher beschreiben?

Man sollte nicht jedes Wort auf die Waagschale legen .

Was ich meine:
Die Sensoren sollten weiterhin mit Datenblatt ausgeliefert werden, die auch im Shop verlinkt sein sollten. Das vermag das Wiki nicht ersetzen (=Professionalität).
Die Datenblätter enthalten zB Anschlussinfos. Sollte hier im Wiki was von einem freiwilligen Helfer falsch eingepflegt werden, könnte bei einem Kunden von elabnet was beschädigt werden. Auch wenn die Datenblätter einen Rechtsausschluss beinhalten, würde bei einem Fehler kulant agiert werden, so wie ich Stefan kenne. Beim offenen Wiki wird es da schon schwieriger.
Rechtlich ist daher der falsche Ausdruck, da kein Rechtsanspruch auf Richtigkeit bestehen wird, aber dann leidet im der Ruf, Seriösität, wie immer man es nennen will.

Aber die Doppelgleisigkeit zw. Datenblätter und Wiki würde mich nicht stören, da sich an diesen ohnehin nur wenig ändert.

Lg Robert

[StefanW]

Nun, Robert hat mich schon auf einen wichtigen Gedanken gebracht.

Ein Hersteller haftet für seine Prospekte und auch Bedienungsanleitungen. Insofern wäre schon zwischen offizieller Anleitung (oder auch offiziell ¨genehmigt¨) und Tipp von Benutzer zu Benutzer zu unterscheiden.

Es gibt da die bestimmungsgemäße Nutzung für die ein Produkt entworfen wurde und für das auch nur die Gewährleistung / Support-Zusicherungen gelten und die Nicht-Bestimmungsgemäße-Nutzung (z.B. Installationen mit Root-Rechten, Nutzung des WG auch als NAS etc.) für die sich manche User entscheiden, auch wenn sie damit ausgetretene Pfade verlassen oder keinen Support-Anspruch mehr haben. Das berührt auch rechtliche Positionen, insofern wäre eine Unterscheidung sinnvoll.

Ich würde also gerne eine Markierung sehen als ¨Offizielle Doku¨, Anwender-Tipps, Plugins und ¨Root-Erweiterungen ohne Support¨ oder so ähnlich. Bei den gefährlicheren Dingen wie den Plugins und den Manipulationen am System nur mit Root gehört dann auch ein Standard-Warnhinweis untergebracht, evt. gleich in einem entsprechenden Template.

Auf Dauer wäre auch Mehrsprachigkeit und PDF-Ausgabe eine wichtige Sache, wie auch die Unterstützung von mehr als einer WG-Plattform.

Lg

Stefan

[Robert_Mini]

Nun, Robert hat mich schon auf einen wichtigen Gedanken gebracht.

Ein Hersteller haftet für seine Prospekte und auch Bedienungsanleitungen. Insofern wäre schon zwischen offizieller Anleitung (oder auch offiziell ¨genehmigt¨) und Tipp von Benutzer zu Benutzer zu unterscheiden.

Es gibt da die bestimmungsgemäße Nutzung für die ein Produkt entworfen wurde und für das auch nur die Gewährleistung / Support-Zusicherungen gelten und die Nicht-Bestimmungsgemäße-Nutzung (z.B. Installationen mit Root-Rechten, Nutzung des WG auch als NAS etc.) für die sich manche User entscheiden, auch wenn sie damit ausgetretene Pfade verlassen oder keinen Support-Anspruch mehr haben. Das berührt auch rechtliche Positionen, insofern wäre eine Unterscheidung sinnvoll.

Produkthaftung heißt das Teufelswort.

Der Einfachheit halber würde ich das wiki als Community Doku (Hinweis das der Inhalt nicht in der Verantwortung von elabnet liegt) führen, mit einem generellen Haftungs-, Gewährleistungsausschluss und Hinweis, dass der Supportanspruch verloren geht, wenn gewisse Grenzen überschritten werden.

Eine Unterteilung in offiziell und User-infos halte ich für nicht praktikabel, da die Grenzen verschwimmen und letztlich Effizienz und Übersichtlichkeit leiden.

@wiki-experten:
- gibt es auch die Möglichkeit Seiten im Wiki versteckt zu halten, bis sie zB durch Stefan released werden?
- Können die Userrechte auch auf Bereiche des Inhalts eingeschränkt werden oder wie könnten offizielle Bereiche sonst noch geführt werden?

Lg Robert

[bluegaspode]

Insofern wäre schon zwischen offizieller Anleitung (oder auch offiziell ¨genehmigt¨) und Tipp von Benutzer zu Benutzer zu unterscheiden

Das war der Grund warum ich das Wiki gleich "Community Wiki" getauft hatte. Man könnte einen zweiten 'offiziellen' Bereich aufmachen, in dem nur ihr Berechtigungen habt (und User trotzdem Kommentare hinterlassen könnten).

Bei den Root-Geschichten, sollte man vermutlich sowieso auch 'ne Tutorial Seite machen (wie komme ich mit Windows/Mac überhaupt auf die Konsole etc.), da hats auch Platz für 'nen großen roten Disclaimer.
Bei den Seiten die Root-Zugriff benötigen, kann man den Disclaimer dann wiederholen oder auf die Seite verlinken.

@wiki-experten:
- gibt es auch die Möglichkeit Seiten im Wiki versteckt zu halten, bis sie zB durch Stefan released werden?
- Können die Userrechte auch auf Bereiche des Inhalts eingeschränkt werden oder wie könnten offizielle Bereiche sonst noch geführt werden?

alles ja. Berechtigung sind getrennt nach Lese/Schreibrechten. Können für Bereiche oder je Einzelseite vergeben werden. Einzelseiten vererben ihre Rechte auf die Unterseiten.

Die Sensoren sollten weiterhin mit Datenblatt ausgeliefert werden, die auch im Shop verlinkt sein sollten. Das vermag das Wiki nicht ersetzen (=Professionalität).

Die Flyer könnte man, wenn man will parallel in Confluence hochladen, erscheinen dort (optional) gleich mit Vorschau:
https://bluegaspode.atlassian.net/wi...EGATE/Multi-IO

Aber wie so immer - doppelte Pflege hat natürlich seine Nachteile, muss man abwägen - so dass ein einfacher Link hier möglicherweise besser wäre.

Auf Dauer wäre auch Mehrsprachigkeit und PDF-Ausgabe eine wichtige Sache, wie auch die Unterstützung von mehr als einer WG-Plattform

Mehrsprachigkeit ist meines Wissens in Confluence per se nicht gegeben. Nach Google Suche gäbe es zwei Möglichkeiten: saubere Trennung - ein Bereich je Sprache - oder per kostenlosen Plugin nachrüsten: (https://marketplace.atlassian.com/pl...ugins.language) - habe aber keine Erfahrung damit, wie gut es funktioniert.

Ein einfacher PDF-Export ist inklusive (auch für den ganzen Bereich am Stück, nicht nur einzelne Seiten). Man kann glaube ich Deckblatt und Header/Footer individuell noch vorgeben, erhält ein Inhaltsverzeichnis und dann jede einzelne Seite. Google-Suche ergibt noch viel mehr Sachen (CSS-Stile definieren, Kaufbare Plugins für noch mehr Optionen etc.) ...

[swiss]

Ich bin da relativ schmerzfrei. Ich kann mich auch in confluence einarbeiten auch wenn confluence bis auf die Navigation links kein wesentlichen Vorteile hat. Wobei es auch beim Mediawiki Mittel und Wege gäbe. Die beim Mediawiki links angeordnete Navigation kann man auch beliebig editieren und könnte so pro Themenbereich eine Portalseite machen. Das halte ich nicht für wesentlich unübersichtlicher. Wenn man das etwas schlau strukturiert. z.B.

Hauptseite
- Erste Schritte
- Sensoren und Konfiguration
- Plugins (Von den Grundlagen über fertige Plugins einsetzen bis zum selber schreiben)
- Fernzugriff (alles vom einfachen Einrichten bis zu OVPN TUN(<-nur verweis mit Link da Root sonderlocke))

Sonderlösungen mit Root Rechten
- Backup und Restore der wichtigen Wiregatedatein (Und natürlich was unbedingt beachtet werden muss)
- Multiroom mit mpd
- DMX mit dmxd
- e-Bus mit ebusd
- CometVisu <- leider da kein Paket
- DNS Server auf dem WG
- FileServer auf dem WG
- Hilfe zur Selbsthilfe
usw...


Und zusammen mit bluespice, dass gegenüber confluence weder kosten noch Vendorlockin verursacht, wäre dies eine sehr kostengünstige und gute Platform die (sollte das Projekt nicht wie geplant laufen) ohne Probleme und kostenneutral weiter laufen gelassen werden kann (egal ob 1 oder 100 Editoren daran mitarbeiten).

Aber wenn es denn hier soo viele Fans (oder Aktionäre ) von confluence hat, kann ich mich auch darauf einstellen

Ich würde dieses Wiki (egal welche Platform) auch explizit als "Wiregate Community Handbuch" deklarieren. Das bedeutet ja nicht, dass ElabNet nicht auch Input liefern darf. Aber es muss explizit darauf hingewiesen werden dass die Inhalte dieses Wiki trotz Kontrolle keinen Anspruch auf Richtigkeit und/oder Vollständigkeit bieten und die Tipps auf eigene Gefahr ausprobiert werden.