PokéWiki:Allgemeine Diskussionsseite/Archiv 2020

Aus PokéWiki
Zur Navigation springen Zur Suche springen
Diese Seite ist das abgeschlossene Archiv der Allgemeinen Diskussionsseite.
Bitte editiere hier nichts mehr.
Für Kommentare bitte die aktuelle Seite verwenden.

Überarbeitung oder Löschen der Vorlage "Gradient"

Ich glaube, dass wir sollten die Vorlage Gradient auf zwei separate Vorlagen aufteilen oder die Vorlage insgesamt löschen. Es ist so einfach, um Gradienten in CSS zu schreiben: 

background-image: repeating-linear-gradient(to top right, red, yellow 5%, red 10%);

Das Ergebnis ist dieses Rechteck:

Keine Farben-Transition? Dein Browser kann nicht Gradienten darstellen!

Hinweis: Du auch brauchst background-color zu definieren, da auch heute viele Browser können Gradienten nicht darstellen. Viele Browser auch brauchen ein Präfix, um korrekt zu werken (z. B. Mozilla Firefox brauchte das Präfix "-moz-"). Akzeptiert Ihr meine Idee? --TrikephaloFan635 11:50, 4. Jan. 2020 (CET)

Veto, ein Großteil der Nutzer verwendet kein CSS bzw. ist die Nutzung dieser Vorlage für entsprechende Nutzer besser in der Handhabung und eine Änderung so nicht notwendig. * Ryuichi ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 12:06, 4. Jan. 2020 (CET)
Die Nutzung dieser Vorlage erfolgt allerdings sinnvollerweise ohnehin nur in der Vorlagenprogrammierung. Da weiß ich nicht, ob da die CSS-Kenntnisse noch so relevant sind. Ich bezweifle ganz ehrlich in Gegenüberstellung, ob die Anwendung der Gradient-Vorlage tatsächlich einfacher ist; wir könnten wohl genauso gut auch zusammenfassen, wie die CSS-Deklarationen funktionieren. Die Vorlage dürfte mit immerhin 224 #replace jedenfalls recht ineffizient sein. -- Skelabra2509 (Diskussion | Beiträge) 11:45, 5. Jan. 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. --Mecanno-manMäh 03:11, 10. Jan. 2020 (CET)
🤔 Für was überhaupt? Es ist immernoch die Galar-Region und immernoch SWSH. 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 ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 08:51, 10. Jan. 2020 (CET)
Der Ansatz und das Design deiner Idee gefällt mir, Ryu. Leider gibt es zwischen den Inseln auch Unterschiede. So sind unterschiedliche Pokémon auf den Inseln erhältlich, z. B. Coronospa erst mit dem zweiten Teil des Erweiterungspasses. Daher brauchen wir in meinen Augen schon mehr als nur ein Kürzel. ~ Taisuke Diskussion 09:23, 10. Jan. 2020 (CET)
@Taisuke: Die unterschiedlichen Pokémon sind doch Schwert, Schild abhängig was auf der Rüstungsinsel und später auf der Krone kommt, da der EX-Pass für beide Inseln pro Spiel ist wüsste ich nicht für was es weitere Sks benötigt. Auf der Rüstungsinsel gäbe es 3 Kombinationen SWEX, SHEX, und SWSHEX 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 ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 09:39, 10. Jan. 2020 (CET)
Man könnte auch nehmen was da ist 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
SW
SW
SW
SH
SH
SH
SWSH
SWSH
SWSH
* Ryuichi ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 11:21, 10. Jan. 2020 (CET)
Ich wüsste nicht, was dagegen sprechen würde, für jeden Teil des Erweiterungspasses ein eigenes Spielkürzel, im Endeffekt also insgesamt vier neue (Schwert-Rüstung, Schild-Rüstung, Schwert-Krone, Schild-Krone) einzuführen. Ich kann für mich hauptsächlich für den Item-Bereich sprechen, aber ich kann mir auch vorstellen, dass auch andere Bereiche davon profitieren könnten. Und zwar möchte ich ungerne neue Item-Fundorte zu den bereits existierenden hinzufügen, um Besucher, die die DLCs nicht besitzen, nicht zu verwirren, wenn dort Fundorte für Orte angegeben sind, die sie überhaupt nicht erreichen können. Da beide DLCs jeweils einen neuen Bereich freischalten, würde ich da auch gerne die Fundorte getrennt anbieten können, sodass dort auch nicht gemischt wird. Ich denke, die Richtung, in die ich möchte, sollte klar werden ^^
Visuell wäre ich dafür, einfach einen weiteren Buchstaben anzuhängen, der neben dem Hauptspiel klar macht, welche Erweiterung gemeint ist: STR, SDR, STK, SDK. Damit wäre man für alle möglichen Lagen gewappnet und müsste sich keine Sorgen machen, wenn irgendwelche verrückten, Editions- und gleichzeitig auch noch DLC-Spezifischen Inhalte kommen, bei denen wir uns eigentlich sicher sein können, dass es sie geben wird. -- RobbiRobb 17:34, 10. Jan. 2020 (CET)
Ich denke auch, dass neue Spielkürzel sinnvoll wären. Die Anhängung eines weiteren Buchstabens, wie mein Vorredner es bereits verdeutlichte, finde ich als Lösung recht einfach und gut.
P.S.: Wir haben ja sogar n Spielkürzel für etwas, das nicht einmal ein Spiel ist: Pokémon Bank BANK :D also warum dann einer Erweiterung, die ja schon etwas neues ist, das verwehren? -- GrüßeShortyBuzz 17:43, 10. Jan. 2020 (CET)
Mein Problem ist eher das einige Sks sowohl für Rüstung als auch Krone wollen, wo ich bisher immernoch nicht den Sinn heraus sehe da ja jeder der DLCs beides beinhaltet (Rüstung und Krone) nur halt Zeitversetzte veröffentlichung in 2 teilen und jeder der sich im Herbst den Pass für Krone holt sollte damit auch zur Rüstung kommt, mir würde jetzt kein Szenario einfallen was beides benötigt. Aber lässt sich ja wenn es soweit ist alles nochmal ändern ka.gif Gruß * Ryuichi ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 18:43, 10. Jan. 2020 (CET)
Ich würde das ganze erst einmal abwarten und schauen, in wie weit es wirklich notwendig ist. ~ TiMauzi 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 ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 19:31, 21. Jan. 2020 (CET)

Der Meinung bin ich nicht. Es bleibt dasselbe Spiel wie vorher, zumal ja die Pokémon auch für die dazugepatcht werden, die den DLC nicht erwerben. Gleichnis: Mario Kart 8 ist auch Mario Kart 8 geblieben, obwohl damals 4 neue Cups hinzugefügt wurden. Etwas anderes ist das hier auch nicht. Zudem bin ich der Ansicht, dass wir für solche Entscheidungen abwarten sollten, in wiefern die Erweiterungspässe wirklich wie "eigene Spiele" behandelt werden können. Außerdem bin ich der Meinung, dass die Idee dahinter gar nicht neu ist. Früher hat man halt solche neuen Inhalte schon vorher auf das Spiel gepackt und einfach nur (mehr oder weniger erfolgreich) versucht geheim zu halten (Eichs Brief, Azurflöte ...). Im Grunde waren das auch nichts weniger als kleine (kostenlose) DLCs. Mit dem Unterschied, dass heute so etwas wirklich geheim gehalten werden kann, indem man erst später in die Spiele einfügt.
Also kurzum: Ich bin nicht dafür, dass man diese DLCs so separiert betrachtet. ~ TiMauzi 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) --Mecanno-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. SW EX, SH EX und SWSH EX * Ryuichi ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 17:16, 18. Jun. 2020 (CEST)

Hatte mich ja bereits auf Discord dafür ausgesprochen und spiele weiterhin mit dem Gedanken, bei den Items zwischen Hauptspiel und Erweiterungspass zu trennen, auch vor dem Hintergrund, dass bei einigen wenigen Items die Beschreibungen geändert wurden. (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. --Mecanno-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 ({{sk|SWR|SHR}}, {{sk|SWK|SHK}} & SWEXSHEX), 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)

Im Chattreffen vom 06.03.2021 wurde ein Fazit zur Nutzung der eingeführen Sks gezogen. die sk SWR,SHR,SWK und SHK wurden sogut wie nicht genutzt und werden wieder entfernt und für den DLC wird nur SWEXSHEX genutzt. * Ryuichi ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 10:49, 7. Mär. 2021 (CET)

Kategorien bei Datei-Weiterleitungen

Mir ist aufgefallen, dass bei dem oben genannten Thema Uneinheitlichkeit herrscht. Genauer gesagt ist meine Frage, ob wie zum Beispiel hier eine Datei-WL Kategorien erhalten sollte oder nicht. Vorteil ist, dass man sie leichter finden kann. Nachteil ist aber, dass Seiten, die keine Dateien sind, dann als solche kategorisiert werden. Egal wie darüber entschieden wird, müssen jetzt nicht direkt sämtliche Kategorien ergänzt oder entfernt werden, das ist den Aufwand wahrscheinlich nicht wert. Für die Zukunft wäre es aber für alle Wiki-Bereiche ganz gut zu wissen, wie wir damit verfahren. Darum interessieren mich eure Meinungen zu diesem Thema. -- Cliffichen 19:17, 10. Feb. 2020 (CET)

