PokéWiki:Allgemeine Diskussionsseite/Archiv 2018

Diese Seite ist das abgeschlossene Archiv der Allgemeinen Diskussionsseite.

Bitte editiere hier nichts mehr.

Für Kommentare bitte die aktuelle Seite verwenden.

Fehler bei "Ebene von Poni"

Bei der Seite Ebene_von_Poni unter den Pokemon gibt es einen kleinen Fehler. Laut momentanen Stand, soll es in USUM in den raschelnden Büschen 50% Lilminip oder Waumboll geben, 30% Scyther und 30% Chansey was instesamt auf 110% kommt (Der vorstehende nicht signierte Beitrag stammt von: Dirakia • Diskussion • Beiträge • Sperren)

Hallo Dirakia, danke für den Hinweis. Chaneira hat hier nur 20%. Habe es bereits korrigiert. Derartige Fehler kannst du auch gerne direkt auf der Diskussionseite des Artikels melden. Zusätzlich möchte ich dich bitten deine Diskussionsbeiträge zukünftig zu signieren. Dies machst du indem du am Ende deines Beitrages mit vier Tilden (~~~~) abschließt. Gruß * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 20:03, 9. Jan. 2018 (CET)

[Abstimmung] Anleitungen zum Klonen/Bugnutzen/Glitchen

Abstimmung beendet: Anleitungen zum Klonen/Bugnutzen/Glitchen sind weiterhin im Wiki erwünscht

Wie im gestrigen Chattreffen angesprochen und zu Teilen bereits diskutiert wäre das Thema dieser Abstimmung explizite Anleitungen zum Ausnutzen von Fehlern in Spielen. Zur Einordnung: Es wurde beschlossen, dass solche Dinge wie Cheaten (Nutzung externer Programme/Module) im Wiki nicht erwähnt werden sollen, jedoch Fehler in Spielen sollen zumindest auf dafür spezifischen Seiten Erwähnung finden (sprich: Wir haben einen Artikel Mew-Glitch, jedoch wird bei Mews Fundorten nicht Glitch stehen). Als Teilproblem entstand während der Diskussion jedoch der Punkt, wie genau solche Fehler beschrieben werden sollen, konkret, ob beschrieben werden soll, wie der Fehler ausgenutzt werden kann. Als Beispiel kann sehr gut das Klonen genommen werden: Der Artikel selber beschreibt allgemein, was Klonen ist, in welchen Spielen es auftritt und eventuell zumindest die groben technischen Hintergründe. Die Frage wäre hierbei dann, ob eine Anleitung pro Spiel, wie sie aktuell bspw für Smaragd existiert, so genau beschrieben werden sollen. Daher gibt es drei Möglichkeiten: Komplett raus, Externe Anleitungen verlinken oder ins Wiki. Bei Option 3 liegt die genaue Umsetzung anschließend bei Korvel1, gerade ob einzelne Artikel entstehen oder alles in den Hauptartikel kommt oder sogar was ganz anderes. Die Abstimmung läuft bis zum 28. Januar 2018 23:59 Uhr, stimmberechtigt sind alle Stimmberechtigten. Jones ^Albtraum? 22:41, 14. Jan. 2018 (CET)

Option 1: Raus

1. Brauchen wa nicht Jones ^Albtraum? 22:41, 14. Jan. 2018 (CET)
2. Zwar gibt es den Anspruch der Vollständigkeit, aber hier sollte man, aus ideellen Gründen, eine Ausnahme machen. Anleitungen sollten sich auf keinen Fall finden. Maxmiran 12:22, 15. Jan. 2018 (CET)
3. --Mecanno-man^Mäh 13:29, 15. Jan. 2018 (CET)
4. Die Existenz von Bugs und ähnlichem zu entfernen halte ich für falsch, zum Glück steht das aber auch nicht zur Diskussion ^^ Eine erklärung oder gar eine Anleitung, wie man das ausnutzen kann sehe ich allerdings kritisch und glaube, dass es besser wäre, sie aus dem Wiki zu entfernen. -- RobbiRobb 13:30, 15. Jan. 2018 (CET)
5. Ich schließe mich da Maxmiran und Robbi an. Auf die Existenz solcher Möglichkeiten würde ich hinweisen und grobe technische Hintergründe liefern, aber keine Anleitung liefern "So kann ich der 4. Gen Darkrai fangen, ohne irgendwelche Event-Tickets zu haben". (Der vorstehende signierte Beitrag stammt von: Heiteira • Diskussion • Beiträge) 16:23, 15. Jan. 2018 (CET)
6. Kann weg, Glitchen ist doch auch nur Cheaten auf nem andern Weg Esteror (Diskussion) 18:38, 15. Jan. 2018 (CET)
7. Bugs und Spielfehler sollten erwähnt werden, allerdings nicht in der Form, dass Anleitungen zum Ausnutzen dieses Spielfehlers gegeben werden. Also quasi dasselbe, das auch meine Vorredner gesagt haben.--★☆★ Pk-fan 20:07, 16. Jan. 2018 (CET)
8. ~ Taisuke ^Diskussion 08:21, 17. Jan. 2018 (CET)

Option 2: Extern verlinkt

Option 3: Ins Wiki

1. Bevorzuge hier doch aus gründen der Vollständigkeit eine Hinterlegung im Wiki. Über die Ausführlichkeit lässt sich Streiten. Ich kann auch damit leben wenn sie im Wiki nur kurz angerissen werden und die Anleitung Extern verlinkt wird. Jedoch sehe ich komplettes Entfernen möglicher Cheats z.B. Klonen bei Smaragd als Informationsverlust. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 12:55, 15. Jan. 2018 (CET)
2. Ich bin auch dafür, dass uns diese Artikel erhalten bleiben. Spielfehler gehören zum Spiel. Eine Seite, die sich dazu verschrieben, hat so vollständig wie möglich Wissen über eine Reihe von Spielen zusammenzutragen ist geradezu dazu verpflichtet, solche Fehler in ihr Kompendium aufzunehmen. Dass diese Fehler ausgenutzt werden können, ist die logische Konsequenz der Existenz dieser Fehler, erst durch diesen Umstand wurden und werden sie meist erst entdeckt und bekannt. Anleitungen zur „Erfahrbarkeit“ dieser Fehler bereit zu stellen, ist somit ein nicht unwichtiger Beitrag, dem Nutzer die Möglichkeit zu geben, sein Spiel in jeder Form zu erleben. Sind diese Anleitungen nach dem aktuellen Kenntnisstand die sichersten und wird auf ihre Fehler-Natur und mögliche negative Konsequenzen hingewiesen, sehe ich keinen Grund diese aus unserem Wiki zu verbannen. Mit den Erklärungen und Anleitungen zu diesen spiel-internen Fehlern generieren wir nicht nur Nutzer, die diese ausnutzen, sondern klären auch diejenigen auf, die ihnen andernfalls aufgesessen wären. Externe Programme und Module sollten jedoch, wie bereits erwähnt und beschlossen, aus unserem Wiki gelöscht werden, denn sie sind nicht Teil der offiziellen Software. Ich halte es für die Vollständigkeit des PokéWiki also unabdingbar, dass uns diese Seiten erhalten bleiben. -MfG, Kenaz-Hagalaz ^Disku 13:27, 15. Jan. 2018 (CET)
3. Gründe stehen bereits oben. Sollte von mir nicht mehr weiter erläutert werden, finde ich. Jasuanti ^Bzz 14:57, 15. Jan. 2018 (CET)
4. Was meint ihr, wie ich aufs Wiki gestoßen bin (u.a.)? Fehler ausnutzen, gehört halt auch dazu :D --Klein, aber fein. Killuu https://i.imgur.com/Sne7Tvh.png 17:23, 15. Jan. 2018 (CET)
5. Schließe mich Kenaz & co. an. https://poketrainer-warren.de/PokeWiki/User/U1.png SpielefreakJ https://poketrainer-warren.de/PokeWiki/User/U2.png 17:56, 15. Jan. 2018 (CET)
6. Um das Wiki möglichst vollständig zu halten, sollte auch sowas darin stehen. Friedrich on ice^❄ 18:00, 15. Jan. 2018 (CET)
7. Ich sage nur eins: Glich und Bug gehört in Wiki dazu und es bleibt auch! AAWiki ^Diskussion 20:06, 15. Jan. 2018 (CET)
8. Ich schließe mich prinzipiell dem an, allerdings frage ich mich nach dem Sinn einer Glitchstadt einen Städteartikel zu geben statt eines Artikels über den Glitch(→Sunny Town (Glitch)). Das Isso 08/15 ^Konter 14:59, 16. Jan. 2018 (CET)
9. Gut Dung will Weile haben MattiBob ^Diskussion 21:06, 18. Jan. 2018 (CET)
10. Hier bin ich tatsächlich etwas zwiegespalten, allerdings vor allem deswegen, weil beide Aussagen so endgültig klingen. Meiner Meinung nach können wir auf Anleitungen verzichten, wenn sie nur der Anleitung willens im Wiki ist, sprich, es werden keine Hintergründe erklärt, warum der Glitch auftritt und wie es dazu kommt, dass z. B. ein Pokémon geklont wird. Eine Erklärung, wie es zu einem Glitch kommt, hat allerdings Platz in einem Wiki, wird aber den wenigsten ohne Beispiel verständlich erscheinen, die Anleitung kommt also automatisch dazu, wenn der Leser sich ein wenig mit dem Artikel beschäftigt. Das genügt dann aber auch allgemein für ein Spiel. Dazu gehören auch deutliche Hinweise auf die Gefahren, die es bei der Ausnutzung von Glitches geben kann. Bei puren Anleitungen fällt sowas gerne unter den Tisch, wenn unvorsichtige Benutzer einfach nur die Vorgehensweise wissen wollen. Eine Erklärung zu Bugs und Glitches ganz wegzulassen, nur weil man sie ausnutzen könnte, ist (und ich hoffe, da sind wir uns alle einig) jedenfalls Unsinn, wir sind hier, um alles verfügbare Wissen zu sammeln und sollten uns insofern nicht selbst zensieren. Also ein verhaltenes Ja zu Anleitungen, aber nicht so wie hier, sondern nur als Teil einer neutralen Erklärung. -- Korvel1 11:34, 20. Jan. 2018 (CET)
11. Inzwischen wurden ja alle Argumente bereits erwähnt. Auch ich schließe mich der "Ins Wiki"-Gruppe an. Der primäre Faktor ist hierbei die Vollständigkeit. Wie Kenaz es bereits so schön gesagt hat, gehören Spielfehler zum Spiel. Bei illegalen Dingen, wie Softwares von Drittanbietern ist es klar, dass das hier nicht reingehört, jedoch sollten direkte Inhalte des Spiels in einem Wiki nicht vernachlässigt werden, nur weil sie eventuell vom Hersteller nicht so gewollt waren. Ist in manchen Situationen sicher auch gut, bestimme Bugs zu kennen, um sich vor Fehlern, die die "Gesundheit" des Spielstands beeinträchtigen können, zu schützen. Wäre doch außerdem auch schade, Nutzer wegen Fehlen dieser spielinterner Informationen zu verlieren. Yinni ^✧* 11:55, 20. Jan. 2018 (CET)
12. Meiner Meinung nach können fast alle Anleitungen problemlos im Wiki stehen, jedoch sehe ich Bugs und Glitches, die Online-Features betreffen, sehr kritisch. Beispielsweise das hier sollte meiner Meinung, wenn überhaupt, im Wiki stehen, nachdem es behoben wurde. Ansonsten würde man eher Leute dazu bringen, das Spiel von sich und deren Kampfgegnern zum Abstürzen zu bringen, was meiner Meinung nach nicht der Anspruch des Wikis sein sollte. Anleitungen zu Glitches, die nur offline wirken oder bereits behoben sind, somit also keinesfalls Einfluss auf Spiele von Nutzern, die den Glitch nicht aktiv ausführen, und somit das Risiko eingehen, hat. Luca12379 ^Diskussion 14:47, 20. Jan. 2018 (CET)
13. Wieso sollte im Wiki etwas erwähnt werden, ohne es zu erklären? Stellt euch vor, jemand kommt gezielt oder durch Zufall auf die Wiki und liest etwas über einen Glitch; nun möchte dieser den Glitch selber ausführen, aber weiss nicht wie er das tun soll. Was tut er als nächstes? Natürlich geht er aus dem Wiki weg und findet eine Anleitung auf Youtube oder einer andere Pokémon-Seite. Genau dieses Szenario sollte aber nicht das Ziel sein, denn eine Wiki sollte einen klüger machen und nicht einen dazu bewegen anderswo zu suchen. https://i.imgur.com/6WoeBnL.pnghttps://i.imgur.com/jqdtwu0.png 14:45, 22. Jan. 2018 (CET)
14. Ich würde mir zwar schon in jedem einzelnen Fall einer Glitchanleitung genau überlegen, ob die Anleitung relevant genug für das Wiki ist und von der Form her den enzyklopädischen Anforderungen entspricht, aber ich finde nicht, dass man Anleitungen prinzipiell als unerwünscht ansehen sollte. – shadowtweaker 20:53, 22. Jan. 2018 (CET)
15. In welcher Form man es tut, muss man sich noch überlegen. Aber nach 1-2 Nächten Schlaf finde ich, dass man es doch nicht ganz unerwähnt lassen sollte. -- Liebe Grüße, Moltres 20:56, 22. Jan. 2018 (CET)
16. Anleitungen zu Bugs/Glitches finde ich in diesem Zusammenhang verständlich, aber nicht unbedingt als korrekt gewählten Begriff. Ich empfinde das ganze sollte viel mehr wie eine Dokumentation sein, wie die einzelnen Schritte einer chemischen Reaktion, solange es nicht zu spezifisch wird. Ich denke, Allgemeines sollte ins Wiki, aber Einzelschritte zu spezifischen Ergebnissen hunderten sollten höchstens verlinkt werden. Wenn wir den im Einleitungssatz erwähnten Mew-Glitch ansehen, sehe ich was viele unter diesen Anleitungen meinen. Schon alleine der Titel des Artikels macht klar, und vor Allem all die Varianten und Möglichkeiten, dass es nicht wirklich um den Glitch selbst geht, sondern um das Ziel des Glitch: Wie man das mysteriöse Mew bekommt. So würde ich es nicht haben wollen, und ich denke unsere Dissidenten so etwas verhindern wollen. Aber der Artikel bemüht sich auch die Hintergründe des Glitch zu erklären. Im Kontrast dazu steht der Long-Length-Trainer-Artikel. Er behandelt dasselbe Prinzip, und ist viel allgemeiner gehalten. Ihm mangelt es jedoch an Hintergründen und Erklärungen, bis auf die Index-Tabelle, die wieder wie ein Teil als Anleitung für den Glitch aussieht, aber eigentlich nur ein Speichermuster ist, das man woanders im Wiki wie auf Bulbapedia unterbringen könnte und im Text als Erklärung dessen wieso der Glitch passiert, verlinken könnte. Der Mew-Glitch Artikel tut genau das - dafür auf Bulbapedia verlinken (was auch eigentlich heißen sollte, dass wir einen eigenen Artikel dazu anlegen sollten). Man sollte wie bereits durch die Vorlagen erwünscht beide Artikel vereinigen und sich von der Fokussierung auf Mew entfernen, damit der Glitch an sich wieder im Mittelpunkt steht. Mew selbst sollte hier höchstens als Beispiel einer Erklärung der einzelnen Schritte auftauchen, ansonsten das gehört genaue Vorgehen dafür extern verlinkt. Beispielsweise sieht man das gut umgesetzt im Tweaken-Artikel. Der Artikel zeigt einem die generellen Schritte wie das Tweaken gemacht wird, und erklärt Konditionen, Ursachen, und Folgen. Die beliebtesten Nutzen für das Tweaken werden nur nebensächtlich erwähnt, und anstatt selbst Auskunft über die Vorgehensweise dafür zu geben, werden stattdessen entsprechende Videos dazu verlinkt. Ich würde sogar noch ein Bild des oft genutzten Jubelstadt-Zentrums mit Raster als Beispiel erlauben. Natürlich bekommt nicht jeder Glitch seinen eigenen Artikel oder ist erklärbar, und findet oft nur einen Platz auf der Sammelseite der Bugs seiner Generation, aber diese haben auch oft nicht das Problem, dass sie nur eine spezifische Manipulation statt nur das Allgemeine erklären. Also nochmal kurz gesagt: Allgemeine Ausführung Hui, auf etwas bestimmtes abzielende Ausführung Pfui - höchstens als Beispiel, ansonsten verlinkt. — mfg ^Snack_hound 10:28, 23. Jan. 2018 (CET)
17. Ich finde auch, dass Bugs und Glitches erwähnt werden sollten. Bei Anleitungen denke ich, dass wir es bei jedem einzeln entscheiden sollten, wie detailliert sie sein sollten. -- Michelle ^Diskussion 03:10, 28. Jan. 2018 (CET)
18. Es wurde schon alles erwähnt. Ich bin für die Erwähnung und Erklärung, man muss es aber natürlich nicht glorifizieren, also allgemein halten. - - "I'm gonna swing from the chandelier" GoPika ^Disku 13:04, 28. Jan. 2018 (CET)

Kommentare

Da MediaWiki es nicht hinbekommt, wenn ein Artikel mit ner Überschrift endet und RobbiRobb eh einen Ping will: Buoysel, Chrizz, GoPika, Impoleon xy, Jones, Kenaz-Hagalaz, Killuu, Korvel1, Loxi-kun, Luca12379, MattiBob, Matze, Maxmiran, Mecanno-man, Moltres, Pk-fan, RobbiRobb, Ryuichi, shadowtweaker, ShortyBuzz, Snackhound, Taisuke Jones ^Albtraum? 22:45, 14. Jan. 2018 (CET)

Ping an die SBs: @Buoysel, Chrizz, GoPika, Impoleon xy, Jones, Kenaz-Hagalaz, Killuu, Korvel1, Loxi-kun, Luca12379, MattiBob, Matze, Maxmiran, Mecanno-man, Moltres, Pk-fan, RobbiRobb, Ryuichi, shadowtweaker, ShortyBuzz, Snackhound, Taisuke, AAWiki, Akuroma, Arrow, CLina, Der Sternendiamantritter, Digimon, Esteror, Flonc, FloRyan, Friedrich on ice, Heiteira, Hydrokyu, Isso08-15, Jasuanti, Kappador, Kypo, Max98, Michelle, PinBallPong, Schiggy91, Skelabra2509, SpielefreakJ, SwowoJonny, Yinni: --Mecanno-man^Mäh 14:51, 15. Jan. 2018 (CET)

Ich bin mir sicher, dass sich viele unter der schwere der Bugs, deren Anwendungsweg sich ins Wiki findet, etwas anderes vorstellen. Ich würde gerne primär die, die die Option "Raus" gewählt haben fragen, ob sie bedingungslos alle Erklärunsgschritte zum Ausführen sämtlicher Bugs gerne entfernt hätten, oder irgendwo einen Strich ziehen wollen. Eventuell nur Bugs die einen Vorteil verschaffen? Die Umstände des Auslösens und Effekte von etwas wie bei Freier Fall würde ich unter keinen Umständen verlieren wollen. — mfg ^Snack_hound 15:20, 15. Jan. 2018 (CET)

Ich möchte mich da Snack gerne anschließen. Die Beschreibung von Fehlern, Bugs, Glitches etc sollte schon im Wiki vorhanden sein, mein "Raus" bezieht sich explizit nur auf die Beschreibung oder Anleitung dessen, wie man das zu seinem Vorteil ausnutzen kann. Auch einen Verweis auf externe Seiten, die das beschreiben, finde ich unangebracht, da dann die Message dieselbe ist, nämlich dass wir das unterstützen würden, dann kann man es auch gleich ins Wiki aufnehmen. Beschreibungen gehören aber dazu. Maxmiran 15:51, 15. Jan. 2018 (CET)

Stimmt! Ich hatte ganz vergessen, dass diese ganzen Glitch-Anleitungen auch ein großer Werbefaktor für unser Wiki sind und waren. Das sollte man nie vergessen! Alle Leute, die ich im echten Leben kenne und Pokémon gespielt haben, haben das PokéWiki auf der Suche nach solchen Anleitungen entdeckt. Diese Seiten geben uns also zusätzliche Klicks und neue Nutzer. -MfG, Kenaz-Hagalaz ^Disku 17:40, 15. Jan. 2018 (CET)

Sowas wie Freier Fall ist imo ein Paradebeispiel für das Erklären wann er auftritt. Ähnlich sollte z. B. für das Clonen erklärt sein das das bei einem Verbindungsverlust auftreten kann. --Mecanno-man^Mäh 19:03, 15. Jan. 2018 (CET)

Esteror, oh, pass lieber auf.
Glitches ≠ Cheats.
Während Glitche vom Spiel aus eigene Fehler im Code sind, sind Cheats betrüge, werden durch andere hervor gerufen und können ohne dritt-Programme so an sich nicht vorkommen. https://poketrainer-warren.de/PokeWiki/User/U1.png SpielefreakJ https://poketrainer-warren.de/PokeWiki/User/U2.png 00:41, 16. Jan. 2018 (CET)

Es sei angemerkt, dass Anleitungen allgemein eigentlich in einer Enzyklopädie auch nichts zu suchen haben. -- Skelabra2509 (Diskussion | Beiträge) 21:39, 16. Jan. 2018 (CET)

Öhm... Komplettlösungen?... Strategie? ... Wo ist die Grenze? Gut Dung will Weile haben MattiBob ^Diskussion 21:06, 18. Jan. 2018 (CET)

Ich hab jetzt nicht alles durchgelesen und entschuldige mich im Voraus für eventuelle Doppelungen mit den Aussagen anderer User - aber ich bin der Meinung, dass Glitches und dergleichen möglichst ausführlich im Wiki beschrieben werden sollten. Die Ausführung von Glitches mag zwar moralisch fragwürdig sein, aber es ist nicht die Aufgabe des PokéWiki zu bestimmen, was moralisch vertretbar ist und was nicht, das sollte jeder Spieler für sich selbst entscheiden. Außerdem halte ich es für immens wichtig, auf die Risiken bestimmter Glitches hinzuweisen, da gibt es ja durchaus einige, mit denen man ganze Spielstände unwiderruflich ruinieren kann. Und irgendwie wäre es ganz schön blöd, wenn sich jemand seinen Spielstand totgeglitcht hat, weil im PokéWiki keine Infos darüber standen und der Spieler sich eine Anleitung mit ungesundem Halbwissen gegooglet hat. Das Risiko mit dem ungesunden Halbwissen dürfte hier dagegen kaum vorhanden sein, wird doch jeder Pups, den hier einer reinsetzt, von unseren Admins und Redakteuren auf seine Richtigkeit hin überprüft. -- Jaci 22:49, 27. Jan. 2018 (CET)

Anleitungen vs Erwähnungen (Begründungen)

