PokéWiki:Allgemeine Diskussionsseite: Unterschied zwischen den Versionen

Aus PokéWiki
Zur Navigation springen Zur Suche springen
Zeile 802: Zeile 802:
:::::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. -- [[Datei:Pokémon-Icon 380.png|link=Benutzer Diskussion:RobbiRobb]] [[Benutzer:RobbiRobb|<span style="font-family: Comic Sans MS; color: #088A08; text-shadow: 0 0 5px #01DF01, 0 0 10px #01DF01;">RobbiRobb</span>]] 18:21, 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. -- [[Datei:Pokémon-Icon 380.png|link=Benutzer Diskussion:RobbiRobb]] [[Benutzer:RobbiRobb|<span style="font-family: Comic Sans MS; color: #088A08; text-shadow: 0 0 5px #01DF01, 0 0 10px #01DF01;">RobbiRobb</span>]] 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. [[Datei:Pokémon-Icon_376m1.png|link=]] '''''[[Benutzer:Feblue|<span style="font-variant:small-caps;color:#FFD700;font-size:120%;text-shadow: 0 0 5px #000000, 0 0 10px #000000;">Feblue</span>]]''''' 00:02, 29. 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. [[Datei:Pokémon-Icon_376m1.png|link=]] '''''[[Benutzer:Feblue|<span style="font-variant:small-caps;color:#FFD700;font-size:120%;text-shadow: 0 0 5px #000000, 0 0 10px #000000;">Feblue</span>]]''''' 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 so{{Anmerkung|Hierbei handelt es sich um einen wissentlich übernommenen Fehler, um das Original korrekt zu zitieren.|symbol=sic}} bereits vollkommen ausreichen. [[user:Taisuke|<span style="font-family:Apple Chancery;color:#8B1A1A;font-size:150%">~ Taisuke</span>]] <sup>[[User Talk:Taisuke|<span style="font-family:Apple Chancery;color:#8B1A1A">Diskussion</span>]]</sup> 10:39, 29. Okt. 2020 (CET)

Version vom 29. Oktober 2020, 10:40 Uhr

Vorlage:TOC right

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 drop.gif
  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-manMä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 drop.gif 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-manMäh 23:41, 8. Jul. 2019 (CEST)

Als erstes: Herzlichen Glückwunsch zum Geburtstag nachträglich liebe Diskussion emot-highfive.gif

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.pngPL ~ 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-manMä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 ka.gif 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.pngPL ~ 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-manMä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.pngPL ~ 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-manMä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.pngPL ~ 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-manMä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-manMäh 19:11, 2. Mai 2020 (CEST)

Abstimmung: Design der Stellenanzeigen-Box auf der Hauptseite

Abstimmung beendet. Variante 3 wird umgesetzt

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-manMä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-manMä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-manMä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-manMä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.pngPL ~ 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-manMä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... drop.gif
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-manMä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-manMä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-manMä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! 20120215170011_sonne.gif ~ 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.pngPL ~ 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-manMä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.pngPL ~ 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.pngPL ~ 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 ka.gif 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.pngPL ~ 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 ka.gif Gruß * Ryuichi ~ Datei:Sugimori 004.pngPL ~ 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.pngPL ~ 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-manMä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.pngPL ~ 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. (ups.gif) 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-manMä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/StEXSHEX), 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-manMäh 17:46, 27. Feb. 2020 (CET)

Erstmal, der Name SortyBuzz gefällt mir grin.png. 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-manMä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.pngPL ~ 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-manMä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! msnsorry.gif

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

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-manMä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-manMä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-manMä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.pngPL ~ 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-manMä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 (ups.gif) 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.

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-manMä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-manMä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! Pokémon-Icon_674.png 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-manMä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.pngPL ~ 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-manMä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-manMä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...? Pokémon-Icon_674.png 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.pngPL ~ 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-manMä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.pngPL ~ 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! Pokémon-Icon_674.png 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-manMä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


Gruß * Ryuichi ~ Datei:Sugimori 004.pngPL ~ 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-manMä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-manMä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-manMä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-manMä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.pngPL ~ 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. Pokémon-Icon_674.png 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-manMä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-manMä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-manMä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-manMä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.pngPL ~ 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-manMä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-manMä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-manMäh 02:43, 22. Okt. 2020 (CEST)

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, Pokémon-Icon_674.png 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.pngPL ~ 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-manMä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. Pokémon-Icon_674.png 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.pngPL ~ 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-manMäh 19:29, 4. Okt. 2020 (CEST)
emot-rolleyes.gif 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.pngPL ~ 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.pngPL ~ 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 ka.gif * Ryuichi ~ Datei:Sugimori 004.pngPL ~ 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-manMä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)