PokéWiki:Allgemeine Diskussionsseite/Qualitätssicherung

Aus PokéWiki
Zur Navigation springen Zur Suche springen
Diese Diskussion ist fürs Erste abgeschlossen. Das Modell von shadowtweaker wurde beschlossen inklusive einer Projektkoordination, die shadowtweaker und Taisuke übernehmen.

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)

Zusatz: Ich hatte ganz vergessen zu präzisieren, was ich mir in diesem Modell unter oberflächlicher Kontrolle vorgestellt habe. Ich bin eigentlich dafür, schon noch möglichst detailliert zu kontrollieren, damit sich der ganze Verwaltungsaufwand auch lohnt, aber eben auch ein Gleichgewicht zu lückenloser Kontrolle zu halten. Änderungen sollten also vollständig geprüft werden, wenn dies mit geringem Aufwand möglich ist; damit eingeschlossen sind in der Regel Änderungen an einzelnen Daten und sprachliche Korrekturen, aber auch größere Datenänderungen, wenn die Daten leicht abzugleichen sind. Ein Modell für die Eingangskontrolle muss aber auch mit umfangreichen Änderungen umgehen können und hierfür ist es wie oben begründet nötig, oberflächliche Kontrolle zu verwenden. Wenn sich beispielsweise ein Neuling an einem Spezies-Abschnitt versucht, dann kann man den Abschnitt nicht mal eben so perfektionieren. Ziel sollte hier eher sein, ein „kann man erstmal so stehen lassen“-Niveau zu erreichen, d. h. sprachlich und konzeptionell zu prüfen und inhaltlich zu überfliegen, ob es sinnvoll ist, was dort steht. Ein anderes Beispiel sind Zitatesammlungen, das sind zwar ausschließlich aus den Spielen entnommene Daten, aber eben so viele, dass es zu aufwändig wäre, alles komplett zu prüfen. Hier ist es fürs Erste zufriedenstellend zu prüfen, ob die Darstellung stimmt, ob es sorgfältig gemacht wurde oder ob man schon beim Überfliegen viele Tippfehler findet, und ob es inhaltlich plausibel erscheint. – shadowtweaker 11:40, 20. 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. --Mecanno-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. --Mecanno-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 https://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... --Mecanno-manMäh 12:53, 4. Aug. 2016 (CEST)
Nach einigen Diskussionen im Chat hab ich mal ein neues Modell hinzugefügt. --Mecanno-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 ~ ~ 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. --Mecanno-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)
Erstens: Ich bin erstaunt, wie sehr doch diese Diskussion voll Leidenschaft und Wille sprudelt. Das freut mich sehr!
Punkt zwei: Mich hat die länge der Seite, so voller Text und "trocken", ziemlich abgeschreckt. Und würde ich nicht beruflich bedingt alleine am Freitag Abend rum sitzen (bitte... kein Mitleid...), hätte ich mich wohl auch nicht erst beteiligt. Solche umfangreichen Diskussionen sind - vor allem in diesem Fall - notwendig, sollten aber nicht die Regel werden. Logisch: das lässt sich natürlich nicht auf eine Abstimmung reduzieren.
Nun zum inhaltlichen: Ich fasse alle angesprochenen Modelle als sehr ähnlich auf und halte Shadows Modell für das am meisten ausgeschriebenste davon (Qausi die M-Theorie unter den Stringtheorien zwinker3.gif). Ich halte das Modell für sehr vielversprechend!
Eine wichtige Sache noch: Aufgrund der sich andeutenden größeren Verantwortung (möglicherweise mit auch etwas mehr Zeitaufwand) würde ich Personalunionen von Projektleitern strikt ausschließen. In meinen Augen sollte ein Benutzer nicht Leiter von zwei Projekten sein. Egal, wie klein die Projekte auch seien. Ein Porjektleiter könnte dann natürlich weiterhin "normales" Mitglied in einem anderen Projekt sein, aber ohne Verantwortung (Unterleiter, Leiter). Meine Einschätzung! Gut Dung will Weile haben MattiBob Diskussion 00:04, 20. Aug. 2016 (CEST)
@MattiBob: Interessante Idee, würde ich aber ablehnen, denn wir haben sowieso schon Probleme Projekte zu besetzen, es kommt uns also gerade recht, wenn jemand dazu in der Lage ist, mehrere Projekte gleichzeitig zu leiten.
Ich habe zu meinem Modell mal noch etwas zum Thema der oberflächlichen Kontrolle hinzugefügt, das hatte ich leider vergessen und dadurch wohl das ein oder andere Missverständnis verursacht. Vielleicht hilft das auch dem ein oder anderen, der bei oberflächlicher Kontrolle noch ein mulmiges Gefühl hat, sich mit meinem Modell anzufreunden. Auch hierzu ist natürlich Rückmeldung willkommen. – shadowtweaker 12:10, 20. Aug. 2016 (CEST)
Das ist mir durchaus bewusst, dass es schwer sein wird, genügend "passende" User für die Projektleitungen zu finden. Doppelte Besetzung halte ich aber für brandgefährlich. Ich befürchte ein immer größer werdendes Ungleichgewicht in der Qualität der Projekte und dass uns das dann komplett aus der Hand gleitet, Frustration aufkommt (weil: "In der Ecke sieht's total dreckig aus. Warum soll ich mir ein Bein ausreißen, um meine sauber zu halten?!") ... Unterschätzt bitte nicht den Zeitaufwand, der kommen könnte. Ich könnte mir auch vorstellen, dass ein "großes" Projekt nur mit einem "kleinen" kombiniert werden darf. Dann wäre die Wahrscheinlichkeit reduziert, dass ein User zwei Projekte betreut, die beide viel Zeit und Ressourcen benötigen.
Mein Kommentar klingt schwarz-malerischer als er wirklich sein soll. Ich versuche nur so viel wie möglich schonmal zu bedenken und darauf vorbereitet zu sein, schonmal angesprochen und drüber nachgedacht zu haben. Gut Dung will Weile haben MattiBob Diskussion 17:48, 20. Aug. 2016 (CEST)
Qualitatives Ungleichgewicht kann ein Problem sein, ja, aber da gibt es keinen direkten Zusammenhang zu doppelter Besetzung. Wenn ein Projektleiter seinen Pflichten nicht nachkommt, dann wird die Projektkoordination einschreiten, egal, wie viele andere Projekte dieser Benutzer sonst noch leitet. Und umgekehrt, wenn jemand mehrere Projekte zufriedenstellend leiten kann, wäre es kontraproduktiv, ihm das zu verbieten. – shadowtweaker 14:02, 21. Aug. 2016 (CEST)
Dann muss die Projektleitung da auf jeden Fall kontrollieren und ein Auge darauf haben. Wir erwarten dann - zu Recht - immer größere Verantwortungen von den höheren Positionen. Hoffentlich können wir und die Benutzer in diesen Positionen denen auch gerecht werden... *Skepsis ende* Gut Dung will Weile haben MattiBob Diskussion 14:11, 21. Aug. 2016 (CEST)