Ryuichi, AAWiki, Korvel1, Yinni, Schiggy91: Ich möchte nochmal explizit darauf hinweisen, dass es bei dieser Abstimmung nicht darum geht, ob Bugs/Glitches erwähnt werden, sondern wie ausführlich. Um mal bei den obigen Beispielen zu bleiben: Der von Snack angesprochene Freie Fall wird wie Mec im Grunde schon schrieb ziemlich exakt so stehen bleiben, da es eine Beschreibung des Fehlers als solcher ist (Zugegeben gibt es hier Überschneidungen mit einer Anleitung, jedoch ist eine Beschreibung des Fehlers ansonsten auch nicht möglich). Somit wäre dies ein Beispiel, welches nicht von dieser Abstimmung betroffen wäre. Hierbei geht es eher um Fälle, wo eine Beschreibung der (technischen) Hintergründe möglich ist, ohne das es eine exakte Anleitung ist. Als Beispiel sei hier wieder das Klonen erwähnt. Unabhängig vom Ausgang dieser Abstimmung würde dort eine Erläuterung der Hintergründe drin stehen (Bspw. Da während des Speicherns verschiedene Operationen durchgeführt werden, welche nicht in einer Transaktion(wp Link) zusammengefasst werden, können durch gezieltes Softresetten Speicherstände entstehen, von denen ein Teil dem aktuellen Stand entsprechen, ein anderer Teil jedoch noch dem alten Spielstand. Beispielsweise kann durch das Resetten an geeigneter Stelle ein Pokémon, welches zuvor aus den PC-Boxen ins Team aufggenommen wurde, anschließend sowohl im Team, als auch in der Box befinden.). Bei der Option 3 würden anschließend zusätzlich Abschnitte für jedes Spiel folgen, in dem Klonen möglich ist, welche alle in der Form Gehe zu Punkt 1, mache dieses, gehe zu Punkt 3, mache jenes, resette, hoffe das nichts kaputt ist geschrieben sind. Sonstige Dinge im Artikel (Hinweis auf Datenverlust oder Erläuterungen, wie GameFreak probiert dem entgegenzuwirken oder wie man selber sowas probieren kann zu erkennen) bleiben ebenfalls gleich. Es geht hier also ausschließlich darum, ob wir solche Schritt für Schritt Anleitungen wollen. Die Begründung "Glitches und Bugs gehören zum Spiel" ist also etwas am Thema vorbei, da dies gar nicht zur Debatte steht.
Hinweis: Die obigen Beispiele dienen nur zu Demonstrationszwecken, sie erheben keinen Anspruch auf Vollständigkeit oder gar Richtigkeit und werden in dieser Form nicht in den Artikeln erscheinen; vergleichbare, korrekte Absätze jedoch schon. Jones ^Albtraum? 11:43, 21. Jan. 2018 (CET)

Ich gehe mal stark davon aus, dass sich die erwähnten Abstimmenden bereits ganz genau überlegt haben, was sie wählen und es keiner Belehrung bedarf. -MfG, Kenaz-Hagalaz ^Disku 13:21, 21. Jan. 2018 (CET)

Hey Jones, sorry für die verzögerte Antwort. Zu deiner Nachfrage. Für mich gehört sämtliches zu Glitches, Bugs, Cheatanleitungen sowie Tweaken in das PokéWiki. Für mich ist das PokéWiki eine Informationsquelle zu allen Sachen rund um das Thema Pokémon. Dies schließt an dieser Stelle auch Lücken im System ein, die durch diverse Sachen ausgelöst werden können. Einzige Voraussetzung ist aus meiner Sicht das wir nicht stumpf die Anleitung haben sondern dies in Kommentierter Form hinterlegt wird mit allen möglichen Problematiken. Und ja dies heißt, man kann es als Schritt-für-Schritt-Anleitung hinterlegen solange sie auch die Risiken aufzeigt. Was unstrittig ist, sind Cheats mit externer Hardware (ich will hier mal keine Namen Nennen) oder Software. Derartiges gehört nicht in das PokéWiki. Allerdings besteht aus meiner Sicht die Gefahr wenn wir die Anleitungen zu Cheats entfernen, massiv dezimieren, das die Frage aufkommt was als nächstes gestrichen/gekürzt werden soll. KL oder wie auch immer. Mag zwar jetzt abwegig klingen, allerdings haben wir einiges im Wiki was nicht enzyklopädisch ist und einfach vorhanden ist weil es von großem Interesse für die Community ist und Kenaz-Hagalaz wenn man sich die Kommentare der gepingten User ansieht dann finde ich hat die Nachfrage durchaus Berechtigung und keinen Belehrungscharakter . Gruß * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 07:47, 23. Jan. 2018 (CET)

Abstimmung: Design von Thumbnails und Galerien

Diese Abstimmung ist vorbei. Die meisten Stimmen erhielt Version drei, womit die Thumbnails und Galerie-Boxen im Wiki von nun an rund sind.

Alle möglichen Versionen

https://cdn.discordapp.com/attachments/247144261693210624/422863189059829767/unknown.png

Vor einiger Zeit hatte ich mal einige Versuche für das Design von Galerien auf dem Discord-Server vorgestellt und nach Meinungen gefragt, woraufhin wir einige neue mögliche Lösungen geschaffen haben. Neben dem aktuellen Zustand wäre es möglich, die Rahmen der Galerien blau zu färben oder die Ecken abzurunden, wobei auch eine Kombination aus diesen beiden Elementen möglich ist. Dabei geht das runde besonders mit den allgemein runden Infoboxen, während die farbliche Note zum einen frischer, auf der anderen Seite aber auch wesentlich auffälliger wirkt. Daneben würde diese Änderung auch gleich auf allgemeine Thumbnails ausgeweitet, damit hier die Einheitlichkeit gewahrt wird. Um das aber mal von meiner Liste streichen zu können, starte ich hier eine verbindliche Abstimmung, wie wir verfahren und welche Versionen ins Wiki übernommen wird. Diese geht bis zum 26.03.2018 um 23:59 Uhr, teilnehmen darf jeder stimmberechtige Benutzer. -- RobbiRobb 22:39, 12. Mär. 2018 (CET)

Nachtrag: Sollte Version 4 nicht die meisten Stimmen haben, werden diese auf Version 2 und 3 addiert, da diese zusammen schließlich Version 4 ergeben ^^ -- RobbiRobb 00:26, 13. Mär. 2018 (CET)

Version 1: Status quo

1. Ein wenig gegen den Flow, aber eckige Bilder in einer runden Box sehen aus meiner Sicht nicht immer gut aus. Wäre dennoch eher für rund als für blau, da die blauen Boxen in einigen Artikeln (Pokémon, Orte, Items) einen ziemlichen farblichen Stilbruch erzeugen können.--★☆★ Pk-fan 17:42, 17. Mär. 2018 (CET)

Version 2: Blau

1. Friedrich on ice^❄ 00:16, 18. Mär. 2018 (CET)

Version 3: Rund

1. Ich mag es dezent. Das Isso 08/15 ^Konter 23:34, 12. Mär. 2018 (CET)
2. --Mecanno-man^Mäh 00:00, 13. Mär. 2018 (CET)
3. --mfG Lombrero ^Dis 07:57, 13. Mär. 2018 (CET)
4. Maxmiran 11:34, 13. Mär. 2018 (CET)
5. — mfg ^Snack_hound 14:12, 13. Mär. 2018 (CET)
6. Buoysel 14:40, 13. Mär. 2018 (CET)
7. Michelle ^Diskussion 14:41, 13. Mär. 2018 (CET)
8. ~ Taisuke ^Diskussion 14:44, 13. Mär. 2018 (CET)
9. Eigentlich finde ich es aktuell durchaus ok, und die Thumbs passen auch ganz gut. Könntest du noch ein rundes Beispiel der Thumbs geben? Generell ist ja hier inzwischen alles rund (warum eigentlich?), sodass rund eher ins Gesamtbild passen würden. Mit Farbe fänd ich es aber zu aufdringlich. Lg --Vorsicht, heiß! Killuu https://i.imgur.com/wVf4WMM.png 14:57, 13. Mär. 2018 (CET)
10. SwowoJonny 18:48, 13. Mär. 2018 (CET)
11. - - "I'm gonna swing from the chandelier" GoPika ^Disku 19:29, 13. Mär. 2018 (CET)
12. Wenn man die Farbe nicht ändern kann, dann nur rund. Gut Dung will Weile haben MattiBob ^Diskussion 18:48, 15. Mär. 2018 (CET)
13. -- Liebe Grüße, Moltres 20:03, 15. Mär. 2018 (CET)
14. Freigeist^Diskussion 22:28, 15. Mär. 2018 (CET)
15. – shadowtweaker 08:34, 16. Mär. 2018 (CET)
16. -- Skelabra2509 (Diskussion | Beiträge) 17:07, 20. Mär. 2018 (CET)
17. Unbemerkbarer rand zum Typischen Wiki rundem. https://poketrainer-warren.de/PokeWiki/User/U1.png SpielefreakJ https://poketrainer-warren.de/PokeWiki/User/U2.png 22:45, 25. Mär. 2018 (CEST)
18. — Yinni ^✧* 23:17, 25. Mär. 2018 (CEST)

Version 4: Blau und Rund

1. Jones ^Albtraum? 22:47, 12. Mär. 2018 (CET)
2. (Der vorstehende signierte Beitrag stammt von: Heiteira • Diskussion • Beiträge) 22:51, 12. Mär. 2018 (CET)
3. ShortyBuzz 09:46, 13. Mär. 2018 (CET)
4. -- Luca12379 ^Diskussion 21:09, 13. Mär. 2018 (CET)
5. --×Impoleon xy× 21:32, 13. Mär. 2018 (CET)
6. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 08:13, 16. Mär. 2018 (CET)
7. Rund sieht meiner Meinung aus besser aus als eckig. Und es springt auch wegen dem Blau ins Auge, was mir persönlich ziemlich gut gefällt. Jasuanti ^Bzz 23:38, 17. Mär. 2018 (CET)
8. -- AAWiki ^Diskussion 13:12, 21. Mär. 2018 (CET)
9. -- RobbiRobb 01:43, 26. Mär. 2018 (CEST)
10. FloRyan ^Diskussion 21:51, 26. Mär. 2018 (CEST)

Kommentare

Bestünde auch die Möglichkeit, die Farbe den jeweiligen Typen anzupassen, so wie es die anderen Boxen auf den Pokémon-seiten machen? Ich fände es doch irgendwie komisch, wenn beispielsweise auf der Pikachu-Seite, auf der alles gelb ist, unten plötzlich alles blaugefärbt wäre. Oder ist der technische Aufwand zu groß? ShortyBuzz 09:46, 13. Mär. 2018 (CET)

@Killuu
Spoiler

https://cdn.discordapp.com/attachments/247123461225316352/406837838617903105/unknown.png

* Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 15:10, 13. Mär. 2018 (CET)

Zum einen: Spoiler

https://cdn.discordapp.com/attachments/247144261693210624/423132557303873557/unknown.png

Hier die aktuelle Datei, bei der auch das Innere des Thumbnails rund ist, das ist nämlich ebenfalls eingebaut, damit es einheitlich ist.

Abgesehen davon: @ShortyBuzz: So leid es mir auch tut, ich fürchte, dass es nicht möglich ist, die Farben irgendwie anzupassen, vermutlich kann man es doch irgendwie per javascript machen, davon hab ich aber keine Ahnung und mich damit auseinandersetzen möchte ich zurzeit auch nicht wirklich, abgesehen davon, dass es sich kaum wirklich lohnen würde. Natürlich wäre es aber möglich, global eine andere Farbe zu setzen, sofern das von der Mehrheit gewünscht ist. -- RobbiRobb 16:00, 13. Mär. 2018 (CET)

Spoiler

https://cdn.discordapp.com/attachments/256061895180550144/424705861206933504/unknown.png

Auf vielfachen Wunsch biete ich an dieser Stelle zusätzlich noch eine Version mit runden Bildern in den Galerien, da die Abstimmung aber bereits läuft möchte ich es nicht als zusätzliche Abstimmungsoption einfügen sondern einfach mal nach Meinungen fragen, wie man so dazu steht, insbesondere @Pk-fan, der sich ja besonders gegen eckige Bilder in runden Kästen ausgesprochen hat. Wäre das eine zusätzliche Option? Immerhin ist das innere von Thumbnails ebenfalls rund, damit ist das das einzige, was nicht rund wäre. -- RobbiRobb 00:12, 18. Mär. 2018 (CET)

1. würde dafür Stimmen –Yinni ^✧* 11:17, 18. Mär. 2018 (CET)
2. Ich würde auch dafür stimmen, wenn das zur Option steht -- Michelle ^Diskussion 11:48, 18. Mär. 2018 (CET)

Ich halte von der Idee nicht so viel, einerseits gefällt es mir optisch nicht besonders und das Eckige im Runden wäre mir auch nicht negativ aufgefallen. Andererseits werden dadurch Bilder beschnitten, wodurch man sich gegebenenfalls merkwürdige Optik einkauft, z. B. wenn ein Bild selbst einen eckigen Rahmen oder zumindest gradlinige Kanten hat, die dann bei den Rundungen ins Nichts verlaufen. Maxmiran 14:22, 18. Mär. 2018 (CET)

Aus meiner Sicht ist es keine Lösung die Bilder rund zu machen, ich würde dementsprechend in der aktuellen Umfrage nicht dafür stimmen. Auch wenn es nur ein kleiner Teil des Bildes ist, so schneidet man damit etwas von offiziellen Bildern ab, was ich irgendwie nicht so schön finde. Bin da vielleicht auch ein wenig zu pingelig, aber den Status quo finde ich immer noch besser. Und bitte quetscht jetzt keine weitere Option mehr in die Umfrage, sowas geht nie gut. Sobald die runde Version die Wahl gewonnen hat, einfach nochmal eine zeitlich kürzere Abstimmung dazu erstellen, ob die Bilder abgerundet werden sollen oder nicht.--★☆★ Pk-fan 03:05, 19. Mär. 2018 (CET)

Da diese grundlegende Abstimmung am morgigen Tag ihr Ende finden wird, pinge ich an dieser Stelle alle Benutzer an, die für diese Wahl stimmberechtigt sind, aber noch keine Stimme abgegeben haben. Da das Abstimmungsergebnis in sehr vielen Bereichen des PokéWikis zu einer (möglichen) Anpassung führen wird, wäre es schade, sich diese Wahlbeteiligung entgehen zu lassen. Noch habt ihr (Akuroma, Arrow, CLina, Der Sternendiamantritter, Digimon, Esteror, Flonc, FloRyan, Hydrokyu, Kenaz-Hagalaz, Korvel1, Loxi-kun, Matze, Max98, Pintauranimus, Pokénator, RobbiRobb, Schiggy91, SpielefreakJ und Yinni) etwas mehr als 24 Stunden für eure Stimmabgabe. ;) ~ Taisuke ^Diskussion 22:40, 25. Mär. 2018 (CEST)

Das Einzige was ich bisher sagen kann: auf keinen Fall blau, aus genau demselben Grund, den Pk angeführt hat... -MfG, Kenaz-Hagalaz ^Disku 17:58, 26. Mär. 2018 (CEST)

Überarbeitung der Firmen-Artikel

Ich hab mir gerade mal die Artikel angeguckt, die aus Vorlage:Firmen verlinkt werden und finde da muss mal was gemacht werden (ja, nicht nur da, aber irgendwo muss man ja mal anfangen). Da das ganze nach aktuellem Stand keinem Projekt zugeordnet ist (nein, das Spiele-Projekt kann nicht alles machen, auch wenn ich die Diskussion jetzt wieder anstoße), würde ich das ganze mal einfach hier besprechen wollen und dann im Laufe des Jahres da zu nem Ende kommen. Zum Start mal ein Überblick wie es aktuell ist: Kurze Einleitung, komplett unvollständige Liste aller entwickelten Spiele, Wikipedia-Link, wenns gut läuft noch nen Link zur Website der Firma, Vorlage, Ende. Das das nicht ansprechend ist muss ich denk ich keinem erklären. Was ich mir jetzt grob vorgestellt hätte als eine Art "Musterstruktur":

• Infobox: Damit das Logo nicht komplett lose da rum fliegt wäre eine Infobox ala Wikipedia (natürlich etwas aufgehübscht) nicht ganz schlecht: Logo, Mitarbeiter(?), Gründung, Website, Sitz. Rechtsform oä brauchen wir denk ich nicht.
• Kurze Einleitung (was hier genau rein sollte müsste man noch diskutieren)
• Kurze Geschichte (wann aus welcher Firma hervorgegangen oä)
• Bekannte Spielereihen (fehlt bisher komplett, zB bei Intelligent Systems die gesamte Fire-Emblem-Reihe)
• Verbindung zu Pokémon (welche Spiele entwickelt, an welchen mitgearbeitet etc)
• evtl Übersicht über die Verkaufsstärksten Spiele. Auf keinen Fall alle listen, das würde in einem Jahr wieder veraltet sein
• Weiteres?

Andere Vorschläge, weitere Ideen, evtl fehlende Firmen, sonst was gewünschtes in dem Bereich? Jones ^Albtraum? 10:39, 17. Mär. 2018 (CET)

Gefällt mir, klingt schon fast nach einem Konzept, dass man so umsetzen könnte ^^ Aber gibt es wirklich genug Inhalt, um sowas auch ansprechend zu gestalten? Bisher haben die Artikel bis auf zwei Sätze in der Einleitung keinen Text und fünf Ein-Satz-Abschnitte schreiben, nur um die Abschnitte zu haben ist definitiv auch nicht die richtige Herangehensweise an das ganze... -- RobbiRobb 16:29, 17. Mär. 2018 (CET)

Finde ich gut so. Ich denke aber, die aufgezählten Punkte für das Konzept reichen. Geht ja eher um eine kurze Vorstellung. -- Liebe Grüße, Moltres 16:57, 17. Mär. 2018 (CET)

Ich denke bei den meisten Firmen lässt sich deutlich mehr schreiben als aktuell der Fall. Guckt man bei (en) Wikipedia sieht man ja schon einiges mehr, da würde ich teilweise sogar eher weniger schreiben. Dazu sollen die Artikel ja auch nur grob nen Überblick liefern, was für ne Firma das ist und wie sie mit dem Pokémon-Franchise zu tun haben, bzw generell mit Nintendo.

Dazu noch nen Nachtrag: Abschnitte zu "Wichtigen Personen", wie aktuell bei Game Freak inc. würde ich streichen wollen. Die entsprechenden Personen werden sicherlich im Fließtext erwähnt, alles weitere sollte jedoch in Einzelartikeln (die in dem Fall ja auch alle haben) erläutert werden. Jones ^Albtraum? 17:09, 17. Mär. 2018 (CET)

Klingt gut --Mecanno-man^Mäh 17:14, 17. Mär. 2018 (CET)

Zunächst mal: Das hier soll ne Diskussion werden, kein "Hört sich gut an, hauptsache ich muss nicht mitmachen" :$ Zum zweiten: Ich hatte oben schon angerissen, formulier es aber gerne auch nochmal deutlicher: Welche Firmen qualifizieren sich überhaupt für einen Artikel? Ich habe jetzt mal random geguckt: Der Entwickler von Pokémon Card Game Asobikata DS hat keinen Artikel, Niantic als GO-Entwickler hat keinen, bei einigen Spielen steht TPCi als Entwickler, wo ich mir grad ziemlich unsicher bin, ob sie wirklich selber entwickeln, bei vielen Apps ist Creatures als Entwickler eingetragen, mit Intelligent Systems hat jedoch der Entwickler von Puzzle League und Puzzle Challenge einen Artikel. Jones ^Albtraum? 23:54, 19. Mär. 2018 (CET)

Da sich SwowoJonny nun bereits die Mühe gemacht und eine entsprechende Infobox erstellt hat, wäre es vielleicht angebracht diese hier nochmals zu begutachten. An eine Strukturierung hat er sich zudem bereits in den Artikeln zu Chunsoft und Niantic gewagt. Insgesamt greift das viele der hier genannten Punkte von Jones auf und versucht sie umzusetzen. Dennoch habe ich das Gefühl, dass noch nicht alle Fragen in voller Gänze geklärt zu sein scheinen, z. B. welche Firmen sich für einen Artikel qualifizieren. Aus diesem Grund halte ich es für sinnvoll, an dieser Stelle nochmals durch ein Feedback an dem Konzept zu arbeiten, sodass wir diesen Punkt im Anschluss guten Gewissens abhaken können und eine Musterstruktur für alle (auch zukünftigen) Firmen-Artikel haben. ~ Taisuke ^Diskussion 00:11, 5. Jul. 2018 (CEST)

Alle Spiele-Firmen, welche bisher im Wiki vertreten waren, als auch Niantic, sind an sich vervollständigt. Aktuell arbeite ich noch am Artikel für Hudson Soft sowie den Artikel für Nintendo, welchen ich zu Gunsten der VBW gestalte. Jedoch haben wir noch nichts bezüglich den Firmen außerhalb der Spiele. Firmen, welche für den Anime, den Manga oder auch Merchandise oder Karten verantwortlich sind, liegen weit zurück. Mich würde es interessieren, an welchen Firmen Interesse liegt und an welchen nicht. Eure Meinungen? SwowoJonny 13:24, 4. Aug. 2018 (CEST)

Für den Anime schätzungsweise OLM, vom TCG-Bereich her wohl Wizards of the Coast, falls die damals auch in Deutschland zuständig für waren (weiss ich ehrlichgesagt gar nicht), und eventuell Amigo, ist aber imo nicht so wichtig. Aus dem Manga-Bereich hat Shōgakukan schon nen Artikel, den man mal überarbeiten sollte. Ansonsten vielleicht noch Panini? Müsste das Manga-Projekt entscheiden. --Mecanno-man^Mäh 12:14, 30. Aug. 2018 (CEST)

Missionen

Hey liebe Menschen,

mir ist gerade mal wieder aufgefallen, dass wir noch diese Missionen haben, von denen die letzte vor über einem Jahr erfüllt wurde... Also wirklich genutzt wird das ja scheinbar nicht. Ich meine, da stehen noch Missionen von Isso als Itemprojektleiter drin. Hättet ihr irgendwelche Ideen, wie man das wiederbeleben könnte, oder sollten wir uns alle einen Ruck geben und einfach wieder mehr Missionen dort einstellen? Ansonsten könnte man den Kram auch einfach abhaken und archivieren. Einen Platz im Hauptmenü hat es so jedenfalls nicht verdient. Lg --Fliegen bis zum Horizont. Killuu https://i.imgur.com/4EZCZEO.png 21:02, 2. Mai 2018 (CET)

Ich würde es sehr begrüßen, wenn die Missionen wiederbelebt werden würden, da ich sie, soweit ich es beurteilen kann, für ziemlich hilfreich halte, um Autoren zu motivieren. Da jedoch weder eine Mission erfüllt noch eine neue erstellt wurde, seitdem ich mich im PokéWiki angemeldet habe, ist diese Annahme eher Spekulation. Vielleicht würde eine Ankündigung von Missionen auf Discord weiterhelfen, um einen Neuanfang zu starten, wenn die Missionen nur auf der Missionsseite stehen würde, würde es wahrscheinlich fast niemand mitbekommen. Ansonsten könnte ich beinahe garantieren, dass das Strategie-Projekt sicherlich mindestens eine Mission pro Monat stellen könnte, aufgrund der monatlichen Tier-Shifts. Luca12379 ^Diskussion 14:33, 4. Mai 2018 (CEST)

Ich schließe mich Luca da an, auch was den Vorschlag mit Discord betrifft. Außerdem könnte eine Wiederbelebung der Missionen vielleicht auch dazu führen Autoren auf Bereiche aufmerksam zu machen, auf welche sie auf eigene Faust vielleicht auch garnicht gekommen wären. Projekte können für den einen oder anderen vielleicht so aufmerksam gemacht werden. Die Zusammenarbeit zwischen den Autoren wird so sicherlich auch gestärkt. Also ich wäre definitiv dran interessiert. SwowoJonny 14:44, 4. Mai 2018 (CEST)

Der Wunsch der Wiederbelebung ist ja schön und gut, aber gibt es auch wirklich etwas, mit dem man das ganze füllen kann? Es gefällt mir schonmal, dass Luca was hat, aber wie ist das beim Rest? Ich persönlich wüsste spontan nichts, was ich in meinen Bereichen als Mission anbieten könnte, dass sind halt einfach überwiegend routinierte Sachen, bei denen es schwer ist, etwas als Mission darzustellen, die eben auch Anfängerfreundlich ist -- RobbiRobb 15:09, 4. Mai 2018 (CEST)

