Am Mittwoch, 8. Dezember 2004 16:08 schrieb Ivo Köthnig:
Die glaube die Mischung macht's. Das Hauptproblem ist, dass uns die technischen Hilfsmittel fehlen, um schlechte Autoren zum Umdenken oder Aufhören zu bewegen.
Mittlerweile glaube ich auch, dass es ein Fehler ist Stubs überhaupt zuzulassen. Wie lautet doch die Pro-Stub-Begründung: "Man muss sie wachsen und gedeihen lassen und aus vielen Stubs sind schon exzellente Artikel geworden!". Schön und gut, aber man braucht auch nicht viel Phantasie um das als Stub-Autor umzudeuten in: "Ich mach hier mal ein bisschen, weil ich keinen Bock und keine Zeit habe und die fleißigen Idioten machen für mich den Rest!"
Öhm Hüstel. Ich hatte da bezüglich Stub mal einen vollkommen nervenschonenden Vorschlag gemacht, der halt "leider" technisch ist, nur wurde der ignoriert und das Thema Stub lief damals noch ne ganze Weile ohne Ziel weiter...
Hier der Link in's Archiv zum Vorschlag:
http://mail.wikipedia.org/pipermail/wikide-l/2004-November/008218.html
Zitat meiner obigen Mail: "Für diese Art von Problemen gibt es eine sinnvolle Lösung: Algorithmen, die den Eingabetext auf gewissen formale Kriterien überprüfen: Warum sollte ein Benutzer wenn er den Artikel hochläd nicht ne nette Warnung bekommen, dass er doch bitte Fleisch zum textlosen Gerippe hinzugeben möchte? Text und Boxen lassen sich ziemlich simpel voneinander unterscheiden."
Ich plädiere außerdem dafür endlich Regeln/Verhaltensrichtlinien einzuführen, die auf effektives Arbeiten abzielen. Als erste Regel würde ich vorschlagen:
"Als Substub gilt (unabhängig vom Inhalt) ein Artikel mit weniger als 350 Byte. Die Länge von Navileisten und Tabellen und Listen darf von der Artikelänge abgezogen werden. Ein Substub darf ohne lange zu überlegen gelöscht werden, wenn der Löschende dies für sinnvoll hält. Eine anschließende Diskussion darum, ob das gerechtfertigt war, deren Länge das 5fache der Substublänge übersteigt verbietet ein wiederherstellen des Artikels."
Sehr guter Vorschlag. Am besten wir definieren mal exakt in Bytes und anderen Charakteristika (Verhältnis Fließtext zu Metatext wie Tabellen) was ein Stub ist, dann kommen wir einer (Software-)lösung wie oben viel näher, welche den Vorteil hat die Offenheit der Wikipedia weitestgehend zu erhalten. Ich denke ein Kompromiss/Konsens darüber, was ein Stub ist (unabhängig was mit den dann passiert) sollte möglich sein.
Weitere Vorschläge hatte ich in http://mail.wikipedia.org/pipermail/wikide-l/2004-October/008112.html (so ab der Hälfte der etwas länglichen Mail ab "Intelligente algorithmische Editregeln" ;-) ) und eine Klarstellung in http://mail.wikipedia.org/pipermail/wikide-l/2004-October/008162.html gemacht.
Nachdem wir uns hier konkret auf ein paar gute Ideen geeinigt haben laufen wir zu http://bugzilla.wikimedia.org und machen eine sehr präzise formulierte Wikisoftwarewunschliste für den Weihnachtsmann. Wenn einige hier die Ideen dann so toll finden (wie den Bewertungsvorschlag den es ja schon in Software gibt) und auch die Zeit und Fähigkeit haben, bringen sie sich einfach in das Programmierteam mit ein, um die Sache voranzubringen.
Alles andere läuft auf eine der drei Möglichkeiten hinaus: a) die Diskussion kocht alle paar Wochen ohne Konsens wieder hoch b) Wir ändern unsere interne Policy und löschen schneller, was also einer "sozialen" Änderung innerhalb der Wikipedia entspricht c) Die denen es nicht gefällt suchen sich irgendwann frustriert andere Ziele
zu den Punkten: a) ist wohl sehr wahrscheinlich b) nicht Konsensfähig c) wäre sehr zu bedauern und wird auch schon beklagt
Gruß, Daniel Arnold (Arnomane)