Ich erläutere mal meine Sicht zum Thema change tags. In unserem Fall geht es ja darum, mit change tags die Leiter eines bestimmten Projektes auf zu prüfende Änderungen aufmerksam zu machen. Hier gibt es prinzipiell erstmal zwei Möglichkeiten, wie man change tags verwenden möchte, punktuell oder flächendeckend. Mit punktuell meine ich, dass man nur vereinzelt und unterstützend change tags setzt, wenn eine Bearbeitung ganz besonders fragwürdig ist oder die Wahrscheinlichkeit hoch ist, dass sie übersehen wird, aber dass das Qualitätssicherungsmodell nicht auf change tags angewiesen ist. Punktuelle Nutzung finde ich okay, wäre meiner Meinung nach aber schöner, das einfach per Kommunikation zu lösen und beim Benutzer der Wahl mal nett anzufragen, ob er sich das mal ansehen könnte. Flächendeckend hingegen wäre, dass change tags eine komplette Liste an zu prüfenden Änderungen bereitstellen sollen. Auf zwei größere Nachteile davon möchte ich aufmerksam machen.

Erster Punkt ist der Klickaufwand: Beim Prüfen einer Änderung schaut man ja auf den Versionsunterschied, für die Kontrollmarkierung ist direkt dort eine Schaltfläche angebracht, also nur ein Klick, für die change tags muss man dagegen die Versionsliste aufrufen, bei der betroffenen Version einen Haken setzen, dann auf Markierungen bearbeiten gehen, dort dann glaube ich irgendwie aus allen möglichen change tags die richtigen auswählen und die Tags abspeichern, das ganze muss dann die Projektleitung wieder rückgängig machen. Auf die Dauer kommt da schon einiges an zusätzlichem Verwaltungsaufwand zusammen, gerade wenn jemand viele Bearbeitungen nach demselben Schema tätigt.

Zweitens sollte man bedenken, dass bei flächendeckender Kontrolle das Vier-Augen-Prinzip für Bearbeitungen von Benutzern mit autopatrol außer Kraft gesetzt wird, denn für die setzt niemand change tags – es sei denn, man verpflichtet alle Benutzer mit autopatrol dazu, ihre eigenen Bearbeitungen mit change tags zu versehen, was ich für absurd halte. Mec versucht in seinem Modell, dieses Problem dadurch zu lösen, dass Projektleiter ebenso wie in meinem Modell selbstständig die Bearbeitungen in ihrem Zuständigkeitsbereich zu prüfen, aber das ist dann ja doppelt gemoppelt und zwar nicht von der Sorte "doppelt hält besser", sondern von der kontraproduktiven Sorte, denn wenn man selbstständig prüft, dann braucht man change tags nicht und es nervt, sie beseitigen zu müssen, und umgekehrt, wenn man sich an den change tags orientiert, hat man keine Lust mehr, nach dem Abarbeiten der change tags noch selbstständig zu prüfen, weil man sich lauter Bearbeitungen nochmal ansieht, die man schon erledigt hat.

Über Reaktionen auf meine Argumentation würde ich mich freuen, damit wir mit dem Austauschen der Argumente vorankommen und uns allmählich auch einer Abstimmung annähern. :) – shadowtweaker 23:54, 22. Aug. 2016 (CEST)