Ich leite auch nicht gerade missionierbare Projekte. Was sagen denn so die anderen Projektleiter dazu? --Kein Dschungel zu dicht... Killuu https://i.imgur.com/acgb9YG.png 20:03, 19. Mai 2018 (CET)

Da ich das Missionsbrett nicht ganz aufgeben möchte, werde ich mal schauen, was ich machen kann. Ein Umstyling? Ein paar leichte Missionen? Vielleicht lockt das. Das Isso 08/15 ^Konter 12:11, 27. Jun. 2018 (CEST)

Ein Umstyling wäre vielleicht wirklich nicht schlecht Auf jeden Fall irgendwas, um das ganze ansprechender zu gestalten - angefangen damit, dass man diesen letzten Abschnitt, der den meisten Leuten egal sein dürfte, mal so einstellen könnte, dass nur PLs/VBs ihn sehen können. Der normale Nutzer hat davon eh nix. Und ein paar einfache Missionen wären glaube ich auch gut, um da mal wieder Leben rein zu bringen, denn um es abzuschaffen wäre es mir auch zu schade, schließlich hätten wir dann abgesehen von Projekthelden und Rängen nahezu keine Auszeichnungen mehr und nahezu nichts, womit man einfach mal Nutzer auszeichnen kann, die nicht unbedingt an einem Projekt mitwirken oder insgesamt nicht so aktiv sind, aber bei einer bestimmten Sache aushelfen. Trotzdem finde ich es schwierig, da irgendwas zu finden, was man gut als einfache Mission nehmen kann, ich habe schon lange die Item-Beschriebungen im Kopf, aber irgendwie finde ich sowas zu einfach, schließlich ist das vermutlich sogar mit einem Bot machbar... -- RobbiRobb 12:20, 27. Jun. 2018 (CEST)

Ich habe jetzt auch nochmal ein paar Missionen eingestellt. Und auch direkt mal auf Discord in dem entsprechenden Projekt darauf aufmerksam gemacht. Vielleicht müssten wir uns das angewöhnen, auf den Projektseiten und Discord die Missionen dann auch anzugeben. Würde sich eventuell auch in Discordchannel dafür lohnen? Ohne Schreibrechte vielleicht, sodass da nur die aktuellen Missionen gepusht werden? Lg --Und dann im Mondschein... Killuu 18:13, 8. Jul. 2018 (CET)

Grüß euch. Ist aus der Wiederbelebungs-Aktion der Missionen jetzt eigentlich etwas geworden? Der Ansatz, eine Person für solche Missionsabschlüsse (die jetzt ja vom Niveau her sehr unterschiedlich sind) zu belohnen ist ja irgendwie ganz nett, aber wie ich finde auch irgendwo nicht zielführend. Wir haben etliche Auszeichnungen, die theoretisch Motivation geben können, praktisch sind sie aber eigentlich egal und nur zur Profilierung gedacht. Wofür denn noch Missionen, wenn wir (äußerst) wertvolle Benutzer, Projekthelden (sogar mit drei Abstufungen!), Edit-Auszeichnungen, die in Vergessenheit geratene Auszeichnung der "Helfenden Hand", die Verbesserungswochen und (wenn man das überhaupt als Auszeichnung sehen kann) die Stimmberechtigung, die Rechte der verlässlichen User sowie die Redakteurs-Rechte haben? Damit sind es eigentlich sehr viele Möglichkeiten, mit denen man den Usern ihre Anerkennung und ihren neu angetriebenen Ansporn geben kann. Diese Missionen wurden ja auch nicht besonders beworben (so kam es mir zumindest vor, korrigiert mich, wenn das falsch ist), und haben deshalb nur mediokren Anklang gefunden. Und zu deinem Punkt, Robbi: Einfache Missionen sind natürlich gut, um vielleicht Leute zu beschaffen, die sonst eher nur gelegentlich mal ins Wiki reinschauen. Aber solche Massenedits, die Bots genauso machen können, müssen wir da nicht unbedingt verteilen. Ließe sich nur irgendwas nettes finden, wofür man nicht unbedingt besonders lange Zeit investieren muss, wäre das Ganze ja schön. Dann ließe sich auch feststellen, ob das Missionsbrett wirklich als Motivation taugt. Denn ich glaube nicht, dass Leute dazu geneigt sind, Missionen zu erfüllen, wenn die Hälfte davon nur nach dem Schema "Erstelle ein XdW zu [...]" ist. Ein XdW kostet nun mal Zeit und muss auch mehrmals korrigiert werden, bevor es auf der Hauptseite vorgestellt werden kann. Fazit: Wenn wir leichte Aufgaben finden, kann man das ja mal als Missionen eintragen und schauen, wie sich das mit den Missionen weiterentwickelt. Ansonsten sehe ich da nicht viel Hoffnung und würde eher eine komplette Archivierung befürworten. Mit liebstem Grüß, --Gala 06:53, 27. Aug. 2018 (CEST)

Ich meine der einzige Grund warum es das überhaupt noch gibt ist weil shadow mit der PokéWiki:To-do-Liste nicht einverstanden war; wir wollten es abschaffen sobald wir die fertig hatten, das ist aber irgendwie im Sand verlaufen. --Mecanno-man^Mäh 23:17, 29. Aug. 2018 (CEST)

Das Thema wurde gestern auf dem Chattreffen besprochen, dessen Zusammenfassung hier nachgelesen werden kann. Das Missionsbrett soll demnach weiterhin bestehen und für einzelne kleine bis größere Bearbeitungen genutzt werden soll (also keine Massenedits). Alle Projektleiter (und gerne auch andere User ab der Stufe Verlässlicher Benutzer) sind angehalten, zu überlegen/prüfen, ob sie hierfür Aufgaben einstellen können. Also selber einfach ein bisschen hinterklemmen. Sollte das nicht laufen, kann man ja immer noch über eine Entfernung nachdenken. Lg --Klein, aber fein. Killuu 15:11, 22. Okt. 2018 (CET)

Variables

Ich würde gern den Vorschlag äußern, dass es verpflichtend sein sollte, die Definition von Variables auf Hilfe:Variables zu dokumentieren. Dass ich dies für sinnvoll halte, ist besonderen Eigenschaften von Variables geschuldet:

1. Variables sind die einzige Funktion, die aus der Verschachtelung von MediaWiki in größerem Maße ausbricht und so zu unerwarteten Effekten führen kann. Es ist nicht möglich, das Deklerieren einer Variable am Ende einer Vorlage völlig rückgängig zu machen und zudem recht schwer, den Grund für die unerwarteten Effekte zu finden, da die meisten Seiten recht viele Vorlagen einbinden.
2. Der Inhalt von Variables ist über eine einzelne Vorlagen hinaus relevant. Es sollte zentral dokumentiert sein, auf welchen Seiten welche Variables zur Verfügung stehen, sodass andere Benutzer wissen, auf was sie bei der Programmierung von Vorlagen für entsprechende Seiten bereits zurückgreifen können.
3. Benutzer bleiben nicht für immer, und Variables erhöhen die mögliche Komplexität von Vorlagen noch weiter, als es zuvor schon der Fall war. Wenn die Benutzer, die bestimmte Vorlagen geschrieben haben, inaktiv waren, können sie einen gordischen Knoten bilden, der kaum mehr zu durchblicken ist. Zudem können sie keine Nachfragen im Sinne des letzten Punktes mehr beantworten.
4. Aus denselben Gründen kommentiert man ja auch Quellcode…

-- Skelabra2509 (Diskussion | Beiträge) 21:35, 16. Jun. 2018 (CEST)

Ich versteh zwar nicht viel von Variables, aber trotzdem mal , oder ist dies schon abgeschlossen? --Mecanno-man^Mäh 12:17, 30. Aug. 2018 (CEST)

Nein, hier ist leider nichts weiter passiert. -- Skelabra2509 (Diskussion | Beiträge) 15:21, 30. Aug. 2018 (CEST)

Abstimmung: Kategorie zu Pokémon: Let’s Go, Pikachu! und Let’s Go, Evoli!

Diese Abstimmung ist vorbei. Die meisten Stimmen erhielt Kategorie:LGPE-Screenshot, womit diese Kategorie bestehen bleibt und ähnliche Kategorien nach demselben Muster angelegt werden.

Hallo liebe Leute,

da vor einigen Tagen eine kleinere Diskussion auf unserem Discordserver zu einer Screenshot-Kategorie zum Spiel Pokémon: Let’s Go, Pikachu! und Let’s Go, Evoli! entstanden ist, möchte ich an dieser Stelle eine Abstimmung starten. Momentan haben wir sowohl Kategorie:LGPE-Screenshot als auch Kategorie:LGPLGE-Screenshot; benötigen tun wir aber nur eine von ihnen. Aus diesem Grund kann bei dieser Abstimmung jeder stimmberechtigter Benutzer eine Stimme abgeben. Diese Abstimmung ging bis zum 04.07.2018 um 23:59 Uhr.

Je nach Ausgang dieser Abstimmung, werden selbstverständlich auch ähnliche Kategorien – z. B. zu den Sprites oder VS-Sprites – nach dem ausgewählten Muster angelegt. ~ Taisuke ^Diskussion 09:28, 27. Jun. 2018 (CEST)

Kategorie:LGPE-Screenshot

1. [1] vs [2]. Dürfte klar sein was sich durchsetzt in der Community und was einfacher zu merken ist, somit ist LGPE auch besser zu finden. Jones ^Albtraum? 09:55, 27. Jun. 2018 (CEST)
2. Abk. sind da um abzukürzen, demzufolge ist kürzer besser. Das Isso 08/15 ^Konter 12:08, 27. Jun. 2018 (CEST)
3. Als Gegenargument zu SpielefreakJ's S2W2-Argument: Let's Go ist ein Übername zu den Spielen, so reicht es Let's Go Pikachu & Evoli zu sagen. Bei S2W2 ist die ’2’ ein wichtiger Bestandteil beider Spielnamen. Deshalb denke ich ist LGPE mehr als ausreichend. Schiggy91 14:07, 27. Jun. 2018 (CEST)
4. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 14:10, 27. Jun. 2018 (CEST)
5. SwowoJonny 14:15, 27. Jun. 2018 (CEST)
6. Sechs Buchstaben sind für eine Abkürzung zu viel. Außerdem weiß bei LGPE jeder was gemeint ist. Friedrich on ice^❄ 15:02, 27. Jun. 2018 (CEST)
7. Auf jeden Fall LGPE! KappaDor^*Dis* 15:53, 27. Jun. 2018 (CEST)
8. -- Liebe Grüße, Moltres 18:15, 27. Jun. 2018 (CEST)
9. Das Spielkürzel wäre für mich kein aussagekräftiges Argument; sonst hätten wir auch die Kategorie:ΩRαS. Dann ist eine kurze Abkürzung doch zu bevorzugen.--★☆★ Pk-fan 18:16, 27. Jun. 2018 (CEST)
10. Solange man versteht, welches Spiel gemeint ist, finde ich das kürzere Kürzel besser :) - Michelle ^o° 23:00, 27. Jun. 2018 (CEST)
11. Luca12379 ^Diskussion 00:17, 28. Jun. 2018 (CEST)
12. Ist halt einfacher. Esteror (Diskussion) 20:33, 28. Jun. 2018 (CEST)
13. Ich denke, ich bin auch für die abgekürzte Variante. Als Beispiel dient mir HGSS, welches auch abgekürzt wurde und, Gott sei Dank, nicht zu GEHGSESS wurde. Grüße ShortyBuzz 12:40, 30. Jun. 2018 (CEST)
14. Ich sehe auf langer Sicht eher diese Abkürzung als allgemein genutzte Abkürzung für die beiden Spiele, weshalb ich diese Abkürzung auch für die dazugehörigen Kategorien bei uns nutzen würde. ~ Taisuke ^Diskussion 20:00, 2. Jul. 2018 (CEST)
15. Ich stimme dieses Screenshots zu. Besser als LGPLGE! AAWiki ^Diskussion 22:11, 4. Jul. 2018 (CEST)
16. Da trotz des Weglassens des zweiten "LG" immernoch klar ist, was gemeint ist, bevorzuge ich die kürzere Schreibweise. Simonsees ^[Diskussion] 22:56, 4. Jul. 2018 (CEST)

Kategorie:LGPLGE-Screenshot

1. War zwar anfangs erst für LGPE, da es einfacher zu merken war, jedoch ist es in ähnlicher form wie bei der Kat von S2W2 (ist ja auch nicht SW2). Gruß, SpielefreakJ 09:48, 27. Jun. 2018 (CEST)
   P.S.: Als ich die Screenshot-Kat's durchgegangeb bin, viel mir auf, dass die Rumble U kat noch PSU heißt.
2. Ich wäre dafür, die Kategorien so zu gestalten, dass man durch die Kategorien die Schreibweise für die jeweiligen Spiele innerhalb der Spielkürzel-Vorlage nachahmt. LGELGP LGPLGE macht es dann konsistenter im Ganzen. — mfg ^Snack_hound 12:42, 27. Jun. 2018 (CEST)
3. Ich schließe mich Snackhound an und finde ebenfalls, dass man sich da etwas an die Spielkürzel richten sollte. Natürlich ist LGP kompakter, jedoch ist es doch auch unvollständig. Yinni ^✧* 11:34, 29. Jun. 2018 (CEST)

Kommentare

Da der Abstimmungszeitraum nur eine Woche beträgt, gehen an dieser Stelle Pings an die stimmberechtigten Benutzer (AAWiki, BaseEvoli, CLina, Der Sternendiamantritter, Esteror, Flonc, FloRyan, Freigeist, Friedrich on ice, Heiteira, Hydrokyu, Jasuanti, Kappador, Kypo, Mario-WL, Michelle, Pintauranimus, Pokénator, Simonsees, Schiggy91, Skelabra2509, SpielefreakJ, SwowoJonny und Tyber) und erweitert stimmberechtigten Benutzer (Buoysel, GoPika, Impoleon xy, Isso08-15, Jones, Kenaz-Hagalaz, Killuu, Korvel1, Lombrero, Loxi-kun, Luca12379, Matze, Maxmiran, Mecanno-man, Moltres, Pk-fan, RobbiRobb, Ryuichi, shadowtweaker, ShortyBuzz, Snackhound und Yinni) raus. ~ Taisuke ^Diskussion 09:29, 27. Jun. 2018 (CEST)

Wo ist die Enthaltungsüberschrift? Ich finde, beides hat seine Vorzüge und so ist es mir eigentlich egal. --Fliegen bis zum Horizont. Killuu 22:43, 27. Jun. 2018 (CET)

Ich schließe mich hier Killuu an. - - "I'm gonna swing from the chandelier" GoPika ^Disku 14:08, 30. Jun. 2018 (CEST)

Mir ist es nicht egal, aber ich kann mich nicht entscheiden, da es für beide Seiten gute Punkte gibt. Zunächst einmal finde ich kürzere Namen praktisch, ich bin faul und gebe gerne weniger ein, wenn es geht ^^ Dazu kommt auch, dass LGPE in meinen Augen intuitiver ist, warum genau kann ich nicht sagen, fühlt sich für mich aber so an. Auf der anderen Seite haben wir LGPLGE, was sich wie gewöhnlich näher an den Spielkürzeln orientiert, wie es die meisten anderen Kategorien auch machen. Dadurch lässt es sich besonders für neue Nutzer leichter finden. Insgesamt wiegen die Punkte sich gegenseitig auf, womit ich keinen eindeutigen Favoriten habe. Ich könnte letzendlich mit beidem leben. -- RobbiRobb 19:56, 2. Jul. 2018 (CEST)

Angepasste Rechtestruktur im Testwiki

Seit einiger Zeit steht uns neben diesem Wiki ein Test-Wiki zur Verfügung, das dazu genutzt wird, Updates, Anpassungen an der Konfiguration und andere Tests mit Vorlagen und ähnlichem durchzuführen. Dieses basiert auf einer alten Version des Wikis aus dem letzten Winter und ist von diesem Wiki unabhängig, das heißt Änderungen in einem Wiki führen nicht zu Änderungen im anderen Wiki.

Da im Test-Wiki kaum Schaden angerichtet werden kann, bietet es sich dort an, dort einer größeren Gruppe von Benutzern Rechte zu vergeben, um derartige Tests durchzuführen. Insbesondere für Vorlagentests in der Praxis ist das Testwiki sehr geeignet, da hier das Risiko eingegangen werden kann, durch radikalere Veränderungen Artikel zu zerschießen, ohne dass ein Schaden entsteht. Diese Möglichkeiten werden allerdings insbesondere durch den Seitenschutz im Testwiki, der dem im PokéWiki auf Stand Winter 2017 entspricht, eingeschränkt.

Für Tests sind insbesondere folgende Rechte über dem SB-Level von Nutzen:

• admin, redakteur, trusted, um höher geschützte Seiten zu bearbeiten.
• delete, rollback um Tests danach aufzuräumen.

Folgende Rechte sollten hingegen in keinem Fall einer weiteren Gruppe von Benutzern zur Verfügung gestellt werden, da sie indirekt Berechtigungen in diesem Wiki oder große Sicherheitsrisiken darstellen:

• editinterface, edituserjs, editusercss können benutzt werden, um bösartigen Code einzuschleusen.
  • Ersteres Recht wird dabei ab MW 1.32 deutlich unkritischer und könnte dann ggf. nochmal diskutiert werden.
• undelete, deletedhistory, deletedtext können verwendet werden, um Zugriff auf in diesem Wiki evtl. bewusst versteckte Inhalte zu erhalten.
• checkuser, checkuser-log können verwendet werden, um persönliche Informationen von Benutzern auszulesen.

Um die Rechte von Benutzern zu erweitern, stehen grundsätzlich drei Möglichkeiten zur Verfügung:

• Benutzergruppen werden direkt um Rechte erweitert.
• Benutzer erhalten das Recht, sich selbst höheren Gruppen zuzuordnen
• Es werden spezielle Gruppen eingeführt, die sich Benutzer mit bestimmten Berechtigungen selbst hinzufügen.

Berücksichtige ich diese Überlegungen sowie, dass im Testwiki eine komplexe Hierarchie mit Ausnahme vom Verhindern von Sicherheitsrisiken keinen weiteren Zweck erfüllt, komme ich zu folgendem Ergebnis für ein angepasstes Rechtesystem. Dieses unterscheidet letztlich zwischen Administratoren, Redakteuren, anderen privilegierten Benutzern und sonstigen, behält aber die Standardgruppen bei. Folgende Anpassungen schlage ich vor:

• Stimmberechtigte Benutzer und Veteranen können sich selbst zu Verlässlichen Benutzern machen und sich selbige Rechte wieder entziehen.
  • Mit dem Rang des VBs gehen keine sicherheitskritischen Rechte einher, die Arbeit im Wiki wird allerdings vereinfacht.
  • Benutzer, die seit dem Aufsetzen der Testversion SB geworfen sind, können diese Rechte bereits von Redakteuren wenn benötigt erhalten.
• Verlässliche Benutzer erhalten Zugriff auf redakteur-geschützte Seiten.
  • So können die meisten Vorlagen zu Testzwecken bearbeitet werden.
• Redakteure erhalten Zugriff auf admin-geschützte Seiten.
  • So können alle Seiten außerhalb des MW-Namensraums bearbeitet werden.

Damit hätte man die Situation für Tests für die meisten aktiven Benutzer deutlich verbessert. Denkt man allerdings die Argumentation logisch zu Ende, kann man noch weitere Rechte erteilen, die nicht sicherheitskritisch sind:

• Verlässliche Benutzer erhalten admin-Rechte, sodass sie alle Vorlagen bearbeiten können.
• Verlässliche Benutzer erhalten delete-Rechte, um hinter ihren Tests wieder aufräumen zu können. Dieses Recht erlaubt nicht die Einsicht in gelöschte Inhalte.
• Redakteure erhalten block-Rechte, um möglicherweise störende Benutzer zu sperren.

Was haltet ihr von diesem Vorschlag? Findet ihr das vorgeschlagene Modell angemessen, oder würdet ihr eine angepasste Version vorziehen? Buoysel wäre mit einer angepassten Konfiguration im Test-Wiki einverstanden, sofern keine Sicherheitsrisiken entstehen. -- Skelabra2509 (Diskussion | Beiträge) 23:15, 29. Aug. 2018 (CEST)

Ich schließe mich hier Skelabra2509 an --Ige64 23:30, 29. Aug. 2018 (CEST)

Mir Wurst. Das einzige was man bedenken muss ist das diese Einstellungen bei jedem Zurücksetzen des Testwikis erneut vorgenommen werden müssen. Aber wenn @Buoysel das macht, bitte. --Mecanno-man^Mäh 23:40, 29. Aug. 2018 (CEST)

Sehe hier persönlich keine Notwendigkeit, User die SB sind können so oder so im Vorlagennamensraum arbeiten. Der Quelltext ist immer einsehbar. Wenn sie eine Vorlage nicht bearbeiten können dann erstellen sie einfach eine Neue welche sie im Testwiki einfügen können wo sie wollen. patrol markierungen interessieren dort keinen, ebensowenig ob dort danach aufgeräumt wird, somit wäre delete und rollback unnötig. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 08:40, 30. Aug. 2018 (CEST)

Ich finde das eine schöne Idee. Ob und inwiefern das nötig ist, kann ich nur wenig einschätzen, vor allem beim Aufräumen sehe ich es wie Ryu. Aber ich kann mir vorstellen, dass es für User auch einen netten Anreiz darstellen kann, wenn sie im Testwiki "Blut lecken" und erleben, was man für tolle Sachen kann, sobald man sich eine höhere Rechtestufe erarbeitet hat. Daher ein Pro! Maxmiran 09:37, 30. Aug. 2018 (CEST)

Seh ich ehrlich gesagt keinen Sinn drin, mal abgesehen davon, dass die Änderungen jedesmal angepasst werden müssten, ist das Testwiki auch nicht wirklich für "normale" Tests geeignet und eine wirkliche Nutzung bis hin zu SBs runter würde mMn sogar zu noch mehr versehentlichen Reverts führen, da Änderungen hier eben nicht gespiegelt werden. Auch Seitenschutz ist eher uninteressant, abgesehen vllt von CSS/JS, wo man aber nen Admin fragen kann, immerhin spricht im Testwiki nichts dagegen Benutzerseitenvorlagen auch testweise in Artikeln einzubinden. Und Aufräumen tut da nach Tests auch keiner (und wird vorallem bei Bottests auch eher nervig...) Jones ^Albtraum? 10:04, 30. Aug. 2018 (CEST)

Ich muss hier in mehreren Punkten widersprechen.

Zum einen ist die Behauptung, SBs (und eigentlich sogar noch VBs) könnten im Vorlagennamensraum arbeiten, recht schöngeredet. An tatsächlich einigermaßen komplexen und häufig eingebundenen Vorlagen lässt sich in den seltensten Fällen etwas modifzieren. Und die Besonderheit im Testwiki ist ja gerade, dass man direkt mit den Vorlagen testen kann, sodass man das Ergebnis nicht nur in konstruierten Testfällen, sondern in dem realen Datensatz zugesicht bekommt. Die Realität ist immer komplexer, als was man sich als mustergerechte Anwendung überlegt hat, und so kann man viel einfacher dort Fehler finden. Auch die Praktikabilität, sich die Vorschau einer Vorlage direkt in Artikeln anzeigen zu lassen, ohne dort vorher den Vorlagennamen ändern zu müssen, wird hier unterschätzt. Wenn man die Möglichkeiten nicht hat, Vorlagen direkt zu Testzwecken zu bearbeiten, ist das Testwiki für Vorlagentests unnötig.

