yaVDR-Dokumentation verbessern: Wer macht mit?

Quote

Original von steffen_b
Aus rein praktischen Beweggründen, sollte zuerst geklärt werden, wie das ungefähr aussehen soll, Ziele , Form, wenn das geklärt ist, welches Tool man verwendet. Wenn das geklärt ist, müssen wir zusehen das wir schnellstmöglich die technische Basis liefern können, damit dann jeder der Lust hat und fähig ist, loslegen kann.

Sollte es mal dazu nen IRC Chat o.ä geben um zu diskutieren, sagt mir bescheid. Würde meine Ideen auch gern einbringen.
Spätestens beim einpflegen/neugestalten der Seiten

Quote

Original von gda
Allerdings wird hier etwas außer Acht gelassen, dass der Bernie7 schon großes geleistet hat. Auf seiner Homepage wird man fast immer fündig. Auch das Thema, dass ich heute erwähnt habe, kann man dort finden. Er widersetzt sich allerdings unseren Anwerbeversuchen als Hausdokumentierer standhaft.

Danke !

Meine Doku ist immer nur so weit wie mein eigener VDR und meine eigenen Kenntnisse. Sie ist geeignet für User die die gleichen Vorkenntnisse haben wie ich, also etwas Windows und kein Linux.

Meine Kenntnisse in Linux und in geschriebenem Englisch reichen für einen Hausdokumentierer leider nicht aus.

Mit meinen selbst geschriebenen Kunstwerken helfe ich immer gerne aus.

Da die Entwicklung immer weiter geht, passe ich die Kapitel immer nach und nach an die neueste Version an (Installation, Samba etc.). So hat der Anwender eine einigermaßen aktuelle Doku die zu der aktuellen yaVDR Version passt.

Grüße Bernd

Ja, ich bin gestern über's Ziel hinausgeschossen mit meinen Träumereien über ein englisches Forum. Hintergrund: Ich hatte den sehr guten Artikel [1] über Mehrsprachigkeit in Wikis komplett durchgelesen, den Spiff in diesem Thread gepostet hatte. Der Artikel hat meine Sicht auf multilanguage Wikis total umgekrempelt und dann war mein Gehirn in einer unendlichen Theorieschleife gefangen.

Der Artikel hat mir verdeutlicht, dass hinter jeder Sprachfassung eines Wikis eine Community mit dieser Sprache steht und das jede Community freiwillig ihr eigenes Wiki in der eigenen Sprache pflegt, weil sie es als sinnvoll erachtet. Auch gibt es natürlich ein englischsprachiges VDR-Wiki bei linuxtv.org, in das einige Leute hier sehr viel Energie stecken. Das will ich nicht unterschlagen.

Ulf: Ja, im VDR-Wiki ist schon einiges zu yaVDR vorhanden, das ist ausbaufähig, ich habe gestern auch mal den Inhalt von diesem gepinnten Posting aktualisiert: FAQs und andere Doku zu yaVDR

Gruß
hepi

[1] http://moinmo.in/Creating%20mu…is%20and%20wiki%20engines

Es wäre ja schonmal ein Anfang, wenn die Entwickler von Plugins "ihre" Seite im Wiki mal aktuell halten. Wenn man da durch schaut, sind viele Seiten das letzte mal 2007 aktualisiert worden... Manche plugins funktionieren nicht richtig und man hat viel Arbeit sie ans Laufen zu bekommen.

Muss die Änderungen eigentlich ein Moderator freischalten? Wieviele gibt es im Moment?

Grüße

Quote

Original von KlimBim
Es wäre ja schonmal ein Anfang, wenn die Entwickler von Plugins "ihre" Seite im Wiki mal aktuell halten. Wenn man da durch schaut, sind viele Seiten das letzte mal 2007 aktualisiert worden... Manche plugins funktionieren nicht richtig und man hat viel Arbeit sie ans Laufen zu bekommen.

Das ist zwar richtig, hat aber wenig mit dem Thema zu tun. Es gehört nur eine Handvoll Plugins zu yaVDR und meines Wissens nach laufen die alle nach der Installation. Außerdem sind diese Plugins im allgemeinen nicht yaVDR spezifisch.

