PokéWiki:Allgemeine Diskussionsseite

Allgemeine Diskussionsseite Zweck dieser Seite ist es, die Gestaltung und Organisation des Wikis zentral zu diskutieren. Wenn ihr neue Ideen für das Wiki habt, könnt ihr hier die Meinungen anderer User in Erfahrung bringen oder eine Abstimmung abhalten. Ebenso können hier Lösungen für akute Probleme im Wiki gemeinsam gesucht werden. Zusätzlich liefert euch diese Seite die Möglichkeit, mit den Admins in Kontakt zu treten. Wenn ihr eine konkrete Anfrage an sie habt, macht dies im Abschnittstitel kenntlich.

+

Vorhandene Archivierungen: 2012 • 2012-2 • 2013 • 2014 • 2015 2016 • 2017 • 2018 • 2019 • 2020 2021 • 2022 • 2023 - zuletzt archiviert von * Ryuichi ~ Datei:Sugimori 004.pngPL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 13:25, 21. Mai 2020 (CEST)

Gestaltung der Stellenanzeigen/Ausschreibungen

→ vorrausgegangene Abstimmung

Hallo!
Vor Kurzem ergab die Abstimmung über die Einführung von Stellenanzeigen bzw. Ausschreibungen auf unserer Hauptseite, dass tatsächlich ein Bedarf für solche da zu sein scheint. Deshalb soll es in dieser Diskussionsrunde darum gehen, wie eine solche Box denn ganz konkret gestaltet und ausgeführt werden soll.
Die zu klärenden Fragen sind:

1. Wie sieht das Layout der Box aus?
2. Welche Hauptseiten-Position hat die Box?
3. Wer darf die Vorlage, die zur Box gehört, bearbeiten?
4. Was darf/muss alles in die Box?

Als Diskussionsbasis möchte ich hier nochmals meine beiden Beispiele einer möglichen Gestaltung anführen: Link zu den Beispielen
Die Antworten meiner Beispiele auf die oberen Fragen sind:

1. Entwurf 1: Vertikal schmal; horizontal die Seitenbreite ausnutzend // Randfärbung hellrot, im Überschriftenteil mit Gradient // Überschrift: "Gesucht!" am linken Rand; am rechten Rand Links zu Missionsbrett und globaler To-do-Liste // Im Textfeld kursive, gereihte Kurzausschreibungen mit Projektlinks; ganz rechts Großlinse (als visuell-ansprechendes Element)
   Entwurf 2: Vertikal höher; horizontal einer gegenüberliegenden Box angepasst // Randfärbung blau, im Überschriftenteil mit Gradient // Überschrift "Ausschreibungen:" // Im Textfeld rote Überschrift "Gesucht!"; aufgelistete Kurzausschreibungen mit Projektlinks; unten abgesetzt Links zu Missionsbrett und globaler To-do-Liste; rechts ORAS-Ruinenmaniac-Artwork (als visuell-ansprechendes Element)
2. Entwurf 1: unter "Willkommen im PokéWiki!" oder über "Aktuelles"
   Entwurf 2:Kein Plan
3. Die Vorlage soll ab dem VB-Rang bearbeitbar sein.
4. Kurzbeschreibungen in Stichpunktform von gesuchten Positionen oder Funktionen. Es soll auch Mitgliederengpässen oder offene Aufgaben in den jew. Projekten aufmerksam gemacht werden, die von Neumitgliedern relativ leicht ausgefüllt/erfüllt werden können.

Nicht nur schriftliche Vorschläge und Einwände, sondern vor allem auch bildlich anschaubare Entwürfe (Testseiten-/Screenshot-Links) sind sehr erwünscht!
-MfG, Kenaz-Hagalaz ^Disku 18:10, 26. Mär. 2019 (CET)

Ich habe Entwurf 1 von Kenaz ein wenig abgewandelt und hier mal in einer "Testumgebung" dargestellt. Da ich noch unschlüssig bei der Farbe des unteren Teils und dem Standort bin, habe ich ein paar toggler eingebaut, dann könnt ihr, wenn ihr wollt euch das anschauen und beurteilen^^. Meine Antworten auf die Fragen:

1. Wie Kenaz' erster Entwurf. Meine Änderungen: der untere Teil ist eine Tabelle um bessere Trenner zu ermöglichen und die Großlinse ist im oberen Teil.
2. Wie bei Kenaz. Die Stellenanzeigen sollten meiner Meinung nach gut sichtbar sein und neben der dominanten Farbe, halte ich es für wichtig, dass man, am PC die Anzeigen ohne runter zu scrollen sehen kann.
3. Erneut wie Kenaz^^. Auf der Hauptseite und auffällig --> mindestens ab VB.
4. Wie Kenaz. Zusätzlich bin ich zur Zeit am überlegen wie man so etwas wie {{Tt}} auch "Smartphone-Nutzer-freundlich" umsetzen kann, um bei Bedarf zu den einzelnen Stichpunkten eine Erklärung abgeben zu können, da die angebenen Punkte sich hauptsächlich (klärt mich auf sollte ich die Haupt-Zielgruppe falsch verstanden haben) an neue Nutzer (und an zukünftige Nutzer) richten und einen relativ einfachen Schwierigkeitsgrad haben sollen. Außerdem könnte man damit ermöglichen auch mal ein bisschen anspruchsvollere Aufgaben mit ausreichender Erklärung zu stellen. --DeXter 21:54, 27. Mär. 2019 (CET)

1. Mir gefällt da jetzt spontan die generelle Richtung von Entwurf 2 besser; finde allerdings dass da zu viel Farbe hervorsticht, hätte mir da einen wesentlich kleineren Rahmen, wenn überhaupt, vorgestellt (das ihr hier schon viel zu früh Farbe in die Diskussion werft, sei mal dahingestellt - so wird sich jetzt nämlich die Hälfte gegen dieses Orange und nicht gegen das Design aussprechen). Oh und um himmels willen, kein tt auf der Hauptseite - ist schon schlimm genug das wir das noch in Artikeln nutzen. Zeitgemäss ist das einfach nicht mehr.
2. Spontaner Vorschlag - und müsste definitiv noch von Killuu und Isso genehmigt werden: über das schon gewusst und dafür das Zeichenlimit von AdW/PdW erhöhen, damit da kein Leerraum entsteht. Haben wir Kapazität dafür aus dem XdW-Bereich? Ich meine mich nämlich erinnern können das früher sich immer darüber beklagt wurde dass die Zeichenlimite da zu kurz sei.
3. Es is sinnlos es PLs zu verbieten und SB und alles drunter traue ich dieses Recht nicht zu - ist immerhin die Hauptseite. Folglich Entweder VB+ oder PL+ - was genau hängt vor allem von der Umsetzung von Punkt 4 ab.
4. ..doppelt sich entweder mit der To Do oder mit dem Missionsbrett, so wie die Diskussion läuft eher mit der To Do. Da deren Darstellung allerdings meine Idee war, sie nicht so wirklich funktioniert hat und ich nicht weiss, wie man sie verbessert, halte ich mich hier glaub besser raus. --Datei:Sugimori 672.pngMecanno-man^Mäh 18:35, 29. Apr. 2019 (CEST)

Zu dem Thema kann ich eigentlich nicht viel sagen, da ich erstens kein Fan dieser "Stellenausschreibungen" bin (soll jetzt keine weitere Debatte anstoßen, ich akzeptiere die Entscheidung) und zweitens ein furchtbares Gefühl für Design habe. Nur eine Bitte meinerseits: benutzt wenn möglich keine zu grellen roten und ins rote gehende Farben. Das beißt sich furchtbar mit dem Blau, das wir hier hauptsächlich verwenden. Fällt zwar sofort auf, lenkt aber auch vom Rest ab und ist zumindest für mich fast schon unangenehm anzusehen :x -- ^{Datei:Pokémonsprite 359 Pinball2.png} Korvel1 ^Diskussion 10:10, 4. Mai 2019 (CEST)

Ich habe das Design meiner Vorschläge ein wenig geändert (auch etwas mehr nach dem Stil der anderen Boxen auf der Hauptseite). Hoffe, dass das Aussehen euch eher zusagt^^. --DeXter 18:54, 4. Mai 2019 (CEST)

Ich finde Entwurf zwei eigentlich schicker. So schmale Boxen gefallen mir meistens nicht so. Zu Mecs Einwurf: Ja, wir haben teilweise XdWs die gerne eine höhere Zeichenzahl hätten, manchmal krebst man da aber auch am unteren Ende rum. Wenn man aber die XdW-Box vielleicht etwas quetscht, wird sie auch länger? Wobei man dann schauen müsste, ob das noch schön proportioniert ausschaut. Lg --Und dann im Mondschein... Killuu 22:23, 5. Mai 2019 (CET)

Danke für eure Rückmeldungen!
Ja, die tt-Vorlage sollte in dieser Box wirklich komplett vermieden werden. Allein schon, weil sie auf Mobilgerät-Browsern oft nicht richtig dargestellt wird, was dann meist die Zerstörung des Layouts zur Folge hat. Eventuelle weitere Nachteile der tt-Vorlage unterstützen diesen Punkt nur noch.
Ich denke auch, dass man die Farben der Box nicht zu grell gestalten sollte. Ich finde den Vorschlag, von der Signalfarbe Rot abzusehen, sehr interessant und bin zu dem Schluss gekommen, dass ein blauer oder grüner Farbton, wohl am besten passen würde. Z. B. die gleiche Farbe, wie die, der übrigen Boxen nur ggf. etwas dunkler oder eben ein Greenchu-Grün.
Als XdW-Autor habe ich auch immer wieder mit der Zeichenbegrenzung zu kämpfen. Als jemand, der gerne ein weites Spektrum an Formulierungsmöglichkeiten haben möchte, würde ich eine Aufstockung des Zeichenlimits begrüßen. Ich sehe aber auch, dass viele mit dem Mindestzeichensatz ringen. Das Problem der Proportionsästhetik entsteht durch eine allzu große Vergrößerung der XdW-Box leider auch. Ich hoffe, unsere Projektleiterin Isso kann uns ihre Einschätzung der Lage und der potenziellen Möglichkeiten geben.
Ich bin auch von der „Längsfassung“ (wie DeXters oder mein Entwurf 1) eher abgekommen, da ich ein Problem bei dieser sehe, wenn es zu viele oder zu wenige Gesuche geben sollte. Besser wäre es wohl, eine schmalere Box (wie mein Entwurf 2) zu haben, die sich nach Bedarf füllt oder erweitert. Ich würde sehr gerne auch eine solche Variante mal „in Aktion“ sehen. Da du dich, DeXter, für diese Sache sehr engagierst und deine Syntax-Fähigkeiten deutlich besser sind als meine, möchte ich dich bitten, mal deine Version dieser Variante zu erstellen. Bin gespannt, wie die wohl aussähe. :)
-MfG, Kenaz-Hagalaz ^Disku 16:32, 24. Jun. 2019 (CEST)

Kann ich gerne machen Kenaz^^. Sollte dann die nächsten Tage fertig werden, je nach dem wie schnell ich mit meinem Ergebnis zufrieden bin (nach Möglichkeit werd ich auch versuchen das irgendwie ins Haupseiten-Layout reinzubringen, bin da aber eher am zweifeln ob ich das in angemessener Zeit schaffe). Vorhin hatte ich mir auch noch eine Frage überlegt, die ich aber wieder vergessen habe Sollte sie mir wieder einfallen, kommt nochmal was von mir. --DeXter 19:28, 24. Jun. 2019 (CEST)

Tada! Zwar nicht ganz fertig, aber das Einzige, was mich noch stört ist das "Gesucht!" und dafür hab ich bisher noch keine zufriedenstellende Lösung gefunden. Hoffentlich fällt euch was ein (muss auch nicht gleich in CSS sein; wenn nötig kann ich versuchen einen Vorschlag möglichst gut umzusetzen). Mit der restlichen Box bin ich sehr zufrieden (viell. könnte man auch noch den freien Platz unterm Bild entfernen, dafür müsste nur die Höhe des divs, in dem die Liste ist, geändert werden; dann wäre die Box auch kürzer). Ich hab mich am Design der restlichen Hauptseiten-Boxen orientiert und denke, dass das Bild auf jeden Fall ausreicht um auf die Box aufmerksam zu machen. --DeXter 18:58, 26. Jun. 2019 (CEST)

Passt anscheinend doch nicht. Das Entfernen der Scrollbar über scrollbar-width: none funktioniert in Firefox und dem Samsung Internet Browser für Handys (wie auch immer der genau heißt), aber nicht in Edge und dem Internet Explorer. Bei anderen Browsern weiß ich es nicht. Ich versuche in den nächsten Tagen das zu lösen. --DeXter 16:49, 27. Jun. 2019 (CEST)

@Kenaz (und alle, die hier mitwirken wollen^^), jetzt ist die Box (fast) fertig. Wie bereits gesagt stört mich noch das "Gesucht!"; ansonsten siehe meine vorletzte Nachricht. Hier nochmal der Link. Und noch etwas hintendran: Mec kritisierte grad auf Discord, dass man durch die unsichtbare Scrollbar nicht mehr sehen könne, dass die Liste hoch- und runtergescrollt werden kann und, dass somit der "08/15-Nutzer" nicht merken wird, dass die Liste diese Funktion hat. Meiner Meinung nach ist das kein Problem, da, auf meinem Handy und meinem PC, wenn die Liste lang genug ist, der unterste, sichtbare Listeneintrag (wenn die Box ganz hochgescrollt ist) vom Rand der Box angeschnitten wird und man sich somit erschließen kann, dass die Liste länger ist als das, was man sehen kann. Was sind eure Meinungen? --DeXter 19:08, 8. Jul. 2019 (CEST)

Durch das fehlen der Scrollbar interpretier zumindest ich das eher als n Designfehler als n Indikator zum Scrollen; irgend einen Indikator das man da Scrollen kann brauchts definitiv. --Datei:Sugimori 672.pngMecanno-man^Mäh 23:41, 8. Jul. 2019 (CEST)

Als erstes: Herzlichen Glückwunsch zum Geburtstag nachträglich liebe Diskussion

Spaß beiseite, diese Diskussion benötigt nicht nur etwas, sondern ordentlich Schwung, damit hier in absehbarer Zeit mal Fortschritt zustande kommt (mein Ziel ist es die Stellenanzeigen bis zum ersten oder zweiten Teil des Erweiterungspasses fertig zu kriegen).

Als erstes möchte ich etwas zum Inhalt der Anzeigen sagen, das ist auch der Punkt neben dem Design, an dem das gesamte Konzept steht und fällt. Bisher waren u. a. Sachen wie „Aktive Mitglieder im Manga-Projekt gesucht“ geplant. Diese Stellenanzeigen halte ich für nicht zielführend. Meiner Meinung nach sollten in die Stellenanzeigen-Box zeitlich nicht allzu aufwendige und nicht allzu komplexe Aufgaben rein, die für Neulinge geeignet sind und auch u. a. speziell für diesen Zweck (den Zweck der Nutzer-Anwerbung) "aufgehoben" und/oder gestellt werden. Hin und wieder hieß es, dass die To-do-Liste und das Missionsbrett den Zweck der Anzeigen bereits erfüllen. Aber die To-do-Liste ist für Neulinge mMn ungeeignet wegen der schieren Masse an Aufgaben, deren Bearbeitung zusätzlich nicht (für Neulinge) genau genug erklärt wird. Das Missionsbrett eignet sich da schon eher. Allerdings sind beide Seiten meines Wissens nach nicht auf der Hauptseite verlinkt bzw. sonst wo leicht zu finden (abgesehen von der Sidebar, aber dort gehen die beiden Seiten mMn unter den vielen Links unter). Also wären nebenbei angemerkt die Links in der Stellenanzeigen-Box zur To-do-Liste und zum Missionsbrett auf jeden Fall vorteilhaft.

Dann der andere wichtige Punkt: Das Design. Wie viele andere Leute in dieser Diskussion, bin ich für eine Box designt wie diese hier. Wichtig ist dabei meiner Meinung nach, dass die Box im gleichen Design wie die anderen auf der Hauptseite ist (das habe ich damals beim Erstellen des Entwurfes auch versucht). Zum Design zähle ich ein weiteres heikles Thema dazu: Die Position der Stellenanzeigen-Box. Denn dafür muss an den anderen Elementen der Hauptseite rumgewerkelt werden und das wird vermutlich auch einer der schwierigsten Punkte sein. In der bisherigen Diskussion gab es Überlegungen die XdW-Box dafür zu verformen. Dazu muss ich mir aber noch Gedanken machen.

Um den verbleibenden Punkt von Kenaz' Einstiegsnachricht zu dieser Diskussion auch noch zu behandeln: Bearbeitungsrechte der Box für VB und höher.

Da diese Diskussion seit über einem halben Jahr still liegt, habe ich in diesem Diskussionsbeitrag nochmal alle wichtigen Punkte angesprochen um einen Überblick zu kriegen. Als Schlusssatz, in der Hoffnung die Motivation von dem ein oder anderen hier zu wecken: Der User-Mangel wird schlimmer und unser Team wird kleiner. Das wird sich nicht ändern, indem wir nichts tun. Der Kontakt mit Neulingen und Besuchern hat gezeigt, dass es oft daran scheitert, dass die Leute nicht wissen was sie machen sollen oder wie sie es machen sollen (um die To-do-Liste aufzugreifen) (teils herrscht auch einfach der Irrglaube das Wiki sei bereits vollständig bzw. es gäbe nichts zu tun). Meine Hoffnung ist es mit den Stellenanzeigen neue User zu gewinnen, sodass wir wieder mehr vielversprechende Neuzugänge kriegen. Beim Thema User-Mangel werden die Stellenanzeigen allein sicher nicht ausreichen, aber sie werden einen Teil dazu beitragen.--DeXter 00:42, 27. Mär. 2020 (CET)

Ich habe hier mal den Mittelteil der Hauptseite nachgebaut (Ober- und Unter-Teil sind einfach die Vorlagen) und die Stellenanzeigen-Box an einer möglichen Stelle eingebunden. Das bisher benutzte Bild habe ich entfernt, um Platz zu sparen. Meiner Meinung nach sollte man, wenn dann ein recht schmales oder kleines Bild benutzen, damit kein wertvoller Platz verbraucht wird. Den entstandenen habe ich gefüllt, indem ich die XdW-Box verlängert habe. Als erstes zu diesem Lösungsansatz: Eine Folge dieser Möglichkeit ist die Erhöhung der XdW-Längen (ich glaube auf ca. maximal 1850 Zeichen; keine Ahnung wie viel als Minimum) für manche wird das evtl. ein Vorteil sein, manch anderer (auch ich) wird es dadurch allerdings hin und wieder schwer(er) haben. Deshalb hatte ich die Idee je nach Bedarf ein zweites Bild einzubinden (dies würde aber keines Falls den zusätzlich nötigen Text ersetzen können, nur verringern). Isso, wie ist deine Einstellung als derzeitige XdW-Projektleiterin dazu, allgemein als Lösung an der XdW-Box rumzuschrauben? Ansonsten hatte ich noch den Einfall, dass der entstehende, freihe Platz durch eine weitere Box gefüllt werden könnte. Allerdings habe ich keine Ahnung was für eine das sein sollte (und dafür müsste höchst wahrscheinlich eine komplett neue, separate Diskussion gestartet werden). --DeXter 02:14, 1. Apr. 2020 (CEST)

Als Alternative könnte man sonst auch die Anzahl der Wds-Sätze reduzieren, sodass XdW-Artikel nicht künstlich durch ein weiteres Bild gestreckt werden müssten. Die Stellenanzeigen-Box könnte man zudem scrollbar machen, um dort auch etwas mehr als drei knappe Anzeigen unterzubekommen. ~ Taisuke ^Diskussion 09:18, 1. Apr. 2020 (CEST)

Mit Hilfe von Tais Idee hab ich eine zweite Version auf meiner Testseite erstellt. Dieses Mal ist die XdW-Box völlig unverändert. Dafür wurde der Wds-Teil verkürzt. Durch die Scrollbar kann man aber immer noch alle Wds-Sätze sehen (hierbei entsteht bloß das Problem, dass die "verdeckten" Sätze weitaus weniger Aufmerksamkeit kriegen würden). Eine Scrollbar habe ich ebenfalls bei der Stellenanzeigen-Box hinzugefügt und bin auch dafür, das wegen der ermöglichten Platzersparnis ins finale Design mitaufzunehmen (diese Möglichkeit hatte ich, glaube ich, bisher verdrängt, weil das vor vielen Monaten nicht mit dem Bild harmonieren konnte. Dadurch ist auch erst die Sache mit der ausgeblendeten Scrollbar entstanden). Da das hier noch nicht in der Diskussion steht, werfe ich eine Idee von Mec noch in den Raum, die er vor langer Zeit hatte: Die Stellenanzeigen, ähnlich wie die Wds-Sätze zufällig aus einem Text-Pool anzeigen. Aber wie gesagt, ich präferiere die Scrollbar-Lösung. --DeXter 13:13, 1. Apr. 2020 (CEST)

Ich finde, beide Versionen haben ihre Vor- und Nachteile. Die Verwendung von Scrollbars führt dazu, dass wir den Seite komprimiert halten können, ohne dabei auf Inhalt verzichten müssen oder diesen anderswo künstlich aufblähen müssen. Bei der News nutzen wir dies ja bereits und da können problemlos einige Einträge drin stehen, bevor das überfüllt wirkt, wobei die Seite dabei nicht unnötig in die Länge gezogen wird. Im Gegensatz zu dem Wds und den Stellenausschreibungen haben wir hier einen entscheidenden Faktor aber verfügbar: Aktualität. Bei den News stellt es kein Problem dar, wenn man ältere Sachen "schwerer" erreichbar macht, indem man etwa eine Scrollbar nutzt, da diese sowieso nicht so häufig gesucht werden. Bei den Stellenausschreibungen wird Aktualität aber eher eine geringere Rolle spielen, die meisten Sachen werden immer wichtig sein, wenn sie da drin stehen. Einige Einträge zu verstecken wird da also nur dazu führen, dass sie übersehen werden. Ähnliches gilt für die Wds, wenn diese teils versteckt sind, werden die weiter unten aufgeführten seltener gelesen und damit geht der "Spaßfaktor" daran verloren.

Der Verzicht auf Scrollbars auf der anderen Seite führt dazu, dass logischerweise andere Inhalte drum herum länger werden müssen, um den frei gewordenen Raum aufzufüllen. Das mag in diesem Beispiel gut geklappt haben, aber es wird einige Fälle geben, wo die XdW-Artikel das nicht leisten können. Ich bin mir also nicht sicher, ob das hier der zielführende Weg ist. Logischerweise wäre es auch möglich, ein anderes Design für die Box zu wählen, man könnte etwa eine breitere Box über die ganze Seitenbreite wählen, so ließen sich mehr Punkte unterbringen und man hätte das Platzproblem an dieser Stelle nicht. Das stellt uns aber natürlich vor ein anderes Problem: Wohin damit? Über oder unter den XdW/Wds/Zitat-Abschnitt? Da drüber würde dazu führen, dass die Seite möglicherweise aus dem Gleichgewicht gerät, da wir bereits drei Boxen darüber haben, eine weitere könnte das ganze visuell länger erscheinen lassen, als es tatsächlich ist und so beinahe abschreckend wirken. Verfrachten wir die Anzeigen hingegen unter diesen Abschnitt, werden ihn höchstens die paar Leute sehen, die ohnehin den XdW/WdS/Zitate-Abschnitt bis zum Ende lesen und dann feststellen, dass da noch was drunter ist, für die EP-Sachen werden die wenigsten ans Ende der HS scrollen. Mit anderen Worten: Man riskiert, dass niemand die Ausschreibungen sieht und das wäre so ziemlich das Gegenteil von dem, was wir erreichne wollten. Man könnte natürlich darüber nachdenken, die News nach da unten zu verschieben, aber ich kann mir gut vorstellen, dass die Leute diese gerne sehen und daher vermissen würden. Alternativ wäre es vielleicht auch möglich, eine der bereits bestehenden Boxen zu erweitern. Das könnte vielleicht etwas platzsparender sein und uns erlauben, die Ausschreibungen weit oben zu platzieren, ohne dass sie störend wirken. Aber da wird man vermutlich einfach testen müssen, was passt.

Abschließend noch kurz: Am Handy scheinen die Boxen nicht ganz zu passen, ich weiß aber ehrlich gesagt nicht, wie genau das zustande kommt, ich lass das einfach mal mit Bild da, vielleicht kannst du da ja noch mal drauf schauen, DeXter. -- RobbiRobb 19:19, 1. Apr. 2020 (CEST)

Ich finde das zweite Design deutlich angenehmer und vor allem praktikabler, bei meinen XdWs gibt es einfach keine Möglichkeit noch andere Bilder reinzubasteln. Ich würde jedoch versuchen auf die Scrollbars zu verzichten. Man könnte ja zum Beispiel auch weniger Wds-Sätze einbinden und auch in der Stellenanzeige die angezeigten Punkte durch Zufall einbinden lassen. Was mir jetzt noch als Idee kam, sorry, falls das schon irgendwo stand, wäre die News zu verschmälern und die Stellenanzeigen da noch neben zu packen. Vielleicht nicht in der gleichen Breite wie Wds- und Zitatekästchen, sonst sieht das so komisch aus. Aber diese Newsbox besteht eh aus unglaublich viel Whitespace. Oder das Stellenanzeigenkästchen dann links und die News rechts. Ich denke, wir sollten auf jeden Fall bis zum Chattreffen die Optionen optimieren bzw. da noch bequatschen und dann mal ganz dringend eine Abstimmung starten ;). Btw. ich finde den zugefügten Text in Beispiel 1 beim PdW echt awesome :D. Lg --Vorsicht, heiß! Killuu 19:36, 28. Apr. 2020 (CET)

Ich habe, nach Killus wunderbarer Idee, mal eine paar Varianten hier auf meiner Testseite hinzugefügt. Da gefällt mir Version 3 schon ganz gut (bei Version 2 sieht die Stellenanzeigen-Box mMn irgendwie an den Rand gequetscht aus). Ob mit Scrollbar, zufällig angezeigten Stellenanzeigen oder anderem Schnickschnack, kann man noch entscheiden. Das hat denke ich auf jeden Fall Potenzial. Jetzt möchte ich noch etwas zum anderen kritischen Thema sagen - den Stellenanzeigen selbst. Wie Robbi auf Discord im VC schon meinte, dürfen keine wichtigen Sachen warten, bloß, damit sie als Anzeigen genutzt werden können. Deswegen könnten sich da die allseits bekannten müsste-man-mal-machen-Aufgaben wunderbar eignen. Wäre dann natürlich wieder Thema, ob man da genügend anfänger-freundliche auftreiben kann. Außerdem dachte ich mir, dass manche Aufgaben angeworben werden können, während sie jemand bearbeitet (z. B. weil die Sache dringend erledigt werden muss). Dann wird die Sache bearbeitet und Neulinge können zusätzlich etwas dazu beitragen und, wenn der Punkt erledigt ist, kommt die Stellenanzeige wieder raus. Mal als Denkanstoß bis zum Chattreffen. --DeXter 22:11, 28. Apr. 2020 (CEST)

Unabhängig der Mühe die sich Dexter gemacht hat... ich finde die Idee mit "Halbierung" und alle 3 Versionen schrecklich. Und bin dagegen. Es gab da schon deutlich optisch bessere Versionen. Eine weitere Box daneben macht die Newsline ziemlich dick und unschön. Und der Whitespace kommt je nachdem was in der News steht. Persönlich halte ich dieses Thema für ziemlich aufgebauscht, ähnlich wie das Mentorenthema damals. Es worden schon viel zu oft User auf Baustellen hingewiesen. Wir haben Mühen in Mitmachen, To-Dos usw. gelegt. Im Endeffekt hat sich allerdings nichts als hilfreiches Mittel erwiesen. Die Leserschaft will die Informationen vorgesetzt bekommen. Allerdings wollen die wenigsten Verstehen das ein Wiki nur durch Mitarbeit weiter wächst. Und solange sich das nicht ändert (und ich sehe Stellenanzeigen als kein mögliches Mittel) werden solche Sachen nur Perlen vor die Säue sein. Daher denke ich auch nicht das sowas das ganze verbessern wird. Das überlasse ich aber jedem selbst. Allerdings sollte dieser Stellenanzeiger, wenn die Mehrheit ihn will, nicht das Gesamtbild verschlechtern sondern sich in dessen Integrieren oder verbessern. Ich glaub auch nicht das dieses Ding groß jemand auf Dauer füllen wird, außer den paar euphorischen am Anfang. Man sieht ja wie schwer es ist das News hinzugefügt werden.* Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 22:32, 28. Apr. 2020 (CEST)

Ich denke die Idee das neben die News zu packen passt. Man sollte dann einfach bei der News drauf achten, das da nicht all zu lang ist. Die die da in mehrere Zeilen gehen scheinen mir definitiv kürzbar - und die News soll ja auch dazu aufrufen in die Artikel zu kucken, folglich braucht die nicht all zu lang sein. Die Gefahr, das das ganze hier nix bringt, besteht natürlich - aber hast du denn eine bessere Idee, Ryu? Ich nämlich aktuell gerade nicht, und das Problem nur zu erkennen hilft niemandem. (Ausserdem hatten wir hier ja ne Abstimmung wo sich die Mehrheit *für* die Dinger ausgesprochen hat). Bezüglich der Gefahr, das das ganze vergessen geht - wenn das Ding funktioniert wirds nicht vergessen gehen, wenn nicht is nicht so schlimm weil das Zeugs da drin sich nicht wirklich ändert... --Datei:Sugimori 672.pngMecanno-man^Mäh 00:56, 29. Apr. 2020 (CEST)

Sehe ich ganz anders. Die Breite der News über die gesamte Seite ist bewusst gewählt. Sie trennt die Navigation von wechselndem Wikizeugs. Durch die Splittung geht die klare Struktur verloren und die Leute wollen News, daher fände ich es verkehrt eine so wichtige Box zu halbieren. Die damalige Abstimmung war lediglich für Ja und Nein zur Box gedacht und wenn man sich die ansieht zeigt sich das die Gegenteiligen Argumente überwiegen. Allerdings zählen hier lediglich die Anzahl der Stimmen. Mmn kann sowas auf die Seite Mitmachen. Da ich wette das über 75% der Leser nicht über die Hauptseite ins Wiki gelangen. Und die restlichen 25% sollten Mitmachen bereits entdeckt haben Denn User die aktiv mithelfen wollen werden auch auf Mitmachen klicken oder könnten darauf verwiesen werden. Halte ich zumindest für besser, wie die Verschandelung der Hauptseite durch etwas was nicht einmal einen Bruchteil der Leser interessiert. Hier können auch Postings auf SocialMedia zur stärkeren Promotion von Mitmachen weiter helfen. Statt über das Design dieser Box zu reden wäre erstmal der Inhalt zu klären. Denn hierzu gibt es (wenn man die Baustellenbanner mit einrechnet) außer die Projekte suchen Mitarbeiter seit Eröffnung der Diskussionen keine weiteren ersichtlichen Inhalte. Und diese Müsste-man-mal-machen-Sachen bleiben liegen weil sie einfach viel zu umfangreich sind. Da wirst du auch keinen Neuling für begeistern können. * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 09:31, 29. Apr. 2020 (CEST)

Ziel ist es, Leuten zu zeigen, dass es im Wiki etwas zu tun gibt. Das auf eine Seite wie Mitmachen zu packen halte ich für verkehrt, denn da werden eh nur Leute hinkommen, die mithelfen wollen. Es geht darum Leute dazu aufzufordern überhaupt mitzuarbeiten. --Datei:Sugimori 672.pngMecanno-man^Mäh 12:11, 29. Apr. 2020 (CEST)

Welche Zeitung schreibt ihre Stellenanzeigen auf die Hauptseite? Sie stehen i.d.R. im entsprechenden Bereich. das könnte auch ganz unten über der EP Leiste sein... oder wir kürzen/verlängern das XdW einfach um paar Wörter. so das eine Box darunter oder daneben passt. Ist eine Idee. Aber im Großen und ganzen gehört dies nicht auf die HS sondern nach Mitmachen. und du hast selbst das Beste argument geliefert da werden eh nur Leute hinkommen, die mithelfen wollen. Genau diese Leute wollen wir doch. User die es wollen und nicht welche die sich genötigt fühlen oder aus langweile eher verschlimmbessern. * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 13:09, 29. Apr. 2020 (CEST)

Ich sehe hier einen gravierenden Unterschied. Nehmen wir dein Beispiel mit der Zeitung; du gehst da nicht davon aus, dass du als Leser da einen Artikel drin verfassen kannst/darfst/sollst (Leserbriefe aussen vor gelassen, aber die sind klar als solche gekennzeichnet). Ich glaube, so ähnlich sehen viele User das Wiki, weil sie das Wikimodell gar nicht kennen. Diese Wissensdifferenz ist meinem Verständnis nach was wir mit den Stellenanzeigen überbrücken wollen. Mitmachen wird nur von Leuten aufgerufen werden, die entweder bereits wissen das hier jeder mitmachen kann, oder die denken das ganze laufe hier wie eine "normale" Fansite (vgl. Bisafans/Pokefans/Serebii) ab und wem man Artikel schicken soll (eine Hürde, der sich mehr Leute nicht gewachsen fühlen im Vergleich zu der vom Wiki). Gerade diese letztere Zielgruppe ist hier mMn. die die wir ansprechen wollen; diese werden aber vornehmlich wohl gar nicht erst auf mitmachen klicken, weil sie sich eh nicht glauben im Stande zu sein den Ansprüchen der Admins gerecht zu werden. --Datei:Sugimori 672.pngMecanno-man^Mäh 13:34, 29. Apr. 2020 (CEST)

Es war für mich noch nie so schwer einen gescheiten Diskussionsbeitrag zu schreiben. Meine Gedanken schwirren von einem Argument von Ryu zum anderen. Deshalb hier die komplett überarbeitete Version (ist hoffentlich besser als mein erster Entwurf (der nur lokal auf meinem PC ist)):

Das Ziel der Stellenanzeigen ist das offene Zeigen und aufmerksam machen. Deswegen der Platz auf der Hauptseite. Schön und gut, wenn Seiten wie "Mitmachen" oder die To-do-Liste verbessert wurden, aber das bringt wenig, wenn keiner sie findet. Auf der HS haben wir meines Wissens nach eine Fläche, die auf "Mitmachen" verlinkt und die ist zum Teil transparent, neben großen Bannern, die die Aufmerksamkeits-Erreger der Hauptseite sind. Das geht daneben einfach unter und noch allgemeiner als der Text davon gehts denke ich nicht. Das ist genau richtig für so eine Fläche, spricht aber mMn kaum einen an. Und natürlich finden trotzdem einige Leute die Seite, aber viele bemerken es einfach nicht und die wegfallen zu lassen, wäre höchst ineffizient. Links zu Seiten wie "Missionsbrett" oder "To-do-Liste" haben wir glaube ich bei den meisten Seiten nur versteckt in der Sidebar und dort gehen sie in der Masse der anderen Links unter. Da ist eben wieder der Vorteil, dass diese beiden Seiten durch die Stellenanzeigen-Box offen verlinkt werden würden. Außerdem soll die News-Box nicht halbiert werden, wurde sie auch in keinem Entwurf. "Aktuelles" war immer breiter und dominanter und hatte mehr Platz als die Stellenanzeigen-Box.

Etwas, das Mec in seinem Beitrag in etwa auch angesprochen hat: Meiner Ansicht nach besteht bei vielen Leuten der Mythos, dass Wikis bereits vollständig sind, sie nichts mit ihrem Wissen beitragen können oder ähnliches. Und diesen Irrglauben anzugehen sollte eines der wichtigsten Ziele von uns beim Thema Usergewinnung sein (und genau dafür sind die Stellenanzeigen wunderbar geeignet). Und wir haben doch bereits Beispiele, die zeigen, dass Leute aktiv geworden sind, als sie bemerkten, dass etwas fehlt (spontan fallen mir Luca und ich ein, es gibt aber auf jeden Fall noch weitere).

Dann noch etwas zur vergangenen Abstimmung, die Ryu angesprochen hat: Die Argumente der Contra-Seite der Abstimmung damals waren grob zusammengefasst: "Der Einstieg ist zu schwierig, wir brauchen ein Konzept, wie wir den neuen Usern helfen können." Und das ist ein völlig anderes Thema, weshalb die Kritik, dass bei der Abstimmung die Pro-Seite weniger Argumente aber mehr Stimmen hatte, meiner Ansicht nach unberechtigt ist.

Abschließend: Ryu, direkte Wortwahl ist ja schön und gut. Aber deine Direktheit geht teils klar in den beleidigenden Bereich. Und etwas, an dem viele Leute mit Ideen und Entwürfen gearbeitet haben, etwas, das ich mühsam im TestWiki nachgebaut habe, einfach als "Verschandelung" und "schrecklich" abzustempeln ist respektlos und unangemessen. Direktheit ist gut, aber es gibt einen Unterschied zwischen "Das gefällt mir nicht, das, das und das sollte geändert werden" und "Das ist scheiße". --DeXter 14:53, 29. Apr. 2020 (CEST)

Ich hatte eigentlich vorgehabt, mich hier vorerst noch zurückzuhalten, aber es gibt doch ein paar Sachen, die ich gerne loswerden würde. Ich kann Ryus Argumente grundsätzlich nachvollziehen. Wir weisen an vielen Stellen darauf hin, dass es Baustellen im Wiki gibt und sind jederzeit bereit, zu helfen, wenn jemand etwas machen möchte, aber nicht so richtig den Einstieg findet. Das Problem ist: Sowas passiert so gut wie nie. Ob es daran liegt, dass die Leute nicht wissen, dass sie helfen können, oder schlicht nicht helfen wollen, lässt sich natürlich nur schwer mit sicherheit sagen, aber es ist davon auszugehen, dass tatsächlich beides der Fall ist. Und so, wie sich momentan die VBW entwickeln, würde ich sogar so weit gehen und behaupten, dass letzteres in den vergangenen paar Jahren deutlich stärker auftritt als zuvor. Woran das jetzt liegt, sei mal dahingestellt, aber führt auf jeden Fall etwas interessantes auf: Bei den Leuten bringt uns auch nen Haufen Stellenanzeigen nichts. Für die, die ohnehin interessiert sind, muss ich Ryu dahingehend recht geben, dass diese sich auch freiwillig umsehen werden und beim Mitmachen und in der globalen To-Do fündig werden. Selbstverständlich würde es denen aber auch nicht schaden, wenn sie die Stellenanzeigen hätten. Und dann gibt es noch die, die unvoreingenommen im Wiki unterwegs sind und weder direkt dagegen sind, zu helfen, noch bewusst hier sind, um zu helfen. Auf die würden sich die Stellenanzeigen vermutlich am ehesten auswirken. Zu der Positionierung möchte ich mich an dieser Stelle nicht wirklich äußern, ich habe jetzt einige Designs gesehen, die teils mehr oder weniger vielversprechend waren, habe mir selber auch einige Gedanken gemacht, wo man die Box platzieren könnte und bin zu dem Schluss gekommen, dass es keine perfekte Möglichkeit gibt, mit der man alle zufrieden stellen kann. Man wird hier also irgendwie einen Kompromiss finden oder eine Abstimmung durchführen und danach eine harte Linie fahren müssen.

Etwas, dass mich aber schon länger bei den Stellenanzeigen stört und das ich schon mehrfach erwähnt habe, für das mir aber bisher niemand eine Lösung liefern konnte: Der Inhalt dieser Anzeigen. Sinnvollerweise würde man möglichst einfache Aufgaben angeben, damit Neulinge sich einfacher im Wiki einfinden können, ohne großartiges Vorwissen mitzubringen. Bisher ist es mir aber nicht gelungen, in einem meiner eigenen Projekte eine Aufgabe zu finden, die einfach genug ist, um diesem Anspruch gerecht zu werden und gleichzeitig nicht schnell genug einfach von mir selbst erledigt werden könnte. Vielfach ist es dabei auch wichtig, dass Aufgaben dringend sind, obwohl sie einfach sind. Ich werde unter keinen Umständen Aufgaben zurückstellen, die dringen erledigt werden müssen, nur weil sie einfach genug sind, dass sie ein blutiger Anfänger übernehmen könnte. Und damit wird auch meine Sorge offensichtlich: Einfaches ist häufig dringend und so einfach, dass ich es am schnellsten selber erledige, während lediglich komplexe Aufgaben liegen bleiben. Ich leite zwar "nur" drei Projekte im Wiki, gehe aber davon aus, dass es anderen genau so gehen wird, dass sie nicht in der Lage sein werden, Aufgaben zu stellen. Und dadurch befürchte ich, dass die Stellenanzeigen über kurz oder lang entweder (nahezu) leer stehen werden oder wieder aufwendige Aufgaben, wie sie bislang im Missionsbrett zu finden sind, hinzugefügt werden.

Abschließend noch zwei Punkte: Zum einen hatte mich damals bei der Abstimmung für die Stellenanzeigen ausgesprochen, obwohl ich bereits damals besorgt war, dass sich kein sinnvolles Konzept für den Inhalt finden würde und bislang scheint sich diese Sorge zu bewahrheiten. Sollten andere ebenfalls besorgt sein, dass sie selbst nichts zu den Anzeigen hinzuzufügen haben, möchte ich dazu aufrufen, zu überdenken, wie zukunftsfähig diese Idee tatsächlich ist. Wenn ich da mit meinem Projekt alleine stehe, dass ich dem nichts hinzufügen könnte, werde ich dem ganzen aber natürlich nicht im Weg stehen. Zum anderen muss ich mich auch gegen Ryus Wortwahl aussprechen. Ich kann nachvollziehen, dass du nicht ganz zufrieden mit dem Design und der Ausführung bist, aber das lässt sich definitiv anders ausdrücken. Eine weitere Verfolgung der Umsetzung wurde damals in einer fairen Abstimmung beschlossen, und wie alle Abstimmungen werden wir mit dem Ergebnis leben und nicht einfach alles umwerfen, nur weil einer nicht zufrieden ist. Du kannst aber natürlich wie sonst auch versuchen, einen besseren Vorschlag einzureichen; wenn es dir die Arbeit wert ist, kannst du sogar einen Vorschlag erstellen, der in eine vollkommen andere Richtung geht und die erzielten Punkte auf einem völlig anderen Weg erreicht. Ich behaupte einfach mal, dass wir grundsätzlich auch von den Stellenanzeigen als solchen absehen, wenn es einen Vorschlag gibt, der unseres Erachtens nach das Ziel der Nutzer-Anwerbung besser erreicht. Bis dahin wird die aktuelle Diskussion aber weiter verfolgt, du kannst zusätzliches Feedback angeben, aber das Vorhaben zu Stoppen ist definitiv nicht Sinn der Diskussion. -- RobbiRobb 15:41, 29. Apr. 2020 (CEST)

Sorry wenn du oder sonst wer sich auf den Schlips getreten fühlt. Ich werde allerdings meine Meinung nicht ändern nur damit sie jemanden gefällt. Und wie du sagst ich bin direkt. Wenn etwas Scheiße ist, dann kannst du sicher gehen das ich auch schreibe das es Scheiße ist. In dem Fall finde ich es lediglich Schrecklich, da es mMn das Gesamtbild verschlechtert. Und dabei bleibe ich auch. Klärt erstmal was in diese Box rein soll. Davon steht nirgends etwas. Und ich glaube auch nicht wenn eine Liste mit sämtlichen Projekten und davor nem "dieses Projekt braucht Mitarbeiter" die User animiert den Sinn und Zweck eines Wikis zu verstehen. Das dies zum Ziel führen wird, glaube ich seit der Baustellenbanner Diskussion nicht mehr. Auch so müsste-man-mal-machen-Sachen.... Es gibt unzähliges was was auf der To-Do versauert oder allgemein bekannt ist oder (an die Leute gerichtet die mich privat bzgl. Klamotten aus StSd angeschrieben haben mit Worten du hast es doch sonst auch immer gemacht, wann machst du es endlich mal, hoffe das ist dann auch vollständig...) Es wird einfach immer abgewälzt, da die Leute selbst keine Intention haben oder es für sie zu aufwendig ist. Und wenn es für "erfahrene" User zu aufwendig ist, dann wird sich ein Neuling dessen garantiert nicht annehmen. Daher sollte mMn andere Optionen angedacht werden. Und aus diesem Grund habe ich mich größtenteils aus dieser Diskussion raus gehalten. Nun geht es aber darum das News (ich betone halbierung das heißt: aus einer Box zwei zu machen) oder ein anderer Bereich dessen weichen soll. Und da bin ich wie gesagt dagegen. Zurück zum Kernpunkt was soll in diese Box rein, wie wäre es mal mit einer Liste der Angaben die da rein soll! So eine Projektliste scheitert ja schon am Wort XdW... Sobald der Inhalt geklärt ist starten wir einfach ne Abstimmung wo das Ding hin soll. Sollte die Mehrheit es auf die HS wollen so sei es... Auf die Hauptseite gehört es mMn aus vielen Gründen die bereits ellenlang diskutiert worden nicht hin. Ich werde diese hier nicht wiederholen. Das kann ja jeder selber nachlesen. Sobald Inhalt und Ort geklärt ist kann sich daran gemacht werden sich hier ein Design zu überlegen. * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 15:53, 29. Apr. 2020 (CEST)

Erstmal: Ich hab nochmals nachgeschaut und die Abstimmung war über die Frage der Einbindung einer Stellenanzeigenbox auf der Hauptseite. Ich sähe es demnach nicht als rechtens diese irgendwo sonst einzubinden und dieser Punkt ist imo. damit bereits geklärt.

Bezüglich Inhalt könnte ich aus meinen Projekten Punkte wie „Gesucht: Schreiber von Charakterbeschreibungen der Charaktere aus Schwert/Schild“ oder „Gesucht: Jemand, der Spielmechanik-Artikel aus dem Ranger-Bereich aufpolieren möchte“. Ich denke nicht, das wir in diesen Anzeigen etwas so umfangreich wie die gesamte To-Do, noch etwas so klein wie die Missionsbrettsachen da aufschlagen sollten. Die Sachen sollten gross genug sein das wir im Zweifel mehr Leute dran haben können, aber auch klein genug das sie überschaubar sind. Wahrscheinlich wärs auch noch hilfreich, gleich einen Ansprechpartner im Auftrag anzuführen. --Datei:Sugimori 672.pngMecanno-man^Mäh 17:10, 29. Apr. 2020 (CEST)

Wie Mec geschrieben hat ist das Thema "Hauptseite ja oder nein" bereits vom Tisch, weil das in der Abstimmung mit enthalten war. Dann zum nächsten kritischen Themenbereich, von dem das Überleben dieses Konzepts abhängt: Dem Inhalt. Dazu habe ich vor geraumer Zeit hier geschrieben, dass die Stellenanzeigen nicht zu aufwendig sein sollten. Das möchte ich zum Teil zurücknehmen. Natürlich sollten da jetzt keine Mega-Aufgaben rein, aber ich kann mir gut vorstellen, auch Anzeigen zu nehmen, die beispielsweise aus, für Anfänger machbaren, Teilschritten bestehen, aber zusammengenommenn sehr viel Zeit beanspruchen (z. B. Attacken-Videos eines Spielepaars aufnehmen und einbinden).

Nach ein paar Überlegungen sind mir ein paar mögliche Stellenanzeigen eingefallen. Vorweg: Allgemein Punkte bei Spielrelease, die zeitaufwendig sind und zu denen es keine Daten in Dumps oder ähnlichem gibt (da man sie sonst botten könnte). Und nein, diese To-do-Punkte sollen keines Falls warten. Diese würden gezeigt werden, während Wiki-Leute bereits daran arbeiten und würden wieder aus der HS-Box entfernt werden, wenn die Sache erledigt ist. Also quasi ein temporäres Angebot für zusätzliche Hilfe. Ein Beispiel dafür wäre das Eintragen von Items mitsamt Item-Fundorten bei neuen Spielen. Denn dafür gab es bei StSd keine Dump-Daten, oder? Keine Ahnung ob das allgemein bei Release der Fall ist, aber das soll bloß ein Beispiel sein.

Dann zu Stellenanzeigen, die nicht bereits von Wikingern bearbeitet werden würden. Hier finde ich die von Mec schon ganz gut, auch wenn die mMn schon wieder etwas in die komplexe Richtung gehen, aber das ist Ansichtssache. Ich denke die Stellenanzeigen müssen eine eindeutige Aufgabe enthalten. Beispielsweise eben wie "Charakterbeschreibungen formulieren", aber nicht "Beim Projekt mithelfen". Hier ein paar Ideen von mir (die Formulierungen seien mal dahingestellt; da müssen noch bessere gefunden werden):

• „Schreiber eines PdWs - ein ca. 1450 Zeichen langer, informativer Text über ein Pokémon. (mehr Info)“
• „Jemand, der Attacken-Animationen aus Pokémon Schwert und Schild beisteuern kann. (mehr Info)“
• „Jemand, der den Artikel Liste der Attackennamen in anderen Sprachen um die 8. Generation erweitert.“
• „Jemand, der den Artikel Rückstoß-Attacke um die 8. Generation erweitert.“
• „Jemand, der den Artikel Versteckte Fähigkeit/Fundorte (8. Generation) erweitert.“
• „Jemand, der den Artikel Spezialattacke aktualisiert.“
• „Jemand, der Trainer-Attacken in <Spielepaar, Region, sonst was> prüft und einträgt.“
• „Jemand, der die Itemfundorte in <Spielepaar, Region, sonst was> bei Bedarf besser formuliert.“

Da sind einige Sachen, die noch im Attacken-Projekt erledigt werden müssen oder grad in Bearbeitung sind. Die müssen gemacht werden, aber ich bin noch z. B. u. a. (schön formuliert xD) mit den Effekten beschäftigt, die mMn wichtiger sind. Also könnte man das in der Zwischenzeit anwerben. Die wären ein Beispiel für "an sich wichtig, aber es gibt wichtigeres". Sowas fällt denke ich auch bei anderen Projekten an.--DeXter 17:35, 2. Mai 2020 (CEST)

Etwas, das nur einen einzelnen Artikel betrifft, ist imo. eher etwas fürs Missionsbrett. Ich finde da sollten eher Sachen hin, die mehrere Artikel befassen. Generell könnte man aber die ewigen blauen Missionen dahinverlagern. Wäre dann einfach die Frage ob die immernoch gemacht werden wenns keine Missionen mehr sind. --Datei:Sugimori 672.pngMecanno-man^Mäh 19:11, 2. Mai 2020 (CEST)

Abstimmung: Design der Stellenanzeigen-Box auf der Hauptseite

Abstimmung beendet. Variante 3 wird umgesetzt

Während Pin, Kenaz und ich uns um die Form der Inhalte der Stellenanzeigen-Box und -Seite kümmern, möchte ich bereits die Abstimmung über das Design der Hauptseiten-Box starten. Die verschiedenen Varianten sind hier zu finden. Diese Hauptseiten-Nachbildungen sind unsauber, also kann es durchaus zu optischen Unsauberheiten kommen (z. B. der Gradient von "Ausschreibungen" ist kürzer als der von "Aktuelles"), über diese bitte hinwegsehen, am Ende wird das sauber in die Hauptseite eingebaut.

Diese Abstimmung wird über mehrere Runden hinweg ablaufen, die jeweils den Ausschluss der Variante(n) mit der geringsten Stimmenanzahl festlegen (Optionen, die keine Stimme erhalten, werden automatisch ausgeschlossen und beeinflussen nicht die eigentliche Ausscheidungsauswahl). Als Zeitraum für diese Abstimmungsrunden ist jeweils eine Woche vorgesehen. Das heißt Runde 1 geht bis zum 25.05.2020 um 20:00 Uhr. Teilnehmen dürfen alle Stimmberechtigten. --DeXter 20:00, 18. Mai 2020 (CEST)

Runde 1

Variante 1: Wds-Box wird verändert

1. Idealerweise würde ich statt dem Scrollen einfach weniger Wds-Stichpunkte anzeigen lassen, da mir die Aufzählung so vieler Fakten ohnehin nicht wirklich gefällt. Mehr Schreibarbeit für XdWs und weniger Platz für Neuigkeiten halte ich außerdem nicht für ideal, auch wenn beide Optionen im aktuellen Entwurf besser aussehen. Wds braucht den Platz ganz einfach am wenigsten.--✦✧✦ Pk-fan 04:07, 23. Mai 2020 (CEST)
2. Denke wie Pk-fan. Nescientist (Diskussion) 14:47, 23. Mai 2020 (CEST)
3. nach etwas Überlegen habe ich mich auf diese Variante umentschieden, bin mir aber nicht zu 100% sicher, ob nicht doch Variante 2 besser wäre BlauesSerpiroyal ^Diskussion

Variante 2: XdW-Box wird verändert

1. --Datei:Sugimori 672.pngMecanno-man^Mäh 23:40, 18. Mai 2020 (CEST)
2. -- Luca12379 ^Diskussion 22:50, 19. Mai 2020 (CEST)
3. Halte weiterhin ein Splittung von News für einen riesigen Fehler. Gerade da dort öfters längere Texte stehen wäre es Unschön wenn man nichtmal die erste News ohne Scrollen lesen könnte. Daher blieb die Entscheidung zwischen WdS und XdW. * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 12:59, 21. Mai 2020 (CEST)

Variante 3: Aktuelles wird verändert - Version 1

1. Ich bin klar dafür "Aktuelles" zu ändern und somit weitere Scrollbars und unter Umständen eine veränderte XdW-Box zu vermeiden. Version 1 finde ich hierbei optisch ansprechender. --DeXter 20:00, 18. Mai 2020 (CEST)
2. Ich bin auch für diesen Entwurf. Wir sollten maximal eine Scrollbar auf der Hauptseite haben, sonst wirkt es seltsam, außerdem gefällt mir das Layout hier insgesamt am besten. Nur ganz unten, wo die Zitat- mit der XdW-Box abschließt, sollte man schauen, dass diese auf demselben Level sind. -MfG, Kenaz-Hagalaz ^Disku 20:24, 18. Mai 2020 (CEST)
3. Gefällt mir persönlich am besten. Das Isso 08/15 ^Konter 20:55, 18. Mai 2020 (CEST)
4. Cliffichen 22:56, 18. Mai 2020 (CEST)
5. Die Version sieht am ansprechendensten aus. --mfG Lombrero ^Dis 08:56, 19. Mai 2020 (CEST)
6. Das sieht schön aus. BeyJim ^Diskussion 23:52, 19. Mai 2020 (CEST)
7. Zeynex (Diskussion) 10:48, 20. Mai 2020 (CEST)
8. Lasagne (Diskussion) 17:27, 20. Mai 2020 (CEST)
9. Diese Variante bleibt im Gegensatz zur vierten dem Raster treu, das ist optisch deutlich angenehmer. Die XdW-Box zu verändern führt nur zu weiteren Anpassungen, in diesem Falle der Regelung zur Länge der Artikel. Und bei Variante ein wird die rechte Spalte durch drei Boxen sehr gedrubbelt. Da kann also nur diese dritte Variante richtig sein. -- GrüßeShortyBuzz 11:24, 21. Mai 2020 (CEST)
10. Finde persönlich diese Version am besten. -- "I'm gonna become the Campion of the Pokemon League!!!" PokéSpe ^Disku 19:46, 23. Mai 2020 (CEST)

Variante 4: Aktuelles wird verändert - Version 2

1. - - - Mit einem Lachen werden wir es machen! 𝅘𝅥𝅮 - SwowoJonny Datei:Sugimori 156.png 20:44, 18. Mai 2020 (CEST)
2. Keine Gründe, einfach nur subjektives Empfinden. --Kein Dschungel zu dicht... Killuu 22:07, 23. Mai 2020 (CET)
3. Variante 1 und Variante 2 sagen mir beide nicht wirklich zu, da ich den Scrollbalken bei den Ausschreibungen als störend empfinde. Die Verlängerung des XdWs zugunsten des Wds finde ich irgendwie merkwürdig, da hätte ich eher den Platz in die Ausschreibungen investiert, mal davon abgesehen, dass ich nicht denke, dass wir die Zeichenanforderungen im XdW permanent erhöhen sollten. Im Endeffekt war es für mich also eine Entscheidung zwischen Variante 3 und Variante 4, wobei ich Variante 4 aus mehreren Gründen ansprechender empfand: Die Platzierung der Stellenanzeigen auf der linken Seite führt nicht nur dazu, dass diese eher wahrgenommen werden (typische Leserichtung von links nach rechts), sondern brechen auch das einheitliche Bild etwas auf, dass in Variante 3 zustande kommt. Außerdem hat es den netten Vorteil, dass der Scrollbalken vom Aktuelles dadurch ganz rechts außen ist und nicht mitten auf der Seite. Und zuguterletzt bringt es den Wiki-Teil besser zusammen, besonders die Ausschreibungen und das XdW promoten die Inhalte des Wikis aktiv, Wds und Zitate machen das zwar auch, brauchen aber keine regelmäßige Aufmerksamkeit. Finde diese Variante daher am angenehmsten und vorteilhaftesten. -- RobbiRobb 17:04, 25. Mai 2020 (CEST)
4. ~ ~ Simonsees ~ 17:28, 25. Mai 2020 (CEST)
5. GrollenKette951 17:43, 25. Mai 2020 (CEST)

Enthaltung

Kommentare

Bedenkt die kurze Abstimmzeit pro Runde. Daher auch gleich mal einen Ping: Buoysel, Cliffichen, CLina, DeXter, GoPika, GrollenKette951, Impoleon xy, Isso08-15, Kenaz-Hagalaz, Lombrero, Luca12379, Matze, Mecanno-man, RobbiRobb, Ryuichi, ShortyBuzz, Simonsees, SwowoJonny, Taisuke, AAWiki, BeyJim, BlauesSerpiroyal, Der Sternendiamantritter, Enzo, Hydrokyu, Jass, Killuu, K0pplosio, Lasagne, Mario-WL, Nescientist, Pintauranimus, Pk-fan, Pokefan212, PokéSpe, PokemontutorialTV, TiMauzi, TM Master, Vircaprae, Zeynex --DeXter 20:00, 18. Mai 2020 (CEST)

Runde 2

Runde 2 geht bis zum 01.06.2020 um 21:00 Uhr.

Variante 3: Aktuelles wird verändert - Version 1

1. Ist optisch ansprechender BlauesSerpiroyal ^Diskussion 20:56, 26. Mai 2020 (CEST)
2. Ich bleib dabei Datei:Pokémonsprite 248 StSd.gif BeyJim ^Diskussion 22:16, 25. Mai 2020 (CEST)
3. Cliffichen 00:21, 26. Mai 2020 (CEST)
4. Diese Reihenfolge halte ich für die meisten Besucher, die wahrscheinlich mehr an den Pokémon-Neuigkeiten als an den Ausschreibungen interessiert sind, für sinnvoller, außerdem ist das Kreuz meiner Meinung nach optisch ansprechender als der Versatz Lasagne (Diskussion) 14:48, 26. Mai 2020 (CEST)
5. --Datei:Sugimori 672.pngMecanno-man^Mäh 15:03, 26. Mai 2020 (CEST)
6. Ich bleibe weiterhin bei meiner bisherigen Meinung.-MfG, Kenaz-Hagalaz ^Disku 17:05, 26. Mai 2020 (CEST)
7. Dann das. Nescientist (Diskussion) 17:27, 26. Mai 2020 (CEST)
8. Ich ändere meine Meinung nicht so schnell. mfG Lombrero ^Dis 17:29, 26. Mai 2020 (CEST)
9. --✦✧✦ Pk-fan 03:02, 28. Mai 2020 (CEST)
10. Das Isso 08/15 ^Konter 14:25, 28. Mai 2020 (CEST)
11. Ich stimme zwar vielen Argumenten von Robbi aus Runde 1 zu, aber irgendwas optisches stört mich immer noch bei Option 4. Deshalb bleibe ich bei Variante 3, auch wenn ich bei dieser Runde anfangs gezögert habe. --DeXter 14:58, 28. Mai 2020 (CEST)
12. -- GrüßeShortyBuzz 15:03, 28. Mai 2020 (CEST)
13. kann mich nur schwer entscheiden bin aber etwas mehr für dieses. Zeynex (Diskussion) 02:12, 31. Mai 2020 (CEST)

Variante 4: Aktuelles wird verändert - Version 2

1. - - - Mit einem Lachen werden wir es machen! 𝅘𝅥𝅮 - SwowoJonny Datei:Sugimori 156.png 21:13, 25. Mai 2020 (CEST)
2. ~ ~ Simonsees ~ 21:20, 25. Mai 2020 (CEST)
3. Ich finde beide Versionen echt nicht schön, aber das hier ist wohl das kleinere Übel Luca12379 ^Diskussion 16:47, 26. Mai 2020 (CEST)
4. Vircaprae 13:03, 31. Mai 2020 (CEST)

Enthaltung

1. Leider gibt es nur Enthaltung und kein Kontra... ohne mich.... beide Versionen sind mMn ein no Go und zerstören die Sinnhaftigkeit der Newsbox... WdS oder XdW wäre sinnvoller gewesen. Auch verstehe ich nicht warum hier nur eine Woche Abstimmfrist gegeben wurde und wie auf Discord angegeben wurde mMn eine Version zuviel rausgestrichen. Da bei Gleichstand wohl erst eine Stichwahl gemusst hätte. * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 21:28, 25. Mai 2020 (CEST)

Kommentare

Ping: Buoysel, Cliffichen, CLina, DeXter, GoPika, GrollenKette951, Impoleon xy, Isso08-15, Kenaz-Hagalaz, Lombrero, Luca12379, Matze, Mecanno-man, RobbiRobb, Ryuichi, ShortyBuzz, Simonsees, SwowoJonny, Taisuke, AAWiki, BeyJim, BlauesSerpiroyal, Der Sternendiamantritter, Enzo, Hydrokyu, Jass, Killuu, K0pplosio, Lasagne, Mario-WL, Nescientist, Pintauranimus, Pk-fan, Pokefan212, PokéSpe, PokemontutorialTV, TiMauzi, TM Master, Vircaprae, Zeynex --DeXter 20:50, 25. Mai 2020 (CEST)

Ich war mir relativ sicher, dass wir während des Chattreffens gesagt hatten, dass jede Runde die Version mit den wenigsten Stimmen wegfällt und nur im Falle von 0 Stimmen eine bzw. mehrere weitere ausgeschlossen werden würden. Ich bin daher ebenso wie Ryuichi etwas verwundert, dass zwei Versionen mit der ersten Runde gestrichen wurden, nur weil sie gleich viele – oder besser gesagt wenige – Stimmen erhalten haben. ~ Taisuke ^Diskussion 11:15, 26. Mai 2020 (CEST)

Ich dachte das beim Chattreffen wäre nur ein Vorschlag gewesen und keine Festlegung Ich kann euch aber verstehen und habe auch nichts dagegen erst noch eine der beiden betroffenen Varianten wieder "reinzuwählen", wenn das in Ordnung ist. Dafür würde ich dann die Dauer der eigtl. Abstimmung erhöhen und parallel eine einwöchige Abstimmung starten, in der festgelegt wird, ob Option 1 oder 2 wieder dazu kommen. Das ist zumindest mir grade als Lösung eingefallen. Tut mir Leid wegen den Unannehmlichkeiten. --DeXter 14:47, 26. Mai 2020 (CEST)

Wäre ich dagegen; es wurde über der Abstimmung geschrieben wie hier verfahren wird und auch so umgesetzt; hier jetzt ex post etwas daran zu ändern fände ich falsch. Das System sollte man aber für zukünftige Wahlen nochmals überdenken, da es hier z. B. auch eine zweite Runde gegeben hätte wenn eine Position ein absolutes Mehr erreicht hätte. --Datei:Sugimori 672.pngMecanno-man^Mäh 15:03, 26. Mai 2020 (CEST)

Ich habe nirgendwo gefordert, etwas neu aufzurollen oder umständlich zu lösen, sondern lediglich meine Verwunderung über die Vorgehensweise zum Ausdruck gebracht, weil diese Handhabung aus dem eingangs beschriebenen Verfahren nicht eindeutig hervorgeht. Am Ende des Tages wurde ja aber auch nicht meine Stimme gleich Null gesetzt, nur weil eine andere Version gleich wenige Stimmen erhalten hat. Jedoch könnte ich daraus evt. resultierenden „Frust“ nachvollziehen. ~ Taisuke ^Diskussion 15:27, 26. Mai 2020 (CEST)

Ich wuerde einfach mal hoffen, dass Discord voellig irrelevant war und da hier ganz klar stand, wie es ablaufen wird, sollte das auch so akzeptiert werden (zumal sich niemand wahrend der Wahl beschwert hat).

Im Uebrigen finde ich aber das Verfahren auch deswegen grundsaetzlich nicht sinnvoll, weil es evtl. einen Anreiz liefert, einen anderen Vorschlag zu waehlen, als den, den ich gerne als Gewinner haette. Beispiel: Die Verteilung der 4 Alternativen kurz vor Schluss ist 5/4/3/0 und ich will Alternative 1, dann sollte ich Alternative 3 waehlen, weil Alternative 1 dann in der ersten Wahlrunde direkt gewinnt. Nescientist (Diskussion) 17:27, 26. Mai 2020 (CEST)

Der Vorteil von diesem Wahlsystem ist, dass keine vereinte Minderheit die Wahl gewinnen kann (bzw. es schwerer hat). Zu Verbessern währe mMn der Fall mit gleich wenigen Stimmen von mehreren Optionen, der das hier im Kommentar-Bereich gestartet hat und der Fall einer absoluten Mehrheit. Außerdem ist mir anhand von der Sache hier aufgefallen, dass die Abstimmungsregeln recht locker oder unkonkret gestellt sind. Der Initiator kann an sich Wahlsystem und -dauer ziemlich bzw. komplett frei wählen, was mMn so nicht sein sollte. Da kann zwar immer noch ein Admin eingreifen, aber mMn sollte man bei Regeln nicht zu sehr auf die Macht-Stellung von Admins setzen. Die beiden Themen (Verbesserungen für das Wahlsystem und Abstimmungsregln) gehören aber hier, denke ich, nicht hin. --DeXter 18:37, 26. Mai 2020 (CEST)

Typenicons und wie wir entscheiden, welche wir nutzen.

Bekanntlich sind die neuen SWSH-Typenicons relativ einheitlich dunkel, weshalb sich die Frage stellt, ob wir diese überhaupt nutzen wollen. Da es hier nicht viele sachliche Argumente gibt (mir fallen konkret nur „Aktualität“ vs „Nutzerfreundlichkeit bzgl. Differenzierbarkeitsgeschwidigkeit“ ein) wäre ich dafür das irgendwie per Abstimmung zu machen. Da diese Entscheidung aber schlussendlich hauptsächlich Leser betrifft wäre ich dafür, diese auch in den Entscheidungsprozess mit einzubeziehen. Aus diesem Grund schlage ich vor, in unseren Social Media-Kanälen (also: FB und Twitter) Umfragen zu machen, welche Icons als Standard genutzt werden sollen (und die Stimmen einfach aufzuaddieren). So könnte man auch mal wieder unsere Social Media-Kanälen etwas Leben einhauchen. Hätte da irgendjemand etwas dagegen? --Datei:Sugimori 672.pngMecanno-man^Mäh 17:20, 15. Dez. 2019 (CET)

Bin der Idee, auch die Besucher in diese Entscheidung mit einzubeziehen, gegenüber aufgeschlossen, finde es nicht falsch, da auch weitere Meinungen zu berücksichtigen. Finde aber, dass eine ausschließliche Verwedung direkter Abstimmungen bei Twitter und Facebook das Problem auch nicht löst, da Benutzer, die dort keine Konten haben genau so ausgeschlossen sind, als würde man eine Abstimmung im Wiki durchführen; Unterschied wäre lediglich, dass die der Abstimmung zugrunde liegende Benutzerkontenzahl größer ist. Bringt im übrigen auch das Risiko mit sich, dass manche bei beiden Seiten an der Abstimmung teilnehmen werden und andere nicht, dadurch könnte das Ergebnis verfälscht werden. Mit am praktischsten wäre daher meiner Meinung nach eine Abstimmung, die zentral auf einer Seite ist und sowohl über Social Media als auch direkt im Wiki beworben wird und dort eine Teilnahme auch ohne Account ermöglicht. Ich sehe darin allerdings ganz klar auch Sicherheitsrisiken, da eine Abstimmung, bei der die Stimmen nicht eindeutig zugeordnet werden können, leicht verfälscht werden können, etwa wenn Stimmen über IPs gezählt werden, die sich vergleichsweise einfach ändern lassen. Für den Moment also mein Pro dazu, die breite Leserschaft mit einzubeziehen, allerdings gefällt mir die Methode nicht, wobei ich nicht sicher sagen kann, ob mein Vorschlag da so viel besser ist. -- RobbiRobb 21:59, 15. Dez. 2019 (CET)

Ich finde das mit der Doppelabstimmung auf beiden Seiten nicht wirklich problematisch, da die Leute die das tun werden wohl kaum etwas anderes bevorzugen als die Allgemeinheit, wodurch das schlussendliche Resultat nicht verändert wird. Geht allerdings zugegebenermassen auch nur bei so einer single-choice-Frage, nicht bei etwas komplexerem. Bezüglich dem Ausschliessen von Nutzern ohne Konto, die ein Konto im Wiki haben: Ich habe die Hoffnung, dass es so viele Stimmen geben wird, dass das irrelevant wird, weil wir so wenige Stimmen ausmachen. --Datei:Sugimori 672.pngMecanno-man^Mäh 22:44, 15. Dez. 2019 (CET)

Ich finde es ebenfalls gut die Meinung der Besucher einzubeziehen. Bezüglich der Zentralität, Sicherheit vor Mehrfachabstimmungen und der Möglichkeit einer Teilnahme ohne Konten bei Facebook und Twitter habe ich hier mal etwas über Google Formulare ausprobiert. (Ich bekomme nur die Antworten und den Zeitpunkt der Antwort zu sehen.) Natürlich bleibt zwar auch dort eine Beschränkung auf Leute mit Googlekonto, darin sehe ich jedoch kein allzu großes Problem, da vom Gefühl her fast jeder ein Googlekonto hat. Ich kann die Vorraussetzung auch rausnehmen, dann wären aber eine Mehrfachabstimmung wieder möglich. Über Feedback zu dieser Idee würde ich mich freuen. GrollenKette951 00:43, 16. Dez. 2019 (CET)

Würde diese Umfrage entscheiden, wie wir das mit den Typ-Icons handhaben wollen (siehe Überschrift des Abschnitts), oder soll sie die Follower auf Facebook und Twitter miteinbeziehen (siehe einleitender Text)? Das ist für mich ein kleiner, aber feiner Unterschied. Zudem vermag ich nicht grundsätzlich mein „Ok“ hier zu äußern, ohne zu wissen, wie eine solche Umfrage aussehen soll. Gibt es visuellen Input für die Abzustimmenden? Heißt grundsätzlich neu vs. alt oder auch beispielhafte Auswirkungen auf bestimmte Vorlagen. Mein Eindruck der Follower unserer sozialen Kanäle ist über die Jahre eher der, dass sie nicht die wirkliche Besucherbandbreite abbilden können. Allgemein behagt es mir, eine bzw. zwei Abstimmung(en) auf den beiden Kanälen durchzuführen, um über solch grundlegenden Dinge entscheiden zu lassen. ~ Taisuke ^Diskussion 10:29, 16. Dez. 2019 (CET)

Wenn wir das machen müsste es schon ein entscheiden sein, weil sich das ganz schlecht macht wenn wir ne Umfrage machen und die dann nicht umsetzen. Für mich ist es imo. grundsätzlich neu vs alt, mit Ausnahmen wie z. B. diese Tabelle. Etwas anderes zu machen macht imo aus rein technischer Sicht keinen Sinn, da damit relativ aufwändig für jeden Fall entschieden werden muss, ob man das neue oder das alte Icon nehmen will. Eine solche Entscheidung könnte man auch nicht über eine Abstimmung machen. Bezüglich der tatsächlichen Umsetzung finde ich durchaus, das Bildmaterial angeboten werden sollte; bevorzugterweise irgendwo an exponierter Einzelstelle, irgendwo in ner Aufzählung und auch einmal ne Aufzählung auf dunklerem Hintergrund. Über die genauen Bilder kann man aber definitiv noch reden. Die Idee das über eine Google-Umfrage zu machen finde ich allerdings auch gut, wenn nicht sogar für diese Zwecke besser; die Idee das per unsere Social Media-Kanäle zu machen hätte allerdings den Vorteil das diese zur Zeit relativ abgelegten Kanäle wieder irgendwas bieten. --Datei:Sugimori 672.pngMecanno-man^Mäh 23:33, 16. Dez. 2019 (CET)

Fürs Protokoll: Nach kurzen tests ist offensichtlich, dass Google Forms sich ohne Google Eccount lächerlich einfach austricksen lässt (bzw. Mehrfachbeantworten sogar zugelassen sind.) Das sollte man wenn mans nutzt also eindeutig mit Accountzwang machen. --Datei:Sugimori 672.pngMecanno-man^Mäh 23:47, 16. Dez. 2019 (CET)

Besucher miteinzubeziehen finde ich ebenfalls gut. Entscheidungen sollten aber mMn nicht durch eine Umfrage allein getroffen werden können. Durch derartige Umfragen z. B. über das Google Formular von Peter ist die "Bequemheit" zu groß, um alles bei dieser Entscheidung zu berücksichtigen, bevor man sie fällt (mal abgesehen von der mangelnden Erfahrung/Fachkenntnis der Besucher). Bei dem Formular wählt man eine Option aus, drückt auf "Senden" und fertig; das dauert wenige Sekunden, geht super einfach und man muss nicht viel nachdenken. Wenn man allerdings hier auf der AD etwas schreibt muss man erstmal seinen Text verfassen und liest nochmal drüber bevor man die Änderung speichert, das dauert länger und man denkt auch mehr über das Thema nach. Meiner Meinung nach sollten also solche Umfragen in Diskussionen wenn dann nur berücksichtigt werden, um die Nutzerfreundlichkeit bzw. den optischen Eindruck der Besucher zu ermitteln. Sollten solche Umfragen stattfinden, sollte mMn nach dem Beschluss eine Stellungnahme von uns warum es so entschieden wurde auf den Social Media Kanälen geposted werden, um je nach dem einen anderen Ausgang als den der Umfrage zu rechtfertigen, damit nicht der Eindruck entsteht wir würden Scheinumfragen o.ä. machen.--DeXter 15:24, 20. Dez. 2019 (CET)

Eingeschlafen oder geht es hier noch weiter? Wir verwenden immernoch die alten Icons. Gruß * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 13:29, 13. Jan. 2020 (CET)

Ich bin gerade mehr durch Zufall auf diese Diskussion gestoßen. Zugegeben, so furchtbar finde ich die neuen Icons gar nicht, eher einfach nur etwas groß. Die ganze Diskussion ist total auf diese "Wie machen wir eine Umfrage"-Schiene gerutscht. Die Idee an sich ist zwar nett, aber wenn sich daran dann die Diskussion aufhängt, ist uns damit leider auch nicht geholfen. Vielleicht sollte man anstatt seine ganze Energie in eine Umfrage bei wo auch immer zu stecken, einfach ganz unvermittelt hier eine Abstimmung starten. Ich wundere mich gerade sowieso, wieso das eine Abstimmung braucht, früher wurde das doch auch einfach direkt zu den neuen Icons umgesetzt, oder? :'D Lg --Fliegen bis zum Horizont. Killuu 15:25, 29. Apr. 2020 (CET)

Das ganze war etwas versandet, nachdem auf Discord einige Zeit darin investiert wurde, Icons zu erstellen, die aktuell wirken aber gleichzeitig auch noch nutzerfreundlich sind, dann aber gestoppt wurde, weil wir keine selbsterstellten Icons mehr nutzen wollen und zuletzt Zeit darein investiert wurde, diese wo vorhanden gezielt zu entfernen. Ein Mittelweg wäre daher an dieser Stelle ausgeschlossen, man müsste also tatsächlich zwischen den beiden Möglichkeiten, die eingangs von Mec erwähnt wurden, entscheiden. -- RobbiRobb 15:49, 29. Apr. 2020 (CEST)

Ich bin immer noch dafür das wie von GrollenKette vorgeschlagen zu machen. Den Link könnte man dann neben Twitter/Facebook auch auf Discord irgendwo sowie im Wiki erwähnen. Wikiseitig ist nur etwas blöd das wir die Sitenotice grad für die VbW brauchen. --Datei:Sugimori 672.pngMecanno-man^Mäh 17:19, 29. Apr. 2020 (CEST)

Da bin ich nach wie vor anderer Meinung, Mec. Und nun geht die Diskussion wieder in dieselbe Richtung, wie von der lieben Killuu angemerkt, weshalb ich nicht verstehe, warum es just wieder nur darum zu gehen hat, wie die Abstimmung auszusehen hat...

Anstatt sich wie die letzten 10 Jahre auf eine Abstimmung im Wiki einzulassen, die schnell organisiert und gut nachvollziehbare Stimmen mit Argumenten ermöglicht, möchtest du dich urplötzlich auf Stimmen verlassen, bei denen weder erkennbar ist, ob sie ernst gemeint sind, es doppelte Stimmabgaben mittels verschiedener Accounts bzw. einfach auf unterschiedlichen Plattformen gegeben hat und am Ende vermutlich überhaupt nicht möglichst objektiv einschätzen können, in welchen Artikeln das zu Veränderungen führt. Das kann ich nicht nachvollziehen.

Ich bin mir sicher, dass wäre die Abstimmungsart von Anfang an gar nicht ins Spiel gebracht worden, hätten wir unlängst eine umgesetzte Entscheidung innerhalb des Wikis. ~ Taisuke ^Diskussion 17:32, 29. Apr. 2020 (CEST)

Der Grund warum ich das nicht einfach als Wiki-Abstimmung machen möchte ist, das sich das Thema gut dazu eignet Aufmerksamkeit für die Arbeit am Wiki zu generieren. Es ist ne banale ja/nein-Frage wo man sich nicht all zu lange einlesen muss um mitentscheiden zu können. Ausserdem kann man mit einer öffentlichen, transparenteren Abstimmung auch schonmal die "Öh, warum isn das jetzt so, das is doof"-Kommentare umgehen. --Datei:Sugimori 672.pngMecanno-man^Mäh 18:12, 29. Apr. 2020 (CEST)

Solche Entscheidungen sind aber nicht dafür da, um damit irgendwelche sozialen Kanäle zu beleben. Wer im Wiki mitentscheiden möchte, arbeitet mit und erarbeitet sich das Recht dafür. Wollen wir beispielsweise die Stimmberechtigung nun ad absurdum führen, da nun einfach jeder Hans und Franz Mitspracherecht innehat? Ich meine, wofür ist dieser Rang dann überhaupt noch da? Versteh mich nicht falsch, für Meinungsumfragen oder anderweitiges Feedback über soziale Kanäle bin ich jederzeit zu haben und auch dankbar, aber eine Entscheidungsgewalt außerhalb des Teams etablieren zu wollen, halte ich für grundsätzlich falsch. Wenn ich mich – überspitzt gesagt – fortan bei wichtigen Grundsatzentscheidungen immer einer fremden bzw. äußeren Marschroute beugen muss, dann weiß ich nicht, wie lange der Laden hier noch läuft. ~ Taisuke ^Diskussion 18:35, 29. Apr. 2020 (CEST)

Insgesamt unterstütze ich Tais Argumente. Robbi hat gerade auf Discord noch einen ganz wichtigen Punkt reingeworfen. Falls für irgendeine Abstimmung irgendein Account außerhalb des Wikis nötig ist, nimmt man eventuell stimmberechtigten Nutzern ihr Abstimmungsrecht. Ich würde außerdem auf Social Media eher sowas schreiben wie "Es wurde XY entschieden. Wollt ihr bei der nächsten Abstimmung auch eure eigenen Ideen einbringen? Dann werdet zum Wikinger!". Und insgesamt finde ich es verwunderlich, dass sowas banales zur Abstimmung mit der Leserschaft vorgeschlagen wird, diese aber bei ganz anderen Dingen außen vor gelassen wird, zum Beispiel nicht im Anschluss nach ihrer Meinung gefragt wird (aka Attackenauslagerung, das scheint ja immer wieder zu Problemen zu führen). Ich meine sowas wie "Wir haben die Pokémonseiten umstrukturiert, wie findet ihr das?" oder so. Insgesamt empfinde ich es halt als unbefriedigend, dass diese doch so leicht entscheidbare Sache hier seit Ewigkeiten hier rumgammelt wegen einer eigentlich ganz anderen Diskussion (Beleben von Social Media). Wollte hierzu ja eigentlich nichts mehr schreiben, weil ich meine Meinung schon kundgetan hatte, ich hoffe, du bist mit dieser Antwort halbwegs zufrieden Mec :). --Fliegen bis zum Horizont. Killuu 21:32, 29. Apr. 2020 (CET)

Die meisten Sachen sind zu kompliziert für eine allgemeine Umfrage; die Attacken-Auslagerung war ja z. B. hauptsächlich aus technischen Gründen herausgegangen - das ist nicht etwas, was einem normalen User voraussetzbar ist. Deshalb finde ich ja gerade dieses Thema eignet sich dafür - es ist extrem simpel. --Datei:Sugimori 672.pngMecanno-man^Mäh 21:51, 29. Apr. 2020 (CEST)

Vielleicht habe ich es zu schwammig formuliert. Ich meine nicht, dass zum Beispiel die Attackenentscheidung durch Leser hätte entschieden werden sollen, sondern dass man ihnen im Nachhinein nochmal Möglichkeiten für Kritik und neue Anregungen gibt. --Fliegen bis zum Horizont. Killuu 21:55, 29. Apr. 2020 (CET)

Da ich ja durch das voreilige Erstellen einer Testumfrage ja nicht ganz unschuldig bin an der aktuelle Situation, hier mal meine Meinung: Sowohl Mec als auch Tai bringen Argumente, die ich unterstütze. Zum einen müssen immer noch die Personen hinter dem Wiki entscheiden, wie und ob die Typ-Icons aus SWSH benutzt werden sollen. Zum anderen wäre es natürlich hilfreich die Meinung der Leser mit einzubeziehen, da diese eventuell Interesse hätten an der Verwendung der neuen Icons. Die Idee, das ganze über Social Media zu machen, kam ja auch, da unsere, zu diesem Zeitpunkt toten, Kanäle (besonders Twitter) einen kleinen Push brauchten.
Insgesamt bin ich der Meinung, dass man den Lesern über Social Media ein minimalstes Mitentscheidungsrecht geben sollten, in Form der Umfrage. Diese sollte dann aber klar als Meinungssammlung ersichtlich sein und auch klarstellen, dass im Anschluss an die Umfrage alle Stimmberechtigten Benutzer eine Abstimmung halten über das weitere Vorgehen unter Betrachtung der Umfrage halten. So geben wir den Lesern nur ein kleines Mitspracherecht und das ganze Vorhaben wird immer noch von den aktiven Autoren, die sich mehr mit dem Wiki auskennen entgültig entschieden. GrollenKette951 22:10, 29. Apr. 2020 (CEST)

Ich glaube eine nicht-bindende öffentliche Meinungsumfrage ist so ziemlich das schlechteste was wir machen können. Wenn wir uns da dann im Nachhinein anders entscheiden wird das eine Imageschädigung zur Folge haben - das genau Gegenteil von dem was wir mit einer öffentlichen Umfrage bewirken wollen. --Datei:Sugimori 672.pngMecanno-man^Mäh 03:21, 30. Apr. 2020 (CEST)

Da ich mit meiner Meinung weitestgehend alleine bin, will ich die Entscheidungsfindung nicht länger aufhalten. Führt eure Umfragen auf den sozialen Kanälen durch und setzt das danach dann zeitnah dem Ergebnis entsprechend um. Ich werde mich an dem Prozess nicht beteiligen und auch nicht abstimmen. Bin schon gespannt, welche Frage zukünftig mit Ja oder Nein beantwortet werden kann und daher als „simpel“ oder „banal“ genug angesehen wird – trotz einer hier über sechs Monate geführten Diskussion ohne Ergebnis – um sie erneut an eine kleine Gruppe der Leser abzugeben. Lustigerweise wissen wir über unser Entscheidungsgremium lediglich, dass sie mal ein „Like“ hinterlassen haben. Ob sie das PokéWiki überhaupt (noch) aktiv nutzt, weiß niemand. Die meisten stillen Mitleser werden durch die beiden Kanäle wohl kaum das Gefühl bekommen, dass sie mehr einbezogen worden sind als sonst. Aber bevor ich hier noch weiter ausschweife, lasse ich es lieber sein. Have fun! ~ Taisuke ^Diskussion 08:41, 30. Apr. 2020 (CEST)

Nur mal so am Rand. @Tai, ich teile hier vollständig deine Meinung. Gruß * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 09:00, 30. Apr. 2020 (CEST)

Pro Tai! --Toben des Meeres. Killuu 09:56, 30. Apr. 2020 (CET)

Die DLCs

Ich weiß nicht, wie weit es schon klar ist, wie wir sie behandeln. Aber ich wäre für eigene Artikel und Kürzel. Z.B. IR=Insel der Rüstungen und SK=Schneelande der Krone. Weitere Meinungen dazu bitte. Das Isso 08/15 ^Konter 22:59, 9. Jan. 2020 (CET)

Da die DLCs Versionsunterschiede haben werden bräuchte man zumindest zwei/DLC, einfach nur IR und SK werden also nicht passen. --Datei:Sugimori 672.pngMecanno-man^Mäh 03:11, 10. Jan. 2020 (CET)

🤔 Für was überhaupt? Es ist immernoch die Galar-Region und immernoch Vorlage:Spielkuerzel/StVorlage:Spielkuerzel/Sd. Wenn wir soetwas brauchen würden dann würde ich nicht die Einzelnen Inseln nehmen sondern ein in Gelb/Grün gehaltenes EX wie es die offizielle Seite macht oder EP für Erweiterungspass, natürlich in Sk-Optik. So lässt sich bei bedarf das Kürzel für den Erweiterungspass dahintersetzen, denn in diesem sind beide Inseln enthalten, denn die Unterschiede sind nicht zwischen den Inseln sondern weiterhin zwischen den Spielen. Und Linktechnisch hätte ich gesagt geht das EX/EP dann entweder zu StSd/EX bzw. EP oder man macht aufgrund des Kontent einen eigenständigen Artikel StSw EX bzw. EP. Grüße * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 08:51, 10. Jan. 2020 (CET)

Der Ansatz und das Design deiner Idee gefällt mir, Ryu. Leider gibt es zwischen den Inseln auch Unterschiede. So sind unterschiedliche Pokémon auf den Inseln erhältlich, z. B. Coronospa erst mit dem zweiten Teil des Erweiterungspasses. Daher brauchen wir in meinen Augen schon mehr als nur ein Kürzel. ~ Taisuke ^Diskussion 09:23, 10. Jan. 2020 (CET)

@Taisuke: Die unterschiedlichen Pokémon sind doch Schwert, Schild abhängig was auf der Rüstungsinsel und später auf der Krone kommt, da der EX-Pass für beide Inseln pro Spiel ist wüsste ich nicht für was es weitere Sks benötigt. Auf der Rüstungsinsel gäbe es 3 Kombinationen Vorlage:Spielkuerzel/StEX, Vorlage:Spielkuerzel/SdEX, und Vorlage:Spielkuerzel/StVorlage:Spielkuerzel/SdEX oder man macht 3 einzelne Sk mit StEX, SdEX und StSdEX.... ob man da eines macht und das immer dran hängt oder 3 separate soll mir da egal sein, jedenfalls lässt sich mit diesen mMn eindeutig zeigen: das der Content Editionsabhängig ist und das dafür der EX-Pass benötigt wird der ja schließlich beide Inseln freischaltet. Somit hat jeder mit Zugang zur Rüstungsinsel später auch Zugang zur Krone.... daher kann ich der Notwendigkeit mehrerer Sks nicht ganz folgen da es ja nur ein Pass ist. Gruß * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 09:39, 10. Jan. 2020 (CET)

Man könnte auch nehmen was da ist wie hier am Beispiel Sk plus das jeweilige Icon... mein Favorit ist aber weiterhin EX da es kurz prägnant und zudem in Kombination mit dem Spielkürzel mMn ausreichen wäre

Vorlage:Spielkuerzel/StDatei:Icon Rüstungsinsel.png

Vorlage:Spielkuerzel/StDatei:Icon Kronen-Schneelande.png

Vorlage:Spielkuerzel/StDatei:Icon Rüstungsinsel.pngDatei:Icon Kronen-Schneelande.png

Vorlage:Spielkuerzel/SdDatei:Icon Rüstungsinsel.png

Vorlage:Spielkuerzel/SdDatei:Icon Kronen-Schneelande.png

Vorlage:Spielkuerzel/SdDatei:Icon Rüstungsinsel.pngDatei:Icon Kronen-Schneelande.png

Vorlage:Spielkuerzel/StVorlage:Spielkuerzel/SdDatei:Icon Rüstungsinsel.png

Vorlage:Spielkuerzel/StVorlage:Spielkuerzel/SdDatei:Icon Kronen-Schneelande.png

Vorlage:Spielkuerzel/StVorlage:Spielkuerzel/SdDatei:Icon Rüstungsinsel.pngDatei:Icon Kronen-Schneelande.png

* Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 11:21, 10. Jan. 2020 (CET)

Ich wüsste nicht, was dagegen sprechen würde, für jeden Teil des Erweiterungspasses ein eigenes Spielkürzel, im Endeffekt also insgesamt vier neue (Schwert-Rüstung, Schild-Rüstung, Schwert-Krone, Schild-Krone) einzuführen. Ich kann für mich hauptsächlich für den Item-Bereich sprechen, aber ich kann mir auch vorstellen, dass auch andere Bereiche davon profitieren könnten. Und zwar möchte ich ungerne neue Item-Fundorte zu den bereits existierenden hinzufügen, um Besucher, die die DLCs nicht besitzen, nicht zu verwirren, wenn dort Fundorte für Orte angegeben sind, die sie überhaupt nicht erreichen können. Da beide DLCs jeweils einen neuen Bereich freischalten, würde ich da auch gerne die Fundorte getrennt anbieten können, sodass dort auch nicht gemischt wird. Ich denke, die Richtung, in die ich möchte, sollte klar werden ^^

Visuell wäre ich dafür, einfach einen weiteren Buchstaben anzuhängen, der neben dem Hauptspiel klar macht, welche Erweiterung gemeint ist: STR, SDR, STK, SDK. Damit wäre man für alle möglichen Lagen gewappnet und müsste sich keine Sorgen machen, wenn irgendwelche verrückten, Editions- und gleichzeitig auch noch DLC-Spezifischen Inhalte kommen, bei denen wir uns eigentlich sicher sein können, dass es sie geben wird. -- RobbiRobb 17:34, 10. Jan. 2020 (CET)

Ich denke auch, dass neue Spielkürzel sinnvoll wären. Die Anhängung eines weiteren Buchstabens, wie mein Vorredner es bereits verdeutlichte, finde ich als Lösung recht einfach und gut.

P.S.: Wir haben ja sogar n Spielkürzel für etwas, das nicht einmal ein Spiel ist: Pokémon Bank BANK :D also warum dann einer Erweiterung, die ja schon etwas neues ist, das verwehren? -- GrüßeShortyBuzz 17:43, 10. Jan. 2020 (CET)

Mein Problem ist eher das einige Sks sowohl für Rüstung als auch Krone wollen, wo ich bisher immernoch nicht den Sinn heraus sehe da ja jeder der DLCs beides beinhaltet (Rüstung und Krone) nur halt Zeitversetzte veröffentlichung in 2 teilen und jeder der sich im Herbst den Pass für Krone holt sollte damit auch zur Rüstung kommt, mir würde jetzt kein Szenario einfallen was beides benötigt. Aber lässt sich ja wenn es soweit ist alles nochmal ändern Gruß * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 18:43, 10. Jan. 2020 (CET)

Ich würde das ganze erst einmal abwarten und schauen, in wie weit es wirklich notwendig ist. ~ TiMauziDatei:Pokémonsprite 052 Fuß.png 03:45, 12. Jan. 2020 (CET)

Dem kann ich nur zustimmen -- Opii Wunschtraum 17:21, 13. Jan. 2020 (CET)

Mal eine Frage, wie wollen wir Die Insel der Rüstung und Die Schneelande der Krone behandeln? AN und für sich sind sie durch Neue Handlung, neue Pokémon usw wie eine Zusatzedition die einfach nur direkt ins aktuelle Spielnachgepacht wird. Daher fände ich es sinnvoll die DLC wie eigenständige Zusatzeditionen inklusive Spieleartikel zu behandeln. WIe ist da hier die allgemeine Meinung zu? Gruß * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 19:31, 21. Jan. 2020 (CET)

Der Meinung bin ich nicht. Es bleibt dasselbe Spiel wie vorher, zumal ja die Pokémon auch für die dazugepatcht werden, die den DLC nicht erwerben. Gleichnis: Mario Kart 8 ist auch Mario Kart 8 geblieben, obwohl damals 4 neue Cups hinzugefügt wurden. Etwas anderes ist das hier auch nicht. Zudem bin ich der Ansicht, dass wir für solche Entscheidungen abwarten sollten, in wiefern die Erweiterungspässe wirklich wie "eigene Spiele" behandelt werden können. Außerdem bin ich der Meinung, dass die Idee dahinter gar nicht neu ist. Früher hat man halt solche neuen Inhalte schon vorher auf das Spiel gepackt und einfach nur (mehr oder weniger erfolgreich) versucht geheim zu halten (Eichs Brief, Azurflöte ...). Im Grunde waren das auch nichts weniger als kleine (kostenlose) DLCs. Mit dem Unterschied, dass heute so etwas wirklich geheim gehalten werden kann, indem man erst später in die Spiele einfügt.

Also kurzum: Ich bin nicht dafür, dass man diese DLCs so separiert betrachtet. ~ TiMauziDatei:Pokémonsprite 052 Fuß.png 21:35, 21. Jan. 2020 (CET)

Seh ich ähnlich wie TiMauzi; wir sind btw so auch schon mit vorherigen Zusatzinhalten so verfahren (z. B. die Updates in Go oder die Portale-DLCs) --Datei:Sugimori 672.pngMecanno-man^Mäh 22:23, 21. Jan. 2020 (CET)

Ich würde mich freuen wenn wir die Diskussion Zeitnah zu Ende bringen. Persönlich würde ich mich bereits anhand des Materials vom ersten DLC für neue SK aussprechen. z.b. Vorlage:Spielkuerzel/St EX, Vorlage:Spielkuerzel/Sd EX und Vorlage:Spielkuerzel/StVorlage:Spielkuerzel/Sd EX * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 17:16, 18. Jun. 2020 (CEST)

Hatte mich ja bereits auf Discord dafür ausgesprochen und spiele weiterhin mit dem Gedanken, bei den Items zwischen Hauptspiel und Erweiterungspass zu trennen, auch vor dem Hintergrund, dass bei einigen wenigen Items die Beschreibungen geändert wurden. () Die Frage ist aber ein Kürzel für beide Erweiterungen? Oder zwei getrennte, um noch mal besser differenzieren zu können? Für die Items wäre vermutlich letzteres praktischer, wie sieht das in anderen Bereichen aus? -- RobbiRobb 17:27, 18. Jun. 2020 (CEST)

Wie ich auch schon gestern merhfach im VC gesagt habe, bin ich eindeutig für eigene Spielekürzel; es entsteht nur Chaos, wenn dann mit dem StSd-Sk Sachen eingetragen werden, die aber nur im DLC vorhanden sind. Einfach um auf Nummer sicher zu gehen würde ich sagen eine Sk-Variante fürs 1. DLC und eine fürs 2. GrollenKette951 17:32, 18. Jun. 2020 (CEST)

Für z. B. die Fundortetabellen bei Pokémon und Items ist es sicherlich hilfreich eines zu haben, ich würde es aber z. B. bei Item- und Pokémontabellen in Orten lieber nicht sehen. Trotzdem sollte man imo. erst mal eines erstellen. --Datei:Sugimori 672.pngMecanno-man^Mäh 14:32, 19. Jun. 2020 (CEST)

Da wir alle keine Freunde von Abstimmungen sind, habe ich mich dazu entschlossen, die eigenen Spielkürzel ohne weitere Rückfragen zu erstellen. Aufgrund der Tatsache, dass Eintragungen oder Kontrollen nicht getätigt werden, weil hier erst eine Entscheidung benötigt wird, wäre es unangebracht noch mehr Zeit verstreichen zu lassen. Sollten wir feststellen, dass wir eines oder mehrere Spielkürzel nicht benötigen (Vorlage:Spielkuerzel/StRVorlage:Spielkuerzel/SdR, Vorlage:Spielkuerzel/StKVorlage:Spielkuerzel/SdK & Vorlage:Spielkuerzel/StEXSH^EX), können wir das zu einem späteren Zeitpunkt immer noch wieder ändern und die Einbindungen in Artikeln mittels eines Bots entfernen lassen. Auch die Linkziele könnten bei Bedarf noch angepasst werden. Jedoch ist es wichtig, erstmal etwas zu haben, mit dem man arbeiten kann. Schließlich entsteht gerade ein kleines Chaos durch unterschiedliche Handhabungen improvisierter Spielkürzel, sodass ein Bedarf an eigenen Kürzeln nicht von der Hand zu weisen ist. ~ Taisuke ^Diskussion 11:54, 22. Jun. 2020 (CEST)

Zentrale Hinterlegung von Trainerdaten

Hab mir vor kurzem überlegt das es eigentlich unsinnig ist sowohl Vorlage:Team/Kopf als auch Vorlage:Orte Trainer/Kopf zu haben, da beide schlussendlich in etwa dasselbe machen. Bei der Idee, einfach im Charaker-Projekt die Orte-Vorlage zu nutzen ist mir dann aufgefallen, das es mehr Sinn machen würde, die Daten einfach in einem Artikel zu hinterlegen und dann daraus in die anderen zu ziehen. Ich würde deshalb vorschlagen, die ganzen Daten in den Orten und bei Charakteren aus den Trainer-Unterseiten zu ziehen, und da in nem includeonly ne Vorlage drum zu bauen, das man über nen Parameter auswählen kann welchen Trainer man haben möchte. Die tatsächliche technische Umstrukturierung würde ich aber vorschlagen nur Stück für Stück zu machen, da das nicht wirklich iwas is, was all zu wichtig ist. Wollte demnach nur mal fragen ob hier jemand grundsätzlich dagegen ist, insbesondere @GoPika, Cliffichen, Ryuichi und SortyBuzz, sowie RobbiRobb, an dem das ganze wahrscheinlich hängen bleiben wird... --Datei:Sugimori 672.pngMecanno-man^Mäh 17:46, 27. Feb. 2020 (CET)

Erstmal, der Name SortyBuzz gefällt mir . Dann kann ich mir nicht wirklich vorstellen, wie das funktioniert mit der von dir angesprochenen Datenhinterlegung über includeonly und Parameter. Aus diesem Grund kann ich mich noch nicht zu 100 % dafür aussprechen, wobei ich den Vorschlag nicht schlecht finde. Kann man dort auch irgendwie Vorlage:Berühmte Trainer und/oder Vorlage:Weitere Trainer einbinden? -- Cliffichen 22:56, 28. Feb. 2020 (CET)

Ne das geht nicht, es geht mir nur drum das die Orte/Trainer nicht an drei Orten mit identscher Befüllung steht. --Datei:Sugimori 672.pngMecanno-man^Mäh 23:06, 28. Feb. 2020 (CET)

An und für sich habe ich nichts dagegen einen Zentralen Platz zu schaffen von dem aus die Daten abgegriffen werden können, ob dieses dann auch funktioniert ist die andere Frage. * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 23:31, 28. Feb. 2020 (CET)

Ich finde schön, dass schon davon ausgegangen wird, dass ich das übernehme. Das aber erst mal beiseite, ich halte es grundsätzlich für umsetzbar. Mit includeonlys und onlyincludes dürfte sich eine Struktur erstellen lassen, mit der sich alle Daten zentral an einem Ort lagern und in anderen Artikeln aufrufen lassen. Ich sehe allerdings zwei Probleme: Das System ist sehr anfällig, ein kleiner Fehler in den Konstrukten und es werden mehr als eine Seite zerlegt. Das führt auch gleich zum zweiten Problem: Einsteigerfreundlich sieht anders aus. Neue Nutzer werden schwierigkeiten haben, den Ursprung eines Fehler zu finden, helfen dadurch entweder gar nicht oder machen irgendwas anderes, um vielleicht doch noch ihr Ziel zu erreichen. In jedem Fall besteht die Gefahr, dass dabei ordentlich was schief geht. Sofern man aber bereit ist, dieses Risiko einzugehen, denke ich, dass man damit durchaus einen Gewinn haben könnte, da Daten dann global gleich sind. Vielleicht wäre es hier aber besser, noch in eine andere mögliche Richtung zu forschen, ob man die Daten nicht besser hinterlegen könnte. Wobei dann fragwürdig ist, ob es etwas gibt, dass sich leicht bedienen lässt und trotzdem in der Lage ist, unsere Daten zu speichern. -- RobbiRobb 23:33, 29. Feb. 2020 (CET)

So rein konzeptionell fällt mir keine Idee ein, auch nicht iwie mit externer Datenbank oder sowas, womit man die Daten von mehreren Orten aus ändern kann, ausser nem Bot der iwie auf Änderungen an der Vorlage achtet. Das halte ich aber für keine gute Idee. Demnach haben für mich alle potenziellen anderen Lösungen die von dir angesprochenen Userfreundlichkeits-Nachteile ebenfalls. Bezüglich das mit den mehreren Seiten kaputtmachen, ja das stimmt, gäbe es denn irgendwelche anderen Lösungen, die das umgehen und realistisch in der Umsetzung sind? --Datei:Sugimori 672.pngMecanno-man^Mäh 23:53, 29. Feb. 2020 (CET)

Die WMF-Extension LabeledSectionTransclusion könnte für so ein Unterfangen vermutlich hilfreich sein, und ist auch nicht allzu komplex. Das ermöglicht es, innerhalb einer Seite mehrere "benannte Onlyinclude" zu erstellen und per Parserfunktion einzubinden. Dadurch dürfte das Gesamtkonstrukt auch weniger fehleranfällig sein.

Eine umfangreiche Datenbanklösung neu aufzubauen (Zum Beispiel mit Wikibase, vermutlich alternativ mit Semantic MediaWiki oder Cargo) halte ich mit unseren personellen und technischen Ressourcen für unrealistisch, und wäre wenn ein Projekt, bei dem man sich mit Bulba kurzschließen sollte. Das Thema haben wir ja vor etwa 4 Jahren schon mal diskutiert.

-- Skelabra2509 (Diskussion | Beiträge) 17:44, 8. Mär. 2020 (CET)

Sind weitere Pokémon-Formen als Parameter notwendig?

Hallo zusammen!

Wie einige von euch sicherlich schon mitbekommen haben, liegen die HOME-Sprites sämtlicher Pokémon seit Upload noch nahezu ungebraucht herum. Das Ganze liegt an mir und einer Entscheidung, die ich diesbezüglich treffen müsste. Wollt ihr also einen Schuldigen haben: Hier bin ich!

Um das Ganze nun aber mal zu lösen, verfrachte ich die Entscheidung hierher, um sie nicht alleine treffen zu müssen, denn das möchte ich nicht. Grundsätzlich gab es im Jahre 2018 bereits eine kurze Diskussion zu diesem Thema, die aber am Ende ohne wirkliches Ergebnis eingeschlafen ist. Dies führte dazu, dass wir teilweise Duplikate und teilweise Weiterleitungen haben und ganz allgemein es in verschiedenen Vorlagen unterschiedlich gehandhabt wird.

Wer keine Lust hat sich die vorangegangene Diskussion durchzulesen (auch wenn sie nicht wirklich lang ist), bekommt hier ne kurze Zusammenfassung des Problems:

Es gibt bestimmte Pokémon, die in den Spieldaten über Formen verfügen, die bei uns aber als solche nicht verstanden werden. Am einfachsten lässt sich das an einem Beispiel erklären, wie z. B. Meteno. Grundsätzlich kennen wir die Meteorform und die sieben farbigen Kerne. Jedoch gibt es innerhalb der Spieldaten nicht nur eine Meteorform, sondern sieben: Eine je farbigen Kern. Auch wenn dies nie irgendwo ersichtlich ist, so handelt es sich in den Spieldaten um verschiedene Datensätze. Ein ähnliches und aktuelleres Dilemma haben wir beispielsweise bei Riffex, dessen Gigadynamax-Form bei beiden Formen (Hoch- und Tief-Form) dieselbe ist, sie in den Spieldaten aber als zwei unterschiedliche gehandhabt werden. Darüber hinaus gibt es aber auch bestimmte Event-Pokémon, wie z. B. Wuffels, die sich zwar nicht optisch vom eigentlichen Pokémon unterscheiden, jedoch spielintern als separate Form aufgeführt werden. Mit Pokémon Schwert und Schild gibt es nun zudem diese Wuffels-Form (heißt: mit Tempomacher) auch in Dyna-Raids.

Daher gilt es nun zu schauen und anschließend zu entscheiden, ob man zusätzliche Parameter für solche Fälle haben möchte oder nicht. Sollte man sich für die Verwendung einiger solcher neuen Parameter entscheiden, würden bei optischer Gleichheit keine Duplikate der Sprites, sondern Datei-Weiterleitungen erstellt werden.

Bevor ich hier aber noch weiter ausschweife, habe ich mich mit Ryu zusammengesetzt, um zu überlegen, welche weiteren Formen wir bislang nicht mit Parametern bedacht haben, warum dies der Fall war und ob man daran nicht etwas ändern sollte. Am Ende unserer Gespräche haben wir diese Formen wie folgt zugeordnet:

Benötigt einen Parameter:

(A): 658a (Quajutsu mit Freundschaftsakt) + 658b (Ash-Quajutsu) → gibt es bereits!

(B): 718c (50%-Zygarde mit Scharwandel) + 718d (10%-Zygarde mit Scharwandel)

(C): 744a (Wuffels mit Tempomacher)

(D): 6 weitere Parameter für die Meteorform von Meteno (vom nicht ersichtlichen farbigen Kern abhängig; wie diese Parameter dann genannt werden, ist noch nicht beschlossen – ob generell vor den Kernformen oder immer im Wechsel)

Benötigt keinen Parameter:

(E): 20 weitere Purmel-Parameter (je nach Form des Vivillon am Ende)

(F): 20 weitere Puponcho-Parameter (je nach Form des Vivillon am Ende)

(G): Zygarde-Kern und Zygarde-Zelle → sind momentan noch als Parameter vorhanden!

(H): Zweiter Parameter für G-Riffex aufgrund zugrunde liegender Form

(I): Weitere Parameter für G-Pokusan aufgrund zugrunde liegender Form

(J): Schatten-Mewtu (nur in Pokémon Tekken)

(K): Schatten-Dialga (nur in PMD)

(L): Lila Kecleon (nur in PMD)

(M): Herrscher-Pokémon, Crypto-Pokémon und Ähnliches

(N): Ukulelen-Pichu (nur in Ranger)

(O): Thu-Fi-Zer (nur im Manga)

(P): Volly (nur im Manga)

(Q): Kristall-Onix (nur im Anime)

(R): Kostümierte Pokémon aus Shuffle & GO (lediglich Kostüme)

(S): Rüstungs-Mewtu (zwar unterschiedliche Medien mit Anime & GO, aber aus unserer Sicht ein Kostüm)

Keine eindeutige Entscheidung:

(T): Klon-Pokémon (sowohl im Anime als auch in Pokémon GO vorhanden)

(U): Crypto-Lugia (zentrales Pokémon des Spiels)

Nachträglich hinzugefügt:

(V): Moterpel (besitzt spielintern je nach Form von Burmy eine von drei Formen)

Den Entscheidungen liegt zugrunde, dass wir im Vorfeld alle möglichen Formen unterschiedlichster Medien gesammelt haben, ganz unabhängig, ob sie denn auch in Spielen vorkommen. Danach haben wir geschaut, ob diese Formen auch in mehr als einem Medium vorkommen, um deren Wichtigkeit einschätzen zu können. Vorrang hatten hierbei jedoch stets in den Hauptspielen auftretende Formen, die nicht zwingend in einem weiteren Medium berücksichtigt werden mussten.

Wir haben versucht, eine gewisse Balance zu wahren und stellen euch hiermit vor, welche Parameter wir am ehesten hinzufügen würden. Damit dieser Beitrag nicht noch mehr ausufert, habe ich die Begründungen für einzelne Fälle kurz gehalten oder gar ganz weggelassen. Für Rückfragen und Anregungen sind wir jedoch stets offen; wollen aber auch zeitnah eine Umsetzung anstreben. Deshalb wäre es cool, die Sache kurz abzunicken oder Verbesserungsvorschläge zu machen.

Abstimmung

Abstimmung abgeschlossen

Aus diesem Grund schließe ich diesen Beitrag mit einer zweiwöchigen Abstimmung (Ende: 27. Juli 2020 um 23:59 Uhr), bei der ihr euch entweder an unserer Einschätzung orientieren oder bestimmte Einzelfälle anders einschätzen könnt. Wahlberechtigt sind bei dieser Wahl alle stimmberechtigten Benutzer! Am Ende der zwei Wochen wird jeder Parameter mit einer ⅔-Mehrheit hinzugefügt oder eben nicht. Somit haben wir dann endlich mal eine bindende Grundlage für diese Entscheidung!

Legende:

✔ → Es soll einen Parameter für diesen Fall geben.

✘ → Es soll keinen Parameter für diesen Fall geben.

— → Ich enthalte mich, ob es für diesen Fall einen Parameter geben soll.

Benutzer	A	B	C	D	E	F	G	H	I	J	K	L	M	N	O	P	Q	R	S	T	U	V
Taisuke	✔	✔	✔	✔	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘
Ryuichi	✔	✔	✔	✔	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✔	—	✘
SwowoJonny	✔	✔	✔	✔	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	—	—	—	✘	✘	✔	✔	✘
Haijo18	✔	✔	✔	✔	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✔	—	✔	✘
BeyJim	—	—	—	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✔	✔	✘
Mooni000	✔	✔	✔	—	✘	✘	✘	✘	✘	✔	✔	✔	✘	✘	✘	✘	✘	✔	✔	—	✔	✘
Mecanno-man	✔	✔	✔	✔	✔	✔	✘	✔	✔	✘	✘	✘	✔	✘	✘	✘	✘	✔	✔	✔	✔	✔
Impoleon xy	✔	✔	✘	✔	✔	✔	✔	✔	✔	—	—	—	—	✘	✘	✘	✘	—	—	—	—	✔
GrollenKette951	✔	✔	✔	✔	—	—	✘	✔	✔	✘	✘	✘	—	✘	✘	✘	✘	✔	✔	✔	✔	—
DeXter	✔	✔	✔	✔	✔	✔	✘	✔	✔	✘	✘	✘	✔	✘	—	✘	✘	✔	✔	✔	—	✔
Nescientist	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
Pk-fan	✔	✔	✔	✔	✔	✔	✔	✔	✔	✘	✘	✘	✔	✘	✘	✘	✘	✘	✘	✘	✘	✔
RobbiRobb	✔	✔	✔	✘	✘	✘	✘	✘	✘	✘	✔	✘	✔	✘	✘	✘	✘	✘	✘	✘	✔	✘
Isso08-15	✔	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✘	✔	✘	✘	✘	✘	✔	✔	✔	✔	✘
Zeynex	✔	✘	✘	✘	✘	✘	✘	✘	✘	✔	✔	✔	✘	✘	✘	✘	✘	✔	✔	✔	✔	✘
BlauesSerpiroyal	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—	—
Lasagne	✔	✔	✔	—	—	—	✘	—	—	✘	✘	✘	✔	✘	✘	✘	✘	—	—	—	—	✘
Ergebnis

Kommentare

Ich habe bereits meine Stimmen für die einzelnen Fälle angegeben, sodass ihr euch an dem Muster orientieren bzw. die Zeile als Vorlage für eure Stimmen nutzen könnt. Und am Ende geht wie immer ein Ping an alle stimmberechtigten Benutzer, damit niemand sagen kann, er hätte von dieser Abstimmung nichts mitbekommen. :)

Grüße gehen raus an: Buoysel, Cliffichen, CLina, DeXter, GoPika, GrollenKette951, Impoleon xy, Isso08-15, Kenaz-Hagalaz, Lombrero, Luca12379, Matze, Mecanno-man, RobbiRobb, Ryuichi, ShortyBuzz, Simonsees, SwowoJonny + AAWiki, BeyJim, BlauesSerpiroyal, Der Sternendiamantritter, Haijo18, Hydrokyu, Jass, Killuu, K0pplosio, Lasagne, Mario-WL, Mooni000, Nescientist, Pintauranimus, Pk-fan, PokéSpe, PokemontutorialTV, Vircaprae, Xatuhatu, Zeynex

Ich hoffe, nichts vergessen zu haben. ^_^ ~ Taisuke ^Diskussion 12:35, 13. Jul. 2020 (CEST)

Ich bin mir hier nicht vollständig im klaren darüber, für was für eine Änderung hier abgestimmt wird. Es ist meiner Meinung nach offensichtlich das einige Vorlagen einige dieser Sonderfälle irgendwie berücksichtigen müssen (z. B. Go-Sprites mit Hut) und andere nicht (irgendwelche Strategie-Sachen brauchen den ganzen Co-Kram garantiert nicht). Geht es hier einfach darum zu entscheiden, was die XXXa-Nummern etc. bekommt? Wenn ja, wie würden dann andere Sachen miteinbezogen, die nicht in dieses Schema passen? Wäre es evtl. eine Idee hierfür Schema wie XXXzz, XXXzy etc. zu nutzen, für non-Hauptspiel-Sachen? Oder hab ich hier völlig am Thema vorbeigeschossen und es geht um etwas anderes? --Datei:Sugimori 672.pngMecanno-man^Mäh 14:09, 13. Jul. 2020 (CEST)

PS: In der Liste fehlt Moterpel. Das hat spielintern auch drei Formen.

Danke für den Hinweis mit Moterpel, das habe ich als nun als weitere Option ergänzt. Da müsstet ihr Fünf (1, 2, 3, 4, 5) am besten nochmals schauen und eure Entscheidung diesbezüglich nachtragen. :)

Um aber auf deine eigentliche Frage zurückzukommen: In erster Linie sollte es hiermit eigentlich generell um neue Parameter gehen, die unserem bisherigen Schema folgen (XXXa), aber im Gegensatz zu den vorhandenen Formen (noch) nicht berücksichtigt werden. Die restlichen Punkte sind im Zuge dessen ins Auge gesprungen und haben für uns auch eine Erwähnung hier verdient, um zu schauen, ob wir solche Formen zukünftig auch berücksichtigen wollen. Momentan werden Spin-off-Sonderfälle wie die unzähligen Pikachu-Formen in Shuffle oder GO einfach als 025_X genutzt, sodass z. B. die Sprites-Vorlage auf diese zurückgreifen kann. Aber als eigenständige Parameter sind diese bislang nicht angelegt, da Vorlage:Namenr usw. mit diesem nie (?) genutzt werden würden. So ähnlich würde es doch vermutlich auch den anderen Spin-off-Sonderfällen gehen oder?

Falls das in der Art aber nicht mehr erwünscht wäre und wir dafür ein neues Parameter-Schema, wie von dir vorgeschlagen, nutzen wollen würden, wäre das für mich natürlich auch in Ordnung. ~ Taisuke ^Diskussion 14:20, 14. Jul. 2020 (CEST)

Danke für die Antwort; möchte hier noch kurz meine Stimmen erklären: Meiner Meinung nach macht es Sinn das aktuelle Schema nur für Hauptspiele + eventuell Go zu verwenden (wegen zukünftiger Home-Anbindung), da man nur bei diesen wirklich davon ausgehen kann das sie vorwärts getragen werden, irgendwie. Bei Formen die irgendwelche non-Unterschiede haben (Purmel, Moterpel etc.) macht es von mir aus gesehen weiter Sinn diese zu allokieren, damit nicht in Zukunft irgendwelche botgestüzte Programme beim durchgehen irgendeines Spiele-extracts durcheinander geraten. All zu viel Einfluss sollte das ja schlussendlich kaum haben, da diese Werte wahrscheinlich nirgends benutzt werden würden. Die anderen Spin-Off-Sachen (Shuffle, PMD, etc.) könnten in eine Art Nebenschema eingefügt werden, sei dies über 352zzz oder sowas wie 352lila, wobei letzteres wahrscheinlich sinnvoller wäre da so nicht ein Haufen kurioser Buchstabenketten entstehen - so können diese grundsätzlich auch über dieselben Vorlagen aufgerufen werden, wo nötig. Ich würde allerdings davon absehen Anime-, Manga und TCG-spezifische Sachen* aufzunehmen; selbst wenn man diese einfügt wüsste ich nicht wo man sie gescheit verwenden könnte. --Datei:Sugimori 672.pngMecanno-man^Mäh 15:59, 14. Jul. 2020 (CEST)

Ich vermute mal, dass Mecanno-man mit den TCG-spezifischen Sachen sowas wie Koiking-gokku Pikachu und Poncho o Kita Eievui meint, oder vergesse ich hier noch mehr TCG-Sonderfälle, die ich kenne sollte? GrollenKette951 00:17, 15. Jul. 2020 (CEST)

Naja, Delta-Pokémon könnte man diskutieren, aber die Kostüme war schon eher das was ich gemeint hab. Plus all die anderen sinnlosen, also iwie das einkaufende, das Fussballspielende etc. --Datei:Sugimori 672.pngMecanno-man^Mäh 01:12, 15. Jul. 2020 (CEST)

Als jemand, der sich mit diesem Thema noch nicht wirklich auseinandergesetzt hat, würde ich gerne wissen, was genau der Nutzen dieser zusätzlichen Parameter wäre, wenn die Sprites gleich sind. Ist es eine Absicherung für den Fall, dass z. B. irgendwann die Sprites von den Meteno-Meteorformen so geändert werden, dass man die Farbe des Kerns erkennen kann? Oder werden aktuell bzw. sollen irgendwann über Vorlagen zusätzliche Informationen anhand des eingestellten Form-Parameters dargestellt werden, z. B. die verfügbaren Fähigkeiten des Pokémon?
Eine Sache, die ich aber auf jeden Fall noch anmerken möchte, ist dass sowohl die Herrscher-Pokémon als auch die Pokémon in Herrscher-Größe (gegen erstere kämpft man in SM/USUM, letztere kann man in USUM erhalten) sich nicht nur durch ihre Darstellungsgröße unterscheiden, sondern zumindest laut Bulbapedia auch in den Werten Größe und Gewicht (ich weiß nicht, ob diese Werte im PokéWiki überhaupt irgendwo eingetragen sind, auf Bulbapedia stehen sie aber auf jeden Fall hier). Das erhöhte Gewicht dieser Pokémon in Herrscher-Größe hat sogar aufgrund von Attacken wie Rammboss oder Strauchler sogar Auswirkungen auf Kämpfe. Zudem haben diese Herrscher-Pokémon festgelegte Fähigkeiten. Auch wenn diese Formen bzw. Größen mit der 8. Generation wieder entfernt wurden, sind solche direkten spielerischen Unterschiede meiner Meinung nach ein besserer Grund für eigene Parameter als solche indirekten und ausschließlich optischen wie bei Meteno, zumindest wenn ich mit meinen Vermutungen bezüglich des Nutzens dieser Parameter einigermaßen richtig liege. -- Lasagne (Diskussion) 22:52, 14. Jul. 2020 (CEST)

Edit: Ich habe meinen Kommentar mal verschoben, da ich versehentlich in eine andere Diskussion reingegrätscht bin. Ich hoffe, diese Änderung geht so in Ordnung. Ich würde mich trotzdem freuen, wenn jemand noch meine Frage beantwortet. -- Lasagne (Diskussion) 12:54, 19. Jul. 2020 (CEST)

Die späte Antwort tut mir leid, Lasagne. Dein Beitrag ist tatsächlich etwas untergegangen bzw. mir einfach durchgerutscht. Kurz gefasst geht es um die Kennzeichnung von abweichenden Formen von Pokémon im Quelltext und eine andere Darstellung durch Vorlageneinbindungen. Hierdurch wird den Lesern und Benutzern angezeigt, dass es sich um eine andere Form handelt, die sich zwar nicht optisch, aber spielintern (z. B. durch eine andere spezielle Fähigkeit) unterscheiden. Es haben hierbei also nicht ausschließlich optische Unterschiede den Ausschlag gegeben. Vor allem in deinem Beispiel von Meteno, haben die Meteorformen optisch gar keinen Unterschied, weshalb ich das Beispiel nicht ganz verstehe und mir etwas unsicher bin, ob ich deine Frage überhaupt richtig verstanden habe. ^_^ ~ Taisuke ^Diskussion 14:01, 30. Jul. 2020 (CEST)

Danke für die Antwort, Taisuke, auch wenn sie für die Abstimmung etwas zu spät war. Damit verstehe ich schon ein bisschen besser, wozu diese Parameter eigentlich gut sind.
Mit dem Meteno-Beispiel meinte ich, dass Game Freak sich in irgendeiner späteren Generation dazu entscheiden könnte, das Design der Meteorform-Sprites so anzupassen, dass man die Farbe des Kerns erkennen kann. Auf diesen Fall wäre das PokéWiki vorbereitet, wenn jetzt diese Parameter hinzugefügt werden.
--Lasagne (Diskussion) 19:07, 30. Jul. 2020 (CEST)

Umsetzung

Danke an alle, die sich an der Abstimmung beteiligt haben! Ich werde mich um eine Umsetzung der mehrheitlich beschlossenen Parameter kümmern und im Anschluss hier nochmals auflisten. ~ Taisuke ^Diskussion 14:01, 30. Jul. 2020 (CEST)

Seh ich das richtig, das nur die Go-Klone eingefügt werden? Schliesslich bringt DeXters ver-ttte Stimme das ganze über die 2/3. --Datei:Sugimori 672.pngMecanno-man^Mäh 02:30, 31. Jul. 2020 (CEST)

Dafür hatte ich extra eine Ergebnis-Zeile eingefügt. Ja, die Klon-Pokémon werden eingefügt. Crypto-Lugia hat aber neben den vier ersten Fällen auch genügend Stimmen erhalten. ~ Taisuke ^Diskussion 12:53, 31. Jul. 2020 (CEST)

Du hast mich da leicht falsch verstanden. Meine Frage ist, ob die Go-Klone eingefügt werden, die Anime-Klone allerdings nicht. --Datei:Sugimori 672.pngMecanno-man^Mäh 17:04, 31. Jul. 2020 (CEST)

Mein Fehler, entschuldige. Lediglich die Klone, die in beiden Medien zu finden sind: Bisaflor, Glurak, Turtok und Pikachu. Oder mit anderen Worten: Nur die GO-Klone. :D ~ Taisuke ^Diskussion 17:14, 31. Jul. 2020 (CEST)

Etwas, dass bei der Abstimmung entweder vielen nicht bewusst, oder möglicherweise auch egal war, ist mir leider erst jetzt im Nachhinein eingefallen: Und zwar sollen die Herrscher-Pokémon nicht in Vorlagen aufgenommen werden. Das bringt allerdings ein Problem mit sich: Wir haben nen ganzen Haufen Sprites der Herrscher-Pokémon, die ich jetzt zunächst ausgebunden bzw. gar nicht erst eingebunden habe. Das bringt nicht nur zusätzliche unbenutzte Dateien mit sich, sondern unterschlägt in gewissem Sinne auch Informationen, weil wir so tun, als hätten sie keine eigenen Sprites, was allerdings nicht korrekt ist. Jetzt also die Frage, vor der ich gerade stehe: Bleiben die Dateien uneingebunden, weil der Wunsch dieser Abstimmung darin besteht, dass sie nicht in Vorlagen beachtet werden, oder soll ich sie einfügen und damit gegen diese Abstimmung handeln, dafür aber die Dateien korrekt anzeigen? -- RobbiRobb 21:17, 11. Aug. 2020 (CEST)

Imo. sollten die eingebunden werden, aber nicht im normalen Schema, sondern iwie als "Herrscher-Rattikarl Sprite". Oder wie irgendwann von mir vorgeschlagen "023aherrscher" --Datei:Sugimori 672.pngMecanno-man^Mäh 00:17, 15. Aug. 2020 (CEST)

Ja, da liegen die bereits, siehe Datei:Pokémonsprite 020a Herrscher Bank.png. Der Punkt, den ich versuche zu machen, ist, dass die Abstimmung zum Ergebnis hatte, dass wir die Herrscher nicht in Vorlagen mit aufnehmen - mit dem Ergebnis, dass eben nicht nur Namenr, Nrname oder Id2Typ betroffen sind, sondern soweit ich das sehe auch sowas wie Sprites. Und dadurch sind die Dateien unbenutzt und werden überall als nicht-existent behandelt, was ich nicht für sinnvoll halte. Mein Ziel ist es im Grunde also, dass hier gegen das Ergebnis der Abstimmung gehandelt wird, was zwar nach unseren Regeln soweit ich das sehe nicht zwangsläufig verboten ist, definitiv aber nicht im Sinne einer Abstimmung ist, dass das Ergebnis hinterher ignoriert wird und trotzdem das Gegenteil passiert. Die Frage an dieser Stelle ist, warum sich die Benutzer, die gegen die Herrscher gestimmt haben, so entschieden haben, und ob sie sich des Problems, vor dem ich jetzt als mehr oder weniger Zuständiger für die Vorlage:Sprites stehe, bewusst waren, oder ob sie das ganze überhaupt nicht bedacht haben. -- RobbiRobb 01:47, 15. Aug. 2020 (CEST)

Die Herrschersprites sollen meiner Meinung nach, auch wenn das gegen das Ergebnis der Abstimmung geht, auf jeden Fall in die Spritevorlage aufgenommen werden. Ich glaube, dass das eher mit einem Sonderschema geregelt werden sollte, wie es oben auch schon geschrieben ist, als mit dem Standardschema. GrollenKette951 23:57, 15. Aug. 2020 (CEST)

An sich bin ich dafür, dass die Sprites eingebunden werden (so hab ich, glaube ich, auch abgestimmt), aber das hier war immer noch eine Abstimmung, deren Ergebnis mMn keines Falls ohne weiteres zum Teil ignoriert/angepasst/... werden sollte. Wenn dann sollte man mMn eine breite Zustimmung aller Stimmberechtigten haben, bevor da irgendwas gemacht wird. --DeXter 00:32, 16. Aug. 2020 (CEST)

So wie ich das sehe, sollte es ausreichen, wenn sich dazu die an der Abstimmung teilnehmenden Benutzern nochmals äußern, die gegen eine Aufnahme von Option (M) gestimmt haben. Sollte sich daraus dann im Nachhinein eine Mehrheit ergeben, sehe ich kein Problem darin, in diesem Fall entgegen dem ursprünglichen Abstimmungsergebnisses zu handeln. Schließlich muss ich gestehen, dass die Option nicht optimal von mir festgelegt wurde, da es mehrere verschiedene Elemente in einen Top wirft. Zumal die Option darüber hinaus auch noch Spin-off-Elemente (Crypto) mit Hauptspiel-Elementen (Herrscher) vermengt. Als einer derjenigen, die sich eigentlich gegen diese Parameter ausgesprochen hat, würde ich mich im Nachhinein bzgl. der Herrscher-Pokémon umentscheiden und diese nun doch befürworten. Weitere Argumente dafür lieferte übrigens Lasagne schon weiter oben in den Kommentaren des Spoilers. ~ Taisuke ^Diskussion 10:11, 16. Aug. 2020 (CEST)

Schwierig. Die Herrscher unterscheiden sich lediglich Storybasiert durch eine Aura und ansonsten nur in Größe/Gewicht. Das dieser Unterschied bei Sprites auffällt glaube ich nur bedingt. Ich kann mich hier nicht zu einem Pro durchringen. Daher enthalte ich mich in diesem Fall und überlasse es der Mehrheit, da ich auch mit einer Einbindung leben könnte. Ggf. sollte man nochmal einen Ping an die die abgestimmt haben absetzen. Gruß * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 12:36, 16. Aug. 2020 (CEST)

Behandelt die Abstimmung überhaupt die Vorlage:Sprites? So wie ich das verstehe ging es doch nur um die IDs, also namenr, nrname, id2typ etc. --Datei:Sugimori 672.pngMecanno-man^Mäh 12:41, 16. Aug. 2020 (CEST)

Typen-Icons

Damit es hier gar nicht erst langweilig wird, starte ich schon mal die nächste Abstimmung, noch bevor die letzte beendet wurde. Und zwar geht es darum, wie beim Chattreffen beschlossen, in einer finalen Abstimmung zu entscheiden, welche Typen-Icons wir in der Zukunft im Wiki verwenden wollen. Dazu habe ich entsprechend eine Demo-Version erstellt, die die jeweiligen Typen-Icons gegenüberstellt. Dabei habe ich die Gen8-Icons auf etwa-Textgröße verkleinert, damit sie nicht unnatürlich wirken - zumal sie auch in dieser Größe etwa eingebunden würden, weil die Icons ja auch teils () noch in Fließtexten verwendet werden. Und auch in Tabellen haben wir nix davon, wenn die jetzt plötzlich riesig groß sind. Aber jetzt seid ihr gefragt: Welche der Version sagt euch am meisten zu? Was möchtet ihr in Zukunft im PokéWiki sehen, vor dem Hintergrund, dass zukünftige Spiele vermutlich wieder neue Icons einfügen werden.

Abstimmung

Abstimmung beendet, vier Stimmen für official, elf Stimmen für gen7, sechs Stimmen für gen8.

Offizielle Icons von pokemon.com (official)

1. Die Einzige Lösung, die sowohl aktuell als auch farblich nicht überall fast gleich ist. Ausserdem eine, womit man nicht zwingend alle zwei Jahre alle Icons ersetzen geht... --Datei:Sugimori 672.pngMecanno-man^Mäh 02:25, 27. Jul. 2020 (CEST)
2. Sonst haben wir diese Diskussion jede Gen aufs Neue. - -wowoJonny 05:33, 27. Jul. 2020 (CEST)
3. Meiner Meinung nach die einzig sinnvolle Option. Wenn wir die Icons der 7. Gen weiterhin verwenden, würden sich "gewöhnliche Leser" des Wikis spätestens bei der Veröffentlichung der 9. Gen fragen, warum wir die "veralteten" Icons einer scheinbar willkürlichen ausgewählten Generation verwenden. Wenn wir immer die neuesten Icons nehmen, haben wir (neben der problematischen farblichen Gestaltung der 8. Gen) das Problem, dass diese u. U. ein anderes Seitenverhältnis haben, sodass Vorlagen, die die Icons verwenden, umgestaltet werden müssen, oder andere Farben verwendet werden, sodass Typ/Color angepasst werden muss. Mit den pokemon.com-Icons haben wir Icons, die von offizieller Seite verwendet werden, nicht veraltet sind und keine Umgestaltung von Vorlagen alle paar Jahre erfordert. --Vircaprae 14:47, 27. Jul. 2020 (CEST)
4. Falls wir uns jetzt für diese Option entscheiden, heißt das ja noch nicht, dass diese Änderung für alle Zeiten bestehen bleibt. Vielleicht kommen ja mit einer neuen Generation auch wieder optisch ansprechendere und fürs Wiki passendere Icons, die dann verwendet werden können. Bis dahin finde ich dass die offiziellen Icons verwendet werden sollten, um auf aktuellem Stand zu bleiben. Beim ersten Blick auf die Tabelle war es zwar eine ziemliche Umgewöhnung, aber mittlerweile habe ich mich schon mit ihnen angefreundet. -- Cliffichen 18:40, 27. Jul. 2020 (CEST)

Icons aus den Spielen der 7. Generation (gen7)

1. Die Entscheidung ist hier nicht einfach, bei den Icons von pokemon.com werden oftmals andere Farben verwendet. Dies schließt somit eine Anpassung der Typ/Color mit ein und sollte auch aus der Abstimmung hervor gehen. Auch finde ich die Darstellung vom Flug- und Drachentypen ziemlich Fehlerhaft (ja sie ist so, dennoch bleibts bei dem empfinden) wie diese beiden dann bei Typ/Color aussehen ist fraglich. Auch ein Wechsel auf Gen8 fände ich nicht den richtigen Weg. Es würde vielerorts Darstellungsprobleme geben. Beim Wechsel auf Gen8 werden wir diese Diskussion höchst wahrscheinlich bei Gen9 wieder führen. In der Abstimmung fehlt mir eine 4. Option (Erstellung von eigenen dauerhaften Icons), @Robbi ich weiß das du da die Aufgabe hattest die 3 Versionen gegenüberzustellen und Buos Entwurf beim Chattreffen verworfen wurde. Wäre es nicht dennoch sinnvoll noch eine 4. Option hinzuzufügen auch wenn es dafür noch keinen Entwurf gibt? Oder wenigstens eine Enthaltung? Solange die Optionen nicht vorhanden sind bleibe ich lieber beim Status Quo. Sowohl pokemon.com als auch Gen8 sind für mich keine ansehnlichen Optionen. Gruß * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 06:22, 27. Jul. 2020 (CEST)
2. An den Icons von pokemon.com stören mich vor allem die doppelten Farben und auch generell die Farbauswahl. Feuer und Kampf sehen sehr ähnlich aus und Normal und Stahl kann man von den Farben her auch nur schwer unterscheiden. Die Icons aus Gen8 finde ich da schon besser, aber ich denke, dass diese vor allem in Fließtexten den Lesefluss aufgrund der dunklen Farben stören werden. Wie Ryu schon erwähnt hat, käme mit Gen9 die Diskussion wieder auf und dann stehen wir wieder vor dem selben Problem. Deshalb bin ich dafür bei den aktuellen Icons zu bleiben, bis es eine bessere Alternative gibt. -- Mooni000 ^Diskussion 11:53, 27. Jul. 2020 (CEST)
3. Ich bin eindeutig für die Icons der 7. Generation. Bei denen von der offiziellen Website stören mich die Farben von Flug und Drache, da diese zweifarbig sind. Die Icons von Generation 8 hingegen sind ziemlich dunkel und die Farbe des Typs ist nur am linken Rand gut erkennbar, da sie in der Mitte ziemlich wirklich sehr dunkel ist. Die Symbole am Rand gefallen mir dort zwar ziemlich gut, aber machen die Icons nur noch länger, was im Fließtext nicht gerade positiv ist. Generation 7 ist also für mich sowohl optisch am ansprechendsten als auch nicht so störend in Texten. ~~ Haijo18 +++ (Diskussion) 14:47, 27. Jul. 2020 (CEST)
4. Auch wenn es ein wenig willkürlich ist, ausgerechnet die Icons der siebten Generation zu verwenden und damit veraltet wirkt, so ist dies in meinen Augen von den wählbaren Möglichkeiten die beste. Immer die aktuellen Icons zu nutzen würde bei jeder kommenden Generation erneut das Problem aufwerfen, Darstellungen in Vorlagen an die neue Breite/Höhe der Icons anzupassen, denn ich denke nicht, dass diese ab jetzt so bleiben wird. Bei den Icons von pokemon.com stört es mich hingegen stark, dass Flug, Boden und Drache – wie, soweit es mir bekannt ist, sonst nur im Pokédex der vierten Generation – zweifarbig sind. Ich wäre für die Erstellung eigener Icons in etwa im Stil der Icons von pokemon.com, doch mit einer eindeutig zugewiesenen Farbe für jeden Typen. Ich kann allerdings die Ansicht nachvollziehen, dass diese als Fanarts im Wiki nicht erwünscht sind. ~ ~ Simonsees ~ 16:22, 27. Jul. 2020 (CEST)
5. Bevor ich jetzt unnötigerweise das Gleiche schreibe schließe ich mich dem an was Simon geschrieben hat. Datei:Pokémonsprite 248 StSd.gif BeyJim ^Diskussion 15:46, 28. Jul. 2020 (CEST)
6. Normalerweise würde meine Stimme bei den aktuellsten Icons (also der 8. Generation) landen, aber ich befürchte, dass es dort zu keiner Mehrheit kommen wird. Da mir die Icons von pokemon.com absolut nicht zusagen, stimme ich somit für die Icons aus Gen. 7. Denn alles ist besser als dieser Graus der offiziellen Seite. Ich rechne fest damit, dass wir bei einer Umstellung mit eindeutig mehr Nachfragen von Seitenbesuchern zu rechnen haben als wir es momentan aufgrund fehlender Aktualität haben. Denn der normale Seitenbesucher kennt diese Windows-98-Icons der Typen nicht, wodurch es für ihn nicht nachvollziehbar sein wird, warum wir diesen Rückschritt gehen.
   Ein weiterer Grund für die negative Einstellung gegenüber den aktuellen Icons – neben dem einheitlich dunkleren Ton – ist vermutlich die Darstellung im Vergleichsbild. Es ist das einzige, das eckig dargestellt wird, obwohl es ein leichtes wäre, dies auch rund anzuzeigen. Ein Vergleich zwischen Datei:FeuerIC.png und sollte denke ich schon mehr von den aktuellen Icons überzeugen können als bisher. Dabei habe ich nur eine andere Höhe des Bildes gewählt und die Ecken abrunden lassen. Und weil es hier bereits erwähnt wurde: Wir könnten die Icons auch um eine zweite Variante (Datei:Typ-Icon Feuer StSd.png z. B. mit {{#icon:Feuer2}} oder {{#icon2:Feuer}}) ergänzen, sodass situativ die passendere Variante genutzt werden kann. Damit würde man die bereits angesprochenen Platzprobleme in mancher Vorlage auch umgehen können. Muss ja nicht zwingend überall dasselbe Icon zu finden sein. Nur mal so als Denkanstoß. Schließlich haben wir mehrere aktuelle Varianten zur Verfügung, die in den Spielen ja auch beide genutzt werden. :) ~ Taisuke ^Diskussion 17:49, 29. Jul. 2020 (CEST)
7. Ich sehe diese Sache exakt wie Tai. Alles was ich noch dazu sagen könnte, wär quasi redundant. -MfG, Kenaz-Hagalaz ^Disku 18:12, 29. Jul. 2020 (CEST)
8. Ich bin auch dafür, erstmal weiterhin die Icons aus der siebten Generation zu verwenden, da sie von den drei Optionen meiner Meinung nach klar die für das PokéWiki am besten geeigneten sind. --Lasagne (Diskussion) 15:02, 31. Jul. 2020 (CEST)
9. Siehe vorherige Argumente --DeXter 11:27, 1. Aug. 2020 (CEST)
10. Zeynex (Diskussion) 22:40, 8. Aug. 2020 (CEST)
11. siehe alles davor. - - "I'm gonna swing from the chandelier" GoPika ^Disku 12:25, 10. Aug. 2020 (CEST)

Icons aus den Spielen der 8. Generation (gen8)

1. Finde die Icons der Website wirklich nicht schön. Die Schriftart ist absolut langweilig, die verschiedenen Schriftfarben stören und die doppelten Farben sind auch nicht toll. Bin auch kein Freund davon, veraltete Icons zu verwenden und mag die Gen8-Icons wirklich gerne.--✦✧✦ Pk-fan 22:35, 27. Jul. 2020 (CEST)
2. Also die Aktuellen Icons aus dem Schwert und Schild wäre sehr gut ausgesehen. Mit Symbolen und Schrift sind besser lesbar, wegen Kontrast. Deshalb entscheide ich ein Icon aus dem 8.Generation. -- AAWiki ^Diskussion 22:41, 29. Jul. 2020 (CEST)
3. Bin zwar mehr für die Icons aus der achten Generation, aber mit denen aus der siebten Generation kann ich auch leben. Bezieungsweise hab ich mich schon daran gewöhnt. --mfG Lombrero ^Dis 16:54, 30. Jul. 2020 (CEST)
4. --Schöne Träume! Killuu 09:37, 31. Jul. 2020 (CET)
5. Sehe das so wie Taisuke etc., aber stimme dann auch tatsächlich dafür. Ich finde die auch schön designed, da ist direkt klar worum es geht, sogar wenn man ein optischer Typ ist. Was bei neuen Icons wäre, kann man ja dann entscheiden. Nescientist (Diskussion) 12:23, 1. Aug. 2020 (CEST)
6. Habe mich nach längerem Überlegen noch einmal umentschieden, da es bei diesen wirklich sofort klar ist, um was es geht und die aus Gen 7 veraltet sind. Die offiziellen Icons finde ich gar nicht schön. BlauesSerpiroyal ^Diskussion 14:41, 8. Aug. 2020 (CEST)

Kommentare

Ping an alle SBs und ESBs: @Buoysel, Cliffichen, CLina, DeXter, GoPika, GrollenKette951, Impoleon xy, Isso08-15, Kenaz-Hagalaz, Lombrero, Luca12379, Matze, Mecanno-man, RobbiRobb, Ryuichi, ShortyBuzz, Simonsees, SwowoJonny, Taisuke, AAWiki, BeyJim, BlauesSerpiroyal, Der Sternendiamantritter, Haijo18, Jass, Killuu, K0pplosio, Lasagne, Mario-WL, Mooni000, Nescientist, Pintauranimus, Pk-fan, PokéSpe, PokemontutorialTV, Vircaprae, Xatuhatu, Zeynex: -- RobbiRobb 02:21, 27. Jul. 2020 (CEST)

Ich glaube, du hast in der Demo-Tabelle versehentlich die Icons aus Gen. 6 statt der aus Gen. 7 verwendet, @RobbiRobb. --Lasagne (Diskussion) 09:12, 27. Jul. 2020 (CEST)

@Lasagne: Jo, das scheinen die falschen zu sein, der Unterschied ist aber minimal und nach der Abstimmung werden wir dann die richtigen nutzen. Hab das ganze im Testwiki erstellen müssen, damit ich nicht mit Vorlagen und großen Mengen css das Live-Wiki beeinflusse, nur um mal eben ne Demo zu erstellen, und dort standen mir die aus Gen7 nicht zur Verfügung; wobei ich es auch tatsächlich selber nicht bemerkt hatte. Ich bitte daher alle, einfach über diesen kleinen Fehler meinerseits hinwegzusehen und sich dort die korrekten Icons zu denken, der Unterschied ist dabei ja so gering, dass es vor dem Hintergrund der anderen Möglichkeiten keinen großen Einfluss auf die Abstimmung haben sollte.

@Ryuichi: Keine Ahnung, woher jetzt das mit der vierten Option kommt, ich habe einfach nur das gemacht, was im Protokoll stand, hatte die Diskussion selbst auch gar nicht wirklich mitverfolgt und um ehrlich zu sein gehöre ich zu denen, die die Thematik am wenigsten interessiert Ne Enthaltungs-Option kann natürlich gerne noch eingebaut werden, da spricht nix gegen, weil sie keinen Einfluss auf die eigentliche Abstimmung gilt, alle dort hinterlegten Stimmen verfallen einfach und haben damit den selben Stellenwert wie das einfache Auslassen der Abstimmung. Bei einer zusätzlichen Option für was eigenes bin ich aber ganz klar dagegen, nicht nur weil die Abstimmung bereits läuft, sondern auch, weil wir uns bereits gegen die veränderten Versionen der aktuellsten Icons ausgesprochen hatten und auch sonst im Wiki alles, was nichts offizielles ist, löschen, sehe da also absolut keinen Grund, jetzt wieder was eigenes anzufangen.

Noch eine Bemerkung bzw. Frage meinerseits in die Runde. Ich hatte es so in Erinnerung, dass bei einer Entscheidung für die Gen8-Icons dann auch in Zukunft stets die aktuellsten verwendet werden und nicht jedes mal aufs neue ne Abstimmung durchgeführt wird, ob wir die aktuellsten nutzen wollen oder nicht. Hab ich das richtig in Erinnerung oder hatten andere das so verstanden, dass wir dann dauernd aufs neue abstimmen? -- RobbiRobb 16:54, 27. Jul. 2020 (CEST)

Kleine Anmerkung zu dem Thema mit der vierten Option: Bin auch strikt dagegen eigene Icons zu erstellen. Die angepassten Gen8-Icons von Buo, wurden ja bereits abgelehnt, weil nicht offiziell. Also warum jetzt plötzlich den Kurs wechseln?

Noch eine Frage zu Tais Vergleich von Gen7- und Gen8-Icons mit abgerundeten Ecken: Das Abrunden der Gen8-Icons wäre doch auch vom Offiziellen weg, oder? Ich kann mich nicht daran erinnern die Icons im Spiel rund gesehen zu haben. --DeXter 11:27, 1. Aug. 2020 (CEST)

Mit elf Stimmen sind die meisten Stimmen für die Icons der siebten Generation, womit diese bis auf weiteres die im Wiki verwendeten bleiben. Da weder aus dem Chattreffen noch aus den Kommentaren zu dieser Abstimmung ersichtlich ist, wie lange diese Entscheidung bestand hat, beschließe ich an dieser Stelle einfach, dass bis zur Veröffentlichung neuer Icons, sei es in Spielen oder eventuell auch auf der offiziellen Seite, die Icons aus der siebten Generation im Wiki verwendet werden.
-- RobbiRobb 20:02, 11. Aug. 2020 (CEST)

Scheint mir am sinnvollsten. --Datei:Sugimori 672.pngMecanno-man^Mäh 23:51, 14. Aug. 2020 (CEST)

Umgestaltung der Rechtesruktur

Einigen von euch wird vielleicht auffallen, dass es in letzter Zeit etwas wenige VBs und Redakteure gab. Zumindest teilweise liegt dies daran, das ich Mühe mit der aktuellen Rechtestruktur habe, denn sie knüppelt Rechte und Ansehen an ein und dieselbe Struktur. Das ist meiner Meinung nach ein Problem, denn so werden Rechte nicht sinnvoll verteilt. Sieht man sich die Rechtestruktur an, haben wir zwei Ränge, die nahezu über dieselben Rechte verfügen: Redakteur und VB - was unterscheidet diese Ränge? Löschrechte, sowie das Redakteure durch die Community bestätigt sind*. Tatsächliche Macht haben Redakteur kaum noch; sie dienen lediglich als Entscheider sollten sich die Admins uneinig sein und nicht zu einem Kompromiss kommen, was sehr selten vorkommt. Ich sehe deshalb geraden den Sinn nicht, für Löschrechte eine Wahl durchzuführen, wenn bei allen anderen Rechten nur die Admins entscheiden, wer sie kriegt. Insgesamt scheint mir die Rechtestufe der Redakteure in ihrer heutigen Form relativ unnötig.

Deshalb mein Vorschlag: Ein Ersetzen der Redakteursstufe mit einer für Projektleiter (mit denselben Rechten). Denn wer braucht das Löschrecht? Leute, die in einem Inhaltsbereich Verantwortung tragen - das sind die Projektleiter. Zeitgleich finde ich aber, das die Wahl gutes Feedback zur Mitarbeit im Wiki liefern kann - zumindest wenn die User nicht sowieso schon ausgezeichnete Mitarbeit liefern, was jedoch die meisten VBs, die zum Red vorgeschlagen werden, tun. Deshalb schlage ich vor, den VB in Zukunft über eine Wahl zu vergeben; als Wahlverfahren scheint mir dasselbe wie das aktuelle der Redakteurswahl zufriedenstellend. Ich denke auch, das dies hilfreich dabei wäre, neue VBs zu gewinnen, da nicht nur die Admins so ein Auge auf alle potenziellen VBs richten, sondern insbesondere auch Projektleiter, in denen die potenziellen VBs aktiv sind. Zwei Änderungen am System, die ich dabei vorschlage: 1. die potenziellen VBs zu fragen ob sie wollen bevor die Wahl eröffnet wird; zumindest aus den aktuellen Redakuteruswahlregeln geht hervor, das dies erst geschieht, wenn die Admins pro stimmen... 2. Sollen stimmberechtigte Veteranen ebenfalls ihre eigene Wahl auslösen können, anstelle von direkt den VB von Admins zurückzukriegen - dies insbesondere, weil sich die Community ändern kann während Veteranen inaktiv sind, sollte aber solche Fälle wie Max neulich verhindern. Insgesamt hat diese Vorschlag meiner Meinung nach auch den Vorteil, das die Community viel mehr involviert darin ist, wer sich in den internen Kreisen der Community bewegen kann, anstelle das dies allein von den Admins entschieden wird.

Dennoch hat dieser Vorschlag einige Knackpunkte: Erstens ist die Frage, wie gut ESBs anderen Patrolrechte zutrauen können. Patrol und Autopatrol sind meistens die zentralen Rechte in Diskussionen um neue VBs und häufig das totschlagargument bei einigen Vorschlägen. Ich hätte an dieser Stelle kein Problem damit, wenn man die patrol-Rechte auf Projektleiterstufe setzt, wieder mit demselben Argument das diese am ehsten für den Inhaltsbereich „zuständig“ sind und deshalb die Rechte am ehsten brauchen, und ich oftmals schon gehört hab, das sich ein Projektleiter darüber beschwert hat, das Sachen in ihrem Projekt gegen ihren Willen patrolt wurde. Zeitgleich könnte es aber auch mühsam sein, wenn ein VB viel macht, was dann patrolt werden muss. Ausserdem ist patrol/autopatrol aktuell so ziemlich das einzige, was VBs Rechtemässig von SBs unterscheidet. Die Ernennung zum VB hat allerdings innerhalb der Wiki-Community meiner Meinung nach mehr Gewicht, weshalb ich hier mit einer Wahl zu einem Kaum-Recht mit Bedeutung besser leben könnte, als mit einer Scheinwahl zu einem Kaum-Recht ohne Bedeutung. Ich selbst tendiere dazu, den neuen VBs die patrolrechte zu geben, hauptsächlich weil man ansonsten potentiell auf ewig ohne autopatrol dasteht.

Genau das ist Teil des zweiten Punktes, dessen tatsächlichem Umfang ich mir nicht bewusst bin: Potentielle fehlende Aussichten für VBs. Die einzigen Stufen über den VBs wären dann Projektleiter und Admin, beides Stufen die nach Bedarf und nicht nach Verdienst vergeben werden. Es gibt also keine Stufe mehr, die erarbeitet werden kann. Dieser Einwand kam von Tai, und ich kontere an dieser Stelle mit dem WB, dem ÄWB und Projekthelden - denn wenn man mal den VB hat ist alles was man eigentlich noch erarbeiten kann Ansehen, und diese Auszeichnungen sind genau das. Dennoch kann ich mich nicht in die Schuhe eines VBs versetzen und muss hier demnach nachfragen, wie ihr aktuellen VBs das seht.

Ach und noch was: Falls euch etwas am Wort "Redakteur" liegt hab ich nichts dagegen das was ich als zukünftigen VB beschrieben habe als Redakteur zu bezeichnen. Wie das heisst is mir eigentlich egal.

Generell die Frage: Wie steht ihr zu diesem Vorschlag? --Datei:Sugimori 672.pngMecanno-man^Mäh 20:00, 24. Aug. 2020 (CEST)

Eine kurze Reaktion direkt nach dem zweiten Lesen (keine Sorge ein fetter Brummer bzw. ausführlicher Diskussionsbeitrag wird von mir auch noch kommen). Das Ansehen des Redakteursrang fühlt sich mMn ganz anders an als das von Auszeichnungen, wie WB, ÄWB und Projekthelden (auch noch eine Anmerkung zu Projekthelden: Alleinige PLs, von denen es inzwischen sehr viele gibt, haben nach derzeitiger Praxis mMn kaum Aussicht auf so eine Auszeichnung bevor sie aus dem Projekt austreten). Also hab ich grade Schwierigkeiten das als "guten" Konter zu sehen. Ist aber natürlich alles rein subjektive "Gefühlssache", wobei man da glaube ich schwierig oder gar nicht objektiv urteilen kann. Ich für meinen Teil habe aber sehr gerne ein Ziel vor Augen, auf das ich zuarbeiten kann und da würde ein zentrales mMn verloren gehen.

Patrol und autopatrol bitte nicht nur für PLs und Admins. Denn z. B. im Attacken-Projekt ist der Kontrollier-Aufwand immer mal wieder enorm und da will ich so wenig wie möglich kontrollieren "müssen" und so viele potenzielle Kontrollier-Helfer haben wie es geht.

So viel zur ersten Reaktion, die ich gleich mal äußern wollte. Ein ausführlicher Beitrag wird noch kommen, aber dafür brauche ich Zeit.--DeXter 20:41, 24. Aug. 2020 (CEST)

So, jetzt mein ausführlicher Diskussionsbeitrag. Es wird sicherlich zu ein zwei Dopplungen mit meiner ersten Reaktion kommen und ich wollte wegen der Textmenge gleich für die dritte Nachricht die volle Breite haben. Das ist hoffentlich verschmerzbar.

Nun erstmal zu Mecs Einleitung. Ich verstehe nicht was der allgemein präsente Usermangel mit unserer Rechtestruktur und einem Admin, der mit ihr Mühe hat, zu tun haben soll. Ich habe das Hauptproblem immer so wahrgenommen, dass zu wenig SBs nachkamen, die sich für den VB eignen könnten (was glücklicherweise inzwischen nicht mehr der Fall ist, da wir wieder einige vielversprechende SBs haben). Rechte und Ansehen sind zwei Dinge, die man sich bei uns erarbeitet. Also warum sollten sie nicht aneinander gekoppelt sein? In der aktuellen Situation brauchen PLs mMn das Löschrecht nicht übermäßig viel öfter als andere User. Die Ausnahme ist da Peter, da beim TCG-Projekt immer wieder Sachen gelöscht werden müssen. Allerdings hat das bisher meines Wissens nach immer geklappt und wegen einem User verändert man nicht eine Rechtestruktur. In Bezug auf das Thema Löschrechte ist die derzeitige Situation mMn völlig zufriedenstellend.

Unabhängig von dieser Kritik finde ich das Konzept von VB-Wahlen sehr interessant und vielversprechend. Das bringt mehr Transparenz und mehr Mitentscheidung der ESB-nicht-Admins. Dass die Abstimmung öffentlich ist und man schon in der Abstimmung den Kandidaten fragt, hat bei einem Wahl-Verlust Demotivierungsgefahr, was man aber denke ich in Kauf nehmen muss. Nach einer missglückten Wahl hätte der Kandidat ja außerdem die Möglichkeit das erhaltene Feedback umzusetzen und wieder vorgeschlagen zu werden oder dies selbst zu tun.

Soviel zu der Idee der VB-Wahlen, jetzt zu dem Vorschlag den Redakteursrang abzuschaffen. Der Red-Rang ist mMn u. a. ein "zentrales Ziel", auf das man hinarbeiten kann und das man unabhängig der aktuellen Team-Lage, mit Eigenleistung erreichen kann. Außerdem ist er der zweithöchste Rang (Bürokrat ausgenommen), womit unser Motto (mMn haben wir das) "Leistung resultiert in Aufstieg usw." erhalten bleibt. Würde dieser Rang verloren gehen, wäre das mMn nach für die VBs demotivierend, die weiter aufsteigen möchten (ganz besonders für die, für die sich kein PL-Posten anbietet). Mec stellt dem die Auszeichnungen WB, ÄWB und Projekthelden entgegen, da man seiner Meinung nach dem VB sich nur noch Ansehen erarbeiten kann. Allerdings kann man diese Dinge mMn mit dem Redakteursrang nicht vergleichen. Der Rang bedeutet Rechte, Ansehen, "Macht" (hört sich komisch an, triffts aber) usw. und die Auszeichnungen sind Anerkennung und Ansehen und hübsche Boxen, die die BS schmücken. Die Anerkennung und das Ansehen fühlen sich mMn, wie bereits gesagt, dabei anders an. Also sollten der Rang und die Auszeichnungen sich mMn gegenseitig ergänzen, anstatt sich gegenseitig zu ersetzen.

Zusammenfassend möchte ich vorschlagen, dass Mecs Vorschlag dahingehend angepasst wird, dass das Konzept der VB-Wahlen an sich umgesetzt wird, der Redakteursrang aber bleibt. Mit diesen beiden Sachen hätten die ESBs außerdem großen Einfluss auf Rangänderungen rund um VB und Red und dann kann da, denke ich, mit der richtigen, aufmerksamen Team-Mentalität nichts mehr an einem Admin, der "Mühen" hat, hängen. --DeXter 11:19, 25. Aug. 2020 (CEST)

Für mich ist es schwierig, zur aktuellen Diskussion etwas beizutragen, weil ich ja in Teilen auch Bestandteil, quasi "betroffen" davon bin. Ich will aber dennoch meinen Eindruck schildern, einfach um das Thema voranzutreiben. Ich habe zusammenfassend das Gefühl, dass das Hauptproblem, das für den Usermangel verantwortlich ist, eine Struktur ist, die nicht auf Wertschätzung, sondern auf Kontrolle basiert, wie wir es ja auch im Discord diskutiert haben. Zwar ist ein Symptom davon, dass das Rechtesystem einige Unschärfen aufweist, aber dass nun ausschließlich Maßnahmen angestoßen werden, die auf das Rechtesystem abzielen, geht in meiner Wahrnehmung völlig am eigentlichen Ziel vorbei, eine engere und konstruktivere Zusammenarbeit zu fördern und Leute zum Mitmachen zu bewegen. Man geht quasi davon aus, dass desto mehr User mitmachen, je präziser Erläuterungen und Regelwerke ausgestaltet sind. Das ist NICHT der Fall, denn Wikiarbeit ist zeitintensiv und mühsam, und es muss folglich andere Aspekte in der Community geben, die einem als User etwas "zurückgeben", vor allem nach der Anfangszeit (da wird man meistens noch von dem Motiv getragen, "dem Wiki etwas zurückgeben zu wollen").

Zur Frage, ob eine Zusammenlegung von Rängen sinnvoll ist: Ich glaube, den meisten Usern sind die Unterschiede in den Rechten relativ gleichgültig, mir zumindest geht es so. Der Unterschied im "Prestige" von VB zu Redakteuren jedoch ist immens, z. B. war ich in meinem eigenen Fall von VB fest ausgegangen, wodurch die Kontroverse entstand, während ich an ein Wiedererlangen des Redakteurstatus nicht einmal gedacht habe. Eher sollte man die Projektleiter zu einem eigenen Rang machen, der vielleicht zwischen Redakteuren und VBs angesiedelt werden könnte. VBs und Projektleiter erscheinen mir eher projektbezogen unterstützend, während Redakteure wikiübergreifend unterstützend tätig sind. Das ist quasi die größte Auszeichnung, die es im Rangsystem derzeit gibt, wenn man davon ausgeht, dass der Adminstatus einen Sonderfall darstellt. Daher bin ich auch unsicher, ob eine gesamtwikiweite Abstimmung über VBs, die häufig in einem bestimmten Feld tätig sind, sinnvoll ist, also ob alle das gut einschätzen können. So etwas wiederum, also die Erwartungshaltung an den Umfang der Mitarbeit über verschiedene Hierarchieebenen hinweg, könnte man etwas ausdefinieren, damit man als User weiß, was man tun muss, um aufzusteigen.

Die Ursache für die schwindende Anzahl an Usern in höheren Hierarchiestufen ist, dass die Erwartungen übertrieben hoch geworden sind, weil Admins und Redakteure ihren eigenen Maßstab an neue User anlegen. Es erklärt sich von selbst, dass man an die jahr(zehnt)elange Wikierfahrung als neuer User niemals herankommen kann. Deswegen müsste man z. B. präzise definieren, was ein VB oder ein Redakteur z. B. NICHT leisten müssen. Wenn an einen VB dieselben Maßstäbe wie an einen langjährigen Redakteur angelegt werden, ist es in sich logisch, dass das niemand erreichen kann. Hinterfragt also eure eigenen Maßstäbe. Wenn man das Haar in der Suppe sucht anstatt zu denken "nicht perfekt, aber sicher eine Bereicherung!", dann ist man schon den ersten Schritt dahin gegangen, Leute zu vergraulen.

Hinzu kommt: Je bürokratischer und strikter Richtlinien durchgepeitscht werden, desto schwieriger ist es für einen User, mit Spaß an der Sache dabei zu bleiben, weil es dann in Zwänge ausartet, was bei einem Hobby wie bei der Wikiarbeit nicht das Ziel sein kann. Ich beobachte, dass quasi alle sehr aktiven Wiki-Autoren sich dadurch auszeichnen, dass sie IT-interessiert sind. Das hilft offensichtlich dabei, mit Spaß an der Sache zu sein, womit ich wieder beim ersten Punkt bin. IT-Interesse ist offensichtlich eine (vielleicht gerade eine der wenigen) Wege, die Mühen der Wikiarbeit auszugleichen. Es muss aber dringend auch Strukturen geben, die es anderen Leuten mit anderen Interessen schmackhaft machen, mitzuhelfen. Das Thema wird völlig verfehlt, wenn im "stillen Kämmerlein" der IT-Interessierten Entscheidungen getroffen werden, die dann nach Kritik nicht zurückgerollt, sondern sogar im Regelwerk verankert werden, denn dadurch wird das Regelwerk natürlich immer unattraktiver für Leute mit anderen Interessen. Es geht also darum, statt mit Übervorsicht davor, dass User mangelhafte Bearbeitungen tätigen, eher mit wohlwollender Unterstützung dabei zu sein und eher mal eine Chance zu viel als eine zu wenig zu vergeben. Wieder: Maßstäbe hinterfragen. Ausnahmen, die gut begründet sind, gefährden zudem keine Regeln. Der gesunde Menschenverstand und ein bisschen Empathie helfen viel mehr weiter als Wortklaubereien in Regeln. Ich könnte noch einen ganzen Aufsatz zu dem Thema schreiben, belasse es jetzt aber erstmal mit diesen Gedanken. Zusammengefasst: An den Regelwerken werdet ihr bis zum Ende der Zeit drehen können. Wenn die Ansprüche und Wertschätzungsfragen nicht beantwortet werden, wird das doch keinen wirklichen Einfluss haben. Liebe Grüße! Maxmiran 15:17, 25. Aug. 2020 (CEST)

Kurzer Einschwung: Es ist mir klar, das dieser Vorschlag nichts am allgemeinen Usermangel ändern wird; es geht mir eher darum, Änderungen am Rechtesystem vorzunehmen, die Wertschätzung und Rechte auf höherer Ebene trennen, sowie Rechte und Macht besser aneinander angleicht (Projektleiter haben imo. mehr zu sagen als Redakteure). Auch scheint mir die Redakteurswahl in ihrer heutigen Form nicht wirklich sinnvoll; wir hatten seit meiner Redakteurswahl im Jahre 2013 keine Contra-Stimme, die nicht von einem Admin kam. Die Massstäbe wird man sowieso ändern müssen, egal welches System man nutzt. --Datei:Sugimori 672.pngMecanno-man^Mäh 15:39, 25. Aug. 2020 (CEST)

Auch ein kurzer Einschwung von mir. Das mit der sehr geringen Anzahl an Contra-Stimmen ist mir schon vor einiger Zeit aufgefallen. Ich schließe aber daraus, dass die Leute schon früher hätten vorgeschlagen werden können. Denn ab dem gewissen und unbestimmbaren Zeitpunkt, ab dem eine Person für einen Rang geeignet ist, gibt es meiner Ansicht nach unterschiedliche Meinungen, ob die Person bereits den Rang verdient. Denn manche Leute würden einen Rang etwas früher vergeben, andere warten lieber etwas. Dass alle sich einig sind, zeigt mMn, dass dieser "unbestimmbare Punkt" schon geraume Zeit zurückliegt. Bei der Sache mit den Contra-Stimmen sehe ich also eher das Problem in der wählenden Community bzw. in einer mangelnden Bereitschaft Leute vorzuschlagen (wobei das aber absolugt kein "Angriff" an die ESBs sein soll) (das kann unter anderen auch sehr gut mit dem Maßstäbe-Thema, das Max angesprochen hat, in Verbindung gesetzt werden). --DeXter 15:50, 25. Aug. 2020 (CEST)

Dexter war schneller, aber trotzdem der Vollständigkeit halber mein Text: Das Ausbleiben der Contra-Stimmen ist wohl eher dem Umstand geschuldet, dass Wahlen zum Redakteur so lange auf sich haben warten lassen, dass jeglicher Zweifel ausgeschlossen gewesen war, ehe die Wahl initiiert wurde. Frühere und rechtzeitige (!) Wahlen würden mehr Feedback bzw. Kritik hervorbringen und es uns ermöglichen, dem Kandidat einen Vertrauensvorschuss zu gewähren und ihm aufzuzeigen, woran er trotz erfolgreicher Wahl weiter arbeiten kann. Wir können die Wahlen nicht immer so lange hinauszögern, bis wir einen perfekten Kandidaten haben, an dem es nichts auszusetzen gibt und der Erfolg der Wahl quasi gewiss ist. ~ Taisuke ^Diskussion 15:52, 25. Aug. 2020 (CEST)

Bis auf das VB-Wahl-System halte ich von Mec seinem Vorschlag nichts. WB und ÄWB waren für mich keine vergleichbaren Anerkennungen zum Red. Jemand der aktiv im Wiki mitarbeitet ist seine Benutzerseite Wurscht... Sie wird in der Regel mal aktualisiert wegen der Auszeichnung. Aber ansonsten ist es für mich persönlich keine "sichtbare" Auszeichnung/Wertschätzung. Sichtbar sind Farben/Symbole direkt beim Namen oder bei öffentlichen "schnellklicks" weit oben gelistet zu sein. Schnellklicks sind für mich Seiten die stark präsent Promotet werden. Wie z.b. die Seite der Reds/Admins. Vielleicht lässt sich das bisherige WB/ÄWB/PH etwas ausgestalten. Ich denke da an sowas wie ein Punktesystem. Rechtestufen (SB/VB/PL/Red/Admin) geben je nach Stufe Punkte. Dann gibt's für WB welche für ÄWB und vielleicht findet ja meine angedachte QS-Auszeichnung Anspruch und gibt dann auch pkt. Zu guter letzt kommen die PH mit in den Topf mit einer sinnvollen Gewichtung. z.b. 50pkt. Bronze, 100 Silber, 200 Gold. So werden werden User mit breitgefächerten PHs gegenüber projektspezi. nicht benachteiligt. Die Liste macht man dann mit Usern ab mind. VB und haut sie ganz oben mit rein. Soviel zu meiner Meinung/Ideen usw. Gruß * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 18:38, 25. Aug. 2020 (CEST)

Von der Idee, eine User-Rangliste zu erstellen halte ich nicht viel; das führt eher dazu, das Leute sich nur versuchen Auszeichnungen zu erarbeiten und dann auf Projekthelden/WBs geiern, was nicht der Sinn dieser Auszeichnungen ist. Man sieht das jetzt schon teilweise, mit den Bearbeitungszählern. Ich hätte aber nichts dagegen, WB/ÄWB iwie farblich hervorzuheben, wenn wir den Redakteur abschaffen; wie müsste man dann aber klären, ich sehe da nämlich dann das Problem, das ein bunter Regenbogen bei entsteht zwischen Projektleitern, VBs, WBs und ÄWBs - welcher noch dazu verkompliziert wird, das wir auch ne Farbe für Veteranen haben. Ich sehe da gerade spontan kein System, welches noch übersichtlich ist. --Datei:Sugimori 672.pngMecanno-man^Mäh 19:10, 25. Aug. 2020 (CEST)

Wie Mec bin ich nicht so von der Idee einer User-Rangliste überzeugt. Da würden viele User mit all ihren verschiedensten Eigenschaften, Ausrichtungen, Umständen,... mit einer einzelnen Zahl beschrieben und verglichen werden. Das würde außerdem dann das, von Mec anpesprochene, Auszeichnungs-Geiern verursachen. Aber Auszeichnungen sollten mMn nur eine Nebensache, ein Motivationsgrund sein und nicht das Ausschlaggebende warum man im Wiki mitmacht. --DeXter 20:06, 25. Aug. 2020 (CEST)

Zuerst gehe ich einmal auf die VB ein: Wie Mec schon gesagt hat, der größte Unterschied von SB zu VB ist eben das (auto-)patrol. Das muss unbedingt so bleiben, denn sonst gibt es aus meiner Sicht keinen Grund, VB werden zu wollen. Denn VB sind - wie der Name schon sagt - verlässlich und müssen daher auch dementsprechende Rechte haben. Die Idee, dass man VB wählen kann, ist gar nicht so schlecht. Dementsprechend müsste dann aber auch regelmäßig jemand vorgeschlagen werden, damit das Ganze auch einen Sinn hat. Zu Punkt 1. der Änderungen: Ja, definitiv sollen Benutzer, die VB werden sollen, ‚‘vor’ der Wahl gefragt werden. Punkt 2. finde ich auch wichtig, damit die Community mehr eingebunden wird, aber auch ein größeres Meinungsbild mit einfließt, das bestätigt, ob der Benutzer diesen Rang auch wieder verdient hat. Abschließend also zu VB: Bitte das patrol nicht verschieben, sonst gebe es z.B. für mich keinen Grund, aufsteigen zu wollen. Wenn das bisher das Totschlagargument war, dann muss daran gefeilt werden - ich weiß nicht, wie es bisher gehandhabt wurde. Aber: Die Edits der potentiell-VB-Benutzer müssen besser kontrolliert werden, sollten wichtig sein und vor allem Sinn ergeben. Das sind mMn Kriterien, an denen man festmachen kann, ob der Nutzer das patrol wirklich haben sollte.

Zu den PL: Sechs Projekte werden aktuell nur von Admins, zwei mit einem zweiten PL neben einem Admin besetzt. Da brauchen die Projektleiter kein Löschrecht, zumal man die Projekte mit Benutzern ohne Löschrecht an einer Hand abzählen kann. Die erste Frage wäre da also mMn nicht, ob man den Projektleitern entsprechende Rechte der Redakteure, die dann ja entfernt werden würden, geben muss, sondern ob man die Admins nicht entlasten müsste, was die Dreifachbelegung der Projektleitungen angeht. Wenn die Admins von neuen VB dahingehend entlastet werden würden, könnte man vielleicht erneut darüber diskutieren, wann man das Löschrecht erhält.

Nun zu den Redakteuren, dem Hauptkern der Idee: Ich finde, so hat es Dexter ja auch schon niedergeschrieben, dass zwischen dem Ausgleich der WB, ÄWB, PH und der Redakteure ein gewaltiger Unterschied herrscht, der nicht einfach so ersetzt werden kann. Redakteur zu sein Stelle ich mir anders vor, als drei Auszeichnungen auf meiner Benutzerseite zu haben. Ich muss Mec aber auch in dem Punkt zustimmen, dass zwischen Red und VB kein großer Unterschied herrscht, bis auf natürlich das Löschrecht. Durch die Community wären dann ja auch die VB bestätigt, wenn man die VB Wahlen umsetzt. Trotzdem ist das ein Unterschied, der bestehen bleiben muss. Die Beschreibung des Red sagt folgendes: „Die Redakteure des PokéWikis sind eine Benutzer-Gruppe mit erweiterten Rechten. Zu ihren Aufgaben zählt vor allem, für Qualität in Inhalt und Darstellung der Artikel zu sorgen“.

Und genau das macht die Reds aus. Ihr Löschrecht, ihre Sauberhaltung der Inhalte. Während die VB bisher von Admins nur die Bestätigung dafür erhalten haben, dass sie verlässlich arbeiten können und keinen brauchen, der hinter ihnen herläuft, sind Reds eine von der Community bestätigte Gruppe, die sogar Inhalte löschen kann, was stark Richtung Adminrechte geht. Es geht mir also hierbei darum, dass es eine Benutzergruppe gibt, die nicht unbedingt an den Rang des PL gebunden ist, aber die Sachen löschen kann, die also ein Anlaufpunkt auch für VB ist. Das muss auch mMn unbedingt höher angesiedelt sein als ein PL, denn Löschrechte sind besonders und damit sollte auch vorsichtiger umgegangen werden. Ich wiederhole auch das, was schon geschrieben wurde: Die Redakteure handeln im gesamten Wiki, Projektleiter meist nur in ihren Projekten. Das grenzt diese beiden Gruppen voneinander ab. Also: Auch hier würde ich sagen, dass die Rechte so wie sie sind bestehen bleiben müssen.

Ansonsten möchte ich hinzufügen, dass die Vergabe der Rechte etwas zu streng ist - bei Redakteuren ist für mich gar nicht ersichtlich, was man für diesen Rang machen muss, außer, dass es hilfreich ist, ein Projektleiter zu sein. Bei den VB ist das schon anders - man hat eine (un-)genaue Angabe, dass man mit genügend Wiki-Erfahrung, die sich bei aktiver Mitarbeit bestimmt sammeln lässt, VB werden kann. Allerdings fände ich es da wirklich sinnvoll, Benutzer vorschlagen zu können, weil bisher nach Beschreibung des VB nur Admins darüber beraten haben, ob man einen Benutzer als verlässlich einstuft. Das sollte transparenter sein, sonst ist vielleicht bei dem ein oder anderen Nutzer die Motivation weg. Die Wahlvorschläge wären da ideal. Feblue 21:55, 25. Aug. 2020 (CEST)

Hmm... ich hab die Titel / Rang Diskussion am Rande mitbekommen. Ich hab nicht wirklich viele Edits, aber vielleicht habe ich dadurch eine Sicht fast als Außenstehender und wollte mal von so einer Warte Feedback geben.

Also, wieso macht man Edits in einer Wiki? Letztlich nur für andere, man teilt Wissen (das man ggf. selber schon hat, oder in dem Zuge für sich recherchiert) und hilft damit anderen. Leider gibt es nicht viel mehr Anerkennung dafür, als sich selber auf die Schulter Klopfen zu können. Eigentlich muss man, damit es Spaß macht, eine intrinsische Motivation entwickeln anderen zu helfen. Anderer Name im Discord oder der Wiki macht da letztlich wenig Unterschied für langfristige Motivation.

Was sich hier entwickelt hat, ist für mich schon wirklich Deutscher als Deutsch. Als ich vor nem knappen Jahr beim Sw/Sh Release in den Discord gekommen bin, sind mir direkt die Titel aufgefallen. Veteran? Stimmberechtigt? Verlässlich (was heißt das, wann ist man verlässlich)? Die Thematik erinnert mich frappierend an die Pöstelei im Sportverein meiner verstorbenen Oma, wo jeder mit einer Aufgabe, oder einem Ehrenrang versorgt wurde. InB4 Brozene Ehrennadel des Pokéwiki-Bewirks Nordwest für Mario. Ehrenvorsitz wäre auch noch eine Idee.

So das war der fiese Teil, jetzt will ich auf eine produktive Schiene: Als Außenstehender würde ich empfehlen massiv den Rotstift anzusetzen, auch wenn zugebenermaßen, es den Zugang für Neulinge nicht bedeutend verbessern wird. Mein Vorschlag wäre trotzdem, Funktion (Rechteausübung) und Fame (Reward für Mitarbeit) strikt voneinander zu trennen. Fame sollte man nicht verlieren, Funktion aber ggf. nur für Aktive nach Community oder Admin-Entscheid vergeben werden. Trotzdem sollte man hier evtl. schauen, was wirklich Sinn macht und auch hier die diversen Stufen auf ein Minimum begrenzen... Auf der Arbeit bezeichnen wir so gewucherte Cluster gerne als historisch gewachsen.

Tldr: Für eher außenstehende sind die Stufen alle etwas Strange o.o

Benutzer:Darklux 22:02, 25. Aug. 2020 (CEST)

Kurz an Feblue: Löschen ist in der MediaWiki-Software nicht permanent; es kann grundsätzlich alles wiederhergestellt werden was jemals gelöscht wurde. Eine so grosse Verantwortung sehe ich deshalb jetzt nicht darin. Bezüglich Projektleiterentlastung (oder Adminentlastung?) verstehe ich auch nicht ganz, was du meinst. Es ist zwar in der Tat so, das es besser wäre in jedem Projekt zwei Projektleiter zu haben, allerdings braucht es dafür auch Leute, die für diese Posten in Frage kommen. Das ist aktuell an vielen Stellen einfach nicht der Fall - da wird ein Systemwechsel ebenfalls nichts bewirken.

Was Darklux und das mit dem Minimum an Stufen angeht: Ich glaube nicht, das es sinnvoll ist, mehr als eine Stufe zu streichen. SBs erhalten einige erweiterte Rechte, die wir nicht jedem mit nem Konto geben möchten, da sie gezeigt haben das sie auf jeden Fall proaktiv mitarbeiten wollen. VBs und Reds erhalten mehr Rechte, die dem Kontrollieren des Inhalts im Wiki dienen, und Admins haben etliche Rechte, die gravierende Eingriffe in das Wiki haben können. An der Stelle scheint mir nicht sinnvoll, mehr als einen Rang aufzuheben. --Datei:Sugimori 672.pngMecanno-man^Mäh 22:26, 25. Aug. 2020 (CEST)

Mal ehrlich, sind denn Ranglisten, Babeln und Punkte alles, was uns zum Thema Wertschätzung einfällt? Ich finde das Wort auch abgenudelt, weil es so oft fällt, aber der Umgang damit ist dann doch zu simpel und ich möchte euch da nicht von der Angel lassen. Das bisschen Symptombekämpfung sollte durch eine Wurzelbehandlung ersetzt werden... "User X macht Y, dafür kriegt er Z Punkte" entbindet nicht von anderen Arten des respektvollen Umgangs, denn zwei Drittel aller User wird sich dafür kaum interessieren. Im schlimmsten Fall sind die Auszeichnungen dann nämlich nicht authentisch, sondern nur rausgekloppt, weil ein Zähler auf eine bestimmte Zahl springt.

Leute, Wikiarbeit ist Communitypflege. Das ist ne relativ schlichte Wahrheit, denn so sind Wikis gebaut, von ihrem Wesen her, als Communityprojekt. Da kommt man nicht drumherum, das kann einem kein Bot abnehmen.

Eigentlich ist es gar nicht so schwer: Respektvoller Umgang heißt letztendlich Umgang auf Augenhöhe. Das kann man auf extrem viele Arten zeigen: Fragt neue User, ob sie klarkommen oder Unterstützung brauchen. Und wenn sie es tun, dann helft mit eurer Wikierfahrung aus. Auch, und das kostet Überwindung, wenn man gerade an anderen Wikithemen arbeitet oder andere Prioritäten hat. Das hat was von dem Mentorensystem, was schon häufiger anklang, man kann es also sogar institutionalisiert machen, das muss nichts Weiches, wenig Greifbares sein. Es ist ätzend, wenn Nachfragen als Störung verstanden werden. Schlimmer ist es nur, Vorschriften zu machen oder gar mit irgendwelchen Konsequenzen zu drohen, in welchem Kontext auch immer, denn wir sind hier eine Community verschiedener junger Leute und nicht in einem "Machtverhältnis" (ich nenne es so, weil der Begriff hier aufkam) zueinander, Bossgehabe oder auf Hierarchien pochen ("ich bin aber Red und du nicht, daher machen wir es, wie ich es sage") sind völlig daneben. Eher sind die nachkommenden User die, welche von den "alten Hasen" umgarnt werden sollten, mal übertrieben ausgedrückt, damit man sie hält.

Bedankt euch, wenn Leute mithelfen, kritisiert nicht übermäßig, gebt konstruktive Rückmeldung ohne pampige oder passiv-aggressive Emojis. Konstruktiv heißt mit Begründung. Begründungen wirken auch Wunder bei Entscheidungen, die nicht verstanden werden. Sitzt Diskussionen nicht aus, stellt euch ihnen. Hört richtig zu und überlegt, was denn Wahres am Standpunkt der Gegenseite ist, als nur Mängel aufzuzeigen. Geht auf User zu, bei denen ihr merkt oder vermutet, dass sie was brauchen oder sich zurückziehen... beteiligt euch an Smalltalk in Discord, sucht den Austausch. Gebt nen Vertrauensvorschuss. Beugt Regeln ein Stück weit, wenn es dazu dient, Usern eine Freude zu machen. Lasst Leute kontrolliert Dinge ausprobieren; was dazuzulernen treibt auch viele an. Ich bin sicher, für jeden Charaktertyp gibt es Arten, Communitypflege zu betreiben. Soll ich weiter machen? Oder grübeln wir doch ernsthaft weiter über Punkte und Ranglisten...? Maxmiran 22:34, 25. Aug. 2020 (CEST)

@Mecc: Danke fürs Einrücken :) also um das evtl. nochmal klar zu stellen: Wenn Ränge oder Rollen organisatorisch gebraucht werden, werden diese gebraucht. Was ich damit eher ausdrücken wollte, das geprüft werden könnte a) die administrativen Ränge so straff wie möglich zu machen und b) ein meritorisches System hiervon abzugrenzen. Rechte sollte haben, wer aktiv moderiert. Diese als gemischt mit Ehren-Auszeichnungen zu vergeben kann m.E. a) zu bösem Blut führen (wenn eine Funktion als Auszeichnung interpretiert wird) und b) führt ggf. zu einer verwirrenden Struktur, die Neulinge eher verwirrt und ggf. belustigt. Die diversen Funktionen und Rollen, bzw. die Mischung davon wirken auf mich stark "gewachsen", teilweise passiert sowas weil sich etwas bewährt, manchmal kommt mit der Zeit aber einfach immer mehr hinzu und wirkt letztlich gewuchert. Vielleicht fehlt mir als eher passiver Member die Einsicht, aber auf mich wirkt manches eher über die Jahre gewuchert.

@Maxmiran: Das meiste würde ich 1:1 unterstreichen. Offenheit ist für mich das Gebot der Stunde, und Flexibilität. Mit Ehrentiteln werden wir niemand für das Wiki begeistern, dann schon eher mit einer tollen, offenen Community. Strukturen sind Wichtig, ab einem gewissen Grad können diese aber auch ungewollt Schaden, ggf. wie gut im Fall zu sehen der zu der Diskussion geführt hat.

Benutzer:Darklux 22:02, 25. Aug. 2020 (CEST)

Zu Mec: Ja, das mit der MediaWiki-Software war mir bewusst. Trotzdem liegt mir etwas an dem Rang des Redakteurs, weil einfach eine weitere Stufe, die man sich durchaus verdienen kann, wenn man will, ein schöner Anreiz ist. Wenn man den Redakteuren also ihr Löschrecht nimmt, ist quasi der Sinn des Redakteurs nicht gegeben und es den Projektleitern zu überreichen würde für mich quasi ab VB den Anreiz nehmen, mehr im Wiki machen zu wollen. Zu meiner Idee mit den PL: Ja, das war mir auch bewusst, dass es aktuell (vielleicht) niemanden gibt, der eine Projektleitung mitmachen könnte / würde. Ich wollte mit dem Punkt einfach nur sagen, dass eine Verschiebung des Löschrechtes quasi nichts bewirken würde, weil sowieso fast niemand Projektleiter ist, der kein Löschrecht hat. -- Feblue 13:05, 26. Aug. 2020 (CEST)

Mal ein paar Anmerkungen zu den Diskussionsbeiträgen.

„Allerdings fände ich es da wirklich sinnvoll, Benutzer vorschlagen zu können, weil bisher nach Beschreibung des VB nur Admins darüber beraten haben, ob man einen Benutzer als verlässlich einstuft.“

– Feblue

Vielleicht verstehe ich das grad falsch, aber man kann allgemein immer Leute für verschiedenste Sachen vorschlagen. Damit meine ich nichts förmliches wie bei der Red-Wahl, sondern, dass man die jew. Personen (Admins oder PLs, je nachdem für was man vorschlägt) einfach anschreibt ^^ Der Vorschlag kann dabei z. B. VB-Ernennung, WB, ÄWB, Projektheld, usw. sein.

Der letzten Nachricht von Max kann ich nur zustimmen. Das würde zwar dauern, das alles umsetzen und das einzubürgern, ist aber etwas meines Erachtens nach sehr wichtiges und etwas, das wir mMn anstreben sollten.

„weil sowieso fast niemand Projektleiter ist, der kein Löschrecht hat.“

– Feblue

Wie man hier sehen kann, haben wir bei den Projektleitern aktuell 6 "nur"-VBs, 4 Reds und 3 Admins. "Fast niemand" würde ich also nicht sagen.

Mir fällt außerdem auch auf, dass diese Diskussion das Potenzial hat Unterthemen zu entwickeln, die auch eigene Diskussionen kriegen könnten, wodurch hier am Ende ein hin-und-her-Pendeln entsteht. Sollten hier solche Themen (ich sehe da in den von Max angesprochenen Punkten Potenzial) auftauchen und der Bedarf näher drauf einzugehen bestehen würde ich dazu aufrufen die eher separat zu diskutieren, damit die die volle Aufmerksamkeit kriegen, die sie brauchen und verdienen, und damit der Abschnitt hier nicht am Ende ewig lang wird und das eigtl. Thema irgendwann aus Versehen in den Hintergrund geraten ist :) --DeXter 14:23, 26. Aug. 2020 (CEST)

Also mal ganz ehrlich. Hier wurde inzwischen so viel geschrieben was es für Leute die ein Privatleben haben echt schwer macht auf dem laufenden zu bleiben. Wäre es nicht sinnvoll hier mal via Discord zu einer Talkrunde aufzurufen? In CT handeln wir zig Themen an einem Abend ab und hier stehen ellenlange Texte deren lesen schon einen Tag frisst. Wenn es zu soetwas keine Gegenmeinungen gibt würde ich einfach mal einen Doodle die nächsten Tage machen. So kommen wir vielleicht effektiver auf einen Konsens oder Ideen die wir testen können. Gruß * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 21:08, 26. Aug. 2020 (CEST)

Hey, DeXter! Nein, das hast du komplett so verstanden, wie ich das meinte. Allerdings war mir das nicht bewusst, dass man bisher für alles jemanden vorschlagen konnte. In Bezug auf die Projektleiter meinte ich das so, dass es entweder einen zweiten Projektleiter in einem Projekt neben einem VB gibt, der ein Löschrecht hat (bsp. Wds Projekt Tai und Jonny) oder die Projektleitung nur aus Nutzern besteht, die sowieso das Löschrecht haben. Da das aber ein Thema ist, wie du ja schon sagtest, das hier lieber den Hintergrund einnehmen sollte, schreibe ich dazu jetzt nichts mehr, da ich denke, dass meine Aussage klar geworden ist. -- Feblue 22:36, 26. Aug. 2020 (CEST)

Ich finde, das ganze in den VC zu verlegen, ist an dieser Stelle nicht notwendig. Grundsätzlich ist es besser, wenn Diskussionen im Wiki stattfinden; VC ist für mich nur da notwendig, wo eine Diskussion im Wiki eingeschlafen ist. Folglich bin ich an dieser Stelle dagegen. Bei einer schriftlichen Diskussion hat man zudem Zeit, seine Meinung zu überdenken und gezielt zu antworten, während in einer VC-Runde eher Ideen durcheinander geworfen werden, ohne das man da wirklich Zeit hat drüber nachzudenken. Außerdem gehe ich davon aus, das an der Stelle dann alle Benutzer sowieso die Texte hier gelesen haben müssten, um an der VC-Runde teilzunehmen, was dein Zeit-Argument so gut wie negiert. Und schliesslich noch: Das ganze ist hier bewusst öffentlich, so kann jeder seine Meinung dazu beitragen, in einer VC-Runde wären sofort Leute, die dann nicht Zeit haben (u. A. weil nicht von der Doodle-Umfrage mitbekommen), von der Diskussion ausgeschlossen. Das möchte ich nicht. --Datei:Sugimori 672.pngMecanno-man^Mäh 00:52, 27. Aug. 2020 (CEST)

Da so ein Doodle immer im Wiki ist, negiert sich das mit nicht mitbekommen. Und es ist glaube das vierte mal das du diese Idee im Wiki i.wo anbringst. Doch bevor hier ein Radikalschlag statt findet, braucht es erstmal Ideen oder Vorschläge und sowas im VC zu sammeln und dann hier nieder zuschreiben halte ich da für die sinnvollste Idee. Mal schauen ob auch andere dagegen sind. Gruß * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 09:33, 27. Aug. 2020 (CEST)

Ich wollte mir eigentlich mal an einem ruhigen Abend Zeit nehmen, meine Ansichten zu der ganzen Diskussion darzulegen. Das kommt dann noch später, wollte nur schnell mitteilen, dass ich Mecs letzte Nachricht komplett unterstütze. Dass das Thema wichtig ist, sieht man ja an den ganzen produktiven Beiträgen. Und ich denke, dass man jetzt nicht alles in den VC verlegen sollte, wo dann bestimmte Ansichten bei einer "Übertragung" ins Wiki untergehen bzw. falsch wiedergegeben werden könnten. Gerade dieses Thema hier eignet sich perfekt für eine Diskussion im Wiki, weil es jeden betrifft, viel Resonanz da ist, es viele verschiedene Meinungen gibt und, wichtig, extrem viele Argumente, die ausreichend gegeneinander abgewogen werden müssen. Das alles festzuhalten finde ich wichtig, sodass auch jemand, der erst später zu der Diskussion dazustößt, alle nötigen Informationen vorliegen hat. So, ist jetzt doch wieder länger geworden, egal :D. Lg --Toben des Meeres. Killuu 11:07, 27. Aug. 2020 (CET)

Die Diskussion hat sich mit der Zeit in mehrere Unterdiskussionen getrennt, ich hoffe ich vergesse kein Thema.

1.) Das Ändern der Rechtestruktur. Meiner bisherigen Erfahrung nach bin ich mit dem aktuellen Rechtesystem gut zurechtgekommen. Das fehlende Löschrecht stört mich nur selten, und wenn ich etwas löschen musste, war es auch selten ein Problem, jemanden zu finden, der das übernehmen konnte. Ich kann mir allerdings auch gut vorstellen, dass es anderen PLs dabei anders geht, im Strategie-Projekt hab ich allgemein wenig, was gelöscht werden muss. Aber auch abseits meines Projekts halte ich das aktuelle Rechtesystem für sinnvoll, so wie es ist. Der Rang des Redakteurs lässt sich meiner Meinung nach nicht wirklich durch Projektleiter "ersetzen". Redakteure können einfach als Ansprechpartner für viele verschiedenen Themenbereiche oder andere allgemeine Fragen dienen, was PLs nicht zwangsläufig können. Zusätzlich spielt das Prestige dieses Rangs eine Rolle. Ich könnte mich damit anfreunden, PLs und Reds rechtemäßig auf eine Stufe zu stellen, allerdings die Red-Rolle als reine Prestige-Rolle zu behalten. Der Redakteurs-Rang hat einfach eine ganz andere Wirkung als ein WB, ÄWB oder PH.

2.) VB-Wahlen. Ich halte Wahlen von VBs nur für bedingt sinnvoll. Im aktuellen System schlagen Admins intern einen SB vor und diskutieren intern. Das vorschlagen von SBs kann auch auf weitere Benutzergruppen ausgeweitet werden, wie Dexter bereits sagte ist es ja auch jetzt schon möglich, solche Diskussionen anzuregen. Allerdings denke ich, dass es bei vielen SBs schwierig sein wird zu beurteilen, wie qualitativ die Beiträge sind. Viele SBs, die sehr aktiv mitarbeiten und sich so potenziell für den VB-Posten qualifizieren, nehmen sich einzelne Aufgabenbereiche und legen ihren Hauptfokus auf diese Bereiche. Ich könnte mir kaum vorstellen, eine begründete Stimme bei einer VB-Wahl abzugeben, für einen SB, der hauptsächlich im Anime- oder im TCG-Projekt tätig ist. Andersherum glaube ich, dass viele kaum eine Stimme zu einem SB abgeben können, der hauptsächlich Strategie-Beiträge macht. Auch andere Punkte, wie Diskussionsverhalten und Vorlagenarbeit, sind bei SBs eher schwierig zu bewerten, da dieses in den meisten Fällen eher weniger ausgeprägt sind. Die Red-Wahl hingegen würde mir im Allgemeinen "einfacher" fallen, da Reds in der Regel in mehreren Bereichen tätig sind und auch über Vorlagenverständnis und Diskussionsaktivität verfügen sollten, sodass sich mehrere Punkte bewerten lassen. Allerdings denke ich, dass vor allem die inhaltliche Bewertung für den "allgemeinen ESB" schwer fallen kann. Ich fände es deswegen sinnvoll, zuständige PLs in die Diskussion der Admins mit einzubeziehen, da diese wahrscheinlich am besten bewerten können, wie gut der Nutzer mit den patrol-Rechten umgehen kann.

Luca12379 ^Diskussion 23:20, 27. Aug. 2020 (CEST)

Ich muss Lucas Kritik an VB-Wahlen zustimmen. Würden alle ESBs an solchen VB-Wahlen teilnehmen können, würde es früher oder später vermutlich zu geringer Wahlbeteiligung und/oder bloßem Signatursetzen kommen. Ich würde aber nicht nur die zuständigen PLs sondern allg. ESBs miteinbeziehen, die in den Bereichen aktiv sind, in denen auch der Kandidat was macht. Z. B. wäre es beim Spin-off-Projekt mMn nicht sinnvoll nur die PLs zu nehmen (dass die beiden sowieso Admins sind lassen wir mal bei dem Gedankengang weg), da ein zuständiger Unterleiter sicherlich auch ein gutes Bild des Users hat. Ein anderes Beispiel wäre der Café-Mix-Bereich (auch Spin-off, aber kein(e) Unterleiter). Da könnten von den ESBs, denke ich, Isso und ich am besten eine Einschätzung geben. Als Idee ist mir da grad eingefallen, dass bei einer VB-Wahl individuell die beteiligten Leute zusammengesucht werden könnten (wobei man das zusammensuchen viell. auch zum Teil in Form von in #intern fragen wer mitmachen will umsetzen kann). Die Vorgehensweise hätte aber auf jeden Fall auch ihre Schwachstellen, ist nur eine Idee, die mir zu später Stunde eingefallen ist. --DeXter 02:07, 28. Aug. 2020 (CEST)

Ich hätte nen Vorschlag dazu, wie eine sinnvoll hierarchische Rechtestruktur aussehen könnte, aus der man wiederum auch gut Kriterien dafür ableiten könnte, die man erfüllen muss, um eine Stufe aufzusteigen. Das sind dabei eher qualitative Vorschläge, die man quantitativ unterfüttern könnte, aber nicht zwingend müsste.

• SBs werden danach gemessen, ob sie die grundlegenden Funktionen des Wikis verstanden haben und sich mit dem Bearbeiten gut zurechtfinden.
• VBs stellen die nächste Stufe dar. Sie zeichnen sich dadurch aus, dass sie an mindestens einem Projekt gewinnbringend mithelfen. Daher sollten VBs nicht allgemein gewählt, sondern in diesem Szenario von einem Projektleiter vorgeschlagen werden. Im Sinne des Vertrauensvorschusses müssen Admins dem nicht zwingend zustimmen, können aber ein Veto einlegen. Im Unterschied zur unten vorgeschlagenen Redakteurs-Definition wird klar, dass das wahrscheinlich dazu führen wird, dass wir mehr VBs erhalten werden als aktuell gesetzt werden, was ich toll fände. EIn Name für die Rechtestufe könnte "Verdienter Benutzer" sein, im Sinne von dass er sich in einem Projekt verdient gemacht hat. Dann müsste man sich nicht mal an ein neues Kürzel gewöhnen :)
• Die nächste Stufe würden Projektleiter darstellen. Sie wären in dieser Denke dann für ein Projekt auch inhaltlich stärker verantwortlich und würden mit den VBs zusammen darin werkeln.
• Redakteure könnte man nun wiederum so definieren, dass sie projektübergreifend unterstützend tätig sind. Das würde dann auch eine Wahl rechtfertigen, weil dieser projektübergreifende Gedanke dazu führt, dass alle Autoren projektübergreifend aussagefähig über den Autoren sein sollten.
• Admins haben dann zu Redakteuren dasselbe Verhältnis wie Projektleiter zu VBs, übernehmen also mehr Verantwortung für das Gelingen.

Ich kann mir ein solches Definieren der Rechtestufen gut vorstellen, weil es deutlich macht, in welche Richtung man sich entwickeln muss, wenn man aufsteigen möchte. In Projekten mitarbeiten, in Projekten mehr Verantwortung übernehmen, projektübergreifend mitarbeiten, projektübergreifend mehr Verantwortung übernehmen. Ich glaube, dass der größere Projektfokus dazu führen könnte, dass mehr User VBs werden, weil die Projektleiter auch sehr speziell interessierte User fördern könnten. Ich würde zudem empfehlen, von numerischen Kriterien ein Stück weit abzukommen. Zahlen und Zähler können natürlich ein nützlicher Richtwert sein, aber wenn sie keine inhaltlichen Ausnahmen zulassen, werden sie immer ein Ungerechtigkeitsgefühl hinterlassen. Vielleicht ist ja was Interessantes dabei! Maxmiran 19:59, 1. Sep. 2020 (CEST)

Zu Max' Vorschlag: Ich werd hier das Gefühl nicht los, das dies lediglich Änderungen sind, die das System ändern aber sonst nicht viel erreichen. Bei den SBs würd ich erst mal nicht mehr ändern, als auf der Diskussionsseite der Stufe aktuell diskutiert wird; imo. braucht es da inbesondere Klarheit, da es die erste Stufe ist, und „grundlegende Funktionen verstehen“ scheint mir da etwas sehr schwammig. Dafür wird btw nicht mal ein Account benötigt; jeder der in nem anderen Wiki arbeitet kennt diese. Bei den VBs hab ich das Gefühl ist dies de facto keine Änderung, denn: nicht ablehnen ist schlicht die doppelte Negierung von akzeptieren, und grundsätzlich kann jeder jetzt schon nachfragen wie es denn mit VB-Rechte für wen bestimmtes aussähe, auch wenn dies nirgends iwie definitiv niedergeschrieben ist. Die Admins sind auch Menschen, und Menschen können kommunizieren. Folglich ist das einzige was da noch dran ist die „Definition“ der Ränge, und ich hab das Gefühl die klar zu definieren ist nicht wirklich sinnvoll, da sie so nicht etwa flexibler, sondern starrer wird. Der konkrete Vorschlag geht meiner Meinung nach auch eher in die Gegenrichtung zum tatsächlichen Trend, wie sich ein User im Verlauf der Zeit verhält. Tendenziell scheint mir nämlich, das ein User sich voller Elan in die verschiedensten Sachen reinstürzt und dann mit der Zeit mehr und mehr spezialisiert. Hier würde dann allerdings verlangt werden, erst einmal fokussiert zu arbeiten und dann breiter zu werden, wenn man mal VB ist. Ungeachtet der vorherigen Argumentation ist es mir auch schleierhaft, warum Projektleiter plötzlich formell in die Pyramide aufgenommen werden sollen - diese werden nach Bedarf vergeben, ein neuer User könnte da recht leicht also seinen Aufstieg "blockiert" sehen, wenn er in einem Projekt mit einem aktiven Leiter arbeitet.

Generell in die Runde: Es scheint mir nicht mehr sinnvoll, den Vorschlag der Ablösung des Redakteurs-Ranges weiter zu verfolgen. Allerdings haben die Ideen, VB-Wahlen zu machen, ziemlichen Anklang gefunden. Da ich die Wahlen ja ursprünglich verschieben wollte, demnach die Frage an die Unterstützer dieser Idee: Wie säht ihr denn die zwei Wahlen nebeneinander? Meint ihr das eher so das sowohl für VB als auch für Reds Wahlen existieren, oder eher so das die Wahlen auf VB runtergesetzt werden und Admins die Redakteure einsetzen? Ausserdem hat sich an der Stelle niemand zu meinem Vorschlag mit den Veteranen geäussert, wär ich auch noch um Feedback froh; insbesondere wenn ihr für beides Wahlen möchtet wie das dann implementiert sein soll. --Datei:Sugimori 672.pngMecanno-man^Mäh 01:53, 2. Sep. 2020 (CEST)

Der eine oder andere hat es evtl. im Discord in #organisation bereits mitbekommen. Ich hatte zum Beitrag von Max einige Rückfragen um seinen Gedankengängen zu folgen. Daraus ist ein wenig Brainstorming geworden was auch teils Sachen die ins Wiki gehören hervor gebracht hat. Damit die Diskussion nicht untergeht, kopiere ich sie einmal mit hierher: Discord Diskussion zum nachlesen

Pöbelpanda gestern um 20:00 Uhr
Hab nochmal einen Vorschlag zum Rechtesystem gepostet, als antwort auf das Lounge-Gespräch, aber wollte da nicht noch einmal reingrätschen. :slight_smile: Vielleicht ist ja was dabei, was den gefühlt ungleichen Abstand zwischen den Rollen etwas glätten und damit das System besser handhabbar machen könnte, ohne zu groß eingreifen zu müssen ^^

Ryuichi gestern um 20:11 Uhr
@Pöbelpanda :thinking: mal blöd gefragt... dein Gedanke zu dem neuen VB ist doch ziemlich einseitig und zwingt User fix auf ein Projekt zum aufsteigen... ist es da nicht sinnvoller bei Usern die sich auf ein Spezielles Projekt werfen mehr gewichtung in die PL-Meinung zu legen und ansonsten ist der Vorschlag ja auch nur ein VB-Wahlen.... Der Gedankengang zu SB ist schon gut und recht aber woher weißt du ob sich ein User gut zurecht findet oder lediglich sich durch copy/Pastet? Ich schreibs einfach mal hier da mir gerade eher das Verständnis zu deinen Gedankengängen fehlt. Ggf. kannst es entweder auf der Disku oder per PN erläutern dann wüsste ich eher wie ich da im Wiki drauf reagieren soll:blush:

Pöbelpanda gestern um 20:13 Uhr
Ja, verständliche Nachfrage! Ich würde das als Mindestanforderung verstehen. Klar, wenn man in mehreren Projekten mithilft, hätte man sich auch überqualifiziert. Ich möchte nur vermeiden, dass man erst als VB in Betracht gezogen wird, wenn man "wikiweit Aufmerksamkeit" erhalten hat, und fänd es daher schön, wenn es auch auf Projektebene schon möglich wäre

definitiv keine VB-Wahlen, das wäre für so spezielle Fälle einfach doof, die dann erst die Aufmerksamkeit kriegen, die sie eigentlich schon längst gebraucht hätten.

Ryuichi gestern um 20:15 Uhr
Ich persönlich behalte da meine Schäfchen soweit wie möglich im Auge und mache da hier und dort mal eine Anfrage zum VB bei einem Admin... kp wie das andere halten

Pöbelpanda gestern um 20:15 Uhr
und was ich daran schick fände, wäre, dass man quasi wüsste "Wenn ich VB werden möchte, dann suche ich mir ein Projekt aus, was ich cool finde, und engagiere mich da. Dann zeige ich, dass ich VB werden kann". Man kann also gezielt was dafür tun

cool wenn das unter der Hand schon so ist, aber man könnte es auch festschreiben, damit User sehen, was es braucht, schwarz auf weiß

Mario-WL gestern um 20:15 Uhr

„und was ich daran schick fände, wäre, dass man quasi wüsste "Wenn ich VB werden möchte, dann suche ich mir ein Projekt aus, was ich cool finde, und engagiere mich da. Dann zeige ich, dass ich VB werden kann". Man kann also gezielt was dafür tun“

– Pöbelpanda

Speziell das liest sich richtig toll!

Jetzt muss nur noch das Event-Projekt oder QC-Projekt gegründet werden :DD

Pöbelpanda gestern um 20:16 Uhr
"Verdienter User" bleibt VB, ist nicht mal ne Umgewöhnung :smirk:

Mario-WL gestern um 20:18 Uhr

„"Verdienter User" bleibt VB, ist nicht mal ne Umgewöhnung :smirk:“

– Pöbelpanda

Das ist nur leider wieder ein Adjektiv, das alle anderen völlig falsch deuten können … haben es alle darunter nicht verdient User zu sein? :smile: Aber Adjektive werden fast immer Probleme machen

Pöbelpanda gestern um 20:18 Uhr
ich würde gerne erreichen, dass man auch mit speziellen Interessen VB werden kann, also wenn man z. B. von Vorlagen nicht die blasseste Ahnung hat, dafür aber ein Texteprofi ist ich weiß, was du meinst, Mario, aber es gibt ja auch Adjektive, die nicht wertend sind. "gewählt" z. B., das beschreibt dann halt einfach den Zustand der Usergruppe

Mario-WL gestern um 20:20 Uhr
Absolut. „Verdient“ würde ich aber schon zu den eher wertenden zählen, um bei deinem Beispiel zu bleiben.

Pöbelpanda gestern um 20:20 Uhr
verdient meint nicht "das habe ich mir verdient" sondern "ich habe mich verdient gemacht", ja stimmt, das ist blöd, weil es doppeldeutig ist

Regisso gestern um 20:20 Uhr
Fleißiger User :fluffeluff:

Mario-WL gestern um 20:20 Uhr
FU … wofür das wohl steht :enton:

Pöbelpanda gestern um 20:22 Uhr
ich würde irgendein Adjektiv wählen, wenn sonst sich nichts anbietet, was den Umstand beschreibt, dass der User von der Community anerkannt wurde als qualitative Unterstützung. also was passivisches quasi

Lila Serpiroyal gestern um 20:22 Uhr
Anerkannter Benutzer?

Pöbelpanda gestern um 20:22 Uhr
ja wieso nicht

Mario-WL gestern um 20:22 Uhr
Weil jeder Benutzer, der kein Vandale ist, Anerkennung verdient? :see_no_evil:

Regisso gestern um 20:23 Uhr
Qualitätsprüfender User

Ryuichigestern um 20:23 Uhr
:thinking: nur weil sich jemand bei Orten gut anstellt bedeutet es nicht das es generell im Wiki klappt... und das ist für mich halt so der knackpunkt jemanden autopatrol zu geben... ich habe später nach Orten auch einfach mal bei manga usw. rumgewerkelt... es heißt verlässlich da man i.d.R. nicht jeden edit prüfen muss... verdient ist da eher was wertendes/belohnend aufsteigend. Da beißt sich wieder Wertsystem mit Rechtesystem. Da du diese Systeme ja selbst kennst und damalige Diskussionen wenn ich mich recht erinnere mitbekommen hast, kann ich deinen Vorschlag immernoch nicht nachvollziehen. Es werden mMn eher Ideen benötigt die entweder die Systeme trennen oder besser in Einklang bringen. Hoffe ist nun besser verständlich warum ich deinen Gedankengänge nicht folgen kann

DeXteur 🧐 gestern um 20:25 Uhr
Eine Frage zu den von Max vorgeschlagenen Red-Anforderungen: Ich nehme das gerade so war, dass der projektübergreifende Aspekt eine Pflichtvoraussetzung wäre. Da habe ich aber entgegenzusetzen, dass mit dem aktuellen kleinen Team PLs teils ziemlich vollbeladen mit Arbeit sind und evtl. einer in einem ziemlich starken Fall dann unter Umständen nicht wikiübergreifend mithilft, da sein Projekt bereits immens viel Arbeit benötigt. Ich fände es nicht gut da einen Anreiz zu geben "sein" Projekt zum Teil zu vernachlässigen und woanders was zu machen nur damit man im Rang aufsteigen kann. Die Argumentation geht natürlich an manchen Ecken etwas ins fiktive, da bei uns eigtl. fast alle Projekte mit anderen verbunden sind, aber ich will den Aspekt trotzdem mal ansprechen ^^

Pöbelpanda gestern um 20:26 Uhr
Ich kanns logisch nachvollziehen, Ryu. Ich habe aber ein Stück weit ein Problem mit dem Grundgedanken den Usern gegenüber, was ich unter dem Thema "vertrauensvorschuss" zusammenfassen könnte. Ich bin ziemlich sicher, dass User, die sich in einem Projekt verdient gemacht haben, einschätzen können, was sie im Wiki sicher bearbeiten können und wo ihnen Wissen fehlt. Deswegen glaube ich, dass man diesen Usern ohne Vorsicht nen VB geben kann, denn sie "wissen, was sie nicht wissen". Dein Gedanke geht davon aus, dass User dann in anderen Projekten einfach rumwüten, aber ich kann mir das schlicht nicht vorstellen. Dex, ne übergreifende Wikiarbeit kann ja auch kleiner beginnen, beispielsweise darin, dass man bei Redakteuren erwartet, dass sie bei allgemeinen Diskussionen sich beteiligen, während man das bei einem VB vielleicht nur bei projektinternen Diskussionen erwarten würde. Es muss ja keine zwingend inhaltliche Mitarbeit reindefiniert werden ein Beispiel noch: Ich habe als VB damals auch Vorlagen geschrieben, aber sie dann immer gegenchecken lassen, weil ich wusste, dass ich das nur schlecht kann. Ich hätte sie nie einfach implementiert, ohne sie prüfen zu lassen. Vielleicht hilft das ja als Beispiel, Ryu Ich finde wichtig, dass die Anforderungen ein Kontinuum sind, und dass keine riesigen Lücken zwischen den Hierarchiestufen sind. Ein solches Modell könnte dann auch bewusst Aspekte umfassen, die man z. B. als VB nicht leisten muss. Kann, aber nicht muss. Das nimmt Last von den Schultern und reduziert die Anforderungen auf ein realistisches Maß :slight_smile: Erwartungen statt Anforderungen vielleicht Ich bin ja im realen Leben bei ner Unternehmensberatung. Ich weiß z. B., dass ich als Juniorberater keine Akquise machen muss. Wenn ich Seniorberater werden muss, schon. Ich kann mich also entspannt zurücklehnen, wenn ich das nicht werden möchte, und gehe das Thema an, wenn ich es möchte. Meine fachlichen Schwerpunkte sind dabei erst mal egal. Weiß nicht, ob das Beispiel nur in meinem Kopf sinn macht. :smile: Aber ein Stufensystem muss halt auf den unteren Stufen Inhalte auslassen

das ist wie bei den Artikelauszeichnungen übrigens auch. Da reicht schon ein Kritikpunkt, um gegen eine Auszeichnung zu stimmen, obwohl lesenswert quasi einen Puffer für Mängel enthalten sollte.

DeXteur 🧐 gestern um 20:32 Uhr

„Ich persönlich behalte da meine Schäfchen soweit wie möglich im Auge und mache da hier und dort mal eine Anfrage zum VB bei einem Admin... kp wie das andere halten“

– Ryuichi

„cool wenn das unter der Hand schon so ist, aber man könnte es auch festschreiben, damit User sehen, was es braucht, schwarz auf weiß“

– Pöbelpanda

Wie Ryu behalte ich auch meine "Schäfchen" im Auge, um sie dann bei Gelegenheit vorzuschlagen, allerdings bin ich bei der Sache noch etwas ungeübt. Ich denke aber, dass das recht allgemeine Praxis ist, denn jeder PL wird, denke ich mal, aktive ESBs und/oder Co-PLs in seinem Projekt haben wollen.

Pöbelpanda gestern um 20:38 Uhr
Ich bin sicher, es gibt auch viele andere Kriterien, die man anlegen könnte. Vielleicht habt ihr ja andere Ideen, was man auf die Frage "Was unterscheidet einen Redakteur von einem Projektleiter, was von einem VB" als Antwort geben könnte. Diese Antwort wird aber präzise sein müssen. und bitte keine Zahl sein. ich weiß, wir sind nicht Wikipedia, aber übrigens kann man dort den verlässlich-Status nicht verlieren, weil die auch davon ausgehen, dass man, wenn man die Struktur und die Arbeitsweise kapiert hat, nicht mehr rumwüten wird. :smile:

Ryuichi gestern um 20:41 Uhr
geht nicht um rum wüten sondern das man versucht mit seiner Erfahrung wo anders zu helfen was dann ggf. übersehen wird wodurch sich Handhabungen in verschiedene Richtungen entwickeln. z.b. Habe ich die alte inzwischen nicht mehr existente Ortenav entwickelt und die einfach mal fürs Manga gemacht da es meiner Meinung dort fehlte. Dies war nie wütend sondern aus meiner Sicht helfend. Go hatte dies allerdings erst auf Nachfrage meinerseits mitbekommen. Meine Grundsätzliche Meinung ist hier halt das wir versuchen mit den Aktuellen Stufen sowohl Wert wie auch Rechte zu vermitteln. Die vergangenen Diskussionen haben mir persönlich allerdings aufgezeigt das bei Beibehaltung dieser Stufen inkl. Rechte es keinen Einklang geben wird. Es mangelt derzeit an Ideen und konzepten wie wir Wert und Rechte in Einklang bringen und daher dreht sich diese Diskussion die Mec schon zum x-ten mal anbringt immer wieder im Kreis.

Am liebsten wäre mir wir streichen deine Frage und vergeben zukünftig Rechte aufgrund von Erfahrung und Ränge aufgrund von Leistung... z.b. Artikel aufbereitet, Vorlagen neu entworfen, Diskussionsinput usw.

Pöbelpanda gestern um 20:43 Uhr
Ich glaube nicht, dass sich das zwingend widerspricht. In nem echten Unternehmen wirst du auch befördert, wenn du dich verdient gemacht hast und bewährt hast, und dann werden neue Anforderungen an dich gestellt. Finde das relativ logisch miteinander gekoppelt und glaube, man muss es nicht zwingend auseinanderdividieren. Man könnte es auch einfach glätten und aneinander angleichen, von der Logik her "zeig, dass du mit dem Recht umgehen kannst, dann kriegst du es auch." und das sind halt keine quantitativen Maßstäbe, sondern qualitative n Recht ist ja quasi ein Vertrauensbeweis, also das ist immer auch eine Art der Wertschätzung, ein Recht zu verleihen im Sinne von "wir glauben, dass du es gut einsetzen kannst, und vertrauen es dir an"

Ryuichi gestern um 20:51 Uhr
Aber wie will man die 2 wichtigen Rechte autopatrol/delete zwischen diesen wenigen Stufen glätten. Ich wäre eher für mehr stufen. Erst nach "vielen" bearbeitungen sieht man ob man jemanden noch über die Schulter schauen muss. Allerdings kann zwischenzeitlich wertschätzung in form eines Aufstiegs fehlen was wieder zu inaktivität führt. Teufelskreis.... hätten wir die Kapazitäten dann hätte ich jedem neuen VB für die Anfangszeit einen Mentor zur Verfügung gestellt der anfangs noch bissl über die Schultern sieht. Dies haben wir allerdings nicht

Pöbelpanda gestern um 20:51 Uhr
Was nicht ist, kann ja noch werden! Ich wäre der erste, der für ein Mentorensystem zur Verfügung stünde, haha :smirk:

Killuiumpermanganat gestern um 20:52 Uhr
Das ist ja scho lange auf Max' Agenda :grin:

Pöbelpanda gestern um 20:52 Uhr
Also, sobald man mir selbst wieder zutraut, sinnige Edits zu machen :enton:

Ryuichi gestern um 20:55 Uhr
Wenn es Kapazitäten gibt, bin ich der letzte der sich gegen stellt. Ich wüsste allerdings nicht wie ich noch Mentor spielen soll. Mir fällt es ja schon schwer sämtliches was so auf meiner Agend steht abzuarbeiten.... Jetzt stell sich einer vor wir würden mittels Vertrauensvorschuss 5 neue VB machen... diese würden bis zu 5 Mentoren benötigen außer es hat jemand soviel Kapazitäten (wodurch ggf. eigene Projekte/Ideen/Hilfen liegen bleiben).... Es fehlt halt an Erfahrenen Helfern neue zu Unterstützen für ein solches System...

Pöbelpanda gestern um 20:58 Uhr
Naja, oder ihr teilt halt die inhaltliche Arbeit auf und was dir dadurch frei wird, investierst du ins Unterstützen. Das könnte ein weiterer Vorteil der eher projeltbezogenen VBs sein, dass die Projektleiter entlastet werden und aber klar zuständig fürs Unterstützen sind

Ryuichi gestern um 20:59 Uhr
Auf wen soll ich den meine Aufgaben aufteilen welcher nicht bereits selbst so viel Aufgaben hat?

Pöbelpanda gestern um 20:59 Uhr
Anderen was zu zeigen oder beizubringen ist übrigens auch n krasser Motivator Das ist n Zirkelschluss ryu. Wenn jemand käme, dem du helfen müsstest, dann wäre das auch derjenige, der dir was abnimmt. Umgekehrt musste nix befürchten, wenn keiner da ist. Der Aufwand ist gleich

DeXteur 🧐 gestern um 21:02 Uhr
Zu dem mit dem Mentor-Thema: Meiner Meinung nach sollte jeder aktive SB einen ESB als eine Art Mentor haben, um den z. B. mit Fragen zu durchlöchern (@Shorty weiß von früher gaaaanz genau was ich damit meine :grins:) An sich kann jeder User sich sein "Opfer" (:enton:) selbst aussuchen, aber besonders wenn man grade erst in die Community einsteigt wird sicherlich nicht jeder einfach eine wildfremde Person anschreiben und zu seinem Mentor auserwählen. Daher würde ich da auf jeden Fall dazu aufrufen, dass jeder in seinen Bereichen schaut, obs da nen User gibt dem er mit Rat und Hilfe usw. zur Seite stehen kann (und in anderen Bereichen kann man natürlich auch schauen und dann da die passenden Leute auf die Kandidaten hinweisen) Ryus Argumente kann ich aber unterstützen. Aktuell kann man es sich teils kaum leisten aufwendige Hilfe zu leisten. Z. B. könnte ich eigtl. großteils nur Fragen beantworten usw. und im "fortgeschrittenen Stadium" kleinere Anstöße für Sachen geben. Leuten im Mentoren-Stil zu helfen würde ich sehr gerne machen, aber das würde mein Projekt aktuell nur sehr eingeschränkt zulassen.

Ryuichi gestern um 21:04 Uhr
@Pöbel Ja und nein... erst muss er soweit sein das er mir was abnehmen kann, bis dahin stagniert bzw. steigt mein Haufen. Es bräuchte erst Entlastung insoweit das der Berg mindestens stagniert und nicht steigt. Siehe hier auch Dexi

Pöbelpanda gestern um 21:10 Uhr
Kann ich sehr gut nachvollziehen. Es ist halt ein Investment; je mehr und schneller du Leute befähigst, selbstständig was abzunehmen, desto eher hast du selbst die Hände frei. Hoher Anfangsaufwand mit hohem Nutzen später Und wie gesagt, hat auch wieder nen Respektscharakter, weil Mentoren natürlich höheres Ansehen erlangen als Projektprofis im stillen Kämmerlein

feblue heute um 00:27 Uhr
Mal aus der Sicht eines SBs:

Ich fände es zwar schön, wenn es jemanden gäbe, der mir: zeigt, was ich wo finde; Begriffe erklärt, die in Diskussionen vorkommen; hilft, mich in Sachen einzufinden, die ich mir bisher nicht vorstellen kann, weil ich sie gar nicht kenne; einen Weg vorgibt, den ich gehen kann, um selbst mehr herauszufinden; …

Das wäre echt genial, aber aus den höheren Rängen höre ich leider nur, dass man dafür keine Zeit hat. Das könnte ich verstehen, wenn ich soweit wäre, dass ich mir vorstellen kann, woran ihr denn alle arbeitet. Ich sehe davon nämlich nichts außer in den letzten Änderungen. Und da fängt es an: Ich nehme einfach an, dass das alles so ist, wie ihr es beschreibt. Ich verstehe aber nicht, was ihr macht, sondern kann es nur hinnehmen, weil es für mich nichts anderes als die letzten Änderungen gibt. Wenn aber so eine Person, die im Hintergrund arbeitet, mir und auch anderen Potentiell-VBs zeigt, was sie da eigentlich machen, gibt es vielleicht mehr helfende Hände. Helfende Hände, die Dinge beschleunigen können und Nutzern höherer Ränge Arbeit abnehmen können. Ergo: Mehr Zeit, um neuen VBs zu zeigen, wie das Wiki läuft.

Ich würde mir einen Mentor wünschen, aber bisher konnten sich alle meine Fragen in den Kanälen hier lösen.

Weiter zu Potentiell-VBs:

Ich bin da ganz bei Max, dass es einfach seitens der PL oder Admins einen Vertrauensvorschuss geben könnte. Ich stimme ihm auch dabei zu, dass man als VB nicht das ganze Wiki auswendig kennen muss, um VB zu sein. Man kann doch immer noch nachfragen, falls man sich nicht sicher ist, was man sicherlich kann, wenn man eine Zeit lang im Wiki tätig ist. Man kann sich Dinge zutrauen oder sagen: "Okay, da brächte ich doch noch Hilfe.". Das verstehe ich nämlich unter verlässlich. VBs müssen nicht zu 100% bereits alles kennen, was das Wiki inne hat, es geht vielmehr darum, zu wissen, wann ein Benutzer sich selbst gut zurechtfindet und auch weiß, wo Anlaufstellen sind, falls man Hilfe braucht.

Mecanno-man heute um 00:54 Uhr
es wäre schön, wenn diese Diskussion auf der AD stattfinden würde :ups: Wenn nämlich zwei Gruppen an unterschiedlichen Stellen über dasselbe diskutieren, werden am Ende zwei unterschiedliche Schlüsse daraus gezogen

feblue heute um 00:55 Uhr
Dann kopiere ichs eben rüber. Edit: Funktioniert nicht, die Mentorengeschichte wurde ja nur hier erwähnt. Morgen schreib ich drauf.

DeXteur 🧐 heute um 00:57 Uhr
Mir fällt grad anhand des ersten Teils von feblues Nachricht auf, dass ich eine ziemlich ungenaue Vorstellung der Sicht eines SBs auf das Thema gehabt habe :thinking: Vielen vielen Dank, feblue! Die Sichtweise eines Stimmberechtigten Benutzers auf das Thema ist super wichtig und dank dir jetzt vorhanden :fluffeluff:

Das zeigt mir, dass bei dem Thema unbedingt was getan werden muss, wenn ein Gefühl der Verschlossenheit gegenüber nicht-ESBs entsteht. Mir ist es allerdings nicht möglich mir jetzt gleich ein Konzept oder eine vielversprechende Idee dafür auszudenken, da ich und meine To-Do-Punkte und die Möglichkeit bei mir einen oder mehrere SBs einzubinden sicherlich anders als bei anderen Leuten ist. Ich habe grade immer Gedankengänge in die Richtung von wir sollten SBs stärker mit einbeziehen; aber wird das nicht evtl. schon versucht? Bei vielen meiner To-Do-Punkte könnte ich Leute direkt mitwirken lassen, aber wie sieht das bei anderen Bereichen aus?

feblue heute um 01:02 Uhr

„Die Sichtweise eines Stimmberechtigten Benutzers auf das Thema ist super wichtig und dank dir jetzt vorhanden“

– DeXteur 🧐

Das freut mich doch. Nur muss ich zusehen, dass ich das irgendwie verpackt kriege, dass es auf der AD auch Sinn ergibt^^. Wobei ich eigentlich nur hier antworten wollte, weil das Zeug mit den Mentoren drin war. Aber was solls, dann muss ich eben den Hergang meiner Ansicht mit einbinden :adeal:

DeXteur 🧐 heute um 01:04 Uhr
Jo, das hier hat mit Fragen zu Max' Disku-Beitrag angefangen und ist zum Mentoren-Thema übergegangen. Blieb aber mMn eher auf der Brainstorming-Seite, weshalb ich da bisher noch keinen AD-Bedarf gesehen habe. Die Sachen oben zu Max' Beitrag können mMn zur Wiki-Diskussion in irgendeiner Form hinzugefügt werden, aber das mit dem Mentoren-Thema und [Edit: der Teil von] feblues Beitrag ist mMn schon wieder ein anderes Thema. Das sollte, denke ich, dann ne eigene Überschrift kriegen :thinking: Mentoren haben zumindest mit einer Umgestaltung der Rechtestruktur nicht viel zu tun (es sei denn man baut das irgendwie in die Rechtestruktur ein, aber das klingt grad nicht sinnvoll)

feblue heute um 01:07 Uhr
Das wäre auch eine Option, aber da müssen wir aufpassen, dass sich nichts überschneidet. Vielleicht sollte ich damit dann noch warten, bis auf Max‘ Beitrag genügend reagiert wurde. Ich finde, dass die Rechtestrukturdiskussion erst beendet werden sollte.

DeXteur 🧐heute um 01:09 Uhr
Jo, wär vermutlich gut :thinking:

Mecanno-man heute um 01:30 Uhr
meinte damit auch eher die Sachen zu Max' Beitrag

RobbiRobb heute um 01:32 Uhr

„Das wäre echt genial, aber aus den höheren Rängen höre ich leider nur, dass man dafür keine Zeit hat.“

– feblue

Man möge mir verzeihen, dass ich dieses Thema hier jetzt doch wiederbelebe, aber da würde mich mal interessieren, wie dieser Eindruck zustande kommt. Hast du, Feblue, jemanden gefragt und von diesem dann nur zu hören bekommen, dass derjenige keine Zeit hat? Ist das mehrfach so vorgekommen oder ist das ein Einzelfall? Ich tue mich nämlich schwer mit der Vorstellung, dass dich jemand einfach so völlig ohne Hilfe dastehen lassen würde, wenn du explizit darum bittest. Dass nicht jemand auf dich zukommt und dir aktiv eine Hilfestellung anbietet, wäre etwas, was sich bspw. durch ein momentan nicht vorhandenes Mentoren-Programm lösen ließe, aber zumindest ich versuche auch jetzt schon alle Fragen zum Wiki zu beantworten und seien sie auch noch so simpel. Und ich bin mir ziemlich sicher, dass auch etliche andere Benutzer so damit umgehen

Mario-WL heute um 02:04 Uhr
Dexter, hast du vergessen, dass ich selbst SB bin? XD Aber ja, feblue hat gut formuliert :bg:

DeXteur 🧐 heute um 02:14 Uhr
Ich denke deine Sicht der Dinge ist nochmal eine andere, da du selbst ja schon verschiedenste Erfahrungen in anderen Wikis und hier gemacht hast, vergessen will ich dich keines Falls :P

Heißt das dann, dass du feblue in seiner Sicht zustimmst?

Gruß * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 06:39, 2. Sep. 2020 (CEST)

Die Beiträge der letzten Tage erzeugen bei mir den Gesamteindruck, dass grundsätzlich eine überwiegende Zufriedenheit mit der Rechtestruktur vorliegt, weshalb Mec auch bereits von seinem ursprünglichen Vorhaben, die Redakteure zu streichen, abgekommen ist (siehe sein letzter Beitrag). Jedoch zeigt sich mir hier ein ganz anderes Problem: Die einzelnen Ränge sind wenig bis gar nicht definiert, sodass es vielen schwer fällt einzuschätzen, was bestimmte Ränge ausmacht. Daran anschließend ist es natürlich sowohl in den höheren Rängen problematisch Beförderungen durchzuführen als auch in den niedrigeren Rängen einzuschätzen, was einem zum Aufsteigen noch fehlt. Unter dieser allgemeinen Unsicherheit leidet natürlich auch die Bereitschaft, geeignete Benutzer für neue Ränge vorzuschlagen, da man sich unsicher ist, ob man selbst überhaupt richtig liegt mit seiner Einschätzung.

Für mich haben sich dadurch in dieser Diskussion – die zum Teil auch parallel bei Discord an verschiedenen Stellen weitergeführt wurde – fünf (große) Themenbereiche aufgetan (die Reihenfolge ist willkürlich):

1. Wahlen: Für Redakteure und/oder verlässliche Benutzer?
2. Definition der einzelnen Rechtestufen sowie deren Übergang
3. Ein Mentorensystem
4. Wertschätzung
5. Förderung qualitativer Mitarbeit

Aus meiner Sicht wäre es sinnvoll zu 1. hier weiter zu diskutieren und zu den anderen Punkten wieder mit Unterseiten zu arbeiten, wie wir es bereits bzgl. des Teamworks oder der Hauptseite in der Vergangenheit gehandhabt haben. Dann kann an allen vier Punkten parallel (oder auch nacheinander – mir egal) und ganz transparent darüber diskutiert werden, ganz unabhängig vom Rang eines Benutzers. So kann sich jeder bei den Themen einbringen, der es möchte. Sollten sich dann Ergebnisse bzw. Vorschläge abzeichnen, könnte man sie schlussendlich durch ne Abstimmung als Gemeinschaft absegnen.

Ich bin mir zwar unsicher, wie ihr die Sache seht, aber ich fände das sehr interessant und lohnenswert in diese Baustellen Zeit zu investieren. ~ Taisuke ^Diskussion 12:08, 2. Sep. 2020 (CEST)

Ich weiss nicht, ob es direkt Unterseiten sein müssen, aber ich teile Tais Meinung, das das Ganze hier etwas zu gross für alles in einem Abschnitt geworden ist, und bin ebenfalls der Meinung, das hier am Besten nur noch zu 1. weiter diskutiert wird. Für die anderen Sachen wären zumindest eigene Abschnitte sinnvoll. --Datei:Sugimori 672.pngMecanno-man^Mäh 13:12, 2. Sep. 2020 (CEST)

Ich finde Taisukes Vorschlag super. Ich würde dazu vorschlagen, dass wir die Themen nacheinander durchsprechen. Nur so kann man allen Konversationen folgen und muss nicht für alles gleichzeitig Ideen sammeln. Von mir aus ginge auch die Reihenfolge, die vorgegeben wurde. Eigene Abschnitte für die Themen finde ich sehr sinnvoll, da sie sichtbar getrennt sein müssen, damit wir nicht am Ziel vorbeischießen. -- Feblue 01:37, 3. Sep. 2020 (CEST)

Erstmal zu Max' Beitrag und seinem Ränge-Konzept:

• Beim SB-Rang muss mMn Quantität mit reinspielen, da sonst, wie Mec schon zum Teil angesprochen hat, Leute mit Vorwissen an sich direkt SB werden können müssten und der Rang z. T. auf Lebenszeit wäre (wenn man davon ausgeht, dass Leute nicht die grundlegenden Funktionen vergessen).
• Zum VB-Rang schreibe ich unten noch was.
• PL sollte mMn keine eigene Stufe werden, damit so wenig wie möglich bei-Bedarf-Stufen existieren (da ist z. B. ein Argument, dass ansonsten Projekte mit ausreichender Leitungsbesetzung unattraktiver wären, da die PL-Stufe und damit in dem Konzept Rang-Aufstieg, dann schwieriger zu erreichen wäre).
• Zum Red-Rang habe ich bereits etwas bei den verfrachteten Discord-Nachrichten geschrieben (siehe die erste Nachricht von dem User mit dem schicken Monokel im Namen).

Dann zu Mecs Frage mit den zwei Wahl-Konzepten: Die Red-Wahlen wurden hier doch bisher mehrmals als mit allen ESBs umsetzbarer angesehen. Ich sehe also keinen Grund die abzuschaffen. Zu VB-Wahlen gleich noch mehr.

Tai stimme ich zu. Unterseiten mit einzubeziehen hört sich auch gut an, sonst haben wir am Ende gleich mehrere derbe lange Diskussionen (wie die hier).

Nun zu den VB-Wahlen: Mecs Einschätzung, dass Max' Vorschlag bei der Bestimmung nichts ändern würde stimme ich nicht zu. Der Unterschied ist da zwischen Zustimmungslösung (aktuelle Situation) und Widerspruchslösung (Max' Vorschlag). Die Widerspruchslösung hätte das Potenzial mehr VB-Ernennungen zu ermöglichen, weil dann keine Ablehnungen nötig wären (etwas passives), anstelle von Zustimmungen (etwas aktives). Dem steht aber im Weg, dass ein Admin den VB-Rang vergeben muss, also ist bei einer Person immer ein aktiver Aspekt dabei. Wir haben also zwei Versionen im Raum stehen:

• Die Zustimmungslösungs-Variante: Da würde ein bestimmter Userkreis, der noch geklärt werden muss (siehe Lucas Nachricht und meine Reaktion darauf), eine öffentliche Wahl nach Vorbild der Red-Wahlen abhalten.
• Die Widerspruchslösungs-Variante (da bringe ich auch noch einen Vorschlag meinerseits in Max' Konzept ein): Da könnten PLs für ihr Projekt einen SB vorschlagen und Admins und andere PL(s) in dem Projekt können ihr Veto einlegen, und Admins können wikiübergreifend SBs vorschlagen und die anderen Admins und der oder die jew. PLs können ein Veto einlegen.

Ich halte das Konzept der Widerspruchslösung für sehr interessant. Das steht und fällt aber letztendlich wie gut das nach dem Widerspruchskonzept umgesetzt werden würde. Dabei wäre auf jeden Fall eine Zeitbegrenzung fürs Widersprechen notwendig, aber was wenn jemand von den Beteiligten grad z. B. im Urlaub ist? Würde man warten, wäre das wieder in Richtung Zustimmungsprinzip, aber die Person kann auch nicht einfach ignoriert werden.--DeXter 14:42, 3. Sep. 2020 (CEST)

Ungeachtet dessen, das ich immer noch nicht verstehe, wo der Unterschied zwischen zustimmen und nicht widersprechen liegt (abgesehen davon das ersteres transparenter ist), insb. wenn für Zweiteres alle möglichen Abstimmenden beachtet werden sollte, finde ich es leicht problematisch hier bestimmte Projektleiter einzubinden. Wenn man das nämlich tut müssten tatsächlich Projektmitgliedschaften irgendwelche formale Strukturen gegeben werden, damit entschieden werden kann, welche Projektleiter da abstimmen können und welche nicht, denn wie wird ansonsten zugeordnet, in welchen Projekten der Benutzer „aktiv“ ist? Und wenn man das macht, dann haben wir hier einen bürokratischen Papierkrieg über Projektmitgliedsschaften, was auf jeden Fall vermieden werden soll. Auch wenn ich immer noch gegen das Veto-System bin: Wenn es eingeführt wird, sollen doch bitte wenigstens alle Projektleiter ein Vetorecht haben. --Datei:Sugimori 672.pngMecanno-man^Mäh 14:59, 3. Sep. 2020 (CEST)

Ich möchte gerne DeXters Vorschlag erweitern (sofern ich ihn denn richtig verstanden habe) und auf Mecs letzte Idee eingehen. Anstatt nur bestimmte Projektleiter für die Wahl eines VBs zuzulassen, dürfen alle Nutzer ab PL bei einer VB-Wahl abstimmen. Warum genau diese Grenze? Nun, die Projektleiter haben auf ihren Bereich sowieso ein Auge und bemerken dabei, dass sich der ein oder andere SB für die Wahl eignet, weil er konstant mitarbeitet, wenig bis keine Fehler zulässt usw. Dann setzen sich die Benutzergruppen ab PL zusammen und tauschen Eindrücke aus. Die Stimmen der Projektleiter, in deren Projekt der SB sehr offensichtlich mitarbeitet, können auch gesondert betrachtet werden, weil sie den SB eh länger beobachten, weil sie ja patrolen müssen / sollten. Auch wenn viele SBs nicht in allen Projekten aktiv sind, denke ich trotzdem, dass alle anderen Projektleiter auch dazu in der Lage sind, ein Urteil über einen SB fällen zu können. -- Feblue 01:24, 14. Sep. 2020 (CEST)

Unabhängig der Wahlart würde ich nicht einfach alle PLs in den Wählerkreis nehmen. Oft können nicht-PLs sich ebenfalls ein ganz gutes oder besseres Bild von einem SB bilden, da diese z. B. mit dem Kandidaten immer wieder mal zusammenarbeiten o. ä. Dass alle PLs sich ein Urteil über einen SB bilden können, kann ich nicht wirklich zustimmen. Von Usern z. B. im Strategie- oder Manga-Projekt kann ich nur grob Edit-Menge, -Art (z. B. Fließtexe, Vorlagen, usw.), Edit-Größen und allgemeines Bild des Users zum Einschätzen nehmen. Letztendlich habe ich bei manchen Projekten keine Ahnung wie die Mitarbeit da aussieht.

Daher bin ich weiterhin dafür zu versuchen alle "relevanten", "betroffenen" ESBs für so eine Wahl zu nehmen. Da muss ich Mec aber auch zustimmen, dass das sehr schwammige Vorgaben sind und das in einem Papierkrieg enden könnte. Das hängt aber auch davon ab, wie ernst die die Sache behandelt wird. Natürlich sollte die VB-Ernennung nicht zu locker genommen werden, aber pro Wahl einfach zu schauen wer Lust hat mitzuwählen und ein gutes Bild vom User haben kann ohne viel Bürokratiekrieg drum rum sehe ich immernoch als eine Möglichkeit an.

Besonders die für die Wahl in Frage kommenden Leute hätten ja außerdem ein Interesse an der VB-Ernennung, was eine gute Wahlbeteiligung fördern könnte. Aus letzterem kam mir grade auch die Idee, dass bei VB-Ernennungen z. B. in einem gewissen Zeitraum jeder ESB mitmachen kann der will und im letzten Abschnitt dann keiner mehr dazu kann und es unter den jew. Leuten diskutiert und abgestimmt wird. Das wäre eine Idee, ein Konzept mit schwammigen Vorgaben wobei das nicht unbedingt negativ sein muss. Die Idee ist aber eher für das Zustimmungskonzept geeignet, da beim Widerspruchskonzept eigtl. für die Wahl ungeeignete Leute teilnehmen könnten nur um den Kandidaten an der erfolgreichen Wahl zu hindern. Da wäre aber wieder die Sache, dass ich so ein Verhalten nicht von einem ESB erwarte. --DeXter 22:17, 14. Sep. 2020 (CEST)

Ich hab das Gefühl, es wird hier versucht das Red neu zu erfinden, mit dem Ergebnis das Sachen überbürokratisch enden würden wenn dem weiter freien Lauf gelassen wird. Das System der Wahl sollte halbwegs einfach zu verstehen sein, damit neue User verstehen wie das ganze abläuft; VB ist schliesslich der Rang über dem SB, da irgendwelche Projektleiter einzubeziehen/auszuschliessen halte ich allein schon dahingehend nicht sinnvoll. Weiter dürften Projektleiter wissen, ob sie ihrer eigenen Meinung nach einen User beurteilen können; wer dies nicht kann enthält sich einfach, Problem gelöst. Das ganze auf Projektleiter-Ebene zu stellen ist für mich weiter insofern fragwürdig, da so nicht-PL ESBs bei VB-Wahlen nicht abstimmen dürften, bei Redakteurswahlen aber schon, obwohl Redakteur der höhere Rang ist. Bezüglich dem Anmelden zum diskutieren: Ich verstehe nicht ganz, wo da eine Diskussion herkommt, das Ding ist ne Wahl; der Sinn einer Wahl besteht nicht daraus einen Konsens zu schaffen, sondern zu schauen ob eine Mehrheit erreicht wird. Ich wäre an dieser Stelle einfach dafür, die Wahl nahezu identisch wie die Redakteurs-Wahl zu machen, mit dem Zusatz das die Veteranen sich selbst vorschlagen dürfen.

Übrigens, ich wäre froh, wenn hier nicht nur drei Leute über so eine grundlegende Änderung diskutieren würden; deshalb hier einfach mal ein Ping an alle VBs: Buoysel, Cliffichen, CLina, DeXter, GoPika, GrollenKette951, Impoleon xy, Isso08-15, Kenaz-Hagalaz, Lombrero, Luca12379, Matze, Mecanno-man, RobbiRobb, Ryuichi, ShortyBuzz, Simonsees, SwowoJonny, Taisuke --Datei:Sugimori 672.pngMecanno-man^Mäh 22:45, 14. Sep. 2020 (CEST)

Okay, das mit den Redakteur-Wahlen hatte ich gestern nicht auf dem Schirm. Nach Mecs Vorschlag habe ich lange überlegt, ob man das Wahlsystem der Reds für VB-Wahlen nicht vereinfachen könnte. Ich weiß nicht, ob ihr diesen Eindruck teilen könnt, aber die Red-Wahlen kommen mir so vor, als ob ein riesiges Fass dafür aufgemacht wird. Das sollte mMn zumindest für die VB-Wahl vereinfacht werden. Da wäre es schon passend, die Wahlrunde der Admins rauszulassen. Feblue 01:16, 15. Sep. 2020 (CEST)

Ehrlich gesagt, habe ich hier den Überblick verloren und momentan keine Zeit, mich mit einer langwierigen Grundsatzdiskussion zu beschäftigen. Macht wie die Mehrheit entscheidet, ich werd mich nicht beschweren. Ob ich Red heiße oder sonst was ist mir wurscht, ich würde meine Rechte wie bisher gerne behalten, das ist alles. Und wie wer wann wo gewählt wird oder wählt kann ich jetzt nicht mitentscheiden. - - "I'm gonna swing from the chandelier" GoPika ^Disku 07:20, 15. Sep. 2020 (CEST)

Ich habe kein großes Problem mit dem jetzigen System und bei dieser Diskussion verliere ich den Faden. Sorry. Das Isso 08/15 ^Konter 14:34, 15. Sep. 2020 (CEST)

Ähh... hat jemand den roten Faden gesehen? Jetzt aber mal ehrlich, ich kann hier eindeutig verstehen warum GoPika und Isso08-15 hier nicht mehr groß an der Diskussion teilnehmen können oder wollen. Diese ganze Diskussion ist mittlerweile so aufgebläht über die letzten Wochen und sollte eigentlich mal langsam bisschen ausklamüsert werden. Jetzt aber erstmal genug davon und zum eigentlichen Text:

Da die Anfangsidee, den Red zu streichen mittlerweile verworfen wurden ist, müsste ich hierzu meine Meinung eigentlich nicht mehr äußern. (tldr: Red behalten; WM, ÄWM und anderen Auszeichnungen sind kein Ersatzt für das „Er/Sie wurde von der Community gewählt“)

„Frühere und rechtzeitige (!) Wahlen würden mehr Feedback bzw. Kritik hervorbringen [...]“

– Taisuke 15:52, 25. Aug. 2020 (CEST)

Das ist meiner Meinung nach der wichtigste Punkt zum Theme Red-Wahlen. Diese sollten bereits dann abgehalten werden, wenn der Benutzer in Frage nicht schon Monate lang über der „Grenze“ zum Red drüber ist, sondern dann, wenn dieser in die Nähe des Niveaus der anderen Reds kommt; dies würde dafür sorgen, dass dieser VB/PL neben Auszeichnungten und ähnlichem nochmal ein größeres Feedback vom „inneren“ Team bekommt.

So nun zum Thema der VB-Wahlen: Ich finde die Idee grundsätzlich gut, da es somit nicht zu Szenarien kommt sollte, in denen es dann heißt „Hat leider ein bisschen gedauert, es fehlte noch eine Meinung, deswegen jetzt erst der VB“ (sinngemäß aus den Discord-PNs mit Mec übernommen). Solche Situationen, in denen es genau an einer Meinung hängt, sollten eigentlich durch ein Wahlsystem verhindert werden können. Zusätzlich erhält der Kandidat ebenfall ein Feedback zu dem was er bisher gemacht hat. So nun zu einem kritischen Punkt zu dem Thema: Wer soll dort wählen und in welcher Form? Meiner Meinung nach ist der Ausschluss der VBs keine Option, da diese nochmal einen anderen Sichtpunkt auf die Situation haben, als Pls, Reds und Admins. In welcher Form diese Abstimmung (Zustimmung, Ablehnung, anderes) weiß ich an dieser Stelle ehrlichweise nicht wirklich.

Zum Thema Mentorensystem hatte ich mich schonmal auf Discord geäußert:

„Vielleicht liegt das nur an meinem Projekt, aber ich kann mir zu mindestens für meins kaum ein Mentorensystem vorstellen. Mehr Text wenn ich auf meinen Platz sitze. [...] Gegen ein Mentorensystem habe ich grundsätzlich nichts. Jedoch sehe ich, da ich auf anderen Discordserver, auf denen sich häufiger über fehlende oder veraltet Informationen beschwert wird, Leute zum Mitarbeiten zwinge motivieren und da bis jetzt nicht all zu gute Erfahrungen habe (von 5 Leuten ist bis jetzt keiner aktiv geworden/geblieben; heute Abend ist der nächste Versuch), das Problem, dass entweder niemand will, Lust und/oder Zeit hat oder sich schlichtweg niemand findet der zu etwas bereit ist. Die Argumentation "Weniger Zeit" kann ich auch verstehen wenn ich sehe, dass das Attackenprojekt momentan ein ganzes Stück hinterher ist. Vielleicht kann das Mentorensystem aber auch bewirken, dass diese PLs dann dadurch Wikinger oder SBs haben denen sie, ähnlich wie einem VB "blind" vetrauen können.“

– GrollenKette951; 02.09.2020 10:57 bis 11:06 CEST

Hier jetzt auch nochmal einen Nachtrag: Sicherlich kann es zeitaufwändig werden Benutzern dauerhaft zur Seite zu stehen, jedoch könnte sich das lohnen, da man so eigentlich sich sehr schnell eine Person „heranziehen“ kann der man fast bedingungslos vertrauen kann.

Bezüglich irgendwelchen Punktesystemen: Ich finde das großen Schwachsinn, da ein solches System eher die Leute dazu bringt mehr auf Quantität als auf Qualität zu gehen (genau das was jeztzt auch schon mit dem Edit-Auszeichnungen abgeht).

Definition der Rechtestufen: Hier wäre es sicherlich sinnvoll genaue Angaben zu machen, da Formulierungen wie „die sie als „verlässlich“ ansehen“ einfach viel zu schwammig sind, selbes auch bei den Reds. Denn diese schwammigen Formulierungen sorgen dazu, dass ein aktiver SB kein klares Leistungsziel für den VB vor Augen hat, auf das er zu arbeiten kann. Beim SB sind es ja immerhin die 100+ Edits.

Ich hoffe ich habe jetzt nichts aus dieser ellenlangen Diskussion vergessen anzusprechen, wenn dem doch so sein sollte sagt mir bescheid. GrollenKette951 17:14, 17. Sep. 2020 (CEST)

Ein kurzer Einwurf von mir:(doch nicht nur ein Einwurf) Ich glaube es bestand nach Tais Nachricht ein Konsens, dass die Diskussion aufgesplittet werden soll in die folgenden Punkte:

1. Wahlen: Für Redakteure und/oder verlässliche Benutzer?
2. Definition der einzelnen Rechtestufen sowie deren Übergang
3. Ein Mentorensystem
4. Wertschätzung
5. Förderung qualitativer Mitarbeit

Hier geht es grad aktuell meines Wissens nach nur um die Red- und VB-Wahlen, der Rest soll separat behandelt werden. Dazu wird aktuell vor allem die Hauptfrage diskutiert aus wem sich der Wählerkreis der VB-Wahlen zusammensetzen soll. Außerdem steht auch noch die Idee einer Widerspruchslösung für die VB-Wahlen (eine berechtigte Person schlägt wen vor, wenn kein Veto von bestimmten Personen, dann Rang-Erhöhung) im Raum.

Ich bin inzwischen eher auf Mecs Seite. Also, dass alle ESBs an den VB-Wahlen (per klassischer Zustimmungslösung) teilnehmen und man eine unter Umständen verglichen niedrige Wahlbeteiligung in Kauf nimmt. Ist am einfachsten, transparent und in Gewissem Sinne flexibel. Dabei wäre es mMn aber auch wichtig, dass bei den Wahlen nicht einfach Signaturen gesetzt werden oder nach einmal die Benutzeredits ansehen ein "sieht gut aus" kommt, sondern lieber mehrere Enthaltungen kommen und die Stimmen dann aus durchdachtem Feedback bestehen. Allerdings müsste die verhältnismäßig hohe Menge an Enthaltungen auch als normal angesehen werden.--DeXter 17:59, 17. Sep. 2020 (CEST)

Ich weiß, dass es eigentlich der Plan war die ganze Diskussion aufzusplittern, jedoch ist seitdem nichts in dieser Richtung passiert, deswegen hatte ich jetzt einfach erstmal einen Text zu allen Themen, die hier schonmal gefallen sind, geschrieben. GrollenKette951 19:24, 17. Sep. 2020 (CEST)

Wir hatten weiter oben besprochen, dass es vielleicht sinnvoll wäre, die Punkte einzeln abzuklappern, daher ist hier bisher zu den anderen Themen nichts passiert. Da DeXters Vorschlag wie ich finde legitim ist, können wir auch gerne mit Punkt 2 fortfahren, wenn denn hier nichts mehr beigetragen wird. Ich gehe davon aus, dass folgendes das Endresultat ist: Der Redakteur und sein Grundgerüst bleiben bestehen. Neu hinzu kommen VB-Wahlen mit Wahlbeteiligung aller ESBs. Dabei ist zu beachten, dass nicht nur eine Signatur gesetzt wird, sondern genauer hingeschaut wird. -- Feblue 23:25, 17. Sep. 2020 (CEST)

Es ist definitiv zu früh, das VB-Wahl-Thema hier als abgeschlossen zu betrachten; es haben sich nach wie vor nur eine Minderheit der aktiven Nutzer für oder gegen Wahlen ausgesprochen, und wer abstimmen darf innerhalb von 5 Stunden zu festigen scheint mir auch, als würden sich da Leute im Nachhinein beklagen, das sie nicht zu Wort gekommen sind. Wenn sich hier wieder eine Weile nichts mehr tut werde ich ne Abstimmung starten, aber bevor die durch ist (oder sich hier plötzlich ne Menge User, die noch nix zum ganzen gesagt haben, plötzlich alle für dasselbe aussprechen und niemand dagegen) ist für mich das Thema noch nicht gegessen. --Datei:Sugimori 672.pngMecanno-man^Mäh 00:14, 18. Sep. 2020 (CEST)

Ich verfolge das Thema seit einer Weile kaum noch. Der Abschnitt ist dermaßig aufgebläht von verschiedenen Themem, Vorschlägen usw. Und ehrlich, das Thema haben wir seitens Mec zum X-ten mal ohne das sich hier etwas verändert hat. Wem meine Ansicht interessiert kann sich gerne durch die Archive wühlen. Da sich meine Meinung hier nicht geändert hat. Ich kann bei VB mit wahlen wie auch mit dem bisherigen Verfahren leben. Gruß * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 18:23, 18. Sep. 2020 (CEST)

VB-Wahlen sind an sich erstmal ein gutes Konzept. Es ist demokratischer, dadurch automatisch interaktiver und ggf. motivierender. Ich habe nur die Befürchtung, dass in vielen Fällen persönliche Sympathien und Antipathien über die Ergebnisse dieser Wahlen entscheiden werden, anstelle einer ehrlichen Einschätzung von Eignung und Leistung der zur Wahl stehenden Kandidaten durch die Wahlberechtigten. Doch könnte man dagegenhalten, dass die Redakteurswahl ja scheinbar auch ziemlich gut funktioniert. Deshalb möchte ich weder dagegen noch dafür sein. Wir müssten bei einem Pro für VB-Wahlen aber das System vorher sehr gut bedacht festschreiben: Stimmberechtigung, Empfehlungsberechtigung, genaues Wahlsystem (wie die Red-Wahl oder anders?), usw.
Ein Mentorenprogramm halte ich in der aktuellen Lage für langfristig nicht lebensfähig. Weil es sehr viel Zeit und Energie verschlingen kann, Menschen auszubilden und ich nicht sehe, dass wir diese Kapazitäten haben oder in naher Zukunft bekommen werden. Selbst wenn sich Leute dafür finden, die das demnächst durchziehen würden, frage ich mich halt, ob die das in einem halben Jahr auch noch tun werden und ob die Ergebnisse den Aufwand rechtfertigen. -MfG, Kenaz-Hagalaz ^Disku 19:15, 18. Sep. 2020 (CEST)

Das wichtigste Unterthema, nämlich die Wertschätzung vor allem von neuen Usern, ist über diese ganzen Detaildiskussionen völlig in den Hintergrund getreten. Alles waren ja nur Ideen, um dieses Thema anzugehen. Letztendlich ist es egal, mit welchen Methoden man das angeht, es muss kein Mentorenprogramm sein. Mein Aufruf geht nur in die Richtung, das zugegebenermaßen heikelste, aber gewinnbringendste Unterthema nicht über die wenig relevanten Themen aus dem Blick zu verlieren. Maxmiran 12:38, 19. Sep. 2020 (CEST)

Bei „Umgestaltung der Rechtesruktur“ denkt man halt eher an organisationstechnische Dinge und wenn man so viele Ideen und Nebenthemen in den Ring wirft, dann kann so ein Abschweifen schon mal vorkommen. Vlt. liegen aber auch die Foci, der jeweiligen Dialogpartner in Teilen schlicht woanders. Wenn wir wirklich nur eine Sache besprechen wollen, müssten wir diesen Behemoth, den eh kaum einer komplett lesen wird, beenden und die Themen jeweils einzeln in neuen Abschnitten besprechen. -MfG, Kenaz-Hagalaz ^Disku 21:38, 19. Sep. 2020 (CEST)

So, Zeit sich hier auch mal zu Wort zu melden. Wer aufmerksam war, sollte mitbekommen haben, dass ich mich bislang noch nicht gemeldet hatte. Das hat vor allem den Hintergrund, dass ich bei der ursprünglichen Thematik, der Abschaffung des Redakteurs-Rangs, zunächst abwarten wollte, wie die aktuellen und potenziellen Redakteure dazu stehen. Vielen sollte es bereits aus der Vergangenheit bekannt sein, aber ich vertrete auch weiterhin die Meinung, dass diese Rechtestufe sinnvoll ist, sowohl als Zwischenschritt zwischen einem Verlässlichen Benutzer und einem Administrator, als auch generell bis zu einem gewissen Grad als Belohnung für die anhaltende und qualitative Arbeit. Da ich aber nicht einfach von oben herab meine Meinung kund tun wollte, hatte ich zunächst abgewartet um zu sehen, wie die betroffenen Benutzer auf den Änderungs-Vorschlag reagieren - hätte das ganze allgemeinen Anklang gefunden, hätte es für mich keinen Grund gegeben, den Erhalt der Gruppe zu unterstützen, wenn diejenigen, die ihn bekleiden (könnten) ihn sowieso nicht wollen. Nachdem sich dann aber doch eine große Mehrheit für den Erhalt ausgesprochen hat und Mec letztendlich seinen Vorschlag zurückgezogen hat, gab es dann irgendwie erst mal auch keinen Grund mehr, direkt noch etwas dazu zu sagen. Und während ich dann im Urlaub war, hat sich hier dann wieder einiges getan.
Und zwar ist diese Diskussion noch weiter als im Vorfeld bereits schon abgedriftet in viele kleinere Themen, die deutlich mehr Aufmerksamkeit bekommen haben als das eigentliche Thema, nämlich die Frage nach der Umgestaltung der Rechtestruktur. Da sind wir inzwischen an dem Punkt, dass sich einige Benutzer Wahlen für Verlässliche Benutzer wünschen, was ich für eine interessante Idee halte. Stimmberechtigte Benutzer werden nach einfachen klaren Regeln eingesetzt, Redakteure werden durch Erweitert Stimmberechtigte Benutzer gewählt und Administratoren nach bedarf vergeben, wobei dort die Administration stets einstimmig entscheided, ob jemand ins Team aufgenommen wird oder nicht. Verlässliche Benutzer werden allerdings stets von oben herab entschieden, einzig durch die Administratoren (und gegebenefalls Redakteure, wenn sich die Admins nicht einig werden), wobei der beförderte Benutzer nicht mal eine Wahl hat, ob er zum Verlässlichen Benutzer ernannt wird oder nicht. Und es scheint mir in der Tat etwas komisch, dass eine niedrigere Rechtestufe von oben bestimmt wird während eine höhere von unten gewählt wird. Die Idee Verlässliche Benutzer ebenfalls von einem größeren Spektrum Benutzern zu wählen klingt daher durchaus verlockend, birgt allerdings auch einige Risiken, die nicht unterschätzt werden sollten:
Zum einen natürlich die offensichtlichste Frage: Können alle Verlässlichen Benutzer andere ausreichend einschätzen, um ein entsprechendes, objektives Urteil zu fällen? Wie groß ist die Gefahr, dass sie einen Benutzer einfach nur abnicken, ohne sich großartig mit diesem und seinen Beiträgen auseinander setzen? Was ist mit jemandem, der selber gerade neu zum Verlässlichen Benutzer gewählt wurde, wird dieser wissen, wie er damit umzugehen hat, vielleicht sogar von sich aus nicht an der Wahl teilnehmen, weil er denkt, dass eine faire Einschätzung nicht möglich ist? Oder wird das ganze dann einfach von Pro-Stimmen überflutet, wobei sich am Ende herausstellt, dass es eine Fehlentscheidung war.
Damit einher geht natürlich auch die Frage, ob Benutzer ausschließlich objektiv gewählt werden oder ob sich auch subjektive Meinungen dabei mit einschleichen und über Sympathien oder Antipathien entschieden wird. Verstärkt könnte letzteres vor allem durch den PokéWiki-Discord-Server sein, auf dem sich die Benuter aller Rechtegruppen untereinander austauschen können und an vielen Stellen Freundschaften entstehen, die das Wahl-Ergebnis beeinflussen könnten. Als der Server noch kleiner war oder überhaupt gar nicht erst existierte war das im Normalfall kein Problem, eine Kommunikation mit dem Team enstand hauptsächlich, wenn jemand sich aktiv beteiligte, heute kann es auch anders herum passieren, dass jemand, der sich auf Discord etabliert hat, im Wiki anfängt dann einen deutlich besseren Start dort haben könnte.
Fraglich ist aber natürlich, wie viel davon jetzt bereits mit in die Wahlen einfließt, sei es bewusst oder unbewusst. Ich bin da ziemlich sicher, dass es niemals möglich ist, alle diese Sorgen gänzlich zu unterbinden und denke auch, dass es durchaus sinnvoll sein kann, so manches davon bewusst zu beachten. Die Herausforderung ist es halt einfach einen Punkt zu finden, bei dem ein gesundes Ergebnis bei rum kommt. Und ob wirklich alle Verlässlichen Benutzer immer in der Lage sein werden, diesen Punkt zu finden, halte ich für fragwürdig. Denn während ich zwar auch der Meinung bin, dass wir in der Vergabe der Rechte zu hart geworden sind, möchte ich jetzt keine Drehung machen und vollständig in die entgegengesetzte Richtung gehen und im schlimmsten Fall das ganze viel zu niedrig ansetzen, wodurch Benutzer die erweiterten Rechte erhalten würden, die sie entweder nicht verdient hätten oder nicht in der Lage sind, mit ihnen umzugehen.
Um diesen Problemen aus dem Weg zu gehen oder ihnen entgegen zu wirken, brauchen wir natürlich Lösungen, die wahrscheinlich entweder in der Form von Beschränkungen oder Empfehlungen ausfallen. Während ich das ganze natürlich so offen und frei wie möglich halten würde, fürchte ich allerdings schon, dass wir um Einschränkungen nicht gänzlich herum kommen werden. Bin mir dabei nicht ganz sicher, ob es weiter oben bereits niedergeschrieben wurde, aber es stand auf jeden Fall die Idee im Raum, dass nur die jeweiligen Projektleiter, in deren Bereich der zur Wahl stehende Benutzer aktiv ist, neben den (Redakteuren und) Admins abstimmen dürfen, wobei das natürlich das Problem mit sich bringen würde, dass der Kreis der Wähler nicht nennenswert größer wird, während dafür allerdings die Meinungen um so aussagekräftiger sind, weil sie eben von jemandem stammen, der die Beiträge des Benutzers stets kontrolliert.
Der einfachste Gedanke ist natürlich, dies zu nutzen und anderen Benutzern gleichzeitig die Möglichkeit zu geben, sich ebenfalls zu beteiligen, indem man die besagten PLs dazu verpflichtet, an der Wahl teilzunehmen, während andere Benutzer ihre Meinung ebenfalls teilen können, die Wahl aber nicht beeinflussen, wenn sie nicht abstimmen. Ob das jetzt die Lösung schlechthin ist, ob es nicht vielleicht doch besser wäre, den Kreis der Abstimmenden vergleichsweise klein zu halten, ich weiß es nicht. Es wird sicherlich auch noch weitere Lösungen geben, vielleicht sogar welche, die einen besseren Effekt erzielen; Transparenz gewährleisten während man sich trotzdem keine Sorgen machen muss, dass das Ergebnis die Meinungen spaltet.
Dahingehend habe ich ohnehin noch einige offene Fragen, zunächst ein mal, wie genau die Wahl überhaupt ausfallen soll. Im Moment haben wir bei den Redakteurs-Wahlen eine erste Runde, bei der sich die Admins für oder gegen einen Kandidaten aussprechen und damit die Wahl direkt beenden oder autorisieren, wobei eigentlich in der zweiten Wahlrunde lediglich allgemein bestätigt wird, dass ein Kandidat den Posten verdient hat, dass jemand dort noch abgelehnt wurde, ist glaube ich noch nicht vorgekommen (geprüft hab ichs jetzt aber nicht). Stellt sich also die Frage, ob das ein Konzept ist, dass man so übernehmen kann, oder ob es vielleicht besser wäre, hier den Admins die selbe Stimmmacht zu geben wie allen anderen Benutzer, die dann die Berechtigung haben, sich an der Wahl zu beteiligen. Im gleichen Zuge stellt sich natürlich auch die Frage, ob die Admins überhaupt bereit sind, ihre Macht aus der Hand zu geben, denn während ich natürlich grundsätzlich bereit bin, auf den allgemeinen Willen der Community zu hören und diesem nach Möglichkeit zu folgen, so möchte ich persönlich schon ein gewisses Veto-Recht als (zweit-)höchste Instanz des Wikis behalten, vor allem wenn es um die Rechtevergabe geht. Natürlich bleibt uns das erhalten, weil niemand außer Admins Verlässliche Benutzer ernennen kann, aber Rechte zur Unterdrückung von Entscheidungen zu nutzen möchte ich eigentlich gerne vermeiden, mir wäre es dort also wichtig, tatsächlich in der Regelung einen Weg zu haben, eine Wahl zu stoppen, wenn sich die Administration einig ist, dass es die falsche Entscheidung für das Wiki wäre, diesen Benutzer zu befördern. Wie genau das ganze dann ausfällt, ob direkt im Wahlprozess oder außenstehend, das sei an dieser Stelle erst mal dahingestellt, aber ich möchte zumindest darauf aufmerksam machen, dass der Wunsch von meiner Seite besteht.
Zusätzlich ist auch noch die Frage, wer alles das Recht hat, jemanden vorzuschlagen - und wen. Ich hatte den Vorschlag gesehen, dass Verlässliche Benutzer andere Stimmberechtigte Benutzer vorschlagen können und zusätzlich Veteranen, die gleichzeitig auch stimmberechtigt sind, sich selbst vorschlagen können, wenn sie der Meinung sind, dass sie wieder aktiv genug sind und sich ausreichend mit den aktuellen Themen auseinandergesetzt haben, um sich aktiv an Diskussionen zu beteiligen. Dabei wäre ich zunächst ein mal dagegen, dass Stimmberechtigte Benutzer direkt andere Stimmberechtigte Benutzer vorschlagen können, da dieser Rang extrem schnell erreicht werden kann und dieses System so einfach manipuliert werden könnte. Gleichzeitig denke ich aber schon, dass es durchaus vorstellbar ist, dass ein Stimmberechtigter Benutzer einen vernünftigen Vorschlag einreichen könnte. Vielleicht wäre es hier eine Idee, dass ein Vorschlag stets begründet sein sollte, wobei die Begründung dann nicht nur daraus besteht, dass der Benutzer ja aktiv ist, sondern wesentlich konkreter ist, der Vorschlagende sich also mit den Beiträgen des Benutzers auseinandergesetzt hat, bevor er diesen vorschlägt. Ob es das dann bereits ermöglichen würde, auch Stimmberechtigten Benutzern zu erlauben andere vorzuschlagen, wird die weitere Diskussion zeigen. Selbstvorschläge möchte ich dann auf jeden Fall ausschließen, lediglich ehemalige mindestens Verlässliche Benutzer sollten dieses Recht haben. Andernfalls will jeder plötzlich Verlässlicher Benutzer werden ohne auch nur ansatzweise qualifiziert für diesen Posten zu haben und wir haben ganz viele abgelehnte Wahlen, die nicht nur Zeitverschwendung sind, sondern die abgelehnten Benutzer auch unnötig demotivieren. Und generell finde ich es sehr schön, wenn ein Benutzer von einem anderen vorgeschlagen werden muss, dass zeigt, dass jemand Leistungen erbracht haben, die jemand anderen auf diesen aufmerksam gemacht haben.
Damit soll es das dann jetzt aber erst mal von meiner Seite gewesen sein, ist jetzt doch ne ganze Menge geworden, passiert aber, wenn man sich halt erst so spät dazu äußert... Sorry. Die ganzen anderen Themen, die sonst noch angesprochen wurden, möchte ich dabei erst ein mal auslassen, zum einen ist der Text mehr als lang genug, zum anderen will ich die Diskussion aber nicht noch weiter zerstückeln. Sollte das ganze in eigene Abschnitte verteilt werden, werde ich mich dann dort zu Wort melden und meine Ideen und Gedanken teilen. -- RobbiRobb 00:20, 24. Sep. 2020 (CEST)

Da hier SB-beteiligung an Wahlen nun in den Ring geworfen wurde: Ich hab sehr viel Mühe damit, einem Rang, den man sich theoretisch an einem Nachmittag erarbeiten kann, überhaupt Entscheidungsmacht in personellen Angelegenheiten zu geben. Ich traue da schlicht nicht allen SBs zu, gut genug über sowohl die Erwartungen an einen VB als auch über den User, der vorgeschlagen ist, bescheid zu wissen. SBs nur Vorschläge machen zu lassen bietet zudem imo. Missbrauchspotenzial, was in der Vergangenheit bereits versucht wurde. (Für den Kontext, damals hatten Rollback?-Wahlen das System das jeder Wikinger vorschlagen durfte, die erste Wahlrunde besteht aus Admins und Projektkoordinatoren? und die zweite aus allen anderen SBs). Insgesamt bin ich gegen eine Einbindung von SBs in die Wahl; ebenso bin ich jedoch gegen eine Stimmpflicht für irgendwen ausserhalb der Admins - das PokéWiki ist ein Hobby, und da sollten die Verantwortungen so niedrig wie sinnvoll möglich gehalten werden. --Datei:Sugimori 672.pngMecanno-man^Mäh 02:44, 24. Sep. 2020 (CEST)

Ich finde Robbis Vorschlag zu der Stimmmacht der Admins sehr gut. Das Konzept wäre dann, dass ein SB (-veteran) von einer bestimmten Rechtestufe vorgeschlagen wird und anschließend sofort die Wahlrunde begonnen wird. Sollten sich die Admins einig sein, dass der vorgeschlagene Benutzer ungeeignet für den Rang ist, so haben sie immer noch ein Vetorecht, das sie ausüben können, indem alle drei Admins Contra stimmen.

Zum Vorschlag: Ich möchte Mec da gerne glauben, dass die Vorschläge seitens der SB nicht funktionieren. Von daher wäre ich dafür, dass Vorschläge ab VB oder vielleicht auch PL geregelt werden, weil PL vielleicht nochmal ein genaueres Auge auf bestimmte SB haben.

Zur Wahlrunde: So sehr ich Kenaz’ Vorschlag zur Wahlrunde mag, muss ich doch Mec und Robbi zustimmen, dass Sym- und Antipathien die Wahlen manipulieren könnten. Dann kann man aber auch als Regel hinzufügen, dass in der Wahlrunde der SBs konkrete Argumente aufgeführt werden müssen, warum man sich für seine gegebene Stimme entschieden hat. Sind die Argumente unzureichend oder schlicht nicht überzeugend, können Admins auch hier eingreifen und die einzelne Stimme oder gar den ganzen SB-Wahlkreis für diese Wahl ausschließen. —- Feblue 22:24, 24. Sep. 2020 (CEST)

Über die Begründungen anderer Abstimmenden zu entscheiden halte ich für eine schlechte Idee, denn das wirft nur die Frage auf, was eine gut begründete Begründung ist, und das wird für jeden anders sein, folglich werden solche Diskussionen sehr schnell auf persönlicher Ebene enden - was wir auf jeden Fall vermeiden sollten. Auch scheint es mir kontraproduktiv, nach der Stimmeinreichung die Meinung einer Person auszuschliessen; das kommt einfach nicht gut rüber egal wie man es dreht und wendet. Ich bin in diesem Sinne weiterhin dagegen, SBs abstimmen zu lassen. --Datei:Sugimori 672.pngMecanno-man^Mäh 23:54, 24. Sep. 2020 (CEST)

Eine andere Frage, die aufgekommen ist: Wie machen wir das mit VB-Wahlen und Projektleiterposten? Bisher konnten neue Projektleiter ja von Projektleitern zusammen mit den Admins einfach eingesetzt werden? Würden wir hier einfach sagen, Projektleiter können Nutzer ja vorschlagen, es kommt zur Wahl und wenn diese bestanden ist können Projektleiter den neuen VB wie beliebige andere VBs als Projektleiter einsetzen? Sollte in der Nominierung stehen, das die Person als Projektleiterkandidat gehandet wird; sollte dies nicht da stehen? (Ich tendiere zu ja, sollte) Hat jemand einen besseren Vorschlag, wie man damit in einem Wahlsystem umgeht? --Datei:Sugimori 672.pngMecanno-man^Mäh 01:27, 3. Okt. 2020 (CEST)

So jetzt auch mal meine Meinung hierzu. Dieses ganze Wahlkreissystem-Zeug finde ich eher kritisch, da mir dieses System doch recht fehleranfällig erscheint. Auch finde ich die Idee die SBs auch abstimmen zu lassen so eher naja. Diese Meinung kommt dadurch zustande, dass ich ehrlicherweise als ich noch SB war, nicht gewusst hätte, was einen guten VB ausmacht. Zusätzlich sehe ich einfach das Problem, dass der SB doch recht einfach an einem Nachmittag zu erlangen ist. Ich wäre eher dafür, die SBs aus der Wahl rauszulassen (auch wenn dann die 3 bis 4 richtig aktiven SBs, die es fast immer gibt, dadurch nicht abstimmen können). Bei der Aktivität der SBs sind wir gleich beim nächsten Punkt, was passiert in diesem System denn, wenn kein einziger SB abstimmen würde. Die Idee ein Vetorecht für die Admins in den Regeln zu verankern, sehe ich nicht kritisch, solange diese Regel nur bei Begründeden Zweifeln am VB-Kandidat benutzt wird. Zu dem möglichen PL-Problem: Sollte ein Nutzer, der noch nicht VB ist, zum PL vorgeschlagen werden, sollte dieser doch eigentlich in den Augen der Admins und/oder des PLs, der einen (Co-)Leiter möchte, doch eigentlich in den meisten Fällen auch fit für den VB sein, ansonsten wäre diese Person ja nicht vorgeschlagen worden, außer es ist ein Fall von Projekt ohne Leiter. Von dem her würde ich da sagen, dass man den Nutzer in den meißten Fällen eigentlich auch ohne Wahl zum VB machen könnte, da ich hier die Problemfrage sehe „Was passiert, wenn ein PL-Kandidat aus was auch immer für Gründen durch die VB-Wahl nicht zum VB werden würde? Soll das Projekt dann einfach ohne (zweiten) PL auskommen und warten?“ GrollenKette951 17:52, 3. Okt. 2020 (CEST)

VB-Wahlen zu überspringen hat mein klares Contra. Wenn Admins überlegen, ob ein SB für einen PL-Posten geeignet ist, gehen sie ja quasi auch die VB-Ernennungsphase durch und die soll ja durch die VB-Wahlen ersetzt werden. Ich würde bei der Wahl kennzeichnen, dass der User ggf. direkt ein PL werden würde, aber ansonsten die Wahl ganz normal durchführen. Die Kritik daran SBs mitabstimmen zu lassen kann ich verstehen. Ich habe bisher aber die Hoffnung, dass dieser Vertrauensvorschuss am Ende gut ausgehen wird. Ja, als ich SB war, hätte ich auch kaum einschätzen können was einen VB ausmacht, aber damals bzw. auch heute noch, haben SBs bei Rang-Sachen nix zu sagen. Wenn Leute bei sowas nicht miteinbezogen werden, können sie das natürlich nicht beurteilen. Bedenkt, aus der VB-Wikiseite kann man kaum die Anforderungen an einen VB rauslesen und bisher wurden die Entscheidungen im internen Admin-Kreis getroffen. D. h. dass man hauptsächlich durch das Mitkriegen von Ernennungen und Kennen der Fähigkeiten des jew. Kandidaten ein Gefühl dafür kriegt und das dauert, da VB-Ernennungen nicht grade an der Tagesordnung stehen. Ein Veto-Recht der Admins kann es von mir aus geben, dann aber nur mit sehr hohem nötigen Prozentsatz wie 80% oder sogar einstimmig (2/3 ist mMn zu niedrig). Die Begründung für diesen hohen Prozentsatz ist, dass die Admins sich über die Entscheidung von einem Großteil des Teams hinwegsetzen müssten und das auf jeden Fall von mehreren Leuten gut durchdacht sein muss. --DeXter 18:33, 3. Okt. 2020 (CEST)

Ein Adminvetorecht über zwei Drittel bei aktueller Besetzung zu setzen ist sinnlos, da dies sehr wahrscheinlich dazu führt, das sich die Admins vorab absprechen ob sie alle ablehnen oder nicht, wodurch im Zweifel lediglich eine Pro-Stimme verloren geht. Ich glaube nämlich nicht, das ein Admin gegen den Willen aller anderen Admins eine Wahl durchgehen lassen würde. --Datei:Sugimori 672.pngMecanno-man^Mäh 19:36, 3. Okt. 2020 (CEST)

Ich finde, dass es ruhig gekennzeichnet sein kann, dass ein VB, der zur Wahl steht, auch direkt PL werden würde. Allerdings finde ich nicht, dass bei solchen Kandidaten die Wahl übersprungen werden sollte, weil die Wahl genau dazu dient, andere Nutzer dabei einzubinden und dem Vorgeschlagenen Feedback zu geben. Dass die Wahl da scheitert, denke ich nicht, weil bei solchen Kandidaten, die sowieso PL werden sollen, erkennbar ist, dass sie sich sehr engagieren und von den Admins "geschätzt" sind. -- Feblue 14:40, 5. Okt. 2020 (CEST)

Zu Feblue: Dass ein User PL werden würde, wäre in der Regel, denke ich, ein weiterer Plus-Punkt für ihn, aber es sollte dennoch weder eine Scheinwahl sein noch als eine behandelt werden. Zumindest lese ich aus deinem Beitrag heraus, dass du die Wahlen von potenziellen PLs quasi als von Anfang an für den jew. User gewonnen siehst.

Zu Mec: In der aktuellen Situation heißt das dann, dass nur zwei Nicht-Bürokraten sich potenziell über (fast) alle ESBs und SBs hinwegsetzen könnten? Das ist sicherlich bei anderen Sachen schon der Fall, aber ich kann das nicht unterstützen, denn das hat Potenzial, dass Entscheidungen getroffen werden, die gegen den Willen des Teams sind. Mit nur 3 Admins sollten mMn für so eine Aktion wirklich alle dahinterstehen.--DeXter 09:13, 6. Okt. 2020 (CEST)

Eine Randnotiz seitens der Admins an dieser Stelle: Wir setzen bis zum Ende dieser Diskussion übrigens sämtliche VB- und PL-Ernennungen aus. Hat den Grund, dass wir nicht jetzt jemanden ernennen wollen, wenn sich wahrscheinlich bald das Ernennungs-Verfahren ändert, um nicht den Eindruck zu erwecken, dass wir jetzt noch schnell unseren Willen durchsetzen, bevor wir nicht mehr einfach frei entscheiden können. Andererseits wollen wir nicht gegen jemanden stimmen, wenn dieser in zukünftigen Wahlen gewählt würde. Daher keine neuen VBs und PLs bis sicher ist, wie genau diese in Zukunft ernannt werden. -- RobbiRobb 15:59, 6. Okt. 2020 (CEST)

Ich denke aber es wird noch eine Weile dauern bis wir ein fertiges Wahl-Konzept haben. Z. B. kam bisher ja nur erste Kritik zu einzelnen Punkten von Kenaz' Konzept (und damit auch indirekt zu meinem, da ich einige Sachen von Kenaz übernommen und angepasst habe). Von "bald" oder "noch schnell" kann hier also mMn nicht die Rede sein. Das zweite Argument ist für mich nicht ganz schlüssig. Es ist doch egal, ob jemand jetzt abgelehnt wird oder ob gar nicht über seine Ernennung geredet wird. In beiden Fällen wird er nicht VB und meines Wissens nach hätte das keinen Einfluss auf eine zukünftige VB-Wahl (unabhängig davon wie VB-Wahlen am Ende aussehen werden).

Ich bin also klar gegen dieses Vorgehen und kann das grade auch nicht wirklich nachvollziehen. Es heißt so oft, dass wir VB-Mangel haben und händeringend nach neuen Leuten, nach neuen VBs und PLs suchen. Dann kann man doch nicht wegen einer Diskussion die Ernennungen für diese beiden Ränge komplett blockieren. Vor allem ist die Dauer mMn hier ein großes Problem. Die Diskussion läuft schon seit ca. 1,5 Monaten und wird sicherlich nicht in den nächsten Wochen vorbei sein.

Meine dringliche Bitte ist also, dass dieses Vorgehen wieder zurückgezogen wird und VB- und PL-Ernennungen wie gewohnt stattfinden, bis das VB-Wahl-Konzept anwendungsbereit ist und ohne Verzögerung angewandt werden kann.--DeXter 17:54, 6. Okt. 2020 (CEST)

siehe Dexi * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 09:42, 8. Okt. 2020 (CEST)

(DeXters vorletzte Nachricht) Ja, ich sehe die Wahl theoretisch als gewonnen. Ich stimme dir zu, dass es keine Scheinwahl sein sollte, aber es sprechen (für mich) nunmal bei einem Nutzer, der PL werden soll, fast alle Argumente (außer irgendetwas, das mir gerade nicht einfällt, ist sehr auffällig / außer etwas, das ich nicht kenne, das also vor meiner Zeit passierte, spricht dagegen) dafür, dass er VB wird. Feblue

Da auf Discord erneut eine Diskussion über das bestmögliche VB-Wahlsystem gehalten wurde, kamen auch gleichzeitig neue Ideen auf. Eine davon stach zum Schluss heraus:

Die Idee besteht darin die Wahlen auf VB und aufwärts zu beschränken. Diese können ihre Stimme abgeben. SB werden allerdings nicht komplett ausgeschlossen. Sie haben die Möglichkeit, ihre Argumente sowie Wünsche durch Kommentare auf der Diskussionsseite im Wiki kundzutun. Dies wird ihnen vor den eigentlichen Wahlen ermöglicht. SB haben 5-7 Tage Zeit (kann geändert werden) ihre Kommentare zu schreiben. Die eigentlichen Wähler können sich somit die Meinungen der SB durchlesen und dadurch ggf. deren eigene Stimme überdenken. Sie wählen dann nach diesem Zeitraum (gerne so lange wie bei den Red-Wahlen). SB werden mit diesem System also angehört, können jedoch nicht abstimmen, was im Sinne vieler ist, die denken, dass durch eine Wahlbeteiligung der SB das Stimmbild verzerrt werden könnte.

Dadurch können SB, welche gerne an der Abstimmung teilnehmen würden, dies auch tun. Für gute und auch brauchbare Argumente Seitens dieses Ranges wird also ein Vorwissen zu den Nutzern und deren Aktivität im Wiki vorausgesetzt. Dementsprechend können Argumente einen Nutzer betreffend auch ignoriert werden, wenn klar ersichtlich ist, dass sich mit diesem nicht befasst wurde. Auf diese Weise können alle, ob direkt oder indirekt, abstimmen und es sollte (hoffentlich) alle zufriedenstellen. -- Feblue 18:57, 15. Okt. 2020 (CEST)

Es scheint mir irgendwie, als würde jedes Mal wenn hier etwas vorgeschlagen wird, dies ein ganzes Wahlkonzept sein. Ich sehe uns hier ehrlichgesagt nicht auf ein fertiges Konzept ohne Abstimmung einigen, folglich wäre es hier meiner Meinung nach an der Zeit das Vorgehen zu ändern und das System modular angehen - denn zig verschiedene ganze Systeme werden in einer Abstimmung nicht gut kommen, da garantiert den meisten irgend ein Detail an einem System nicht passen wird. Ich halte e aber durchaus möglich parallel mehrere Abstimmungen zu verschiedenen Komponenten zu machen; also iwie eine für ne Kommentarphase, eine für gleichzeitige Wahlrunden etc. So hätten wir dann zum Schluss ein System, bei dem auch jede Komponente tatsächlich von der Mehrheit bestätigt wurde.

In diesem Fall sei auch noch erwähnt, das ich (in Absprache mit den anderen Admins) grundsätzlich eine solche Abstimmung bereits vorbereitet habe. Sollte hier also eine Weile lang nichts mehr kommen werde ich diese starten. --Datei:Sugimori 672.pngMecanno-man^Mäh 21:13, 16. Okt. 2020 (CEST)

Ich denke das wird nur bedingt so klappen. Denn manche Aspekte sind abhängig voneinander. Z. B. sähe ich keinen Sinn darin für "SBs als Wähler?" und "Kommentarphase?" parallel Abstimmungen zu haben, da die miteinander verknüpft sind (nur wenn SBs nicht mitwählen dürften, würde die Kommentarphase einen Sinn machen). Solche Verknüpfungen bzw. Abhängigkeiten sind denke ich auch (zum Teil) daran Schuld, dass bisher großteils ganze Wahlkonzepte in einem erstellt wurden, denn in diesen Konzepten sind die Komponenten mit ihren Abhängigkeiten genau aufeinander abgestimmt. Ich würde da, wenn dann stufenweise vorgehen. Z. B. als erstes die Abstimmung: "SBs als Wähler?" Bei einer frühen Festlegung auf so etwas fundamentales, sehe ich aber die Gefahr, dass man dann im späteren Verlauf überlegen könnte, ob man nicht doch nochmal über die andere Option nachdenken sollte.--DeXter 21:48, 16. Okt. 2020 (CEST)

Nun gut, man kann die Optionen natürlich auch als "Falls X gewinnt/verliert, sollen wir dann Y machen?" stellen. Würden so oder so alle Wahlkonzepte bekommen, da die dann von "Wollen wir Wahlen?" abhängen. --Datei:Sugimori 672.pngMecanno-man^Mäh 22:49, 16. Okt. 2020 (CEST)

Öhm, dann viel Spaß bei solchen Abstimmungen die Übersicht zu behalten, da man dann ja pro Abhängigkeit mind. zwei Optionen bräuchte. Bin mir grade auch unsicher, ob es Punkte gibt, die sogar mehr als eine Abhängigkeit haben, da würde eine Abstimmung darüber sehr komplex werden. --DeXter 22:55, 16. Okt. 2020 (CEST)

Eine Idee, die mir grad beim Durchlesen der letzten Beiträge kam: Die Diskussion ist inzwischen super lang geworden. Ich fänds gut, wenn man irgendwie einen "neuen" Anhaltspunkt wie z. B. einfach einen Unterabschnitt dieser Diskussion erstellt und da am Anfang den aktuellen Stand zusammenfasst und dort dann weiterdiskutiert. Hört sich nach keinem Unterschied an, aber ich denke, dass das was verändern wird (z. B. u. a., dass ich nicht jedes mal beim Vorschau anzeigen n gutes Stück nach unten scrollen muss). Ich habe die Diskussion seit Anfang an mitverfolgt und habe trotzdem keinen sicheren Überblick über all die Meinungen, Ideen, Vorschläge, die aktuell im Raum stehen, eine Sammelstelle mit allem, wäre langsam aber sicher mMn gut. (ab einem bestimmten Zeitpunkt die früheren Beiträge zu dieser Diskussion irgendwie archivieren o. ä. und den aktuellen Stand zusammenfassen, würds auch tun)

Dann meine Ansicht zu einem entscheidenden Thema bei dieser Diskussion: Sollen SBs wählen können oder nicht? Vorweg: Wenn SBs mitabstimmen können, sollte ein SB mMn die gleiche Stimm-Kraft wie ein ESB haben, da sonst so eine Scheinmacht à la "du kannst zwar abstimmen, aber deine Stimme zählt viel weniger" entsteht. Allerdings will ich noch weniger, dass die Gruppe der SBs in der Theorie allein VBs ernennen könnte (was bei einem Wahlkreis und gleichen Wahlbedingungen in der Regel möglich wäre, da meistens die SB-Gruppe größer als die ESB-Gruppe ist). Denn ja, manche SBs können bestimmt sich ein gutes Bild von manchen Wahl-Kandidaten machen, z. B. wenn sie selbst kurz vor der Wahl stehen. Aber alle können das unter Garantie nicht. Neue User, die gerade ihren 100. Edit gemacht haben, haben denke ich oft noch nicht mal einen Überblick übers Team (was mMn völlig in Ordnung ist; als ich SB wurde, hatte ich keine Ahnung vom Wiki, so Standard-Sachen wie die LÄ kannte ich damals einfach nicht, geschweige denn hatte ich eine Ahnung welche Leute das SB-ESB-Team bilden) und können daher mMn auch nicht urteilen, ob ein SB das Zeug zum VB hat. Hier könnte man natürlich darauf setzen, dass die SBs selbst einschätzen können, wann sie abstimmen sollten, aber allein darauf hoffen, will ich bei einer so schnell erreichbaren Gruppe und einem so fundamentalen, wichtigen Rang in unserem System nicht. Eine Randbemerkung: Alle ESBs können sich mMn sicherlich auch nicht von jedem SB ein gutes Bild machen. Woher soll ich z. B. auch wissen was für Qualität ein User im Strategie-Bereich leistet, wenn ich von dem Projekt keine Ahnung habe. Bei ESBs habe ich aber das Vertrauen, dass diese gut genug einschätzen können, ob sie abstimmen sollten.

Will man SBs trotzdem mitabstimmen lassen, braucht man mMn also z. B. sowas wie zwei Wahlkreise (siehe Kenaz' erstes und mein erstes Konzept), die z. B. beide Pro sein müssen für einen Wahlerfolg. Da ist aber das Problem, dass so ein Wahl-System zu kompliziert werden könnte. Auf der anderen Seite könnte man die SB-Wähler-Gruppe mit Sonderbedingungen belegen, aber das würde in Richtung von der bereits angesprochenen Scheinmacht gehen und da ist mir noch keine Lösung eingefallen.

Die andere Option wäre also SBs kein Wahl-Recht zu geben. An sich fände ich es gut, wenn die stimmberechtigten Benutzer stärker miteingebunden werden, aber der Rang ist so schnell zu erreichen, dass mMn nicht alle SBs bei einer VB-Wahl abstimmen sollten und wie soll man da die Grenze ziehen ohne früher oder später in Diskussionen zu geraten, wer genug Erfahrung hat und wer nicht?

Hier auch noch am Ende die Links zu den meines Wissens nach aktuell bestehenden Unterseiten mit Konzepten zu dem Thema: Kenaz' Unterseite, meine Unterseite --DeXter 23:26, 21. Okt. 2020 (CEST)

Ich sehe hier ehrlichgesagt keine Möglichkeit, den SBs etwas anderes zu geben als den ESBs, ohne das ihre einzelnen Stimmen mehr zählen als diejenigen der ESBs, ausser sie strikt als weniger Wert festzulegen - wo ich dir zustimme, das ich das nicht möchte. Punkt ist das schlicht weniger SBs abstimmen werden, weil etliche von ihnen nicht abstimmen werden wollen. Wenn wir ihnen einen eigenen Wahlkreis geben, der auch zustimmen muss, dann haben die individuellen SBs die abstimmen automatisch eine grössere Stimm-Kraft als individuelle VBs - was ich auch nicht wirklich möchte. Ich stehe deswegen dem ganzen Wahlkreis-Zeugs *sehr* skeptisch gegenüber; die Frage ob SBs teilnehmen dürfen ist definitiv eine, die zu klären ist, aber meiner Ansicht nach sind hier nur die Möglichkeiten ihnen genau so viel Stimm-Kraft zu geben wie ESBs dadurch das beide Gruppen zusammengenommen werden, oder sie ganz auszuschliessen. --Datei:Sugimori 672.pngMecanno-man^Mäh 02:43, 22. Okt. 2020 (CEST)

VB-Wahlen

Da diese Diskussion inzwischen (wortwörtlich) mehrere Meter lang ist, habe ich mich entschlossen den bisherigen Verlauf zum Thema VB-Wahlen zusamenzufassen (Sachen zu anderen Themen habe ich ignoriert) und einen Unterabschnitt dafür zu erstellen, in der Hoffnung, dass das die Diskussionsbeteiligung hier steigern wird. Die Zusammenfassung habe ich in zwei Teile getrennt. Einen mit alten Sachen, die nicht mehr im Raum stehen, um Anhaltspunkte zu haben, wie es zu der aktuellen Situation gekommen ist und einen Teil mit den aktuell im Raum stehenden Dingen (um es auch deutlich zu sagen: nichts davon steht fest, die Sachen stehen aktuell "nur" im Raum).

Ältere Sachen zum Nachvollziehen (aus-/einklappen)

• Ein Knackpunkt: Großer Wählerkreis sinnvoll? Problem, dass man nicht von jedem User ein gescheites Bild kriegen kann.
  • Werden Wahlen am Ende abgenickt? Können frische VBs sich ein gutes Bild machen? Einfluss von Discord im Bezug auf Sympathien und Antipathien?
  • eine Idee von mir dazu: betroffene PLs und passende andere ESBs dazuholen und damit einen flexiblen Wahlkreis pro Wahl haben (Steht nicht mehr im Raum, da das zu schwammig ist).
    • Eine Abwandlung: bei Wahl kann jeder ESB, der will sich melden und in den Wählerkreis einschreiben und dann wird mit diesen Leuten die Wahl gestartet (dazu eine Idee: Erst Einschreibungsphase (wer abstimmt), dann Diskutierphase, dann Abstimmphase).
  • Vorschlag von Feblue: Alle PLs, da PLs einen Blick auf die User in ihren Bereichen haben.
    • Meine damalige Reaktion dazu: Nicht nur PLs als Wähler, da oft VBs mit SBs zu tun haben und sich auch ein gutes Bild machen können.
    • Mecs Kritik: nicht-PL-ESBs könnten dann nicht für VBs stimmen aber für Reds.
• Nicht mehr im Raum stehende Idee der Widerspruchslösung kam von Max auf und wurde von mir weiter ausgeführt: SB kann von PL vorgeschlagen werden und wenn kein Admin oder kein anderer PL des Projekts ein Veto äußert wird er VB.
  • Problem: Widerspruchslösung würde mit unserer aktiv orientierten Team-Einstellung bei Rang-Sachen kaum Unterschied machen.
  • Aktive Zustimmung vs. passives nicht-Ablehnen => zum einen muss ein Admin einen VB ernennen und somit ist immer etwas aktives dabei.
  • ich denke auch, dass die Admins sich bei VB-Ernennungen egal welcher Form nicht passiv halten werden.

Aktuell im Raum stehende Punkte

• Siehe Benutzer:Kenaz-Hagalaz/Wikipolitik und Benutzer:DeXter/Gehirnstürmen.
• Wunsch nach eingegliedertem Admin-Veto, damit im Notfall über User und Regeln hinwegsetzen verhindert wird.
  • Mein Wunsch, dass der Prozentsatz dafür sehr hoch sein muss (denn Admins würden sich mit dem Veto über die Mehrheit einer User-Gruppe hinwegsetzen).
    • dass mit drei Admins alle drei fürs Veto sein müssten hat Kritik von Mec.
• Wer schlägt wen vor?
  • ESBs andere SBs.
  • Vet-SBs sich selbst.
  • SBs, die eine Wahl bereits verloren haben können sich selbst vorschlagen.
• Rolle der SBs (hat großen Einfluss aufs gesamte Wahl-System (z. B. zwei Wahlkreise oder einer?)).
  • Kritik an Stimmrecht der SBs (sehr schnell erreichbarer Rang und damit u. U. nicht genügend Übersicht über die Rechtestruktur und das Team => nicht alle SBs können einschätzen, ob sie den Kandidaten gut genug beurteilen können (die, die nah am VB sind könnten das vermutlich)).
  • Bei einem Wahlkreis mit absoluter Mehrheit könnten SBs in der Theorie ohne ESBs den Wahl-Sieg verursachen, da in der Regel mehr SBs als ESBs vorhanden sind; SBs mit Sonderregelungen würde in Benachteiligung, Scheinmacht u. ä. enden.
  • Mehr als ein Wahlkreis (z. B. einer für SBs und einer für ESBs, siehe die ersten Konzepte von Kenaz und mir) könnte zu kompliziert werden und vermutlich werden in der Regel weniger SBs abstimmen, weshalb mit zwei Wahlkreisen die wenigen SBs mehr Einfluss hätten als die ESBs.
  • Idee, dass SBs nicht abstimmen dürfen, aber vor der Wahl ihre Meinungen, Einstellungen usw. in einer Brainstorming-Phase äußern können und somit dennoch Einfluss haben.
• Umgang mit VB-Kandidaten, die direkt PL werden würden?
  • Mein Vorschlag: normale Wahl mit Anmerkung, dass der User direkt PL werden würde.

Sollte ich etwas vergessen haben oder anderes an der Zusammenfassung nicht passen, kann das natürlich noch angemerkt werden. --DeXter 20:15, 3. Nov. 2020 (CET)

Dexi hat mich ja diesbezüglich angeschrieben und wollte das ich meine Aussagen mal hier her kopiere. Im großen und ganzen finde ich dieses Trara massiv übertrieben. wozu überhaupt ein Vetorecht? -> Wird es den unteren Ränge nicht zugetraut?

Wozu Abstimmungen der SB? -> Warum sollte jemand mit unzureichender Erfahrung Entscheidungsträger für Patrol sein? Dies soll keine Pauschalisierung der derzeitigen SB sein sondern ist runter gebrochen auf die SB vorraussetzungen. Warum soll ein Vet sich selbst verschlagen können? Er war mal erfahren... Betonung liegt auf war.... (je nach Dauer der Inaktivität kann er immernoch erfahren sein). der Vet kann sich mMn auch einfach wenn er sachen gemacht hat bei einem Red usw.. melden das er wieder VB werden will und dann leitet der Red es je nachdem ein und fertig ist der Lack.... was sonst hier so steht ist alles nur unnötig und viel zu komplex für 20 aktive Hansel... Wozu überhaupt was drum rum... Ein PL oder mind. Red darf SB/Vet zum VB vorschlagen/einstellen und dann gibt's 14 Tage Abstimmungsfrist... Reds sind zur Stimmabgabe verpflichtet.... ist dann analog zur Redwahl welche Admins einleiten und wo admins verpflichtend abstimmen müssen und fertig.... was will man da noch unnötig verkomplizieren Und nein ich finde wer Redakteur ist, hat die höchstmögliche Stufe bis mal ein Admin abtritt oder Verstärkung gebraucht wird und da finde ich die Pflicht nicht schwierig.... wie sollen wir andere zur Mitarbeit bewegen wenn die höchste Ebene (höchste für jeden erreichbare Ebene) sich zu weigert eine poplige Stimme abzugeben. * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 20:41, 3. Nov. 2020 (CET)

Kurze Frage zu deinem Vorschlag, Ryu: Meinst du hier eine riesige Wahlrunde für alle, oder eine 14-Tage-VB-Wahlrunde, gestartet nach einem Pro von Admins und Reds? Bei der Red-Wahl funktioniert das mit der Stimmpflicht eines gewissen Anteils der Admins ja auch nur, weil die erste Wahlrunde unbefristet ist, eine Wahlpflicht - egal für welche Usergruppe - halte ich für unumsetzbar wenn die Wahlrunde ebenfalls befristet ist (was machen wir, wenn x User die abstimmen müssen es in der Zeit nicht tun?), und eine Trennung von wann Redakteure und wann VBs abstimmen dürfen scheint mir nicht sonderlich sinnvoll - zeitgleich hab ich ebenfalls das Gefühl, das dies eine Wahl nur unnötig verzögert bis sich mal genügend Reds ein Bild zum SB gemacht haben, denn ich glaube nicht das alle Redakteure dies andauernd machen. --Datei:Sugimori 672.pngMecanno-man^Mäh 21:41, 3. Nov. 2020 (CET)

Beispielhaft: Unser Pöbel möchte wieder VB werden oder ESB schlägt RBS vor. Es wird im Redchannel angesprochen das Pöbel/RBS VB werden möchte/vorgeschlagen wurde. Gibt eine kurze Red Umfrage nach dem Motto Wahl ja/nein bei mindestens 51% Befürwortern startet ein Red eine Wahl. Sonderfall bei Max der ja doch aktiv ist da würde ich die Klausel mit Vet bekommt schneller die rechte zurück anwenden. Also wie damals bei PK. Kurze Umfrage mit VB wieder ja nein... und fertig... Und solange man es anschließend transparent hält. Z.b. Beitrag auf Pöbels Seite "Haben Wunsch nach VB bekommen, aufgrund Begründung z.b. kurzfristiger Inaktivität und vergangener Beiträge und Nachräumaufwand, geben wir dir VB wieder", ne Wahl fänd ich in dem Fall zu überbürokratisiert. Und manches sollten wir mal wieder etwas userfreundlicher handhaben und nicht ewige pampflet von Unterseiten Konzepten durchackern.... Würde Max hochgespitzt nach 2 Jahren kommen dann ganz klar wieder ne Wahl..... wir sind aktuell nur 6 Reds, und i.d.R. melden sich die meisten ab wenn sie länger nicht da sind. Die werden dann halt rausgerechnet... Wenn wir 30 Red wären dann wäre so eine Verpflichtung utopisch aber bei 6. Und es muss nicht groß rumgeeiert werden sondern einfach nur ein ja/nein das halte ich für ziemlich machbar. einzig Sonderfälle gäbe es zu diskutieren. Das halte ich für aber auch für machbar. Da Admins den Channel sehen, könnten diese bei Unklarheit ja nachfragen oder sich einbringen. Sind es jedenfalls mindestens 50% der Reds dafür dann startet ein Red eine 14tägige Wahl. Wahlbeteiligung ab ESB und fertig. Frage ist halt wer die VB dann ernennt/ändert. Bleibts bei Admins oder sollen Reds es auch dürfen * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 22:43, 3. Nov. 2020 (CET)

Ich bin dagegen irgendwas rechtemässiges offiziell auf Discord zu machen wenn VBs abstimmen dürf(t)en, abgesehen von Nominierungen. Denn nicht alle VBs sind auf Discord und das sollte eigentlich nicht eine Bedingung sein um VB zu werden/bleiben/seine Rechte nutzen. Generell finde ich, das abgesehen von Admin-internem, kleineren Projekten mit wenigen involvierten (wo eine grosse Beteiligung nicht erwünscht ist) und Besonderheiten wie iwie VBW-Beurteilungen, die nicht das ganze Team angehen, Sachen grundsätzlich im Wiki geklärt werden sollten - und an der Stelle sehe ich dann nichts sinnvolleres als eine eigene Wahlseite, wo dann auch alle Fälle abgehandelt werden, ungeachtet dessen ob das jetzt eine "kontroverse" Entscheidung ist oder nicht. --Datei:Sugimori 672.pngMecanno-man^Mäh 23:26, 3. Nov. 2020 (CET)

Ich finde, dass Ryu da nicht ganz Unrecht hat. Wir können es einfacher halten, komplizierter als die Red-Wahl sollte es keinesfalls werden. Daher finde ich auch: Ab ESB kann man einen SB und Veteranen vorschlagen. Weiter (wie Ryu meint) dürfen Veteranen sich bei den ESB melden, damit diese den Vorschlag weitergeben und die Wahl einleiten. An der Wahl dürfen ESB teilnehmen. Weiterhin bin ich dafür, dass vor der Wahl eine Kommentarfunktion für SB eingerichtet wird, womit dann die Wahl beeinflusst werden kann, aber eben nicht abgestimmt werden kann. Ansonsten wird wie bei der Red-Wahl verfahren. -- Feblue 00:55, 4. Nov. 2020 (CET)

@Mec: Ich glaube wir reden aneinander vorbei daher nochmal zum Mitschreiben

1. pot. SB wir von ESB bei Reds vorgeschlagen bzw. Vet meldet sich bei Reds (Plattform Discord oder Wiki)
2. Der Red macht eine kurze Meinungsumfrage (ja/nein) im Redchannel (ALLE Reds sind auf Discord) ob der Pot.SB/Vet zur Wahl gestellt werden sollte, bzw bei Sonderfällen eine Diskussion ob wahl oder direkt wieder vb. Das kann ja im Discord gemacht werden. Wurde ja bei PK damals auch so gemacht und sehe da keine Problematik.
3. Red eröffnet bei 51% fürsprache 14tägie Wahl im Wiki. Stimmberechtigt ab ESB.

@Feblue: Wenn SBs die Wahl vorher beeinflussen, dann haben sie indirekt mit abgestimmt bzw. die Wahl in eine vorbestimmte Richtung gelenkt. Daher bin ich bei dem Vorschlag dagegen. Hintergrund sind wie gesagt nicht die derzeitigen SB sondern die SB-Voraussetzungen. Daher können SB während der Abstimmung natürlich ihre Meinung unter Kommentare hinzufügen was auch gerne gesehen wird allerdings sehe ich alles andere mehr als nur kritisch auf Grund der Voraussetzungen und nicht weil ich es z.b. dir persönlich nicht zutraue eine adäquate Meinung zu schreiben. Das wäre falsch wie man an deiner bisherigen Diskussionsbeteiligung ja sieht. Nur wenn wir jetzt anfangen SBs zu "bevorzugen" indem wir beispielhaft sagen feblue und Pöbel dürfen teilnehmen RBS und Mario nicht, oder umgekehrt (obwohl alle SB sind) dann wirkt das ziemlich Kalkül und intransparent usw. daher einfach klare Linie und fertig * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 07:06, 4. Nov. 2020 (CET)

Okay, deinen Standpunkt kann ich verstehen. Ich weiß gar nicht mehr, ob du Teil der Diskussion warst, aus der die Idee stammt. Ich erkläre einfach mal etwas mehr: Die Einbindung von SB bei Abstimmungen wurde ja durch die Wahlkonzepte bereits erwünscht, allerdings gab es da Gegenwind aufgrund der potentiellen Macht der SB, die sich in allen vorgeschlagenen Systemen irgendwie über ESB hinwegsetzen könnten. Daher war mein Einwurf auf Discord ("Dann müsste man aber auch die Kommentare zuerst freischalten, damit die Meinung der SBs auch wahrgenommen wird") darauf ausgerichtet, dass SB in einem wie dem Red-Wahlsystem eingebunden werden, allerdings keine Stimme haben. Die Idee dahinter ist, dass die Sichtweise der SB auf den zur Wahl stehenden SB offengelegt wird und somit ESB diese Sichtweise nutzen können, um sich selber ein klareres Bild zu machen. Ich hoffe, dass ich da jetzt die Idee besser erklärt habe. Ansonsten auf Discord zum Nachlesen: https://discordapp.com/channels/247122072378146816/303171986979291136/766047412418117653 Oder eben per Suche einfach von:feblue in:organisation eingeben, da findest du meine Idee und den Kontext relativ schnell. Das war am 14.10.2020. -- Feblue 13:11, 4. Nov. 2020 (CET)

Also ...würden Reds und Admins in deinem System quasi doppelt abstimmen, Ryu? Scheint mir ehrlichgesagt auch übermässig bürokratisch, was du ja gerade verhindern wolltest, oder?

Bezüglich Kommentarmöglichkeit für SBs - ich wüsste nicht warum sie dies nicht tun sollen, können sie ja bei ner Red-Wahl auch. Frage is halt ob vorher oder während der Wahl. Ich tendiere hier zu während, da da vorher meiner Meinung nach das ganze nur unnötig verzögert. --Datei:Sugimori 672.pngMecanno-man^Mäh 16:04, 4. Nov. 2020 (CET)

SBs können gerne während der Wahl. Aber von vorher halte ich nix. Und wieso Doppelt und verkompliziert? Jeder Red vorschlag wird Admin intern besprochen und kommt dann auf die Wahlseite und dann kommt das öffentliche Feedback. So stehts bisher bei den Wahlen. Und eine Kurze Rundfrage in Red ob ja/nein und bei >50%ja wird die Wahl gestartet ist doch nicht überbürokratisiert. Oder wo siehst du massig doppelten Aufwand? Und bei sowas wie Max das kurz auf Redebene zu klären und ihn ggf. zu befördern ist doch eher vereinfacht statt überbürokratisiert. Aber z.b. Pöbel wird wegen VB angefragt und über die Hälfte der Reds sagt nein, dann sollte sich mMn ein Admin einschalten und mal nachfragen warum der Großteil dagegen ist. * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 16:14, 4. Nov. 2020 (CET)

Ich finde, dass der Zeitaufwand sich lohnt. Daraus kann sich eine bisher passive Haltung der SB verändern, wenn sie sehen, dass sie ihren Senf bei etwas sehr wichtigem dazugeben können. Ich hatte zwar bei den letzten beiden Red-Wahlen kommentiert, weil ich beiden Gewählten etwas auf den Weg geben wollte, aber ansonsten hat das für mich keinen weiteren Sinn. Vielleicht ist das auch der bisher intendierte Sinn der Kommentare. Aber eine Stufe, die stimmberechtigt ist, sollte doch zumindest an der Wahl der nächsthöheren Stufe teilhaben können. Das steigert nicht nur das Potential der aktiveren Diskussionsteilnahme, sondern auch, dass die SB versuchen, tief in Thematiken einzudringen, die sie dadurch besser zu verstehen lernen. -- Feblue 00:48, 5. Nov. 2020 (CET)

@Ryu: Bei Redakteurs-Wahlen wird admin-intern eigentlich nur diskutiert, ob man jemanden selber vorschlagen soll, was keiner geregelten Struktur folgt und im Grunde genommen einfach ne Meinungsfindung ist, die auch jeder andere User informell betreiben kann. Wenn da aber von ausserhalb der Administration ein Vorschlag eingeht kommt dieser Vorschlag eigentlich immer zur Wahl. Eine interne Abstimmung der Admins ist an dieser Stelle nicht notwendig, weil dafür ja die erste Wahlrunde der Redakteurs-Wahl ist. Würde man bei einer VB-Wahl jetzt sowas offiziell noch in nen internen Kanal legen sehe ich dadurch eine doppelte Befassung des Themas durch Admins und Reds, weil sie erst die Wahl da beurteilen müssen und danach noch selber abstimmen gehen sollen. Eine erste/zweite Wahlrunde mit Trennstrich Red/VBs sehe ich auch nicht wirklich als all zu sinnvoll, weil die Reds üblicherweise genügend Stimmen haben das schon klar ersichtlich ist, wohin die Wahl geht. Die Reds und Admins nur auf Discord abstimmen zu lassen scheint mir ihm Rahmen des Transparenzwunsches auch nicht sinnvoll. --Datei:Sugimori 672.pngMecanno-man^Mäh 03:42, 5. Nov. 2020 (CET)

Getrennte Wahlen mit Trennung zwischen Reds und VBs zu machen sehe ich jetzt nicht so schlimm. Ja, aktuell haben die Reds und Admins glaube ich die Mehrheit der ESBs, aber neue VBs gabs jetzt schon ung. 10 Monate nicht mehr. Wenn da die aktuell qualifizierten Kandidaten befördert werden, sähe das denke ich wieder anders aus. Ich habe es grade schon mit reingeschrieben, aber trotzdem noch die Nachfrage zur Sicherheit: Bei dem Gedankengang zu den getrennten Wahlrunden, wären die Admins in der Red-Wahlrunde dabei, oder? Die Rolle der Admins wurde glaube ich bisher nicht explizit erwähnt.

Bei dem Punkt, dass Vet-SBs sich nicht selbst vorschlagen, aber eine Anfrage an einen Red o. ä. schreiben können, bin ich auch noch skeptisch. Denn so wie ich das Vorschlagen grade verstehe, ist das das inoffizielle einfach anschreiben, was eigtl. jeder machen kann. Bei dem Punkt bin ich weiterhin der Meinung, dass Vet-SBs eine Wahl für sich selbst starten können sollten (als Veteran hat ein User, denke ich, genügend Erfahrung, um mit der Aktivität als SB wieder als VB in Frage zu kommen). Bei der internen Autorisierungswahl im Red-Kreis bin ich ebenfalls kritisch. Wenn eine Wahl abgelehnt wird, sollten mMn die Gründe als Feedback dem Kandidaten mitgeteilt werden. Bei einer ersten, öffentlichen Wahlrunde der Reds wäre der Aspekt ja auch gleich erfüllt. Ich bin mir auch unsicher, ob es sinnvoll ist am Anfang auf Meinungen von SBs zu warten. Denn aktuell denke ich, dass nicht allzu viele davon Gebrauch machen würden. Allerdings weiß ich auch nicht, wie sich das durch so etwas in Zukunft ändern könnte. Zu einer Red-Wahlpflicht wäre ich jetzt nicht direkt contra, aber das sollte mMn vorsichtig beschlossen werden. Z. B. sollten die "abgemeldeten" User (Abgemeldet im Sinne von z. B. auf Discord geschrieben, dass man die nächste Zeit kaum oder nichts machen wird wegen wasweisich) von der Pflicht ausgeschlossen sein. Wenn es da keine Zeitbegrenzung für die Wahlrunde der Reds geben würde, könnte ich mir so eine Wahlpflicht für Reds aber vorstellen.

Abschließend noch etwas zu Ryus Kritik am geplanten Admin-Veto-Recht: Sollte es eine Autorisierungswahl der Reds geben, würde auch ich dieses Veto anfeinden. Die Redakteurs-Stufe braucht denke ich keine Notbremse von oben, Redakteure sind erfahren genug um gemeinsam zu bestimmen, ob jemand zu Wahl zugelassen werden sollte. --DeXter 19:18, 10. Nov. 2020 (CET)

Ich werde hier jetzt mal noch eine Idee hin schmeißen:

1. Ein SB (hier zählen auch die SB-Vets hinzu) kann von einem VB oder höher für eine VB-Wahl vorgeschlagen werden; Veteranen brauchen demnach erstmal die Stimmberechtigung
2. Bevor die Wahl auf der gesonderten Wahlseite vom VB+ aus Punkt 1 gestartet wird, wird dies auf Discord in #intern angekündigt. Hier können Admins (bei Unstimmigkeiten auch Reds) die Wahl noch stoppen. Durch diese Maßnahme entfällt das Vetorecht der Admins. Ein Grund für den Abbruch der Wahl kann, aber muss nicht mitgeteilt werden. (Mit wie viel Vorsprung die Ankündigung gemacht werden soll hab ich keine Ahnung)
3. Die Wahl dauert zwischen 1 und 3 Wochen. Sobald 2/3 für Pro erreicht sind, wird der SB zum VB befördert
4. Wer stimmt ab: Alle VB+ (Admins und Reds sollen/müssen, VBs und PLs sind dazu aufgefordert ihren Senf dazu zu geben)
5. Was ist mit den SBs?: Diese werden nicht in die Wahl eingebunden, da diese größtenteils nicht einschätzen können, ob ein SB zum VB werden soll. Allerdings haben sie die Möglichkeit wie bei der Red-Wahl den Kommentarbereich zu nutzen.
6. Wenn ein VB direkt Wahl zum PL werden würde: Macht da was ihr denkt. Sollte jemals dort was schief laufen komm ich um die Ecke mit einem „Hab ichs euch doch gesagt.“?
7. Ich hoffe ich habe jetzt nichts vergessen. Falls doch: Mist!

Soweit erstmal mein Gedanke zu dem Thema. Vielleicht kann man ja irgendwas davon nutzen oder bei ner Lücke, die ich übersehen habe, noch ausbessern. Ich hoffe einfach mal, dass wir das Thema nicht ins nächste Jahr mitnehmen werden müssen. GrollenKette951 22:03, 14. Nov. 2020 (CET)

Hieß es irgendwo, dass Veteranen ohne SB vorgeschlagen werden können? Zumindest ich hatte immer SBs als Wahl-Kandidaten genommen und da zähle ich Vet-SBs dazu, Vet und SB sind ja separate, voneinander unabhängige Ränge. Den zweiten Punkt sehe ich am kritischsten. Denn der hat das meiste Intransparenz- und Konflikt-Potenzial und ist recht schwammig formuliert. Inwiefern kann die Wahl gestoppt werden? Welche nötigen Mehrheiten usw.? Zum vorletzten Punkt: Ich verstehe immer noch nicht warum potentielle Neu-PLs eine Sonderbehandlung kriegen sollten. Natürlich sollte angemerkt werden, dass der Kandidat bei Erfolg direkt PL werden würde, aber ich sehe absolut keinen Sinn dahinter eine Wahl für einen Rang zu überspringen, der Grundvoraussetzung für PL ist. Und wenn der User nicht durchkommt, bleibt das Projekt halt ohne PL. Mit den aktuellen VBPL-Ernennungsbestimmungen würde ein PL-Kandidat ja auch nicht unabhängig von seiner VB-Eignung einfach direkt eingesetzt werden. Ob du immer noch der Ansicht bist, weiß ich nicht. Du hast aber mal vor geraumer Zeit ein Überspringungsrecht für PL-Kandidaten gefordert. --DeXter 22:49, 14. Nov. 2020 (CET)

Trivia: Bezüge aus der realen Welt

Liebe Mitwikinger, auf dem Discord-Server kam eine Diskussion zu Triviapunkten auf, die sich auf die Welt außerhalb des Pokémon-Franchise beziehen, z. B. wenn ein Pokémon oder das Pokémon-Franchise an sich Erwähnung in Serien, Quizshows, Nachrichten, der Forschung etc. finden. Daraus ließen sich vielleicht Richtlinien ableiten, weshalb ich die Diskussion hier kurz zusammenfassen und zur Kommentierung bereitstellen möchte. :) Zunächst zur Ausgangslage: Mit der Popularität von Pokémon geht einher, dass es häufig Bezüge zum Franchise in anderen Medien gibt. Diese Informationen sind witzig und für Leser interessant, zudem feiern sie das Franchise, von dem das Wiki lebt, daher müssen sie aus meiner Sicht unbedingt im Wiki aufgenommen werden. Andererseits würden wir uns einen Wolf recherchieren, wenn wir jede denkbare Erwähnung zitieren wollten. Folglich muss ein Mittelweg gefunden werden, der relevante Erwähnungen benennt. Nachfolgend meine Gedanken dazu, was sich hinter dem "Relevanz"-Begriff verbergen könnte:

• Wir sollten keine Medien mit Gaming-Kontext zitieren, die sich direkt auf das Pokémon-Franchise beziehen, also keine Gaming-Newsseiten oder -Youtube-Videos, keine Nachrichten über neue Spiele-Erscheinungen, keine Let's-Play-Videos, etc. Die haben meiner Meinung nach keinerlei Informationswert, der über die tatsächlichen Spieleinhalte oder offizielle Ankündigungen hinausgeht.
• Wir sollten nicht jeden Bezug, der aus dem Nintendo-Universum kommt, zitieren. Ich würde mich bei Nintendo-Spielen auf unerwartete Easter Eggs beziehen. Bezüge aus nintendofernen Spielen, die quasi nicht davon profitieren, Pokémon zu zitieren, finde ich hingegen immer interessant und zum Schmunzeln, unbedingt aufnehmen. Vermutlich ist aber ein Fokus auf Nicht-Indie-Titel sinnvoll.
• Ich würde im deutschsprachigen Wiki nur Bezüge aus dem deutschsprachigen Raum oder zumindest aus Medien mit deutscher Sprachversion aufnehmen. Darunter fallen für mich auch Quizfragen aus deutschsprachigen Quizshows, mich würde es z. B. interessieren, wenn Pokémon einen Auftritt bei Wer wird Millionär hätte.
• Bezüge aus bekannten Fernsehserien oder Filmen finde ich selbstverständlich. Die Frage, was Bekanntheit bzw. Relevanz ausmacht, wird man nie final klären können, da es subjektiv ist. Hier denke ich aber, dass es Fälle geben wird, die jedem selbstverständlich als relevant vorkommen, und Erwähnungen, die selbstverständlich irrelevant sein werden. Im Graubereich würde ich wie üblich verfahren: Wenn es wer einträgt und keiner beschwert sich, war es relevant genug, und falls eine Diskussion aufkommt, führt man sie eben. Wie überall sonst im Wiki auch. Die Existenz eines Graubereichs darf uns aber nicht dazu verleiten, alles von vorneherein auszuschließen und nur ne lahme Minimallösung ohne Erwähnungen in der realen Welt zu fahren, das fände ich für die Artikel sehr schade. Ich glaube auch, dass der Graubereich sich als kleiner herausstellen wird, als mancher befürchtet, wenn die vorgeschlagenen Regeln verbindlich gelten und mögliche Trivia-Punkte deutlich einschränken.
• Weitere Richtlinien lassen sich gegebenenfalls ja ergänzen, wenn sich sinnvolle Kriterien auftun.

Was denkt ihr, macht es Sinn, solche Richtlinien zu verabschieden und irgendwo festzuhalten? Liebe Grüße, Maxmiran 11:38, 29. Sep. 2020 (CEST)

Wichtig wäre für mich ein dauerhafter Prüfbarer Beleg. Wenn heute wer schreibt, Dienstag abend den x.ten war Glumanda eine mögliche Lösung bei der Fernsehsendung Y. Dann muss in einem Monat das ganze noch Belegbar sein. Entweder durch Screenshots oder anderem. Und davon ab, weiß ich nicht ob sowas überhaupt in diesen Abschnitt gehört. Gibt es keine sinnvollere Lösung/Abschnitte außer Trivia? * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 11:49, 29. Sep. 2020 (CEST)

Ich halte es fragwürdig das ganze als Triviapunkte aufzunehmen, das wird bei beliebten Pokémon (Pikachu, Glurak, die Kanto-Starter, Mewtu etc.) doch eher dazuführen das die Triviapunkte ellenlang werden. Ausserdem wird es garantiert Anspielungen geben, die sich nicht wirklich auf einen Artikel in unserer Struktur beziehen, sondern auf Sachen im Pokémon-Franchise generell. Aus diesem Grund fände ich hier ein Verfahren, wie es Bulba hat, besser geeignet: Einfach einen Artikel für die Anspielungen in anderen Medien. In diesem müsste man sich dann imo. nicht mehr auf deutschsprachige Medien reduzieren. Forschung kann imo. auch einen eigenen Artikel bekommen, da wird es garantiert auch genug zu geben. Vermischen würde ich die beiden aber nicht. Einige klar-zuordnbare Forschungssachen können imo. auch in den Triviapunkten bleiben (z. B. der Aerodactylus) aber bei Anspielungen in Medien würde ich eher davon absehen. --Datei:Sugimori 672.pngMecanno-man^Mäh 12:18, 29. Sep. 2020 (CEST)

@Ryuichi: das mit der Prüfbarkeit kann ich nur unterschreiben! Zum eigenen Abschnitt: Bei Pikachu z. B. gibt es eine eigene Zwischenüberschrift für das Thema bei den Trivia. Ich fände es in diesem Fall auch schick, da einen eigenen Abschnitt draus zu machen, aber da halte ich Pikachu für einen Sonderfall. Bei den meisten Pokémon wird es da, wenn überhaupt, vielleicht einen oder zwei Stichpunkte geben, dafür dann einen neuen Abschnitt in die Musterstruktur einzuziehen finde ich zu viel des Guten.

@Mec: ich kann nachvollziehen, was du meinst. Ich denke jetzt mal aus der Perspektive der Pokémon-Artikel, weil ich mich dort am ehesten zu Hause fühle: Ich finde die Lösung von Bulbapedia deswegen nicht schön, weil sie die Pokémon-Artikel verarmt. Wenn ich z. B. Glurak-Fan bin und den Artikel von Glurak nach allen möglichen Auftritten von Glurak durchstöbere, dann würde ich mich als Leser über diese Bezüge zu Glurak am Ende des Artikels freuen, während sie in einem eigenen Artikel versauern würden. Ich bin also zumindest dafür, die Bezüge zu einzelnen Pokémon in die Pokémon-Artikel zu packen. Bezüge zum Franchise an sich, da bin ich indifferent, die werden aber gegenüber den spezifischen Pokémon-Bezügen eher nicht ins Gewicht fallen, würde ich schätzen. Maxmiran 15:35, 29. Sep. 2020 (CEST)

Ich denke das es neben Pikachu auch viele andere Populäre Pokémon geben wird, und mMn spricht nichts dagegen bei einer Musterstruktur auch optionale Punkte einzufügen. z.b. Pokémon hat mehr als wie 5 Auftritt dann Abschnitt sonst Trivia oder what ever. Und diese sogenannte Übersicht von Mec halte ich für keine schlechte Idee. Man listet dort die Auftritte und z.b. der Glurak-Fan liest bei Glurak das es Symbolpokémon beim Indischem Curry hersteller XY war -> weitere Details auf Seite ABC. Denke das ist eine Option die Punkte in den teils überfüllten Dexartikeln kurz und knapp zu halten und die zusätzliche Seite zu promoten. * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 15:51, 29. Sep. 2020 (CEST)

Interessante Diskussion! Ich würde mich ebenfalls freuen, wenn wir solche Punkte (weiterhin) im Trivia-Bereich des jeweiligen Artikels unterbringen. Die von Max vorgeschlagenen Richtlinien halte ich schon für äußerst gut überlegt und dafür anwendbar. Des Weiteren stimme ich ebenfalls mit Ryu überein und plädiere an dieser Stelle auch für Belege dieser Umstände. Das wird sonst für mich und jeden anderen kontrollierenden Benutzer eine Qual, die Punkte auf eigene Faust herauszusuchen und somit zu prüfen. Aus diesem Grund bietet sich ein Screenshot an. Bei generellen Verweisen bin ich mir aber auch noch nicht ganz sicher, wie man das gestalten sollte. Entweder man sagt, diese sind zu unspezifisch und bedürfen daher keiner Erwähnung oder man sammelt nur diese in einem eigenen Artikel. Darüber hinaus sollten wir uns an der Stelle nicht zu sehr festlegen, wie das Ganze im Zweifel auszusehen hat, wenn x Punkte vorhanden sind. Vielmehr erstmal schauen, was das überhaupt für ein Ausmaß annimmt und dann Einzelfallentscheidungen treffen, denn mehr als z. B. zehn Pokémon-Artikel wird das ohnehin nicht betreffen. Ich könnte es mir beispielsweise gut vorstellen, dass sich gleichende Bezüge auch zusammengefasst werden können: „Glurak ist in verschiedenen Quizshows, u. a. Wer wird Millionär?, Teil einer Frage gewesen. ^{[1], [2], [3], [4]}“ Somit vermeidet man sowohl Dopplungen als auch einen neuen Unterabschnitt, der evt. nur sieben verschiedene Fragen aus Quizshows listet, bei denen Glurak eine Antwortmöglichkeit gewesen ist.

Ich bin mir also sicher, dass wir für diese wenigen Fälle kreative Lösungen finden werden. :) ~ Taisuke ^Diskussion 11:19, 30. Sep. 2020 (CEST)

Umfragen auf der Hauptseite

Hallo, Wikinger! Ich habe das vor einigen Chattreffen schon mal angesprochen, jedoch ist es seit dem wieder in Vergessenheit geraten, weswegen ich es jetzt nochmal aufrolle. Es geht um die Idee einen Umfragen-Block auf der Hauptseite einzubauen. Inspiriert wurde ich von dem MarioWiki und dessen Hauptseite. Somit können wir interessante Informationen und Meinungen sammeln und sie auch auswerten. Thematisch könnte man sowohl aktuelle Ereignisse thematisieren (wie bspw: „Wie findet ihr die ersten Open World-Konzepte aus Schwert und Schild?“) oder allgemeinen Pokémon-Fragen (wie bspw. Was ist dein Lieblingstyp?). Diese Umfragen sollten im „Ankreuz“-Verfahren laufen, wie halt auch im Beispiel des MarioWikis. Ich weiß leider natürlich nicht, wie aufwendig eine solche Abstimmung ist und ob es überhaupt umsetzbar ist. Wünschen würde ich es mir auf alle Fälle und wie es sich auf Discord schon rumgesprochen hat, wären auch viele andere daran interessiert. Theoretisch könnte man diesen Block zum Wds-Projekt packen, da ich glaube, dass das dort am besten hin passt. Ich würde natürlich auch aktiv versuchen mitzuwirken, wird ein solches Konzept wirklich durchgezogen. - -wowoJonny 17:21, 4. Okt. 2020 (CEST)

Finde die Idee grundsätzlich erst mal nicht schlecht, suche gerade aber noch den Sinn dahinter. Ist es einfach nur das Ziel, die Besucher mit einzubinden? Denn aus den von dir genannten Beispiel-Fragen geht nichts hervor, wovon wir irgendwas haben. Zu wissen, was den Leuten an den Spielen gefällt oder welche Pokémon/Typen/sonstiges sie mögen hat für uns keinen Vorteil, wir können an den Spielen nichts ändern und sowas wie Lieblings-Pokémon ist ganz brutal gesagt einfach nur Datenmüll ohne jeglichen Wert. Der Gedanke, das stattdessen fürs Wiki zu nutzen, will mir dabei nicht wirklich gefallen, zwar könnte man da erfragen, wie den Leuten Konzepte für Artikel gefallen, aber ich mache mir Sorgen, dass dann entweder nur negative Meinungen kommen, weil den Leuten, denen es gefällt, sich nicht zu Wort melden, oder das ganze einfach generell nicht repräsentativ ist. Im schlimmsten Fall wirkt das eher demotivierend auf Benutzer, die viel Zeit in den Entwurf und die Umsetzung solcher Konzepte gesteckt haben. Sehe daher wenig bis keinen Nutzen oder zumindest ein gewisses Risiko darin. -- RobbiRobb 17:31, 4. Okt. 2020 (CEST)

Ich frag mich etwas, ob es eventuell für Projekte je nach Thema der Umfrage interessant sein könnte. Z.B. für XdW: „Was ist eure Lieblingsregion?“ → AdW zur Region. Aber da kommt es eben sehr auf die Art der Frage an. Ich hätte daher gern noch ein paar Beispiele. Danke Das Isso 08/15 ^Konter 19:24, 4. Okt. 2020 (CEST)

Stimme generell Robbi zu. Ich wüsste nicht, was man mit den erhobenen Daten machen sollte, und Daten erheben einfach nur der Erhebung willens ist nicht sinnvoll, insbesondere da man dabei wahrscheinlich dann irgendwelche Datenschutz-Gesetze zusätzlich beachten müsste. Wenn Daten erhoben werden dann sollten diese auch irgend einen Zweck haben. Und für Wiki-relevante Umfragen halte ich die Hauptseite als Plattform für ungeeignet, da es garantiert sehr viele Leute gibt die die Hauptseite nicht jedes Mal durchscrollen werden wenn sie das Wiki besuchen. Ausserdem müsste man dann ständig irgendwelche Konzepte überdenken nur um da ne Umfrage zu haben, was nicht Ziel von Konzeptänderungen sein sollte. Ausserdem, wer würde sich um die vielen daraus resultierenden Umstrukturierungen kümmern? Das also als fixen Block hinzustellen scheint mir für non-wiki-Angelegenheiten sinnlos und für wiki-Angelegenheiten langfristig schädlich.

Die Idee war imo. gut gemeint, aber eignet sich eher für Social Media, was die Hauptseite nicht ist. --Datei:Sugimori 672.pngMecanno-man^Mäh 19:29, 4. Okt. 2020 (CEST)

vielleicht ist das unser Problem... das Wiki ist für viele was zum Lesen ohne Community, Discord ist rein für Community. Vielleicht lässr sich mit allgemeinen Fragen Leute ins Wiki ziehen... z.b. im Social Media wird eine Umfrage beworben die im Wiki steht. z.b. Wie gefällt euch Galar-Lavados? Schaut in unseren Artikel. Haben wir dort sogar noch etwas vergessen? Helft mit den Artikel zu füllen.... So ne Art Impuls zum Mitmachem in einer allgemeinen Umfrage. Die Grundidee der Umfrage finde ich nicht schlecht. Frage ist nur wie wir es im Wiki fürs Wiki und für die Community nutzen.* Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 21:57, 4. Okt. 2020 (CEST)

Ich hab ehrlicherweise weder hier im Wiki noch auf Social Media einen Plan wofür man solche Daten benutzen sollte. Was bringt es uns zu wissen wie vielen Leute welches Pokémon, welche Gen oder welches Spiel gefällt? Und weiterhin sehe ich auch keinen Fall, in dem ein etwaiger Zeitaufwand die HS umzubauen und eine Extension zu basteln einen Mehrwert für das Wiki haben könnte. Da Ryu jetzt hier noch vor mir geantwortet hat, werde ich das hier erst mal speichern und später noch was schreiben. GrollenKette951 22:02, 4. Okt. 2020 (CEST)

Ich verstehe eure Kritik hinter dem Sinn, aber gleichzeitig finde ich den Vorschlag von Ryu und Isso ziemlich super. Zu einem können wir Leute dazu anregen die Artikel auf Inhalte zu korrigieren und zu vervollständigen und andererseits kann man diese Umfragen als Hilfe für AdWs nutzen. Der eigentliche Sinn meinerseits soll dabei die Kommunikation mit der Community sein und etwas mehr Nähe zu ihr aufzubauen. Mir persönlich zumindest gefällt es immer mehr wenn die Wikis Nähe zu der Community finden, damit auch diese Leute merken, dass hier Menschen arbeiten. Ich glaube euch, dass das nicht einfach umzusetzen ist, aber ich glaube auch, dass sich das auszahlen wird, grade da sich Leser über sowas freuen würden (ich habe die Idee auch einigen Leuten im privaten Umfeld erklärt, die sich so etwas gerne wünschen). - -wowoJonny 08:24, 5. Okt. 2020 (CEST)

Wenn es um Vorschläge wie diesen geht, habe ich eigentlich stets ein offenes Ohr. Der erste Part bezieht sich auf die Argumentation im Sinne einer Motivation zum Mitmachen: Mir leuchtet nicht ein, wieso wir nun an einer zweiten möglichen Stellschraube drehen wollen, die neue Leute bzw. einfache Seitenbesucher zum Mitmachen motivieren soll, wenn wir unsere erste Stellschraube nach mittlerweile fast zwei Jahren noch immer nicht gedreht haben. Wir wissen noch nicht, wie sich die Stellenanzeigen am Ende auswirken und vielleicht stellen wir durch diese fest, dass die Hauptseite für solche Vorhaben ohnehin schlecht gewählt ist. Oder aber sie fruchten und es braucht keine weitere Idee, die ein ähnliches Ziel verfolgt.

Darüber hinaus sehe ich auch keinen Nutzen für die dadurch erhobenen Daten. Sie sind weder für Artikelinhalte nutzbar, da sie keineswegs aussagekräftige Daten darstellen werden, noch werden wir dadurch konstruktiven Input aus der Community zu Veränderungen erhalten. Dafür bräuchte es mehr als ein einfaches Ankreuzen vorgeschriebener Antworten, sondern dann würde ich mir individuelle Begründungen und Verbesserungsvorschläge wünschen. Denn damit kann ich am Ende als Benutzer auch arbeiten. Dies werden wir aber wohl hierüber nicht in Erfahrung bringen können.

Dann wäre da noch das Argument, dass man die Daten für das XdW-Projekt nutzen könnte. Dem Projekt mangelt es neuerdings nicht an geschriebenen Texten und floriert seit einiger Zeit ungemein. Die Knappheit an Texten kann hier also nicht der Ausschlag sein. Und auch Umfragen wie „Was ist eure Lieblingsregion?“, die dann zu einem AdW führen sollen, sehe ich nicht gewinnbringend für uns. Denn am Ende der Umfrage, schreiben dennoch dieselben Leute die Texte. Wenn es ganz doof läuft, fühlt sich dabei dann auch wieder jemand an die Challenges bei Filb erinnert, wo uns quasi nur vorgegeben wurde, wozu ein Text geschrieben werden musste und die eigentliche Arbeit bleibt dann trotzdem an den Projektmitgliedern und der Leitung hängen. Oder übersehe ich hier etwas?

Versteht mich nicht falsch, ich finde es toll, dass sich Gedanken gemacht werden, wie man das PokéWiki mehr als Community nach außen darstellen kann. Ich sehe aber aus den oben genannten Gründen nicht, wie das eine Umfrage auf der Hauptseite leisten können soll. Ich würde mich auf jeden Fall nicht als Teil einer Community sehen, nur weil ich ich wöchentlich/monatlich bei einer zufälligen Umfrage eine „Ein-Klick-Antwort“ abgebe. Es braucht da in meinen Augen eher einen anderen Ansatz. ~ Taisuke ^Diskussion 22:05, 5. Okt. 2020 (CEST)

Auch ich stehe dem Vorschlag skeptisch gegenüber. Bei den XdW-Umfragen würde mMn sogar eine Distanz zwischen Wiki und Community aufgebaut werden. Denn anstatt, dass man die Leute motiviert z. B. zu ihrem Wunschthema ein XdW selbst zu schreiben, wäre mit so einer Umfrage dann das aktive von XdW-Autoren übernommen, was Leute gar nicht erst aus dieser passiven Haltung gegenüber Wikis bringen könnte. Feedback zu Artikeln über Umfragen verursachen hört sich interessant an, aber ich bin mir unsicher, wie hilfreich die Rückmeldungen sein werden. Einfach Umfragen im Wiki machen ohne einen direkten Zweck fürs Wiki zu haben, bin ich kein Freund von. Für ein Forum ist das sicherlich was, da die nunmal die Community als Hauptziel haben, aber bei uns ist das nicht der Fall.

Außerdem wäre die Umsetzbarkeit alles andere als leicht. Ich erinnere mich schwach gelesen zu haben, dass man Teile von Spezialseiten in Artikel einbinden kann, das könnte viell. eine Lösung sein (der liebe Skel weiß da bestimmt mehr), aber von den Stellenanzeigen wissen wir auch noch wie "einfach" Änderungen an der Hauptseite zu beschließen sind. So eine Extension zu schreiben, die Änderung an der Hauptseite zu beschließen und umzusetzen ist mMn zu großer Aufwand im Vergleich zum möglichen Nutzen. Wenn man diese Umfragen leicht umsetzen könnte (wie, ich denke mal, auf Social Media) wäre das sicher interessant, aber im Wiki ist da mMn das Kosten-Nutzen-Verhältnis nicht gut genug. --DeXter 09:13, 6. Okt. 2020 (CEST)

Ich möchte nicht der nächste sein, der dir den Wind aus den Segeln nimmt, Jonny, aber aus schon genannten Gründen (für mich ist das Hauptargument Datenschutz, wo Besucher wirklich ein Fass aufmachen können) spreche ich mich gegen eine Umfragefunktion innerhalb des Wikis aus. Allerdings finde ich, dass die Idee durchaus auf unseren Social Media Kanälen genutzt werden und Menschen dazu anregen kann, hier mitzuhelfen. Wie das aussehen soll, muss ich noch überlegen. Sobald mir eine Idee kommt, werde ich nochmal schreiben. Feblue 16:38, 8. Okt. 2020 (CEST)

sīc erat scriptum

Hallo zusammen!

Ich weiß nicht, wie vielen von euch die Überschrift etwas sagt bzw. ob euch allen im PokéWiki bereits ein (versteckter) Hinweis in Form von [sic] oder auch <!--sic!--> aufgefallen ist. Jedenfalls wird so darauf hingewiesen, dass die unmittelbar vorangehende Stelle zwar korrekt zitiert wurde, aber dadurch beispielsweise ein Rechtschreibfehler beabsichtigt übernommen wurde. Dadurch gewährleisten wir Zitate bzw. Texte jeglicher Art (in Spielen, auf Karten und so weiter) dem Original gegenüber nicht zu verändern, aber trotzdem darauf hinzuweisen, dass dadurch beabsichtigt ein Fehler übernommen wurde. So viel zur Erklärung des Hinweises.

Mein Anliegen diesbezüglich ist nun, dass mich die uneinheitliche Darstellung wurmt. Ich bin kein Fan davon, diesen Hinweis nur im Quelltext versteckt anzugeben und ebenso stört es mich, dass in Texten uneinheitlich mit [sic!], [sic] oder auch (sic) gearbeitet wird. Hin und wieder ist es dann noch kursiv geschrieben, damit es sich etwas vom normalen Text abhebt. Mit anderen Worten: Es gibt Änderungsbedarf!

Daher ist mein Vorschlag, eine kleine Vorlage anzulegen, die zum einen sicherstellt, dass solche übernommenen Fehler aus Zitaten für jeden Leser ersichtlich sind und zum anderen niemand erst einmal nachschlagen muss, wofür diese Abkürzung denn überhaupt steht. Darüber hinaus sollte der Hinweis vom restlichen Text klar abgegrenzt sein und durch die Vorlage eine einheitliche Handhabung ermöglichen.

Beispiel: Beschreibungstext der sechsten Spielgeneration von Zwango

„Anwender tanzt zu einem seltsamem^[sic!] Rhythmus und zwingt das Ziel mitzumachen. Dieses nimmt dabei die Fähigkeit des Anwenders an.“

Durch die Hochstellung hebt es sich vom eigentlichen Text ab und hovert man über den Hinweis wird eine Erklärung angezeigt.

Das ist jedoch nur ein Vorschlag meinerseits, der natürlich nicht nur auf Zustimmung treffen muss, sondern auch gerne (vorlagentechnisch) weiter verfeinert bzw. angepasst werden könnte. Vielleicht bin ich sogar der einzige, dem das etwas ausmacht und sich daran stört, oder ihr seid alle der Meinung, dass ein solcher Hinweis allgemein nur versteckt in den Quelltext gehört. Wobei mich Letzteres etwas verwundern würde, da es nicht gerade benutzerfreundlich für Seitenbesucher ohne Account wäre. ^_^

Aber bevor ich hier jemandem noch etwas vorwegnehme: Her mit euren Meinungen dazu. :D ~ Taisuke ^Diskussion 16:27, 28. Okt. 2020 (CET)

Der Vorschlag mit Einheitlichkeit hat meine Unterstützung. Auch dein Beispiel gefällt mir. Hat nur eine Problematik. Funktioniert Mobil nicht. * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 16:47, 28. Okt. 2020 (CET)

Wir haben doch Vorlage:Anmerkung, die kann auch ihr Symbol verändern. Etwas richtung [sic!] wäre hier also durchaus realisierbar und würde auch mobil funktionieren. Sieht allerdings nicht perfekt aus, wobei man natürlich auch ohne diese Vorlage eine ähnliche Vorlage bauen könnte, die nicht so komisch aussieht. -- RobbiRobb 16:53, 28. Okt. 2020 (CET)

Das komische sind hier nur die Klammern...sic! ohne würde es mMn auch passen * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 17:26, 28. Okt. 2020 (CET)

Das Anmerkungs-Ding mag ich nicht wirklich, da fände ich simplen hochgestellten Text besser. Wüsste nicht warum das jetzt in nem Oval stehen braucht. Grundsätzlich wär ich auch dafür da ne Vorlage zu haben, vergesse nämlich jedes Mal wenn ich das nutze wie's andererorts gemacht ist, wodurch wahrscheinlich auch Teile der Uneinheitlichkeit her rühren.

Eine Kurze Anmerkung an den, der das dann ersetzen geht (ich hoffe mal Tai, da er's angesprochen hat :hihi:) - bei <!--sic!--> handelt es sich auch um ein uraltes Steuerding für einige Bots, wodurch diese diese Seiten ignorierten. Ich glaube nicht das wir noch Bots haben, die das beachten, aber man sollte eventuell mal nachfragen. Generell: Wenn ihr da also ein sic für gar nix seht ist es wahrscheinlich so ein uraltes Bot-Ignorier-Flag. --Datei:Sugimori 672.pngMecanno-man^Mäh 17:49, 28. Okt. 2020 (CET)

Wie gesagt: Das sieht nicht perfekt aus, kann man aber noch ändern; es ging mir hauptsächlich darum, dass Tooltip verwendet wird, weil das mobil optimiert ist, im Gegensatz zu nem einfachen hochgestellten Text. Außerdem hat das am PC nen veränderten Cursor, der darauf aufmerksam macht, dass da was steht. -- RobbiRobb 18:21, 28. Okt. 2020 (CET)

Ich würde auch das Ausrufezeichen rausnehmen. mMn sollte da nur sic stehen und nicht noch irgendetwas anderes, weil die Hochstellung, die ich als sehr passend empfinde, das sic schon genug hervorhebt. Ich hätte nichts gegen das Oval, aber ich hätte auch kein Problem damit, wenn man eine Vorlage baut, die das Oval nicht beinhaltet. Allerdings muss ich da noch erwähnen, dass es schon irgendwie erkenntlich sein muss, dass man da draufklicken kann, ansonsten ist der gewollte Nutzen nicht gegeben, weil ich mir vorstellen kann, dass man da nicht unbedingt drauf kommt, dass da ein Hinweis versteckt ist. Feblue 00:02, 29. Okt. 2020 (CET)

Ich finde es sehr cool, dass in so kurzer Zeit für mich unerwartet viel Input zu dem Thema gekommen ist. Danke! Grundsätzlich habe ich auch ein wenig mit Vorlage:Anmerkung herumgespielt, aber war vermutlich zu starr und habe die Chance nicht gesehen, weg von den Klammern und dem Ausrufezeichen zu gehen. Wenn man das dann weglassen würde, wäre das für mich fein. Darüber hinaus wäre ich bei Robbi und würde die Verwendung von Tooltip bevorzugen. Letzten Endes ist das jetzt ja auch nichts, was sehr wichtig oder omnipräsent im PokéWiki vorhanden ist. Daher muss es für mich auch kein Meisterwerk werden. Es würde mir sosic bereits vollkommen ausreichen. ~ Taisuke ^Diskussion 10:39, 29. Okt. 2020 (CET)

Bevor das Vorhaben wieder in der Versenkung verschwindet, weil ich momentan nur eingeschränkt Kapazitäten für das Wiki habe, habe ich die Vorlage nun einfach erstellt und an allen Stellen eingesetzt, die ich gefunden habe. Falls ihr etwas finden solltet, was mir entgangen ist, würde ich mich freuen, wenn ihr das an der Stelle dann auch einfügt. Ansonsten bleibt nur noch zu sagen, dass bei einer Unzufriedenheit mit dem Aussehen der Vorlage oder ähnlichem, natürlich auch gern weitere Anpassungen vorgenommen werden können. Mir war nur wichtig, dass wir erstmal eine einheitliche Kennzeichnung am Start haben. ;)
Ich war mir jedoch in Bezug auf verschiedene Punkte unsicher: Inwiefern z. B. die Kategorie des Pokédex-Eintrags von Geckarbor (Anime) als ein solches falsches Zitat gekennzeichnet werden sollte, da es im Anime einfach schlichtweg oft falsche Begrifflichkeiten gibt, die so dann leider synchronisiert wurden. Man denke zum Beispiel an die ganzen Attackennamen etc. Hier müsstest du also eine Entscheidung treffen, Robbi, ob du so etwas überhaupt kennzeichnen würdest. Auch beim Brückbrief W musst du schauen, da dort nur uneinheitlich in den Spielbeschreibungen der Hinweis zu finden ist. Bei den beiden Artikeln habe ich also die Vorlage noch nicht eingebunden.
Und für Mec wären bei Zitaten Alfried, Cynthia/Zitate, Erika, Frohderich/Zitate und Ruhmesdatei interessant, da dort das Wort „öfters“ gekennzeichnet wurde, was aber nicht wirklich ein Fehler sein sollte, siehe hier. Da müsstest du also nochmals schauen, ob du den Hinweis an den Stellen entfernst. ~ Taisuke ^Diskussion 09:47, 6. Nov. 2020 (CET)

Beim Brückbrief W lässt man mir scheinbar keine Mitbestimmungsmöglichkeit; BlauesSerpiroyal hat das ganze dort bereits einfach angepasst. Werd ich jetzt vorerst einfach so stehen lassen, grundsätzlich sollte man das vermutlich überall so machen, im Moment hab ich aber definitiv nicht die Zeit, 17k Item-Beschreibungen auf korrekte Schreibung zu prüfen. Bei Geckarbor hab ich das aber mal rausgenommen, generell halte ich es im Anime für nicht sonderlich sinnvoll, da passt ohnehin die Hälfte nicht. -- RobbiRobb 11:24, 6. Nov. 2020 (CET)

Entschuldigung, ich hab nur gesehen, dass es dafür eine Vorlage gibt und dass die da noch nicht war. BlauesSerpiroyal ^Diskussion 11:34, 6. Nov. 2020 (CET)

Hab die sics bei öfters mal entfernt (und Killuu ne DM geschrieben, das das Wort existiert...).

Was das ganze angeht, wirklich überzeugt bin ich da noch nicht von, besonders da das sic im Oval bedingt durch Vorlage:Zitat häufig kursiv ist. Ganz vom Oval abkommen würde ich allerdings doch nicht mehr, da mit oval es deutlich erkennbarer ist, das da ein tooltip existiert. Im Grunde genommen ist das also nur noch meckern, ohne das ich ne bessere Lösung hab - ignoriert mich also, ausser ihr habt selber gerade nen Geistesblitz wie ihr mich zufriedenstellen könnt. (...wobei, ist es technisch machbar, Schrift innerhalb von nem italic als non-italic zu markieren...?) --Datei:Sugimori 672.pngMecanno-man^Mäh 19:13, 6. Nov. 2020 (CET)

Kurzer Einwurf zur Behandlung von „öfters“: Ja, das Wort existiert, allerdings ist es in Deutschland inkorrekt. Nur in der Schweiz und in Österreich soll es das Wort geben. Daher meine Frage: Wurde / Wird im PokéWiki das Vokabular des gesamten deutschsprachigen Raums angewandt oder halten wir uns nur an das deutsche Wörterbuch? Ich fände da eine einheitliche Regelung sehr sinnvoll. -- Feblue 20:11, 6. Nov. 2020 (CET)

Der Duden nennt da auch „landschaftlich“, und abgesehen von dem einen Ruhmesdatei-Eintrag haben die Charaktere einen ländlichen Hintergrund, sehe jetzt da keinen Grund das als falsch zu bezeichnen. Und für den einen Ruhmesdatei-Eintrag will ich jetzt auch nicht wirklich n sic drin haben, ansonsten packt das noch wer in den anderen wieder rein... --Datei:Sugimori 672.pngMecanno-man^Mäh 23:49, 6. Nov. 2020 (CET)

Falls mein letzter Diskussionsbeitrag wie eine Aufforderung zum Durchforsten aller Item-Beschreibungen rübergekommen ist, dann tut es mir leid. Denn das war nicht meine Absicht, Robbi. Ich wollte die Handhabung bei dem expliziten Einzelfall nur nicht ohne Rücksprache mit dir einfach alleine entscheiden.

Darüber hinaus scheint es eine interessante Diskussion zu sein, was wir genau bei Zitaten als richtig ansehen. Das Bestreben nach einem einheitlichen Vokabular bzw. einer damit einhergehenden Regelung kann ich nachvollziehen, sollte jedoch bei Bedarf eher separat nochmals aufgearbeitet werden. Hier geht das Ganze dann doch eher unter. Wobei ich ohnehin das Gefühl hätte, dass dort jetzt nicht unbedingt eine Vielzahl an Benutzern an der Diskussion teilnehmen würde.

Ansonsten ist mir noch aufgefallen, dass bei einigen Vorlagen-Verwendungen nicht unbedingt ersichtlich ist, warum der Hinweis dort zu finden ist. Beispielsweise wenn vor einem Komma ein Leerschritt zu finden ist, obwohl im Deutschen dort keiner zu sein hat. Vielleicht könnte man dort im Quelltext bei der Vorlagenverwendung noch irgendwie eine Art Begründung mit einbauen, um es ersichtlich zu machen, worin der Fehler des Zitats liegt. ~ Taisuke ^Diskussion 16:10, 11. Nov. 2020 (CET)

Nein, keine Sorge, so kam das nicht rüber. Ich habe einfach von meiner Seite aus darauf aufmerksam machen wollen, dass es eben nicht einheitlich ist bei den Items, ich weiß, dass an einigen Stellen Fehler drin stehen, die nicht markiert sind, daher gehe ich davon aus, dass es noch viele weitere - für die ich aber wie gesagt nicht die Zeit habe, sie alle zu finden. -- RobbiRobb 16:36, 11. Nov. 2020 (CET)

Vorstellung: Pokémon-Zuchtrechner

Hallo zusammen!

Ich habe eine Idee für eine neue interaktive Seite im PokéWiki: Ein Rechner, der bei der Zucht kompetitiv brauchbarer Pokémon hilft, indem er die Wahrscheinlichkeiten für bestimmte Zuchtergebnisse berechnet.

Und damit niemand denkt, ich würde irgendjemanden mit der vollständigen Implementierung eines solchen Zuchtrechners beauftragen wollen, gleich zu Beginn: Es geht hier nicht um die Entwicklung eines völlig neuen Rechners, sondern um die Einbindung eines existierenden Rechners ins PokéWiki und die Anpassungen, die dafür gemacht werden müssen. Als jemand, der gerne Pokémon züchtet und dabei so effizient wie möglich vorgehen möchte, habe ich einen solchen Zuchtrechner vor einiger Zeit für mich selbst entwickelt und ihn erst in Excel und später zusammen mit einer rudimentären HTML-Seite in JavaScript implementiert, vor Kurzem habe ich dann noch einige Verbesserungen eingefügt. Alle Nutzer des PokéWiki-Discords, die dort zumindest der Rechtegruppe "Wikinger" angehören, können die aktuellen Versionen v2 und v3 selbst runterladen und mit ihrem Browser öffnen, um den Zuchtrechner zu testen (auf die Versionsunterschiede gehe ich später ein). Wer nicht im Discord angemeldet ist oder den Zuchtrechner nicht testen möchte, kann sich hier zumindest einen Screenshot (von v3) angucken, der auch einige Funktionen zeigt.

Im Folgenden beantworte ich einige mögliche Fragen zum Zuchtrechner und stelle ihn dadurch genauer vor. Wer sich nicht alles durchlesen möchte (es ist wirklich ziemlich viel geworden, da nehme ich das keinem übel), kann auch gerne die weniger interessanten Punkte auslassen.

• Was kann der Zuchtrechner und wie benutzt man ihn?
  Der Zuchtrechner berechnet insgesamt drei Arten von Ergebnissen: Die Wahrscheinlichkeiten dafür, dass ein gezüchtetes Pokémon ...

1. insgesamt keine, einen, zwei, drei, vier, fünf bzw. sechs sensationelle (also maximale) DVs hat.
2. vom Nutzer eingegebene Kombinationen von Anforderungen an die DVs erfüllt.
3. Kraftreserve vom Typ Kampf, Flug, etc. einsetzen kann.

Zusätzlich zu den Wahrscheinlichkeiten sind jeweils auch die Versuche angegeben, die durchschnittlich benötigt werden, um das jeweilige Zuchtergebnis zu erhalten.
Für all diese Berechnungen müssen zunächst die DVs der Eltern-Pokémon in der obersten Tabelle eingetragen werden. Leere Felder und ungültige Eingaben werden dabei als ein DV-Wert von 0 betrachtet. Über ein Dropdown-Menü können zudem die Items ausgewählt werden, welche die Eltern tragen. Diese Angaben reichen schon aus, um die Wahrscheinlichkeiten für die Anzahl sensationeller DVs und die Verteilung der Kraftreserve-Typen zu berechnen (um die Berechnung zu starten, muss auf den Knopf "Wahrscheinlichkeiten berechnen" am Ende der Seite geklickt werden).
Die Tabelle für Kombinationen ermöglicht es dem Nutzer, die Wahrscheinlichkeit für das Zuchtergebnis zu berechnen, das er gerne erreichen möchte. Dazu gibt man an, welchen KP-DV, welchen Angriffs-DV usw. das Kind haben soll. Das Wichtige ist, dass hier nicht nur einzelne Werte eingegeben werden können, sondern auch Wertebereiche, z. B. "20-31". Man kann so auch angeben, dass ein bestimmter DV-Wert egal ist (z. B. der Spezial-Angriff für ein Pokémon, das ein physischer Angreifer werden soll), indem man das entsprechende Feld freilässt oder "0-31" einträgt. Für bestimmte Wertebereiche sind als alternative Schreibweisen auch "n+" für "n-31", "n-" für "0-n" (also z. B. "20+" für "20-31") und "X" für "0-31" erlaubt. Zuletzt kann man noch den Kraftreserve-Typen auswählen oder dieses Feld bei der Standard-Option "beliebig" belassen.
Der berechnete Wert ist dann die Wahrscheinlichkeit dafür, dass ein gezüchtetes Pokémon all diese Anforderungen erfüllt. Ein Beispiel aus dem verlinkten Screenshot: Bei "Kombination 2" wird die Wahrscheinlichkeit dafür berechnet, dass ein gezüchtetes Pokémon einen KP-DV von mindestens 20, einen Angriffs-DV von min. 25, einen Verteidigungs-DV von min. 15, einen Spezial-Verteidigungs-DV von min. 12, einen Initiative-DV von 31 und den Kraftreserve-Typ Boden hat.
Ungültige Eingaben werden wie leer gelassene Felder betrachtet und mit einem roten Rahmen versehen. Es stehen mehrere Zeilen für Kombinationen zur Verfügung, um ähnliche Kombinationen miteinander vergleichen oder zusammenrechnen zu können.

• Welche Unterschiede gibt es zwischen Version 2 und 3?
  In Version 3 habe ich ein paar Verbesserungen der Nutzbarkeit durchgeführt:

1. Statt einer festen Anzahl von Kombinationen steht zunächst nur eine Zeile zur Verfügung, es lassen sich aber mit Knöpfen unter der Tabelle beliebig viele Zeilen hinzufügen oder wieder entfernen.
2. Am Anfang jeder Kombinationszeile (außer der ersten) wurde ein kleiner Knopf hinzugefügt, mit der sich die Kombination aus der vorherigen Zeile in die aktuelle kopieren lässt.
3. Neben jedem Eingabefeld wurde eine Checkbox hinzugefügt, die den Wert des jeweiligen Feldes automatisch auf "31" setzt. Dies beschleunigt die Verwendung für diesen häufig genutzten Anwendungsfall, da man sich die Eingabe der Zahl 31 spart.

Diese Anpassungen sind aber vielleicht Geschmackssache und vor allem die erste ist möglicherweise nicht problemlos im PokéWiki umsetzbar (zumindest habe ich hier noch keine Tabellen gesehen, die dynamisch die Anzahl ihrer Zeilen oder Spalten ändern), deswegen habe ich zum Vergleich auch die simplere v2-Version zum Download bereitgestellt.

• Wozu ist dieser Zuchtrechner nützlich? Und gibt es Interesse dafür?
  Abgesehen davon, dass man die Wahrscheinlichkeiten für Zuchtergebnisse möglicherweise nur aus Interesse wissen möchte, kann er auch tatsächlich bei der Zucht hilfreich sein: Z. B. wissen viele sicherlich Spieler, die Pokémon mit sechs sensationellen DVs züchten wollen, nicht, ob man dafür lieber Eltern mit fünf sensationellen DVs auf verschiedenen oder gleichen Statuswerten verwenden soll, oder ob sich für ein gewünschtes Zuchtergebnis ein Machtitem oder ein Fatumknoten besser eignet. Solche Fragen kann dieser Rechner beantworten. Außerdem hilft er einem vielleicht dabei, sich realistischere Zuchtziele zu setzen, wenn man sieht, dass man für ein gewisses Ergebnis durchschnittlich über 1000 Versuche braucht oder es sogar unmöglich ist.
  Dass es Interesse für einen solchen Zuchtrechner gibt, erkennt man auch daran, dass es bereits ähnliche Rechner im Internet gibt, z. B. behandelt dieser Rechner den Spezialfall, dass der Fatumknoten, aber kein Machtitem von den Eltern getragen wird und unterscheidet bei den DVs nur zwischen 31 und nicht 31 bzw. beliebig. Ein anderer Rechner bietet ein paar mehr Funktionen, gibt dafür aber in vielen Fällen Ergebnisse aus, die meiner Meinung nach nicht ganz korrekt sind.
  Keiner dieser Rechner unterstützt aber z. B. Wertebereiche für gewünschte Zuchtergebnisse oder Kraftreserve-Typen, sodass der von mir entwickelte Zuchtrechner meines Wissens momentan ziemlich einzigartig ist.

• Sind die vom Zuchtrechner berechneten Wahrscheinlichkeiten definitiv korrekt?
  Das kann ich leider nicht garantieren, da ich den Code, mit dem die Spiele die DVs von gezüchteten Pokémon festlegen, nicht kenne. Ich habe aber natürlich die grundsätzlichen Regeln, die bei der Zucht gelten, beachtet und gehe ansonsten davon aus, dass alles einigermaßen "normal" umgesetzt ist, dass also z. B. die Chance, dass die DVs der Statuswerte KP, Angriff und Verteidigung vererbt werden, gleich der Chance für die Vererbung von Angriff, Sp.-Ang. und Initiative ist. Ich kann aber sagen, dass die berechneten Ergebnisse mit meinen Erfahrungen bei der Zucht und meinen Tests übereinstimmen. Es kann aber natürlich noch Bugs geben, die mir bislang nicht aufgefallen sind. Die würde ich auf jeden Fall korrigieren, wenn sie mir gemeldet werden.
  Ein Punkt, bei dem der Zuchtrechner momentan aber definitiv nicht die korrekten Ergebnisse liefert, ist wenn beide Eltern-Pokémon Machtitems tragen. In diesem Fall ist es quasi so, dass sich das Spiel bei jedem gezüchteten Pokémon zufällig eines der beiden Machtitems aussucht und dann nur dieses Wirkung hat. Dieses Verhalten lässt sich leider nur schlecht mit der aktuellen Berechnungsstruktur umsetzen, allerdings ist dieser Fall auch nicht besonders wichtig, da es aufgrund dieses Verhaltens praktisch nie sinnvoll ist, beiden Eltern-Pokémon ein Machtitem zu geben. Auf diesen Fehler sollte man dann hinweisen, wenn man den Zuchtrechner ins PokéWiki einbindet.
  Und eine Sache noch: Um Platz zu sparen, steht im Zuchtrechner an vielen Stellen "Versuche", gemeint sind aber immer durchschnittliche Versuche. Wenn also nicht "1" oder "Unmöglich" bei den Versuchen angegeben wird, können wie bei Schillernden Pokémon wesentlich mehr oder weniger Versuche als angegeben benötigt werden.

• Für welche Pokémon-Spiele liefert dieser Zuchtrechner korrekte Resultate?
  Grundsätzlich sollten die Ergebnisse für alle Pokémon-Hauptspiele seit Pokémon Platin stimmen, wobei nicht jede Funktion für jedes dieser Spiele relevant ist. (Machtitems haben erst seit Heartgold und Soulsilver Auswirkungen auf die Zucht, der Fatumknoten seit X und Y. Die Kraftreserve-Typen sind für Schwert und Schild nicht mehr relevant.)
  In Pokémon Smaragd, Diamant und Perl funktioniert die Zucht leicht anders, sodass die berechneten Wahrscheinlichkeiten ein bisschen von den tatsächlichen abweichen sollten. Bei Rubin, Saphir, Feuerrot und Blattgrün bin ich mir anhand der Beschreibungen, die ich zu deren DV-Vererbung gelesen habe, unsicher, ob es letztendlich das gleiche System wie seit Platin ist oder ob es doch einen Unterschied gibt, der auf diesen Seiten nicht explizit erwähnt wurde. In jedem Fall sollten die berechneten und tatsächlichen Wahrscheinlichkeiten aber auch für diese Spiele nicht zu stark voneinander abweichen.

• Wie berechnet der Zuchtrechner die Wahrscheinlichkeiten?
  Ohne hierfür zu sehr ins Detail gehen zu wollen, kann ich schonmal sagen, dass die Berechnungen deutlich komplizierter sind, als z. B. die des Statuswerte-Rechners, der vor einiger Zeit in die Pokémon-Artikel integriert wurde. Es gibt keine verhältnismäßig einfache mathematische Formel zur Berechnung der Wahrscheinlichkeiten (zumindest ist mir keine eingefallen), aber das macht einen funktionierenden Rechner ja nur nützlicher. Es werden zwei verschiedene Techniken verwendet: Für die Wahrscheinlichkeiten für eine Anzahl maximaler DVs werden mehrere Binomialkoeffizienten berechnet und kombiniert, um die Anzahl der Möglichkeiten, mit der diese Anzahl sensationeller DVs erreicht werden kann, durch die gesamte Zahl an Möglichkeiten zu teilen. Für die Wahrscheinlichkeiten für eingegebene Kombinationen und Kraftreserve-Typen wird für jede mögliche Auswahl vererbter Statuswerte (also z. B. KP, Angriff, Sp.-Vert.) die Wahrscheinlichkeit dafür berechnet, dass damit die Kombination bzw. der Kraftreserve-Typ erreicht wird, und am Ende wird durch die Anzahl möglicher Statuswert-Kombinationen geteilt. Wer es genau wissen möchte, kann sich gerne den Quellcode des Zuchtrechners anschauen, allerdings ist er momentan kaum kommentiert.

• Kann der Zuchtrechner noch erweitert oder fürs PokéWiki angepasst werden?
  Diesbezüglich bin ich offen für Vorschläge und auch bereit, diese umzusetzen, insbesondere wenn derjenige auch ein mögliches Design für seinen Vorschlag nennt.
  Ich hatte mir basierend auf den anderen weiter oben verlinkten anderen Rechnern gedacht, eine Wesens-Auswahl oder Fähigkeiten-Auswahl zu den Kombinationen und Eltern hinzuzufügen oder den Wunsch nach einem Schillernden Pokémon angeben zu können, allerdings würde das einiges verkomplizieren, weil es dann relevant würde, welches Pokémon-Hauptspiel man nutzt und ob die Eltern männlich, weiblich, von unbekanntem Geschlecht oder ein Ditto sind. Außerdem sind dies meiner Meinung nach keine Features, die unbedingt nötig sind, da es für einen Nutzer relativ einfach ist, die Wahrscheinlichkeiten für diese Fälle selbst nachzuschlagen und dann mit der vom Zuchtrechner angegebenen Wahrscheinlichkeit zu multiplizieren. Wenn jemandem hierfür aber eine gute Idee zur Umsetzung dieser Features einfällt, gerne her damit!
  Theoretisch kann man noch sehr viel mehr Funktionen zu einem Zuchtrechner hinzufügen: Man könnte eine Pokémon-Auswahl einbauen und dann z. B. testen, ob diese Pokémon überhaupt miteinander kompatibel sind und falls ja, welches Pokémon schlüpfen würde, man könnte die Attacken berechnen, die der Nachwuchs auf Level 1 beherrscht und noch einiges mehr. Das alles wäre aber dann schon mit recht großem Aufwand verbunden und würde meiner Meinung nach auch über das Ziel hinausschießen.

So, und nach all diesen Infos, meinen Einschätzungen und der Werbung zum Zuchtrechner würde ich gerne wissen, was ihr davon haltet. Haltet ihr diesen Zuchtrechner für eine gute Ergänzung zum PokéWiki? Habt ihr selbst Interesse daran? Habt ihr noch Verbesserungsvorschläge?

Wenn sich hier genügend Mitglieder für eine Einbindung des Zuchtrechners ins PokéWiki aussprechen, sollte nichts mehr gegen eine Umsetzung sprechen. Ich habe jedenfalls auch schon Buoysel kontaktiert, der keine Einwände hatte und meinte, eine Umsetzung sei machbar. Ich hatte mir gedacht, den Rechner wie den Geheimcode-Generator auf eine Spezialseite zu packen, evtl. kann man genau wie bei dem Generator dann auch für den Zuchtrechner Übersetzungen anbieten.

Falls es zu einer Umsetzung kommt, würde ich auf jeden Fall den Code des Zuchtrechners besser dokumentieren und anderweitig verbessern, damit dann im Idealfall auch andere Nutzer Anpassungen vornehmen und Bugs korrigieren können. Aber auch ansonsten kann ich gerne bei der Umsetzung helfen (auch wenn ich noch nicht weiß, wie viel Aufwand das letztendlich wird), würde aber auf keinen Fall die Mithilfe anderer Nutzer verweigern. Vor allem die optische Gestaltung der letztendlichen Wiki-Seite bekommen andere Nutzer sicherlich besser hin als ich.

Zum Schluss möchte ich mich noch bei allen bedanken, die diese Vorstellung bis hierhin gelesen haben. Und jetzt warte ich auf eure Meinungen.
-- Lasagne (Diskussion) 11:16, 31. Okt. 2020 (CET)

Ich hab nichts dagegen dem eine eigene Spezialseite zu geben, sofern die bekannten Bugs (also z. B. das mit den zwei Machtitems) vorher noch behoben werden. Ein Tool mit bekannten Fehlern anzubieten ist meiner Meinung nach nicht wirklich sinnvoll, wenn man theoretisch auch auf das ganze verzichten könnte. Meine zweite Bedingung - nämlich das Buoysel bereit sein muss, das Ding einzubinden und später dann zu warten - scheint zumindest teilweise gegeben zu sein. Sollte sich das ganze allerdings nicht mit dieser Codebase umsetzbar sein würde ich dafür plädieren nicht all zu grosse Aufwände darin zu investieren das ganze umzuschreiben - so wichtig scheint mir das dann doch nicht zu sein. --Datei:Sugimori 672.pngMecanno-man^Mäh 16:06, 31. Okt. 2020 (CET)

Keine Ahnung welchen Nutzen das für das Wiki bieten soll. Wenn sich eine Mehrheit dafür ausspricht schließe ich mich da Mec an. * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 17:50, 1. Nov. 2020 (CET)

Mir wurde das ganze ja bereits im Vorfeld präsentiert und wie dort kann ich auch hier nur noch mal sagen, dass ich da relativ neutral zu stehe. Inhaltlich habe ich davon absolut keine Ahnung und selber nutzen werde ich es vermutlich auch nicht, ich kann mir aber durchaus vorstellen, dass es irgendwen geben wird, dem das hilft oder für den es hilfreich ist. Von demher werde ich dem nicht im Weg stehen, glaube aber auch nicht, dass ich da in irgendeiner Form behilflich sein kann. -- RobbiRobb 18:25, 1. Nov. 2020 (CET)

So wie es aussieht, liegt die Entscheidung zur Umsetzung dann letztendlich bei Buoysel, weswegen ich mich freuen würde, wenn er sich hier auch noch meldet.
Den von Mecanno-man angesprochenen bekannten Fehler des Rechners bzw. den noch nicht eingebauten Fall, dass beide Eltern Machtitems tragen, würde ich im Falle der Umsetzung noch beheben, keine Sorge.
Und damit es hier nicht so aussieht, als gäbe es nur neutrale Stimmen zum Zuchtrechner, wollte ich noch erwähnen, dass sich auf dem Discord-Server (im Strategie-Kanal) noch ein paar Nutzer positiv zum Rechner geäußert haben. -- Lasagne (Diskussion) 22:02, 15. Nov. 2020 (CET)

Jetzt melde auch ich mich mal hierzu. Das wollte ich eigtl. schon früher, habs aber vergessen. Ich wäre auf jeden Fall Pro gestellt. Auch wie Mec finde ich aber, dass der eine bekannte Bug behoben werden sollte, bevor das ins LiveWiki kommt. Aber da hast du, lasagne, ja schon geschrieben, dass du das beheben würdest. Am Ende will ich noch meine Hilfe anbieten, sollte es zu einer Umsetzung kommen. Ich arbeite seit geraumer Zeit selbst an einer Spezialseite, die einem den Zuchteltern-Baum für ein Pokémon und eine Attacke ausgibt. Allerdings kommen mir immer wieder Sachen dazwischen, weshalb der Fortschritt da immer wieder zum Erliegen kommt. Dennoch habe ich aber schon einige Sachen hingekriegt, deren Umsetzung mit der eher bescheidenen Dokumentation von MediaWiki ziemlich zeitaufwendig sein können und könnte dir da helfen.--DeXter 22:43, 15. Nov. 2020 (CET)

Ich weis leider immer noch nicht welchen Nutzen dies für das Wiki haben soll. Auch auf Discord konnte ich nur von 4 Leuten lesen das dieses Tool eine gute Idee ist. Für mich geht da allerdings nicht hervor ob dieses Tool eine gute Idee ist oder ob es um die Implementierung ins Wiki geht. Allgemein finde ich die Resonanz im Wiki und Discord ziemlich dürftig für eine derartige Implementierung. Klar liegt es bei Buo es einzupflegen. Allerdings ist halt echt die Frage ob sich das lohnt wenn man alle „Fürsprachler“ zusammen nimmt (6 User). Bin ich skeptisch. Wie gesagt, ich stelle mich nicht gegen. Bis jetzt sehe ich nur keinen größeren Nutzen. * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 12:01, 16. Nov. 2020 (CET)

Den größten Nutzen, den ich in diesem Tool sehe, ist dass es besonders neuen Pokémonspielern, die gerne in die Cp-Szene einsteigen wollen diesen Einstieg zu erleichtern. Auch die Wahrscheinlichkeit für ein bestimmtes Ereignis finde ich gut, da man dort schnell einen Überblick bekommt, wie viel Zeit man aufwenden muss, um folgendes Pokémon zu züchten und außerdem die Chance hat mit verschiedenen Zuchteltern und Items eine möglichst effiziente Taktik zu finden. Da wir im Wiki bereits ein Strategie-Projekt haben und dieses Möglichkeiten aufzeigt Pokémon zu nutzen, ist es wohl keine schlechte Idee auch einen Zuchtrechner zu haben, der hilft die gewünschten Pokémon mit gewollten Werten zu erhalten. -- Mooni000 ^{Pelipper-Post} 19:10, 16. Nov. 2020 (CET)

Ich finde es sehr schwer darüber zu urteilen, ob ein derartiger Rechner genutzt werden würde. Dennoch bin ich der Meinung, dass wir uns mit einer solchen Spezialseite keine Probleme oder zusätzliche Arbeit einheimsen. Was ich damit sagen will? Lasagne stellt uns den kompletten Code dafür zur Verfügung, da muss nichts mehr groß erarbeitet werden, sondern es fehlt nur noch der Feinschliff. Keiner von uns muss einen solchen Rechner komplett neu schreiben oder ähnliches. Aus diesem Grund wäre ich dafür, eine solche Spezialseite anzulegen. Wenn sich die Mehrheit unschlüssig ist, ob diese Spezialseite überhaupt genutzt werden wird, kann man das Ganze doch auch testweise anlegen. Es ist ja kein großer Aufwand für Buo in regelmäßigen Abständen zu schauen, wie die Zugriffszahlen dort aussehen. Und wenn man in einem (halben) Jahr merkt, dass diese Seite kaum verwendet wird, nimmt man sie wieder offline. Das tut keinem weh und sollte doch auch niemanden Sorgen bereiten. Wenn es nach mir ginge, kann man also eine solche Spezialseite testweise anlegen und dann nochmals nach einer bestimmten Zeit schauen, ob es sich lohnt sie weiterzuführen oder eben nicht. ~ Taisuke ^Diskussion 09:39, 17. Nov. 2020 (CET)

Ich glaub den potentiellen Wartungsaufwand unterschätzt du hier leicht, Tai: Der Code wird von Lasagne zur Verfügung gestellt - heisst aber nicht, dass uns Lasagne den Code jedes mal updatet wenn etwas am Zuchtsystem geändert wird. Dann müsste man entweder vermerken, dass der Rechner veraltet ist, oder ihn updaten (wobei zweiteres zu bevorzugen ist). Ebenfalls muss die Extension mit neueren Versionen von MediaWiki kompatibel sein, und sollten irgendwelche Javascript-Sachen dadrin deprecatet werden müssen die auch geupdatet werden. Deshalb ja auch meine Bedingung das Buo bereit sein muss sich da drum zu kümmern. --Datei:Sugimori 672.pngMecanno-man^Mäh 13:35, 18. Nov. 2020 (CET)

Mir ist eigentlich recht egal, was ihr mit dem Zuchtrechner macht, solange der auch wirklich zu 100% funktioniert ohne Probleme, wobei ich hier keinen wirklichen Mehrwert für uns als Wiki sehe. Das letzte Wort hat hier aber eindeutig Buo, da dieser den Code erstmal fertig für eine Spezialseite machen müsste. Und zur Tais Idee, den Rechner erstmal einfach ins Wiki zu nehmen und dann je nach Aufrufzahlen über dessen Verbleib zu reden, kann ich nur sagen, dass das totaler Humbug ist, da es am Ende Leute geben wird, die den mögen und dann äußerst angepisst sind, wenn der plötzlich wieder weg ist. Und das Entfernen des Zuchtrechner, nachdem er im Wiki war, würde nur unserem Bild nach Außen schaden. GrollenKette951 02:01, 24. Nov. 2020 (CET)

Event-Screenshots der Schwert und Schild-Spiele

Guten Abend!
Ich habe mich ja in den letzten Tagen um die Event-Seiten gekümmert und mir ist aufgefallen, dass wir ja immer noch keine Entscheidung getroffen haben, in welcher Form wir jetzt die Screenshots der Pokémon aus Schwert und Schild einbauen sollen. In Generation 7 war es ganz einfach, da wir einfach den Top- und Touchscreen zusammensetzen konnten, hier in Generation 8 haben wir allerdings ganze 4 (Mit Bänder sogar 5) Bildschirme die alle nicht vom Spiel selber kombiniert werden.
Es gab dazu bereits gestern eine kleine Diskussion auf dem Discord-Server, dies möchte ich aber jetzt einmal hier auf die AD verlegen damit wir uns relativ genau einigen können ohne, dass das Thema immer wieder aufgebracht werden muss.
Dort sind wir primär auf zwei Ideen gekommen: Entweder eine Galerie-Funktion, die allerdings erst wieder getestet werden muss, oder ein einzelnes Bild welches ein Zusammenschnitt aus den wichtigsten Punkten im Menü bildet.
(Beispiel: https://cdn.discordapp.com/attachments/247300276732559360/776538948125720587/Hutsassa.png, Dies kann natürlich immer noch geändert werden und steht keinesfalls so wie es ist fest, lediglich die Idee soll rüberkommen) Da ich diese beide Ideen allerdings immer noch nicht gut genug finde, möchte ich einmal fragen ob jemand hier vielleicht sogar noch eine bessere Idee findet. -- Taube4Life (Diskussion) 20:30, 13. Nov. 2020 (CET)

Seit StSd ist mir keine Lösung eingefallen. Wie aber schon auf Discord geschrieben. Die Home Screenshots sind bereits ewig lang da können auch 5 Screenshots zusammengestellt für StSd rein, macht so keinen Unterschied * Ryuichi ~ Datei:Sugimori 004.png^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 23:45, 14. Nov. 2020 (CET)