Zum zweiten finde ich, dass im Testwiki die Mentalität nicht sein muss: Welche Rechte brauchst du jetzt genau zum Testen? Es entsteht schließlich bei den meisten Rechten kein Schaden, wenn sie dort einem weiteren Nutzerkreis zugängig sind, aber einen Nutzen gibt es offenbar, wie ich hier dargelegt habe. Ich finde deswegen nicht, dass man hier zu kleinkariert sein muss, was die Rechtevergabe betrifft, sondern durchaus freigiebiger sein kann als in diesem Wiki.

Zum dritten ist es kein großes Ding, wenn die Änderung bei jedem Neuaufsetzen angepasst werden müssen. Das passiert höchstens zwei oder drei mal im Jahr, und die von mir vorgeschlagen Änderungen sind einfach etwa 10-Zeilen PHP-Code, die unten in die LocalSettings kopiert werden können. Das ist wirklich vernachlässibar.

Und zum letzten: Warum sollte das Testwiki nicht geeignet sein, um "normale" Tests durchzuführen? Das Testwiki wird laufend von Vorlagenprogrammiern genutzt, um dort Tests durchzuführen, und ich wurde für solche Tests auch schon von Ryu dorthin verwiesen. Ich sehe nicht wirklich irgendeinen Schaden darin, wenn auch einige SBs das Testwiki benutzen, es ist ja nicht so, als würden wir sie aktiv dahinschicken. -- Skelabra2509 (Diskussion | Beiträge) 15:34, 30. Aug. 2018 (CEST)

🤔 würde da nicht reichen editprotected und editsemiprotected an SB+ zu vergeben? * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 15:49, 30. Aug. 2018 (CEST)

Sinngemäß ja, aber unsere höheren Seitenschutzlevel werden durch die Berechtigungen admin, redakteur und trusted gesteuert. -- Skelabra2509 (Diskussion | Beiträge) 01:10, 9. Sep. 2018 (CEST)

Mir fällt grad auf: Sind einige Vorlagen nicht noch geschützt, um die Server nicht zu überlasten? Wiki und Testwiki laufen afaik aufm selben Server, wenn jemand folglich im Testwiki ine ofteingebundene Vorlage oft bearbeitet, dürfte das dann nicht auch Auswirkungen auf das Livewiki haben? --Mecanno-man^Mäh 13:53, 8. Sep. 2018 (CEST)

Ich vermute, dass das keine Probleme verursacht, das das Testwiki kaum ausgeloggte Aufrufe hat. Die Zeiten, wo wir große Probleme damit hatten sind zudem schon länger vorbei. Ich denke Buo würde was sagen, wenn das ein Problem wäre. -- Skelabra2509 (Diskussion | Beiträge) 01:10, 9. Sep. 2018 (CEST)

Die Jobs werden ohnehin nicht automatisch abgearbeitet, insofern gibt es nahezu keine Belastung bei einem Edit im Testwiki, selbst wenn die Vorlage tausenden male eingebunden ist. -- RobbiRobb 12:56, 17. Sep. 2018 (CEST)

Abstimmung: Der Doppelpunkt am Ende von einigen Kategorien

Es handelt sich hierbei um eine relativ simple Frage: Sollen Kategorien, deren Unterkategorien durch Doppelpunkte abgetrennt sind, einen Doppelpunkt am Ende haben (Beispiel: Kategorie:Benutzer:) oder soll es einfach nur der Name sein? (Das wär in diesem Fall dann Kategorie:Benutzer). Zu beachten ist hierbei das dies ausschliesslich für die Kategorien gilt, bei denen der Doppelpunkt am Ende steht. Kategorie:Benutzer:10000 Edits würde also in jedem Fall bleiben wo sie ist.

Diese Abstimmung ist vorbei. Die meisten Stimmen sprachen sich gegen den Doppelpunkt aus.

(Mit Doppelpunkt)

1. Ohne Doppelpunkt ist das System nun mal ganz klar inkonsistent: Wenn alle PokéWiki-Kategorien einen Doppelpunkt am Ende haben, quasi als Analogon zu den Namensräumen, so ist es ein Fehler im System, wenn die Hauptkategorie, die zu dem entsprechenden Namensraum gehört, keinen Doppelpunkt am Ende hat. -- Skelabra2509 (Diskussion | Beiträge) 13:33, 7. Sep. 2018 (CEST)

(Ohne Doppelpunkt)

1. --Mecanno-man^Mäh 12:10, 7. Sep. 2018 (CEST)
2. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 12:12, 7. Sep. 2018 (CEST)
3. - - "I'm gonna swing from the chandelier" GoPika ^Disku 12:22, 7. Sep. 2018 (CEST)
4. Aufgrund dessen, dass es immer so wahr und bereits der Namens erreicht schon einen hat. Gruß, SpielefreakJ 12:31, 7. Sep. 2018 (CEST)
5. Friedrich on ice^❄ 12:35, 7. Sep. 2018 (CEST)
6. Jones ^Albtraum? 12:37, 7. Sep. 2018 (CEST)
7.  TM Master  13:30, 7. Sep. 2018 (CEST)
8. ~ noch ein schönen Tag ^^ ~ DarkViper 14:50, 7. Sep. 2018 (CEST)
9. Loxi-kun
10. Schiggy91 20:44, 7. Sep. 2018 (CEST)
11. Korvel1 ^Diskussion 10:22, 8. Sep. 2018 (CEST)
12. SwowoJonny 11:44, 8. Sep. 2018 (CEST)
13. Tyber 01:29, 9. Sep. 2018 (CEST)
14. -MfG, Kenaz-Hagalaz ^Disku 13:49, 10. Sep. 2018 (CEST)
15. Yinni ^✧* 10:25, 14. Sep. 2018 (CEST)
16. Ich verstehe nicht, wozu das nützen soll, außer dass es komisch ausschaut. --Kein Dschungel zu dicht... Killuu 11:09, 15. Sep. 2018 (CET)
17. -- RobbiRobb 12:56, 17. Sep. 2018 (CEST)
18. --❄❄ Pk-fan 14:47, 17. Sep. 2018 (CEST)

(Mir sowas von egal)

1. aber sowas von Das Isso 08/15 ^Konter 13:47, 7. Sep. 2018 (CEST)
2. Maxmiran 16:03, 7. Sep. 2018 (CEST)
3. Ich versteh nichtmal den Unterschied bzw. den Sinn dahinter :ka: Und um es mit dem Worten der „die ärzte“ zu sagen: „Mir könnte nichts egaler sein!“ -- Grüße ShortyBuzz 17:33, 7. Sep. 2018 (CEST)
4. Was kann schon schlimmstenfalls passieren, aber ich halte mich hier raus Hydrokyu 18:04, 7. Sep. 2018 (CEST)
5. AAWiki ^Diskussion 19:34, 7. Sep. 2018 (CEST)
6. Luca12379 ^Diskussion 21:32, 7. Sep. 2018 (CEST)
7. Esteror (Diskussion) 21:09, 9. Sep. 2018 (CEST)
8. Michelle ^o° 20:34, 10. Sep. 2018 (CEST)
9. Snowy Dragons ^Diskussion 23:36, 14. Sep. 2018 (CEST)
10. Simonsees ^[Diskussion] 21:23, 20. Sep. 2018 (CEST)
11. -- Liebe Grüße, Moltres 09:34, 21. Sep. 2018 (CEST)

Kommentare

Ich kann beide Seiten verstehen. Auf der einen Seite möchte Skel beim Aufräumen unserer Kategorien es dann auch komplett richtig machen, sodass man nicht nochmals auf die Idee kommen würde, es in ein paar Jahren zu überarbeiten, weil es nicht in sich schlüssig ist. Natürlich sieht ein Doppelpunkt am Ende einer Kategorie bescheiden aus, aber er wäre nach der Herangehensweise von Skel korrekt. Dennoch kann ich gut nachvollziehen, dass es vielen einfach zu kompliziert gedacht ist. Vor allem, da sich kaum einer für unsere Kategorien interessieren wird, sondern eher für die Artikel und die Handhabung dadurch komplizierter wird als bisher. Es hat in den letzten Jahren niemanden gestört, wieso sollte es also in den nächsten Jahren jemanden stören? Ich kann mich jedoch auf keiner der beiden Seiten komplett wiederfinden, weshalb ich nur ein „Kommentar“ abgebe; egal ist es mir nämlich auch nicht.
Aufgrund der bereits abgegebenen Stimmen ist ohnehin ein Ergebnis erkennbar, da wir uns für eine inkonsistente, aber dafür benutzerfreundlichere Kategorisierung entschieden haben. ~ Taisuke ^Diskussion 09:57, 21. Sep. 2018 (CEST)

Ping

@Buoysel, GoPika, Impoleon xy, Isso08-15, Jones, Kenaz-Hagalaz, Killuu, Korvel1, Lombrero, Loxi-kun, Luca12379, Matze, Maxmiran, Mecanno-man, Moltres, Pk-fan, RobbiRobb, Ryuichi, shadowtweaker, ShortyBuzz, Snackhound, Taisuke, Yinni, AAWiki, CLina, DarkViper, Der Sternendiamantritter, Esteror, Flonc, FloRyan, Freigeist, Friedrich on ice, Hydrokyu, Jasuanti, JustRotty, Mario-WL, Michelle, Pintauranimus, Pokénator, Simonsees, Schiggy91, Skelabra2509, Snowy Dragons, SpielefreakJ, SwowoJonny, TM Master, Tyber: --Mecanno-man^Mäh 12:10, 7. Sep. 2018 (CEST)

Meltans Ruf

Liebe Wiki-Gemeinde, ich habe den Ruf von Meltan aus dem Trailer extrahiert. Leider sind meine Wikitext-Kenntnisse gerade nicht groß genug, um den Dateinamen in der Infobox Pokémon zu replacen. Falls das jemand besser hinbekommt, wäre ich dankbar! Hier die Datei! ~ TiMauzi 04:28, 11. Okt. 2018 (CEST)

Danke für den Upload, ich habe die Vorlage mal soweit angepasst, dass der Ruf auch geladen wird ^^ Wenn es dadurch Probleme gibt, bitte Bescheid geben. -- RobbiRobb 09:52, 11. Okt. 2018 (CEST)

Bisschen unelegant, aber der Zweck heiligt die Mittel ;) Vielen Dank! ~ TiMauzi 17:42, 11. Okt. 2018 (CEST)

Ich möchte hiermit mal eben kurz auf meinen Vorschlag auf der Vorlagendiskussion hinweisen! ~ TiMauzi 18:17, 11. Okt. 2018 (CEST)

Hervorhebung von Links für SBs

Um das Hoch des Chattreffens zu nutzen, hab ich heute mal einen etwas technischeren Punkt: Und zwar möchte ich an dieser Stelle vorschlagen, dass Links auf Weiterleitungen und insbesondere Begriffsklärungsseiten für alle Stimmberechtigten Benutzer hervorgehoben werden. Dies hat vor allem den Grund, dass die Benutzer in dieser Gruppe den großteil aller Edits tätigen, da wäre es praktisch, wenn sie nicht noch neue Fehler einbauen, da Links auf diese in den Wartungslisten auftauchen. Weiterleitungen sind zwar nicht so relevant, allerdings kann es trotzdem nicht schaden, sie anzuzeigen, daher würde ich die einfach direkt mitaufnehmen, wenn da niemand dagegen ist. Es ist dabei zwar durchaus möglich, dass Leute durch diese neuen Anzeigen zunächst verwirrt werden könnten, jedoch haben viele diese bereits ohnehin schon hervorgehoben, sodass es für diese nichts neues wäre, die anderen würden dann einfach davon profitieren. Gibt es dazu Gegenstimmen oder trifft das auf Unterstützung? -- RobbiRobb 22:15, 21. Okt. 2018 (CEST)

Scheinbar war ich zu der Zeit gerade afk. Das gilt ja sicherlich auch für höherrangige User? Finds auf jeden Fall praktisch und benutze es selbst ja schon länger. --Und dann im Mondschein... Killuu 22:20, 21. Okt. 2018 (CET)

Das wurde während des Chattreffens nicht angesprochen, ich habe das einfach direkt auf die AD verlegt ^^ Und ja, das gilt für alle, die den Rang eines SBs innehaben – also auch du :D -- RobbiRobb 22:21, 21. Okt. 2018 (CEST)

Fände ich sehr praktisch. Benutze es ja selber im CSS auch für mich. Es ist wirklich angenehmer es so zu haben - zumindest für mich. SwowoJonny 22:26, 21. Okt. 2018 (CEST)

Ja, wäre dafür! ~ TiMauzi 22:31, 21. Okt. 2018 (CEST)

Bin dafür es generell umzusetzen. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 12:39, 22. Okt. 2018 (CEST)

Ich kann mich ebenfalls nur dafür aussprechen. --  TM Master  16:05, 22. Okt. 2018 (CEST)

Ich sehe keinen Nachteil darin, dies direkt für alle Mitglieder ab stimmberechtigt derart einzublenden, ohne das jeder ein eigenes CSS anlegen muss. ~ Taisuke ^Diskussion 21:16, 22. Okt. 2018 (CEST)

BKLs auf jeden Fall, WLs sind mir egal. -- Skelabra2509 (Diskussion | Beiträge) 02:20, 23. Okt. 2018 (CEST)

Ich wäre auch dafür, allerdings finde ich auch wichtig, dass die Darstellung nicht zu offensiv ist. Ich möchte zum Beispiel nur sehr ungerne neben allen Weiterleitungen ein hochgestelltes „WL“ vorfinden, wie einige es in ihrem CSS haben. Ich würde es viel angenehmer finden, wenn die Farbe des Links einfach ein wenig anders ist, zum Beispiel durch einen anderen Blauton, wie es in meinem CSS der Fall ist. Also sollte das Design meiner Meinung nach definitiv vorher abgeklärt werden.--❄❄ Pk-fan 15:44, 24. Okt. 2018 (CEST)

Klingt vernünftig, und wenn dir das Ergebnis nicht gefällt, solltest du es mit deinem eigenen CSS ja einfach wieder überschreiben können ^^ -- RobbiRobb 15:51, 24. Okt. 2018 (CEST)

Stimme dem zu Ige64 ^Diskussion 20:10, 24. Okt. 2018 (CEST)

Auf jeden Fall ein sinnvoller Vorschlag. Ich muss zudem auch Pk-fan zustimmen, dass diese Hinweise nicht zu penetrant sein sollten. Außerdem müsste auf irgendeiner Hilfeseite (oder ähnlichem) dieses Feature für unsere neuen Mitglieder erklärt werden, damit sie in Eigenrecherche auch eine eindeutige Erklärung dazu finden können. -MfG, Kenaz-Hagalaz ^Disku 18:46, 26. Okt. 2018 (CEST)

Eine kurze Änderung auf der Seite zu stimmberechtigten Benutzern mit Erklärung und anschließend eine kleine Mitteilung der Änderung auf der Diskussionsseite, in der alle aktuellen stimmberechtigten Benutzer angepingt und somit darüber in Kenntnis gesetzt werden. Das sollte passen! Vielleicht wäre es auch gut, dann nochmals auf der PokéWiki-Seite zu erwähnen, dass eine einfache Ersetzung von Weiterleitungen als Bearbeitung nicht gern gesehen ist, sondern eher nebenbei gemacht werden sollte. Eine Änderung eines Links auf eine Begriffsklärung jedoch sinnig ist. ~ Taisuke ^Diskussion 12:25, 27. Okt. 2018 (CEST)

Ich denke der Konsens ist gefunden falls noch Zeit gegeben werden soll wäre eine Frist schön @Robbi hast du einen entwurf wie das ganze anschließend aussehen soll? Gruß * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 08:03, 29. Okt. 2018 (CET)

Ich hätte einfach gewartet, bis die Sache zu den KLs durch ist, damit ich mich nicht um zu viel gleichzeitig kümmern muss, und dann eine zwei-wöchige Abstimmung gestartet, wie wir das per default haben wollen, bisher gab es Wünsche nach kursiv und farblich hinterlegt, ich hätte noch das kleine hochgestellte WL in den Ring geworfen. Sollte es noch weitere Wünsche geben, sollten diese also zeitnah geäußert werden, damit sie ebenfalls in die Diskussion kommen können, andernfalls müssten diese die Nutzer halt einfach selber setzen -- RobbiRobb 14:09, 29. Okt. 2018 (CET)

Abstimmung

Abstimmung beendet, Mehrheit für Kürzel. Ergebnis: Farbliche Markierung: 9 Stimmen, Kursiv: 2 Stimmen, Kürzel: 10 Stimmen

Ziel dieser Abstimmung ist der Beschluss eines Standards für die Hervorhebung von Links auf Weiterleitungen und Begriffsklärungen für Stimmberechtigte Benutzer. Dabei ist es natürlich später jedem Benutzer selbst überlassen, ob er diese Hervorhebungen anders dargestellt haben möchte. Jeder Stimmberechtigte Benutzer darf eine Stimme abgeben, die Abstimmung geht vom 05.11.2018 bis zum 19.11.2018 um 23:59:59 Uhr. Heute ist der 28.04.2024 15:46 Uhr.

Farbliche Markierung

1. SwowoJonny 20:29, 5. Nov. 2018 (CET)
2. In meinen eigenen CSS habe ich zwar die hochgestellten Sachen für Weiterleitung^WL und Begriffsklärung^BKL denke allerdings das dies auf den ersten Blick verwirrender sein könnte als wenn der link in grün oder orange wäre. Gerade auch Texte (AdW) würden aufgrund von weiteren Zeichen dahinter Breite gewinnen und unschöne umbrüche Verursachen die derjenige nur sieht weil es WL/BKL sind. Würde hier die Gefahr sehen das Massenbearbeitungen entstehen die sich ausschließlich darauf beziehen und nicht nebenbei mit erledigt werden. Gruß * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 20:52, 5. Nov. 2018 (CET)
3. Fällt auch in der Vorschau sofort auf, ist dementsprechend meiner Ansicht nach die sinnvollste Lösung. --Shin no tatakai wa, korekara da. The true fight is yet to come. JustRotty 15:31, 6. Nov. 2018 (CET)
4. -- Liebe Grüße, Moltres 20:39, 6. Nov. 2018 (CET)
5. Sprechen wir hier nur von farbigen Links, oder farbigen Hinterlegungen? Fände beides nützlicher als die anderen zwei Optionen. — mfg ^Snack_hound 09:37, 9. Nov. 2018 (CET)
6. Luca12379 ^Diskussion 21:38, 9. Nov. 2018 (CET)
7. Die Option der farbigen Markierung ist vorzuziehen: Hochgestellte Kürzel verfälschen das Layout. Kursive Links verfälschen die Satzgestaltung. Ich möchte zudem nochmals auf Snackhounds Vorschlag zu einer zweiten Farbgestaltungsoption hinweisen. -MfG, Kenaz-Hagalaz ^Disku 19:15, 11. Nov. 2018 (CET)
8. Solange es nicht zu bunt wird, definitiv für diese Option. Es reicht ja schon ein leicht anderer Blauton und es fällt trotzdem auf. Ich selbst markiere meine WLs zum Beispiel seit Jahren in dieser Farbe und das reicht mir schon um auffällig genug zu sein. Ich kann gut verstehen, dass dies vielen zu unauffällig ist, aber das Ergebnis sollte meiner Meinung nach nicht direkt orange werden, sondern eher ein anderes Blau, möglicherweise Richtung Türkis oder Dunkelgrün.--❄❄ Pk-fan 22:40, 12. Nov. 2018 (CET)
9. Ich bin da auch Pks Meinung. Eine krass andere Farbe würde ich nicht nehmen, weil die sich dann mit den anderen Farben stechen würden. Ein anderer Blauton, Richtung Türkis oder Dunkelgrün klingt für mich aber sehr vernünftig. :) - Michelle ^o° 21:18, 19. Nov. 2018 (CET)

Kursiv

1. Farbige Links werden sich mit bereits farbigen Links beissen. Für die Argumentation gegen hochgestellte siehe shadow. --Mecanno-man^Mäh 19:53, 6. Nov. 2018 (CET)
2. Mega Glurak Y (Diskussion) 12:42, 8. Nov. 2018 (CET)

Hochgestelltes Kürzel

1. -- RobbiRobb 20:17, 5. Nov. 2018 (CET)
2. Eine kursive Markierung ist zu unauffällig. Des Weiteren kann sie im schlimmsten Fall zu Verwirrungen bzgl. der Formatierung des Textes führen. Eine farbliche Markierung des gesamten Links empfinde ich als störend. --  TM Master  20:27, 5. Nov. 2018 (CET)
3. Entspricht in meinen Augen der "Wichtigkeit" bzw. "Andersartigkeit" der Weiterleitungen ggü. regulären Artikeln besser. Farbliche Markierungen finde ich zu aufdringlich. ~ TiMauzi 21:03, 5. Nov. 2018 (CET)
4. ~ Taisuke ^Diskussion 21:04, 5. Nov. 2018 (CET)
5. ~ noch ein schönen Tag ^^ ~ DarkViper 21:17, 5. Nov. 2018 (CET)
6. ene mene muh -- Grüße ShortyBuzz 21:18, 5. Nov. 2018 (CET)
7. -- Cliffichen ^Diskussion 21:37, 5. Nov. 2018 (CET)
8. Finde es sonst so merkwürdig bunt. Keine Kürzel sind selbsterklärender. --Fliegen bis zum Horizont. Killuu 15:30, 7. Nov. 2018 (CET)
9. ~ ~ Simonsees ~ 23:01, 14. Nov. 2018 (CET)
10. Korvel1 ^Diskussion 10:35, 19. Nov. 2018 (CET)

Kommentare

@Buoysel, CLina, GoPika, Impoleon xy, Isso08-15, Jones, Kenaz-Hagalaz, Killuu, Korvel1, Lombrero, Loxi-kun, Luca12379, Matze, Maxmiran, Mecanno-man, Moltres, Pk-fan, RobbiRobb, Ryuichi, shadowtweaker, ShortyBuzz, Simonsees, Snackhound, Taisuke, Yinni, AAWiki, Cliffichen, DarkViper, Der Sternendiamantritter, Esteror, FloRyan, Friedrich on ice, Hydrokyu, Ige64, Jasuanti, JoshOt, JustRotty, Mario-WL, Mega Glurak Y, Michelle, Pintauranimus, Pokénator, Schiggy91, Skelabra2509, Snowy Dragons, SpielefreakJ, SwowoJonny, TiMauzi, TM Master, Tyber, Yrel: -- RobbiRobb 20:17, 5. Nov. 2018 (CET)

Könnte ich ein Beispiel sehen? Also welche Farbe käme in Frage oder wie würde das Kürzel aussehen? Das Isso 08/15 ^Konter 20:34, 5. Nov. 2018 (CET)

Für die Farbe habe ich kein Beispiel, das hat sich speziell Pk-fan gewünscht . Abgesehen davon gibt es leider 2²⁴ mögliche Farben, daher will ich jetzt auch nicht einfach etwas vorschlagen Beim Kürzel hingegen würde ich einfach das nutzen, was ohnehin ein Großteil der Nutzer verwendet – Beispiellink^WL und Beispiellink^BKL. -- RobbiRobb 20:54, 5. Nov. 2018 (CET)

@Ryuichi: Gegen eine Verwirrung wird auf jeden Fall etwas unternommen, indem auf der Seite der SBs erklärt wird, was die einzelnen Markierungen zu bedeuten haben. Gegen das andere Argument kann ich nichts sagen, das ist einfach eine persönliche Vorliebe ^^ -- RobbiRobb 20:58, 5. Nov. 2018 (CET)