Hey Shadow damit die Diskussion von gerade im Chat nicht untergeht ich frag da gleich mal doof hier beziehungsweise fasse noch einmal zusammen^^ Es geht ja wegen der doppelten arbeit... auch die "kontrolleure" haben doch so ihre Stärken und Schwächen, ist da nicht die kombination von hiddencat und changetags sinnvoll? Durch die Hiddencats hat/sollte ein PL immer die aktuelle Arbeit zu seinem Projekt leichter als über die LÄ im Auge behalten können um so schneller mögliche Änderungen/Neuerungen die ggf. für das gesamte Projekt sinnvoll währen schneller zu erkennen oder gar welche die vor längerem Vorgeschlagen wurden aber aus bestimmten gründen nicht umgesetz wurden um so neuen Usern die ggf. nach dem Prinzip gleich mehrere Artikel ändern darauf aufmerksam machen noch zu warten das es im Projekt abgestimmt wird oder dies vom Projekt so nicht gewünscht ist. Das erstmal zu dem allgemeinen Überblick für die Projekte. So dann gibt es ja generell noch die Patroler selbst, diese sollten meiner Meinung die Vorhut bilden und alles was keiner weiteren Prüfung bedarf abhacken. Zum Beispiel korrekturen weil ein Buchstabe vergessen wurde, ein Link korrigiert wurde etc. da muss mMn keiner ein weiteres mal darüber schauen. Als nächster Schritt sollte dieser schauen ob Gramatikalisch der Artikel stimmt, ihn gegebenfalls ändern (mit dem Vermerk Grammatik korrektur) dann liegt er wieder in den Änderungen das ein anderer Patroler darüber liest und das abhackt. Sollte er bereits vorher Gramatkalisch passen erfolgt inhaltliche Prüfung ist die korrekt dann ist die änderung meiner Meinung als erledigt zu kennzeichnen. Dies kann mittels der chancetags erfolgen. Oder wenn der Petroler der Meinung ist inhaltlich sich unsicher zu sein kann dies mit einem entsprechenden marker ja gekennzeichnet werden so das die PL oder zuständige Person für den Inhaltlichen Abschnitt noch einmal sich den Inhalt anschaut. Wie dies bei komplexen Bearbeitungen aussieht ist da denke auch sinnvoll einen zweiten darüber schauen zu lassen, gerade bei vielen Tabellen die einzelnen Parameter zu prüfen ist etwas was schnell zum Übersehen eines Fehlers in einer Zelle führen kann. Bei zusätzlicher Strukturellen Änderung sollte immer der PL mit einbezogen werden ob dies so gewollt ist oder der Patroler weis bereits ob es schon einmal in dieser Struktur thema war und kann es mit verweis auf den entsprechenden diskussionspunkt wieder zurücksetzen (zurücksetzten ist denke in dem Fall bei derartigem Vermerk nicht erneut zu kontrollieren, da die vorherige Version bereits kontrolliert war). Dadurch wäre er entweder abgehackt oder wieder als geändert in der übersicht für den nächsten Patroler und der nächste schaut drüber ja ist ok und hackt ab oder es liegt beim PL... das ganze ist ähnlich Mecs Modell ist aber meiner Meinung nur möglich durch die von dir angesprochene Senkung der Rechte. Durch das erneute einschieben in die queue mag zwar auf den ersten Blick meiner Erläuterung ein Mehraufwand entstehen da er aber in kleinere Bereiche gestückelt ist könnten so zeitnaher mehrere Beiträge auch mit der Senkung der Rechte zielführend der verbesserung der QS schneller bearbeitet werden. Ich denke halt nach dem ganzen durchlesen der Einzelnen Modelle und Diskussionen hier (viel Text und nach einiger Zeit vermischt man auch einiges -.-) das alle Modelle ihre stärken und ihre Macken haben und nur eine Kombination der einzelnen Modelle eine Sinnvolle Lösung darstellt die einzelnen Macken sinnvoll zu kompensieren. Auch finde ich wenn jemand Patrolt und er korrigiert/ändert etwas und ein weiterer schaut darüber nicht als schlechterstellung des Patrolers. Im Gegenteil wir sind alles nur Menschen die auch mal etwas überlesen können oder erneut einen Tippfehler verursachen. Daher empfinde ich dies als Mehrwert und es senkt die Wahrscheinlichkeit von Durchrutschern. Wenn der Patroler seine Änderungen im Auge behält und feststellt das seine Änderungen im Großteil i.O. waren ist das doch auch Positiv zu sehen das der vorherige Patroler gute Arbeit geleistet hat. Ich denke das Punktuelle tags für vom Patroler als noch einmal zu Kontrollieren sinnvoll ist und Flächendeckend nur sinn für einen Überblick geben kann. ob dies nur durch Setzen meherer Tags ermöglicht werden kann oder durch die Kombination von hiddencat und chancetag besser zu lösen ist kann ich mangels technischen umsetzungswissen nicht sagen, dies ist rein ein Gedankengang meinerseits dazu. Der von dir angesprochende entstehende Klickaufwand für die tags ist vielleicht störend aber ein sinnvolles störend und ich denke nicht das die zweite Ebene dadurch das ein artikel abgehackt wird oder erneut in der ersten queue landet bevor es zum pl oder weiteren Prüfung geht so starke bzw. viele artikel betreffen wird was einen massiven Klickaufwand verursacht. Da ich die rechte nicht besitzte, verstehe ich auch dieses autopatrol nicht so recht... ist dies ein einfacher blick der sagt ja kann alles so bleiben oder wurde hier nur darauf geachtet das durch die Änderung nichts "kaput" gemacht wurde. Das einmal kurz als Zusammenfassung meiner Sicht, beziehungsweise der angesprochenen Sachen. So dann hoffe ich mal das meine Erläuterungen trotz der Uhrzeit noch nachvollziehbar sind. Gruß Ryu ~ ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 02:01, 23. Aug. 2016 (CEST)
Öh, etwas konfus ist dein Beitrag schon... Ich sehe in deinem Vorschlag keinen Unterschied zu Mecs Modell, außer dass du andeutest, über grammatikalische Korrekturen an einem unkontrollierten Beitrag müsste unbedingt nochmal jemand anderes drüberschauen, worin ich aber keinen Sinn sehe. Ich habe nicht behauptet, dass der Klickaufwand von change tags sinnlos ist, sondern dass er ein erheblicher Nachteil ist gegenüber meinem Modell, das ohne diesen Klickaufwand auskommt. Nehmen wir mal an, ein Neuling tätigt 50 Bearbeitungen im Anime-Bereich, ich schaue sie durch und sie sind grammatikalisch und strukturell alle in Ordnung, aber inhaltlich fragwürdig. Dann müsste ich jede Bearbeitung kontrollieren und für jede einzelne Bearbeitung einen change tag zur inhaltlichen Überprüfung setzen. Fünf Minuten später kommt jemand aus dem Anime-Bereich, sieht, dass das kompletter Murks ist, und macht alle 50 Bearbeitungen wieder rückgängig. Jetzt muss derjenige wieder alle meine change tags entfernen. Und was haben die change tags jetzt gebracht? Überhaupt nichts, ich habe nur meine Zeit verschwendet und die des anderen Benutzers auch. In meinem Modell dagegen hätte ich diese Bearbeitungen nur stichprobenartig angesehen, gemerkt, dass ich das nicht kontrollieren kann, und mich einer anderen Tätigkeit zugewendet, und das Resultat wäre genau dasselbe gewesen, aber mit einem optimalen Klickaufwand, 110 statt 700. 50 Änderungen rückgängig zu machen ist so schon nervig genug, da nochmal den Faktor 6 bis 7 draufschlagen? Ne danke. In einem Modell mit change tags wäre diese Situation nur dann eingetreten, wenn ich zu faul gewesen wäre, mich an der Kontrolle dieser Bearbeitungen zu beteiligen. Aber ein QS-Modell, in dem nur komplette Faulheit zur optimalen Effizienz führt, kann nicht funktionieren. – shadowtweaker 11:30, 23. Aug. 2016 (CEST)
Ich glaub, mein Modell ist nur wegen der Missverständlichkeit von shadows Modell entstanden, hätte ich dieses von Anfang an verstanden, hätte ich das auch so unterstützt, anstelle von selbst ein Modell zu erstellen, welches einen mir bereits beim erstellen bewussten massiven bürokratischen Mehraufwand hat. Zu MattiBob kann ich sagen, das ich mir dieser Problematik bewusst bin, das Problem aber anders und nur teilweise zu lösen versuche: Ich würde am liebsten jedes Projekt (ausser Spin-Off-Unterprojekte) doppelt besetzen (achte auch darauf, das das in „meinen“ der Fall ist), das verhindert einerseits ein Shadixx-Fall, wo der einezige Projektleiter inaktiv wird, heisst aber auch, das die Chance höher ist, das zumindest einer der beiden Leiter im Projekt aktiv ist. Auf Ryuichi gehe ich mal nicht ein, zumal ich vermute, das er anschliessend an seinen Beitrag im Chat über autopatrol aufgeklärt wurde. --Mecanno-manMäh 18:38, 24. Aug. 2016 (CEST)