Eine Weiterleitung iwo einkategorisieren wo die Zielseite schon drin ist ist imo. auf jeden Fall sinnlos. Dasselbe gilt in Fällen wo das eine ne Unterkategorie vom anderen ist; bei Sachen wie spiele-spezifischen Sprites-Kategorien bin ich mir unschlüssig und hängt wohl damit zusammen wie die Kategorie konzeptionell aussehen sollte - also ob da alles drin sein soll oder nur das was neu in dem Spiel hinzugekommen ist. Je nach dem müssen dann Weiterleitungen einkategorisiert werden oder nicht. --Mecanno-manMäh 21:23, 10. Feb. 2020 (CET)
Mir fällt gerade auf das es wahrscheinlich sinnvoller ist die Kategorie die man bei den Weiterleitungen einfügen würde direkt bei der Zieldatei reinzuschreiben, dann wird auch auf der Datei-Seite klar das der Sprites für mehrere Spiele gelten, was es aktuell nicht wird. --Mecanno-manMäh 21:26, 10. Feb. 2020 (CET)
Wie wäre es, wenn man ganz ohne WLs auskäme und die Dateien gleich mit jedem Spielekürzel im Dateinamen versehen wurde, in der sie vorkommt? -MfG, Kenaz-Hagalaz Disku 19:33, 12. Feb. 2020 (CET)
Oh, das hat Mec ja im Prinzip auch geschrieben. ^^ -MfG, Kenaz-Hagalaz Disku 19:35, 12. Feb. 2020 (CET)
Hö, nein, ich will die mit jeder Kategorie versehen in der sie vorkommt. Alle Spielkürzel in die Namen zu machen und die Redirects wegwerfen dürfte etliche Vorlagen im Wiki um einiges komplexer machen und jede Menge Wartung bedeuten; insbesondere da wir dann auch andauernd Sachen verschieben wenn sie in einem neuen Spiel wiederverwendet werden. --Mecanno-manMäh 19:57, 12. Feb. 2020 (CET)
Ohje, ich sollte keine Disku-Beiträge schreiben, wenn ich nicht ganz fit bin ^^" -MfG, Kenaz-Hagalaz Disku 20:09, 12. Feb. 2020 (CET)
Gibt es dazu noch weitere Meinungen? Sonst würde ich das bei den nächsten Datei-WLs (brauche einige für Trainer, darum habe ich hier gefragt) so machen, wie Mec das vorgeschlagen hat. Sprich die Zieldatei zusätzlich kategorisieren. Und vielleicht gibt es irgendwann eine Wartung, bei der das dann einheitlich für alle Datei-WLs so umgesetzt wird. -- Cliffichen 11:52, 16. Feb. 2020 (CET)

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. --Mecanno-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? --Mecanno-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. --Mecanno-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 ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 18:38, 25. Aug. 2020 (CEST)
Von der Idee, eine User-Rangliste zu erstellen halte ich nicht viel; das führt eher dazu, das Leute sich nur versuchen Auszeichnungen zu erarbeiten und dann auf Projekthelden/WBs geiern, was nicht der Sinn dieser Auszeichnungen ist. Man sieht das jetzt schon teilweise, mit den Bearbeitungszählern. Ich hätte aber nichts dagegen, WB/ÄWB iwie farblich hervorzuheben, wenn wir den Redakteur abschaffen; wie müsste man dann aber klären, ich sehe da nämlich dann das Problem, das ein bunter Regenbogen bei entsteht zwischen Projektleitern, VBs, WBs und ÄWBs - welcher noch dazu verkompliziert wird, das wir auch ne Farbe für Veteranen haben. Ich sehe da gerade spontan kein System, welches noch übersichtlich ist. --Mecanno-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. --Mecanno-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 ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 21:08, 26. Aug. 2020 (CEST)
Hey, DeXter! Nein, das hast du komplett so verstanden, wie ich das meinte. Allerdings war mir das nicht bewusst, dass man bisher für alles jemanden vorschlagen konnte. In Bezug auf die Projektleiter meinte ich das so, dass es entweder einen zweiten Projektleiter in einem Projekt neben einem VB gibt, der ein Löschrecht hat (bsp. Wds Projekt Tai und Jonny) oder die Projektleitung nur aus Nutzern besteht, die sowieso das Löschrecht haben. Da das aber ein Thema ist, wie du ja schon sagtest, das hier lieber den Hintergrund einnehmen sollte, schreibe ich dazu jetzt nichts mehr, da ich denke, dass meine Aussage klar geworden ist. -- Feblue 22:36, 26. Aug. 2020 (CEST)
Ich finde, das ganze in den VC zu verlegen, ist an dieser Stelle nicht notwendig. Grundsätzlich ist es besser, wenn Diskussionen im Wiki stattfinden; VC ist für mich nur da notwendig, wo eine Diskussion im Wiki eingeschlafen ist. Folglich bin ich an dieser Stelle dagegen. Bei einer schriftlichen Diskussion hat man zudem Zeit, seine Meinung zu überdenken und gezielt zu antworten, während in einer VC-Runde eher Ideen durcheinander geworfen werden, ohne das man da wirklich Zeit hat drüber nachzudenken. Außerdem gehe ich davon aus, das an der Stelle dann alle Benutzer sowieso die Texte hier gelesen haben müssten, um an der VC-Runde teilzunehmen, was dein Zeit-Argument so gut wie negiert. Und schliesslich noch: Das ganze ist hier bewusst öffentlich, so kann jeder seine Meinung dazu beitragen, in einer VC-Runde wären sofort Leute, die dann nicht Zeit haben (u. A. weil nicht von der Doodle-Umfrage mitbekommen), von der Diskussion ausgeschlossen. Das möchte ich nicht. --Mecanno-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 ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 09:33, 27. Aug. 2020 (CEST)
Ich wollte mir eigentlich mal an einem ruhigen Abend Zeit nehmen, meine Ansichten zu der ganzen Diskussion darzulegen. Das kommt dann noch später, wollte nur schnell mitteilen, dass ich Mecs letzte Nachricht komplett unterstütze. Dass das Thema wichtig ist, sieht man ja an den ganzen produktiven Beiträgen. Und ich denke, dass man jetzt nicht alles in den VC verlegen sollte, wo dann bestimmte Ansichten bei einer "Übertragung" ins Wiki untergehen bzw. falsch wiedergegeben werden könnten. Gerade dieses Thema hier eignet sich perfekt für eine Diskussion im Wiki, weil es jeden betrifft, viel Resonanz da ist, es viele verschiedene Meinungen gibt und, wichtig, extrem viele Argumente, die ausreichend gegeneinander abgewogen werden müssen. Das alles festzuhalten finde ich wichtig, sodass auch jemand, der erst später zu der Diskussion dazustößt, alle nötigen Informationen vorliegen hat. So, ist jetzt doch wieder länger geworden, egal :D. Lg --Toben des Meeres. Killuu 11:07, 27. Aug. 2020 (CET)
Die Diskussion hat sich mit der Zeit in mehrere Unterdiskussionen getrennt, ich hoffe ich vergesse kein Thema.
1.) Das Ändern der Rechtestruktur. Meiner bisherigen Erfahrung nach bin ich mit dem aktuellen Rechtesystem gut zurechtgekommen. Das fehlende Löschrecht stört mich nur selten, und wenn ich etwas löschen musste, war es auch selten ein Problem, jemanden zu finden, der das übernehmen konnte. Ich kann mir allerdings auch gut vorstellen, dass es anderen PLs dabei anders geht, im Strategie-Projekt hab ich allgemein wenig, was gelöscht werden muss. Aber auch abseits meines Projekts halte ich das aktuelle Rechtesystem für sinnvoll, so wie es ist. Der Rang des Redakteurs lässt sich meiner Meinung nach nicht wirklich durch Projektleiter "ersetzen". Redakteure können einfach als Ansprechpartner für viele verschiedenen Themenbereiche oder andere allgemeine Fragen dienen, was PLs nicht zwangsläufig können. Zusätzlich spielt das Prestige dieses Rangs eine Rolle. Ich könnte mich damit anfreunden, PLs und Reds rechtemäßig auf eine Stufe zu stellen, allerdings die Red-Rolle als reine Prestige-Rolle zu behalten. Der Redakteurs-Rang hat einfach eine ganz andere Wirkung als ein WB, ÄWB oder PH.
2.) VB-Wahlen. Ich halte Wahlen von VBs nur für bedingt sinnvoll. Im aktuellen System schlagen Admins intern einen SB vor und diskutieren intern. Das vorschlagen von SBs kann auch auf weitere Benutzergruppen ausgeweitet werden, wie Dexter bereits sagte ist es ja auch jetzt schon möglich, solche Diskussionen anzuregen. Allerdings denke ich, dass es bei vielen SBs schwierig sein wird zu beurteilen, wie qualitativ die Beiträge sind. Viele SBs, die sehr aktiv mitarbeiten und sich so potenziell für den VB-Posten qualifizieren, nehmen sich einzelne Aufgabenbereiche und legen ihren Hauptfokus auf diese Bereiche. Ich könnte mir kaum vorstellen, eine begründete Stimme bei einer VB-Wahl abzugeben, für einen SB, der hauptsächlich im Anime- oder im TCG-Projekt tätig ist. Andersherum glaube ich, dass viele kaum eine Stimme zu einem SB abgeben können, der hauptsächlich Strategie-Beiträge macht. Auch andere Punkte, wie Diskussionsverhalten und Vorlagenarbeit, sind bei SBs eher schwierig zu bewerten, da dieses in den meisten Fällen eher weniger ausgeprägt sind. Die Red-Wahl hingegen würde mir im Allgemeinen "einfacher" fallen, da Reds in der Regel in mehreren Bereichen tätig sind und auch über Vorlagenverständnis und Diskussionsaktivität verfügen sollten, sodass sich mehrere Punkte bewerten lassen. Allerdings denke ich, dass vor allem die inhaltliche Bewertung für den "allgemeinen ESB" schwer fallen kann. Ich fände es deswegen sinnvoll, zuständige PLs in die Diskussion der Admins mit einzubeziehen, da diese wahrscheinlich am besten bewerten können, wie gut der Nutzer mit den patrol-Rechten umgehen kann.

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

Ich muss Lucas Kritik an VB-Wahlen zustimmen. Würden alle ESBs an solchen VB-Wahlen teilnehmen können, würde es früher oder später vermutlich zu geringer Wahlbeteiligung und/oder bloßem Signatursetzen kommen. Ich würde aber nicht nur die zuständigen PLs sondern allg. ESBs miteinbeziehen, die in den Bereichen aktiv sind, in denen auch der Kandidat was macht. Z. B. wäre es beim Spin-off-Projekt mMn nicht sinnvoll nur die PLs zu nehmen (dass die beiden sowieso Admins sind lassen wir mal bei dem Gedankengang weg), da ein zuständiger Unterleiter sicherlich auch ein gutes Bild des Users hat. Ein anderes Beispiel wäre der Café-Mix-Bereich (auch Spin-off, aber kein(e) Unterleiter). Da könnten von den ESBs, denke ich, Isso und ich am besten eine Einschätzung geben. Als Idee ist mir da grad eingefallen, dass bei einer VB-Wahl individuell die beteiligten Leute zusammengesucht werden könnten (wobei man das zusammensuchen viell. auch zum Teil in Form von in #intern fragen wer mitmachen will umsetzen kann). Die Vorgehensweise hätte aber auf jeden Fall auch ihre Schwachstellen, ist nur eine Idee, die mir zu später Stunde eingefallen ist. --DeXter 02:07, 28. Aug. 2020 (CEST)
Ich hätte nen Vorschlag dazu, wie eine sinnvoll hierarchische Rechtestruktur aussehen könnte, aus der man wiederum auch gut Kriterien dafür ableiten könnte, die man erfüllen muss, um eine Stufe aufzusteigen. Das sind dabei eher qualitative Vorschläge, die man quantitativ unterfüttern könnte, aber nicht zwingend müsste.
  • SBs werden danach gemessen, ob sie die grundlegenden Funktionen des Wikis verstanden haben und sich mit dem Bearbeiten gut zurechtfinden.
  • VBs stellen die nächste Stufe dar. Sie zeichnen sich dadurch aus, dass sie an mindestens einem Projekt gewinnbringend mithelfen. Daher sollten VBs nicht allgemein gewählt, sondern in diesem Szenario von einem Projektleiter vorgeschlagen werden. Im Sinne des Vertrauensvorschusses müssen Admins dem nicht zwingend zustimmen, können aber ein Veto einlegen. Im Unterschied zur unten vorgeschlagenen Redakteurs-Definition wird klar, dass das wahrscheinlich dazu führen wird, dass wir mehr VBs erhalten werden als aktuell gesetzt werden, was ich toll fände. EIn Name für die Rechtestufe könnte "Verdienter Benutzer" sein, im Sinne von dass er sich in einem Projekt verdient gemacht hat. Dann müsste man sich nicht mal an ein neues Kürzel gewöhnen :)
  • Die nächste Stufe würden Projektleiter darstellen. Sie wären in dieser Denke dann für ein Projekt auch inhaltlich stärker verantwortlich und würden mit den VBs zusammen darin werkeln.
  • Redakteure könnte man nun wiederum so definieren, dass sie projektübergreifend unterstützend tätig sind. Das würde dann auch eine Wahl rechtfertigen, weil dieser projektübergreifende Gedanke dazu führt, dass alle Autoren projektübergreifend aussagefähig über den Autoren sein sollten.
  • Admins haben dann zu Redakteuren dasselbe Verhältnis wie Projektleiter zu VBs, übernehmen also mehr Verantwortung für das Gelingen.
Ich kann mir ein solches Definieren der Rechtestufen gut vorstellen, weil es deutlich macht, in welche Richtung man sich entwickeln muss, wenn man aufsteigen möchte. In Projekten mitarbeiten, in Projekten mehr Verantwortung übernehmen, projektübergreifend mitarbeiten, projektübergreifend mehr Verantwortung übernehmen. Ich glaube, dass der größere Projektfokus dazu führen könnte, dass mehr User VBs werden, weil die Projektleiter auch sehr speziell interessierte User fördern könnten. Ich würde zudem empfehlen, von numerischen Kriterien ein Stück weit abzukommen. Zahlen und Zähler können natürlich ein nützlicher Richtwert sein, aber wenn sie keine inhaltlichen Ausnahmen zulassen, werden sie immer ein Ungerechtigkeitsgefühl hinterlassen. Vielleicht ist ja was Interessantes dabei! 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. --Mecanno-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 ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 06:39, 2. Sep. 2020 (CEST)