Letzten Endes wird hier ja auch nur über die standardmäßige Hervorhebung abgestimmt. Am Ende steht es jedem (stimmberechtigten) Benutzer frei, die Hervorhebung über ein eigenes CSS so zu gestalten, wie es ihm am ehesten zusagt. ;) ~ Taisuke ^Diskussion 21:04, 5. Nov. 2018 (CET)

Wurde schon die Möglichkeit von farblich markierten Hochstellungen gesprochen? Ist nicht so krass, wie wenn der gesamte Titel farbig wäre, aber auffällig genug, als dass es ins Auge springt. ~ TiMauzi 21:07, 5. Nov. 2018 (CET)

Wenn wir diese Markierung flächendeckend einführen, dann wäre ich sehr für eine Lösung, die die Position des Textes unverändert lässt. Wie Ryu bereits erwähnt hat, die Lösung mit den hochgestellten Kürzeln vergrößert zum einen die Zeilenhöhe und verschiebt den Text dahinter natürlich nach rechts. Ich fände es ungünstig, wenn viele Artikel für alle stimmberechtigten Benutzer ein anderes Textbild haben als für normale Leser. – shadowtweaker 18:09, 6. Nov. 2018 (CET)

Sehe das genauso wie shadow. -- Liebe Grüße, Moltres 20:40, 6. Nov. 2018 (CET)

Ich denke, ich werde mich enthalten. Ich bin mit keiner der Varianten zufrieden. Kursiv nicht, weil es zu Verwechslungen führen kann. Hochgestellte Kürzel, da versteh ich Shadows Begründung. Farbig, naja, hängt evtl. von der Wahl der Farbe ab, aber das könnte zu bunt werden. Das Isso 08/15 ^Konter 20:54, 6. Nov. 2018 (CET)

Wie sieht der Link denn aus, wenn die Linkfarbe bereits geändert ist, beispielsweise durch einen Link, der von einer Vorlage erzeugt wird? Luca12379 ^Diskussion 22:16, 6. Nov. 2018 (CET)

Zu bunt? Sollte es nicht Ziel sein, Weiterleitungen, die einem so auffallen, zu beseitigen? Verstehe also das Problem nicht so ganz. --Shin no tatakai wa, korekara da. The true fight is yet to come. JustRotty 12:10, 7. Nov. 2018 (CET)

Bei normalen Links funktioniert alles wie gewohnt, bei Links, die über Klassen verändert wurden sowie Links, die ihre Farbe von einem höher gestellten Element erben, funktioniert das ganze ebenfalls, bei Links die jedoch über [[Linkziel|<span style="color: #000000;">Link</span>]] gefärbt wurden, wird das ganze wahrscheinlich eher nicht funktionieren, da diese die Farbe von einem höheren Element erben würden, gleichzeitig den Wert von diesem aber überschreiben. Bin mir also nicht sicher, ob wir da was machen können, vielleicht weiß da jemand etwas, der etwas mehr Ahnung von css hat als ich. Im übrigen ist das Ziel nicht, alle Links auf Weiterleitungen zu entfernen, sondern alle Links auf Begriffsklärungsseiten zu entfernen. Weiterleitungen wären nur nebenbei mit drin, sodass diese ggf. ausgebessert werden können, wenn ein Artikel ohnehin bearbeitet wird. Eine genaue Erklärung wäre später auch noch auf der Seite der Stimmberechtigen Bentuzer zu finden, damit dort keine oder möglichst wenig Verwirrung entsteht. Im übrigen würde eine Formatierung in Kursiv das Markieren von Weiterleitungen ohnehin ausschließen, da diese sonst nicht von Begriffsklärungslinks zu unterscheiden wären. -- RobbiRobb 13:21, 7. Nov. 2018 (CET)

Mir ging es nicht darum, das es zu bunt werden würde, sondern darum, um es technisch überhaupt umsetzbar ist. Wenn die anders gefärbten Links für Probleme sorgen würden, würde ich die hochgestellten Kürzel bevorzugen, da es aber anscheinend funktioniert, ist die geänderte Linkfarbe meiner Meinung nach auffälliger. Luca12379 ^Diskussion 21:38, 9. Nov. 2018 (CET)

Gemäß dem Wunsch der (knappen) Mehrheit habe ich jetzt hochgestellte Kürzel für alle SBs eingerichtet, sollte sich herausstellen, dass das eine wirklich schlechte Entscheidung war, können wir das gerne nochmal absprechen. Sollte jemand für sich selbst damit unzufrieden sein, kann er die Anzeige natürlich weiterhin überschreiben, die Verwendung von !important ist hierbei entscheidend ^^ Wenns Probleme gibt, kann ich natürlich auch gerne Hilfestellung leisten, damit hier auch alle zufrieden sind. Und abschließend noch ein Ping an alle SBs (@Buoysel, CLina, GoPika, Impoleon xy, Isso08-15, Jones, Kenaz-Hagalaz, Killuu, Korvel1, Lombrero, Loxi-kun, Luca12379, Matze, Maxmiran, Mecanno-man, Moltres, Pk-fan, RobbiRobb, Ryuichi, shadowtweaker, ShortyBuzz, Simonsees, Snackhound, Taisuke, Yinni, AAWiki, Cliffichen, DarkViper, Der Sternendiamantritter, Esteror, FloRyan, Friedrich on ice, Hydrokyu, Ige, Jasuanti, JoshOt, JustRotty, Mario-WL, Mega Glurak Y, Michelle, Pintauranimus, Pokénator, Schiggy91, Skelabra2509, Snowy Dragons, SwowoJonny, TiMauzi, TM Master, Tyber, Yrel:), die ich bitten würde, diesen Abschnitt zu lesen, um Missverständnisse und unnötige Edits vorzubeugen. Ansonsten ist es das aber von meiner Seite ^^ -- RobbiRobb 21:16, 20. Nov. 2018 (CET)

Neues Design für Komplettlösungen

Während des eben beendeten Chattreffens wurde mehr oder weniger beschlossen, dass die Komplettlösungen in naher Zukunft gemäß eines solchen Vorschlags umstrukturiert werden. Da das Design vielfach auf Anklang stieß und vor allem die ewig andauernde Problematik mit den unvollständigen und falschen Komplettlösungen damit aus der Welt geschaffen würde, möchte ich dieses Design zeitnah umsetzen. Um hier aber allen, auch denen, die nicht am Chattreffen teilnehmen konnten, die Möglichkeit zu geben, sich dazu zu äußern, besteht jetzt die Möglichkeit, bis Sonntag den 04.11.2018 um 23:59:59 sich dagegen auszusprechen oder Verbesserungsvorschläge einzubringen, bevor das ganze dann umgesetzt wird. -- RobbiRobb 22:15, 21. Okt. 2018 (CEST)

Ein Vorschlag: Wäre es nicht sinnvoll, mithilfe von Toggles optional die Möglichkeit zu geben, einen Fließtext zu bestimmten Unterpunkten ausklappen lassen zu können? Auf diese Weise könnten bei Bedarf genauere Informationen zum Spielverlauf eingefügt werden (also in Richtung der "klassischen" Komplettlösungen), ohne dass die neue Übersichtlichkeit verloren ginge.

Am Beispiel "Lili’i":

Unausgeklappt:

• Kampf gegen Rivalen

Ausgeklappt:

• Kampf gegen Rivalen

"Ihr begegnet Tali zunächst an Ort xy. Dort fordert er euch nach Erhalt des ersten Pokémon zu einem Kampf heraus. Tali besitzt dabei jeweils das Pokémon, welches eurem unterlegen ist. Hierbei solltet ihr beachten, dass [...] Eine gute Strategie ist [...] Als Belohnung erhaltet ihr [...]"

Allein mit Stichpunkten geht das Wesen einer Komplettlösung in meinen Augen ein wenig verloren. ~ TiMauzi 00:07, 22. Okt. 2018 (CEST)

Möglich wäre das schon, aber dann stehen wir wieder vor dem klassischen Problem: Wer will die Texte schreiben? Wenn du dich dazu bereits erklärst, das für alle Komplettlösungen zu machen, können wir diese Idee gerne weiter verfolgen, andernfalls sehe ich aktuell keine Chance, dass das in den nächsten 20 Jahren erledigt wird. Bisher hat sich schließlich auch niemand dazu bereit erklärt, die aktuellen Komplettlösungen zu überarbeiten, wäre dies geschehen, hätten wir überhaupt nichts am System ändern müssen. Ich werde jedoch definitiv keine solche Texte schreiben. Oh und btw, das "du" oder "ihr" will ich da auf keinen Fall sehen, wir sind ein Wiki -- RobbiRobb 01:17, 22. Okt. 2018 (CEST)

Daher spreche ich von optional. Also standardmäßig nur Stichpunkte, bei gegebenen Anlässen gern mit Fließtextergänzung (wichtige Storyelemente bspw.). Und mit dem "du" stimme ich dir voll und ganz zu, das stört mich selbst immer, war halt bei den Komplettlösungen bisher so üblich, daher habe ich das im Beispiel übernommen. ~ TiMauzi 01:38, 22. Okt. 2018 (CEST)

Einzig was man noch schauen müsste ist ob es alternativen zum Whitespace gäbe. Aber ansonsten befürworte ich die Änderung. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 12:41, 22. Okt. 2018 (CEST)

Kannst du genauer erläutern, was du mit "Whitespace" genau meinst? ~ TiMauzi 14:50, 22. Okt. 2018 (CEST)

@TiMauzi, weis jetzt nicht so recht was ich da erklären sollte. Halt die weiße Fläche an der rechten Seite siehe Testwiki Gruß * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 14:55, 22. Okt. 2018 (CEST)

Buo hat hierzu was auf Discord geschrieben, was auch meine Meinung widerspiegelt. Ich zitiere ihn einfach mal "Die Idee mit den Flowcharts finde ich ganz gut, so wird es teilweise ja auch in den offiziellen Guides dargestellt – mit Seitenzahlen für die Detailseiten. Dann wäre es auch übersichtlicher und man würde als User die gesuchten Informationen schnell erhalten. Denn irre viel Text mag heutzutage bei Komplettlösungen glaub ich kaum noch jemand lesen. Man sollte bei uns aber trotzdem darauf achten, dass jedes Rätsel/Puzzle im Spiel dann aufgelistet und in den verlinkten Artikeln auch mit Lösung vorhanden ist. *thumbsup-Emoticon*" Gerade natürlich der letzte Satz ist wichtig, dass die verlinkten Artikel vor der Umstellung natürlich alle relevanten Aspekte aufgreifen. Ich finde auch TiMauzis Vorschlag nicht schlecht, würde aber eventuell da nur Stichpunkte schreiben. Also bei einem Kampf nochmal grob das Team angeben (z.B. nur Pokémon mit Level) oder andere wichtige Sachen à la "wird durch Erhalt von xy freigeschaltet" oder sowas. Ich hoffe, ihr versteht, was ich meine. Halt nochmal in Superkurzform das Allerallerwichtigste. Auch wie Ryu finde ich den Whitespace nicht so wirklich hübsch. Ich frage mich, ob man hier kleine Bildchen der Orte einfügen könnte oder halt vielleicht die von Berdl vorgeschlagenen Zusammenfassungen. Lg --Klein, aber fein. Killuu 15:03, 22. Okt. 2018 (CET)

Je länger ich darüber nachdenke, desto schlechter gefällt mir irgendwie die Idee mit den Fließtexten dadrin. Schließlich sollen ja direkt bei dem Link Fließtexte, die die Handlungen an diesem Ort zusammenfassen, stehen, die Vorlage verlinkt ja schon automatisch auf den Abschnitt. Jetzt also nochmal zusätzliche Texte verfassen, für die wir wahrscheinlich keine Ressourcen aufbringen können, finde ich geht irgendwie wieder weg von dem eigentlichen Flowchart, dann kann man nämlich, speziell Texte wie im Beispiel, bei so ziemlich jedem der Punkte listen.

Im Bezug auf die Bilder kann ich im Moment nur sagen, dass es sich technisch wahrscheinlich nicht realiseren lässt, da die ganze Seite eine einzige Tabelle ist, Bilder rutschen unterhalb der Box und zerstören damit den "Fluss" des ganzen, ich fürchte da müssen wir uns also was anderes einfallen lassen... -- RobbiRobb 17:12, 22. Okt. 2018 (CEST)

Fliesstexte und Teams finde ich da jetzt ehrlichgesagt auch nicht so toll, da sich das dann wieder mit den Artikeln doppelt. Ich hätte dafür gerne etwas mehr Stichpunkte, damit das nicht so leer wirkt (à la „Durchquer das Erzelingen-Tor“) - auch wenn das keinen wirklich brauchbaren Inhalt vermittelt, sowie Tipps, z. B. für nützliche Items (iwie TM Donnerblitz oder so), oder besondere Sachen auf die man in Kämpfen aufpassen sollte (Achtung, Garados kann Erdbeben!), die Tipps womöglich per Toggle ausklappbar (wobei man da aufpassen sollte nur einen Toggler aufzuklappen und nicht alle... ) --Mecanno-man^Mäh 19:58, 22. Okt. 2018 (CEST)

Im wesentlichen +1, ich finde aber nicht wirklich, dass nicht storybezogene Punkte (Kämpfe, Fundorte) da was zu suchen haben. -- Skelabra2509 (Diskussion | Beiträge) 02:18, 23. Okt. 2018 (CEST)

Hey, ich melde mich mal auch zu Wort. Ich denke ebenfalls wie Ryu, dass der Whitespace igrendwie gefüllt werden sollte (also nicht mit sinnlosen Bilder, die ja, wie Robbi schon sagte, unter die Tabelle rutschen), da er den Artikel, Weiterleitung, was auch immer, leer wirken lässt. Vielleicht reicht ja auch schon ne Zentrierung in die Mitte. Die Fließtexte würde ich tatsächlich auch raus lassen (siehe genannte Gründe oben). Ich denke das die Stichpunkte reichen würden, da sie nur einem einen kleinen Überblick verschaffen sollen. Aber ich bin auf jeden Fall für Flowcharts. ~ noch ein schönen Tag ^^ ~ DarkViper 19:58, 23. Okt. 2018 (CEST)

Ich hab nix dagegen einzuwenden, solange das Wesentliche zu finden ist. Z.B. "Du benötigst die Schiggykanne, um gegen Mogelbaum zu kämpfen." (Ich weiß noch, wie ich die lange gesucht habe.) oder "Zum nächsten Ort kannst du erst, wenn du das und dies getan hast." Das fände ich noch hilfreich, natürlich kurz gefasst. Details kann man immer noch nachschauen (Wo ist diese Kanne...). Gegen den Whitespace habe ich keine wirklich ansprechende Idee, evtl. statt eine weitere Verzweigung nach rechts eine nach unten machen; oder evtl. Lösungsbilder von Labyrinthen statt in den Artikeln in die KL. Nur wenn man das als sinnvoll erachtet. Das Isso 08/15 ^Konter 20:17, 4. Nov. 2018 (CET)

Da es hier im Grunde keine Gegenstimmen gab sondern nur einzelne Wünsche nach Erweiterungen, die man am besten in Fallentscheidungen klären kann, würde ich sagen, dass wir das ganze erstmal so beschließen. Da die Umsetzung jedoch vom Orte-Projekt abhängt, da diese die verlinkten Handlungen verfassen, ist es aktuell leider unmöglich, direkt alle Komplettlösungen zu erneuern, ich denke allerdings, dass dies mit der Zeit möglich sein wird. Zunächst werden wir einfach die umsetzen, bei denen die Handlungen bereits existieren - also SoMo und USUM in Alola - und dann mit der Zeit weitere Seiten erneuern. -- RobbiRobb 20:23, 5. Nov. 2018 (CET)

Mit meinen Stichpunkten meinte ich genau das, was jetzt Isso beschrieben hat. Danke fürs besser beschreiben. Sowas finde ich halt doch extrem wichtig. Lg --Fliegen bis zum Horizont. Killuu 15:32, 7. Nov. 2018 (CET)

Optionales nach der Liga

Ich möchte an dieser Stelle gerne nochmal etwas weiter gehen und das Design der Handlung nach der Hauptstory klären. Dass wir natürlich nichts außen vor lassen wollen, was für die Geschehnisse relevant ist, dürfte klar sein. Bleibt allerdings die Frage, wie wir es angeben wollen. Meine Idee wäre spontan einfach eine Überschrift zu setzen, die Hauptstory und Nebenhandlung voneinander trennt und dann einfach das Flowchart fortführt. Ansonsten müsste ich mir was einfallen lassen, wie man alles optionale nach der Liga optional an die Liga anhängt und da habe ich ehrlich gesagt nicht so unglaublich viel Lust drauf. Abgesehen davon würde mich interessieren, wie ihr dazu steht, bei den Orten anzugeben, dass dort ein Legendäres Pokémon zu fangen ist. Sollten wir das immer machen? Das dürfte die Leser neben der Handlung noch am ehesten interessieren, oder? -- RobbiRobb 22:07, 5. Dez. 2018 (CET)

Redesign des Icons Exzellent

Entscheidung: Version Zwei (6 Stimmen Version Eins, 16 Stimmen Version Zwei, 0 Stimmen Version Drei, 12 Stimmen Version Vier)

Diese Abstimmung dient der Entscheidung, welches Icon wir für die Auszeichnung Exzellenter-Artikel wir wollen. Die Abstimmung wurde im Chattreffen vom 21. Oktober beschlossen. Für die Möglichkeiten bitte in der Entsprechenden Tabelle schauen. Jeder stimmberechtigte Benutzer kann eine Stimme abgeben. Die Abstimmung läuft bis am 05.11.2018 um 13:00. Heute ist der 28.04.2024 15:46 Uhr.

Versionen

Version	1	2	3	4
Icon

Version 1

1. Friedrich on ice^❄ 15:43, 22. Okt. 2018 (CEST)
2. SwowoJonny 16:52, 22. Okt. 2018 (CEST)
3. AAWiki ^Diskussion 19:26, 22. Okt. 2018 (CEST)
4. Cliffichen ^Diskussion 20:34, 22. Okt. 2018 (CEST)
5. Auf dem Handy wirkt alles etwas anders, deshalb entscheide ich mich farblich für nicht zu hell, nicht zu dunkel und nicht zu Bronze. Das Isso 08/15 ^Konter 20:56, 22. Okt. 2018 (CEST)
6. Isso hat recht. Auf dem Handy sieht man eindeutige Unterschiede. Ich denke auch, dass dieser hier am Angenehmsten für die Leute ist. ~ noch ein schönen Tag ^^ ~ DarkViper 07:01, 24. Okt. 2018 (CEST)

Version 2

1. Version 3 erinnert mich zu sehr an Bronze und Version 4 an Messing. — mfg ^Snack_hound 15:03, 22. Okt. 2018 (CEST)
2. --  TM Master  16:05, 22. Okt. 2018 (CEST)
3. --×Impoleon xy× 16:19, 22. Okt. 2018 (CEST)
4. Eine schöne, hell-goldene Farbe! -MfG, Kenaz-Hagalaz ^Disku 19:23, 22. Okt. 2018 (CEST)
5. FloRyan ^Diskussion 19:50, 22. Okt. 2018 (CEST)
6. Eins ist zu orange, vier sieht angelaufen aus, von drei reden wir nicht. --Mecanno-man^Mäh 20:26, 22. Okt. 2018 (CEST)
7. ~ Taisuke ^Diskussion 20:44, 22. Okt. 2018 (CEST)
8. Simonsees ^[Diskussion] 23:55, 22. Okt. 2018 (CEST)
9. Sehe ich wie Mecanno-man. --mfG Lombrero ^Dis 10:51, 23. Okt. 2018 (CEST)
10. Michelle ^o° 19:19, 23. Okt. 2018 (CEST)
11. Maxmiran 07:50, 24. Okt. 2018 (CEST)
12. Korvel1 ^Diskussion 08:24, 26. Okt. 2018 (CEST)
13. ~ TiMauzi 18:51, 26. Okt. 2018 (CEST)
14. Yrel (Diskussion) 10:00, 28. Okt. 2018 (CET)
15. -- RobbiRobb 14:09, 29. Okt. 2018 (CET)
16. Buoysel 12:50, 5. Nov. 2018 (CET)

Version 3

Version 4

1. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 12:35, 22. Okt. 2018 (CEST)
2. Klein, aber fein. Killuu 14:54, 22. Okt. 2018 (CET)
3. Ige64 ^Diskussion 16:31, 22. Okt. 2018 (CEST)
4. -- Liebe Grüße, Moltres 17:20, 22. Okt. 2018 (CEST)
5. -- Skelabra2509 (Diskussion | Beiträge) 02:16, 23. Okt. 2018 (CEST)
6. -- Grüße ShortyBuzz 10:49, 23. Okt. 2018 (CEST)
7. -- Luca12379 ^Diskussion 21:13, 23. Okt. 2018 (CEST)
8. --Shin no tatakai wa, korekara da. The true fight is yet to come. JustRotty 23:33, 23. Okt. 2018 (CEST)
9. Wirkt meiner Meinung nach am realistischsten. 1 ist zu rötlich und 2 wäre mir eher zu weiß.--❄❄ Pk-fan 15:39, 24. Okt. 2018 (CEST)
10. CLina 8:31, 26. Okt. 2018 (CEST)
11. Mega Glurak Y (Diskussion) 22:54, 27. Okt. 2018 (CEST)
12. JoshOt ^{Lecker Gummibärchen} 23:02, 27. Okt. 2018 (CEST)

Kommentare

AAWiki, DarkViper, Der Sternendiamantritter, Esteror, Flonc, FloRyan, Friedrich on ice, Hydrokyu, Ige64, Jasuanti, JustRotty, Mario-WL, Michelle, Pintauranimus, Pokénator, Schiggy91, Skelabra2509, Snowy Dragons, SpielefreakJ, SwowoJonny, TM Master, Tyber, Buoysel, CLina, GoPika, Impoleon xy, Isso08-15, Jones, Kenaz-Hagalaz, Killuu, Korvel1, Lombrero, Loxi-kun, Luca12379, Matze, Maxmiran, Mecanno-man, Moltres, Pk-fan, RobbiRobb, Ryuichi, shadowtweaker, ShortyBuzz, Simonsees, Snackhound, Taisuke, Yinni. Gruß * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 12:35, 22. Okt. 2018 (CEST)

Wie werten wir das eigentlich am Ende aus? Mit relativer Mehrheit oder mit Stichwahl? Angesichts der Wahlsituation kommt mit letzteres sinnvoll vor. -- Skelabra2509 (Diskussion | Beiträge) 02:19, 23. Okt. 2018 (CEST)

Ich habe erst im Nachhinein die Icons in "Action" gesehen, daher habe ich meine Stimme noch einmal geändert! ~ TiMauzi 18:51, 26. Okt. 2018 (CEST)

Kurze Anmerkung meinerseits: Den Link ins Testwiki, wo ich die Icons schonmal testweise in die Vorlage eingefügt hatte, ging aufgrund eines Missverständnisses meinerseits davon aus dass die Vorlage unverändert bleibt - wird sie aber nicht. Im Moment ist angedacht nur das Icon anzuzeigen, ohne umliegenden Farbcontainer. Bei allen die sich darauf belassen haben möchte ich mich für das Missverständnis entschuldigen. --Mecanno-man^Mäh 00:08, 27. Okt. 2018 (CEST)

Zur Kenntniss genommen ;) Wäre es dann trotzdem möglich, mal ein Beispiel zur Anwendung der ganzen Sache zu sehen? Ich glaube, das wäre wirklich interessant! ~ TiMauzi 01:24, 27. Okt. 2018 (CEST)