Kleiner Test von Benutzer:MattiBob

Einleitung

Um mal den Aufwand und das Vorgehen zu testen, habe ich mal soeben geschaut, wie es sich verhält, wenn ich, als verlässlicher Benutzer, kontrollieren würde. Dazu habe ich die Letzten Änderungen geöffnet, die Anzeigeoptionen auf letzten 500 in letzten 30 Tage gestellt und alle Änderungen mit einem "!" kontrolliert. In der Liste befanden sich genau 50 solcher Einträge. Dafür habe ich 25 Minuten gebraucht.

Ergebnis

  • Kontrollierte Änderungen: 50
    • Fehlerhaft: 3
      • Rechtschreibung und Grammatik: 2 --> ausgebessert
      • Fehlende Signatur in einer Diskussion: 1 --> ausgebessert
      • = Ausgebessert: 3
    • Fachwissen benötigt (Japanisch Kenntnisse, Anime-Wissen, ...): 19
    • In Ordnung: 27
      • Namensraum Artikel, Datei, ...: 15
      • Diskussionsbeiträge: 8
      • Benutzerseiten: 4
    • Fragwürdig: 1 (siehe hier)

Versuchsparameter

Auswertung

Als Zeitaufwand finde ich das in Ordnung. Wenn man bedenkt, dass dann jeder verlässlicher Benutzer kontorllieren dürfte, würde sich das auch breiter verteilen.
Fast die Hälfte der Beiträge konnte ich aber nicht inhaltlich kontrollieren. Das war dann nur die von uns diskutierte oberfläche Kontrolle. Da fehlten mir vor allem Japanisch-Kenntnisse (Item-Beschreibungen, PokéDex-Einträge, ...). Aber auch ein neuer Pokémon-Anime Artikel war dabei, den ich halt so überhaupt nicht beurteilen kann. Äußerlich war er in Ordnung.
Über die Änderungen auf Diskussionsseiten kann man noch einmal diskutieren. Müssen die kontrolliert werden, oder reicht es, wenn der betroffene Benutzer auf seiner Seite das dann checkt? Was wäre dann mit Beiträgen auf Diskussionsseiten inaktiver Benutzer?
Letztendlich hätte ich viele Änderungen (19 von 50) markiert und an Projekte / Projektleiter weiter geschoben. Bei einer Änderung sogar einen Redakteur oder Admin angesprochen.
Vielleicht kann ich noch einmal so ein Test machen. Dann können wir den Aufwand und das Vorgehen besser abschätzen.

Freut mich, dass du das mal getestet hast. Es ist aber gar nicht so gedacht, dass du alle diese Änderungen selbst kontrollieren können sollst, deshalb agieren wir ja als ein Team, wo die Schwächen des einen die Stärken des anderen sind. Wenn beispielsweise jemand eine inhaltlich umfangreiche Änderung im Anime-Bereich tätigt und man sich mit dem Anime inhaltlich nicht auskennt, dann überlässt man die Kontrolle dieser Änderung einfach jemand anderem, der sich besser damit auskennt. Mit der Zeit kann man immer mehr kontrollieren, beispielsweise kann ich kein Wort Japanisch, habe mittlerweile aber genug Erfahrung in der Transkription und der Übersetzung mit Wörterbüchern, um die meisten Japanisch-bezogenen Änderungen prüfen zu können. Bei Änderungen im Benutzernamensraum ist es ausreichend, auf Einhaltung der Regeln zu prüfen. – shadowtweaker 16:03, 21. Aug. 2016 (CEST)
Ich wollte einfach mal "alles" testen. Wieviel Zeit man für wieviele Kontrollen aufbringen muss; was ich persönlich überhaupt alles kontorllieren kann; wieviele Fehler kommen überhaupt vor; was würde eine oberflächliche Kontrolle bringen; und und und... Der Test soll als grober Anhaltspunkt für User wie mich dienen, die halt noch nie kontrolliert haben. Aber auch für die jetztigen Redakteure, um zu sehen, wie ein verlässlicher Benutzer mit der Kontrolle zurecht kommen würde.
Ein gutes Beispiel ist der Artikel Mantirps (Anime). Äußerlich kann ich sagen, dass er der Form der anderen Pokémon-Anime-Artikeln entspricht und kein Vandalismus oder Unsinniges enthält. Wie du ja schon richtig sagst: im Endeffekt würde ich den natürlich nicht kontrollieren (können). Die Ergebnisse meines oberflächlichen Drüber-Schauens würde das Projekt ja beim inhaltlichen und genauen Kontrollieren automatisch erhalten. Dieses Szenario wollte ich mit dem Test auch mal nachstellen. Gut Dung will Weile haben MattiBob Diskussion 16:43, 21. Aug. 2016 (CEST)

Nachtrag

Hier wäre mir übrigens der erste Fehler unterlaufen. Diese Änderung habe ich als kontrolliert und "nur" Rechtschreibung / Grammtik ausgebessert gezählt. Wurde dann aber berichtigt.
Die ursprüngliche Änderung hätte ich als abgeschlossen kontrolliert markiert. Und wenn ich die Modelle richtig verstehe, hätte meine Änderung dann niemand mehr kontorlliert. Damit wäre ein Fehler durch das Raster gerutscht.

Gut Dung will Weile haben MattiBob Diskussion 14:19, 21. Aug. 2016 (CEST)

