Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
Ankündigung
Einklappen
Keine Ankündigung bisher.
Das Wiregate und die Dokumentation - Confluence Server BEREIT
im confluence gibt es genügend exporte, im eigenen xml format für den import in andere confluence installationen, gibt aber auch genug export plugins wie docBook etc.
Also den Content aus Confluence rausbekommen ist kein Problem.
Du hast bei Confluence 'ne (vollständig dokumentierte) REST/JSON-API (alternativ Webservice/Soap), über die du an allen Content rankommst. Da muss keiner ins DB-Schema gucken.
Die Confluence-Seiten selber sind 90% HTML, dazu noch ein paar Custom-XML-Tags für die Spezialfeatures/Makros (wie "Seiteninhaltsverzeichnis generieren" / "Als SourceCode rendern").
Den Seitenquelltext kann sich jeder in der Demoinstanz angucken (rechts oben auf jeder Seite gibt es Extra->Seitenquelltext anzeigen).
Wem Rest-API zu kompliziert ist - Confluence unterstützt auch das WebDAV Protokoll - damit kann der gesamte Confluence-Inhalt als Ordnerstruktur im Windows-Explorer eingeblendet werden. Jede Seite eine *.txt Datei, jedes Attachment in Unterordnern ... hier ein Screenshot, wie das aussehen würde: https://confluence.atlassian.com/dow...1316996&api=v2
Darauf kannst mit beliebigen Scripting Tools zugreifen.
Aber mal ganz ehrlich: egal wie einfach es ist, den Content strukturiert wieder aus dem Wiki zu bekommen => wohin damit?
Probiert mal Media-Wiki auf irgendeine andere Plattform zu portieren, die Probleme liegen doch wo ganz anders (z.B. Markup konvertieren, dass es auf der neuen Plattform auch funktioniert).
Also haben wir hier eher ein Wiki-Lock-In als ein Vendor-Lock-In.
Auch ich habe - sowohl als Admin, als auch als User - Confluence und auch Jira in verschiedenen Projekten und Dimensionen zu schätzen gelernt.
Gerade das Konzept der Spaces in Verbindung mit dem Rechtemanagement in Confluence kommt meiner Meinung nach Unternehmen sehr entgegen. Es kann sowohl intern als auch extern genutzt werden und lässt sich - sofern gewünscht - mit Jira für Support und die Entwicklung kombinieren, gerade die Verbindung von Supportfällen mit der KB können reizvoll sein...
Mögliche übergeordnete Struktur:
Offizielle Wiregate Dokumentation
Sichtbarkeit: öffentlich
Autoren: Elaborated Networks GmbH
Community-Dokumentation zum Wiregate
Sichtbarkeit: öffentlich
Autoren: Community
CV-Doku
Sichtbarkeit: öffentlich
Autoren: Community
KB zum Wiregate
Sichtbarkeit: intern
Autoren: Elaborated Networks GmbH
Bei dieser extremsten Form der Nutzung wäre zu klären ob der BusinessCase und die Kosten passen und ob man diesen Weg gehen will...
Exporte, WebDAV, REST-Schnittstelle usw. sind auch wichtige und gute Features für den Betreiber, für den User sind aber die Navigation, die Suche und der Editor wichtig. In diesen drei Punkten ist Confluence mein Favorit, während Wikimedia bei mir eher als Informations-Bermuda-Dreieck rangiert: reinkippen und nicht mehr finden.
Ich denke, die Frage verdichtet sich im Moment stark auf die Lizenzkosten. Wenn wir darin auch unsere (kommerziellen) Sensoren und Hardware beschreiben, läßt sich vermutlich keine Open-Source-Lizenz mehr bekommen. Das müsste man mal herausfinden wie sich das genau verhält.
Und, wie ist das zum Beispiel bei einem inaktiven Autor, muss dafür auch noch ein ¨Seat¨ weiterhin - auf Jahre - bezahlt werden, weil einer einmal was geschrieben hat? Also wie wird gezählt?
Nach allem was ich bisher gelesen habe, wird Confluence eher im IntraNet der Firmen eingesetzt, bei öffentlichen Wikis wird MediaWiki verwendet, weil dafür besser geeignet? Bekämen wir ein Problem mit Confluence wenn es im allseits zugänglichen Internet gehostet ist.
Wie verhält es sich mit der Spam-Abwehr? Lässt sich eine externe RADIUS-Authentifizierung der Autoren / Admins einbauen, dann könnten wir den ElabNET Authentifizierungsdienst mit Token (müssten dann eben zugesandt werden) verwenden.
Und wir müssten uns Gedanken machen über eine gewisse Etikette / Stil. Also wie hat etwas auszusehen, Qualitätsmerkmale für einen Artikel, Bewertungs- und Motivationssystem (also wer vergibt die Punkte für einen ElabNET Gutschein / Rabatt etc.), Nachverfolgung von Artikleln mit Fehlern.
Auf jeden Fall: Ich freue mich schon drauf, das wäre etwas, wo viele WG-Anwender schon lange drauf gewartet haben.
Und, wie ist das zum Beispiel bei einem inaktiven Autor, muss dafür auch noch ein ¨Seat¨ weiterhin - auf Jahre - bezahlt werden, weil einer einmal was geschrieben hat? Also wie wird gezählt?
Inaktive User/Autoren können deaktiviert werden und werden nicht gezählt, weitere Informationen liefert Atlassian.
Nach allem was ich bisher gelesen habe, wird Confluence eher im IntraNet der Firmen eingesetzt, bei öffentlichen Wikis wird MediaWiki verwendet, weil dafür besser geeignet?
Ich denke es ist weniger eine Frage der Eignung, sondern der Zielgruppen und deren Verwendung im Zusammenhang mit den Kosten. In meinen letzten Projekten wurde Confluence von größeren Firmen für interne Dokumentationen verwendet, sei es die fachliche und auch technische Dokumentation für ein Projekt mit bis zu 400 Mitarbeitern oder als KB für die e-Commerce Abteilungen. Da in diesen Fällen auch entsprechende Details enthalten waren, wurden sie intern hinter der FW platziert.
Wie verhält es sich mit der Spam-Abwehr? Lässt sich eine externe RADIUS-Authentifizierung der Autoren / Admins einbauen, dann könnten wir den ElabNET Authentifizierungsdienst mit Token (müssten dann eben zugesandt werden) verwenden.
Plug'n'Play bin ich mir nicht sicher, einbauen könnte man es, hier wären im Zweifelsfall die Kosten wieder die Frage...
Wir authentifizieren unsere User gegen das Firmen-AD, halt LDAP. Die entsprechenden User werden dann in das eigene Confluence-Directory synchronisiert, das liegt aber eher an unser kruden AD-Verwaltung sowie den vielen verschiedenen, applikationsspezifischen Gruppen. Anonymer Access ist auch möglich, die können aber nur lesen oder kommentieren (kann man aber in den Permissions definieren).
Das ganze läuft per SSL nur im Firmennetz, von außen ist halt VPN notwendig.
Müsste da selber erst mal reinschauen was da für weitere Optionen möglich sind...
Hmm, ich hab gerade noch einmal die Lizenzbedingungen angeschaut, wenn ich das richtig sehen ist eine kostenlose OpenSource-Lizenz nur für OnDemand verfügbar...
Wenn also bei Stefan lokal installiert dann werden definitiv Lizenzkosten fällig!
Nach allem was ich bisher gelesen habe, wird Confluence eher im IntraNet der Firmen eingesetzt, bei öffentlichen Wikis wird MediaWiki verwendet, weil dafür besser geeignet? Bekämen wir ein Problem mit Confluence wenn es im allseits zugänglichen Internet gehostet ist.
Confluence wird auch stark im Internet eingesetzt. Das ganze OnDemand Angebot von Atlassian z.B., die Doku von Atlassian selber.
Die Basis-Spam Abwehr findet in Form von Captchas statt (muss aktiviert werden). Z.B. bei der Registrierung von Accounts oder beim anonymen Zugriff beim Schreiben von Kommentaren.
In Atlassians Dokumentation ist z.B. das anonyme Schreiben von Kommentaren auch aktiviert - scheint zu funktionieren.
Sollte das nicht reichen, muss der anonyme Schreibzugriff abgeschaltet werden. User können sich dann entweder selbst registrieren (Admin bekommt nur Info-Mail) alternativ nur per Einladung einen Account bekommen.
Ich würde auf jeden Fall die OpenSource Variante versuchen. Für die internen Firmengeschichten kann man ja dann immer noch die 10$-Spende-10-User-Lizenz parallel installieren.
Ich habe mit mal die Form angesehen, schon raffiniert, man muss erst alles komplett installieren und nach außen freischalten, bevor man die Form absenden darf. Wenn man dann die Open-Source-Lizenz nicht bekommt, hatte man schon soviel Aufwand, dass man dann doch die Lizenz kauft. :-)
Solange die Anzahl der Autoren nicht überhand nehmen, denke ich, läßt sich die Lizenz auch bezahlen. Schließlich sollte dies am Ende unseren Suportaufwand verringern und das ein oder andere WireGate mehr verkaufen helfen.
Eine andere Frage die sich mit stellt: Wir werden vermutlich nicht mit einem Admin auskommen, sondern mehrere benötigen, um zum einen Ordnung zu halten, das Inhaltsverzeichnis gut hinzubekommen als auch die notwendigen administrativen Tasks zu erledigen. Wenn es nun mehrere Admins sind, dann könnten da mehrere Vorstellungen aufeinander prallen, wie bekommen wir eine Einigkeit / Gleichschaltung des Adminteams hin?
- Wie diskutieren wir das aus? Wie stimmt man sich ab (bräuchte man ein eigens Forum dafür).
- Wer prüft auf Einhaltung von rechtlichen Vorgaben (dass uns kein Autor irgendwelche Bilder usw. Einfügt, für die er nicht die Rechte hat).
- Wie erstellen wir überhaupt diese ganzen Vorgaben und Regeln für die Autoren?
- Wer steht denn nun alles als Admin bei einer Confluence-basierten Lösung zur Verfügung?
- Will /soll einer der Chef-Admin sein?
- Wie machen wir ein Bewertungs- und Belohnungssystem für Admins / Autoren. Es soll ja am Ende auch einen Anreiz geben.
Mein Angebot administrativ mit zu helfen steht weiterhin. Mit Confluence habe ich allerdings keine Erfahrung und müsste mich da erst einarbeiten, bin da aber zuversichtlich dies vor meiner Rente zu schaffen.
Ich denke über die ganzen Form und Verfahrensfragen sollte sich ein entstehendes Admin-Team in Absprache mit dir (oder wem auch immer aus eurem Haus) dann im kleinen Kreis abstimmen. (Ich würde ein Kickoff Meeting in der Karibik vorschlagen. )
Chef Admin ist so ne Sache... Finde ich zum einen organisatorisch sinnvoll wenn einer den Hut auf hat, andererseits kann dass, sollte es personell der Falsche sein, bei einem Projekt von Freiwilligen auch nach hinten los gehen... Auch ist es ein undankbarer Job. Ich kenne viele Projekte da ist er/sie (gibts hier eigentlich Vertreter des schöneren Geschlechts?) in der Gefahr derjenige zu sein an dem es hängen bleibt wenn kein anderer etwas bestimmtes machen will.
Durchlauferhitzer ohne eigene Entscheidungskompetenz sollte er natürlich auch nicht sein, dann kann man sich diese Instanz auch einsparen. Da stellt sich dann aber wieder die Frage wie viel Kontrolle du gewillt bist abzugeben und damit ein gewisses Risiko einzugehen.
...
- Wie diskutieren wir das aus? Wie stimmt man sich ab (bräuchte man ein eigens Forum dafür).
- Wer prüft auf Einhaltung von rechtlichen Vorgaben (dass uns kein Autor irgendwelche Bilder usw. Einfügt, für die er nicht die Rechte hat).
- Wie erstellen wir überhaupt diese ganzen Vorgaben und Regeln für die Autoren?
- Wer steht denn nun alles als Admin bei einer Confluence-basierten Lösung zur Verfügung?
- Will /soll einer der Chef-Admin sein?
- Wie machen wir ein Bewertungs- und Belohnungssystem für Admins / Autoren. Es soll ja am Ende auch einen Anreiz geben.
Lg
Stefan
Also ich denke so eine Community Doku lebt von den Freiheiten. Wir können sicher ein paar Grundregeln festlegen, aber ich denke das meiste entwickelt sich ohnehin nach und nach.
Ich würde für die Diskussion primär auf die Kommentare setzen. Ein zB Unterforum auf knx-usr-forum wäre aus meiner Sicht etwas übertrieben. Eventuell stellt confluencedafürwas zur Verfügung?
Ich würde als Admin mitwirken, allerdings nur in redaktioneller Form, nicht IT (Themen strukturieren, Layout überarbeiten, Übersetzen, ev. Aufgaben verteilen).
Als Chef Admin kommt ohnehin nur Stefan in Frage, außer elabnet wirkt nur mit ohne jegliche Gewährleistung = reine Community Doku.
Bez. Belohnungssystem: Frei nach dem Motto: Wer zahlt schafft an.
Ich weiß nicht ob confluence irgendwelche logs zur Verfügung stellt, wie Anzahl edits/user je Zeitraum, ...
Bez. rechtlichen Vorgaben tu ich mir noch schwer. Was schwebt dir vor Stefan? Community doku von elabnet gehostet aber ohne Gewähr, oder offizielle WG doku community supported?
Gefühlsmäßig würde ich hier auf allgemeine Wachsamkeit aller Admins setzen.
Wer istden zB für das knx-user-forum rechtl. verantwortlich?
Ich würde für die Diskussion primär auf die Kommentare setzen. Ein zB Unterforum auf knx-usr-forum wäre aus meiner Sicht etwas übertrieben. Eventuell stellt confluencedafürwas zur Verfügung?
Ich dachte nur an etwas für die Abstimmung der Admins. Ein Unterforum wollte ich deswegen nicht, auch wollen wir das KNXUF nicht überbeanspruchen. Bei einer Handvoll Admins geht das auch per eMail und vielleicht einer initialen Telco / Treffen.
Ich würde als Admin mitwirken, allerdings nur in redaktioneller Form, nicht IT (Themen strukturieren, Layout überarbeiten, Übersetzen, ev. Aufgaben verteilen).
Sehr gerne, wir freuen uns über jeden Mitstreiter.
Als Chef Admin kommt ohnehin nur Stefan in Frage, außer elabnet wirkt nur mit ohne jegliche Gewährleistung = reine Community Doku.
Danke für die Blumen. Aber ich habe keine Kenntnisse über Confluence, als Chef muss man sich auch auskennen, das tue ich in Confluence nicht. Ich suche daher jemanden, der letztlich bestimmt, WIE die ein oder andere Einstellung zu treffen ist. Oder ich lerne es eben entsprechend, aber ich glaube, hier gibt es schon Wissen zu finden dafür. Hannatz?
Bez. Belohnungssystem: Frei nach dem Motto: Wer zahlt schafft an.
Schon, aber vielleicht hat ja einer einen Vorschlag, der als funktionierend und schlank bekannt ist. Weil bei sowas muss man immer darauf achten, dass es nicht ungerecht ist.
Moderne Wikis haben aber Rückmelde bzw. I Like Zähler, die eine Bewertung von Artikeln durch die Anwender zulassen. Allerdings ist dies, wie hier im Forum zu sehen, nicht gerecht, weil es wird rein emotional geurteilt. Du kannst Dir hier ohne weiteres die Finger wund tippen und bekommst kein einziges Lob, nur wenn Du etwas überaus herausragendes schreibst und fünf Stunden drangesessen bist, bekommst mal einen Punkt oder so. Aber wehe du schimpfst mal mit einem User, dann mischen sich nicht nur ein halbes Dutzend anderer ein, sondern bekommst sofort Strafabzug. Steht in keinem Verhältnis.
Darum war ich auf der Suche nach einem gerechten System.
Bez. rechtlichen Vorgaben tu ich mir noch schwer. Was schwebt dir vor Stefan? Community doku von elabnet gehostet aber ohne Gewähr, oder offizielle WG doku community supported?
Mir schwebt die one and only ¨offizielle ElabNET Wiregate Doku - driven by the Community and ElabNET¨ vor. Also von unserer Seite sollte es dann auch zu allem was mal ein Supportfall verursacht hat, einen entsprechenden KnowledgeBase Artikel geben. Zu jedem bekannten Fehler eine Fehlerbeschreibung (und wann und wo es gefixed wurde), zu jedem Relase eine Info. Wir können das nicht in der Qualität a la Microsoft schaffen, weil wir einfach das Geld nicht haben dafür, aber wenn wir nur 1/10 dessen, was wir hier ins Forum schreiben, noch in das Wiki kopieren oder gleich als Wiki-Artikel verfassen und dann im Forum einen Link drauf einstellen, wäre auf Dauer sehr geholfen.
Das steht und fällt am Ende aber mit der Auffindbarkeit und das brauch eine harte Hand.
Ich möchte auch gerne die Plugins und deren Beschreibung im Wiki haben, weil sonst geht zuviel unter.
Zu den Super-Plugins wie emax Zeitschaltuhr oder FRYs Logikprozessor könnte man eine eigene Artikelserie anlegen.
Das braucht aber alles dringed Struktur und diese braucht die Admins.
Die rechtliche Verantwortung macht mir weniger Sorgen. Einfach niemanden verunglimpfen, Warenzeichen beachten, keine unrechtmäßigen Kopien zulassen und keine falschen Tatsachenbehauptungen abgeben, dürfte schon 4/5 der Miete ausmachen.
Also ich wäre dabei!! Ob nun zwei oder drei Confluence-Instanzen ist dann auch egal...
Ne Kick-Off Telko mit dem zukünftigen Admin-Team wäre super, am besten mit ner kurzen Einführung in das System verbunden. Dann könnte man auch ne initiale Struktur sprechen und entsprechende "Abschnitt-Admins" festlegen (je nach Fachwissen und Interesse).
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
)
Kommentar