[Abstimmung] Mitgliederwerbung durch „Stellenanzeigen“

Diese Abstimmung ist vorbei. Die meisten Stimmen erhielt die Pro-Option. Somit wurde der Bedarf einer Stellenanzeigen-Box geklärt. Die Diskussion zu deren Gestaltung findet auf PokéWiki:Allgemeine Diskussionsseite#Gestaltung der Stellenanzeigen/Ausschreibungen statt.

Diese Abstimmung ist vorbei. Die meisten Stimmen erhielt die Pro-Option. Somit wurde der Bedarf einer Stellenanzeigen-Box geklärt. Die Diskussion zu deren Gestaltung findet hier statt.

Hallo zusammen!
Wie bereits im Chattreffen angesprochen, kam ich auf eine Idee, wie wir gezielter und dadurch möglicherweise effizienter neue Mitglieder werben oder bereits registrierten Mitgliedern Arbeit vermitteln könnten.
In Schriftgesprächen mit neuen Mitgliedern und denen, die es werden möchten, höre ich immer wieder die gleichen Fragen: Was kann man denn machen? Werde ich denn überhaupt gebraucht? Gibt es denn irgendwo Seiten mit Aufgaben?
Es scheint als würden To-do-Listen und Missionsbrett sowie andere Seiten unseres Navigations-Menüs nicht gut genug wahrgenommen werden. Dies in Kombination mit dem Gefühl von Zwecklosigkeit bei potenziellen Neumitgliedern führt dazu, dass diese sich gar nicht erst registrieren oder von der Fülle der Aufgaben überwältigt sind. Um diesen Umständen entgegenzuwirken halte ich folgenden Vorschlag für diskussionswürdig: PokéWiki-Stellenanzeigen
Für diese sollte ein Platz auf der Hauptseite freigemacht werden, in welchem dann eine Box mit kurzen Beschreibungen dessen steht, was derzeit am dringendsten gesucht wird: z. B. Mitglieder für das Manga-Projekt gesucht oder Autoren für Inhaltsangaben gesucht. Zusätzlich sollen sich direkte Links zu der globalen To-do-Liste und zum Missionsbrett in dieser Box befinden. Diese Box wäre somit eine schnelle Orientierungshilfe, wenn es um akute Aufgaben des Wikis geht. Dinge, wie genaues Aussehen der Box und die verwendeten Begriffe, lasse ich natürlich offen. Beispiele für diese Idee können auf einer meiner Unterseiten eingesehen werden.
Ich hoffe, mein Vorschlag erscheint sinnvoll und hilfreich! -MfG, Kenaz-Hagalaz ^Disku 15:01, 23. Okt. 2018 (CEST)

Zunächst einmal möchte ich festhalten, dass mir der Gedanke sehr gut gefällt. Seit Jahren zeichnet sich der Usermangel bei uns ab, auch andere Internet-Communities, die ähnliche Ziele verfolgen erfahren ein ähnliches Phänomen, dass zwar alle Nutzer Informationen haben wollen, aber nur die wenigsten auch wirklich bereit sind, an Missständen etwas zu ändern. Und selbst wenn diese Hemmschwelle überschritten ist, stehen viele noch vor dem Problem, dass du dann ansprichst: Das fehlende Wissen, wo man helfen kann. Für uns mag es teilweise schwieriger zu verstehen sein, als für Anfänger, ich kann jedoch nur speziell für mich sprechen und sagen, dass ich es beim besten Willen nicht wirklich nachvollziehen kann. Zugegebenermaßen hatte ich am Anfang auch Probleme, mich zurecht zu finden, alles außerhalb des Artikelnamensraum war mir absolut fremd, ich wusste nicht, wie ich irgendwas anderes, ganz davon abgesehen, dass ich vom meisten nicht einmal wusste, dass es existiert. Mittlerweile weiß ich zwar von bspw. der To-Do oder vergleichbarem, wo man es findet, aber mir ist auch bewusst geworden, dass wir nicht unbedingt schlecht darin sind, unsere Defizite offen zu zeigen, sodass sie leicht zu sehen sind. Alle Wartungsbausteine sind auch für unangemeldete Benutzer sichtbar, man muss also lediglich auf einer der tausend Seiten sein, auf der einer eingebunden ist, um zu sehen, dass noch etwas fehlt. Tatsächlich scheint es auch immer mal wieder neue Nutzer zu geben, die dann den dort stehenden Aufrufen folgen - wie man jedoch auf der Seite der Stimmberechtigten Nutzer sehen kann, bleiben jedoch die wenigsten länger als die ersten paar Edits. Da frage ich mich dann, ob es bei ihnen genau das selbe Problem ist wie bei denen, die garnichts für ihren ersten Edit finden. Sind unsere Wartungsbausteine vielleicht doch nicht auffällig genug? Machen wir nicht prominent genug auf unseren Seiten auf Defizite aufmerksam? (Eine von dir vorgeschlagene Box auf bspw. der Hauptseite könnte zum Beispiel helfen) Oder haben die Leute doch oftmals eigentlich keine Lust, aktiv zu helfen und legen lieber nur einen Account an, um einen zu haben? In jedem Fall zeigt sich der Usermangel, der in den vergangenen Jahren doch eher etwas in den Hintergrund getreten ist, in der letzten Zeit wieder verstärkt ab, da viele Nutzer von höherrangigen Posten zurückgetreten sind. Daher wäre es natürlich sehr willkommen, wenn man mehr neue Nutzer gewinnen würde und gleichzeitig vielleicht sogar langjährige Baustellen, auf die speziell aufmerksam gemacht wird, zu erledigen. Allerdings bin ich doch etwas besorgt, da vor allem die Punke, die du dort auf deiner Liste hast, auch nichts neues sind. Seit Jahren hat sich niemand gefunden, der sich um diese Artikel kümmert, obwohl teilweise Missstände nicht schwer zu erkennen sind oder sogar aktiv auf sie aufmerksam gemacht wird (Wartungsbausteine in Artikeln). Letzten Endes ist also der Erfolg einer solchen Werbung fraglich. Das heißt keinesfalls, dass ich grundsätzlich dagegen bin, aber bisher sehe ich noch nicht den Erfolg, den man sich damit vielleicht erhofft, lasse mich aber sehr gerne eines besseren belehren ^^ -- RobbiRobb 21:01, 23. Okt. 2018 (CEST)

Ich würde solche Stellenanzeigen eindeutig befürworten. Um dies zu erkläre, würde ich mich selbst als Beispiel nehmen. Als ich vor ca. 1,5 Jahren mal wieder irgendetwas im Wiki nachschauen wollte, wusste ich nicht einmal ansatzweise, dass es den Strategie-Bereich gibt. Ich habe zwar schon häufiger die "Stratgischer Nutzen"-Abschnitte bei Fähigkeiten gesehen, von den Strategie-Artikel an sich wusste ich aber nichts. Dann hab ich auf der Hauptseite auf einem Banner gelesen, dass "Strategie-Experten" gesucht werden. Daraufhin hab ich mich mit dem Projekt auseinander gesetzt, meine ersten Strategie-Artikel geschrieben, bin dem Discord gejoined und bin jetzt hier angekommen. Was ich damit sagen will: Ich kann es mir gut vorstellen, dass viele Nutzer gar nichts von vielen "Randbereichen" des Wikis wissen. Die meisten Nutzer werden wohl von den Pokémon-, Item-, Attacken- oder Orte-Artikeln wissen, aber Manga- und Anime-Artikel könnten schon wieder unbekannter sein. Und genau da könnten solche Stellenanzeigen helfen. Sie können Leuten, die noch nicht wissen, dass sie dem Wiki in ihrem Fachgebiet helfen können, zeigen, was sie machen können. Selbiges erlebe ich auch, wenn ich anderen mitteile, dass ich an Strategie-Artikeln arbeite. Viele Personen, die sich sehr gut mit strategischen Kämpfen auskennen, benutzen das Wiki tagtäglich, ohne zu wissen, dass sie ihre Kenntnisse verbreiten könnten. Stellenanzeigen sind meiner Meinung also sehr sinnvoll, da ich aus eigener Erfahrung bestätigen kann, dass viele Nutzer des Wikis nicht wissen, dass sie ihre Fachkenntnisse ins Wiki einbringen können. Luca12379 ^Diskussion 21:35, 23. Okt. 2018 (CEST)

Ich finde, erstmal sollten der geplante Ausbau des Missionsbrett getätigt und evaluiert werden. Weiter ist für mich ein Hauptpunkt die schlechte Menü, da man da nicht sofort die Punkte findet... --Mecanno-man^Mäh 22:05, 24. Okt. 2018 (CEST)

Danke für eure Rückmeldungen! Ich denke auch, dass das Missionsbrett und ggf. die globale To-do-Liste (sofern nötig) zu allererst verbessert gehören, soweit dies beschlossen wurde. Denn immerhin soll die Stellenanzeigen-Box ja auch permanent auf diese verlinken. Beim Menü sehe ich weniger das Problem darin, dass es „schlecht“ ist (auch wenn man die Seite Mitmachen noch hinzufügen sollte), sondern darin, dass es versteckt ist. Wenn es die Leute nicht sofort sehen, ist es oft aus dem Sinn. -MfG, Kenaz-Hagalaz ^Disku 17:38, 26. Okt. 2018 (CEST)

Mitmachen: ✔ -- RobbiRobb 18:04, 26. Okt. 2018 (CEST)

Ich merke schon, ich schreibe im Moment nicht detailliert genug: Das war was ich mit schlecht gemeint hatte - man sieht es schlecht. --Mecanno-man^Mäh 00:08, 27. Okt. 2018 (CEST)

Das ganze erinnert mich doch an eine Diskussion, die ich vor fast 2 Jahren schon mal angestoßen habe. Die ist irgendwie auf dieser dieser Unterseite versumpft. Von daher finde ich die Idee allgemein gut, über die exakte Ausführung lässt sich natürlich noch diskutieren. Lg --Fliegen bis zum Horizont. Killuu 15:43, 7. Nov. 2018 (CET)

Stimmt, Killuu! Dein Vorschlag war damals schon wichtig und wurde leider nicht weiterbearbeitet. Wir brauchen in einer Zeit des Nutzermangels einfach neue Anreize und neue Formen der Tätigkeitsvermittlung. Ich finde, konkrete Kurzbeschreibungen von besonders verlangten Stellen (wie eben auf meinen Text-Anzeige-Boxen) sind dazu das beste Mittel. Wenn wir aber allgemein für eine aktive Mitgliedschaft werben, mit Vorteilen, wie Aufstiegschancen etc. dann geht am wirksamsten im obersten Banner, in dem auch unser Logo steht und auch Infos zu den VBWs standen, denn das ist immer da, auch wenn die Leute nicht die Hauptseite betrchten. -MfG, Kenaz-Hagalaz ^Disku 00:59, 2. Mär. 2019 (CET)

Also, die Idee finde ich super! Ich fände es wichtig, dass es kleine Aufgaben sind die konkret und einfach formuliert sind. Quasie wie Quests... Damit kommt jeder einfach klar... Mesmanuel87 (Diskussion) 16:28, 5. Mär. 2019 (CET)

Ich stimme Mesmanuel187 zu, aber ich würde noch was hinzufügen. Sie sollten auch schnell auffindbar sein, weil beispielweise sind die To-Dos schwer auffindbar für einen Neuling. Hoffe ich konnte was beitragen. RioMaster 16:38, 5. Mär. 2019 (CET)

Ich finde die Idee sehr gut, besser/stärker auf Defizite im Wiki hinzuweisen und damit auch "Nicht-Wikingern" stärker zu zeigen, dass wir mehr Mitarbeiter benötigen. Als Beispiel nehme ich mal mich, da ich das als recht passend ansehe^^. Ich habe jahrelang das Wiki benutzt und ab und zu auf der Hauptseite gelesen, dass Wikinger gesucht werden, hab aber nie wirklich darüber nachgedacht. Mir ist eine fehlende Information zum ersten Mal mit LGPE wirklich aufgefallen, was dann auch zu meiner Anmeldung und meinem ersten Edit geführt hat. Ich denke, dass Leute einen stärkeren Anreiz als "Wir suchen dich!" brauchen um sich zu entscheiden im Wiki mitzuarbeiten und hier Zeit zu investieren.-- DeXter 16:43, 5. Mär. 2019 (CET)

Eine kleine kurze Aufgabe, die sich zB auf einen bestimmten Abschnitt bezieht ist auch wenig abschreckend. Dann denkt sich jemand vielleicht "Das weiß ich und die 10 min habe ich" Anstatt das man sich erst in den Artikel einlesen muss um zu gucken was fehlt. Die Aufgabe Bearbeite im Schiggy Artikel die Fundorte mit Wahrscheinlichkeit von LGPLGE ist klar und schnell gemacht. Im To-Do steht Anime Projekt Fehlende Episodenhandlung,aber welche Episoden... Da muss man schon nachfragen... Mesmanuel87 (Diskussion) 16:52, 5. Mär. 2019 (CET)

Da muss ich auch sagen, dass bei manchen Projekten die To-Do-Listen fehlen. Da ist es tatsächlich schwer was raus zu kristallisieren, was fehlt. RioMaster 17:03, 5. Mär. 2019 (CET)

Danke für eure Rückmeldung! Konkrete Aufgaben mit Kurzbeschreibung haben wir bereits im Missionsbrett. Missionsbrett-Aufgaben sollen in der "Anzeigen-Box" nicht direkt stehen, aber es soll sich ein direkter Link zum Missionsbrett in ihr befinden, so dass man direkt von der Hauptseite ohne Mouseover hinkommt. Die "Anzeigen-Box" ist speziell für allgemein gefasstere Gesuche an Mitarbeitern wie z.B. "Inhaltsangabenschreiber für Anime-Episoden gesucht" enthalten. Die Beispielinhalte auf dieser Seite geben das ganz gut wider: Beispiel-Boxen. Auch ein Direktlink zur zentralen To-do-Liste würde in ihr stehen. Denn die "kurzen" Arbeitsanreize, die ihr erwähnt habt, haben wir eigentlich größtenteils schon, sie werden nur oft nicht gefunden. Doch auch das soll durch die Direktlinks in der "Anzeigen-Box" erleichtert werden. Es wäre natürlich auch gut, wenn alle Projektleiter To-do-Listen oder Prioritätslisten erstellen würden, aber das ist wieder Stoff für eine neue Diskussion. Wir dürfen hier nicht den Fokus verlieren. ;) -MfG, Kenaz-Hagalaz ^Disku 17:07, 5. Mär. 2019 (CET)

Wenn ich Probleme habe eine to-do-Liste zu finden, suche ich in Kategorie:PokéWiki:To-do-Liste. Das zeigt schon, wie schwer diese zu finden sind. Die Listen der Projekte könnten ruhig mit der "Haupt-To-do-Liste" verbunden sein... Oder gar in die Stellenanzeige mit eingebaut werden. Das Isso 08/15 ^Konter 17:14, 5. Mär. 2019 (CET)

Die Idee der Stellenanzeigen gefällt auch mir sehr gut! Wie könnte man den Menü-Knopf denn sichtbarer machen kann, ohne das Design zu zerlegen? Würde bspw. vielleicht ein kleines Icon-Bild (so drei horizontale Linien) neben dem Text „Menü“ helfen? ~ Buoysel 17:18, 5. Mär. 2019 (CET)

Bitte bedenkt, dass es nicht unser Ziel ist, mit einfachsten Aufgaben neue Nutzer anzulocken. Etwas derart simples wie das Eintragen von Fundorten von Pokémon ist auch schon fast zu wichtig, als das man es einfach als Aufgabe im Raum stehen lassen könnte, nur um jemand neuem die Möglichkeit zu geben, etwas zum Wiki beizutragen. Wir haben schließlich auch ein aktives Team, dass sich bemüht, für eine gewisse Vollständigkeit zu sorgen und sowas wie Fundorte der Pokémon gehört da auf jeden Fall zu, sowas wird schon kurz nach dem Erscheinen neuer Spiele erledigt sein. Und genau das ist ja eines der Probleme des Missionsbrettes, die gestellten Aufgaben sind häufig so schwierig oder aufwendig, dass sie eben nicht von einem Mitglied des Teams erledigt werden können, weil diese auch noch andere Aufgaben haben, um die sie sich kümmern müssen. Daher landen dort vor allem Sachen, die schon lange mal erledigt werden müssten, sich aber bisher niemand gefunden hat, der diese übernehmen kann.

Außerdem der Hinweis, dass die Sitenotice nur für besondere Anlässe gedacht ist, etwa die Ankündigung von Gewinnspielen oder Systemupdates, aber auch die Warnung vor Spoilern bei neuen Spielen ist dort zu finden. Mit anderen Worten: sie ist nichts, was permanent da sein soll. Also auch das bitte im Hinterkopf behalten. -- RobbiRobb 17:23, 5. Mär. 2019 (CET)

Ich habe für die "Anzeigen-Box" auch einen Platz auf der Hauptseite angedacht. Die entsprechende Vorlage selbst dürfte man dann ab VB erst bearbeiten, damit PLs Mitgliedergesuche ausschreiben können. Ausschreibungen in die Sitenotice zu packen wäre – und davon bin ich fest überzeugt – zwar effektiver, weil artikelunabhängig vorhanden, aber wie Robbi sagte: Da sollen ja nur temporäre Nachrichten rein und das, was ich vorschlagen möchte, soll permanent sein. Zumindest so lange permanent, wie es Engpässe gibt. Dafür eignet sich die HS sehr gut. -MfG, Kenaz-Hagalaz ^Disku 17:36, 5. Mär. 2019 (CET)

Hallo liebe Wikinger!
Ich möchte jeden stimmberechtigten Benutzer jetzt die Chance geben, über die Einführung von Ausschreibungen bzw. Stellenanzeigen auf der Hauptseite abzustimmen. Der Bedarf und das Interesse sind da, wie die voran gegangene Diskussion zeigt. Diese Abstimmung soll noch nicht entscheiden, welche Gestalt und genaue Position diese haben werden, sondern nur feststellen, ob diese in ihrem Grundkonzept als kurze Ausschreibungen bezüglich Projekt-Stellen oder besonderer Aufgaben innerhalb einer Vorlage auf der Hauptseite angenommen werden. Beispiele wie diese aussehen könnten, finden sich hier.
Die Abstimmung läuft bis zum 21. März 2019 23:59 Uhr, stimmberechtigt sind alle Stimmberechtigten Benutzer.
-MfG, Kenaz-Hagalaz ^Disku 20:10, 7. Mär. 2019 (CET)

PRO: Für die Ausschreibungen/Stellenanzeigen auf der Hauptseite

1. Für mich auf jeden Fall eine erstrebenswerte Methode, um den Nutzermangel zu bekämpfen. -MfG, Kenaz-Hagalaz ^Disku 20:10, 7. Mär. 2019 (CET)
2. SwowoJonny 20:15, 7. Mär. 2019 (CET)
3. Hab mich ja schon in der Diskussion dazu geäußert. --DeXter 20:35, 7. Mär. 2019 (CET)
4. Genauso wie DeXter habe ich mich schon geäußert. RioMaster 20:38, 7. Mär. 2019 (CET)
5. Die idee ist nicht schlecht nur das richtig einzubauen im jetzigen design wird glaube ich nicht einfach das leute es halt sehen aber es auch nicht im weg ist oder stört Zeynex 20:56, 7. Mär. 2019 (CET)
6. Cliffichen 21:15, 7. Mär. 2019 (CET)
7. Ich finde die Idee sehr gut, um Benutzer und Besucher auf Aufgaben aufmerksam zu machen. Es könnte nur schwierig werden dies umzusetzen, ohne das Hauptseitenlayout zu zerstören. Grüße, Mega Glurak Y (Diskussion) 23:16, 7. Mär. 2019 (CET)
8. Wenn wir das designtechnisch auf die Hauptseite bekommen, bin ich dafür. ~ Buoysel 13:48, 8. Mär. 2019 (CET)
9. Im Prinzip ja. Ich könnte mir einen Kasten noch über Wds vorstellen oder einen länglichen unter Aktuelles. Das Isso 08/15 ^Konter 14:46, 8. Mär. 2019 (CET)
10. Solange es mit dem Design der Hauptseite vereinbar ist, gerne. --  TM Master  15:46, 8. Mär. 2019 (CET)
11. Über die Form lässt sich ja noch streiten ;) --Schöne Träume! Killuu 20:17, 8. Mär. 2019 (CET)
12. Ich finde die Idee gut, solange man sie ordentlich in das Design der Hauptseite integrieren kann. GrollenKette951 22:05, 8. Mär. 2019 (CET)
13. Grungedanke gefällt mir, offen zeigen, wo unsere Probleme sind, könnte durchaus helfen, neue Nutzer anzulocken. -- RobbiRobb 20:31, 11. Mär. 2019 (CET)
14. AAWiki ^Diskussion 13:56, 16. Mär. 2019 (CET)

CONTRA: Gegen die Ausschreibungen/Stellenanzeigen auf der Hauptseite

1. Szenario: Bob ist häufiger im PokéWiki unterwegs und wäre prinzipiell dafür zu begeistern, im PokéWiki mitzumachen. Er liest auf PokéWiki:Mitmachen, dass er sich einfach nur einen Account anlegen muss und wir uns über seine Mitarbeit freuen würden. „Das klingt doch gut!“, denkt sich Bob und legt sich einen Account an. Er liest weiter, dass es eine To-do-Liste und Projekte gibt. Bob schaut manchmal den Pokémon-Anime und erkundigt sich daher über die Aufgabe, Inhaltsangaben für Episodenartikel zu schreiben. Nach einigem Suchen landet er auf dem Artikel einer Anime-Episode, in dem die Inhaltsangabe fehlt. „Aber wie soll ich denn da jetzt eine Inhaltsangabe schreiben?“, fragt sich Bob. „Diese Episode habe ich nicht gesehen. Aber selbst wenn ich sie gesehen hätte, wie soll ich denn eine Inhaltsangabe dazu schreiben? Ich habe die Episode doch nicht auswendig im Kopf. Und woher soll ich überhaupt wissen, wie man eine Inhaltsangabe schreibt? Wie man etwas auf diese Seite einfügen kann, weiß ich auch nicht, da kommt irgendeine Programmiersprache, wenn man auf Bearbeiten klickt. Ach, keine Ahnung, das ist wohl nichts für mich.“ Bob ist verwirrt und entmutigt. „Es muss doch etwas Einfaches geben, was ich machen kann“, meint er. Er gibt nicht auf und fragt auf dem Discordserver nach, was es für ihn zu tun gebe. „Es gibt ganz viel, was du tun kannst, schau mal auf der To-do-Liste“, erhält er als Antwort. „Ja toll, da war ich schon...“, denkt sich Bob. Bob weiß nicht, was er machen könnte, und wendet sich einer anderen Aktivität zu.
   
   Ich sehe es auch so, dass die Wurzel des Benutzermangel-Problems nicht darin liegt, dass niemand Interesse an Mitarbeit im Wiki hat, sondern darin, dass die Leser, die prinzipiell an der Mitarbeit im Wiki interessiert wären, nicht wissen, wie sie sich einbringen können. Deshalb gibt es ja so viele Benutzer, die uns fragen, was sie machen könnten. Die Schlussfolgerung in obiger Diskussion war dann meistens: Unsere To-do-Listen sind lang genug, also wenn wir gefragt werden, was es zu tun gibt, liegt das Problem daran, dass die Leute die To-do-Liste nicht finden. Mit obigem Szenario wollte ich erklären, warum ich mir sicher bin, dass dem nicht so ist; und das trifft natürlich nicht nur auf das Beispiel der Inhaltsangaben zu. Informationen, was es zu tun gibt, sind leicht zu finden (wobei man hier und da noch optimieren könnte, z. B. Mitmachen auf der Hauptseite auch nochmal in Textform verlinken). Das Problem ist vielmehr, dass wir keine Aufgaben haben, die für Neulinge geeignet sind. Die Einstiegshürde ist zu hoch. Wenn wir jetzt auf der Hauptseite schreiben, dass Mitglieder fürs Anime-Projekt oder Inhaltsangaben-Schreiber gesucht werden, dann wird das nur diesen Prozess fördern, dass unsere Leser erfolglos nach einer möglichen Aufgabe suchen. Deshalb von mir in dieser Umsetzung ein Contra gegen Ausschreibungen auf der Hauptseite. Meiner Meinung nach müsste man, um den Benutzermangel effektiv zu bekämpfen, erstmal ein Konzept dafür entwickeln, wie man die Einstiegshürde verringert und welche Aufgaben gut für Neulinge geeignet sind. Dann kann man sich immer noch überlegen, ob man solche Aufgaben auch gut auf der Hauptseite präsentieren kann. :) – shadowtweaker 14:03, 17. Mär. 2019 (CET)