In meinem Modell wäre das ein Kontrollfehler gewesen, da die Änderung auch inhaltlich hätte geprüft werden müssen, um als kontrolliert markiert werden zu dürfen, – habe kürzlich zu meinem Modell noch eine Erklärung zur oberflächlichen Kontrolle hinzugefügt – wäre aber dank dem Vier-Augen-Prinzip nicht durchs Raster gerutscht, da sich meine Änderung der zweiten Kontrollebene durch die Projekte zuordnen lässt. – shadowtweaker 14:35, 21. Aug. 2016 (CEST)
Dann nochmal zum Verständnis: Alle (!) Änderungen sollen doppelt kontrolliert werden? Erst "oberflächlich" durch einen erweiterten Benutzerkreis; diese ordnen dann die Änderungen einem (oder mehreren?) Projekten zu; die Projekte kontrollieren es dann inhaltlich das zweite mal. So richtig zusammengefasst? Gut Dung will Weile haben MattiBob Diskussion 14:41, 21. Aug. 2016 (CEST)
(wieder bezogen auf mein Modell) Teilweise richtig. Alle Änderungen nicht-verlässlicher Benutzer werden durch die verlässlichen Benutzer oberflächlich geprüft, dann ist ein Grundniveau gesichert. Unabhängig davon prüfen Projektleiter die Änderungen in ihrem Zuständigkeitsbereich. Wie gründlich sie prüfen, können sie der aktuellen Situation im Projekt anpassen. Eine explizite Zuordnung von Bearbeitungen zu Projekten durch change tags ist nicht flächendeckend vorgesehen. Inhaltliche Kontrolle findet bereits im ersten Schritt statt, nur eben bei umfangreichen Bearbeitungen nicht bis ins letzte Detail. Die Projektleiter können dann flexibel entscheiden, ob sie solch eine Bearbeitung genauer prüfen wollen, oder ob es gerade wichtigere Baustellen gibt. – shadowtweaker 15:10, 21. Aug. 2016 (CEST)
Ah okay, verstehe. Sorry für die Nachfragen, ich habe das alles zwar einmal gelesen, aber da konnte ich mir dann doch nicht mehr alles merken und richtig zuordnen ;). Das heißt: ich, als Kontrolleur würde mir über die Zweitkontrolle keine Gedanken machen müssen. Wenn es in ein Projekt fällt, entscheidet und prüft die Leitung. Auf meinen Test bezogen, würde das bedeuten, die Projekte hätten von den 50 Kontrollen nochmal einen Großteil kontrolliert, egal, wie ich die Änderung eingeschätzt habe. Gut Dung will Weile haben MattiBob Diskussion 15:21, 21. Aug. 2016 (CEST)
Genau, und du hättest für die Projektleiter dann eben schon mal Vorarbeit geleistet. ;) Es gibt überhaupt keinen Grund sich zu entschuldigen; für Benutzer, die noch nie kontrolliert haben, ist es wirklich nicht so einfach, sich in dieses Thema einzuarbeiten. – shadowtweaker 15:57, 21. Aug. 2016 (CEST)

Fazit

So, die Diskussion ist zum Erliegen gekommen, niemand scheint mehr Argumente austauschen oder ein neues Modell aufstellen zu wollen. Momentaner Stand ist jetzt, dass vier Modelle von vier Benutzern, inklusive mir, zur Auswahl stehen. Von diesen vier Benutzern, die sich tiefer mit dem Thema befasst haben, bevorzugen inzwischen alle mein Modell, was ja mehr oder weniger heißt, dass die drei anderen ihren eigenen Vorschlag zurückziehen und mein Modell als einziges übrig bleibt. Und auch von den übrigen Benutzern haben viele, insbesondere alle aktiven Administratoren, ausgesagt, dass ihnen mein Modell gefällt, kein einziger Benutzer hat heftig protestiert. Aus meiner Sicht hat sich eine Abstimmung damit erübrigt und ich möchte vorschlagen, dass wir uns die Zeit für eine Abstimmung sparen und mein Modell ohne weitere Abstimmung beschlossen wird. Schließlich ist dies keine endgültige Entscheidung, wir können ja erstmal probieren, wie sich das System in der Praxis bewährt, und die Diskussion zu einem späteren Zeitpunkt nochmal aufgreifen, ein Schritt in die richtige Richtung ist es auf jeden Fall schon mal. Außerdem gibt es das ein oder andere Thema, das wir auch noch durchbringen sollten, bevor Sonne und Mond erscheinen, angefangen mit der Hauptseite. Gibt es dagegen Einwände? – shadowtweaker 15:17, 27. Aug. 2016 (CEST)

Hey kann mich dem nur anschließen, unklare Punkte haben wir ja bereits weitläufig in dieser Diskussion und auch im Chat geklärt. Zweifel am PK bestehen meinerseits nur wenn es lediglich einen PK gibt und ich tendiere hier wirklich für mindestens zwei. Da es auch seitens der Einführung des PK kein Kontra sondern lediglich enthaltung aufgrund skepsis gab, bin ich ebenfalls der Meinung das Thema kann abgeschlossen werden und man sollte eine Zeitnahe Eigennominierung zum PK starten. Und da du ja eh so tief in der Materie steckst hoffe ich der Name shadowtweaker steht mit ganz oben. Gruß Ryu ~ ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 15:50, 27. Aug. 2016 (CEST)
Ich habe keine Einwände, bei solch einer wichtigen Entscheidung sollte jedoch IMHo noch mal rumgepingt werden: @Akuroma, Buoysel, Chrizz, Der Sternendiamantritter, GoPika, Impoleon xy, Isso08-15, Jass, Jones, Killuu, Korvel1, MattiBob, Matze, Maxmiran, Mecanno-man, Moltres, Pk-fan, RobbiRobb, Ryuichi, Saywhaat, shadowtweaker, Skelabra2509, Snackhound, Taisuke, Xavier, Ale Vidal23, Arrow, Cavana, CLina, Dawth, Flastanarbo, Jaru, Kyubi, Maxnet, Meow (th), Metoschy, Ninjatom Smaragd, NintendoFan214, Philipp S., Pokénator, ProtosHikanios, Swampert, Traslaugen, 詹玮键. -- 609.png Skelabra2509 (Diskussion | Beiträge) 01:03, 29. Aug. 2016 (CEST)
Danke für die Pings, Skel. Dann spreche ich mich an dieser Stelle nun auch "offiziell" für Shadows Modell aus. lg, Arrow https://dl.dropbox.com/s/tb9y2itw4itgs5k/Link.png 01:13, 29. Aug. 2016 (CEST)
Also ich persönlich würde mit dem Vorschlag von shadowtweaker übereinstimmen, sodass wir dieses Modell nun in der Praxis ausprobieren könnten. Den Kritikpunkt mit dem "nur" einen PK können wir ja auch in der Praxis austesten: Wenn shadow merkt, dass es für eine Person zu viel Aufwand wird, kann er ja immer noch um einen Co-Leiter bitten. Ansonsten würde ich gerne auch zum Punkt der überarbeiteten Hauptseite kommen wollen, da ihn ihn auch gerne noch vor SoMo fertig sehen würde. -- Liebe Grüße, Moltres 146.gif 11:51, 29. Aug. 2016 (CEST)
Okay, da bin ich auch für Shadows Modell. --Meow (th) (Diskussion) 15:44, 29. Aug. 2016 (CEST)
Keine Einwände! Gut Dung will Weile haben MattiBob Diskussion 21:11, 29. Aug. 2016 (CEST)
Ich habe auch keine Einwände. Maxnet (Diskussion) 11:56, 2. Sep. 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, CLina, Dawth, Der Sternendiamantritter, Flastanarbo, Jaru, Maxnet, Metoschy, Meow (th), Ninjatom Smaragd, NintendoFan214, Ryuichi, Swampert, Pokénator, Traslaugen, 詹玮键: Sorry, dass der Ping jetzt über mich geht :D -- 380.png RobbiRobb 15:15, 19. Aug. 2016 (CEST)