Gerald

Es gibt für fast alle Bereiche mehrere Orte, wo Dokumentation parallel aktuell gehalten werden muss. Bei VDR-Plugins fallen mir da folgenden Orte ein:

1) Readme-Datei in den Plugin-Sourcen
2) Content auf der Projekt-Website des Plugin-Autoren
3) Announcement einer neuen Plugin-Version im VDR-Portal (man will ja auch spüren, dass die Community benutzt, was man Tolles entwickelt hat, kein anderer Pfad erreicht direkt so viele Leser)
4) Deutsches VDR-Wiki
5) Englisches VDR-Wiki
6) Dokumentation innerhalb der Debian-Pakete

Bei der hohen Anzahl von verschiedenen Stellen, wo man dokumentieren soll, ist es kein Wunder, dass es fast kein Plugin-Autor konsequent durchhält. Und 3) ist die attraktivste Lösung, wenn man auch will, das jemand was von den Änderungen mitbekommt.

Ideal wäre eine möglichst automatisierte Generierung der Dokumentation basierend auf einem strukturierten readme-Dokument oder so, das geparst wird. Bots könnten bestimmte Wikiseiten automatisch aktualisieren und einmal pro Woche die SVNs, GITs, CVSs, etc. der Plugins abklappern und nach aktualisierten Doku-Dateien suchen.

Gruß
hepi

Quote

Original von hepi
Auch gibt es natürlich ein englischsprachiges VDR-Wiki bei linuxtv.org, in das einige Leute hier sehr viel Energie stecken. Das will ich nicht unterschlagen.

Eigentlich stagniert die englischsprachige wiki eher. Ich vermute mal mangels Interesse einerseits, Bekanntheitsgrad andererseits. In den letzten 30 Tagen gab es dort genau eine sinnvolle Änderung.

Quote

Original von KlimBim
Es wäre ja schonmal ein Anfang, wenn die Entwickler von Plugins "ihre" Seite im Wiki mal aktuell halten.

Warum sollte? Der Entwickler braucht Doku in der wiki meist nicht.

Quote

Originally posted by KlimBim
Es wäre ja schonmal ein Anfang, wenn die Entwickler von Plugins "ihre" Seite im Wiki mal aktuell halten. Wenn man da durch schaut, sind viele Seiten das letzte mal 2007 aktualisiert worden... Manche plugins funktionieren nicht richtig und man hat viel Arbeit sie ans Laufen zu bekommen.

Muss die Änderungen eigentlich ein Moderator freischalten? Wieviele gibt es im Moment?

Grüße

Die Developer müssen garnichts, die User könnten, anstatt sich zu beschweren. Warum herrscht hier teilweise die Meinung, das wenn man sich den Arsch aufreisst, sich dazu verpflichtet sich seinen Arsch noch weiter aufzureissen ? Klingt unlogisch für mich

Hier herrscht manchmal ein Ton auf den ich in meiner Freizeit keine Böcke hab.

Ich habe niemals gesagt, dass jemand etwas muss. Es wäre wünschenswert, wenn die Entwickler der plugins die Seite aktuell halten, denn wozu stellen sie die plugins sonst online? Ich denke doch, weil sie sie einer Öffentlichkeit zugänglich machen wollen? Ergo ist eine Dokumentation wünschenswert, weil man sonst einige gar nicht benutzen kann, ohne Programmierkenntnisse
Wie soll ich wissen was jemand in einem update eines plugins "neu" gemacht hat? Wie soll ich also als "user" das Wiki dementsprechend ergänzen?

Und sich hier immer und überall von jedem angegriffen zu fühlen, können manche mal ablegen Ich denke man kann doch noch normal über Sachen diskutieren?

Ich fühle mich nicht angegriffen. Als developer liefere ich ein Changelog, ein README und vielleicht noch ein Announce Mail oder Posting hier. Ich würde nicht einsehen wollen warum man als jemand der Nutzniesser fremder Arbeit ist nicht auch seinen Beitrag leisten kann. Leider bist du nicht alleine.

Ausserdem ist das hier OT. Wenn du es diskutieren willst, gerne, aber nicht in diesem Thread.