2. Kann mich dem nur anschließen. Die besten Beispiele dafür, dass diese Idee am falschen Ende ansetzt, bietet Discord. Hier fragen häufig User nach, wie sie helfen können, und nicht einmal gelang es, für Neulinge oder auch für bereits länger in der Community seiende User, einen Angriffspunkt zu finden. Die ToDos sind klar, aber man erhält keine Unterstützung und im Gegenteil wird den Änderungen neuer User eher mit Skepsis begegnet. Daran muss eher gearbeitet werden. Maxmiran 17:46, 17. Mär. 2019 (CET)
3. Ich schließe mich meinen Vorgängern auch an. Das Problem ist nicht, dass man nicht weiß, was man tun kann, sondern eher, wie man das Ganze umsetzt. Man hat auch immer Angst Fehler zu machen und weiß auch irgendwie nicht so recht, an wen man sich wenden kann. Also ich denke, dass Stellenanzeigen das nicht besser machen können, weil es dann trotzdem an der Umsetzung scheitert. Michelle ^o° 21:28, 17. Mär. 2019 (CET)
4. Ich ändere meine Stimme dann doch nochmal. Nachdem ich die Beiträge von shadow, Tai und Max gelesen habe, ist mir auch nochmal klar geworden, dass mir die Stellenanzeigen nicht vielversprechend genug sind. Da kann man lieber erfolgsversprechendere Module auf der Hauptseite unterbringen, wie laufende Events, Umfragen oder ein Social Media-Feed.--❄❄ Pk-fan 00:00, 18. Mär. 2019 (CET)
5. Ich hab überlegt ob ich mich enthalten soll, hab mich jetzt aber entschieden mit Contra zu stimmen. Ich finde insbesondere, dass wir bereits ein entsprechendes Programm haben, welches auf den Namen Missionen hört, die zwar ggf etwas optimiert werden könnten (ausformulierter, Zuständigkeiten klarer usw). Evtl könnte man die noch im oberen Bereich verlinken, aber das sollte es da auch schon gewesen sein. Wenn unbedingt was auf die Hauptseite soll, sollte man einfach die Missionen 1:1 auf dieser anzeigen, aber ohne da einen sonstigen Mehraufwand zu beschreiben und selbst da bin ich mir eher unschlüssig (die Gründe wurden schon genannt). Was ich mir eher vorstellen könnte wäre die Nutzung vom Aktuelles-Bereich für abgeschlossene Arbeiten: „Wir bedanken uns herzlich bei Benutzer:XY, welcher die Handlung von Pokémon Aka und Midori stark überarbeitet hat. Du möchtest auch mithelfen? Dann schau doch mal auf unser Missionsbrett!“. Aber das ist schon wieder nen anderes Thema. Jones ^Albtraum? 22:44, 20. Mär. 2019 (CET)

Enthaltung

1. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 20:20, 7. Mär. 2019 (CET)
2. Shin no tatakai wa, korekara da. The true fight is yet to come. JustRotty 21:54, 7. Mär. 2019 (CET)
3. ~ TiMauzi 01:14, 8. Mär. 2019 (CET)
4. Kann mich da Pk-fan in der Argumentation nur anschließen. - - "I'm gonna swing from the chandelier" GoPika ^Disku 10:55, 8. Mär. 2019 (CET)
5. Korvel1 ^Diskussion 10:42, 9. Mär. 2019 (CET)
6. ~ ~ Simonsees ~ 14:16, 13. Mär. 2019 (CET)
7. Ich kann mich weder gegen weitere Bemühungen neue Mitglieder zu werben stellen, da ich sie grundsätzlich unterstütze, noch kann ich mich aber restlos für diese Idee begeistern. Das liegt grundsätzlich an zwei Punkten: a) Für mich ist die Hauptseite nicht die richtige Anlaufstelle, um aktiv neue Benutzer zu werben. Im Normalfall kommen in meinen Augen Besucher über eine Google-Suche auf einen bestimmten Artikel im PokéWiki, finden ihre Information (→ und gehen) oder finden sie nicht und suchen in weiteren relevanten Artikeln, in denen sie mit der gesuchten Information rechnen. Haben sie diese Information am Ende nicht gefunden, gehen sie entweder auf eine andere Fanseite oder melden sich an und fügen nach eigener Recherche den betreffenden Punkt im PokéWiki hinzu. Die Hauptseite sehen sie daher vermutlich nie bzw. erstmalig nach der Registrierung. b) Des Weiteren erhoffe ich mir von einem „Stellenanzeiger“ eher wenig. Lese ich als Besucher des PokéWikis z. B. von der Suche nach einem Inhaltsangaben-Schreiber, glaube ich nicht, dass sich ein einziger Besucher davon angesprochen fühlen werden wird. Auch Fließtext-Schreiber würde einem ähnlichen Schicksal erliegen. Schüler bzw. Studenten, die ich einfach mal als unser Hauptpublikum bezeichnen würde, haben davon in ihrem Alltag zu Genüge, sodass sie das nicht auch noch in ihrer Freizeit freiwillig machen würden. Aus diesen Gründen muss ich mich bei dieser Abstimmung enthalten. ~ Taisuke ^Diskussion 20:36, 16. Mär. 2019 (CET)
8. Ich bin per se nicht dagegen, aber irgendwie kann ich mir keinen großen Effekt auf Neulinge ausmalen. Ich lass mich aber sehr gerne vom Gegenteil überzeugen -- Grüße ShortyBuzz 20:53, 20. Mär. 2019 (CET)

Kommentare

AAWiki, DarkViper, Der Sternendiamantritter, DeXter, Dusk, Esteror, FloRyan, Friedrich on ice, GrollenKette951, Hydrokyu, JustRotty, Lord Racer, Loxi-kun, Mario-WL, Mega Glurak Y, Michelle, Nescientist, RioMaster, Schiggy91, Skelabra2509, SwowoJonny, TiMauzi, TM Master, Yrel, ZeynexBuoysel, Cliffichen, CLina, GoPika, Impoleon xy, Isso08-15, Jones, Kenaz-Hagalaz, Killuu, Korvel1, Lombrero, Luca12379, Matze, Maxmiran, Mecanno-man, Pk-fan, RobbiRobb, Ryuichi, shadowtweaker, ShortyBuzz, Simonsees, Snackhound, Taisuke, Yinni -MfG, Kenaz-Hagalaz ^Disku 20:10, 7. Mär. 2019 (CET)

Ich wollte meine Begründung für eine Enthaltung nicht noch weiter ausführen, weshalb ich hier noch einen Gedanken mit euch teilen möchte, von dem ich mir noch den meisten Nutzen erhoffen würde. Der Knackpunkt des Ganzen ist aber auch, dass er jeden Artikel – der einem Projekt zuzuordnen ist – etwas hinzufügen würde. Und zwar ist mir diese Idee gekommen als ich mich durch ein paar Artikel von Bulbapedia geklickt habe. Diese nutzen am Ende eines jeden Artikels einen Hinweis (wie diesen) und zeigen damit an, welchem Projekt dieser Artikel zugehörig ist und was deren Hauptaufgabe ist. Ich könnte mir so etwas in abgewandelter Form am Kopf unserer Artikel vorstellen, um a) ein Projekt als Ansprechpartner für diesen Artikel aufzuzeigen und b) vielleicht die ein oder andere Baustelle aufzuzeigen, bei der noch Unterstützung gesucht wird. Dies würde unsere Besucher direkt im jeweiligen Artikel abholen und selbst in nahezu fehlerlosen Artikeln auf Baustellen im PokéWiki aufmerksam machen. Das Ganze könnte man lediglich für unangemeldete Seitenbesucher sichtbar machen, sodass für angemeldete Besucher die Artikel nicht noch länger werden. Der einzige Nachteil ist wie gesagt, dass es sich dabei um Hinweise an jedem Artikelanfang an fast jedem unserer Artikel handeln würde und dieses Werben um Unterstützung schon etwas aufdringlich wirken könnte. Anders kann ich mir aber kaum einen Nutzen vorstellen. Entweder wir werben aktiv an den Stellen, wo Seitenbesucher sind (in unseren Artikeln) oder wir lassen es. Denn das halbherzige Suchen über die Hauptseite oder andere Extraseiten, auf die ein Seitenbesucher überhaupt erstmal kommen müsste, ist für mich nicht erfolgsversprechend. ~ Taisuke ^Diskussion 20:36, 16. Mär. 2019 (CET)

Ich stelle mich klar gegen den Vorschlag solcher Projektbanner - allein die Frage was zu welchem Projekt gehört wird zweifelsohne Probleme verursachen (z. B. das Trading Card Game für den GB - is das jetzt TCG oder Spin-Off? Mir als Leiter von beidem eigtl. Wurst), von der Spin-Off vs Orte/Chara-Diskussion in Col/XD gar nicht erst zu sprechen... --Mecanno-man^Mäh 18:34, 18. Mär. 2019 (CET)

Die Einwände unserer Vertreter der Contra- und Enthaltungsoptionen sind durchaus gerechtfertigt. Vor allem auch die Sorge, dass eine solche Box möglicherweise nichts brächte. Ich denke jedoch nicht, dass sie uns schaden wird und dass ein Nullgewinn der tatsächlich negativste Fall sein würde, so er denn überhaupt einträfe. Ich persönlich habe in der Vergangenheit immer mal wieder auch Arbeit direkt an Neulinge delegiert, und zwar sehr konkret und sehr einfach zu machen, teils mit präziser Anleitung und Erklärung. Nachhaltig hat dies kaum etwas gebracht.
Eines möchte ich noch meinerseits einwenden: Die Contra-Einwände sind interessanterweise größtenteils von altgedienten ESBs erhoben worden, wohingegen die meisten Pro-Stimmen von einfachen SBs kommen. So stellt sich die Frage; liegt eine Art „Betriebsblindheit“ auf der einen Seite vor oder eine zu große „Unwissenheit“ der anderen? Dies sollen keine Unterstellungen sein, nur ein Denkanstoß für uns alle. -MfG, Kenaz-Hagalaz ^Disku 17:54, 21. Mär. 2019 (CET)

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. --Mecanno-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 -- 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. --Mecanno-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 ~ ^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... --Mecanno-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 ~ ^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. --Mecanno-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 ~ ^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. --Mecanno-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 ~ ^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. --Mecanno-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. --Mecanno-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. --Mecanno-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 ~ ^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 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 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. --Mecanno-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 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 ~ ^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. --Mecanno-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)

Im Chattreffen vom 06.03.2021 wurde Beschlossen das dieser Punkt abschließend Diskutiert wurde und es lediglich an der Umsetzung fehlt welche durch DeXter oder die Admins umgesetzt wird. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 10:06, 7. Mär. 2021 (CET)

Anpassungen der Auszeichnungs-Abstimmungen

Liebe Wikinger, ich nehme Bezug auf das Chattreffen, wo über die Abstimmungen gesprochen wurde, welche Artikelauszeichnungen nach sich ziehen. Der ein oder die andere mag sich erinnern: Vor einiger Zeit wurden die beiden Abstimmungen zu lesenswerten und exzellenten Artikeln zusammengelegt, um Mehrfachabstimmungen zu vermeiden. Auch hat sich durchgesetzt, dass Abstimmungszeiträume zum Feedback geben und umfangreichen Verbessern von Artikeln genutzt werden. Das hat Vor- und Nachteile.

Vorteile:

• Durch die Möglichkeit, Artikel während der Abstimmung noch umfassend zu verbessern, wird häufig detaillierte Kritik an den Artikeln geübt. Da Geschmäcker bekanntlich verschieden sind, haben Autoren dann die Möglichkeit, nicht nur eigene Vorlieben sondern auch die von anderen zu berücksichtigen und die Artikel auf eine hohe Qualitätsstufe zu heben.
• Es wird Zeit gespart. Früher musste eine Abstimmung fehlschlagen, dann wurden Artikel korrigiert und dann erneut abgestimmt. Das fällt nun in eine einzelne Abstimmungsphase. Dies erhöht die Motivation, den Artikel zu verbessern, und es versandet nicht.

Nachteile:

• Der Prozess ist unklar. Wie lange darf verbessert werden? Wie werden bereits abgegebene Stimmen nochmal geändert, wie geht man sicher, über welche Artikelversion eigentlich abgestimmt wird?

Im Chattreffen bestand aus meiner Sicht ein relativer Konsens dazu, dass der Prozess nicht auf solch wackeligen Beinen stehen sollte, man sich aber auch gleichzeitig nicht die Vorteile von Feedback verbauen will. Deshalb schlage ich eine Kompromisslösung vor:

• Die Abstimmung wird in zwei Phasen aufgeteilt. Die erste könnte z. B. vier Wochen betragen. Hier werden noch keine Stimmen abgegeben und alle (stimmberechtigten?) Nutzer sind dazu aufgerufen, Rückmeldungen zu dem Artikel zu geben. Jeder interessierte Autor kann dann in der Verbesserungsphase am Artikel schleifen. Die Phase erinnert an die Verbesserungsinitiativen.
• Die zweite Phase, vielleicht zwei Wochen, ist die konkrete Abstimmungsphase. Hier dürfen nun keine bedeutsamen Änderungen am Artikel mehr vorgenommen werden, kleinere Änderungen sind weiterhin erlaubt. Nur in dieser Phase darf abgestimmt werden.

Nicht ganz sicher bin ich, wie man Autoren zum Rückmeldung geben animieren kann, aber ich habe Vertrauen dass es klappen kann. Mit der Änderung verbinden könnte man einen etwas veränderten Abwahlprozess:

• Im Chattreffen bestand großer Zuspruch dazu, dass der Abwahlprozess erschwert werden soll. Nur Artikel, bei denen eine Zweidrittelmehrheit gegen eine Auszeichnung stimmt, sollen sie künftig verlieren. Der Prozess wäre also umgedreht zum Nominierungsprozess, zusammengefasst muss immer eine Zweidrittelmehrheit für eine Änderung des Auszeichnungsstatus erreicht werden. Dafür sollte eine zweite Vorlage her, einfach des Wordings wegen, der Prozess jedoch bleibt derselbe. Für mich stellt sich die Frage, ob zwei Drittel denn nicht etwas viel sind und vielleicht 60% etwas flexibler wären.

Wie steht ihr zu dem Vorschlag? Gibt es Dinge, die berücksichtigt werden müssen? Andere Gedanken dazu, die dagegen sprechen? Ist der Abwahlprozess abgesegnet? LG, Maxmiran 19:19, 30. Okt. 2018 (CET)

Bezüglich Abwahlen: Hatten wir hier nicht gesagt das wir das jetzt erstmal mit zwei-Drittel-Mehrheit im aktuellen System machen - so quasi ne Art Hotfix - und dann den Punkt völlig offen für diese Diskussion lassen? In dem System das du da vorschlägst fänd ich für ne Abwahl z. B. auch nur die Wahlphase zu nutzen geeignet. --Mecanno-man^Mäh 22:08, 30. Okt. 2018 (CET)

Ich finde das wir hier in einer Zwickmühle stecken. Es zeigten die vergangenen Abstimmungen immer das entweder gar nicht abgestimmt wurde. Oder das Feedback nicht Zeitgen eingearbeitet wurde. Daher wurde der Abstimmzeitraum verlängert, die Bearbeitungsmöglichkeit für die ersten 3 Wochen in vollem Umfang zugelassen und wenn eine Kritik kam, dann wurde ausgebessert und es gab einen kurzen Ping und der User hat ggf. seine Stimme abgeändert und erst in der letzten Woche durften nur Kleinigkeiten gemacht werden. Somit wurde immer die Version in der letzten Woche ausgezeichnet. Wenn wir jetzt das ganze in zwei Phasen trennen so habe ich die Befürchtung das die Feedbackphase ausgelassen wird und nur bei der Wahl als solches, Kritik geäußert wird. Somit würde es vermutlich wieder zu Zwei Abstimmungen kommen. Der gewählte Zeitraum von insgesamt 6 Wochen erscheint mir zu lange. Persönlich sehe ich die Trennung kontraproduktiv und würde eher überlegen was wir anders machen können um Feedback zu bekommen. Denn das ist es ja was immer fehlt. Wäre es nicht möglich hierfür den Discord oder Filb zu nutzen und dort soetwas wie Feedback-Wochen/Abende abzuhalten. Wo 1-2 Artikel vorgestellt werden die man auszeichnen möchte. Und dort via VC/Channel/Thread Meinungen der Leser einholt. User die häufig daran Teilnehmen kann man ja mit entsprechenden "Feedback"-Auszeichnungen/Babeln belohnen oder man nimmt es als wiederkehrende Mission fürs Missionsbrett und ein User bekommt pro sinnvollem Feedback einen Punkt. Ich sehe derartige Maßnahmen sinnvoller als hier zu verlängern oder das noch weiter zu trennen. Bzgl. Auf- oder Abwertung der Auszeichnung ist für mich die Frage offen ob hier ein Optimierungszeitraum gegeben werden sollte. Bei Aufstufung kann ein Optimierungszeitraum durchaus Sinn ergeben um an allen Ecken Feinschliff und Exzellent raus zu holen. Bei Abwahlen find ich es wiederum schwierig. Mangels aktueller Begründung warum der Artikel zur Abwahl steht kann die Abwahl für viele nicht nachvollziehbar sein. z.B. vollständige Projektumstrukturierungen usw. andererseits kann mittels Optimierungszeitraum die Abwahl verhindert werden um Aushängeschilder nicht zu verlieren. Im Endeffekt lande ich immer wieder bei unserem aktuellen Modell. Wo wir lediglich die Feedbackschleife ankurbeln sollten. Beim Abstimmverfahren selbst finde ich das der Konsens hier 2/3-Mehrheit für jede Änderung war und wir daran festhalten sollten. Wenn wir jetzt noch mit 60% usw. anfangen dann verkompliziert es das ganze nur noch mehr. Eine weitere Vorlage find ich daher unnötig. Hier muss man sie lediglich optimieren z.B. über 3 Parameter |Aufstufung=, |Wahl= und |Abstufung= die Parameter bestimmen die allgemeine Struktur der Vorlage und alles was hinter dem = steht Wird dann unter Begründung gepostet und fertig. die drei Parameter sollten somit selbsterklärend sein. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 10:48, 31. Okt. 2018 (CET)

Ich weiß ehrlich gesagt nicht, was ich hier noch groß hinzusteuern könnte. Ich habe ja bereits beim Chattreffen gesagt, dass ich klar hinter Max' Ausführungen stehe. Die Abwahl durch 2/3-Mehrheit halte ich für sehr wichtig, da demokratische Beschlüsse niemals durch die Minderheit wieder umgeworfen werden sollten. Was die Feedbackphase angeht, so halte ich sie definitiv für sinnvoll und würde sie zumindest probeweise einführen. Als Dauer würde ich an zwei bis drei Wochen und für die Abstimmungsphase an zwei Wochen denken. Zwischen diesen beiden Phasen sollte man einen ganz klaren Cut machen und von da an nur noch die Korrektur von Rechtschreibfehlern erlauben. Dass Änderung des Artikels und Abstimmung zeitgleich stattfinden durften, empfand ich schon von Anfang an als schwierig. Da dieses Feedback aber dennoch sehr wertvoll ist, ist die Lösung mit der zweigeteilten Abstimmung aus meiner Sicht aktuell die beste Lösung.--❄❄ Pk-fan 12:09, 5. Nov. 2018 (CET)

Abstimmung zum weiteren Vorgehen

Da das Ganze mal wieder einzuschlafen droht, habe ich mich jetzt für eine Abstimmung entschieden. Frage ist, wie wir künftig mit Auszeichnungsabstimmungen verfahren. Die beiden Positionen sind oben näher ausgeführt. Die zweite Option habe ich nochmal aufgespaltet. Die Abstimmung läuft bis zum 12. Dezember 2018 23:59 Uhr, stimmberechtigt sind alle Stimmberechtigten.

Abstimmung beendet, Mehrheit für einen zweistufigen Prozess, nur für Nominierungen

Option 1: Prozess bleibt so

Genauer: Der Abstimmungsprozess bleibt derselbe, wir fördern Feedback zu Artikeln auf andere Weise.

1. Bei einer stärkeren Trennung und Unterbindung von Abstimmungen sehe ich wie gesagt die Gefahr das Feeback ausbleibt. Alles weitere habe ich ja dazu bereits weiter oben erläutert. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 10:01, 21. Nov. 2018 (CET)
2. ~ noch ein schönen Tag ^^ ~ DarkViper 11:54, 21. Nov. 2018 (CET)
3. Ige ^Diskussion 12:08, 21. Nov. 2018 (CET)
4. Ich teile Ryuichis Bedenken. --  TM Master  16:32, 21. Nov. 2018 (CET)
5. -- Skelabra2509 (Diskussion | Beiträge) 03:39, 22. Nov. 2018 (CET)
6. Ich schließe mich Ryuichi an Snowy Dragons ^Diskussion 22:30, 2. Dez. 2018 (CET)

Option 2.1: Zweistufiger Abstimmungsprozess, für Nominierungen und Abwahlen

Genauer: Der Abstimmungsprozess für Auszeichnungsnominierungen wird aufgeteilt in eine Feedbackphase, in der man nicht abstimmen darf, und eine Abstimmungsphase, in der nur noch kleine Änderungen erlaubt sind.

Option 2.2: Zweistufiger Prozess, nur für Nominierungen

Genauer: Der aufgeteilte Prozess wird nur für Nominierungen, nicht jedoch für Abwahlen genutzt. Abwahlen beinhalten nur die Abstimmungsphase.

1. Maxmiran 09:29, 21. Nov. 2018 (CET)
2. - - "I'm gonna swing from the chandelier" GoPika ^Disku 14:27, 21. Nov. 2018 (CET)
3. -- Grüße ShortyBuzz 16:02, 21. Nov. 2018 (CET)
4. Aktuell sind die ersten Wochen der Abstimmphase absolut unnötig, da der Artikel eh noch bearbeitet werden kann. Insofern macht diese Aufteilung viel mehr Sinn.--❄❄ Pk-fan 18:34, 21. Nov. 2018 (CET)
5. --Mecanno-man^Mäh 19:23, 21. Nov. 2018 (CET)
6. SwowoJonny 20:29, 21. Nov. 2018 (CET)
7. Shin no tatakai wa, korekara da. The true fight is yet to come. JustRotty 20:34, 21. Nov. 2018 (CET)
8. Bei den letzten Abstimmungen zu Auszeichnung habe ich öfter das Gefühl gehabt, dass noch etwas hätte verbessert werden können. Vorher wollte ich eigentlich nicht abstimmen, aber ohne Abstimmung (bzw. irgendeinen Anstoß) bin ich gar nicht auf die Idee gekommen, mir den Artikel überhaupt anzusehen. Worauf ich hinaus will: Ich halte eine zweigeteilte Abstimmungsphase auch für besser. (Und sorry, die Diskussion ist total an mir vorbeigegangen...) -- Michelle ^o° 22:17, 21. Nov. 2018 (CET)
9. Cliffichen ^Diskussion 23:15, 21. Nov. 2018 (CET)
10. Mir auf jedenfall auf diese Weise lieber. — mfg ^Snack_hound 13:34, 27. Nov. 2018 (CET)
11. Buoysel 23:00, 2. Dez. 2018 (CET)
12. ~ Taisuke ^Diskussion 20:19, 3. Dez. 2018 (CET)

