PokéWiki:Allgemeine Diskussionsseite

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

+

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

Gestaltung der Stellenanzeigen/Ausschreibungen

→ vorrausgegangene Abstimmung

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Abstimmung: Design der Stellenanzeigen-Box auf der Hauptseite

Abstimmung beendet. Variante 3 wird umgesetzt

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

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

Runde 1

Variante 1: Wds-Box wird verändert

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

Variante 2: XdW-Box wird verändert

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

Variante 3: Aktuelles wird verändert - Version 1

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

Variante 4: Aktuelles wird verändert - Version 2

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

Enthaltung

Kommentare

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

Runde 2

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

Variante 3: Aktuelles wird verändert - Version 1

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

Variante 4: Aktuelles wird verändert - Version 2

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

Enthaltung

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

Kommentare

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

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

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

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

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

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

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

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

Typenicons und wie wir entscheiden, welche wir nutzen.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Die DLCs

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Zentrale Hinterlegung von Trainerdaten

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

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

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

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

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

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

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

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

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

Sind weitere Pokémon-Formen als Parameter notwendig?

Hallo zusammen!

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

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

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

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

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

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

Benötigt einen Parameter:

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

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

(C): 744a (Wuffels mit Tempomacher)

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

Benötigt keinen Parameter:

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

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

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

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

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

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

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

(L): Lila Kecleon (nur in PMD)

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

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

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

(P): Volly (nur im Manga)

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

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

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

Keine eindeutige Entscheidung:

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

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

Nachträglich hinzugefügt:

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

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

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

Abstimmung

Abstimmung abgeschlossen

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

Legende:

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

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

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

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

Kommentare

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Umsetzung

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

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

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

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

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

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

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

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

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

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

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

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

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

Typen-Icons

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

Abstimmung

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

Offizielle Icons von pokemon.com (official)

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

Icons aus den Spielen der 7. Generation (gen7)

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

Icons aus den Spielen der 8. Generation (gen8)

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

Kommentare

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

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

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

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

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

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

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

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

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

Umgestaltung der Rechtesruktur

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Mal ein paar Anmerkungen zu den Diskussionsbeiträgen.

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

– Feblue

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

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

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

– Feblue

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

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

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

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

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

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