Worüber diskutieren wir denn dann?

Quote

Es gibt für fast alle Bereiche mehrere Orte, wo Dokumentation parallel aktuell gehalten werden muss[...]Ideal wäre eine möglichst automatisierte Generierung der Dokumentation.

Das wäre doch die Schnittstelle "Problem" gelöst...

Quote

Original von KlimBim
Es wäre wünschenswert, wenn die Entwickler der plugins die Seite aktuell halten, denn wozu stellen sie die plugins sonst online?

Ich kann zwar nicht wirklich mitreden, weil ich nur ein Plugin geschrieben habe, aber mir ist es Wurst ob es benutzt wird, oder nicht. Ich wollte damit etwas beweisen und jetzt ist es uninteressant.

Es gibt einige Entwickler, mich eingeschlossen, die reagieren empfindlich wenn Andere meinen entscheiden zu dürfen was sie zu tun oder zu lassen haben. Das darf nur mein Chef und ich bekomme ja auch Geld dafür.

Gerald

Quote

Original von Wicky
P.S. Ist eigentlich klar was ich unter einer Guideline verstehe??

Jau Du magst nen mod job im wiki annehmen

Gruß Ulf

Quote

Original von ULF

Jau Du magst nen mod job im wiki annehmen

Gruß Ulf

Meine Zustimmung hat er auch dazu

Wickies Guideline-Entwurf ist ein sehr guter Ausgangspunkt. Ich bin damit wahrscheinlich zu 90% zufrieden, und die 10% Nörgeleien formuliere ich in den nächsten Tagen, falls ich das brauche.

Auch wenn technische Aspekte sicherlich nicht aus schlechtem Content guten Content machen: Einem Mediawiki einfach die semantischen Erweiterungen hinzuzufügen ist kein Teufelszeug, und niemand zwingt die Autoren, auch semantische Features zu benutzen. Der Autor merkt erstmal gar nix davon, dass er sich in einem semantischen Wiki befindet. Man muss nicht jede Seite mit semantischen Meta-Infos anreichern.

Die Chancen eines semantischen Wikis erscheinen mir aber so attraktiv, dass ich mir heute Abend ein MediaWiki+semantische Erweiterungen installiert habe, um es mal zu testen.

Wer immer die URL dazu haben will, um mit mir in einem absolut leeren Wiki zu spielen - im Sinne von yaVDR, schicke mir eine PN mit einer kurzen Begründung, warum er die URL haben will. Ich entscheide mich dann, ob ich die URL weitergebe.

Gruß
hepi

Ich kann meine voherigen Ausführungen mal konkretisieren:

Ich bin relativer noobie was das Linux / Vdr Geschäft angeht. Sollte es mit zu euren "Zielen" gehören, yavdr weit zu verbreiten, muss man auch die noobs einbeziehen, denn keiner hat die Weisheit mit Löffeln gefressen

Für mich heißt das heute konkret: Über das vdrrip plugin auf der yavdr Seite gelesen. Wollte mehr Infos dazu, keine gefunden, also einfach mal installiert. Nun sagt er, er findet keinen codec. Im Inet rumgesucht, wahrscheinlich braucht bei mir mplayer noch einen codec....?
Dann hab ich in den bugtracker geschaut, konnte aber meinen "Fall" noch nicht dokumentiert finden....
Auch wenn es ein plugin ist, das ist ein "Problem" welches durch eine bessere Dokumentation behoben werden könnte. Da könnte dann stehen, dass das plugin in Entwicklung ist, dass dafür das und das gebraucht wird, etc....

Also müsstet ihr mal am Anfang klären, wie schon oft gesagt, für wen ihr yavdr zugänglich machen wollt. Dementsprechend "muss" (Achtung für die leichten Gemüter) / sollte dann auch das Wiki gebastelt werden

Hallo,

KlimBims Aussagen haben mich motiviert, mal wieder in die Tasten zu greifen. Das folgende betrifft eher das Thema VDR-Dokumentation als yaVDR-Dokumentation. Deshalb wird demnächst möglicherweise ein Thread-Split notwendig, wenn sich die folgende Diskussion weiter von einer yaVDR-spezifischen Doku entfernen sollte.