Enthaltung

1. Ich muss mich an dieser Stelle, so leid es mir auch tut, enthalten. Ich fürchte einfach, dass eine Änderung der aktuellen Regelung nicht zwangsläufig zielführend ist, das Feedback ist seit langem sehr gering bei solchen Abstimmungen und ich glaube um ehrlich zu sein nicht, dass eine spezielle Phase etwas daran ändern wird. Nichtsdestotrotz ist auch der Status quo nicht perfekt, da Feedback dort ebenso ausbleibt und die Leute einfach nur entscheiden indem sie kurz vor Schluss ihre Stimme abgeben. Was dazu führt, dass wir so wenig Feedback bekommen, lässt sich allerdings nicht so einfach sagen. Demnach werde ich mich enthalten, letztendlich kann ich mit beiden Lösungen leben. -- RobbiRobb 22:23, 21. Nov. 2018 (CET)
2. Der jetzige Prozess ist definitiv nicht perfekt. Wäre er das, stellte sich ja gar nicht die Frage nach einer Veränderung. Die Gründe dafür wurden hier und an anderer Stelle ja immer wieder genannt. Der alternative Prozess scheint mir aber auch ziemlich „experimentell“ zu sein. Er könnte die Probleme vermindern, aber auch unter Umständen welche schaffen. Ich kann mich jedenfalls nicht mit einem guten Gefühl für eine dieser Optionen aussprechen. Eine völlig andere Option habe ich leider auch nicht parat, sonst hätte ich diese bereits bei der Diskussion mitgeteilt. -MfG, Kenaz-Hagalaz ^Disku 20:30, 6. Dez. 2018 (CET)

Kommentare

@Buoysel, CLina, GoPika, Impoleon xy, Isso08-15, Jones, Kenaz-Hagalaz, Killuu, Korvel1, Lombrero, Loxi-kun, Luca12379, Matze, Maxmiran, Mecanno-man, Moltres, Pk-fan, RobbiRobb, Ryuichi, shadowtweaker, ShortyBuzz, Simonsees, Snackhound, Taisuke, Yinni, AAWiki, Cliffichen, DarkViper, Der Sternendiamantritter, Esteror, FloRyan, Friedrich on ice, Hydrokyu, Ige, Jasuanti, JoshOt, JustRotty, Mario-WL, Mega Glurak Y, Michelle, Pintauranimus, Pokénator, Schiggy91, Skelabra2509, Snowy Dragons, SwowoJonny, TiMauzi, TM Master, Tyber, Yrel Viele Grüße! Maxmiran 09:29, 21. Nov. 2018 (CET)

Seh ich das richtig das das hier ein Fall von „die Demokratie gibt eine Richtung vor, die Führung setzt das im Detail dann um“ ist? Ich sehe hier nämlich keinen konkreten Vorschlag zu einer Änderung über den wir abstimmen, lediglich der Status Quo (Option 1) ist in Stein gemeisselt. Insbesondere problematisch finde ich das keine Vorschläge bestehen wie man denn Leute dazu animieren kann in der ersten Phase überhaupt mitzumachen, das einzige was diese Änderung ja de jure bewirkt ist das keine Stimmen mehr vor der Sperre abgegeben werden dürfen, sowie eventuell einen angepassten Zeitraum.* --Mecanno-man^Mäh 19:23, 21. Nov. 2018 (CET)

Hi Mec! Zunächst geht es nur darum, den Prozess weniger verwurstelt zu gestalten. Was verhindert werdem soll ist a) dass Leute abstimmen, dann große Veränderungen gemacht werden und sie die Stimme nicht ändern und B) dass Leute gegen Ende der Abstimmungsphase noch stark editieren und dann nicht mehr klar ist auf welche Version sich die Abstimmung bezieht. Deswegen ja der Plan A) in der ersten Phase nicht abstimmen und B) in der zweiten Phase nicht editieren zu dürfen. Nur darum gehts zunächst, um die Prozessklarheit. Wie man Feedback anregen kann ist einfach in meinen Augen eine andere Frage. LG! Maxmiran 21:59, 25. Nov. 2018 (CET)-- Maxmiran 21:59, 25. Nov. 2018 (CET)

Ich danke euch für die hohe Beteiligung! In naher Zukunft wird das Konzept umgesetzt werden. In diesem Rahmen kann dann darüber nachgedacht werden, wie Artikel zu Feedback gelangen. Die Erfahrungen aus den VBW stimmen mich dazu positiv. LG! Maxmiran 11:39, 13. Dez. 2018 (CET)

Wuffels 774 vs. Wuffels 744a

Hallo Zusammen, wo es mir gerade beim durchsehen von Buo's Uploads aufgefallen ist. Was machen wir mit so etwas:

• Datei:Pokémon-Icon 744 3DS.png reguläres Wuffels
• Datei:Pokémon-Icon 744a 3DS.png spezielles Wuffels

klar die Dateien sind duplikate darum geht es mir aber nicht. Meine Frage ist sollten wir generell 744a oder auch die verschiedenen Zygarde oder Meteno in die vorlagen aufnehmen? Fakt ist 744 und 744a sind zwar vom Design das gleiche Pokémon unterscheiden sich allerdings in Fähigkeiten und Entwicklungsmöglichkeiten bzw. Haben die einzelnen Kernform unterschiedliche Inhalte. Ich persönlich hätte gesagt wir fügen diese hinzu. Entsprechend müssten alle Vorlagen die diese beinhalten wie Namenr usw. Icon-Parser angepasst werden. Gerade bei Meteno und Zygarde würden sich dadurch auch Verschiebungen der IDs ergeben und man müsste einmal durch Wiki schauen und kontrollieren. In wie weit hier auch in den Einzelnen DexArtikeln etwas geändert werden muss z.B. Entwicklung müsste auch geschaut werden. Da wir wert auf Korrektheit und Vollständigkeit legen sollte man überlegen z.b. bei Wuffels zwei Entwicklungstabellen zu machen aber das ist meine subjektive Meinung. Was sagt ihr dazu? Gruß * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 13:22, 15. Nov. 2018 (CET)

Mir ist es ehrlich gesagt egal, ob wir sie mit aufnehmen oder nicht, allerdings möchte ich mich bei Duplikaten klar gegen diese und für die Verwendung von Weiterleitungen aussprechen, wie wir es bisher auch bei allen anderen Datei-Duplikaten immer gehandhabt haben. -- RobbiRobb 16:18, 21. Dez. 2018 (CET)

Wichtig wäre mir hier auch mal die Pokédex-Leiter zu hören @Taisuke und @Maxmiran. Und ja die Duplikate können weg sobald hier klar ist wie wir verfahren. Solange würde ich wenigstens Wuffels noch erhalten lassen. Gruß * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 16:24, 21. Dez. 2018 (CET)

Wäre es nicht einfacher und mit weniger Aufwand verbunden, wenn wir – am Beispiel von Meteno – die Icon-Duplikate a-f löschen und die farbigen Kerne auf die Parameter setzen? Ich möchte damit keineswegs abstreiten, dass es keinen Unterschied zwischen verschiedenen Meteno in ihrer Meteorform gibt, denn ihr Kern kann sich sehr wohl unterscheiden, aber in meinen Augen nutzen sie allesamt dasselbe Icon. Warum können wir das nicht ebenso handhaben und müssen dies mit zusätzlichen Parametern unnötig verkomplizieren? ~ Taisuke ^Diskussion 14:38, 8. Jan. 2019 (CET)

Das, was du vorschlägst, ist in den Vorlagen und der Extension so angegeben, allerdings befinden sich dort im Moment noch die anderen Bilder. Möglich wäre jetzt das, was du vorschlägst - die Dateien einfach zu löschen - oder die Extension anzupassen, sodass im Falle von Meteno die Icons einfach weiter hinten stehen. Problem ist aktuell einfach nur, dass sie nicht in den Spritemaps enthalten sind und daher nicht eingebunden werden können, also entweder Bilder raus oder Nummern in Spritemaps rein, das sind die Möglichkeiten. -- RobbiRobb 15:03, 8. Jan. 2019 (CET)

Ignorieren wir einmal für einen Moment den Punkt Dateiduplikat und konzentrieren uns auf den Kern. Das Spiel unterscheidet in Mehrere Pokémon sowohl, bei Wuffels, Meteno, Zygarde, Quajutsu usw. Mein Punkt ist da es im Spiel verschiedene Pokémon sind ob wir hier nicht auch deutlicher darauf hinweisen sollten. Da es im Grunde eigenständige "Formen" sind, auch wenn sie optisch ident sind. Und das sehe ich als Problematik das wir die Differenzen hier lediglich auf die Optik reduzieren. Wenn wir z.b. Generell 744a als Wuffels (Normal-Form) und Wuffels (Tempomacher) oder whatever differenzieren dann muss nicht einmal was an "großen" vorlagen geändert werden sondern lediglich die ID-Vorlagen und Parserseiten und die Icons kommen aus WL. Das wie es gemacht wird ist im endeffekt rum wie num. Nur wäre hier halt mMn sinnvoller dies als separate "Formen" aufzulisten Gruß * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 15:03, 8. Jan. 2019 (CET)

Weitergedacht heißt das, du möchtest auch sechs Datei-Weiterleitungen für die Artworks und die jeweiligen Sprites bei Meteno, weil ohne diese die Andersartigkeit der verschiedenen Formen nicht wahrgenommen werden würde? Zudem würdest du mehrere Einbindungen in den Typen-Artikeln, Ranglisten, Attacken-Artikeln, der Pokémon-Liste usw. anstreben? ~ Taisuke ^Diskussion 22:22, 12. Jan. 2019 (CET)

Ich zitiere mal Robbi aus Discord, und das kann durchaus auch nur ein Auszug darstellen, gerade auch in Bezug auf Ranglisten und Sachen die mangels Diskussionsbeteiligung noch nicht bedacht wurden: Problem sind vor allem die Wikiweiten Folgen des ganzen. Es ist dabei nämlich wichtig, dass sich dann auch alle dran halten und nicht wieder irgendwo rausfallen, außerdem gibt es noch Schwierigkeiten mit der Darstellung des ganzen, die gestern im VC mal kurz angeschnitten wurde: Wo zieht man die Linie, was angezeigt wird? Was macht man mit Meteno, das im Spiel sechs Pokémon sind, wenn man sich dazu entscheidet, das ganze zu trennen? Alle Spritesa anzuzeigen, auch wenn sie gleich sind, ist noch keine große Problematik, aber was ist mit Attacken? Sie haben alle das selbe Moveset, es sind aber technisch betrachtet verschiedene Pokémon? Sechs mal die selben Attacken-Tabellen dürfte auch schon allein aufgrund der Limits keine gute Idee sein - aber damit hat man schon die erste Abweichung, den die Sprites würde man in diesem Fall ja alle anzeigen - oder ist das im Rahmen der Toleranz, wenn man eindeutig klar macht, dass alle Formen die selben Movesets haben?

Und das ist halt nicht alles, es gibt viele solcher Fälle, die man nicht nur beachten müsste, sondern für die man im Zweifel eine Fallentscheidung machen muss, bei der darauf zu achten ist, dass sie immernoch im Rahmen des Ergebnis einer Abstimmung liegen würde. * Ryuichi ~ ^PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch ^Diskussion 18:30, 16. Jan. 2019 (CET)

Ich wollte mich eigentlich nicht an dieser Diskussion beteiligen, da ich sie nicht mit mehr Wichtigkeit aufladen wollte, als sie hat. Aber da sie mittlerweile eher absurde Dimensionen angenommen hat, doch meine zwei Cent zu dem Thema:

Die einzige Erklärung für Sonderfälle wie Zygarde, Wuffels, Quajutsu oder Meteno ist, dass die Spieldaten nicht die gleiche Komplexität aufweisen, wie es mittlerweile die Pokémon in ihrer Konzeption tun. Das liegt vor allem auch daran, dass der Anime sich von den Spielen ein Stück weit emanzipiert hat. (Ashs) Quajutsu, (Ashs) Wuffels und (Blobby-)Zygarde sollten in den Spielen zitiert und berücksichtigt werden, sind aber nach ihren regulären Gegenstücken veröffentlicht worden, weshalb sie gesondert einprogrammiert werden mussten. Das ist aber eine programmiererische Notlösung und hat natürlich nicht die Bedeutung, dass das eigene Pokémon-Spezies in irgendeiner Form sind, sondern selbstverständlich ist Ashs Wuffels ein ganz normales Wuffels, welches im Anime besonderen Umständen ausgesetzt war, als es sich entwickelte. Auch Ashs Quajutsu ist zwar in den Spieldaten ein Basis-Pokémon, jedoch ist es selbstverständlich aus Ashs Amphizel entwickelt worden und die Spielvariante ist eine künstlich angelegte Notlösung, um Ashs besonderen Einfluss auf das Quajutsu abbilden zu können. Für solche Geschichten haben wir in den Pokédex-Artikeln die Fließtexte in den Entwicklungs- und Formwandel-Abschnitten, die auch ohne Dopplung von Vorlagen etc. die Umstände ideal abbilden können. Schließlich die Diskussion um Meteno... es hat schlicht sieben verschiedene Farben, und verschiedene Farbtöne jenseits der schillernden Variante sind im Spielcode derzeit nicht abbildbar, weswegen man sich für den Workaround entschieden hat. Wie daraus der Gedanke entstehen kann, es bräuchte z. B. eigene Attackentabellen für die Farben, kann ich nicht nachvollziehen und möchte mich vollkommen gegen eine künstliche Aufdröselung von Dingen aussprechen, die nur aufgrund eines Workarounds in den Spieldaten zustande kommt. Maxmiran 19:43, 16. Jan. 2019 (CET)

Meiner Meinung nach sollten Unterschiede da berücksichtigt werden wo sie eine Rolle spielen, bei Wuffels also z. B. in der Entwicklungs-Tabelle und den Fähigkeiten in der Infobox, nicht aber bei den Sprites. Bezüglich ob das jetzt unterschiedliche Pokémon sind oder nicht wäre auch noch das VGC als Argument beizuziehen: auch wenn Meteno sechsfach einprogrammiert ist, ein Team bestehend aus sechs verschiedenfarbenen Meteno wird nicht an einem Turnier teilnehmen können, an welchem jedes Pokémon nur einmal in einem Team vertreten ist. Und zu guter letzt: Bezüglich Robbis „alle müssen sich daran halten“ - dann haben wir im TCG-Bereich die absurde Situation das jedes Pokémon-ex, -EX, -GX, SP, ☆, Mega, TAG TEAM, Helles, Dunkles, TURBO, LEGENDE, Schimmerndes, Prisma Stern oder mit nem Besitzer im Namen, verschiedene Formen und noch einige weiter Sonderfälle ein eigenes Pokémon darstellt. Das sind allein 49(!) verschiedene Pikachu (wovon drei spezifisch Ash gehören), 12 verschiedene Mewtu, 7 verschiedene Kyurem, etc... und im Gegensatz zu den Spielen ist das hier vom Design her gewollt. Dennoch wirst du niemanden finden, der deswegen sagt Ashs Pikachu sei kein Pikachu. --Mecanno-man^Mäh 22:47, 16. Jan. 2019 (CET)

Ich bin klar dafür, hier danach zu entscheiden, was vom Konzept her eine eigene Form ist und was nicht (und ich denke, das lässt sich für jedes Pokémon klar sagen). Wie genau etwas im Code umgesetzt wird, ist ein technisches Detail, das bestimmt den Programmieren überlassen wird, je nachdem, was sich beim Programmieren anbietet. Bei Meteno zum Beispiel wird in der Meteorform nicht nach der Farbe des Kerns unterschieden, sonst hieße es offiziell ja „Meteorform (Roter Kern)“ oder so ähnlich. Also besitzt Meteno sieben acht Formen, die Meteorform und die sechs sieben Formen der Farbigen Kerne. Wuffels besitzt keine verschiedenen Formen, die besondere Fähigkeit ist zu vergleichen mit einer Event-Verteilung, bei der das Pokémon eine Attacke besitzt, die es sonst nicht lernen kann. (Es ist nämlich einfacher, eine besondere Attacke einzuprogrammieren als eine besondere Fähigkeit, weil es für die Fähigkeiten eines Pokémon eine feste Tabelle gibt und für das Exemplar dann nur ein Bit gespeichert wird, ob es die primäre oder die sekundäre Fähigkeit besitzt, während Attacken eines Pokémon einzeln gespeichert sind. Deshalb kann sich die Fähigkeit ggf. auch automatisch ändern bei der Übertragung auf eine neuere Generation. Die Alternative wäre also gewesen, für alle Pokémon einen vierten Fähigkeitenslot einzuführen, und das wäre deutlich aufwändiger.) Demnach brauchen wir für das Event-Wuffels auch keinen eigenen Sprite. Ash-Quajutsu hingegen ist eine eigene Form. In Pokémon-Artikeln von Formwandlern beziehen sich die Daten dann natürlich auf alle Formen, sofern nicht anders angegeben.– shadowtweaker 00:19, 17. Jan. 2019 (CET)

Merchandise-Lizenz

In letzter Zeit haben wir ein großes Lizenz-Problem was Dateien im Merchandise-Bereich angeht. Dadurch, dass es größtenteils nur Fotoaufnahmen der Produkte sind, gibt es keine einheitliche Lizenz dafür. Und dadurch, dass die Pokémon und co. ja unter das Copyright fallen, ist eine Merchandise-Lizenz wohl angebracht. Isso hat hier ein sehr gutes Beispiel für die Lizenz aufgelistet. Was ist eure Meinung? SwowoJonny 08:13, 23. Nov. 2018 (CET)

Ich stimme zu das so eine Lizenz von Vorteil wäre, hab von Lizenzen allerdings wenig Ahnung, weshalb ich den Text lieber jemandem anderes überlassen würde. Anmerken möchte ich allerdings das man wenn man ne allgemeine Merchandise-Lizenz macht doch bitte Vorlage:Bild-copyright-sfs gleich mit verbaut. --Mecanno-man^Mäh 19:02, 27. Nov. 2018 (CET)

Ich habe mich bei meinem Beispiel an der von Mec erwähnten Lizenz orientiert. Ich bin kein Experte, aber ich denke, dass der Text größtenteils hier ebenso anwendbar ist. Ich halte es schon für wichtig, eine passende Lizenz zu haben, um auch diese Produkthersteller zu erwähnen. Das Isso 08/15 ^Konter 19:26, 27. Nov. 2018 (CET)

Öh, ich meinte eher das wir sfs dann durch Merchandise ersetzen können; dafür müssten mindestens noch Kaiyodo und AMIGO in die Vorlage, aber wie gesagt, ich bin auch kein Experte ob nur schon das dann reicht... --Mecanno-man^Mäh 20:15, 27. Nov. 2018 (CET)

Am wichtigsten wäre wahrscheinlich einfach noch mal die Meinung von Buoysel, der uns seinen Standpunkt mal verraten könnte. SwowoJonny 03:04, 2. Dez. 2018 (CET)

Bin auch kein Jurist und würde einfach eine vorhandene Vorlage nehmen und die Firmennamen ersetzen. 🤔 ~ Buoysel 17:22, 2. Dez. 2018 (CET)

So, ich bin auf Mecs Wunsch eingegangen. Ich würde es dann Vorlage:Bild-copyright-merch nennen wollen. Das Isso 08/15 ^Konter 12:57, 5. Dez. 2018 (CET)

Eventuell wichtig anzumerken ist, dass die verlinkte URL https://bundesrecht.juris.de/urhg/__51.html nicht aufrufbar ist und man vielleicht lieber https://www.gesetze-im-internet.de/urhg/__51.html einbinden will. Letzere wird via ihrem SSL Zertifikat als "juris GmbH Juristisches Informationssystem für die BRD [DE]" ausgewiesen und ist damit wohl offiziell. Da sollte sich jemand ran machen und die Vorlagen überarbeiten 😅 ~ Anonymous5000 💬 14:24, 5. Dez. 2018 (CET)

Da ich die Kommentare als Zustimmung empfand, wurde es umgesetzt. Evtl. Beschwerden gehen also an mich. Das Isso 08/15 ^Konter 22:20, 13. Dez. 2018 (CET)

Trennung Eier und Zucht

Da der Artikel etwas lang ist wäre ich für eine Trennung in Eier und Zucht. Wie seht ihr das so? Das Isso 08/15 ^Konter 12:53, 14. Dez. 2018 (CET)

, auch wenns wahrscheinlich geschickter wäre das auf der entsprechenden Disk zu machen... --Mecanno-man^Mäh 17:35, 21. Dez. 2018 (CET)

Auf jeden Fall. Der Artikel ist mir in seiner jetzigen Form schon länger ein Dorn im Auge... -- Korvel1 ^Diskussion 10:59, 24. Dez. 2018 (CET)

Ich tu mich da grad etwas schwer. An sich ist die Trennung sicherlich nicht verkehrt, grade bei den Hauptspielen kann man da sicherlich gut trennen, insbesondere inhaltlich. Der Wartungsaufwand wäre jedoch recht hoch, immerhin wird doch recht häufig auf den Artikel gelinkt (und nein, botten geht nicht). Wo ich mir ebenfalls noch nicht ganz sicher bin, sind die allseits beliebten Spin-offs, die sich so gerne an die selben Mechaniken halten und sich demnach vllt nicht ganz so auftrennen und einsortieren lassen. Hier muss ich aber gestehen, dass ich da nicht so drin bin. Unterm Strich kommt somit ein Neutral, jedoch eher mit Hang zum Pro, bei raus. Jones ^Albtraum? 22:10, 24. Dez. 2018 (CET)

Ich seh da grad wenig Probleme bzgl. Spin-Offs: Zucht ist nämlich etwas was es afaik in der Form nur in den Hauptspielen gibt, in Spin-Offs erhält man die Eier anders - folglich sollten die Spin-Offs nahtlos in einen Eier-Artikel übergenommen werden können. --Mecanno-man^Mäh 22:57, 24. Dez. 2018 (CET)

Ist ein wirklich langer Artikel und ich glaube, dass es nicht schaden würde, wenn man ihn auftrennt. -- Michelle ^o° 12:24, 25. Dez. 2018 (CET)

Dieser Artikel ist sehr lang, da ist eine Trennung nicht verkehrt.Ige ^Feuer 21:51, 4. Jan. 2019 (CET)

Auch ich würde eine Trennung der beiden Artikel befürworten. Solange im Anschluss auch gewährleistet wird, dass die ganzen Verlinkungen durchgegangen und wenn nötig angepasst werden. ~ Taisuke ^Diskussion 14:43, 8. Jan. 2019 (CET)

Die Dikussion ist abgeschlossen und wird aktuell umgesetzt Jones ^Albtraum? 13:25, 16. Jan. 2019 (CET)

Auf Grund der hauptsächlich positiven Rückmeldung sind nun die Artikel getrennt. Das Isso 08/15 ^Konter 20:03, 16. Jan. 2019 (CET)