Die Beiträge der letzten Tage erzeugen bei mir den Gesamteindruck, dass grundsätzlich eine überwiegende Zufriedenheit mit der Rechtestruktur vorliegt, weshalb Mec auch bereits von seinem ursprünglichen Vorhaben, die Redakteure zu streichen, abgekommen ist (siehe sein letzter Beitrag). Jedoch zeigt sich mir hier ein ganz anderes Problem: Die einzelnen Ränge sind wenig bis gar nicht definiert, sodass es vielen schwer fällt einzuschätzen, was bestimmte Ränge ausmacht. Daran anschließend ist es natürlich sowohl in den höheren Rängen problematisch Beförderungen durchzuführen als auch in den niedrigeren Rängen einzuschätzen, was einem zum Aufsteigen noch fehlt. Unter dieser allgemeinen Unsicherheit leidet natürlich auch die Bereitschaft, geeignete Benutzer für neue Ränge vorzuschlagen, da man sich unsicher ist, ob man selbst überhaupt richtig liegt mit seiner Einschätzung.
Für mich haben sich dadurch in dieser Diskussion – die zum Teil auch parallel bei Discord an verschiedenen Stellen weitergeführt wurde – fünf (große) Themenbereiche aufgetan (die Reihenfolge ist willkürlich):
  1. Wahlen: Für Redakteure und/oder verlässliche Benutzer?
  2. Definition der einzelnen Rechtestufen sowie deren Übergang
  3. Ein Mentorensystem
  4. Wertschätzung
  5. Förderung qualitativer Mitarbeit
Aus meiner Sicht wäre es sinnvoll zu 1. hier weiter zu diskutieren und zu den anderen Punkten wieder mit Unterseiten zu arbeiten, wie wir es bereits bzgl. des Teamworks oder der Hauptseite in der Vergangenheit gehandhabt haben. Dann kann an allen vier Punkten parallel (oder auch nacheinander – mir egal) und ganz transparent darüber diskutiert werden, ganz unabhängig vom Rang eines Benutzers. So kann sich jeder bei den Themen einbringen, der es möchte. Sollten sich dann Ergebnisse bzw. Vorschläge abzeichnen, könnte man sie schlussendlich durch ne Abstimmung als Gemeinschaft absegnen.
Ich bin mir zwar unsicher, wie ihr die Sache seht, aber ich fände das sehr interessant und lohnenswert in diese Baustellen Zeit zu investieren. ~ Taisuke Diskussion 12:08, 2. Sep. 2020 (CEST)
Ich weiss nicht, ob es direkt Unterseiten sein müssen, aber ich teile Tais Meinung, das das Ganze hier etwas zu gross für alles in einem Abschnitt geworden ist, und bin ebenfalls der Meinung, das hier am Besten nur noch zu 1. weiter diskutiert wird. Für die anderen Sachen wären zumindest eigene Abschnitte sinnvoll. --Mecanno-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. --Mecanno-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 --Mecanno-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. --Mecanno-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 ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 18:23, 18. Sep. 2020 (CEST)
VB-Wahlen sind an sich erstmal ein gutes Konzept. Es ist demokratischer, dadurch automatisch interaktiver und ggf. motivierender. Ich habe nur die Befürchtung, dass in vielen Fällen persönliche Sympathien und Antipathien über die Ergebnisse dieser Wahlen entscheiden werden, anstelle einer ehrlichen Einschätzung von Eignung und Leistung der zur Wahl stehenden Kandidaten durch die Wahlberechtigten. Doch könnte man dagegenhalten, dass die Redakteurswahl ja scheinbar auch ziemlich gut funktioniert. Deshalb möchte ich weder dagegen noch dafür sein. Wir müssten bei einem Pro für VB-Wahlen aber das System vorher sehr gut bedacht festschreiben: Stimmberechtigung, Empfehlungsberechtigung, genaues Wahlsystem (wie die Red-Wahl oder anders?), usw.
Ein Mentorenprogramm halte ich in der aktuellen Lage für langfristig nicht lebensfähig. Weil es sehr viel Zeit und Energie verschlingen kann, Menschen auszubilden und ich nicht sehe, dass wir diese Kapazitäten haben oder in naher Zukunft bekommen werden. Selbst wenn sich Leute dafür finden, die das demnächst durchziehen würden, frage ich mich halt, ob die das in einem halben Jahr auch noch tun werden und ob die Ergebnisse den Aufwand rechtfertigen. -MfG, Kenaz-Hagalaz Disku 19:15, 18. Sep. 2020 (CEST)
Das wichtigste Unterthema, nämlich die Wertschätzung vor allem von neuen Usern, ist über diese ganzen Detaildiskussionen völlig in den Hintergrund getreten. Alles waren ja nur Ideen, um dieses Thema anzugehen. Letztendlich ist es egal, mit welchen Methoden man das angeht, es muss kein Mentorenprogramm sein. Mein Aufruf geht nur in die Richtung, das zugegebenermaßen heikelste, aber gewinnbringendste Unterthema nicht über die wenig relevanten Themen aus dem Blick zu verlieren. 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. --Mecanno-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. --Mecanno-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? --Mecanno-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. --Mecanno-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 ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 09:42, 8. Okt. 2020 (CEST)
(DeXters vorletzte Nachricht) Ja, ich sehe die Wahl theoretisch als gewonnen. Ich stimme dir zu, dass es keine Scheinwahl sein sollte, aber es sprechen (für mich) nunmal bei einem Nutzer, der PL werden soll, fast alle Argumente (außer irgendetwas, das mir gerade nicht einfällt, ist sehr auffällig / außer etwas, das ich nicht kenne, das also vor meiner Zeit passierte, spricht dagegen) dafür, dass er VB wird. Feblue

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

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

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

Es scheint mir irgendwie, als würde jedes Mal wenn hier etwas vorgeschlagen wird, dies ein ganzes Wahlkonzept sein. Ich sehe uns hier ehrlichgesagt nicht auf ein fertiges Konzept ohne Abstimmung einigen, folglich wäre es hier meiner Meinung nach an der Zeit das Vorgehen zu ändern und das System modular angehen - denn zig verschiedene ganze Systeme werden in einer Abstimmung nicht gut kommen, da garantiert den meisten irgend ein Detail an einem System nicht passen wird. Ich halte e aber durchaus möglich parallel mehrere Abstimmungen zu verschiedenen Komponenten zu machen; also iwie eine für ne Kommentarphase, eine für gleichzeitige Wahlrunden etc. So hätten wir dann zum Schluss ein System, bei dem auch jede Komponente tatsächlich von der Mehrheit bestätigt wurde.
In diesem Fall sei auch noch erwähnt, das ich (in Absprache mit den anderen Admins) grundsätzlich eine solche Abstimmung bereits vorbereitet habe. Sollte hier also eine Weile lang nichts mehr kommen werde ich diese starten. --Mecanno-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. --Mecanno-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. --Mecanno-manMäh 02:43, 22. Okt. 2020 (CEST)

VB-Wahlen

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

Ältere Sachen zum Nachvollziehen (aus-/einklappen)

Aktuell im Raum stehende Punkte

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

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

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

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

Kurze Frage zu deinem Vorschlag, Ryu: Meinst du hier eine riesige Wahlrunde für alle, oder eine 14-Tage-VB-Wahlrunde, gestartet nach einem Pro von Admins und Reds? Bei der Red-Wahl funktioniert das mit der Stimmpflicht eines gewissen Anteils der Admins ja auch nur, weil die erste Wahlrunde unbefristet ist, eine Wahlpflicht - egal für welche Usergruppe - halte ich für unumsetzbar wenn die Wahlrunde ebenfalls befristet ist (was machen wir, wenn x User die abstimmen müssen es in der Zeit nicht tun?), und eine Trennung von wann Redakteure und wann VBs abstimmen dürfen scheint mir nicht sonderlich sinnvoll - zeitgleich hab ich ebenfalls das Gefühl, das dies eine Wahl nur unnötig verzögert bis sich mal genügend Reds ein Bild zum SB gemacht haben, denn ich glaube nicht das alle Redakteure dies andauernd machen. --Mecanno-manMäh 21:41, 3. Nov. 2020 (CET)
Beispielhaft: Unser Pöbel möchte wieder VB werden oder ESB schlägt RBS vor. Es wird im Redchannel angesprochen das Pöbel/RBS VB werden möchte/vorgeschlagen wurde. Gibt eine kurze Red Umfrage nach dem Motto Wahl ja/nein bei mindestens 51% Befürwortern startet ein Red eine Wahl. Sonderfall bei Max der ja doch aktiv ist da würde ich die Klausel mit Vet bekommt schneller die rechte zurück anwenden. Also wie damals bei PK. Kurze Umfrage mit VB wieder ja nein... und fertig... Und solange man es anschließend transparent hält. Z.b. Beitrag auf Pöbels Seite "Haben Wunsch nach VB bekommen, aufgrund Begründung z.b. kurzfristiger Inaktivität und vergangener Beiträge und Nachräumaufwand, geben wir dir VB wieder", ne Wahl fänd ich in dem Fall zu überbürokratisiert. Und manches sollten wir mal wieder etwas userfreundlicher handhaben und nicht ewige pampflet von Unterseiten Konzepten durchackern.... Würde Max hochgespitzt nach 2 Jahren kommen dann ganz klar wieder ne Wahl..... wir sind aktuell nur 6 Reds, und i.d.R. melden sich die meisten ab wenn sie länger nicht da sind. Die werden dann halt rausgerechnet... Wenn wir 30 Red wären dann wäre so eine Verpflichtung utopisch aber bei 6. Und es muss nicht groß rumgeeiert werden sondern einfach nur ein ja/nein das halte ich für ziemlich machbar. einzig Sonderfälle gäbe es zu diskutieren. Das halte ich für aber auch für machbar. Da Admins den Channel sehen, könnten diese bei Unklarheit ja nachfragen oder sich einbringen. Sind es jedenfalls mindestens 50% der Reds dafür dann startet ein Red eine 14tägige Wahl. Wahlbeteiligung ab ESB und fertig. Frage ist halt wer die VB dann ernennt/ändert. Bleibts bei Admins oder sollen Reds es auch dürfen * Ryuichi ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 22:43, 3. Nov. 2020 (CET)
Ich bin dagegen irgendwas rechtemässiges offiziell auf Discord zu machen wenn VBs abstimmen dürf(t)en, abgesehen von Nominierungen. Denn nicht alle VBs sind auf Discord und das sollte eigentlich nicht eine Bedingung sein um VB zu werden/bleiben/seine Rechte nutzen. Generell finde ich, das abgesehen von Admin-internem, kleineren Projekten mit wenigen involvierten (wo eine grosse Beteiligung nicht erwünscht ist) und Besonderheiten wie iwie VBW-Beurteilungen, die nicht das ganze Team angehen, Sachen grundsätzlich im Wiki geklärt werden sollten - und an der Stelle sehe ich dann nichts sinnvolleres als eine eigene Wahlseite, wo dann auch alle Fälle abgehandelt werden, ungeachtet dessen ob das jetzt eine "kontroverse" Entscheidung ist oder nicht. --Mecanno-manMäh 23:26, 3. Nov. 2020 (CET)
Ich finde, dass Ryu da nicht ganz Unrecht hat. Wir können es einfacher halten, komplizierter als die Red-Wahl sollte es keinesfalls werden. Daher finde ich auch: Ab ESB kann man einen SB und Veteranen vorschlagen. Weiter (wie Ryu meint) dürfen Veteranen sich bei den ESB melden, damit diese den Vorschlag weitergeben und die Wahl einleiten. An der Wahl dürfen ESB teilnehmen. Weiterhin bin ich dafür, dass vor der Wahl eine Kommentarfunktion für SB eingerichtet wird, womit dann die Wahl beeinflusst werden kann, aber eben nicht abgestimmt werden kann. Ansonsten wird wie bei der Red-Wahl verfahren. -- Feblue 00:55, 4. Nov. 2020 (CET)
@Mec: Ich glaube wir reden aneinander vorbei daher nochmal zum Mitschreiben
  1. pot. SB wir von ESB bei Reds vorgeschlagen bzw. Vet meldet sich bei Reds (Plattform Discord oder Wiki)
  2. Der Red macht eine kurze Meinungsumfrage (ja/nein) im Redchannel (ALLE Reds sind auf Discord) ob der Pot.SB/Vet zur Wahl gestellt werden sollte, bzw bei Sonderfällen eine Diskussion ob wahl oder direkt wieder vb. Das kann ja im Discord gemacht werden. Wurde ja bei PK damals auch so gemacht und sehe da keine Problematik.
  3. Red eröffnet bei 51% fürsprache 14tägie Wahl im Wiki. Stimmberechtigt ab ESB.