Quote

Original von KlimBim
Wie soll ich wissen was jemand in einem update eines plugins "neu" gemacht hat? Wie soll ich also als "user" das Wiki dementsprechend ergänzen?

Quote

Original von KlimBim
Ich bin relativer noobie was das Linux / Vdr Geschäft angeht. Sollte es mit zu euren "Zielen" gehören, yavdr weit zu verbreiten, muss man auch die noobs einbeziehen, denn keiner hat die Weisheit mit Löffeln gefressen

Eine Grundfrage in Bezug auf Wiki-Dokumentation ist: Wie erfahren muss ein Autor sein, damit es sich lohnt, dass er sein Wissen im Wiki niederschreibt? Soll man Neueinsteiger entmutigen, im Wiki Inhalte hinzufügen? Oder gibt es Wissens-Bereiche, welche fast jeder VDR-Nutzer hat, egal, wie viele Jahre Erfahrung ein Nutzer gesammelt hat mit Linux, mit VDR, mit Plugins, mit XBMC etc. Und ist das Wissen, welches auch für andere VDR-Nutzer interessant ist?
Ich denke:
[list=1]
[*] Ja, solche Art von dokumentationswürdigem Grundwissen hat jeder VDR-User.
[*] Es gibt keine Ausrede für Neueinsteiger, sich zurückzulehen und zu sagen: Dokumentiert mal für mich, ich kann eh nichts beitragen.
[*] Wenn VDR-Entwickler sehen, dass sich viele andere Benutzer engagieren, um zur Dokumentation innerhalb ihrer Möglichkeiten beizutragen, und auch Ihrerseits etwas an die Community geben, werden sie motiviert, weiterhin im Dienste der VDR-Community an Plugins, Addons und Distributionen weiterzuarbeiten.
[/list=1]
Um was für Wissen handelt es sich hier?

Es besteht eigentlich immer ein elementares Wissen über die selbst gekaufte/verwendete Hardware, also Namen und Eigenschaften der Hardware-Komponenten. Dadurch, dass jeder User meist individuell Hardware-Komponenten ausgesucht hat, kann sich aus jedem VDR-User ein Experte für diese spezifische Hardware entwickeln. Und es gibt genug unterschiedliche Produkte, die eingesetzt werden: Hardware-Komponenten-Vielfalt entsteht schon deshalb, weil jeder User ein anderes Budget ansetzt und jeder User je nach Kaufzeitpunkt ein verändertes Hardware-Angebot antrifft. Insofern könnte man sich erhoffen, dass ein möglichst hoher Prozentsatz an yaDR-Nutzern an einer Dokumentation teilnehmen können, indem sie ihre eigenen Hardware-Komponenten dort in der Art eines Datenblattes beschreiben.

Der Schwerpunkt liegt dabei auf den Eigenschaften der Hardwarekomponenten (und Meta-Infos wie URL der Hersteller-Website), und beinhaltet aber meines Erachtens noch gar nicht die Erfahrungen und Probleme damit. Da zur Diagnose und Lösung von Problemen mit diesen Hardware-Komponenten Spezialwissen notwendig ist, das (noch) nicht alle VDR-User haben, wären diese Nutzer möglicherweise damit überfordert, derartige Probleme und ihre Lösung korrekt zu dokumentieren. Ein Problem mit einer bestimmten Hardware sollte nur dann in der Dokumentation an prominenter Stelle auftauchen, wenn gesichert ist, dass mehrere User dieser Hardware das gleiche Problem haben. Und ein Lösungsweg sollte nur dann dokumentiert werden, wenn damit allen Besitzern dieser Hardware-Komponente geholfen worden konnte und möglichst alle mit der Richtigkeit und Nachhaltigkeit des Lösungswegs einverstanden sind.