Wenn es so nicht funktioniert dann setz es doch einfach so 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, CLina, Dawth, Der Sternendiamantritter, Flastanarbo, Jaru, Maxnet, Metoschy, Meow (th), Ninjatom Smaragd, NintendoFan214, Ryuichi, Swampert, Pokénator, Traslaugen, 詹玮键. Gruß Ryu ~ ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 15:34, 19. Aug. 2016 (CEST)

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.

Die Abstimmung dauert 2 Wochen, bis zum 2. September 2016 um 12:00 (Serverzeit). Heute ist der 29.03.2024 14:07 Uhr. Jeder Benutzer, der hier verzeichnet ist, kann eine Stimme abgeben.

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)
  2. Sehe ich wie Maxi und kann mich der Einführung eine PK nur anschließen. Gruß Ryu ~ ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 15:18, 19. Aug. 2016 (CEST)
  3. Definitiv, ohne PK geht es nicht, es gibt genug Projekte, die Probleme haben oder gar inaktiv sind, derartiges könnte eine Projektkoordination verhindern. -- 380.png RobbiRobb 15:23, 19. Aug. 2016 (CEST)
  4. ×Impoleon xy× 15:47, 19. Aug. 2016 (CEST)
  5. *Die Projektkoordination soll eingeführt werden. Würde den Part anfangs ungern einer einzelnen Person aufbürden. Zu einem späteren Zeitpunkt ist dies natürlich wieder neu zu bewerten. ~ Taisuke 136.gif 15:52, 19. Aug. 2016 (CEST)
  6. siehe Taisuke - - Lilia.png "Standing in the Hall of Fame" Lauro.png GoPika Disku 16:04, 19. Aug. 2016 (CEST)
  7. shadowtweaker 16:06, 19. Aug. 2016 (CEST)
  8. -- Liebe Grüße, Moltres 146.gif 18:07, 19. Aug. 2016 (CEST)
  9. Ditto. Es braucht mehr als nur eine überholte Eingangskontrolle um Ordnung und Schwung in das Getriebe der Projekte und der Wiki-Arbeit zu bringen. — mfg Snackhound 058.png 21:34, 19. Aug. 2016 (CEST)
  10. Liebe Grüße Maxnet (Diskussion) 11:43, 20. Aug. 2016 (CEST)
  11. --Chrizz Diskussion 16:19, 20. Aug. 2016 (CEST)
  12. -- 609.png Skelabra2509 (Diskussion | Beiträge) 19:30, 21. Aug. 2016 (CEST)
  13. --Mecanno-manMäh 18:06, 24. Aug. 2016 (CEST)
  14. Mal ganz davon abgesehen, dass sich immernoch keiner gemeldet hat, der das machen möchte... Gut Dung will Weile haben MattiBob Diskussion 20:59, 24. Aug. 2016 (CEST)
  15. Eine tolle Idee, mehr gibt es da nicht dazu zu sagen. lg, Arrow https://dl.dropbox.com/s/tb9y2itw4itgs5k/Link.png 16:42, 27. Aug. 2016 (CEST)
  16. https://i.imgur.com/3oTCc8c.png Jaru Bei Fragen 151.png 22:53, 29. Aug. 2016 (CEST)

Der Projektkoordinator soll nicht eingeführt werden