@Feblue: Wenn SBs die Wahl vorher beeinflussen, dann haben sie indirekt mit abgestimmt bzw. die Wahl in eine vorbestimmte Richtung gelenkt. Daher bin ich bei dem Vorschlag dagegen. Hintergrund sind wie gesagt nicht die derzeitigen SB sondern die SB-Voraussetzungen. Daher können SB während der Abstimmung natürlich ihre Meinung unter Kommentare hinzufügen was auch gerne gesehen wird allerdings sehe ich alles andere mehr als nur kritisch auf Grund der Voraussetzungen und nicht weil ich es z.b. dir persönlich nicht zutraue eine adäquate Meinung zu schreiben. Das wäre falsch wie man an deiner bisherigen Diskussionsbeteiligung ja sieht. Nur wenn wir jetzt anfangen SBs zu "bevorzugen" indem wir beispielhaft sagen feblue und Pöbel dürfen teilnehmen RBS und Mario nicht, oder umgekehrt (obwohl alle SB sind) dann wirkt das ziemlich Kalkül und intransparent usw. daher einfach klare Linie und fertig ka.gif * Ryuichi ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 07:06, 4. Nov. 2020 (CET)
Okay, deinen Standpunkt kann ich verstehen. Ich weiß gar nicht mehr, ob du Teil der Diskussion warst, aus der die Idee stammt. Ich erkläre einfach mal etwas mehr: Die Einbindung von SB bei Abstimmungen wurde ja durch die Wahlkonzepte bereits erwünscht, allerdings gab es da Gegenwind aufgrund der potentiellen Macht der SB, die sich in allen vorgeschlagenen Systemen irgendwie über ESB hinwegsetzen könnten. Daher war mein Einwurf auf Discord ("Dann müsste man aber auch die Kommentare zuerst freischalten, damit die Meinung der SBs auch wahrgenommen wird") darauf ausgerichtet, dass SB in einem wie dem Red-Wahlsystem eingebunden werden, allerdings keine Stimme haben. Die Idee dahinter ist, dass die Sichtweise der SB auf den zur Wahl stehenden SB offengelegt wird und somit ESB diese Sichtweise nutzen können, um sich selber ein klareres Bild zu machen. Ich hoffe, dass ich da jetzt die Idee besser erklärt habe. Ansonsten auf Discord zum Nachlesen: https://discordapp.com/channels/247122072378146816/303171986979291136/766047412418117653 Oder eben per Suche einfach von:feblue in:organisation eingeben, da findest du meine Idee und den Kontext relativ schnell. Das war am 14.10.2020. -- Feblue 13:11, 4. Nov. 2020 (CET)
Also ...würden Reds und Admins in deinem System quasi doppelt abstimmen, Ryu? Scheint mir ehrlichgesagt auch übermässig bürokratisch, was du ja gerade verhindern wolltest, oder?
Bezüglich Kommentarmöglichkeit für SBs - ich wüsste nicht warum sie dies nicht tun sollen, können sie ja bei ner Red-Wahl auch. Frage is halt ob vorher oder während der Wahl. Ich tendiere hier zu während, da da vorher meiner Meinung nach das ganze nur unnötig verzögert. --Mecanno-manMäh 16:04, 4. Nov. 2020 (CET)
SBs können gerne während der Wahl. Aber von vorher halte ich nix. Und wieso Doppelt und verkompliziert? Jeder Red vorschlag wird Admin intern besprochen und kommt dann auf die Wahlseite und dann kommt das öffentliche Feedback. So stehts bisher bei den Wahlen. Und eine Kurze Rundfrage in Red ob ja/nein und bei >50%ja wird die Wahl gestartet ist doch nicht überbürokratisiert. Oder wo siehst du massig doppelten Aufwand? Und bei sowas wie Max das kurz auf Redebene zu klären und ihn ggf. zu befördern ist doch eher vereinfacht statt überbürokratisiert. Aber z.b. Pöbel wird wegen VB angefragt und über die Hälfte der Reds sagt nein, dann sollte sich mMn ein Admin einschalten und mal nachfragen warum der Großteil dagegen ist. * Ryuichi ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 16:14, 4. Nov. 2020 (CET)
Ich finde, dass der Zeitaufwand sich lohnt. Daraus kann sich eine bisher passive Haltung der SB verändern, wenn sie sehen, dass sie ihren Senf bei etwas sehr wichtigem dazugeben können. Ich hatte zwar bei den letzten beiden Red-Wahlen kommentiert, weil ich beiden Gewählten etwas auf den Weg geben wollte, aber ansonsten hat das für mich keinen weiteren Sinn. Vielleicht ist das auch der bisher intendierte Sinn der Kommentare. Aber eine Stufe, die stimmberechtigt ist, sollte doch zumindest an der Wahl der nächsthöheren Stufe teilhaben können. Das steigert nicht nur das Potential der aktiveren Diskussionsteilnahme, sondern auch, dass die SB versuchen, tief in Thematiken einzudringen, die sie dadurch besser zu verstehen lernen. -- Feblue 00:48, 5. Nov. 2020 (CET)
@Ryu: Bei Redakteurs-Wahlen wird admin-intern eigentlich nur diskutiert, ob man jemanden selber vorschlagen soll, was keiner geregelten Struktur folgt und im Grunde genommen einfach ne Meinungsfindung ist, die auch jeder andere User informell betreiben kann. Wenn da aber von ausserhalb der Administration ein Vorschlag eingeht kommt dieser Vorschlag eigentlich immer zur Wahl. Eine interne Abstimmung der Admins ist an dieser Stelle nicht notwendig, weil dafür ja die erste Wahlrunde der Redakteurs-Wahl ist. Würde man bei einer VB-Wahl jetzt sowas offiziell noch in nen internen Kanal legen sehe ich dadurch eine doppelte Befassung des Themas durch Admins und Reds, weil sie erst die Wahl da beurteilen müssen und danach noch selber abstimmen gehen sollen. Eine erste/zweite Wahlrunde mit Trennstrich Red/VBs sehe ich auch nicht wirklich als all zu sinnvoll, weil die Reds üblicherweise genügend Stimmen haben das schon klar ersichtlich ist, wohin die Wahl geht. Die Reds und Admins nur auf Discord abstimmen zu lassen scheint mir ihm Rahmen des Transparenzwunsches auch nicht sinnvoll. --Mecanno-manMäh 03:42, 5. Nov. 2020 (CET)

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

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

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

Ich werde hier jetzt mal noch eine Idee hin schmeißen:
  1. Ein SB (hier zählen auch die SB-Vets hinzu) kann von einem VB oder höher für eine VB-Wahl vorgeschlagen werden; Veteranen brauchen demnach erstmal die Stimmberechtigung
  2. Bevor die Wahl auf der gesonderten Wahlseite vom VB+ aus Punkt 1 gestartet wird, wird dies auf Discord in #intern angekündigt. Hier können Admins (bei Unstimmigkeiten auch Reds) die Wahl noch stoppen. Durch diese Maßnahme entfällt das Vetorecht der Admins. Ein Grund für den Abbruch der Wahl kann, aber muss nicht mitgeteilt werden. (Mit wie viel Vorsprung die Ankündigung gemacht werden soll hab ich keine Ahnung)
  3. Die Wahl dauert zwischen 1 und 3 Wochen. Sobald 2/3 für Pro erreicht sind, wird der SB zum VB befördert
  4. Wer stimmt ab: Alle VB+ (Admins und Reds sollen/müssen, VBs und PLs sind dazu aufgefordert ihren Senf dazu zu geben)
  5. Was ist mit den SBs?: Diese werden nicht in die Wahl eingebunden, da diese größtenteils nicht einschätzen können, ob ein SB zum VB werden soll. Allerdings haben sie die Möglichkeit wie bei der Red-Wahl den Kommentarbereich zu nutzen.
  6. Wenn ein VB direkt Wahl zum PL werden würde: Macht da was ihr denkt. Sollte jemals dort was schief laufen komm ich um die Ecke mit einem „Hab ichs euch doch gesagt.“?
  7. Ich hoffe ich habe jetzt nichts vergessen. Falls doch: Mist!
Soweit erstmal mein Gedanke zu dem Thema. Vielleicht kann man ja irgendwas davon nutzen oder bei ner Lücke, die ich übersehen habe, noch ausbessern. Ich hoffe einfach mal, dass wir das Thema nicht ins nächste Jahr mitnehmen werden müssen. GrollenKette951 22:03, 14. Nov. 2020 (CET)
Hieß es irgendwo, dass Veteranen ohne SB vorgeschlagen werden können? Zumindest ich hatte immer SBs als Wahl-Kandidaten genommen und da zähle ich Vet-SBs dazu, Vet und SB sind ja separate, voneinander unabhängige Ränge. Den zweiten Punkt sehe ich am kritischsten. Denn der hat das meiste Intransparenz- und Konflikt-Potenzial und ist recht schwammig formuliert. Inwiefern kann die Wahl gestoppt werden? Welche nötigen Mehrheiten usw.? Zum vorletzten Punkt: Ich verstehe immer noch nicht warum potentielle Neu-PLs eine Sonderbehandlung kriegen sollten. Natürlich sollte angemerkt werden, dass der Kandidat bei Erfolg direkt PL werden würde, aber ich sehe absolut keinen Sinn dahinter eine Wahl für einen Rang zu überspringen, der Grundvoraussetzung für PL ist. Und wenn der User nicht durchkommt, bleibt das Projekt halt ohne PL. Mit den aktuellen VBPL-Ernennungsbestimmungen würde ein PL-Kandidat ja auch nicht unabhängig von seiner VB-Eignung einfach direkt eingesetzt werden. Ob du immer noch der Ansicht bist, weiß ich nicht. Du hast aber mal vor geraumer Zeit ein Überspringungsrecht für PL-Kandidaten gefordert. --DeXter 22:49, 14. Nov. 2020 (CET)

Abstimmung

Abstimmung beendet

Kommentare

Für den Fall dass Fragen aufkommen, woher diese Abstimmung stammt: Die Abstimmungspunkte sowie dass Abstimmungsverfahren wurde von der Administration - teilweise auch mit Input von ESBs - erarbeitet. Die Abstimmung ist modular, statt direkt über verschiedene Systeme, damit sich nicht ähnliche Systeme gegenseitig Stimmen wegnehmen. Optionen, die mal diskutiert wurde, hier aber nicht zur Abstimmung stehen wurden entweder in der Diskussion von allen Beteiligten als nicht sinnvoll erachtet (inklusive dem, der es zuerst vorgeschlagen hat) oder wurden von der Administration kategorisch ausgeschlossen - meistens da sie nicht zufriedenstellend umsetzbar sind. Der Grund wieso wie hier überhaupt ne Abstimmung machen, ist das die Diskussion so gut wie eingeschlafen ist - es beteiligten sich zuletzt nur noch sehr wenige daran, es braucht hier aber ein Entscheid, der von mehr als nur diesen wenigen akzeptiert wird. --Mecanno-manMäh 23:58, 24. Nov. 2020 (CET)

Da dies hoffentlich der Abschluss von der ganzen Sache ist, möchte ich noch diese Gelegenheit nutzen um abschließende Kritik zu diesem Thema zu äußern (ja, ich weiß, auf beiden Seiten besteht zu diesem Thema absolut keine überglückliche Freude, aber aktuell habe ich die Befürchtung, dass so ein Vorgehen irgendwann wieder mal gemacht werden könnte, da zumindest ich keine oder kaum Einsicht der anderen Diskussionsseite wahrgenommen habe): Wir brauchen jeden Nachwuchs den wir kriegen können. Wir sind nicht in der Position für eine Diskussion ESB-Neuzugänge zu blockieren und dennoch wurde dies nun für ziemlich genau 3 Monate lang getan - die ersten Wochen außerdem im Geheimen. Auch wenn ich die Argumente der Admins nachvollziehen kann, dass man nicht den Anschein erwecken will, man würde noch schnell seinen Willen durchpressen, und dass man dachte die Sache wäre bald vorbei. Ich kann das nicht akzeptieren. Die VBPL-Ernennungsblockade war bzw. ist für mich genau dieses Durchpressen von Willen. Es wurde nicht gefragt, ob Leute etwas dagegen hätten, wenn man weiterhin nach den bestehenden Bestimmungen verfahren würde, es wurde einfach, ich denke mal, admin intern beschlossen, dass das nicht in Ordnung sei. Hier hat mMn ganz klar die Kommunikation gefehlt. Das Zeitargument ist natürlich schwierig, denn man kann nicht in die Zukunft sehen. Dazu möchte ich nur sagen, dass ich es nicht akzeptieren werde, als ein Blockierer hingestellt zu werden, bloß weil ich versucht habe die Diskussion wieder ins Laufen zu bringen. Ich glaube, dass mein versuchter Neustart mehr Anreiz für u. a. Ryu war in die Diskussion einzusteigen und er hat wichtige neue Sichtweisen in die Diskussion gebracht.
Ich will hiermit absolut nicht noch eine Diskussion zu dem Thema starten, aber dennoch wäre eine öffentliche Stellungnahme der Admins denke ich nicht verkehrt, da glaube ich seit dieser "Randnotiz" vor einiger Zeit speziell dazu nichts mehr kam, was besonders für die aktuellen VB-Kandidaten, denke ich, nicht so toll ist.--DeXter 01:28, 25. Nov. 2020 (CET)

