PokéWiki:Allgemeine Diskussionsseite/Qualitätssicherung: Unterschied zwischen den Versionen

Aus PokéWiki
Zur Navigation springen Zur Suche springen
K (→‎Laufende Abstimmung: Ping an alle stimmberechtigten User)
Zeile 139: Zeile 139:


== Umsetzung ==
== Umsetzung ==
=== Laufende Abstimmung ===
=== Laufende Abstimmungen ===
Ping an alle stimmberechtigten User: {{u|Akuroma}}, {{u|Buoysel}}, {{u|Chrizz}}, {{u|GoPika}}, {{u|Impoleon xy}}, {{u|Isso08-15}}, {{u|Jass}}, {{u|Jones}}, {{u|Killuu}}, {{u|Korvel1}}, {{u|MattiBob}}, {{u|Matze}}, {{u|Maxmiran}}, {{u|Mecanno-man}}, {{u|Moltres}}, {{u|Pk-fan}}, {{u|RobbiRobb}}, {{u|Saywhaat}}, {{u|Shadowtweaker}}, {{u|Skelabra2509}}, {{u|Snackhound}}, {{u|Taisuke}}, {{u|Xavier}}, {{u|Ale Vidal23}}, {{u|Arrow}}, {{u|Cavana}}, {{u|CLina}}, {{u|Dawth}}, {{u|Der Sternendiamantritter}}, {{u|Flastanarbo}}, {{u|Jaru}}, {{u|Maxnet}}, {{u|Meow (th)}}, {{u|Metoschy}}, {{u|Ninjatom Smaragd}}, {{u|NintendoFan214}}, {{u|Pokénator}}, {{u|Ryuichi}}, {{u|Swampert}}, {{u|Traslaugen}}, {{u|詹玮键}}
 
==== Projektkoordination ====
==== Projektkoordination ====
Im Folgenden soll über die Frage abgestimmt werden, ob der Posten des/der Projektkoordinatoren/rin eingerichtet werden soll, welcher die Projekte bei der Qualitätssicherung unterstützen soll und bereits mit Vorarbeit und anderen noch näher zu bestimmenden Aufgaben beginnen kann.  
Im Folgenden soll über die Frage abgestimmt werden, ob der Posten des/der Projektkoordinatoren/rin eingerichtet werden soll, welcher die Projekte bei der Qualitätssicherung unterstützen soll und bereits mit Vorarbeit und anderen noch näher zu bestimmenden Aufgaben beginnen kann. Dies wird als der erste Schritt zu einer effizienten QS verstanden.