Enthaltung

  1. Ich habe keinerlei Ahnung, welche Vorteile das mit sich bringen würde, ebenso wie Nachteile. Die logische Konsequenz ist meine Enthaltung. Achja, Skelabra, du bist inaktiv. Grüße von einem Inaktiven, der es ja wissen muss --Xavier 19:20, 19. Aug. 2016 (CEST)
    Leck mich. Aber mit Inaktivität kennst du dich ja aus. -- 609.png Skelabra2509 (Diskussion | Beiträge) 19:30, 21. Aug. 2016 (CEST)
  2. Ich bin etwas skeptisch... 360.png Das Isso 08/15 Konter 14:30, 21. Aug. 2016 (CEST)
    @Isso08-15: Siehst du denn Nachteile in der Projektkoordination (und wenn ja, welche?) oder bist du skeptisch bezüglich der Vorteile, die man sich durch die Projektkoordination erhofft? – shadowtweaker 14:38, 21. Aug. 2016 (CEST)
    Letzteres. 360.png Das Isso 08/15 Konter 14:47, 21. Aug. 2016 (CEST)
    Die Projektkoordination würde dich zum Beispiel bei den Einzelartikeln für Items konzeptionell unterstützen. Wäre das nicht hilfreich? – shadowtweaker 15:02, 21. Aug. 2016 (CEST)
    @Isso08-15: Tut mir leid, dass ich hier so nachbohre, wo du dich extra getraut hast zu sagen, dass du skeptisch bist, aber die Projektkoordination ist für mich eben seit Monaten die Grundlage all meiner Überlegungen, wie sich der Inhalt und das Teamwork im PokéWiki verbessern lässt, und die Vorteile sind in meinen Augen extrem groß, deshalb möchte ich unbedingt verstehen, was deine Skepsis auslöst. – shadowtweaker 10:05, 22. Aug. 2016 (CEST)
  3. Hat zwar seine Vorteile, aber ich bin mir nicht sicher, ob eine Person/zwei Personen alle Projekte in ihrer Tiefe überblicken und "bewerten" können. --Toben des Meeres. Killuu https://i.imgur.com/5kAfY2r.png 21:34, 25. Aug. 2016 (CET)

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)
Bevor ich abstimme: Euren Elan in allen Ehren, aber gibt es denn überhaupt jemanden (ich spreche ♀ und ♂ an), dem diese Verantwortung bewusst ist, der dem gewachsen ist, der das dann auch über längere Zeit durchziehen würde, der auch schon eine Gewisse Instanz bei den Projektleitern und Nutzern hat, der sich das vorstellen kann, der das möchte...???? Ein nachträgliches Hin und Her können wir uns - meiner Meinung nach - nicht leisten. Gut Dung will Weile haben MattiBob Diskussion 00:29, 20. Aug. 2016 (CEST)
Hey MattiBob, da sich Shadow bereits intensiv mit der Materie befasst hat halte ich ihn für einen guten Kandidaten vorausgesetzt er bekommt es getimed und wir verlieren keine wertvollen Recourcen. Da auch Robbi viel Engagement generell im Wiki gezeigt hat würde er mir als Kandidat auch einfallen. Aber ob er sich das zutraut oder sich geeignet für die PK sieht kann ich nicht sagen. Bevor die Entscheidung über die PK also getroffen wird sollten wir hier noch einen Unterpunkt mit Nominierung einführen in welchem Jeder User der es sich zutraut seinen Namen innerhalb der nächsten Tage einträgt. Wem die QS wichtig ist dem wird es mMn möglich sein sich in dieser Zeit einzutragen da er das Thema verfolgt. Sollten sich mehrere für fähig halten kann der PK ja noch mittels Abstimmung bestimmt werden. Gruß Ryu ~ ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 12:16, 20. Aug. 2016 (CEST)
Wenn ein solcher Koordinator eingeführt wird, wäre es ohne Zweifel auch nötig ein Ernennungsprozedere festzumachen. -- 609.png Skelabra2509 (Diskussion | Beiträge) 19:30, 21. Aug. 2016 (CEST)
@MattiBob: Oh, tut mir leid, das hier nicht explizit festgehalten zu haben. Ich wäre natürlich bereit, den Posten zu übernehmen, genauer gesagt warte ich schon über ein halbes Jahr darauf, beispielsweise hatte ich mich beim Chattreffen am 30.01.16 dafür eingesetzt. Leider konnte die Idee damals nicht vollständig überzeugen und die Projektkoordination wurde nur testweise eingeführt, was jedoch nichts Halbes und nichts Ganzes war. Dennoch habe ich in den vergangenen Monaten schon mal ein bisschen Vorarbeit geleistet und das Thema häufig im Chat angesprochen. Die meisten, die für die Projektkoordination abgestimmt haben, wissen daher bereits, dass ich die Projektkoordination gerne übernehmen würde. – shadowtweaker 22:08, 24. Aug. 2016 (CEST)
Kann man die Abstimmung vorzeitig beenden? Ich denke, das Ergebnis liegt auf der Hand. :) Jedoch ist ja die Besetzungsdiskussion schon losgebrochen parallel, weshalb es auch nicht tragisch wäre, die fristgerecht auslaufen zu lassen. 674.png Maxmiran 12:42, 28. Aug. 2016 (CEST)

Abschluss vorgeschlagen am 27.08. > Gilt dieser Punkt nun offizell als erledigt? Gruß Ryu ~ ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 14:40, 2. Sep. 2016 (CEST)

Besetzung der Projektkoordination

Aufgrund des bisherigen Abstimmungsverlaufs scheint es nicht verfrüht zu sein, dass wir uns schon mal genauer der Frage widmen, welche Benutzer für die Projektkoordination in Frage kommen und wie die Besetzung schlussendlich festgelegt werden soll, falls sie eingeführt wird. Unterschiedliche Meinungen gab es bisher dazu, ob die Projektkoordination aus einem, aus zwei oder gar aus drei Benutzern bestehen soll. Außerdem sollten sich hier mal alle Benutzer melden, die bereit wären, die Projektkoordination zu übernehmen, bisher bin ich da der einzige. – shadowtweaker 17:19, 27. Aug. 2016 (CEST)