Fazit

Ich habe jetzt in Rücksprache mit den anderen an einer Ausformulierung gearbeitet und auf der Seite zu Verlässlichen Benutzern gesetzt. Bei der Ausarbeitung sind zwei Punkte noch nicht vollends geklärt, sollen aber an dieser Stelle noch geklärt werden. Diese habe ich in der Ausformulierung auch versteckt im Quelltext kommentiert. 1) Die Stimmpflicht für Redakteure in der ersten Wahlrunde ist durch den zweiten Punkt in der Abstimmung erstmal umgesetzt worden. Durch den vierten Punkt wird aber eigentlich deutlich, dass dort noch Klärungsbedarf besteht, wie eine solche Verpflichtung aussehen sollte, wenn es zu einer kommen soll. Daher gibt es dort erstmal ein vage Beschreibung bzgl. der Stimmabgabe innerhalb der ersten Wahlrunde. 2) Die Kennzeichnung einer Wahl, wo der neue potentielle Verlässliche Benutzer im Anschluss direkt ein Projektleiter werden würde. Da ist noch nicht ganz klar, wie genau die Kommunikation im Vorfeld und die Kennzeichnung bei der Wahl aussehen sollten, sodass dies noch abgestimmt werden muss.
Um anstehende Wahlen aber nicht noch länger durch eine weitere Diskussion nach der Abstimmung aufzuschieben, gibt es erstmal den ausformulierten Kompromiss und diese beiden Punkte können parallel dazu geklärt werden. ~ Taisuke Diskussion 21:39, 12. Dez. 2020 (CET)

Zu 1) hatte ich gehofft das „Mit Stimmpflicht ist ein System ähnlich wie das der ersten Wahlrunde gemeint – sprich die Wahl wird nicht abgeschlossen, bis klar ist, dass die Stimmen der entsprechenden Benutzer das Wahlergebnis nicht verändern, auch wenn die eigentliche Abstimmungsfrist vorbei ist.“ man einfach das Wahlsystem der Redakteurs-Wahl diskussionslos übernehmen könnte. Das ganze mit „Abstimmungsfrist“ kam dabei nur dadurch zustande, das man das auch irgendwie hätte umsetzen müssen, wenn die Wahlrunden gleichzeitig gewesen wären. Ich bin an dieser Stelle weiterhin dafür, das einfach wie die erste Runde der Red-Wahl zu machen.
Zu 2) ist es wahrscheinlich sinnvoll, Projektleiterernennungen formell von der VB-Wahl zu entkoppeln. PLs müssten demnach vor ihrer Einsetzung schlicht und einfach VBs sein und wenn sie nicht Redakteure sind von den Admins bestätigt werden - formell in der VB-Wahl steht dann gar nix, wobei jeder User da grundsätzlich in seiner Stimmbegründung schreiben kann was er will - auch ob er/sie den User z. B. gerne als Co-Leiter hätte. Wenns den Admins nicht passt können sie ihn immer noch ablehnen. --Mecanno-manMäh 20:34, 14. Dez. 2020 (CET)
Ich bin bezüglich 1) etwas zwiegespalten, weil es, wie Robbi schon in der Abstimmung anmerkte, in der ersten Wahlrunde zu einem Ergebnis kommen muss. Die erste Wahlrunde sollte also auch irgendwie zeitig abgeschlossen werden. Das ginge mittels einer Stimmpflicht (nicht gewollt) oder einer Frist (die dem gleichkommt), wobei da ja wieder die Frage ist, was gemacht wird, wenn kein eindeutiges Resultat vorliegt und die Frist abgelaufen ist. Vielleicht erklären sich die Redakteure in der Hinsicht, wie sie sich das vielleicht vorgestellt haben.
Zu 2) hätte ich eine Idee: Der vorschlagende Redakteur / Admin fügt eine weitere Box (die entworfen werden müsste) hinzu, die darauf hinweist, dass der Kandidat auch als PL vorgeschlagen wird. Stimmen die Admins und der / die zugehörige(n) PL zu, wird auch der PL an den Kandidaten vergeben. Mit dem getrennten Vorgehen könnte man denke ich auch leben, aber da finde ich, dass dann ein unnötiger Delay zwischen VB-Ernennung und PL-Ernennung entsteht. Feblue 23:11, 17. Dez. 2020 (CET)

Im Chattreffen vom 06.03.2021 wurden offene Punkte final besprochen und der Ursprungs-Punkt ins Archiv. Die aus diesem Punkt resultierte fehlende Wertschäztung wurde Besprochen und diese wird gesondert noch einmal angesprochen. * Ryuichi ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 10:49, 7. Mär. 2021 (CET)

Trivia: Bezüge aus der realen Welt

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

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

Was denkt ihr, macht es Sinn, solche Richtlinien zu verabschieden und irgendwo festzuhalten? Liebe Grüße, 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 ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 11:49, 29. Sep. 2020 (CEST)
Ich halte es fragwürdig das ganze als Triviapunkte aufzunehmen, das wird bei beliebten Pokémon (Pikachu, Glurak, die Kanto-Starter, Mewtu etc.) doch eher dazuführen das die Triviapunkte ellenlang werden. Ausserdem wird es garantiert Anspielungen geben, die sich nicht wirklich auf einen Artikel in unserer Struktur beziehen, sondern auf Sachen im Pokémon-Franchise generell. Aus diesem Grund fände ich hier ein Verfahren, wie es Bulba hat, besser geeignet: Einfach einen Artikel für die Anspielungen in anderen Medien. In diesem müsste man sich dann imo. nicht mehr auf deutschsprachige Medien reduzieren. Forschung kann imo. auch einen eigenen Artikel bekommen, da wird es garantiert auch genug zu geben. Vermischen würde ich die beiden aber nicht. Einige klar-zuordnbare Forschungssachen können imo. auch in den Triviapunkten bleiben (z. B. der Aerodactylus) aber bei Anspielungen in Medien würde ich eher davon absehen. --Mecanno-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 ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 15:51, 29. Sep. 2020 (CEST)
Interessante Diskussion! Ich würde mich ebenfalls freuen, wenn wir solche Punkte (weiterhin) im Trivia-Bereich des jeweiligen Artikels unterbringen. Die von Max vorgeschlagenen Richtlinien halte ich schon für äußerst gut überlegt und dafür anwendbar. Des Weiteren stimme ich ebenfalls mit Ryu überein und plädiere an dieser Stelle auch für Belege dieser Umstände. Das wird sonst für mich und jeden anderen kontrollierenden Benutzer eine Qual, die Punkte auf eigene Faust herauszusuchen und somit zu prüfen. Aus diesem Grund bietet sich ein Screenshot an. Bei generellen Verweisen bin ich mir aber auch noch nicht ganz sicher, wie man das gestalten sollte. Entweder man sagt, diese sind zu unspezifisch und bedürfen daher keiner Erwähnung oder man sammelt nur diese in einem eigenen Artikel. Darüber hinaus sollten wir uns an der Stelle nicht zu sehr festlegen, wie das Ganze im Zweifel auszusehen hat, wenn x Punkte vorhanden sind. Vielmehr erstmal schauen, was das überhaupt für ein Ausmaß annimmt und dann Einzelfallentscheidungen treffen, denn mehr als z. B. zehn Pokémon-Artikel wird das ohnehin nicht betreffen. Ich könnte es mir beispielsweise gut vorstellen, dass sich gleichende Bezüge auch zusammengefasst werden können: „Glurak ist in verschiedenen Quizshows, u. a. Wer wird Millionär?, Teil einer Frage gewesen. [1], [2], [3], [4]“ Somit vermeidet man sowohl Dopplungen als auch einen neuen Unterabschnitt, der evt. nur sieben verschiedene Fragen aus Quizshows listet, bei denen Glurak eine Antwortmöglichkeit gewesen ist.
Ich bin mir also sicher, dass wir für diese wenigen Fälle kreative Lösungen finden werden. :) ~ Taisuke Diskussion 11:19, 30. Sep. 2020 (CEST)

Im Chattreffen vom 06.03.2021 bestand der Konsens das es zu Tais Aussage keine weitere Ergänzung braucht und der Punkt als erledigt betrachtet werden kann.

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. --Mecanno-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 ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 21:57, 4. Okt. 2020 (CEST)
Ich hab ehrlicherweise weder hier im Wiki noch auf Social Media einen Plan wofür man solche Daten benutzen sollte. Was bringt es uns zu wissen wie vielen Leute welches Pokémon, welche Gen oder welches Spiel gefällt? Und weiterhin sehe ich auch keinen Fall, in dem ein etwaiger Zeitaufwand die HS umzubauen und eine Extension zu basteln einen Mehrwert für das Wiki haben könnte. Da Ryu jetzt hier noch vor mir geantwortet hat, werde ich das hier erst mal speichern und später noch was schreiben. GrollenKette951 22:02, 4. Okt. 2020 (CEST)
Ich verstehe eure Kritik hinter dem Sinn, aber gleichzeitig finde ich den Vorschlag von Ryu und Isso ziemlich super. Zu einem können wir Leute dazu anregen die Artikel auf Inhalte zu korrigieren und zu vervollständigen und andererseits kann man diese Umfragen als Hilfe für AdWs nutzen. Der eigentliche Sinn meinerseits soll dabei die Kommunikation mit der Community sein und etwas mehr Nähe zu ihr aufzubauen. Mir persönlich zumindest gefällt es immer mehr wenn die Wikis Nähe zu der Community finden, damit auch diese Leute merken, dass hier Menschen arbeiten. Ich glaube euch, dass das nicht einfach umzusetzen ist, aber ich glaube auch, dass sich das auszahlen wird, grade da sich Leser über sowas freuen würden (ich habe die Idee auch einigen Leuten im privaten Umfeld erklärt, die sich so etwas gerne wünschen). - -wowoJonny 08:24, 5. Okt. 2020 (CEST)
Wenn es um Vorschläge wie diesen geht, habe ich eigentlich stets ein offenes Ohr. Der erste Part bezieht sich auf die Argumentation im Sinne einer Motivation zum Mitmachen: Mir leuchtet nicht ein, wieso wir nun an einer zweiten möglichen Stellschraube drehen wollen, die neue Leute bzw. einfache Seitenbesucher zum Mitmachen motivieren soll, wenn wir unsere erste Stellschraube nach mittlerweile fast zwei Jahren noch immer nicht gedreht haben. Wir wissen noch nicht, wie sich die Stellenanzeigen am Ende auswirken und vielleicht stellen wir durch diese fest, dass die Hauptseite für solche Vorhaben ohnehin schlecht gewählt ist. Oder aber sie fruchten und es braucht keine weitere Idee, die ein ähnliches Ziel verfolgt.
Darüber hinaus sehe ich auch keinen Nutzen für die dadurch erhobenen Daten. Sie sind weder für Artikelinhalte nutzbar, da sie keineswegs aussagekräftige Daten darstellen werden, noch werden wir dadurch konstruktiven Input aus der Community zu Veränderungen erhalten. Dafür bräuchte es mehr als ein einfaches Ankreuzen vorgeschriebener Antworten, sondern dann würde ich mir individuelle Begründungen und Verbesserungsvorschläge wünschen. Denn damit kann ich am Ende als Benutzer auch arbeiten. Dies werden wir aber wohl hierüber nicht in Erfahrung bringen können.
Dann wäre da noch das Argument, dass man die Daten für das XdW-Projekt nutzen könnte. Dem Projekt mangelt es neuerdings nicht an geschriebenen Texten und floriert seit einiger Zeit ungemein. Die Knappheit an Texten kann hier also nicht der Ausschlag sein. Und auch Umfragen wie „Was ist eure Lieblingsregion?“, die dann zu einem AdW führen sollen, sehe ich nicht gewinnbringend für uns. Denn am Ende der Umfrage, schreiben dennoch dieselben Leute die Texte. Wenn es ganz doof läuft, fühlt sich dabei dann auch wieder jemand an die Challenges bei Filb erinnert, wo uns quasi nur vorgegeben wurde, wozu ein Text geschrieben werden musste und die eigentliche Arbeit bleibt dann trotzdem an den Projektmitgliedern und der Leitung hängen. Oder übersehe ich hier etwas?
Versteht mich nicht falsch, ich finde es toll, dass sich Gedanken gemacht werden, wie man das PokéWiki mehr als Community nach außen darstellen kann. Ich sehe aber aus den oben genannten Gründen nicht, wie das eine Umfrage auf der Hauptseite leisten können soll. Ich würde mich auf jeden Fall nicht als Teil einer Community sehen, nur weil ich ich wöchentlich/monatlich bei einer zufälligen Umfrage eine „Ein-Klick-Antwort“ abgebe. Es braucht da in meinen Augen eher einen anderen Ansatz. ~ Taisuke Diskussion 22:05, 5. Okt. 2020 (CEST)

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

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

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