{{celer1|Die Abstimmung dauert 2 Wochen, bis zum '''2. September 2016''' um '''12:00 (Serverzeit).''' Heute ist der {{#time:d"."m"."Y H":"i "Uhr"}}. Jeder Benutzer, der [[PokéWiki:Stimmberechtigte Benutzer|hier]] verzeichnet ist, kann <u>eine</u> Stimme abgeben. }}
{{celer1|Die Abstimmung dauert 2 Wochen, bis zum '''2. September 2016''' um '''12:00 (Serverzeit).''' Heute ist der {{#time:d"."m"."Y H":"i "Uhr"}}. Jeder Benutzer, der [[PokéWiki:Stimmberechtigte Benutzer|hier]] verzeichnet ist, kann <u>eine</u> Stimme abgeben. }}

Version vom 19. August 2016, 14:07 Uhr

Ziel dieser Diskussion ist es, sich auf Richtlinien in der Qualitätssicherung zu einigen, die unserem Wiki bisher immer gefehlt haben. Egal, welches System wir zukünftig anwenden wollen, es funktioniert erst dann optimal, wenn alle involvierten Benutzer es mit Überzeugung anwenden. Daher ist es extrem wichtig, dass sich alle höherrangigen Benutzer intensiv mit diesem Thema auseinandersetzen und sich an der Diskussion im unteren Teil der Seite beteiligen.

Thematik

Eingangskontrolle

Wichtigster Aspekt der Qualitätssicherung ist die Eingangskontrolle, also die Kontrolle der letzten Änderungen. Hier wird von MediaWiki das System der Kontrollmarkierungen zur Verfügung gestellt, wodurch eine kontrollierte Änderung für andere Kontrolleure sichtbar als solche markiert werden kann. Ziel dieses Verfahrens ist es, lückenlos alle Änderungen zu kontrollieren. Hierbei sollte man festlegen, nach welchen Kriterien eine Änderung als kontrolliert markiert werden soll, um Fehlern vorzubeugen, die aus variierenden Kriterien der verschiedenen Kontrolleure entstehen, und um Klarheit zu schaffen, welche Fähigkeiten von einem Kontrolleur verlangt werden, sodass das Rechtesystem demnach ausgerichtet werden kann. Weiterhin bietet ein MediaWiki-Update neue Möglichkeiten bei Kontrollmarkierungen. Im Folgenden sollen alle in Frage kommenden Definitionen verglichen werden.

Kontrollierte Änderungen

Folgende Möglichkeiten stehen bei der Frage, was unter einer als kontrolliert markierten Änderung zu verstehen ist, zur Auswahl:

  1. Die Änderung ist frei von Vandalismus.
  2. Die Änderung ist oberflächlich überprüft worden.
  3. Die Änderung ist überprüft und ggf. korrigiert worden.
  4. Die Änderung ist von einer anderen Person überprüft und ggf. korrigiert worden.

Zu beachten ist, dass dennoch ein weiteres Qualitätssicherungssystem auf zweiter Ebene verwendet werden kann, beispielsweise durch die einzelnen Projektleitungen, worauf später noch eingegangen wird.

Das unausgesprochene Prinzip, nach dem bisher kontrolliert werden sollte, entspricht am ehesten Variante 3. Unser bisheriges System hat nicht ganz schlecht funktioniert, aber auch nie komplett zufriedenstellend, aus folgenden Gründen:

  • Es ist uns nie dauerhaft gelungen, lückenlos alle Bearbeitungen zu kontrollieren, stattdessen fallen regelmäßig Bearbeitungen durchs Raster, bis die Kontrollmarkierung nach 90 Tagen verschwindet.
  • Es gibt Bearbeitungen, deren detaillierte Kontrolle extrem aufwendig wäre (z. B. Zitate).
  • Bei der inhaltlichen Kontrolle möchte man oft auf Projektleiter als Experten zurückgreifen, aber nicht alle Projektleiter besitzen Kontrollrechte.
  • Es gibt Bearbeitungen, für deren Kontrolle Fachwissen aus mehreren Bereichen notwendig ist, aber jeder einzelne Benutzer kann nur entweder ganz kontrollieren oder gar nicht.
  • In letzter Zeit passieren zu viele Fehler bei der Kontrolle, d. h. trotz offensichtlicher Fehler werden Bearbeitungen kontrolliert und so stehen gelassen.

Weitere Erläuterungen zu den einzelnen Varianten:

  1. Diese Variante einer minimaler Kontrolle wird nicht wirklich in Betracht gezogen, da es sich bei unserem Vandalismusaufkommen nicht zu lohnen scheint, alle vandalismusfreien Bearbeitungen extra als solche zu kennzeichnen. Theoretisch hätte sie aber auch den Vorteil, dass man Kontrollrechte bereits an stimmberechtigte Benutzer vergeben und sie so motivieren könnte. Auf Wikipedia wird diese Definition verwendet.
  2. Dies ist das gegenteilige Extrem von 1, eine maximale Kontrolle nach dem Vier-Augen-System. Theoretisch eine optimale Kontrolle, gilt aber aufgrund des sehr hohen Aufwands als nicht realisierbar. Es kommen also nur 2 und 3 in die genauere Auswahl.
  3. Wie bereits gesagt kommt dieses System der bisherigen Handhabe am nächsten. Möchte man diese Definition weiterhin behalten, so stellt sich die Frage, wie man die bereits angesprochenen Probleme lösen könnte.
  4. Bearbeitungen nicht mehr bis ins kleinste Detail zu prüfen, sondern etwas oberflächlicher nach dem Motto „kann man erstmal so stehen lassen“, stellt eine sinnvolle Alternative dar. Was genau unter oberflächlicher Kontrolle zu verstehen ist, muss in dem jeweiligen Modell noch genauer präzisiert werden. Kontrollrechte können in dieser Variante schon etwas früher vergeben werden.

change tags

Ab dem nächsten MediaWiki-Update 1.25+ wird es die Möglichkeit geben, genauere Einstellungen an den Änderungsmarkierungen (change tags) vorzunehmen. Diese sind technisch noch nicht ganz ausgereift, dennoch wäre es beispielsweise denkbar, Markierungen einzuführen, die die Leiter eines bestimmten Projektes dazu auffordern, eine konkrete Bearbeitung zu prüfen.

Projekte

Der andere Aspekt der Qualitätssicherung ist bei den Projekten zu verorten. Die Projekte erarbeiten Konzepte über die Struktur von Artikelgruppen und stellen somit Qualitätsforderungen auf, deren Einhaltung bei der Qualitätssicherung geprüft wird. Keine festen Richtlinien gibt es bisher jedoch bei der Rolle der Projekte für die Qualitätssicherung sowie bei der Organisation und der Koordination der Projekte.

Qualitätssicherung

Auf die Frage, inwieweit sich Projekte an der Qualitätssicherung in ihrem eigenen Bereich beteiligen sollen, gibt es verschiedene Antwortmöglichkeiten. Denkbar wäre, die Aufgabe der Projekte auf die konzeptuelle Ebene zu beschränken und keine inhaltliche Aktivität zu verlangen. Schließlich muss man nicht der aktivste Benutzer eines Projektes sein, um gute konzeptionelle Arbeit zu leisten, oder kann sich ohne inhaltliche Verpflichtungen sogar stärker auf das Konzept konzentrieren. Andererseits zeigt die Erfahrung deutlich, dass Projekte tendenziell desto erfolgreicher sind, je stärker sich die Projektleitung selbst an der Umsetzung ihrer Konzepte beteiligt. Dadurch erhalten sie nämlich kontinuierlich Rückmeldungen für das Konzept aus der Praxis, beispielsweise werden sie automatisch auf noch nicht berücksichtigte Sonderfälle aufmerksam. Ein nicht zu unterschätzender Faktor ist zudem, dass auf diese Weise sogar die Aktivität anderer Benutzer des Projektes gefördert wird: Durch aktive Bewältigung erhalten Baustellen mehr Aufmerksamkeit und andere Benutzer sind auch eher zur Mitarbeit bereit, wenn sie eine Baustelle nicht alleine angehen müssen, sondern ein erfahrener Benutzer mit gutem Beispiel vorangeht, mit dem man sich austauschen kann.

Als Aufgabe von Projekten wird häufig auch die Koordination der Umsetzung genannt, wofür To-do-Listen ein wichtiges Hilfsmittel darstellen. Der Nutzen einer aktuell gehaltenen To-do-Liste sollte nicht unterschätzt werden: Sie informiert interessierte Benutzer sehr genau, wo und wie sie sich am Projekt beteiligen können, sie motiviert durch sichtbaren Fortschritt, sie fördert die gemeinsame Bewältigung von Baustellen und sie gibt Auskunft über die Aktivität eines Projektes.

Organisation und Koordination

Projekte werden sinnvollerweise durch einen oder mehrere Benutzer geleitet, die sich in diesem Bereich besonders gut auskennen. Dadurch werden jedoch einige Fragen aufgeworfen, die bisher nicht klar geregelt sind: Zu welchen Themengebieten sollen Projekte existieren? Wann ist ein Benutzer geeignet für die Leitung eines Projektes und was passiert, wenn es keine geeigneten Projektleiter gibt? Wie wird entschieden, welche Benutzer ein Projekt leiten? Wie wird kontrolliert, ob die Projektleitung ihren Aufgaben nachkommt, und was passiert, wenn nicht? Sind alle Projektleiter für alles zuständig oder sollen/dürfen sie sich die Arbeit aufteilen?

Modelle

shadows Modell

Die Kontrollanforderungen zu senken, um eine bessere Qualitätssicherung zu erreichen? Das klingt zunächst paradox. Dennoch habe ich beim sorgfältigen Durchdenken der Alternative mit oberflächlicher Kontrolle ein Modell gefunden, das in meinen Augen nicht nur alle Probleme löst, die ich lösen wollte, sondern sogar noch weitere positive Nebeneffekte bietet. Dieses Modell möchte ich nun Schritt für Schritt herleiten.

Bei der Eingangskontrolle gibt es zwei große Faktoren. Erstens, wann eine Bearbeitung als kontrolliert markiert werden darf, und zweitens, welche Benutzer als kontrolliert markieren dürfen. Je restriktiver wir bei der Vergabe der Kontrollrechte sind und je höher die Kontrollanforderungen sind, desto schwieriger ist es natürlich, eine lückenlose Qualitätssicherung zu erreichen. Genau das ist aber mein oberstes Ziel bei diesem Modell. Wenn 95% aller Bearbeitungen gründlich überprüft werden, wir aber die restlichen 5% ratlos stehen lassen, dann ist das keine Grundlage für eine positive Entwicklung der Qualität in unserem Wiki und sollte unseren Ansprüchen nicht genügen. Und wie oben bereits erwähnt, ist es uns in der langen Geschichte des Wikis bis auf eine ganz kurze Blütezeit nie gelungen, diesen Zustand der lückenlosen Kontrolle aufrechtzuerhalten. Noch dazu kommt die aktuelle Entwicklung: Wir haben momentan tendenziell wenig Benutzer, die auf hohem Niveau kontrollieren können, auf der anderen Seite werden die Kontrollanforderungen tendenziell immer höher, denn das Wiki wird immer vollständiger, d. h. es wird immer aufwendiger, das Wiki weiter zu verbessern, und demnach werden diese Verbesserungen auch immer aufwendiger zu kontrollieren (von News wie SoMo mal abgesehen).

Es erscheint mir also alternativlos, bei den anfangs genannten zwei Faktoren mal ein niedrigeres Niveau anzusetzen, also bei der Vergabe der Kontrollrechte weniger restriktiv zu sein oder unsere Kontrollanforderungen zu senken, und zwar deutlich, nicht nur ein bisschen. Diese Faktoren hängen aber natürlich zusammen, denn optimalerweise besitzen genau die Benutzer Kontrollrechte, welche auf dem gewünschten Niveau kontrollieren können, nicht mehr und nicht weniger. Also halte ich es für naheliegend, beide gleichermaßen zu senken, und zwar auf oberflächliche Kontrolle und Kontrollrechte für verlässliche Benutzer (sowohl patrol als auch autopatrol). Das passt zusammen, denn die Stufe des verlässlichen Benutzers entspricht in meinen Augen genau der Reife, dass alle eigenen Bearbeitungen ein solides Niveau aufweisen und man auch viele Bearbeitungen anderer Benutzer grob beurteilen kann.

Okay, also oberflächliche Kontrolle statt detaillierter Kontrolle. Das macht alles natürlich ein bisschen einfacher, aber überraschend ist, wie die obigen Probleme in unserem bisherigen System dadurch auf einen Schlag entschärft werden:

  • Lückenlose Kontrolle: Sollte durch die niedrigeren Kontrollanforderungen und mehr Kontrolleure kein Problem mehr darstellen. Dieser Punkt ist mir wie bereits gesagt sehr wichtig, wir brauchen endlich mal eine solide Grundlage in der Qualitätssicherung.
  • Zu hoher Kontrollaufwand: Wegen niedrigerer Anforderungen nicht mehr gegeben.
  • Projektleiter ohne Kontrollrechte: Nicht mehr möglich, da Projektleiter automatisch verlässlich sind.
  • Fachwissen aus mehreren Bereichen: Wegen niedrigerer Anforderungen nicht mehr notwendig.
  • Fehler bei der Kontrolle: Ist natürlich weiterhin möglich, aber ich gehe davon aus, dass die Fehlerhäufigkeit sinken wird, wenn man nicht mehr dauerhaft in Kontrollrückstand ist und endlich Richtlinien festgehalten wurden.

Dem gegenüber steht natürlich der Nachteil, dass die Kontrollanforderungen gesunken sind. Das heißt aber nicht unbedingt, dass Fehler, die nach oberflächlicher Kontrolle noch nicht aufgefallen sind, auf unbestimmte Zeit im Wiki stehen werden, denn in meinem Modell ist eine zweite Stufe der Qualitätssicherung auf Projektebene vorgesehen. Auf dieser zusätzlichen Ebene kann nämlich doch wieder in Richtung detaillierter Kontrolle gegangen werden, ohne die soeben entschärften Probleme erneut zu verursachen. Und zwar möchte ich die Projektleiter dazu verpflichten, eingehende Bearbeitungen in einem angemessenen Umfang zu prüfen. Warum? Weil ein guter Projektleiter das meiner Ansicht nach ganz automatisch machen sollte. Er ist für diesen Bereich zuständig, kennt sich mit dem Konzept am besten aus und hat am meisten Erfahrung. Eingehende Bearbeitungen in seinem Bereich nicht zu begutachten, würde also bedeuten, aktuelle Entwicklungen in seinem Zuständigkeitsbereich zu ignorieren und Benutzern, die beim Projekt mithelfen, weder Dankbarkeit zu zeigen noch zu unterstützen noch zu korrigieren, falls notwendig. Das kann auf Dauer nur nach hinten losgehen und meine Erfahrung könnte diese Einschätzung nicht besser bekräftigen.

In „angemessenem Umfang“ soll dabei bedeuten, dass die Projektleiter selbst entscheiden dürfen, wie detailliert sie prüfen, und sich so die Freiheit bewahren, ihre Prioritäten flexibel setzen zu können. Wenn es in einem Projekt vor Baustellen nur so wimmelt, dann sollte es nicht die oberste Aufgabe der Projektleiter sein, in den letzten Änderungen jeden einzelnen Rechtschreibfehler ausfindig zu machen. Ebenso gibt es Änderungen wie beispielsweise das Einfügen von Zitaten, deren Prüfung ähnlich aufwendig wäre wie die Bearbeitung selbst zu tätigen. In solchen Fällen ist es viel sinnvoller, dem Projektleiter die Freiheit zu geben, die Detailprüfung dieser Bearbeitung hinten anzustellen und sich anderen Aktivitäten zu widmen, die stärker zur Verbesserung des Wikis beitragen. Hingegen ist es bei Projekten, die bereits ein hohes Niveau erreicht haben, sinnvoll, besonders viel Aufwand in die Eingangskontrolle zu investieren und beispielsweise sogar das Vier-Augen-Prinzip anzuwenden, wodurch die Projektleiter gegenseitig ihre Bearbeitungen prüfen.

Dass dies nun auf einer zweiten Ebene stattfindet, vermeidet nicht nur wie gesagt die Verursachung altbekannter Probleme, sondern hat sogar positive Auswirkungen, die sich mit einer einzigen Ebene nicht erzielen ließen. Durch diese doppelte Kontrolle wird nämlich die Gefahr, dass Fehler die Qualitätssicherung unerkannt passieren, noch einmal deutlich verringert. Insbesondere wird auch über Bearbeitungen von Benutzern mit autopatrol noch einmal drübergesehen, was in meinen Augen ein sehr wichtiger Schritt für unser Wiki ist, denn auch bei Benutzern mit autopatrol sind Fehler natürlich nicht ausgeschlossen.

Sehr am Herzen liegt mir außerdem die offizielle Einführung der bereits mehrfach andiskutierten Projektkoordination. Ihre Hauptaufgabe soll es sein, die Projekte beratend zu unterstützen, in sowohl konzeptioneller als auch organisatorischer als auch technischer Hinsicht. Denn auch für Projektleiter ist es extrem wichtig, regelmäßig Feedback zu ihren Konzepten zu erhalten oder auch mal eine neue Idee zugesteckt zu bekommen (Stichwort Betriebsblindheit). Beispielsweise wurden die Umstrukturierungen im Anime-, Item- und Pokédex-Projekt alle maßgeblich durch inoffizielle Vorgänger der Projektkoordination beeinflusst oder gar erst ermöglicht. Organisatorische Unterstützung könnte zum Beispiel bei dem eben angesprochenen Umfang der projektspezifischen Qualitätssicherung Anwendung finden oder auch bei To-do-Listen, deren Existenz und Pflege ich mir in jedem Projekt wünschen würde. Es würde dann mit den einzelnen Projekten abgestimmt werden, wie eng die Kooperation ausfallen soll. Weitere Aufgaben wären, was man eben sonst alles als Koordination der Projekte bezeichnen kann, beispielsweise Kommunikation und Vermittlung zwischen verschiedenen Projekten, die Zuordnung von Artikeln zu Projekten sowie die Verwaltung unbesetzter Projekte. Sie wäre außerdem eine Anlaufstelle für Fragen zur Projektbesetzung und zur Gründung, Stilllegung, Aufteilung oder Vereinigung von Projekten.

Zum Schluss noch ein kurzer Ausblick auf die Rechtestruktur: Die Stufe eines verlässlichen Benutzers wäre nach diesem Modell wie zuvor erwähnt dadurch definiert, dass alle eigenen Bearbeitungen ein solides Niveau aufweisen und man auch in der Lage ist, die Bearbeitungen anderer Benutzer grob zu beurteilen. Das Modell macht aber keine Aussagen darüber, wie die Rolle von Redakteuren und Administratoren definiert wird, daher wird zu diesem Thema eine weitere Diskussion nötig sein. Es ist jedoch legitim, diese Diskussion erst nach Festlegung der Qualitätssicherung in Angriff zu nehmen, da die Rechtestruktur sich an die Qualitätssicherung anpassen muss und nicht umgekehrt. – shadowtweaker 13:04, 3. Aug. 2016 (CEST)

Zwei-Ebenen-Modell

Dieses Modell beteiligt Projektleiter an der Kontrolle der letzten Änderungen (folgend: Eingangskontrolle), ohne dass die Redakteure zugleich mit patrol eines ihrer zentralsten Rechte als exklusives verlieren, was den Posten deutlich entwerten würde.

Hierbei dienen die Redakteure als erste Stufe der Eingangskontrolle, die grundsätzlich nach Variante 3 konzipiert wäre. Sie checken eine Änderung grob vor und auf Rechtschreibung sowie Vandalismus/Verschlechterung. Nun haben sie drei Optionen:

  • Revert+Patrol: Änderung durchgefallen
  • Patrol: Änderung zusätzlich (nach Var. 3) inhaltlich gegengecheckt
  • Neu: Patrol+Tag

Die dritte Variante transferiert die Version in die zweite Stufe der Eingangskontrolle, die „Expertenrunde“: Der Redakteur weist der Änderung einen Tag zu, der wiederum einem Projekt zugeordnet ist. Hier haben nun die Projektleiter die Aufgabe, die Änderung (innerhalb von 90 Tagen, an älteren Versionen sind Tags nicht mehr einfach detektierbar und sollten botgestützt entfernt werden) zu überprüfen, wobei auch hier eine inhaltliche Kontrolle vorgenommen wird. Ist die Kontrolle durch die Projektleitung abgeschlossen, wird der entsprechende Tag von ihr entfernt.

Die Voraussetzungen für dieses Modell wären:

  • MediaWiki 1.25+
  • managechangetags (Tags verwalten) an Administratoren
  • changetags (Tags hinzufügen/entfernen) an Projektleiter/Verlässliche Benutzer (dies würde eine neue Gruppe vermeiden und zugleich die Verwendung flexibler machen, da sie so auch besser für „Interne Projekte“ eingesetzt u. ä. werden könnten)

Dieses Modell entspricht weitgehend shadow Modell, weist jedoch eine geringere Flexibilität bei größeren Baustellen auf und nötigt die Projektleiter ohne individuelle Abstimmung auf die aktuelle Projektsituation, gründlich zu kontrollieren. Hier und in vielen weiteren Teilen hat shadows Modell deutliche Vorteile.

Das Robb’sche Modell

Bei diesem Modell sind die Hauptkontrolleure die Experten des Themengebiets, also die Projektleiter (Damit sind nicht nur die Leiter der Inhaltsprojekte, sondern auch die Leiter der internen Projekte gemeint, wobei dort eventuell weitere Projekte für Bereiche wie Benutzerseiten benötigt werden). Im Zweifelsfall kommt jedoch eine weitere Gruppe, die Verlässlichen Benutzer, zum Einsatz. Die Projektleiter kontrollieren optimalerweise alles, was direkt oder indirekt mit ihrem Themengebiet zusammenhängt. Dabei sollte die Änderung sowohl inhaltlich, als auch formal geprüft und frei von Vandalismus sein. Wie einem Projektleiter signalisiert wird, dass eine Änderung zu seinem Projekt gehört, sei erstmal dahingestellt (Sei es mit einer Markierung ähnlich den Tags aus dem Zwei-Ebenen-Modell oder einer freien Suche in den Letzten Änderungen). Sollte eine Änderung in mehrere Bereiche fallen, so steht es den Projektleitern frei, von welchem Projekt die Änderung kontrolliert wird, vorrausgesetzt, dass der Kontrolleur in der Lage ist, die Änderung korrekt zu beurteilen und auf die oben genannten Kriterien zu prüfen. Sollte keiner der Projektleiter in der Lage sein, die Änderung zu kontrollieren, so wird die Änderung an die nächste Ebene, die Verlässlichen Benutzer, weitergegeben (Dies könnte entweder durch einen weiteren Tag oder nach einer eindeutig bestimmten Zeitspanne geschehen). Dabei sind dann alle Benutzer dieses Rangs, unabhängig von Projekten, dazu aufgerufen die Änderung zu kontrollieren, um so eine lückenlose Kontrolle zu ermöglichen.

--380.png RobbiRobb 18:20, 3. Jul. 2016 (CEST)

Mecs Modell

Ich hab mir mal einige Gedanken gemacht und ein eigenes Modell entwickelt: An der derzeitigen Kontrolle wird ja einiges kritisiert, u. A. teilweise fehlendes Fachwissen, aber auch, das autopatrol von einigen Benutzern einfach alles durchwinkt, ohne das je jemand drüberschaut. An shadows Lösungsvorschlag wurde kritisiert, das einige Projekte teilweise so gross sind, das sie einfach unübersichtlich sind; dies gilt insbesondere für Anime, Manga und TCG. Ich präsentiere hiermit mein Modell, mit welchem ich versuche, die aktuellen Probleme anzugehen: Erstmal, die Projektleter sollen, wie in shadows Modell, je nach dem wie es um ihr Projekt steht, eine projektliche Eingangskontrolle machen. Diese muss nicht zwingend flächendeckend sein, es muss nicht absolut alles von den Projektleitern geprüft werden, auch wenn es wünschenswert ist. Wenn ihr Projekt mitten in einer Umstrukturierung ist, oder es sonst genug zu tun gibt, muss defnitiv nicht alles, was möglich ist, in die Eingangskontrolle gesteckt werden. Damit dabei aber nichts verloren geht, soll es Changetags geben. Hierbei hat es zu jedem Projekt zwei Changetags zu geben, eventuell auch noch zu ein paar weiteren Sachen. Wenn ein Benutzer eine Änderung patrolt, ist erst mal sicherzustellen, das die Änderung nicht voller Rechtschreibfehler ist, eine Tabelle kaputt macht oder sonst was in der Art. Wenn kein Changetag eingebunden wird, muss sie ausserdem inhaltlich richtig und nicht kontrovers sein. Bei den Tags gibt es zwei Möglichkeiten: Eines sagt im Grunde aus, das der Benutzer, der den patrol durchgeführt hat, keine Ahnung vom Themengebiet hat und eine inhaltliche Kontrolle noch ausstehend ist; ich möchte hier noch hinzufügen, das dies auch bei Tabellenwertänderungen gilt, diese müssen ebenfalls inhaltlich geprüft werden. Diese inhaltlichen Tags dürfen von jedem Benutzer, der patrol hat, entfernt werden. Die anderen Tags sind konzeptionelle Tags; wenn ein Benutzer merkt, das wer einen neuen Abschnitt eingetragen hat, der nicht der Norm entspricht, oder das ein Trivia-Eintrag eventuell unerwünscht ist, kann er diesen Tag einbinden. Dieser Tag darf nur von der entsprechenden Projektleitung entfernt werden, womit sichergestellt werden soll, das wichtiges von der Projektleitung nicht übersehen wird. Die Projektleitung soll allerdings nicht nur diese Tags abarbeiten, sondern auch sonst was in ihrem Projekt, sei es die genauere Eingangskontrolle oder eine aktive Mitarbeit, machen; dafür sorgt die Projektkoordination. In Extremfällen dürfen auch beide Tags gesetzt, oder der inhaltliche Tag durch den konzeptionellen Ersetzt werden, dies kommt immer auf den entsprechenden Edit drauf an. --Datei:Sugimori 672.pngMecanno-manMäh 18:31, 5. Aug. 2016 (CEST)

Diskussion

So, oben seht ihr drei Vorschläge für neue Qualitätssicherungsmodelle, ab jetzt seid ihr alle gefragt. Gibt es Fragen zur Thematik oder zu den Modellen? Möchte jemand noch ein Modell hinzufügen? Welche Vor- und Nachteile seht ihr in den verschiedenen Modellen? Jeder einzelne Beitrag ist hilfreich, um dieses für unser Wiki so zentrale Thema voranzubringen! – shadowtweaker 15:00, 3. Aug. 2016 (CEST)

Ok, hier mal meine Meinungen:
1. Dein Modell, shadow gefällt mir recht gut, da ich mit der ersten Ebene an sich viele Probleme habe, die zweite Ebene diese aber auffängt. Dennoch bleiben mir dabei ein paar Fragen zurück. Zuallererst würde ich gerne wissen, wie ich als Projektleiter die Änderungen an Seiten meines Projektes im Auge behalten kann. Natürlich, es gibt die Beobachtungsliste, die nutze ich aber lieber für die allgemeine Disku und einige Hauptseiten meines Interesses. Ich kann und will jetzt nicht jede Seite, die mit meinem Projekt zu tun hat, auf die Beobachtungsliste setzen, um sie eben zurückstellen zu können und die Änderung später zu begutachten. Gibt es da vielleicht eine Möglichkeit, ich kenn mich mit den technischen Spielereien Null aus. Auch bräuchte ich persönlich als Leiter zweier Projekte dann zwei Seiten, weil ich nicht alles durcheinander angezeigt bekommen möchte.
Ein weiteres Problem sehe ich dabei, alle Seiten aufzuteilen. Für deine zweite Ebene muss jede Seite prinzipiell einem Projekt zugeordnet sein, damit sie nicht durchs Raster fällt. Fraglich ist da bei manchen Seiten, ob es dafür ein Projekt gibt. (EDIT: Sehe gerade, da würde die Projektkoordination dann drüber schauen, von daher wohl kein so großes Problem) Das gegenteilige Problem ist aber auch gegeben. Routen, Städte, Orte, sie vereinen alle Aspekte von Orte-, Item-, Anime-, Manga-, TCG-, etc.-Projekt. Eine Änderung auf einer dieser Seiten müsste dann ggf. erst einmal vom richtigen Projekt erkannt worden sein. Und wie ist es, wenn ein Benutzer auf einer solchen Seite gleichzeitig ein wildes Pokémon hinzufügt und eine Anime-Episode ergänzt?
Nächstes Thema Projektkoordination. Anfangs habe ich ein wenig damit gehadert, muss ich zugeben, aber natürlich will ich mal schauen, wie das funktioniert, weshalb ich sowas grundsätzlich nicht im Weg stehe. Vor allem Hilfe in technischer Hinsicht finde ich Hilfe nicht schlecht und auch Hilfe bei konzeptionellen Dingen finde ich gut, da ich als Alleinunterhalter im Manga-Projekt beispielsweise alleine nie wirklich Lust auf Änderungen hatte, wenn ich sowieso nur selbst davon profitiere. To-do-Liste habe ich ja auch eher zur Eigenkontrolle eingeführt, aber die gibts so wenigstens schon ;) (Problem im Manga-Projekt ist dabei nur, dass es ca. 12drillionen Manga gibt und ich selbst nicht ansatzweise alle irgendwie kennen würde, als dass ich da ne To-Do-Liste erstellen könnte - geht der Projektkoordination da aber wahrscheinlcih genauso).
Zum Zwei-Ebenen-Modell: Finde ich gut, nur ist dieses Modell wohl wie auch erwähnt, anfälliger für durchs Raster fallende Bearbeitungen. Vielleicht könnte man die Tags aber in Shadows Modell einbauen und so den Projektleitern auf einer Seite, wo sie nur die für sie bestimmten Tags sehen, die Bearbeitungen, die sie in Ebene zwei kontrollieren müssen, anzeigen. Kann sein, dass das eh so geplant war, weil es für mich sehr sinnig klingt, stand jetzt aber nicht im Text^^
Robbsches Modell: Ich bin etwas verwirrt. Meint das, erst kontrollieren die Redakteure das für sie projektmäßige und dann, wenn die Redakteure nicht weiter wissen, können die verlässlichen Benutzer? Fraglich, wie das weitergereicht werden soll, bis dahin sind die Änderungen aus den LÄ sicher heraus und mit einem Tag versehen, dass dann alle Verlässlichen angezeigt bekommen, könnte für die doch teilweise auch nervig sein, wenn ein Projektleiter vielleicht mal nicht kann oder keine Lust hat. - - Vivian.png "Dream on" 518.png GoPika Disku 16:05, 3. Aug. 2016 (CEST)
Für mich ist das Zwei-Ebenen-Modell eigentlich die Idealvariante, zumindest jetzt, wo wir das theoretisch diskutieren; ich könnte aber auch mit shadows Modell arbeiten. Der Hauptgrund, warum ich das Zwei-Ebenen-Modell bevorzuge, ist die Übersichtlichkeit der Änderungen; die Projektleiter bekommen eine Liste von Änderungen, die sie kontrollieren sollen, direkt geliefert; sie müssen nichts über die Letzen Änderungen oder die Beobachtungsliste zusammensuchen; die Beobachtungsliste scheint mir sowieso untauglich dafür, ich werde definitiv nicht 8000 Artikel draufsetzen, die so gut wie nie bearbeitet werden, nur um da die Qualität zu sichern... Werden dafür jedoch die Letzten Änderungen benutzt, und ist mal wer im Urlaub, ist QS auch wieder nicht mehr flächendeckend; das changetag-System hingegen versagt erst, wenn jemand mehr als sechs Wochen abwesend ist. --Datei:Sugimori 672.pngMecanno-manMäh 16:17, 3. Aug. 2016 (CEST)
Hallo zusammen! Das ist ja ein ganzes Stückchen Text und ich hoffe, alles richtig verstanden zu haben. Ich finde den Ansatz der zweistufigen Lösung sehr schön. Wenn ich das jetzt richtig aufgefasst habe, könnten die Redakteure zunächst alle Änderungen prüfen und dann mit entsprechenden Tags versehen, um sie einem Projekt(leiter) zuzuordnen, der sie abschließend prüft. Diese Lösung finde ich sehr elegant, frage mich nur, ob das nicht ein sehr großer Aufwand für die Redakteure bedeutet! Oder habe ich das falsch verstanden und es geht gar nicht um alle Änderungen? Gäbe es dann quasi einzelne Änderungsseiten mit ungeprüften Änderungen pro Tag? 674.png Maxmiran 16:21, 3. Aug. 2016 (CEST)
shadows Modell ähnelt dem Zwei-Ebenen-Modell eigentlich sehr, nur dass es die zweite Ebene deutlich flexibler handhabt. GoPikas Probleme, Änderungen zu erkennen, kann ich ein Stück weit nachvollziehen, und leider gibt es keine einfache Lösung. (Evtl. Wartungskategorien mit Projektzuordnung und kategorienfilterbare Letzte Änderungen, die allerdings auch irgendwelche merkwürdigen Probleme haben, oder unproblematischer ein Bot, der alle Artikel eines Fachbereiches alphabetisch auf eine Liste schmeißt, wobei er kategorienbasiert arbeitet, dann hätte man auch wieder eine übersichtliche Liste). Eine interessante Idee wäre es auch, wenn die PLs ein Stück weit mitbestimmen, wie hart die Eingangskontrolle ist, indem sie VBs (in shadows Modell) beauftragen können, in einem relativ baustellfreien Projekt die kontrollierten Änderungen die zu ihrem Projekt gehören zu taggen (RCs sind tagfilterbar, bis zu 90 Tage). Dies erfordert allerdings unabhängig vom Modell große Aufmerksamkeit der PLs: Einmal durch die 90 Tage gerutscht, lassen sich die Tags nur per manueller Suche wiederfinden, dennoch verstopfen sie die Pipeline, weil die Softwarre sie weiterhin als vorhanden zählt. (Dann steht da: 4 Bearbeitungen, und die Letzten Änderungen finden keine, das ist toll) Damit hätte man ja wieder das gleiche Problem, wie jetzt mit durchrutschenden nicht patrolten Änderungen in anderer Form wieder, und die Eingangskontrolle verkompliziert und formalisitischer gemacht, anstatt Ressourcen freizugeben.
Egal wie man sich entscheidet, auf jeden Fall würde der Posten der Projektleiter deutlich wichtiger. Und damit kann man sich so absurde Konstellationen wie aktuell im Item-Projekt nicht erlauben. Eine Projektkoordination ist Pflicht. Und sie muss mehr können als nur meckern, sie muss auch was konkret tun können in Problemfällen, so wie jetzt der Vorlauf des ganzen organisiert ist kann man es auch lassen.
Ich unterstütze shadows Modell, weil es IMHO die einzig logische Folge aus dem Status quo sind. Sonst laufen wir vor bestehenden Problemen weg und flüchten uns in eine Alternative, die wieder die gleichen Probleme birgt. Damit hätten wir nichts erreicht und wären in 6 Monaten wieder hier. Mein Modell verschiebt die Probleme nur, es hält keine Lösung für die Probleme bereit, die aus dem Sachtext vor den einzelnen Modellen hervorgehen.
Zuletzt noch: Ich freue mich auf eine produktive Diskussion und hoffe, dass wir dieses Thema schon bald zu einem angemessenen Abschluss bringen können. For SOMO muss vor allem hinter den Kulissen noch einiges bewerkstelligt werden, damit dann problemlos und schnell das Wiki mit neuen Informationen gefüllt werden kann. -- 609.png Skelabra2509 (Diskussion | Beiträge) 16:41, 3. Aug. 2016 (CEST)
Ich halte das Zwei-Stufen-Modell am geeignetsten. Was VB und Patrol/Autopatrol angeht, kennt ihr ja meine Meinung. Sorry für die kurze Antwort, stand bis eben im Labor und darf jetzt noch für eine Klausur lernen :(--Fliegen bis zum Horizont. Killuu http://i.imgur.com/4EZCZEO.png 19:01, 3. Aug. 2016 (CET)
@alle: Ich weiß, man hört das nicht gerne, aber von dem Mythos einer perfekten Kontrolle müssen wir uns verabschieden. Es stehen bereits tausende Fehler im Wiki und es werden regelmäßig welche dazu kommen, kein Modell kann das verhindern. Es geht viel mehr darum, wie wir Fehler möglichst effizient bekämpfen können. Vielleicht braucht es ein bisschen Zeit, um das zu akzeptieren, aber oberflächliche Kontrolle ist wirklich zufriedenstellend, damit kann man arbeiten. Auch wenn man auf die zweite Ebene verzichten und ausschließlich oberflächliche Kontrolle betreiben würde, das Wiki würde sich immer noch positiv weiterentwickeln. Die sekundäre Kontrolle auf Projektebene ist nur ein Zusatz, um noch effizienter zu arbeiten, und es lohnt sich, in diesen Zusatz zu investieren, aber man sollte eben das Gleichgewicht zu anderen Maßnahmen zur Verbesserung des Wikis halten.
@GoPika: Mit der Spezialseite „Änderungen an verlinkten Seiten“ ist es möglich, die letzten Änderungen nach einer frei angebbaren Liste von Seiten zu filtern, nämlich genau die Seiten, die von einer bestimmten Seite aus verlinkt werden. Mein Lieblingsbeispiel ist Spezial:Änderungen an verlinkten Seiten/PokéWiki:Pokédex-Projekt/To-do-Liste, da sieht man genau die Änderungen an Pokémon-Artikeln, weil das eben genau die Seiten sind, die von der To-do-Liste aus verlinkt werden. Mit Botunterstützung wäre es da ein Leichtes, für jedes Projekt oder für jeden Benutzer eine solche Liste anzulegen. Damit sollten alle arbeiten können, denke ich, alternativ eben die Beobachtungsliste (die kann man auch botgestützt bearbeiten, z. B. fasst meine Beobachtungsliste über 10.000 Seiten und ich komme gut damit zurecht) benutzen oder einfach häufig genug in die letzten Änderungen sehen.
Artikel ohne Projektzuordnung werden auf der zweiten Ebene vernachlässigt, das stimmt, aber da sehe ich kein großes Problem, denn wie gesagt, oberflächliche Kontrolle ist zufriedenstellend. Um solche Artikel wird sich sonst auch nicht richtig gekümmert, da kann ein neues Qualitätssicherungsmodell auch keine Wunder wirken.
Genau, am bearbeiteten Artikel lässt sich nicht hundertprozentig erkennen, zu welchen Projekten die Bearbeitung zuzuordnen ist, das betrifft vor allem das Anime- und das Manga-Projekt. Eine Möglichkeit wäre, alle Artikel mit Anime- bzw. Manga-Abschnitt auf dem Schirm zu haben und Ausschau nach relevanten Bearbeitungen zu halten. Ich denke, das ist im Endeffekt weniger Arbeit, als es sich anhört, oft gibt die Zusammenfassung Hinweise und wenn derselbe Benutzer mehrere Edits auf einmal macht, reichen Stichproben, um zu beurteilen, ob er an den betreffenden Abschnitten gearbeitet hat oder nicht. Noch dazu kommt, dass man sich die Arbeit aufteilen kann, wenn es mehrere Projektleiter gibt. Falls das für dich jedoch unverhältnismäßig großen Aufwand bedeuten würde, können wir aber sicher auch eine andere Lösung finden, vielleicht dass die Projektkoordination oder einzelne Projekte dich benachrichtigen, oder notfalls doch mit change tags arbeiten, wobei ich da eher vorsichtig wäre (siehe unten). Bei umfangreichen Bearbeitungen kann es dann natürlich sein, dass mehrere Projekte unabhängig voneinander die entsprechenden Teile der Bearbeitung prüfen, das ist ja auch gerade mein Lösungsansatz für das Problem „Fachwissen aus mehreren Bereichen“.
@Mecanno-man: Punktuell eingesetzt können change tags auf jeden Fall hilfreich sein, aber das, was du da bevorzugst, nämlich dass Projektleiter ausschließlich eine Liste von change tags abarbeiten, will ich gerade vermeiden. Ein Projektleiter, der nur dort hilft, wo er unbedingt benötigt wird, ist kein guter Projektleiter. Vielmehr sollte ein guter Projektleiter von alleine aktiv werden, z. B. Mitarbeiten im Projekt Tipps geben, was sie noch besser machen könnten, und zwar unabhängig davon, ob ihre Bearbeitungen bereits gut genug sind, um die oberflächliche Kontrolle zu passieren, oder nicht. Nicht oft genug betonen kann ich auch die positiven Effekte, dass ein Projektleiter, der Bearbeitungen in seinem großzügig Bereich prüft, auf viel mehr Fehler bei der Kontrolle und auf viel mehr Fehler von Benutzern mit autopatrol aufmerksam wird. Ich bin nicht der Meinung, dass sich das mit Übersichtlichkeit aufwiegen lässt. Für die Möglichkeiten, Bearbeitungen im eigenen Projekt zu verfolgen, siehe meine Antwort an GoPika.
@Maxmiran: Bitte etwas genauer erklären, was du meinst und worauf du dich beziehst. Alle Bearbeitungen von Benutzern ohne autopatrol werden von Benutzern mit patrol kontrolliert, das ist ganz grob gesagt die Idee hinter allen Qualitätssicherungsmodellen, auch bei dem, das wir bisher anwenden.
@Killuu: Sobald du Zeit hast, bitte nochmal genauer mit dem Thema auseinandersetzen. Es geht hier unter anderem darum, zu klären, wie wir autopatrol und patrol einsetzen möchten, daher hängt es vom genauen Modell ab, welche Fähigkeiten benötigt werden, um mit diesen Rechten umzugehen.
shadowtweaker 00:50, 4. Aug. 2016 (CEST)
@shadowtweaker Ok, mit den Listen klingt schon mal gut und ich denke auch, dass die Kontrolle, wie sie hier angestrebt wird, eine deutliche Verbesserung ist und dass Perfektion sowieso nicht erreicht werden kann. 10:21, 4. Aug. 2016 (CEST) (Der vorstehende nicht signierte Beitrag stammt von: GoPikaDiskussionBeiträge)
Mir waren viele Aspekte, die schon genutzt werden, gar nicht bekannt, weswegen ich mich dort gestern erst nochmal einfinden musste. Nachwievor finde ich die vorgeschlagene Lösung, dass die Redakteure Änderungen oberflächlich prüfen und dann in die Projekte geben, sehr schön, und da es auch allen anderen, soweit ich das sehe, so geht, können wir uns darauf dann nicht schon festlegen und an die Feinabstimmung gehen? Dort könnte man dann auch Dinge, die stören oder aus anderen Modellen integriert werden können, einbauen. Ich frage mich, ob es auch möglich ist, eine Änderung mit mehr als einem Tag zu versehen, dann hätte sich das Problem der Projektzuordnung gelöst.
Zwei Probleme habe ich, und das sind einerseits Bearbeitungen an Seiten, die keinem Projekt zugeordnet sind. Du würdest sie durchs Raster fallen lassen, aber das finde ich weniger schön. Vielleicht kann man diese Änderungen an die Redakteure oder die Projektkoordination zurückgeben, die sich dann um diese in der zweiten Stufe kümmern könnte. Mein anderes Problem ist Autopatrol. Klar, es soll die Überprüfungsarbeit reduzieren, jedoch ist es bei Änderungen einer bestimmten Größe einfach unrealistisch, dass sie fehlerfrei ist. Das gilt quasi für jeden geschriebenen Fließtext. Autopatrol hebelt das Vier-Augen-Prinzip aus und sorgt dafür, dass viele Fehler übersehen werden, das finde ich sehr schwierig. 674.png Maxmiran 10:34, 4. Aug. 2016 (CEST)
Tut mir leid, ich verstehe dich immer noch nicht richtig. Auf welches Modell beziehst du dich jetzt? Sowohl bei meinem Modell als auch bei Skels Modell ist es so, dass zuerst oberflächlich geprüft wird und dann nochmal die Projekte einbezogen werden. Nein, für eine Abstimmung ist es noch viel zu früh. Mehrere Tags zu setzen ist kein Problem. Aber welches Problem der Projektzuordnung meinst du und warum würde das dadurch gelöst werden? Zu Seiten ohne Projekte siehe meine Antwort an GoPika. Das Vier-Augen-Prinzip wird nur in Skels Modell ausgehebelt, in meinem nicht. – shadowtweaker 10:46, 4. Aug. 2016 (CEST)
Ich habe mich bewusst auf kein spezielles bezogen, da sie mir alle in ihrer Grundstruktur ähnlich vorkommen und besser integriert als gegeneinander abgestimmt zu werden, denke ich. Man könnte sich auf ein Zweistufenmodell, den gemeinsamen Nenner der Modelle, beispielsweise einigen und dann das restliche Prozedere so ergänzen, dass es alles abdeckt. Mit dem Problem der Projektzuordnung bezog ich mich auf Änderungen, die im zweiten Schritt keinem konkreten Projekt zugeordnet werden können und deswegen nur im ersten Schritt oberflächlich kontrolliert würden. Für diese würde ich eine projektunabhängige Kontrollinstanz für die zweite Kontrollebene begrüßen. Mir wurde nicht ersichtlich, wieso das Problem des Vier-Augen-Prinzips in deinem Modell nicht besteht, kannst du mir das nochmal erklären? Wer prüft dann beispielsweise Änderungen von mir auf der zweiten, genauen Prüfebene? 674.png Maxmiran 12:21, 4. Aug. 2016 (CEST)
Ich sehe das mittlerweiler so: Einem Projektleiter, der genug Zeit hat, kommt shadows System gut. Bei Projekten, deren Leiter allerdings wenig Zeit hat, wird sich so an der Qualität nicht viel ändern. Wir können nicht alle Projekte ideal besetzen, daran wird auch die Projektkoordination nichts ändern können. Bei Projekten, deren Leiter gerade weniger Zeit haben, hilft die Liste, die sie abarbeiten können, damit sie nicht lange nach Änderungen suchen müssen - in jeder automatisch erstellten Liste erscheinen Änderungen an der Rechtschreibung etc., die nicht inhaltlich geprüft werden müssen - sondern die wenige Zeit, die sie haben, effizient nutzen können. Die Changetags sagen den Leuten genau, wo sie benötigt werden. Es verbietet ihnen nichts, auch woanders nachzusehen. Und von der Projektkoordination erwarte ich mal, kompetent genug zu sein, rauszufinden, ob wer andauernd nur die Liste abarbeitet... --Datei:Sugimori 672.pngMecanno-manMäh 12:53, 4. Aug. 2016 (CEST)
Nach einigen Diskussionen im Chat hab ich mal ein neues Modell hinzugefügt. --Datei:Sugimori 672.pngMecanno-manMäh 18:31, 5. Aug. 2016 (CEST)

An alle die, die sich sorgen machen etwas in ihrem Bereich könnte übersehen werden: Es ist theorethisch möglich Seiten unsichtbar zu kategorisieren. Angenommen man legt eine Kategorie:Anime-Projekt an, versieht diese mit dem Tag __HIDDENCAT__ und fügt dann anschließend diese Kategorie in einigen Infoboxen, die nur im Anime-Projekt genutzt werden, wie etwa die Episoden-Infobox und die Anime-Pokémon-Box ein. Alle Seiten, auf denen diese Vorlagen eingebunden sind, sollten dann unsichtbar kategorisiert in der Kategorie:Anime-Projekt landen. Von dort lassen sich dann mithilfe der funktion Spezial:Änderungen an verlinkten Seiten alle Änderungen an den Seiten in der Kategorie, also alle Änderungen, die (eventuell) zum Projekt gehören, nachverfolgen. Das einzige Problem ist hier natürlich wieder die Übergriffe in andere Projekte, beispielsweise bei Orten, diese würden wahrscheinlich aber so gering ausfallen bzw. man könnte brereits an dem Abschnitt, der bearbeitet wurde erkennen, zu welchem Projekt es letztendlich gehört. (Es wäre ganz schön, wenn da nochmal jemand mit etwas mehr Ahnung von der ganzen Technik drauf gucken könnte und grob abschätzen könnte, ob das 1. auch wirklich so funktioniert und 2. wie viel man extra prüfen müsste, wenn sich Projekte überschneiden) -- 380.png RobbiRobb 22:28, 5. Aug. 2016 (CEST)

Das würde so gehen, IMHO spräche nichts dagegen. -- 609.png Skelabra2509 (Diskussion | Beiträge) 00:24, 6. Aug. 2016 (CEST)
Spricht eigentlich etwas dagegen diese "Sichtbar" zu machen? Bei manchen Sachen ist es für neue so einfacher sich bei Fragen zu einem Artikel an das Projekt-Team bzw. den PL selbst zu wenden. Gruß Ryu ~ Datei:Sugimori 004.png ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 13:00, 12. Aug. 2016 (CEST)
Ich hätte die lieber unsichtbar, sind ja "interne" Kategorien, die nicht wirklich zum navigieren dienen, und auch nicht wirklich Aufmerksamkeit von neuen Benutzern auf sich ziehen müssten. --Datei:Sugimori 672.pngMecanno-manMäh 14:18, 12. Aug. 2016 (CEST)
Ich denke auch, dass man bei der Qualitätssicherungsdebatte einen Schritt zurückgehen sollte, wie ihr es hier gerade macht. Der Kern ist meiner Meinung nach ja das Vieraugen-Prinzip, und ein Projektleiter muss eben einen Überblick haben über alle Änderungen, die in seinem Projekt gemacht werden, bevor seine Prüfungen in ein größeres Modell eingebettet werden können. Das ist jedoch bisher ziemlich unmöglich und funkioniert nur beim Pokédex-Projekt, da dort alle Seiten auf der To-Do verlinkt sind. Im Anime-Bereich zB gibt es solche umfassenden ToDos nicht. Man hätte jetzt zwei Möglichkeiten: Entweder legt man manuell solche to-do-Listen für alles an und kann diese dann zudem noch für Notizen etc nutzen, oder man greift eben wie Bulbapedia auf eine Kategorisierung zurück. Die haben sie ja offen gemacht, auf einen Banner oÄ würde ich aber verzichten, eine bloße Kategorie reicht mir, egal ob sichtbar oder unsichtbar. Bei eindeutigen Zuordnungen habe ich eine Präferenz für sichtbare Kategorien, aber vor allem für Artikel wie Charaktere, die mehreren Projekten zugehörig sind, gefällt mir das schon nicht mehr. Daher sind unsichtbare wohl netter.
Erst wenn man diese Möglichkeit geschaffen hat und es so den Projekten ermöglicht, den eigenen Bereich umfassend zu kontrollieren, DANN kann man das weitere Verfahren drübergeben. Und netterweise fällt dann auch der Aufwand mit den changetags weg, da eine Projektzuordnung der Änderungen dann über die entsprechenden Änderungslisten erledigt würde. 674.png Maxmiran 15:04, 12. Aug. 2016 (CEST)
Ich wäre schon dafür sie standardmäßig unsichtbar zu machen, da es, wie Mec erwähnte, Wartungskategorien sind. Außerdem gibt es in den Einstellungen eine Möglichkeit sich versteckte Kats anzeigen zu lassen, für die, die es unbedingt brauchen zwinker3.gif -- 380.png RobbiRobb 15:10, 12. Aug. 2016 (CEST)
Dann will ich mich auch mal dafür aussprechen. Falls es so funktioniert, wie es angedacht ist und man zur Ergänzung der To-Dos die Wartungskategorien als projektinterne Beobachtungsliste nutzen kann... nun das wäre absolut zufriedenstellend für mich. Ich bin/war in dem Boot der Leute, die mehr von einem System mit changetags überzeugt waren, da ich mir wünsche, möglichst jede projektrelevante Änderung an deren Überprüfung ich verantwortlich oder interessiert bin, natürlich auch, wenn der Artikel selbst nicht dem Projekt zugeordnet ist, schnell für mich zu finden ist. Falls Changetags nun doch so viel Aufwand mit sich bringen soll (da ich nicht einmal über normale patrol-Rechte verfüge, kann ich mir im Vergleich leider nichts ausmalen), und die Befürchtung besteht, dass die Projektleitung nur noch changetags abhakt, statt umfangreich zu kontrollieren, hoffe ich, dass dies hier eine Alternative sein könnte. Die unsichtbaren Kategorien in den wichtigsten Vorlagen eines Projektes sollten flächendeckend genug sein, damit man, wie gesagt, die Kategorien als Beobachtungsliste und das To-Do weiterhin als Stand des Projektes nutzen kann. Und im Vergleich zu Changetags, könnte mit dieser Beobachtungsliste jedes Projektmitglied/jeder Interessent alle Änderungen im Projekt für sich selbst noch einmal überprüfen. Das einzige Problem, welches ich im vornherein sehe ist, dass natürlich nicht nur Artikel, sondern auch Benutzer(test)-Seiten, die solche Vorlagen einbinden, automatisch mitkategorisiert werden. Dies sollte aber weniger ein Problem sein als bei "öffentlich" einsehbaren Kategorien, in denen falsche Seiten kategorisiert sind, da solche Seiten in den Wartungskategorien, solange sie nicht zu viele und zu häufig bearbeitet werden, getrost ignoriert werden könnten. — mfg Snackhound 058.png 12:16, 16. Aug. 2016 (CEST)

Wir werden für jedes Projekt eine zufriedenstellende Lösung finden, wie die Projektleiter alle größeren Änderungen in ihrem Zuständigkeitsbereich mitbekommen, davon bin ich fest überzeugt (ansonsten hätte in meinen Augen das gesamte Projektkonzept versagt). Aber da kann sich ja jedes Projekt unabhängig voneinander für die Lösung ihrer Wahl entscheiden, solange am Ende das Teamwork stimmt, und wir sollten die Diskussion hier nicht pausieren, bis Lösungen wie die versteckten Kategorien umgesetzt worden sind. Daher wäre ich sehr dafür, mit der Diskussion wieder zu den Modellen zurückzukehren. – shadowtweaker 16:01, 12. Aug. 2016 (CEST)

Da sich hier schon jede Menge Wortmeldungen finden, die einen beträchtlichen Umfang haben, versuche ich mich etwas kürzer zu fassen.
Von den hier vorgestellten Modellen sagt mir jenes von shadow am ehesten zu. Es hat gewisse Ähnlichkeiten zu unserem jetzigen System, zumindest dem, wie es von den meisten interpretiert wird. Da wir nun seit geraumer Zeit verlässliche Benutzer mit autopatrol herumlaufen haben und ich bislang keinen gravierenden Nachteil erkennen konnte, schließlich kontrolliere ich deren Änderungen – wie in shadows Modell auf der zweiten Stufe der Projektebene erwünscht – trotzdem nochmals. Um die Eingangskontrolle aber effizienter zu gestalten, könnte man ihnen auch patrol zutrauen. Sollten verlässliche Benutzer vermehrt dadurch auffallen, dass sie die Eingangskontrolle nicht ernst genug nehmen, sondern einfach alles durchwinken, kann man ja eine netten Hinweis verfassen und ihnen mitteilen, sich doch zukünftig etwas genauer mit Punkt X bei der Kontrolle von Bearbeitungen zu beschäftigen. Schließlich unterlaufen jedem von uns mal Fehler, sei es bei der Kontrolle oder der Bearbeitung. ;)
Hierbei ist die Kommunikation ein wichtiger Punkt. Ich möchte eigentlich an dieser Stelle nicht zu weit abschweifen, aber ich erhoffe mir von der Projektkoordination auch eine Auflockerung zwischen einzelnen Lagern, sodass wir sowohl zwischen Projekten als auch Rechtestufen wieder eine bessere Kommunikation hinbekommen. Unsere momentane „Mit-dem-Finger-auf andere-zeigen“-Haltung führt zu einem beträchtlichen Stillstand unserer Baustellen. Hier erhoffe ich mir, dass wir mit Hilfe einer gut organisierten Projektkoordination eine bessere, positivere und auch wertschätzendere Kommunikation hinbekommen. Denn mit einer solchen Kommunikation wird es uns leichter fallen flächendeckend Missstände aufzuzeigen, Agenden aufzustellen, Zugehörigkeiten zu klären, Lösungen vorzuschlagen und wieder effizient zu arbeiten. ~ Taisuke 136.gif 09:50, 17. Aug. 2016 (CEST)
Also mir sagt von allen Modellen shadows Variante auch am ehesten zu und ich könnte sehr gut im Wikialltag damit leben. Ob man jetzt die VBs nur mit autopatrol ausstattet oder ihnen sogar patrol gibt, kann man ja separat noch einmal diskutieren (siehe Max' Punkt unten). Ich denke aber auch nicht, dass es Probleme geben könnte, wenn ein VB kontrolliert, da ich nicht denke, dass dessen Qualitätsansprüche, wenn er kontrolliert, unter denen der Leute mit patrol liegt. Zumindest nicht so, dass es zu einer merklichen Qualitätslücke in meinen Augen kommen würde und hier die Vorteile den Risiken überwiegen. Ansonsten würde Tai's Punkt mit der Kommunikation zum Tragen kommen, die in meinen Augen eh unerlässlich ist. -- Liebe Grüße, Moltres 146.gif 12:14, 19. Aug. 2016 (CEST)

Umsetzung

Laufende Abstimmungen

Ping an alle stimmberechtigten User: Akuroma, Buoysel, Chrizz, GoPika, Impoleon xy, Isso08-15, Jass, Jones, Killuu, Korvel1, MattiBob, Matze, Maxmiran, Mecanno-man, Moltres, Pk-fan, RobbiRobb, Saywhaat, Shadowtweaker, Skelabra2509, Snackhound, Taisuke, Xavier, Ale Vidal23, Arrow, Cavana, CLina, Dawth, Der Sternendiamantritter, Flastanarbo, Jaru, Maxnet, Meow (th), Metoschy, Ninjatom Smaragd, NintendoFan214, Pokénator, Ryuichi, Swampert, Traslaugen, 詹玮键

Projektkoordination

Im Folgenden soll über die Frage abgestimmt werden, ob der Posten des/der Projektkoordinatoren/rin eingerichtet werden soll, welcher die Projekte bei der Qualitätssicherung unterstützen soll und bereits mit Vorarbeit und anderen noch näher zu bestimmenden Aufgaben beginnen kann. Dies wird als der erste Schritt zu einer effizienten QS verstanden.

Vorlage:Celer1

Der Projektkoordinator soll eingeführt werden

  1. Ich denke, ein Projektkoordinator, welcher den Gesamtüberblick über die Projekte besitzt und ihnen bei der konzeptionellen Arbeit unterstützend unter die Arme greifen kann, wäre ein großer Gewinn für das Wiki und sollte am besten gestern mit den Vorarbeiten zur QS anfangen, wie beispielsweise klare Zuordnung von Artikeln zu Projekten. Ich sehe keinen Grund, dies aufzuschieben! 674.png Maxmiran 14:57, 19. Aug. 2016 (CEST)

Der Projektkoordinator soll nicht eingeführt werden

Enthaltung

Kommentare

Hallo zusammen! Mir fällt auf, dass die Debatte hier sehr umfangreich ist und einige Diskutanten (mich eingeschlossen) dadurch abschreckt und deshalb bisweilen wieder etwas einschlummert, obwohl eigentlich eine flotte Umsetzung schön wäre. Ich möchte daher vorschlagen, die QS nicht als Gesamtpaket auszudiskutieren, sondern sie auf Zwischenschritte herunterzubrechen, um einerseits die Komplexität einzelner Abstimmungen nicht zu überlasten. Andererseits wirken sich Zwischenschritte auch auf die Motivation aus, am Ball zu bleiben, weswegen ich das wichtig finde.

Als erste Frage würde ich hier die Projektkoordination vorschlagen, da dieser Posten wichtig für die Durchsetzung der QS ist und für notwendige Schritte zur Vorarbeit, wie die Zuordnung von Seiten zu Projekten, bedeutsam ist. Für mich wirkt es so, als sei die Einführung der PK relativ unstrittig, aber es wird wohl sinnvoll sein, hier doch eine Abstimmung zu starten und über eine Besetzung der Stelle zu debattieren. Der oder die PK kann sich dann mit den Projekten an die ersten Vorarbeiten machen. Seid ihr damit einverstanden? Die konkrete Ausgestaltung des Postens kann ja nachträglich immer wieder abgewandelt werden, sollte es nötig sein. 674.png Maxmiran 15:42, 12. Aug. 2016 (CEST)

Also ich habe mir jetzt den ganzen Textwall auch noch einmal zu Gemüte geführt und sehe das wie Max. Alles gleich auf einmal würde wohl zu viel des Guten werden, da es auch irgendwo unübersichtlich wird. Ich würde daher auch vorschlagen wollen, dass man dies Step by Step macht, allerdings dann dort mit relativ kurzen Intervallen arbeitet, sodass man hier über Teilabstimmungen/diskussionen (k.A. Personelle Besetzung etc.) zeitig eine Komplettlösung für das QS-System findet. Es kommt (gefühlt schon) wieder etwas zum Erliegen und ich wäre nun auch dafür, dass man zumindest den Punkt mit den PKs in den nächsten Tagen (wenn es sein muss Wochen) geregelt bekommt. Mit dem Vorschlag, mit der PK anzufangen, würde ich somit voll und ganz mitgehen wollen, da mir dies in Anbetracht der Diskussion hier auch am sinnvollsten erscheint. -- Liebe Grüße, Moltres 146.gif 12:05, 19. Aug. 2016 (CEST)

Bisher beschlossene und umgesetzte Punkte

Bisher keine.

Frustration

Es mag ja sein, dass ich inaktiv bin, aber das gilt nicht für alle von euch. Gerade von den Admins bin ich e sehr enttäuscht. Ein (aktiver!) Admin wird es innerhal b von 2 Wochen doch wohl schaffen, hier seibe Gedanken zum Thena zu äußern?? Adminiatrator ist kein Orden, mit dem man sich cool fühlen ubd zurücklehnen kann, wenn es um wichtige Entscheidungen geht, manche scheinen gar zu meinen, dass eh nichts an ihnen vorbei entschieden werden kann. Also kriegt endlich mal den Arsch hoch ubd arbeitet euch in die QS ein, Admins und Redakteure! Ein erschütteter Gruß aus Mecklenburg, verfasst von 609.png Skelabra2509 (Diskussion | Beiträge) 09:56, 16. Aug. 2016 (CEST)