Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5100
|
Hallo, ACHTUNG: Dieser Beitrag soll bitte nicht als Vorwurf an irgend jemanden verstanden werden! Es geht einzig und alleine um eine sachliche Betrachtung der Situation! Danke! Ich mache mir schon jahrelang über das "Getestet"-Tag der Wiki-Artikel Gedanken, wobei mein Ärger darüber von Jahr zu Jahr eher zugenommen hat; und zwar deswegen, weil man sich auf das Getestet-Tag überhaupt nicht verlassen kann und es IMO einige unschöne und IMO sinnlose Nebenwirkungen hat. Ich könnte konkrete Artikel-Beispiele nennen, würde das aber nach Möglichkeit gerne vermeiden, weil das dazu führen könnte, dass sich Personen vorgeführt fühlen. Ich wäre für eine Abschaffung des getestet Tag und stattdessen einer klaren Anzeige im Artikel, wann die letzte vollständige Überarbeitung erfolgt ist. Bei mir führt übrigens das Getestet-Tag mit dazu, dass ich über die Jahre mein Wissen zunehmend weniger von ubuntuusers.de ziehe. Nachteile des Getestet-Tag bzw. Argumente dagegen: Es ist IMO besser, wenn ich als Leser direkt sehen kann, wann ein Artikel das letzte mal vollständig überarbeitet wurde. Denn dann kann ich viel besser einschätzen, ob ich den Artikel zur Problemlösung heranziehen möchte oder doch lieber weiter nach einem aktuelleren Artikel auf einer anderen Plattform suche. Das ist über die Bearbeitungs-Historie zu umständlich und auch nur dann möglich, wenn man angemeldet ist. Das Getestet-Tag verleitet auch eher dazu, sich über die Überarbeitung von Artikeln keine Gedanken zu machen, weil sie ja unter Umständen nach wie vor aktuell erscheinen. Würde ich dagegen direkt sehen, die letzte vollständige Überarbeitung des Artikel liegt z.B. mehr als 5 Jahre zurück, dann denkt man auch eher über eine Überarbeitung nach. Es ist überhaupt nicht objektiv überprüfbar, ob und wie ein Artikel getestet wurde. Auch wenn das hier alles freiwillig ist, finde ich es dem Leser gegenüber unhöflich etwas als (noch) aktuell erscheinen zu lassen, was es aber dann in vielen Fällen nicht ist, was dann dazu führt, dass der Leser einen Artikel brav durcharbeitet aber trotzdem nicht zum versprochenen Ziel gelangt. Dabei wird der Leser auch noch dazu verleitet, den Fehler vergeblich auf seiner Seite suchen zu müssen, weil der Artikel scheinbar mit der eingesetzten Version bei anderen wie dargestellt funktionieren soll. Alte Artikel verschwinden aus dem Wiki, weil sie nicht getestet wurden, obwohl sie vielleicht durchaus noch eine Qualität mitbringen. Vielleicht sind z.B. zwar veraltet, legen aber dafür einen Sachverhalt für Laien sehr verständlich dar. Und last but not least: Eine nicht unerheblich Ressourcenbindung! Dazu mal ein kleines Rechenbeispiel: 7867 Wiki-Artikel, davon ziehe ich mal 20% (großzügig?) ab, die kein Getestet-Tag haben (Übersichtsseiten etc.), bleiben abgerundet 6500 Artikel 6500 Artikel brauchen pro Artikel zum Testen - Achtung sehr knapp bemessen, für den gewissenhaften Test eines eher kurzen Artikels habe ich ca. 20 Minuten gebraucht - 10 Minuten = 65000 Minuten Das sind abgerundet 1083 Stunden Durch 8 Arbeitsstunden am Tag geteilt abgerundet = 135 8-Stunden-Tage Aufgeteilt auf 100 Personen = 1,35 8-Stunden-Tage pro Person = 1 8-Stunden-Tag + 2 Stunden und 48 Minuten pro Person bzw. = 10 Stunden 48 Minuten pro Person
Und das ist noch sehr defensiv gerechnet und berücksichtigt auch nicht, dass es hier Artikel gibt, die aufgrund Ihrer Länge und Verschachtelung kaum gewissenhaft vollständig getestet werden können. Das ganze dann noch zwei mal jährlich. Rechnet man dann noch die auf Leser-Seite vergeblichen Stunden dazu, weil man sich fälschlicherweise auf ein Getestet-Tag verlassen hat, steckt da eine ganze Menge Zeit drin bei konkret eigentlich welchem Nutzen genau? Vorteile des Getestet-Tag bzw. Argumente dafür:
Danke, für Eure Aufmerksamkeit. Bitte sachlich bleiben - ich hoffe selbiges ist mir mit diesem Beitrag selbst einigermaßen gelungen! Falls nein entschuldige ich mich vorauseilend. LG,
Newubunti
|
DJKUhpisse
Supporter, Wikiteam
Anmeldungsdatum: 18. Oktober 2016
Beiträge: 17644
Wohnort: in deinem Browser, hier auf dem Bildschirm
|
Das Getestet-Tag verleitet auch eher dazu, sich über die Überarbeitung von Artikeln keine Gedanken zu machen, weil sie ja unter Umständen nach wie vor aktuell erscheinen.
Spätestens alle 5 Jahre wird ein Artikel vollständig getestet - meist aber alle 2 Jahre, wenn eine LTS-Version rauskommt.
Würde ich dagegen direkt sehen, die letzte vollständige Überarbeitung des Artikel liegt z.B. mehr als 5 Jahre zurück, dann denkt man auch eher über eine Überarbeitung nach.
Darüber könnte man Nachdenken. So in der Art "zuletzt vollständig getestet am xx.xx.xxxx"-
Es ist überhaupt nicht objektiv überprüfbar, ob und wie ein Artikel getestet wurde.
Sofern sich die Tester an die Richtlinie halten, kann man das sehr wohl beurteilen.
https://wiki.ubuntuusers.de/Wiki/FAQ_-_h%C3%A4ufig_gestellte_Fragen/#Wie-testet-man
Alte Artikel verschwinden aus dem Wiki
Nein, diese werden archiviert und können - wenn sie jemand testet und ggf. überarbeitet - wieder ins Wiki übernommen werden.
Vielleicht sind z.B. zwar veraltet, legen aber dafür einen Sachverhalt für Laien sehr verständlich dar.
Das Wiki richtet sich an aktuelle Ubuntu-Versionen, daher werden alte, nicht mehr relevante Informationen aus Artikeln entfernt. Diese sind dann nur noch in den Revisionen zu finden. Wenn ein ganzer Artikel als verwaltet gilt kommt der ins Archiv und kann da noch immer gelesen und ggf. dearchiviert werden. Ich halte das getestet-tag für hilfreich, denn es wird hier klar, für welche Version getestet wurde.
Damit wird auch sichergestellt, dass der Artikel für mindestens eine unterstützte Ubuntu--Version getestet wurde.
|
mubuntuHH
Projektleitung
Anmeldungsdatum: 28. November 2010
Beiträge: 866
Wohnort: Hamburg, Germany
|
Hallo Newbunti, danke für Deine sachliche Kritik. Ich finde den Getestet-Block sehr sinnvoll und er hat sich im Laufe der Jahre im Großen und Ganzen bewährt. Die Unterschiede zur Installation und Benutzung eines Programms unterscheiden sich tw. erheblich. Oder anders gesagt, spielen wir mal durch, gäbe es den Block nicht mehr. Ein typischer Forenthread würde so aussehen: Fragesteller: Die Anleitung funktioniert bei mir nicht! Antwort eines Users: Was funktioniert nicht und welche Ubuntu-Version hast Du? Fragesteller: Bla bla bla und ich nutze Ubuntu 18.04. Antwort: Okay diese Anleitung gilt aber nur für Ubuntu 20.04 Fragesteller: Na toll, warum steht das da nicht?! Habe jetzt 3h versucht, diese Anleitung zu befolgen... Und wie mach ich das jetzt mit Ubuntu 18.04.?? tbc... Ansonsten hast Du da einige valide Kritikpunkte, die wir in der Tat betrachten sollten. Sie ändern aber mMn nichts an der Sinnhaftigkeit des Getestet-Blocks. Wir sollten dann eher überlegen, wie wir die Qualität(skontrolle) verbessern könnten.
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Newubunti schrieb: Das wäre ja theoretisch der getestet-tag. Das Problem ist, dass (trotz vieler Zurücksetzungen durch das Wiki-Team) viele Artikel als getestet markiert werden, ohne dass sie es wirklich sind. Das Problem dabei ist, dass keiner nachvollziehen kann, ob der Artikel nun wirklich getestet wurde oder nicht. Das selbst wäre aber auch bei einem „überarbeitet“-Kennzeichen der Fall. Im Prinzip ändert das also nichts. Wenn du aber so einen Artikel findest, der nicht mehr stimmt, gibt es immer eine verlinkte Diskussion, in der du das ansprechen solltest. Fühlt sich da einer auf den Schlips getreten, dann ist das eben so. Jetzt kommt natürlich ein „aber“: Die Testumgebung spielt eine Rolle, wird aber nicht mit angegeben. Manche testen mit LiveUSB, andere in einer VM — da ist auch nicht klar, welche Repos bspw. aktiviert wurden, etc. Wieder andere testen auf ihrem System — erfahrungsgemäß sind die meisten Ubuntu-Installationen aber verstümmelt durch Fremdquellen, irgendwelche „Tutorialseiten“, so dass auch da keine gemeinsame Basis besteht. Ich verwende bspw. zum Test ein nativ installiertes Kubuntu, alle weiteren Derivate oder das Original (wenn nötig) nur in einer VM. Und ich brauche pro Artikel meistens mehr als einen Arbeitstag, da ich ja jedesmal den Ursprungszustand wiederherstellen muss und nicht immer Bock habe den ganzen Samstag/Sonntag komplett dafür zu verwenden.
Denn dann kann ich viel besser einschätzen, ob ich den Artikel zur Problemlösung heranziehen möchte oder doch lieber weiter nach einem aktuelleren Artikel auf einer anderen Plattform suche. Das ist über die Bearbeitungs-Historie zu umständlich und auch nur dann möglich, wenn man angemeldet ist.
Ein Wiki-Artikel kann natürlich bei der Fehlersuche helfen, dient aber eigentlich dazu einen kurzen Überblick über das beschriebene Programm zu bieten. Wie überall zu lesen ersetzt es nicht das Handbuch in Form einer Manpage oder Online-Dokumentation. Falls es ubuntu-spezifische Probleme gibt, die viele betreffen schreibt das für gewöhnlich jemand in den Artikel. Für Probleme sind aber in erster Linie die Supportforen zuständig.
Das Getestet-Tag verleitet auch eher dazu, sich über die Überarbeitung von Artikeln keine Gedanken zu machen, weil sie ja unter Umständen nach wie vor aktuell erscheinen. Würde ich dagegen direkt sehen, die letzte vollständige Überarbeitung des Artikel liegt z.B. mehr als 5 Jahre zurück, dann denkt man auch eher über eine Überarbeitung nach.
Was sagt dir, wenn ein Artikel über find, vim, Emacs (um mal ein paar Ureinwohner zu nehmen) älter als 2 Jahre ist? Um das abschätzen zu können, müsstest du ja die Historie kennen und wann die letzte wirklich essentielle Änderung eingeflossen ist. Jein. Wenn ein Artikel als getestet markiert wird, bedeutet das, dass der Tester jeden Punkt auf der Liste getestet hat — es sei denn es wird darauf hingewiesen, dass Punkt X,Y oder Z nicht testbar war. Und das ist (s.o.) leider nicht immer der Fall — mal ganz unabhängig von den Systemen auf denen getestet wurde.
Auch wenn das hier alles freiwillig ist, finde ich es dem Leser gegenüber unhöflich etwas als (noch) aktuell erscheinen zu lassen, was es aber dann in vielen Fällen nicht ist, was dann dazu führt, dass der Leser einen Artikel brav durcharbeitet aber trotzdem nicht zum versprochenen Ziel gelangt. Dabei wird der Leser auch noch dazu verleitet, den Fehler vergeblich auf seiner Seite suchen zu müssen, weil der Artikel scheinbar mit der eingesetzten Version bei anderen wie dargestellt funktionieren soll.
Da hätte ich tatsächlich gerne mal konkrete Beispiele, bei welchen Artikeln das so ist und welches Ziel da versprochen wurde.
Alte Artikel verschwinden aus dem Wiki, weil sie nicht getestet wurden, obwohl sie vielleicht durchaus noch eine Qualität mitbringen. Vielleicht sind z.B. zwar veraltet, legen aber dafür einen Sachverhalt für Laien sehr verständlich dar.
Dann sind sie nach wie vor im Archiv auffindbar.
Die Zahlen sind irgendwie unpassend, daher sagt das Ergebnis nichts aus. Dazu kommt die Fluktuation bei Helfenden, wechselndes Interesse und die zunehmend fordernde Nutzerschaft, die sich aber keinen Furz selbst beteiligt. Kurz gesagt: Immer weniger machen mit, die Ansprüche aber steigen und es wird ein Rundum-Sorglos-Paket erwartet. Passt halt nicht zusammen. Noch nicht erwähnt sind dann die ganzen proprietären Pakete wie Skype, VirtualBox, Spotify, usw. bei denen man nie weiß, was die nun genau machen, die aber oftmals durch die steigende Anzahl an Umsteigern für reges Interesse sorgen. Leider bleiben dann die eigentlich relevanten Artikel, die bspw. die Desktopumgebung beschreiben auf der Strecke. Ich kann nicht für andere sprechen und deren Interessengebieten, aber ich merke auch, das kein großes Interesse an den meisten Artikeln aus meinem Wirkungsbereich besteht. Bspw. sind Archiv/Plasma/Aktivitäten seit 1,5 Jahren im Archiv, obwohl das eine der größten Errungenschaften dieser Oberfläche ist. Auch die Steuerung über D-Bus kommt mMn viel zu kurz, dafür wächst die Anzahl an proprietärer Software, die ich persönlich gar nicht im Linuxumfeld haben will. Gut, ich verwende kein Ubuntu, keine der angebotenen Desktopumgebungen und beteilige mich ein wenig (weil ich nicht mehr kann) bei der von mir favorisierten Distribution. Nach deinem Text zu urteilen bin ich ja schön blöd hier so viel Zeit zu verbrennen, obwohl es mir gar nichts bringt. Dazu noch Plasma zu supporten, obwohl ich es kaum noch verwende… Das ist absolut richtig, aber irrelevant. Wenn jeder das beiträgt, was er kann, dann funktioniert das System. Wenn alle nur abgreifen und zu ihrem Vorteil ausschlachten, funktioniert das auch → Siehe Microsoft Windows und Apples OS/X und iOS, ist dann aber seeeeehr weit vom Grundgedanken weg.
|
BillMaier
Supporter
Anmeldungsdatum: 4. Dezember 2008
Beiträge: 6473
|
Hallo, DJKUhpisse schrieb:
Spätestens alle 5 Jahre wird ein Artikel vollständig getestet
Warum?
meist aber alle 2 Jahre, wenn eine LTS-Version rauskommt.
Aus meinen Jahren im Wikiteam weiß ich, dass das leider zunächst Theorie (also Regelung) ist. Ob das zur Praxis wird hängt am einzelnen, der das einträgt. Ist aber durch die Verkleinerung und Auslagerung von Artikeln schon deutlich einfacher und besser geworden. Diese Diskrepanz (also ob das jemand einträgt ohne alles zu testen) wird man aber nicht recht auflösen können. Das Liegt wohl in der Natur des Wiki. Wir haben ja keinen Maintainer pro Artikel. Newubunti schrieb
Würde ich dagegen direkt sehen, die letzte vollständige Überarbeitung des Artikel liegt z.B. mehr als 5 Jahre zurück, dann denkt man auch eher über eine Überarbeitung nach.
Das wäre dann aber das Datum der letzten größeren Überarbeitung (=Baustelle), das muss nicht unbedingt mit dem Testdatum zusammen fallen. Außerdem hat eine Person zum testen meist auch nur eine Ubuntu-Version zur Hand. Fazit: Ich finde die Idee durchaus reizvoll, der getestet-Version ein Datum zu spendieren - ähnlich wie das bereits bei den Howtos gemacht wird. Also z.B.
Event. könnte es auch aussagekräftig sein, dem Artikel ein "letzte große Baustelle/Änderung" oder sowas hinzuzufügen - das könnte der Artikelschreiber bei der Entlassbitte aus der Baustelle aktualisieren. Also ich bin für Box behalten und ggf. etwas anpassen. Gruß BillMaier
|
DJKUhpisse
Supporter, Wikiteam
Anmeldungsdatum: 18. Oktober 2016
Beiträge: 17644
Wohnort: in deinem Browser, hier auf dem Bildschirm
|
BillMaier schrieb: DJKUhpisse schrieb:
Spätestens alle 5 Jahre wird ein Artikel vollständig getestet
Warum?
Weil spätestens dann das getestet-tag für die 5 Jahre alte Version rausfliegt und der als ungetestet gilt. Dann gibt es eine Karenzzeit, wenn in der niemand den Artikel für eine unterstützte Version testet kommt der ins Archiv und gilt damit als veraltet, zumindest mal ungetestet und ggf. für neuere Versionen als fehlerhaft.
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
DJKUhpisse schrieb: Weil spätestens dann das getestet-tag für die 5 Jahre alte Version rausfliegt und der als ungetestet gilt. Dann gibt es eine Karenzzeit, wenn in der niemand den Artikel für eine unterstützte Version testet kommt der ins Archiv und gilt damit als veraltet, zumindest mal ungetestet und ggf. für neuere Versionen als fehlerhaft.
Dazu fällt mir gerade ein, dass es irgendwo™ mal darum ging, dass man 3 Jahre daraus macht, wegen der Derivate (und niemand nur Ubuntu-Programme mit 5 Jahren Support verwendet). Falls das jemand wiederfindet, wäre der Link hier ggf. interessant.
|
tomtomtom
Supporter
Anmeldungsdatum: 22. August 2008
Beiträge: 53584
Wohnort: Berlin
|
BillMaier schrieb: Also z.B.
Das wäre aber blöd, wenn das nur VOR dem Release getestet worden wäre. 😉
|
BillMaier
Supporter
Anmeldungsdatum: 4. Dezember 2008
Beiträge: 6473
|
Hättest du das Datum richtig angeschaut, hättest du entdeckt, dass es gar nicht getestet wäre 😋
|
tomtomtom
Supporter
Anmeldungsdatum: 22. August 2008
Beiträge: 53584
Wohnort: Berlin
|
BillMaier schrieb: Hättest du das Datum richtig angeschaut, hättest du entdeckt, dass es gar nicht getestet wäre 😋
Du meinst Das Tagesschau-Video hier ist ein Fake? SKANDAL! 😉
|
Newubunti
(Themenstarter)
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5100
|
BillMaier schrieb: Nein, dass hatte ich nicht gemeint bzw. klingt es in Deinem Beispiel hier eigentlich auch nur wie ein aufgepepptes "Getestet-Tag".
Event. könnte es auch aussagekräftig sein, dem Artikel ein "letzte große Baustelle/Änderung" oder sowas hinzuzufügen - das könnte der Artikelschreiber bei der Entlassbitte aus der Baustelle aktualisieren.
Genau, das hatte ich mit "letzter vollständiger Überarbeitung" gemeint. Das scheint wohl etwas missverständlich gewesen zu sein. Die Überarbeitung muss also mal mindestens so wesentlich gewesen sein, dass der Artikel dafür in der Baustelle war. Zumindest ich teste Artikel dann bei Baustellenüberarbeitung auch immer vollständig und gewissenhaft. Außerdem besteht da wenigstens einigermaßen die Möglichkeit, dass auch noch eine zweite Person inhaltlich - formal kann man sich auf das Wiki-Team, die damit Ihre Aufgabe ja gänzlich erfüllen nach meiner Erfahrung verlassen - gegen liest. Ich hätte auch kein Problem damit, wenn das Getestet-Tag - auch wenn es für mich praktisch den Zweck den es theoretisch erfüllen will nicht erfüllt - dann bleibt. Also es geht mir nicht um ein Abschaffen in erster Linie. ChickenLipsRfun2eat schrieb: Newubunti schrieb: Das wäre ja theoretisch der getestet-tag.
Nein, da habe ich mich zu undeutlich ausgedrückt, siehe in diesem Beitrag oben meine Antwort zum Vorschlag von BillMaier.
Das Problem ist, dass (trotz vieler Zurücksetzungen durch das Wiki-Team) viele Artikel als getestet markiert werden, ohne dass sie es wirklich sind. Das Problem dabei ist, dass keiner nachvollziehen kann, ob der Artikel nun wirklich getestet wurde oder nicht.
Deswegen wäre ja die Frage, ob man es dann nicht auch ganz abschaffen kann.
Das selbst wäre aber auch bei einem „überarbeitet“-Kennzeichen der Fall.
Naja, Garantien gibt es keine. Aber im Rahmen der Überarbeitung in der Baustelle, erhöht sich die Wahrscheinlichkeit, dass auch ein weiteres Augenpaar noch mal über den Artikel schaut schon. Jedenfalls im Vergleich zum reinen Testen.
Was sagt dir, wenn ein Artikel über find, vim, Emacs (um mal ein paar Ureinwohner zu nehmen) älter als 2 Jahre ist? Um das abschätzen zu können, müsstest du ja die Historie kennen und wann die letzte wirklich essentielle Änderung eingeflossen ist.
Ja einerseits, aber andererseits steigt mit zunehmenden Alter des Artikels die Wahrscheinlichkeit, dass er nicht mehr (vollständig) funktioniert. Und um dieses Alter beurteilen zu können, sagt das Datum der letzten Baustelle für mich mehr aus bzw. ist ehrlicher, als ein unzuverlässiges "Getestet Tag". Ich muss ja nicht darauf hinweisen, dass hier zum Testen halbjährlich aufgerufen wird und werden muss. Sprich es ist eine (lästige) wiederkehrende Pflichtaufgabe. Das ist erfahrungsgemäß keine sehr gute Grundlage, für eine gewissenhafte Abarbeitung in der Breite. Ja, es kommt natürlich auch auf den Tester an, aber im Großen und Ganzen ist es so.
Jein. Wenn ein Artikel als getestet markiert wird, bedeutet das, dass der Tester jeden Punkt auf der Liste getestet hat — es sei denn es wird darauf hingewiesen, dass Punkt X,Y oder Z nicht testbar war. Und das ist (s.o.) leider nicht immer der Fall — mal ganz unabhängig von den Systemen auf denen getestet wurde.
Ok, da habe ich mich auch schlecht ausgedrückt. Es ist grundsätzlich schon objektiv überprüfbar, aber eben nur indem ich den Artikel selbst gewissenhaft durchprüfe. Für den Leser ist aber anhand des Getestet-Tag nicht erkennbar, ob überhaupt und ob gewissenhaft geprüft wurde. Beziehe ich mich dagegen auf die letzte Überarbeitung in der Baustelle, dann kann man ohne den ganzen Artikel durch testen zu müssen im Vergleich dazu relativ einfach sehen, wie umfangreich die Überarbeitung war - ja, Umfang alleine ist auch kein Qualitätsmerkmal, aber wiederum im Vergleich zum Getestet-Tag ein mehr.
Da hätte ich tatsächlich gerne mal konkrete Beispiele, bei welchen Artikeln das so ist und welches Ziel da versprochen wurde.
Ich stelle hier niemanden ungewollt an den Pranger und habe Dir deshalb zwei Beispiele aus diesem Jahr per PN zukommen lassen. Wenngleich ich nicht ganz verstehe, was das zur Lösung des Problems beitragen soll.
Dann sind sie nach wie vor im Archiv auffindbar.
Nach meiner Erfahrung sind Archiv-Artikel aber über Suchmaschine schwerer auffindbar. Hinzu kommt, dass ein Leser erst mal wissen muss, dass ein Archiv-Artikel unter Umständen mehr oder die gleiche Qualität haben kann, als ein schlecht getesteter. Das ist ja nicht gerade logisch oder selbsterklärend. Archiv verbinde ich eher erst mal mit "verstaubt", also veraltet.
Die Zahlen sind irgendwie unpassend, daher sagt das Ergebnis nichts aus.
Naja, mit den Zahlen wollte ich verdeutlichen, dass selbst bei minimalen Testanforderung schon ein IMO nicht unerheblicher Stundensatz zusammen kommt und das bei einem, wie Du in vielen Punkten selbst schreibst, unverlässlichen Resultat. Würde ich meine eigene Testweise von Artikeln zugrunde legen, würde sich das Resultat um ein vielfaches erhöhen. Danke auch, für Eure sachlichen Antworten! LG,
Newubunti
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Newubunti schrieb: Event. könnte es auch aussagekräftig sein, dem Artikel ein "letzte große Baustelle/Änderung" oder sowas hinzuzufügen - das könnte der Artikelschreiber bei der Entlassbitte aus der Baustelle aktualisieren.
Deswegen erwähnte ich meine drei Beispiele. ls hat „Dieser Artikel ist größtenteils für alle Ubuntu-Versionen gültig.“ als Tag, was eigentlich bedeutet, dass Änderungen gar nicht einfließen. vim ist getestet 18.04. Ob das alles bei der (mittlerweile steinalten) Version wirklich alles so war und funktionierte — keine Ahnung. Der Artikel beinhaltet ja auch Erweiterungen, wie Dateimanager, die da eigentlich™ nicht reingehören. Emacs habe ich verbrochen und ich kann mich erinnern, dass es der reinste Horror war — dazu natürlich wieder eine Auslaufversion, die kaum noch einer verwenden dürfte, der wirklich damit arbeitet. Der lebt von seinem eigenen Paketmanagement und die Pakete gehen selten mehr als eine Hauptversion zurück. Da kommt dann noch Snap dazu…
Genau, das hatte ich mit "letzter vollständiger Überarbeitung" gemeint. Das scheint wohl etwas missverständlich gewesen zu sein.
Nein. Es ändert nur nichts. Ob ein Artikel in eine Baustelle muss oder nicht, liegt daran, ob derjenige, der den Artikel bearbeitet das im Browser macht oder offline (bspw. mit InyokaEdit) und wie umfangreich die Änderungen sind. Umfang sagt aber auch nichts über qualitative Änderungen aus. Das kann auch das Auslagern von Teilen sein. Wenn dann in einem Artikel nur wenig geändert werden muss, weil er bspw. weitgehend noch gültig ist, würde er dir veraltet erscheinen, obwohl er gerade auf den korrekten aktuellen Stand gebracht wurde. Ich sehe da absolut keinen Vorteil, im Gegenteil.
Naja, Garantien gibt es keine. Aber im Rahmen der Überarbeitung in der Baustelle, erhöht sich die Wahrscheinlichkeit, dass auch ein weiteres Augenpaar noch mal über den Artikel schaut schon. Jedenfalls im Vergleich zum reinen Testen.
Wenn du Glück hast, passiert das. Aber dürfte auch eher selten sein. Es prüft keiner noch mal alle Punkte durch, wenn das schon jemand übernimmt.
Ok, da habe ich mich auch schlecht ausgedrückt. Es ist grundsätzlich schon objektiv überprüfbar, aber eben nur indem ich den Artikel selbst gewissenhaft durchprüfe. Für den Leser ist aber anhand des Getestet-Tag nicht erkennbar, ob überhaupt und ob gewissenhaft geprüft wurde.
Das ist er nie. Er trifft aber auch gar nicht unbedingt auf jeden zu. Stichwort Snap, Fremdquellen, systemweite Konfigurationen, …
Beziehe ich mich dagegen auf die letzte Überarbeitung in der Baustelle, dann kann man ohne den ganzen Artikel durch testen zu müssen im Vergleich dazu relativ einfach sehen, wie umfangreich die Überarbeitung war - ja, Umfang alleine ist auch kein Qualitätsmerkmal, aber wiederum im Vergleich zum Getestet-Tag ein mehr.
Wenn ich also einen Artikel besser strukturiere, inhaltlich aber nichts ändere, dann ist er aktueller? Und ich hätte nicht mal nen getestet tag als Info.
Ich stelle hier niemanden ungewollt an den Pranger und habe Dir deshalb zwei Beispiele aus diesem Jahr per PN zukommen lassen. Wenngleich ich nicht ganz verstehe, was das zur Lösung des Problems beitragen soll.
Per PN natürlich nix, außer dass ich mir das „Ausmaß angucken kann. Hier hätten wir anhand konkreter Beispiele durchprobieren können, welchen Unterschied ein Datum / tag gemacht hätte.
Nach meiner Erfahrung sind Archiv-Artikel aber über Suchmaschine schwerer auffindbar. Hinzu kommt, dass ein Leser erst mal wissen muss, dass ein Archiv-Artikel unter Umständen mehr oder die gleiche Qualität haben kann, als ein schlecht getesteter. Das ist ja nicht gerade logisch oder selbsterklärend. Archiv verbinde ich eher erst mal mit "verstaubt", also veraltet.
Was verbindest du mit alten Artikeln, die über 3 Jahre nicht angefasst wurden? Und die Suchmaschinen sollten das schon können. Selbst wenn da nicht „Archiv“ dabeisteht, sollte die hiesige Seite Vorschläge machen. Bspw. Archiv/KDE/Aktivitäten gibt es nicht, es kommt ein Alternativvorschlag mit Plasma.
Die Zahlen sind irgendwie unpassend, daher sagt das Ergebnis nichts aus.
Naja, mit den Zahlen wollte ich verdeutlichen … würde sich das Resultat um ein vielfaches erhöhen.
Klar kommt da ein Haufen Zeit zusammen. Das ist aber kein Grund zu schludern oder möglichst viele Artikel durchzutesten. Wenn sich jeder, der hier einigermaßen regelmäßig reinguckt einen Artikel vornimmt — oder zwei kleine — reicht das ja. Das das nicht so ist, sieht man daran, wie wenige sich beteiligen und wie viele nur erwarten, dass das jemand für sie macht. Das eigentliche Problem ändert sich aber nicht dadurch, dass man eine andere Kennzeichnung einführt oder das Wiki kleiner und nur noch für registrierte Nutzer sichtbar macht. Das ist ein Gesellschaftsproblem, welches wir hier sicher nicht lösen. Wir können nur mit gutem Beispiel voran gehen und mit dem „Deppenstatus“ — im Sinne von „die machen das ja für lau, die Deppen“ — leben und vielleicht in ein, zwei Generationen werden sich einige Umbrüche getan haben und es gibt größere Gemeinschaften, die allgemein so leben. Aktuell gibt es kleine Kommunen mit um die 10 Mann, die so leben, all ihr verdientes Geld in einen Topf werfen und jede größere Anschaffung abstimmen. Das ist so der Ersatz für die früheren Großfamilien, die sich gegenseitig geholfen haben. Mit „Geiz ist geil“ und „Jeder muss alles haben“ kommen wir auf jeden Fall nicht auf ein qualitativ besseres Maß. Egal ob im Wiki oder sonstwo.
|
Newubunti
(Themenstarter)
Anmeldungsdatum: 16. Februar 2008
Beiträge: 5100
|
Ich fasse Eure Argumente mal bisher zusammen: Im Prinzip widerspricht eigentlich keiner in dem Punkt, dass das Getestet-Tag - in der Praxis - mehr oder weniger viele Probleme in sich trägt. Sofern auf meinen Vorschlag mit der Angabe mit dem Datum der letzten vollständigen Überarbeitung anstatt des Getestet-Tag eingegangen wird, wird diesem entgegengehalten, dass er die Inhaltskontrolle genauso wenig oder noch weniger sicherstellen bzw. darstellen kann, wie jetzt das Getestet-Tag.
Nun diese Argument ist zweifelsohne - in weiten Teilen - richtig, allerdings war meine Aussage, dass mir die Datums-Angabe in der Praxis mehr bringen würde, als das Getestet-Tag so gemeint, dass es mir insofern als Leser mehr bringt, als dass es bei mir nicht die Erwartung weckt, mich auf die Richtigkeit des Inhalts verlassen zu können. Denn: Die Aussage "Dieser Artikel wurde für die folgenden Ubuntu-Versionen getestet: ..." ist ein dem Leser von der Community entgegengebrachtes Versprechen - ob das tatsächlich in vollem Umfang so gewollt ist, spielt dabei keine Rolle. Also verlasse ich mich als Leser auch erst mal darauf. Was kein Problem ist, solange der Artikel seinem Inhalt nach korrekt ist. Es ist aber in dem Moment ein Problem, wo das gemachte Versprechen, dem falschen Inhalt entgegensteht, denn ich erwarte ja aufgrund des Versprechens korrekten/funktionierenden Inhalt. Diese Art der Kennzeichnung ist also für den Leser mal mindestens verwirrend. Dagegen wäre eine Kennzeichnung "Dieser Artikel wurde das letzte mal am ... vollständig überarbeitet" eine rein informative Aussage, die dem Leser ja nichts verspricht. Dementsprechend bin ich als Leser weniger überrascht, wenn der Artikel nicht funktioniert und verschwende demzufolge dann auch weniger Zeit damit, den Fehler bei der eigenen Vorgehensweise zu suchen.
D.h. "bringt mir mehr", war hier im Sinne von "weniger ist in diesem Fall mehr" zu verstehen. ChickenLipsRfun2eat hat ja in seinen Beiträgen - unter anderem - schön dargestellt, welche Unwägbarkeiten das Testen mit sich bringt. Alleine diese Unwägbarkeiten wären für mich persönlich schon Grund genug, die Getestet-Box abzuschaffen. Es erwartet ja eingentlich in der Breite der Leserschaft - Ausnahmen bestätigen die Regel - keine stets fehlerfreien Artikeln, mögen solche auch für alle Beteiligten wünschenswert sein. Die Community gibt aber ohne Zwang von sich aus dieses Versprechen, das angepasst an die tatsächlich Gegebenheiten - für die niemand etwas kann - in vielen Fällen so lauten müsste:
Dieser Artikel wurden von mindestens einer und mit an Sicherheit grenzender Wahrscheinlichkeit auch von höchstens einer Person - von der wir nicht sagen können über welche Hardware sie verfügt, welches System sie einsetzt, welchen Kenntnisstand sie hat und nach welchen Kriterien sie vorgegangen ist - mehr oder weniger gewissenhaft für die folgenden Ubuntu-Versionen getestet. Berücksichtige dabei bitte auch, dass seit dem Zeitpunkt des Tests inhaltliche Änderungen eingeflossen sein könnten, so dass die Testzusage nicht oder nicht mehr vollständig gilt: 18.04, 20.4
Dies wäre eine ehrliche Darstellung des Sachverhalts und rechnet man jetzt den von mir im Eingangsbeitrag dargelegten Zeitaufwand dagegen, macht das die Betrachtung nicht besser. Müsste man die Tester bezahlen, wäre das ein sehr lausiges Kosten- Nutzenverhältnis. Und ja, es gibt hier auch sicher sehr viele Artikel, bei denen das Kosten- Nutzenverhältnis viel stärker Richtung Nutzen ausschlägt. Aber die Gesamtbilanz kann IMO nicht besonders sein. Mir geht es also nicht um mehr bzw. bessere Inhaltskontrolle. Es wäre auch vermessen und praktisch letztlich unmöglich diese einzufordern. Mir geht es darum, dass sich die Community vor sich selbst so ehrlich macht, dass man hier faktisch nur ein sehr vages Versprechen abgeben kann und dafür erhebliche - aber praktische eigentlich viel zu knappe - Ressourcen nicht völlig aber relativ sinnlos einsetzt. Die Community würde an dieser stellt zeitlich entlastet und frei werdende Ressourcen könnten zielgerichteter in die tatsächliche Artikelqualität investiert werden. Damit auch das nicht missverstanden wird: Das Testen an sich, ist natürlich - wenn auch nicht in der bisherigen Häufigkeit - richtig. Aber daraus ein Versprechen an den Leser abzuleiten ist unter den gegebenen Voraussetzungen das Problem.
Wäre es aber dann nicht sinnvoller bei den betroffenen Artikeln auf Versionsunterschiede hinzuweisen, was ja inhaltlich im Prinzip - zumindest bei einigen Artikeln, den Gesamtüberblick habe ich da nicht - im Prinzip jetzt schon der Fall ist. Eine Kennzeichnung wie z.B. "Achtung Versionsunterschiede" würde diesem Punkt ja auch Rechnung tragen ohne dabei für die Richtigkeit des Inhaltes einzustehen? D.h. die Grundannahme wäre, solange nicht explizit eine Kennzeichnung vorliegt, gelten Artikel für alle Versionen. Das wäre IMO effizienter zu handhaben. Danke! LG,
Newubnti
|
BillMaier
Supporter
Anmeldungsdatum: 4. Dezember 2008
Beiträge: 6473
|
Hallo, ich kann deine Argumente zu einem größeren Teil nachvollziehen, will aber dem daraus abgeleiteten Fazit dennoch widersprechen. Und zwar durch meine Erfahrungen aus der Praxis: 1. Es ist tatsächlich ein Unterschied, ob da eine Box mit einer Version steht oder nicht. Und zwar zuallermindest in seinem Umkehrschluss: Wenn da steht (nur) für 18.04 getestet, werde ich bei meinem 20.04 schon etwas genauer hinschauen, was sich ggf. geändert haben könnte. Und: Wenn ein Artikel den ungetestet-Status hat, muss ich davon ausgehen, dass er sich nicht mehr 1:1 übertragen lässt. War bei mir bisher (fast) immer so. 2. Ich habe in den letzten 10 Jahren kaum (oder keinen?) Artikel gefunden, die bei mir nicht "funktioniert" haben - d.h. bei aller Schwäche des Systems haben wir bei uu m.E. eine sehr gute Qualität der Artikel. Dazu muss man ja auch sagen, dass die Wikiartikel eben nicht wie ein Howto aufgebaut sind. Das heißt, man muss schon etwas mitdenken und kann nicht stumpf copy-pasten. Wenn dann mal etwas nicht funktioniert hat, lag es in der Regel daran, dass ich etwas falsch (oder nicht) verstanden habe, etwas missverständlich formuliert war oder mein System eine Konfiguration hatte, die nicht zum Artikel passte. Da kann der Artikel aber nichts dafür (und auch nicht die Getestet-Box). (Selten war es auch nur ein Tippfehler im Artikel, da würde aber gar keine Box helfen, sondern eig. nur 4-Augen-Prinzip beim Testen. Aber, da sind wir uns glaub ich einig, das können wir ignorieren) 3. In meiner Zeit im Wikiteam sah ich das etwas ambivalent: Einerseits sollte und wollte ich das Wiki "aufräumen" (also ungetestete Artikel archivieren), andererseits tat es mir immer weh, "so viele" Artikel ins Archiv zu schieben. Ich habe aus dieser Erinnerung gestern mal die Liste in Archiv überflogen. Fazit: Der ganz, ganz, ganz große Teil ist einfach "alter Scheiß"*) → ich glaube wir haben alles richtig gemacht 😉 Man könnte nun das ganze System hinterfragen - andere Systeme arbeiten mit Votings, Sternchen etc etc. Ich bezweifle, dass das helfen würde und dass es das braucht. Zwei Gedanken nehme ich aus deinen Argumenten mit, die ich spannend finde: Den Test-Termin transparent zu halten. Wann wurde der Artikel mit welcher Version getestet? Wann wurde der Artikel zuletzt bearbeitet - und/oder einer größeren Änderung unterzogen?
Wenn ich diese Termine in Relation sehe, kann das aussagekräftig werden. Muss aber nicht. Und um noch was in den Brainstorming-Ring zu werfen: Man könnte, wie beim Howto, auch dazu schreiben, wer den Artikel getestet hat. Gegenargument wäre vielleicht, dass hier Support-Anfragen bei dem User eintrudeln, gerade wenn etwas nicht funktioniert. Ein Argument dafür wäre eine Würdigung der Artikel-Tester und ein Anreiz, gut zu testen. Das ist wahrlich kein kleiner Job. Wenn deine Erfahrung bei uu dir dann zeigt, dass das getestet-Flag von zuverlässig mehr gilt als von schlamper, hilft das auch. Und wenn sich das taggen lässt, könnte das Wikiteam das sogar ein bisschen auswerten und reagieren (z.B. in Wiki/Neue Artikel getestete Artikel mit Tester übernehmen, die Schlamper anschreiben, Voting für die besten Tester veranstalten ... 😀 ) Soweit meine 7 Cents. Danke füs Mitdenken und Einbringen hier! BillMaier *) nach deinem ausführlichen Prolog im ersten Beitrag sei hier darauf hingewiesen, dass das keine Wertung gegenüber den Artikeln oder gar Artikelschreibern sein soll. (Ich habe die Artikel selbst nicht gelesen.) Ich beziehe mich nur auf den Inhalt, der hier behandelt wird - und den gibt es halt oft schon gar nicht mehr ... EDITED: zwei Abschnitte habe ich nachträglich etwas präzisiert.
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Ich sehe das ein wenig anders. Ich würde kein (up-/down-)voting wollen. Zum einen verschreckt das Nutzer, die vielleicht sprachlich nicht so gewandt, inhaltlich nicht so sicher oder anderweitig leicht zu verunsichern sind, zum anderen führt das zum üblichen Die-Anderen-Sind-Schuld-Voting. Sprich, egal was im Artikel nicht stimmt — oder der Leser falsch gemacht hat — es folgt ein Downvote. Das wertet Artikel zu komplexeren Themen ab und die eher How-To-Like strukturierten auf. Damit würde das Wiki aber weg vom Wiki entwickeln und mehr ein „gemeinschaftliches Blog-HowTo“ werden — es will ja jeder gut dastehen mit seinen Artikeln. [zynismus-mode] Wohin eine solche Arbeitsweise führt sieht man ja an den vielen wundervoll über „Tutorials“ eingerichteten root-Servern, die natürlich absolut nichts mit der größten Botnetzmacht, die je gemessen wurde, zusammenhängt.
[/zynismus-mode] Die meisten Artikel (hab schon einige gelesen über die Jahre) sind aber wirklich gute Einstiege in ein Thema. Mehr sollen sie auch nicht sein! Und wie BillMaier schon schrieb: …man muss schon etwas mitdenken und kann nicht stumpf copy-pasten…
Ein Wiki-Artikel ist ein Einstieg. Eine verständliche Übersicht, was ein Programm zu leisten vermag. Es ist keine vollständige Handbuch-Übersetzung und auch keine Schritt-Für-Schritt-Anleitung, auch wenn in vielen Artikeln Beispiele zur Verdeutlichung verwendet werden. Diese sollen aber in erster Linie beim Verstehen helfen, keine copy/paste-Vorlage sein, die einem das Einlesen und Denken abnimmt. Dazu kommt: Die Bearbeiter werden im Wochenrückblick namentlich erwähnt, was auch gut und richtig ist. Einen Wettstreit, wer jetzt in welchem Artikel oben steht, würde ich vermeiden wollen. Es ist ein Gemeinschaftsprojekt und in einer Gemeinschaft sind alle ein Teil davon. Einzelleistungen zu sehr loben führt dazu, dass es Revierkämpfe gibt. Schaut man sich die Bewertung und die Diskussionen um den völlig belanglosen Beitragszähler an, möge man sich das selbst auf Wiki-Artikel hochrechnen. Da werden auch oft Quantitat und Qualität verwechselt. Nur weil ich 3000 Beiträge mehr geschrieben habe, als XY, bedeutet das nicht, dass ich mehr weiß, besser bin oder ein tiefgehenderes Verständnis habe. Es bedeutet, ich habe 3000 Beiträge mehr geschrieben. Ich habe Verständnis für die Ideen, etc., ich bin ja ebenfalls im preußischen Schulsystem herangezogen worden. Im Sinne der den Linux begleitenden Philosophien ist es aber nicht. Nochmal zu Getestet vs. „Letzte große Änderung“:
Getestet bedeutet, es läuft unter *buntu [Version]. Das sehe ich zunächst mal ohne Detailfragen. Wenn es dann also nicht wie im Artikel beschrieben läuft, muss ich als Nutzer rausfinden, ob ich mein System vorher so geändert habe, dass es nicht funktionieren konnte oder ob der Artikel auf einem so veränderten System gestestet wurde, dass es nicht passt — oder schlichtweg einer nur geguckt hat, ob das Paket noch in den Quellen ist und einfach getestet reinschreibt, damit er beigetragen hat.
Bei der letzten Änderung muss ich zwingend nachgucken: Was geändert wurde (Inhalt, Zusammenstellung, Formatierung, Artikel aufgeteilt/zusammengeführt), ob die von mir verwendete Version darin irgendwo erfasst wurde, etc. Ich sehe also nichts auf den ersten Blick. Dazu kommt, dass kleine aber wichtige Änderungen, wie ein Einzeiler oder eine Befehlsanpassung keine Überarbeitung sind und daher untergehen. Macht man eine „letzte wichtige Änderung“ draus, wird vermutlich jede Änderung wichtig, weil sie sonst nicht getätigt wurde.
Ich sehe also die Änderungsinfo nicht als sinnvolle Alternative für das Getestet-tag an. Das Datum der letzten Bearbeitung steht auch schon unten auf der Seite, es müsste also eine sinnvoll und für alle Artikel festlegbare Anforderung für ein solches Datum geben. Das letzte Mal in einer Baustelle gewesen halte ich für ungeeignet.
|