Das Semantic Media-Wiki bietet die Möglichkeit, für verschiedene Hardware-Komponenten Eingabe-Formulare vor zu definieren, welche das Einpflegen von Hardware-Komponenten erleichtern, so dass ein Wiki-Autor hier noch weniger Wiki-Syntax kennen muss, aber trotzdem Content beitragen kann. Da über die Formulare die neu entstehenden Wiki-Seiten im Bereich Hardware schon automatisch mit semantischen Meta-Informationen versehen werden, kann man dann ohne großen Aufwand automatisch schöne Übersichtstabellen generieren lassen, über welche die Hardware-Datenbank zugänglich wird.

Eine weitere Form von Dokumentation, die unabhängig vom Erfahrungsstand eines Users geschrieben werden kann, wären "User-Tagebücher", wie man sie im easyVDR-Wiki finden kann. Hier kann ein User Tagebuch führen über seinen eigenen Leidens- und Lernprozess mit dem eigenen VDR, mit der Hardware, der Installation der Software und der Konfiguration. Wo der User beschreibt, wie er bestimmte Proleme gelöst hat. Ein Tagebuch hat keinen Anspruch auf Vollständigkeit und Korrektheit, jeder Leser eines Tagebuches muss selbst entscheiden, wie weit er den vom Autor beschriebenen Lösungsansätzen folgen will. Im Grunde genommen ist die von Bernie7 geschriebene Doku so eine Art Tagebuch, nur ist sie nicht nach Datum gegliedert - wie ein Blog, sondern inhaltlich.

Ähnlich wie User-Tagebücher könnte man sich auch vorstellen, dass User unabhängig von Ihrem Wissenstand im Wiki über Aha-Erlebnisse oder über die Euphorie nach der Entdeckung eines neuen Features schreiben können: Kleinigkeiten, Tipps und Tricks, die man bisher nicht kapiert hat oder von denen man bisher noch nie gewusst hat, dass der eigene VDR sie kann. Das wäre in etwa eine Art kurzer Blog-Eintrag, aber im Wiki. (Wenn das denn geht, jeder Eintrag würde wohl wieder eine neue Wiki-Seite sein?)

Inhaltliche Abschnitte eines Tagebuches oder eines Blog-Eintrags kann ein erfahrenerer Wiki-Redakteur aber vielleicht an anderer Stelle im Wiki als Grundlage für eine offizielle Dokumentation weiterverwenden. Oft wird man auch zum Schreiben motiviert, wenn man im Wiki etwas entdeckt, was man für inhaltlich falsch oder ungenügend befindet. Tagebücher von Einsteigern dokumentieren auch, wie Einsteiger vorgehen, und an welchen Stellen sie vermehrt die falschen Entscheidungen treffen, weil ihnen eine Dokumentation fehlt.

Drittens kann prinzipiell jeder User Channel-Scans machen und seine regionalen Kanallisten (channels.conf) im Wiki veröffentlichen und aktuell halten, um anderen Usern den Einstieg zu erleichtern (das ist ja im VDR-Wiki möglich, wird aber recht selten genutzt: http://www.vdr-wiki.de/wiki/in…p/Kategorie:Channels.conf)

Die Attraktivität eines Wikis lebt eigentlich davon, dass man beim Wiki-Besuch überrascht wird davon, dass es seit dem letzten Besuch wieder viele fleißige Autoren gegeben hat, die neuen Content ins Wiki eingefügt haben. Wenn die Liste der letzten Änderungen nicht sichtbar gemacht wird auf der Einstiegsseite des Wikis oder auf der Portal-Einstiegsseite einer Community, merkt man davon nichts, und die Euphorie und Motivation für das Mitschreiben im Wiki schwindet. Gleichzeitig muss Wiki-Content, der vom Autoren ins Forum gepostet wird, umgezogen werden, da er im Forum nicht oft nicht gut genug inhaltlich kategorisiert/abgeheftet werden kann. Jeglicher Content, der vom Autor nicht als Problembeschreibung oder Fragestellung ausformuliert worden ist, ist für eigentlich Wiki-Content und kein Forums-Content, wenn man mal darüber nachdenkt....

Gruß
hepi

Finde ich sehr gut, deine Vorschläge hepi

Vllt. sollte man noch eine Überprüfung durch kundige User einführen? Habe gerade gesehen, dass ja jeder ins wiki schreiben kann. Dementsprechend kann da auch totaler Müll reingeschrieben werden?!