Der Punkt wurde im Chatttreffen vom 06.03.2021 besprochen. Eine derzeitige Einfügung in die Hauptseite wird nicht in betracht gezogen und der Punkt damit als erledigt betrachtet. * Ryuichi ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 10:49, 7. Mär. 2021 (CET)

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 ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 16:47, 28. Okt. 2020 (CET)
Wir haben doch Vorlage:Anmerkung, die kann auch ihr Symbol verändern. Etwas richtung [sic!] wäre hier also durchaus realisierbar und würde auch mobil funktionieren. Sieht allerdings nicht perfekt aus, wobei man natürlich auch ohne diese Vorlage eine ähnliche Vorlage bauen könnte, die nicht so komisch aussieht. -- RobbiRobb 16:53, 28. Okt. 2020 (CET)
Das komische sind hier nur die Klammern...sic! ohne würde es mMn auch passen ka.gif * Ryuichi ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 17:26, 28. Okt. 2020 (CET)
Das Anmerkungs-Ding mag ich nicht wirklich, da fände ich simplen hochgestellten Text besser. Wüsste nicht warum das jetzt in nem Oval stehen braucht. Grundsätzlich wär ich auch dafür da ne Vorlage zu haben, vergesse nämlich jedes Mal wenn ich das nutze wie's andererorts gemacht ist, wodurch wahrscheinlich auch Teile der Uneinheitlichkeit her rühren.
Eine Kurze Anmerkung an den, der das dann ersetzen geht (ich hoffe mal Tai, da er's angesprochen hat :hihi:) - bei <!--sic!--> handelt es sich auch um ein uraltes Steuerding für einige Bots, wodurch diese diese Seiten ignorierten. Ich glaube nicht das wir noch Bots haben, die das beachten, aber man sollte eventuell mal nachfragen. Generell: Wenn ihr da also ein sic für gar nix seht ist es wahrscheinlich so ein uraltes Bot-Ignorier-Flag. --Mecanno-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)

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

Beim Brückbrief W lässt man mir scheinbar keine Mitbestimmungsmöglichkeit; BlauesSerpiroyal hat das ganze dort bereits einfach angepasst. Werd ich jetzt vorerst einfach so stehen lassen, grundsätzlich sollte man das vermutlich überall so machen, im Moment hab ich aber definitiv nicht die Zeit, 17k Item-Beschreibungen auf korrekte Schreibung zu prüfen. Bei Geckarbor hab ich das aber mal rausgenommen, generell halte ich es im Anime für nicht sonderlich sinnvoll, da passt ohnehin die Hälfte nicht. -- RobbiRobb 11:24, 6. Nov. 2020 (CET)
Entschuldigung, ich hab nur gesehen, dass es dafür eine Vorlage gibt und dass die da noch nicht war. BlauesSerpiroyal Diskussion 11:34, 6. Nov. 2020 (CET)
Hab die sics bei öfters mal entfernt (und Killuu ne DM geschrieben, das das Wort existiert...).
Was das ganze angeht, wirklich überzeugt bin ich da noch nicht von, besonders da das sic im Oval bedingt durch Vorlage:Zitat häufig kursiv ist. Ganz vom Oval abkommen würde ich allerdings doch nicht mehr, da mit oval es deutlich erkennbarer ist, das da ein tooltip existiert. Im Grunde genommen ist das also nur noch meckern, ohne das ich ne bessere Lösung hab - ignoriert mich also, ausser ihr habt selber gerade nen Geistesblitz wie ihr mich zufriedenstellen könnt. (...wobei, ist es technisch machbar, Schrift innerhalb von nem italic als non-italic zu markieren...?) --Mecanno-manMäh 19:13, 6. Nov. 2020 (CET)
Kurzer Einwurf zur Behandlung von „öfters“: Ja, das Wort existiert, allerdings ist es in Deutschland inkorrekt. Nur in der Schweiz und in Österreich soll es das Wort geben. Daher meine Frage: Wurde / Wird im PokéWiki das Vokabular des gesamten deutschsprachigen Raums angewandt oder halten wir uns nur an das deutsche Wörterbuch? Ich fände da eine einheitliche Regelung sehr sinnvoll. -- Feblue 20:11, 6. Nov. 2020 (CET)
Der Duden nennt da auch „landschaftlich“, und abgesehen von dem einen Ruhmesdatei-Eintrag haben die Charaktere einen ländlichen Hintergrund, sehe jetzt da keinen Grund das als falsch zu bezeichnen. Und für den einen Ruhmesdatei-Eintrag will ich jetzt auch nicht wirklich n sic drin haben, ansonsten packt das noch wer in den anderen wieder rein... --Mecanno-manMäh 23:49, 6. Nov. 2020 (CET)
Falls mein letzter Diskussionsbeitrag wie eine Aufforderung zum Durchforsten aller Item-Beschreibungen rübergekommen ist, dann tut es mir leid. Denn das war nicht meine Absicht, Robbi. Ich wollte die Handhabung bei dem expliziten Einzelfall nur nicht ohne Rücksprache mit dir einfach alleine entscheiden.
Darüber hinaus scheint es eine interessante Diskussion zu sein, was wir genau bei Zitaten als richtig ansehen. Das Bestreben nach einem einheitlichen Vokabular bzw. einer damit einhergehenden Regelung kann ich nachvollziehen, sollte jedoch bei Bedarf eher separat nochmals aufgearbeitet werden. Hier geht das Ganze dann doch eher unter. Wobei ich ohnehin das Gefühl hätte, dass dort jetzt nicht unbedingt eine Vielzahl an Benutzern an der Diskussion teilnehmen würde.
Ansonsten ist mir noch aufgefallen, dass bei einigen Vorlagen-Verwendungen nicht unbedingt ersichtlich ist, warum der Hinweis dort zu finden ist. Beispielsweise wenn vor einem Komma ein Leerschritt zu finden ist, obwohl im Deutschen dort keiner zu sein hat. Vielleicht könnte man dort im Quelltext bei der Vorlagenverwendung noch irgendwie eine Art Begründung mit einbauen, um es ersichtlich zu machen, worin der Fehler des Zitats liegt. ~ Taisuke Diskussion 16:10, 11. Nov. 2020 (CET)
Nein, keine Sorge, so kam das nicht rüber. Ich habe einfach von meiner Seite aus darauf aufmerksam machen wollen, dass es eben nicht einheitlich ist bei den Items, ich weiß, dass an einigen Stellen Fehler drin stehen, die nicht markiert sind, daher gehe ich davon aus, dass es noch viele weitere - für die ich aber wie gesagt nicht die Zeit habe, sie alle zu finden. -- RobbiRobb 16:36, 11. Nov. 2020 (CET)

Laut Chattreffen vom 06.03.2021 erledigt. * Ryuichi ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 10:49, 7. Mär. 2021 (CET)

Vorstellung: Pokémon-Zuchtrechner

Hallo zusammen!

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

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

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

  • Was kann der Zuchtrechner und wie benutzt man ihn?
    Der Zuchtrechner berechnet insgesamt drei Arten von Ergebnissen: Die Wahrscheinlichkeiten dafür, dass ein gezüchtetes Pokémon ...
  1. insgesamt keine, einen, zwei, drei, vier, fünf bzw. sechs sensationelle (also maximale) DVs hat.
  2. vom Nutzer eingegebene Kombinationen von Anforderungen an die DVs erfüllt.
  3. Kraftreserve vom Typ Kampf, Flug, etc. einsetzen kann.
Zusätzlich zu den Wahrscheinlichkeiten sind jeweils auch die Versuche angegeben, die durchschnittlich benötigt werden, um das jeweilige Zuchtergebnis zu erhalten.
Für all diese Berechnungen müssen zunächst die DVs der Eltern-Pokémon in der obersten Tabelle eingetragen werden. Leere Felder und ungültige Eingaben werden dabei als ein DV-Wert von 0 betrachtet. Über ein Dropdown-Menü können zudem die Items ausgewählt werden, welche die Eltern tragen. Diese Angaben reichen schon aus, um die Wahrscheinlichkeiten für die Anzahl sensationeller DVs und die Verteilung der Kraftreserve-Typen zu berechnen (um die Berechnung zu starten, muss auf den Knopf "Wahrscheinlichkeiten berechnen" am Ende der Seite geklickt werden).
Die Tabelle für Kombinationen ermöglicht es dem Nutzer, die Wahrscheinlichkeit für das Zuchtergebnis zu berechnen, das er gerne erreichen möchte. Dazu gibt man an, welchen KP-DV, welchen Angriffs-DV usw. das Kind haben soll. Das Wichtige ist, dass hier nicht nur einzelne Werte eingegeben werden können, sondern auch Wertebereiche, z. B. "20-31". Man kann so auch angeben, dass ein bestimmter DV-Wert egal ist (z. B. der Spezial-Angriff für ein Pokémon, das ein physischer Angreifer werden soll), indem man das entsprechende Feld freilässt oder "0-31" einträgt. Für bestimmte Wertebereiche sind als alternative Schreibweisen auch "n+" für "n-31", "n-" für "0-n" (also z. B. "20+" für "20-31") und "X" für "0-31" erlaubt. Zuletzt kann man noch den Kraftreserve-Typen auswählen oder dieses Feld bei der Standard-Option "beliebig" belassen.
Der berechnete Wert ist dann die Wahrscheinlichkeit dafür, dass ein gezüchtetes Pokémon all diese Anforderungen erfüllt. Ein Beispiel aus dem verlinkten Screenshot: Bei "Kombination 2" wird die Wahrscheinlichkeit dafür berechnet, dass ein gezüchtetes Pokémon einen KP-DV von mindestens 20, einen Angriffs-DV von min. 25, einen Verteidigungs-DV von min. 15, einen Spezial-Verteidigungs-DV von min. 12, einen Initiative-DV von 31 und den Kraftreserve-Typ Boden hat.
Ungültige Eingaben werden wie leer gelassene Felder betrachtet und mit einem roten Rahmen versehen. Es stehen mehrere Zeilen für Kombinationen zur Verfügung, um ähnliche Kombinationen miteinander vergleichen oder zusammenrechnen zu können.
  • Welche Unterschiede gibt es zwischen Version 2 und 3?
    In Version 3 habe ich ein paar Verbesserungen der Nutzbarkeit durchgeführt:
  1. Statt einer festen Anzahl von Kombinationen steht zunächst nur eine Zeile zur Verfügung, es lassen sich aber mit Knöpfen unter der Tabelle beliebig viele Zeilen hinzufügen oder wieder entfernen.
  2. Am Anfang jeder Kombinationszeile (außer der ersten) wurde ein kleiner Knopf hinzugefügt, mit der sich die Kombination aus der vorherigen Zeile in die aktuelle kopieren lässt.
  3. Neben jedem Eingabefeld wurde eine Checkbox hinzugefügt, die den Wert des jeweiligen Feldes automatisch auf "31" setzt. Dies beschleunigt die Verwendung für diesen häufig genutzten Anwendungsfall, da man sich die Eingabe der Zahl 31 spart.
Diese Anpassungen sind aber vielleicht Geschmackssache und vor allem die erste ist möglicherweise nicht problemlos im PokéWiki umsetzbar (zumindest habe ich hier noch keine Tabellen gesehen, die dynamisch die Anzahl ihrer Zeilen oder Spalten ändern), deswegen habe ich zum Vergleich auch die simplere v2-Version zum Download bereitgestellt.
  • Wozu ist dieser Zuchtrechner nützlich? Und gibt es Interesse dafür?
    Abgesehen davon, dass man die Wahrscheinlichkeiten für Zuchtergebnisse möglicherweise nur aus Interesse wissen möchte, kann er auch tatsächlich bei der Zucht hilfreich sein: Z. B. wissen viele sicherlich Spieler, die Pokémon mit sechs sensationellen DVs züchten wollen, nicht, ob man dafür lieber Eltern mit fünf sensationellen DVs auf verschiedenen oder gleichen Statuswerten verwenden soll, oder ob sich für ein gewünschtes Zuchtergebnis ein Machtitem oder ein Fatumknoten besser eignet. Solche Fragen kann dieser Rechner beantworten. Außerdem hilft er einem vielleicht dabei, sich realistischere Zuchtziele zu setzen, wenn man sieht, dass man für ein gewisses Ergebnis durchschnittlich über 1000 Versuche braucht oder es sogar unmöglich ist.
    Dass es Interesse für einen solchen Zuchtrechner gibt, erkennt man auch daran, dass es bereits ähnliche Rechner im Internet gibt, z. B. behandelt dieser Rechner den Spezialfall, dass der Fatumknoten, aber kein Machtitem von den Eltern getragen wird und unterscheidet bei den DVs nur zwischen 31 und nicht 31 bzw. beliebig. Ein anderer Rechner bietet ein paar mehr Funktionen, gibt dafür aber in vielen Fällen Ergebnisse aus, die meiner Meinung nach nicht ganz korrekt sind.
    Keiner dieser Rechner unterstützt aber z. B. Wertebereiche für gewünschte Zuchtergebnisse oder Kraftreserve-Typen, sodass der von mir entwickelte Zuchtrechner meines Wissens momentan ziemlich einzigartig ist.
  • Sind die vom Zuchtrechner berechneten Wahrscheinlichkeiten definitiv korrekt?
    Das kann ich leider nicht garantieren, da ich den Code, mit dem die Spiele die DVs von gezüchteten Pokémon festlegen, nicht kenne. Ich habe aber natürlich die grundsätzlichen Regeln, die bei der Zucht gelten, beachtet und gehe ansonsten davon aus, dass alles einigermaßen "normal" umgesetzt ist, dass also z. B. die Chance, dass die DVs der Statuswerte KP, Angriff und Verteidigung vererbt werden, gleich der Chance für die Vererbung von Angriff, Sp.-Ang. und Initiative ist. Ich kann aber sagen, dass die berechneten Ergebnisse mit meinen Erfahrungen bei der Zucht und meinen Tests übereinstimmen. Es kann aber natürlich noch Bugs geben, die mir bislang nicht aufgefallen sind. Die würde ich auf jeden Fall korrigieren, wenn sie mir gemeldet werden.
    Ein Punkt, bei dem der Zuchtrechner momentan aber definitiv nicht die korrekten Ergebnisse liefert, ist wenn beide Eltern-Pokémon Machtitems tragen. In diesem Fall ist es quasi so, dass sich das Spiel bei jedem gezüchteten Pokémon zufällig eines der beiden Machtitems aussucht und dann nur dieses Wirkung hat. Dieses Verhalten lässt sich leider nur schlecht mit der aktuellen Berechnungsstruktur umsetzen, allerdings ist dieser Fall auch nicht besonders wichtig, da es aufgrund dieses Verhaltens praktisch nie sinnvoll ist, beiden Eltern-Pokémon ein Machtitem zu geben. Auf diesen Fehler sollte man dann hinweisen, wenn man den Zuchtrechner ins PokéWiki einbindet.
    Und eine Sache noch: Um Platz zu sparen, steht im Zuchtrechner an vielen Stellen "Versuche", gemeint sind aber immer durchschnittliche Versuche. Wenn also nicht "1" oder "Unmöglich" bei den Versuchen angegeben wird, können wie bei Schillernden Pokémon wesentlich mehr oder weniger Versuche als angegeben benötigt werden.
  • Für welche Pokémon-Spiele liefert dieser Zuchtrechner korrekte Resultate?
    Grundsätzlich sollten die Ergebnisse für alle Pokémon-Hauptspiele seit Pokémon Platin stimmen, wobei nicht jede Funktion für jedes dieser Spiele relevant ist. (Machtitems haben erst seit Heartgold und Soulsilver Auswirkungen auf die Zucht, der Fatumknoten seit X und Y. Die Kraftreserve-Typen sind für Schwert und Schild nicht mehr relevant.)
    In Pokémon Smaragd, Diamant und Perl funktioniert die Zucht leicht anders, sodass die berechneten Wahrscheinlichkeiten ein bisschen von den tatsächlichen abweichen sollten. Bei Rubin, Saphir, Feuerrot und Blattgrün bin ich mir anhand der Beschreibungen, die ich zu deren DV-Vererbung gelesen habe, unsicher, ob es letztendlich das gleiche System wie seit Platin ist oder ob es doch einen Unterschied gibt, der auf diesen Seiten nicht explizit erwähnt wurde. In jedem Fall sollten die berechneten und tatsächlichen Wahrscheinlichkeiten aber auch für diese Spiele nicht zu stark voneinander abweichen.
  • Wie berechnet der Zuchtrechner die Wahrscheinlichkeiten?
    Ohne hierfür zu sehr ins Detail gehen zu wollen, kann ich schonmal sagen, dass die Berechnungen deutlich komplizierter sind, als z. B. die des Statuswerte-Rechners, der vor einiger Zeit in die Pokémon-Artikel integriert wurde. Es gibt keine verhältnismäßig einfache mathematische Formel zur Berechnung der Wahrscheinlichkeiten (zumindest ist mir keine eingefallen), aber das macht einen funktionierenden Rechner ja nur nützlicher. Es werden zwei verschiedene Techniken verwendet: Für die Wahrscheinlichkeiten für eine Anzahl maximaler DVs werden mehrere Binomialkoeffizienten berechnet und kombiniert, um die Anzahl der Möglichkeiten, mit der diese Anzahl sensationeller DVs erreicht werden kann, durch die gesamte Zahl an Möglichkeiten zu teilen. Für die Wahrscheinlichkeiten für eingegebene Kombinationen und Kraftreserve-Typen wird für jede mögliche Auswahl vererbter Statuswerte (also z. B. KP, Angriff, Sp.-Vert.) die Wahrscheinlichkeit dafür berechnet, dass damit die Kombination bzw. der Kraftreserve-Typ erreicht wird, und am Ende wird durch die Anzahl möglicher Statuswert-Kombinationen geteilt. Wer es genau wissen möchte, kann sich gerne den Quellcode des Zuchtrechners anschauen, allerdings ist er momentan kaum kommentiert.
  • Kann der Zuchtrechner noch erweitert oder fürs PokéWiki angepasst werden?
    Diesbezüglich bin ich offen für Vorschläge und auch bereit, diese umzusetzen, insbesondere wenn derjenige auch ein mögliches Design für seinen Vorschlag nennt.
    Ich hatte mir basierend auf den anderen weiter oben verlinkten anderen Rechnern gedacht, eine Wesens-Auswahl oder Fähigkeiten-Auswahl zu den Kombinationen und Eltern hinzuzufügen oder den Wunsch nach einem Schillernden Pokémon angeben zu können, allerdings würde das einiges verkomplizieren, weil es dann relevant würde, welches Pokémon-Hauptspiel man nutzt und ob die Eltern männlich, weiblich, von unbekanntem Geschlecht oder ein Ditto sind. Außerdem sind dies meiner Meinung nach keine Features, die unbedingt nötig sind, da es für einen Nutzer relativ einfach ist, die Wahrscheinlichkeiten für diese Fälle selbst nachzuschlagen und dann mit der vom Zuchtrechner angegebenen Wahrscheinlichkeit zu multiplizieren. Wenn jemandem hierfür aber eine gute Idee zur Umsetzung dieser Features einfällt, gerne her damit!
    Theoretisch kann man noch sehr viel mehr Funktionen zu einem Zuchtrechner hinzufügen: Man könnte eine Pokémon-Auswahl einbauen und dann z. B. testen, ob diese Pokémon überhaupt miteinander kompatibel sind und falls ja, welches Pokémon schlüpfen würde, man könnte die Attacken berechnen, die der Nachwuchs auf Level 1 beherrscht und noch einiges mehr. Das alles wäre aber dann schon mit recht großem Aufwand verbunden und würde meiner Meinung nach auch über das Ziel hinausschießen.


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

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

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

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

Ich hab nichts dagegen dem eine eigene Spezialseite zu geben, sofern die bekannten Bugs (also z. B. das mit den zwei Machtitems) vorher noch behoben werden. Ein Tool mit bekannten Fehlern anzubieten ist meiner Meinung nach nicht wirklich sinnvoll, wenn man theoretisch auch auf das ganze verzichten könnte. Meine zweite Bedingung - nämlich das Buoysel bereit sein muss, das Ding einzubinden und später dann zu warten - scheint zumindest teilweise gegeben zu sein. Sollte sich das ganze allerdings nicht mit dieser Codebase umsetzbar sein würde ich dafür plädieren nicht all zu grosse Aufwände darin zu investieren das ganze umzuschreiben - so wichtig scheint mir das dann doch nicht zu sein. --Mecanno-manMäh 16:06, 31. Okt. 2020 (CET)
Keine Ahnung welchen Nutzen das für das Wiki bieten soll. Wenn sich eine Mehrheit dafür ausspricht schließe ich mich da Mec an. * Ryuichi ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 17:50, 1. Nov. 2020 (CET)
Mir wurde das ganze ja bereits im Vorfeld präsentiert und wie dort kann ich auch hier nur noch mal sagen, dass ich da relativ neutral zu stehe. Inhaltlich habe ich davon absolut keine Ahnung und selber nutzen werde ich es vermutlich auch nicht, ich kann mir aber durchaus vorstellen, dass es irgendwen geben wird, dem das hilft oder für den es hilfreich ist. Von demher werde ich dem nicht im Weg stehen, glaube aber auch nicht, dass ich da in irgendeiner Form behilflich sein kann. -- RobbiRobb 18:25, 1. Nov. 2020 (CET)
So wie es aussieht, liegt die Entscheidung zur Umsetzung dann letztendlich bei Buoysel, weswegen ich mich freuen würde, wenn er sich hier auch noch meldet.
Den von Mecanno-man angesprochenen bekannten Fehler des Rechners bzw. den noch nicht eingebauten Fall, dass beide Eltern Machtitems tragen, würde ich im Falle der Umsetzung noch beheben, keine Sorge.
Und damit es hier nicht so aussieht, als gäbe es nur neutrale Stimmen zum Zuchtrechner, wollte ich noch erwähnen, dass sich auf dem Discord-Server (im Strategie-Kanal) noch ein paar Nutzer positiv zum Rechner geäußert haben. -- Lasagne (Diskussion) 22:02, 15. Nov. 2020 (CET)
Jetzt melde auch ich mich mal hierzu. Das wollte ich eigtl. schon früher, habs aber vergessen. Ich wäre auf jeden Fall Pro gestellt. Auch wie Mec finde ich aber, dass der eine bekannte Bug behoben werden sollte, bevor das ins LiveWiki kommt. Aber da hast du, lasagne, ja schon geschrieben, dass du das beheben würdest. Am Ende will ich noch meine Hilfe anbieten, sollte es zu einer Umsetzung kommen. Ich arbeite seit geraumer Zeit selbst an einer Spezialseite, die einem den Zuchteltern-Baum für ein Pokémon und eine Attacke ausgibt. Allerdings kommen mir immer wieder Sachen dazwischen, weshalb der Fortschritt da immer wieder zum Erliegen kommt. Dennoch habe ich aber schon einige Sachen hingekriegt, deren Umsetzung mit der eher bescheidenen Dokumentation von MediaWiki ziemlich zeitaufwendig sein können und könnte dir da helfen.--DeXter 22:43, 15. Nov. 2020 (CET)
Ich weis leider immer noch nicht welchen Nutzen dies für das Wiki haben soll. Auch auf Discord konnte ich nur von 4 Leuten lesen das dieses Tool eine gute Idee ist. Für mich geht da allerdings nicht hervor ob dieses Tool eine gute Idee ist oder ob es um die Implementierung ins Wiki geht. Allgemein finde ich die Resonanz im Wiki und Discord ziemlich dürftig für eine derartige Implementierung. Klar liegt es bei Buo es einzupflegen. Allerdings ist halt echt die Frage ob sich das lohnt wenn man alle „Fürsprachler“ zusammen nimmt (6 User). Bin ich skeptisch. Wie gesagt, ich stelle mich nicht gegen. Bis jetzt sehe ich nur keinen größeren Nutzen. ka.gif * Ryuichi ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 12:01, 16. Nov. 2020 (CET)
Den größten Nutzen, den ich in diesem Tool sehe, ist dass es besonders neuen Pokémonspielern, die gerne in die Cp-Szene einsteigen wollen diesen Einstieg zu erleichtern. Auch die Wahrscheinlichkeit für ein bestimmtes Ereignis finde ich gut, da man dort schnell einen Überblick bekommt, wie viel Zeit man aufwenden muss, um folgendes Pokémon zu züchten und außerdem die Chance hat mit verschiedenen Zuchteltern und Items eine möglichst effiziente Taktik zu finden. Da wir im Wiki bereits ein Strategie-Projekt haben und dieses Möglichkeiten aufzeigt Pokémon zu nutzen, ist es wohl keine schlechte Idee auch einen Zuchtrechner zu haben, der hilft die gewünschten Pokémon mit gewollten Werten zu erhalten. -- Mooni000 Pelipper-Post 19:10, 16. Nov. 2020 (CET)
Ich finde es sehr schwer darüber zu urteilen, ob ein derartiger Rechner genutzt werden würde. Dennoch bin ich der Meinung, dass wir uns mit einer solchen Spezialseite keine Probleme oder zusätzliche Arbeit einheimsen. Was ich damit sagen will? Lasagne stellt uns den kompletten Code dafür zur Verfügung, da muss nichts mehr groß erarbeitet werden, sondern es fehlt nur noch der Feinschliff. Keiner von uns muss einen solchen Rechner komplett neu schreiben oder ähnliches. Aus diesem Grund wäre ich dafür, eine solche Spezialseite anzulegen. Wenn sich die Mehrheit unschlüssig ist, ob diese Spezialseite überhaupt genutzt werden wird, kann man das Ganze doch auch testweise anlegen. Es ist ja kein großer Aufwand für Buo in regelmäßigen Abständen zu schauen, wie die Zugriffszahlen dort aussehen. Und wenn man in einem (halben) Jahr merkt, dass diese Seite kaum verwendet wird, nimmt man sie wieder offline. Das tut keinem weh und sollte doch auch niemanden Sorgen bereiten. Wenn es nach mir ginge, kann man also eine solche Spezialseite testweise anlegen und dann nochmals nach einer bestimmten Zeit schauen, ob es sich lohnt sie weiterzuführen oder eben nicht. ~ Taisuke Diskussion 09:39, 17. Nov. 2020 (CET)
Ich glaub den potentiellen Wartungsaufwand unterschätzt du hier leicht, Tai: Der Code wird von Lasagne zur Verfügung gestellt - heisst aber nicht, dass uns Lasagne den Code jedes mal updatet wenn etwas am Zuchtsystem geändert wird. Dann müsste man entweder vermerken, dass der Rechner veraltet ist, oder ihn updaten (wobei zweiteres zu bevorzugen ist). Ebenfalls muss die Extension mit neueren Versionen von MediaWiki kompatibel sein, und sollten irgendwelche Javascript-Sachen dadrin deprecatet werden müssen die auch geupdatet werden. Deshalb ja auch meine Bedingung das Buo bereit sein muss sich da drum zu kümmern. --Mecanno-manMäh 13:35, 18. Nov. 2020 (CET)

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

Ja, vielleicht unterschätze ich den langfristigen Wartungsaufwand eines solchen Rechners. Aber für eine von mir angedachte Testphase würde ich nicht damit rechnen, dass innerhalb des nächsten halben Jahres ein neues Hauptspiel erscheint, was das Zucht-System (grundlegend) verändern wird. Daher mein Gedankengang, dass wir vorerst eher weniger Arbeit damit haben. Dass meine Idee totaler Humbug sein soll, erschließt sich mir nicht. Die Argumentation habe ich beispielsweise noch nie im Vorfeld einer Seitenlöschung gesehen. Wenn das wirklich die gängige Meinung wäre, dann haben wir all die Jahre – vor allem bei kontrovers diskutierten Artikeln – falsch gehandelt, da wir z. B. Galerie-Seiten trotz spürbarem Benutzer-Gegenwind (und kritischen Nachfragen von Seitenbesuchern im Nachhinein) gelöscht haben.
Als Laie in diesem Themenfeld möchte ich darüber jetzt aber auch keine neue Diskussion lostreten, daher schweige ich fortan und überlasse euch fachkundigen Leuten guten Gewissens die Entscheidung. smile2.gif ~ Taisuke Diskussion 08:55, 27. Nov. 2020 (CET)

Der Punkt wurde im Chattreffen vom 06.03.2021 besprochen. Nach Betrachtung der Anzahl der User die einen solchen Rechner als notwendig betrachten sowie den Wartungsaufwand bei Veränderungen mit zukünftigen Spielen wurde sich im einvernehmen mit Buoysel darauf geeinigt das eine Implementation eines derartigen Tools nicht notwendig ist und die Informationen wie bisher im Wiki aufbereitet für unsere Zwecke passen. * Ryuichi ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 10:49, 7. Mär. 2021 (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. --Mecanno-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. --Mecanno-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" --Mecanno-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 ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 12:36, 16. Aug. 2020 (CEST)
Behandelt die Abstimmung überhaupt die Vorlage:Sprites? So wie ich das verstehe ging es doch nur um die IDs, also namenr, nrname, id2typ etc. --Mecanno-manMäh 12:41, 16. Aug. 2020 (CEST)

Laut meinem Protokoll vom Chattreffen vom 06.03.2021 hatte Robbi angemerkt das nun die Herrscher Inexistent sind und es gab hier wohl noch offenen Diskussionsbedarf!? Der Punkt wurde dann geschoben aufgrund kurzfristiger Abwesenheit des ein oder anderen und ist dann im Chattreffen wohl etwas untergegangen. Bin mir daher über seine Archivierung im Unklaren. @Robbi kannst du es bitte hier noch einmal darlegen? Danke. Gruß * Ryuichi ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 10:51, 7. Mär. 2021 (CET)

Ich hatte noch mal geschaut und so wie es aussieht, habe ich die vorrübergehend unbenutzten Herrscher-Sprites wieder eingebunden, mit dem Ergebnis, dass ich damit gegen die Entscheidung der Abstimmung gehandelt habe. Ich denke allerdings, dass wir uns alle einig sein sollten, dass es Schwachsinn ist, die Sprites zu entfernen und so zu tun, als gäbe es sie nicht, wenn sie ziemlich offensichtlich aus den Spieledaten stammen und dementsprechend auch in den Spielen einsehbar sind. Bin mir daher etwas im Unklaren, wie genau wir hier weiter vorgehen wollen. -- RobbiRobb 16:42, 7. Mär. 2021 (CET)
Das so ein Fall wo sich lediglich der Sprite von allem anderen in der Größe Unterscheidet... sehe da die Problematik zwischen Abstimmung und Informationsvernichtung... wenn das Tai für Tai so in Ordnung ist und es sonst nichts weiteres dazu gibt können wir den Punkt auch ins Archiv schieben... Gruß * Ryuichi ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 16:51, 7. Mär. 2021 (CET)

Parameter für Königsformen in Pokémon-Legenden: Arceus

Mit dem Erscheinen von Pokémon Legenden Arceus sind wieder neue Pokémonformen eingeführt und es geht wieder darum, ob sie einen eigenen Parameter bekommen. Königsformen werden momentan als Formen mit einem eigenen Parameter gelistet, allerdings denke ich, dass sie doch zu ähnlich zu den normalen Pokémon sind, als dass sie einen eigenen Parameter bräuchten. Die einzigen Punkte in denen sie sich unterscheiden sind Größe, Gewicht und Sprites. Da aber alles Andere identisch ist und die Könige nicht vom Spieler erhältlich sind, sehe ich eigentlich keinen Grund ihnen einen eigenen Parameter zu geben, wenn Herrscher-Pokémon auch nicht separat gelistet werden. Des Weiteren sollte auch beachtet werden in welchen Artikeln die Parameter für die Königspokémon würden, denn das wäre hauptsächlich bei den Orten und Attacken. Da ich sowieso plane die Königspokémon aus den Learnset-Tabellen zu streichen, würden sie letztenendes nur bei den Orten verwendet werden. Die Frage wäre dann halt was man mit den Sprites machen würde und wo die liegen sollten. Ich würde deshalb gerne noch ein paar mehr Meinungen hören. -- Mooni000 Pelipper-Post 11:26, 2. Feb. 2022 (CET)

So wie ich es Verstehe gibt es wohl eigenständige Learntabels (auch wenn dies ggf. ident sind). Die Formen werden in den Dumps separat gelistet, auch unterscheiden sich die Formen in Optik, Größe und Gewicht. Für mich wären Sie also gleichzusetzten mit anderen Formen die wir aufgelistet haben. Ich bin der Meinung die Streichung der Form kann schneller erfolgen wie sie ggf. Nachträglich wieder überall hinzuzufügen. Ich erwarte z.B. in nächster Zeit ein Update für HOME was PLA und SDLP kompatibel macht. Dann sieht man es z.B. genauer. Auch kann ich mir sehr gut Vorstellen das Sie in einem Anime oder Manga besonders hervorgehoben werden könnten. Ja derzeit viel Konjunktiv. Nur wie gesagt ich denke es ist sinnvoller die Daten aufgrund der derzeitigen Faktenlage gesplittet zu betrachten bis wir da weitere Informationen haben. Gruß * Ryuichi ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 11:49, 2. Feb. 2022 (CET)
Ausbinden aber erstmal als Option lassen, sie wieder zu verwenden, scheint mir ebenfalls am sinnvollsten. Grundsätzlich haben wir ja eigentlich Zeit das zu entscheiden bis wir die nächsten Formen von den Pokémon mit Königsformen kriegen - also wahrscheinlich mind. bis zum nächsten Hauptspiel. Würde sagen nichts überstürzen. --Mecanno-manMäh 22:13, 3. Feb. 2022 (CET)

Der Punkt wurde im Chattreffen vom 09.04.2021 besprochen: Wenn es Gründe für IDs (vorhandene Sprites, usw.) gibt, dann können die Zukünftig einfach hinzugefügt werden, es benötigt nicht immer eine zusätzliche Rücksprache. Wichtig ist die IDs anschließend auch auf der entsprechenden Hilfeseite zu hinterlegen. Der Punkt gilt damit als Abgeschlossen und kann ins Archiv * Ryuichi ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 13:37, 10. Apr. 2022 (CEST)

Event-Screenshots der Schwert und Schild-Spiele

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

Seit StSd ist mir keine Lösung eingefallen. Wie aber schon auf Discord geschrieben. Die Home Screenshots sind bereits ewig lang da können auch 5 Screenshots zusammengestellt für StSd rein, macht so keinen Unterschied ka.gif * Ryuichi ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 23:45, 14. Nov. 2020 (CET)
Nach Vorstellung und Verfeinerung eines Konzeptes auf Discord hat sich dieser Themenpunkt erledigt. Die Bilder für Eventpokémon aus Schwert und Schild werden aus dem Allgemein-Bildschirm, dem Werte-Bildschirm und dem Attackenbildschirm bestehen. GrollenKette951 04:38, 30. Nov. 2020 (CET)
Abgerufen von „https://www.pokewiki.de/index.php?title=PokéWiki:Allgemeine_Diskussionsseite/Archiv_2020&oldid=2698545“