Ich kann mir nicht vorstellen, dass es möglich ist, dass nur eine Person alles alleine schafft. Zumindest zu Beginn, in Zukunft ist es eventuell möglich, dass man das ganze reduziert. Zu Beginn kann es aber unmöglich von einer einzigen Person umgesetzt werden, selbst von Shadow nicht, zumindest nicht ohne, dass er auf alles andere verzichten muss und dadurch sonst nichts mehr zum Wiki beitragen könnte emot-giggle.gif Ich wäre übrigens auch durchaus bereit zu helfen, wäre aber nicht unglücklich, wenn ich nicht offiziell dazugehören würde, ich würde natürlich trotzdem irgendwie etwas dazu beizutragen versuchen zwinker3.gif Und jetzt sollte ich mit diesen komplizierten Formulierungen aufhören, ich hab nämlich nichtmal Ahnung, ob es alles korrekt ist nervous.gif -- 380.png RobbiRobb 17:40, 27. Aug. 2016 (CEST)
Ich denke auch, dass eine Einzelperson wohl kaum alle Aufgaben alleine bewältigen kann, insofern wäre ein kleines "Team" schon sinnvoll. Grundsätzlich hätte ich selbst Interesse daran, da das aber aufgrund meiner violetten Farbe wohl kaum möglich sein wird, würde ich mich zumindest als Unterstützung anbieten, falls denn eine gebraucht wird. lg, Arrow https://dl.dropbox.com/s/tb9y2itw4itgs5k/Link.png 18:02, 27. Aug. 2016 (CEST)
um die Frage von Arrow aufzugreifen. Welche Mindestanforderungen des Rang sollte jemand mitbringen um sich selbst aufstellen zu dürfen? SB, VB PL? Gruß Ryu ~ ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 18:15, 27. Aug. 2016 (CEST)
Projektleiter zu sein wäre eine sinnvolle Mindestanforderung, denke ich, denn für jemanden, der noch nie ein Projekt geleitet hat, wird es extrem schwer werden, sich in mehreren Projekten gleichzeitig konzeptionell auf ähnlichem Niveau zu bewegen wie die jeweiligen Projektleiter, deren ausgewiesenes Spezialgebiet das immerhin ist, zum Teil seit mehreren Jahren. Gleichzeitig sollte ein Projektkoordinator selbstverständlich aber auch möglichst breit angelegt sein. – shadowtweaker 18:43, 27. Aug. 2016 (CEST)
Man sollte aber in diesem Zusammenhang vielleicht noch anmerken, dass es eventuell nicht ganz ideal ist, wenn alle Plätze wieder von PLs besetzt werden, denn dann findet im Grunde nur die Umbenennung eines gewissen Tätigkeitsbereiches statt. lg, Arrow https://dl.dropbox.com/s/tb9y2itw4itgs5k/Link.png 18:52, 27. Aug. 2016 (CEST)
Denke auch, dass die Personen mindestens Projektleiter sein sollten, bzw. mal Projektleiter waren. Damit die Projektkoordination eben auch Erfahrung mit der Organisation von Projekten hat. Da ich ja zeitlich ein kleines Problem habe und dementsprechend leider nicht sehr aktiv, stelle ich mich hier nicht zur Wahl ;) Wollte aber gerne shadows Meinung unterstützen bzw. ergänzen. Lg --Kein Dschungel zu dicht... Killuu https://i.imgur.com/acgb9YG.png 20:24, 27. Aug. 2016 (CET)
Finde auch, das das mindestens zwei Personen machen sollten. Ich lasse das aber mal lieber Leute machen, die sich nicht schon Wiki-Ziele bis 202X gesetzt haben - ansonsten wird der TCG-Bereich noch 2030 nicht in allen Bereichen aktuell sein. --Mecanno-manMäh 00:31, 28. Aug. 2016 (CEST)
Dem schließe ich mich an, vielleicht sollte man (zumindest am Anfang) sogar über drei Leute nachdenken, die sich darum kümmern, da es doch relativ viel Arbeit sein dürfte, alle Projekte durchzugehen, du analysieren, welche Probleme es gibt und sich evtl. Gedanken darüber zu machen, wie diese Probleme gelöst werden könnten. Als Voraussetzung würde ich ebenfalls Projektleiter vorschlagen, um genauer zu sein würde ich sogar ehemalige Projektleiter bevorzugen, weil sie eben die nötig Erfahrung haben, aber auch keinem Projekt verpflichtet sind und sich ganz auf diese Aufgabe konzentrieren können. Allerdings dürfte es wohl etwas schwer sein, solche Leute zu finden. -- lg 359.png Korvel1 Diskussion 12:06, 28. Aug. 2016 (CEST)
Drei Leute fände ich zu viel. Bei der Zusammenarbeit mit den Projekten soll ja eine persönliche Atmosphäre aufgebaut werden und nicht gleich ein ganzes Inspektionsteam anrücken. Außerdem müssen doch nicht gleich alle Projekte auf einmal detailliert durchgegangen werden, mit Sonne und Mond werden Spin-off-, Anime-, Manga- und TCG-Projekt erstmal in den Hintergrund geraten. Falls die Projektkoordination tatsächlich überlastet sein sollte, kann man immer noch jemanden mit ins Boot holen. – shadowtweaker 12:32, 28. Aug. 2016 (CEST)
Bin natürlich für shadow, wenn er sich schon freiwillig meldet und denke auch, dass er Unterstützung braucht. Vielleicht kann ja shadow alleine der "oberste" Koordinator sein, während ein oder zwei ihn einfach unterstützen und helfen. Dafür müssten diese Helfer auch keine höheren Anforderungen haben, als Erfahrung mit einem Projekt als Leiter oder auch Co-Leiter. Ich selbst kann mich übrigens nicht anbieten, da ab 1. September bei mir wieder Lernstress ansteht und ich erst einmal mich selbst organisieren muss, bevor ich hier was organisieren kann^^ - - Lilia.png "Standing in the Hall of Fame" Lauro.png GoPika Disku 12:41, 28. Aug. 2016 (CEST)
Drei finde ich auch zuviel, aber zwei sind doch eine nette Doppelspitze, die dafür sorgt, dass die PK am Laufen bleibt, sollte einer mal im Urlaub sein etc. Ich denke, bei der Besetzung sollte man nicht nur auf die Einzelqualifikation gucken, sondern auch, wie die beiden PKs miteinander können und harmonieren. 674.png Maxmiran 12:42, 28. Aug. 2016 (CEST)
Obwohl ich anfangs skeptisch gegenüber dieser Idee war, als sie Ende Januar im Chattreffen thematisiert wurde, kann ich nun Monate später sagen, dass ich hinter ihr stehe und sehr viel Potential für uns darin sehe. Des Weiteren werfe ich meinen Namen einfach mal in die Runde, da ich es mir ebenfalls gut vorstellen könnte als Koordinator tatkräftig an der Umsetzung des Ganzen mitzuwirken. ~ Taisuke 136.gif 11:20, 29. Aug. 2016 (CEST)

Damit haben sich nun alle etwas aktiveren Projektleiter hier gemeldet, von denen ich nicht anderweitig erfahren habe, dass sie die Projektkoordination eher nicht übernehmen möchten. Robbi, Tai und ich haben uns daraufhin zusammengesetzt und einvernehmlich entschieden, dass ich und Tai die Projektkoordination übernehmen werden. Robbi hält sich bereit und würde als dritter Projektkoordinator zu uns stoßen, wenn sich abzeichnen sollte, dass ein solcher benötigt wird. Falls es beim gegenwärtigen Stand der Abstimmung bleibt, hoffen wir, dass diese Entscheidung im Sinne derjenigen ist, die sich für die Einführung einer Projektkoordination ausgesprochen haben, sowie auf eine gute Zusammenarbeit mit den Projektleitern! – shadowtweaker 19:39, 29. Aug. 2016 (CEST)

Halte ich für eine super Besetzung! Viel Spaß und Erfolg bei diesem durchaus interessant und spannend klingenden Posten zwinker3.gif! Gut Dung will Weile haben MattiBob Diskussion 21:10, 29. Aug. 2016 (CEST)

Bisher beschlossene und umgesetzte Punkte

Die Vergabe der patrol-Rechte an verlässliche Benutzer wurde jetzt pünktlich zum Beginn des großen Eintragens umgesetzt. – shadowtweaker 09:26, 17. Nov. 2016 (CET)

Status Quo

Hallo zusammen, seit dem Abschluss zur Wahl der PK ist hier kein Voranschreiten erkennbar. Wie ist der aktuelle Status? Speziell auch in den geplanten Änderungen der Kontrollanforderungen und Rechtestruktur? Gruß Ryu ~ ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 15:27, 31. Okt. 2016 (CET)

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)