PokéWiki:Allgemeine Diskussionsseite/Archiv 2018

Aus PokéWiki
Zur Navigation springen Zur Suche springen
Die druckbare Version wird nicht mehr unterstützt und kann Darstellungsfehler aufweisen. Bitte aktualisiere deine Browser-Lesezeichen und verwende stattdessen die Standard-Druckfunktion des Browsers.
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: DirakiaDiskussionBeiträge)

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

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

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-manMäh 00:00, 13. Mär. 2018 (CET)
  3. --mfG Lombrero Dis 07:57, 13. Mär. 2018 (CET)
  4. Pokémon-Icon_674.png Maxmiran 11:34, 13. Mär. 2018 (CET)
  5. — mfg Snackhound 058.png 14:12, 13. Mär. 2018 (CET)
  6. 418.gif 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. - - Overworldsprite_Anissa_SW.png "I'm gonna swing from the chandelier" Pok%C3%A9monicon_609.png 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 146.gif 20:03, 15. Mär. 2018 (CET)
  14. 640.pngFreigeistDiskussion 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: HeiteiraDiskussionBeiträ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. -- 260.png 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
* Ryuichi ~ PL ~ Nur wer erwachsen wird und Kind bleibt, ist ein Mensch Diskussion 15:10, 13. Mär. 2018 (CET)
Zum einen: SpoilerHier 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

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. Pokémon-Icon_674.png 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 146.gif 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-manMä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-manMä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 ka.gif -- 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 emot-rolleyes.gif 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 172.png 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-manMä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-manMä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 Schiggy Schiggy 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 146.gif 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 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! 260.png 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 Snackhound 058.png 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. - - Overworldsprite_Anissa_SW.png "I'm gonna swing from the chandelier" Pok%C3%A9monicon_609.png 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-manMä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! Pokémon-Icon_674.png 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-manMä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-manMä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. - - Overworldsprite_Anissa_SW.png "I'm gonna swing from the chandelier" Pok%C3%A9monicon_609.png 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 Schiggy Schiggy 20:44, 7. Sep. 2018 (CEST)
  11. 359.png Korvel1 Diskussion 10:22, 8. Sep. 2018 (CEST)
  12. SwowoJonny 11:44, 8. Sep. 2018 (CEST)
  13. Tyber 006.png 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. Pokémon-Icon_674.png 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. 260.png 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 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 146.gif 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-manMä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 ka.gif -- 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

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 msnsorry.gif -- 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-manMä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. ka.gif 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)

[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.

Gestaltung der Stellenanzeigen/Ausschreibungen

vorrausgegangene Abstimmung

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

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

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

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


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

Ich habe Entwurf 1 von Kenaz ein wenig abgewandelt und hier mal in einer "Testumgebung" dargestellt. Da ich noch unschlüssig bei der Farbe des unteren Teils und dem Standort bin, habe ich ein paar toggler eingebaut, dann könnt ihr, wenn ihr wollt euch das anschauen und beurteilen^^. Meine Antworten auf die Fragen:
  1. Wie Kenaz' erster Entwurf. Meine Änderungen: der untere Teil ist eine Tabelle um bessere Trenner zu ermöglichen und die Großlinse ist im oberen Teil.
  2. Wie bei Kenaz. Die Stellenanzeigen sollten meiner Meinung nach gut sichtbar sein und neben der dominanten Farbe, halte ich es für wichtig, dass man, am PC die Anzeigen ohne runter zu scrollen sehen kann.
  3. Erneut wie Kenaz^^. Auf der Hauptseite und auffällig --> mindestens ab VB.
  4. Wie Kenaz. Zusätzlich bin ich zur Zeit am überlegen wie man so etwas wie {{Tt}} auch "Smartphone-Nutzer-freundlich" umsetzen kann, um bei Bedarf zu den einzelnen Stichpunkten eine Erklärung abgeben zu können, da die angebenen Punkte sich hauptsächlich (klärt mich auf sollte ich die Haupt-Zielgruppe falsch verstanden haben) an neue Nutzer (und an zukünftige Nutzer) richten und einen relativ einfachen Schwierigkeitsgrad haben sollen. Außerdem könnte man damit ermöglichen auch mal ein bisschen anspruchsvollere Aufgaben mit ausreichender Erklärung zu stellen. --DeXter 21:54, 27. Mär. 2019 (CET)
  1. Mir gefällt da jetzt spontan die generelle Richtung von Entwurf 2 besser; finde allerdings dass da zu viel Farbe hervorsticht, hätte mir da einen wesentlich kleineren Rahmen, wenn überhaupt, vorgestellt (das ihr hier schon viel zu früh Farbe in die Diskussion werft, sei mal dahingestellt - so wird sich jetzt nämlich die Hälfte gegen dieses Orange und nicht gegen das Design aussprechen). Oh und um himmels willen, kein tt auf der Hauptseite - ist schon schlimm genug das wir das noch in Artikeln nutzen. Zeitgemäss ist das einfach nicht mehr.
  2. Spontaner Vorschlag - und müsste definitiv noch von Killuu und Isso genehmigt werden: über das schon gewusst und dafür das Zeichenlimit von AdW/PdW erhöhen, damit da kein Leerraum entsteht. Haben wir Kapazität dafür aus dem XdW-Bereich? Ich meine mich nämlich erinnern können das früher sich immer darüber beklagt wurde dass die Zeichenlimite da zu kurz sei.
  3. Es is sinnlos es PLs zu verbieten und SB und alles drunter traue ich dieses Recht nicht zu - ist immerhin die Hauptseite. Folglich Entweder VB+ oder PL+ - was genau hängt vor allem von der Umsetzung von Punkt 4 ab.
  4. ..doppelt sich entweder mit der To Do oder mit dem Missionsbrett, so wie die Diskussion läuft eher mit der To Do. Da deren Darstellung allerdings meine Idee war, sie nicht so wirklich funktioniert hat und ich nicht weiss, wie man sie verbessert, halte ich mich hier glaub besser raus. --Mecanno-manMäh 18:35, 29. Apr. 2019 (CEST)
Zu dem Thema kann ich eigentlich nicht viel sagen, da ich erstens kein Fan dieser "Stellenausschreibungen" bin (soll jetzt keine weitere Debatte anstoßen, ich akzeptiere die Entscheidung) und zweitens ein furchtbares Gefühl für Design habe. Nur eine Bitte meinerseits: benutzt wenn möglich keine zu grellen roten und ins rote gehende Farben. Das beißt sich furchtbar mit dem Blau, das wir hier hauptsächlich verwenden. Fällt zwar sofort auf, lenkt aber auch vom Rest ab und ist zumindest für mich fast schon unangenehm anzusehen :x -- Korvel1 Diskussion 10:10, 4. Mai 2019 (CEST)
Ich habe das Design meiner Vorschläge ein wenig geändert (auch etwas mehr nach dem Stil der anderen Boxen auf der Hauptseite). Hoffe, dass das Aussehen euch eher zusagt^^. --DeXter 18:54, 4. Mai 2019 (CEST)
Ich finde Entwurf zwei eigentlich schicker. So schmale Boxen gefallen mir meistens nicht so. Zu Mecs Einwurf: Ja, wir haben teilweise XdWs die gerne eine höhere Zeichenzahl hätten, manchmal krebst man da aber auch am unteren Ende rum. Wenn man aber die XdW-Box vielleicht etwas quetscht, wird sie auch länger? Wobei man dann schauen müsste, ob das noch schön proportioniert ausschaut. Lg --Und dann im Mondschein... Killuu 22:23, 5. Mai 2019 (CET)
Danke für eure Rückmeldungen!
Ja, die tt-Vorlage sollte in dieser Box wirklich komplett vermieden werden. Allein schon, weil sie auf Mobilgerät-Browsern oft nicht richtig dargestellt wird, was dann meist die Zerstörung des Layouts zur Folge hat. Eventuelle weitere Nachteile der tt-Vorlage unterstützen diesen Punkt nur noch.
Ich denke auch, dass man die Farben der Box nicht zu grell gestalten sollte. Ich finde den Vorschlag, von der Signalfarbe Rot abzusehen, sehr interessant und bin zu dem Schluss gekommen, dass ein blauer oder grüner Farbton, wohl am besten passen würde. Z. B. die gleiche Farbe, wie die, der übrigen Boxen nur ggf. etwas dunkler oder eben ein Greenchu-Grün.
Als XdW-Autor habe ich auch immer wieder mit der Zeichenbegrenzung zu kämpfen. Als jemand, der gerne ein weites Spektrum an Formulierungsmöglichkeiten haben möchte, würde ich eine Aufstockung des Zeichenlimits begrüßen. Ich sehe aber auch, dass viele mit dem Mindestzeichensatz ringen. Das Problem der Proportionsästhetik entsteht durch eine allzu große Vergrößerung der XdW-Box leider auch. Ich hoffe, unsere Projektleiterin Isso kann uns ihre Einschätzung der Lage und der potenziellen Möglichkeiten geben.
Ich bin auch von der „Längsfassung“ (wie DeXters oder mein Entwurf 1) eher abgekommen, da ich ein Problem bei dieser sehe, wenn es zu viele oder zu wenige Gesuche geben sollte. Besser wäre es wohl, eine schmalere Box (wie mein Entwurf 2) zu haben, die sich nach Bedarf füllt oder erweitert. Ich würde sehr gerne auch eine solche Variante mal „in Aktion“ sehen. Da du dich, DeXter, für diese Sache sehr engagierst und deine Syntax-Fähigkeiten deutlich besser sind als meine, möchte ich dich bitten, mal deine Version dieser Variante zu erstellen. Bin gespannt, wie die wohl aussähe. :)
-MfG, Kenaz-Hagalaz Disku 16:32, 24. Jun. 2019 (CEST)
Kann ich gerne machen Kenaz^^. Sollte dann die nächsten Tage fertig werden, je nach dem wie schnell ich mit meinem Ergebnis zufrieden bin (nach Möglichkeit werd ich auch versuchen das irgendwie ins Haupseiten-Layout reinzubringen, bin da aber eher am zweifeln ob ich das in angemessener Zeit schaffe). Vorhin hatte ich mir auch noch eine Frage überlegt, die ich aber wieder vergessen habe drop.gif Sollte sie mir wieder einfallen, kommt nochmal was von mir. --DeXter 19:28, 24. Jun. 2019 (CEST)
Tada! Zwar nicht ganz fertig, aber das Einzige, was mich noch stört ist das "Gesucht!" und dafür hab ich bisher noch keine zufriedenstellende Lösung gefunden. Hoffentlich fällt euch was ein (muss auch nicht gleich in CSS sein; wenn nötig kann ich versuchen einen Vorschlag möglichst gut umzusetzen). Mit der restlichen Box bin ich sehr zufrieden (viell. könnte man auch noch den freien Platz unterm Bild entfernen, dafür müsste nur die Höhe des divs, in dem die Liste ist, geändert werden; dann wäre die Box auch kürzer). Ich hab mich am Design der restlichen Hauptseiten-Boxen orientiert und denke, dass das Bild auf jeden Fall ausreicht um auf die Box aufmerksam zu machen. --DeXter 18:58, 26. Jun. 2019 (CEST)
Passt anscheinend doch nicht. Das Entfernen der Scrollbar über scrollbar-width: none funktioniert in Firefox und dem Samsung Internet Browser für Handys (wie auch immer der genau heißt), aber nicht in Edge und dem Internet Explorer. Bei anderen Browsern weiß ich es nicht. Ich versuche in den nächsten Tagen das zu lösen. --DeXter 16:49, 27. Jun. 2019 (CEST)
@Kenaz (und alle, die hier mitwirken wollen^^), jetzt ist die Box (fast) fertig. Wie bereits gesagt stört mich noch das "Gesucht!"; ansonsten siehe meine vorletzte Nachricht. Hier nochmal der Link. Und noch etwas hintendran: Mec kritisierte grad auf Discord, dass man durch die unsichtbare Scrollbar nicht mehr sehen könne, dass die Liste hoch- und runtergescrollt werden kann und, dass somit der "08/15-Nutzer" nicht merken wird, dass die Liste diese Funktion hat. Meiner Meinung nach ist das kein Problem, da, auf meinem Handy und meinem PC, wenn die Liste lang genug ist, der unterste, sichtbare Listeneintrag (wenn die Box ganz hochgescrollt ist) vom Rand der Box angeschnitten wird und man sich somit erschließen kann, dass die Liste länger ist als das, was man sehen kann. Was sind eure Meinungen? --DeXter 19:08, 8. Jul. 2019 (CEST)
Durch das fehlen der Scrollbar interpretier zumindest ich das eher als n Designfehler als n Indikator zum Scrollen; irgend einen Indikator das man da Scrollen kann brauchts definitiv. --Mecanno-manMäh 23:41, 8. Jul. 2019 (CEST)

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

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

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

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

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

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

Ich habe hier mal den Mittelteil der Hauptseite nachgebaut (Ober- und Unter-Teil sind einfach die Vorlagen) und die Stellenanzeigen-Box an einer möglichen Stelle eingebunden. Das bisher benutzte Bild habe ich entfernt, um Platz zu sparen. Meiner Meinung nach sollte man, wenn dann ein recht schmales oder kleines Bild benutzen, damit kein wertvoller Platz verbraucht wird. Den entstandenen habe ich gefüllt, indem ich die XdW-Box verlängert habe. Als erstes zu diesem Lösungsansatz: Eine Folge dieser Möglichkeit ist die Erhöhung der XdW-Längen (ich glaube auf ca. maximal 1850 Zeichen; keine Ahnung wie viel als Minimum) für manche wird das evtl. ein Vorteil sein, manch anderer (auch ich) wird es dadurch allerdings hin und wieder schwer(er) haben. Deshalb hatte ich die Idee je nach Bedarf ein zweites Bild einzubinden (dies würde aber keines Falls den zusätzlich nötigen Text ersetzen können, nur verringern). Isso, wie ist deine Einstellung als derzeitige XdW-Projektleiterin dazu, allgemein als Lösung an der XdW-Box rumzuschrauben? Ansonsten hatte ich noch den Einfall, dass der entstehende, freihe Platz durch eine weitere Box gefüllt werden könnte. Allerdings habe ich keine Ahnung was für eine das sein sollte (und dafür müsste höchst wahrscheinlich eine komplett neue, separate Diskussion gestartet werden). --DeXter 02:14, 1. Apr. 2020 (CEST)
Als Alternative könnte man sonst auch die Anzahl der Wds-Sätze reduzieren, sodass XdW-Artikel nicht künstlich durch ein weiteres Bild gestreckt werden müssten. Die Stellenanzeigen-Box könnte man zudem scrollbar machen, um dort auch etwas mehr als drei knappe Anzeigen unterzubekommen. ~ Taisuke Diskussion 09:18, 1. Apr. 2020 (CEST)
Mit Hilfe von Tais Idee hab ich eine zweite Version auf meiner Testseite erstellt. Dieses Mal ist die XdW-Box völlig unverändert. Dafür wurde der Wds-Teil verkürzt. Durch die Scrollbar kann man aber immer noch alle Wds-Sätze sehen (hierbei entsteht bloß das Problem, dass die "verdeckten" Sätze weitaus weniger Aufmerksamkeit kriegen würden). Eine Scrollbar habe ich ebenfalls bei der Stellenanzeigen-Box hinzugefügt und bin auch dafür, das wegen der ermöglichten Platzersparnis ins finale Design mitaufzunehmen (diese Möglichkeit hatte ich, glaube ich, bisher verdrängt, weil das vor vielen Monaten nicht mit dem Bild harmonieren konnte. Dadurch ist auch erst die Sache mit der ausgeblendeten Scrollbar entstanden). Da das hier noch nicht in der Diskussion steht, werfe ich eine Idee von Mec noch in den Raum, die er vor langer Zeit hatte: Die Stellenanzeigen, ähnlich wie die Wds-Sätze zufällig aus einem Text-Pool anzeigen. Aber wie gesagt, ich präferiere die Scrollbar-Lösung. --DeXter 13:13, 1. Apr. 2020 (CEST)
Ich finde, beide Versionen haben ihre Vor- und Nachteile. Die Verwendung von Scrollbars führt dazu, dass wir den Seite komprimiert halten können, ohne dabei auf Inhalt verzichten müssen oder diesen anderswo künstlich aufblähen müssen. Bei der News nutzen wir dies ja bereits und da können problemlos einige Einträge drin stehen, bevor das überfüllt wirkt, wobei die Seite dabei nicht unnötig in die Länge gezogen wird. Im Gegensatz zu dem Wds und den Stellenausschreibungen haben wir hier einen entscheidenden Faktor aber verfügbar: Aktualität. Bei den News stellt es kein Problem dar, wenn man ältere Sachen "schwerer" erreichbar macht, indem man etwa eine Scrollbar nutzt, da diese sowieso nicht so häufig gesucht werden. Bei den Stellenausschreibungen wird Aktualität aber eher eine geringere Rolle spielen, die meisten Sachen werden immer wichtig sein, wenn sie da drin stehen. Einige Einträge zu verstecken wird da also nur dazu führen, dass sie übersehen werden. Ähnliches gilt für die Wds, wenn diese teils versteckt sind, werden die weiter unten aufgeführten seltener gelesen und damit geht der "Spaßfaktor" daran verloren.
Der Verzicht auf Scrollbars auf der anderen Seite führt dazu, dass logischerweise andere Inhalte drum herum länger werden müssen, um den frei gewordenen Raum aufzufüllen. Das mag in diesem Beispiel gut geklappt haben, aber es wird einige Fälle geben, wo die XdW-Artikel das nicht leisten können. Ich bin mir also nicht sicher, ob das hier der zielführende Weg ist. Logischerweise wäre es auch möglich, ein anderes Design für die Box zu wählen, man könnte etwa eine breitere Box über die ganze Seitenbreite wählen, so ließen sich mehr Punkte unterbringen und man hätte das Platzproblem an dieser Stelle nicht. Das stellt uns aber natürlich vor ein anderes Problem: Wohin damit? Über oder unter den XdW/Wds/Zitat-Abschnitt? Da drüber würde dazu führen, dass die Seite möglicherweise aus dem Gleichgewicht gerät, da wir bereits drei Boxen darüber haben, eine weitere könnte das ganze visuell länger erscheinen lassen, als es tatsächlich ist und so beinahe abschreckend wirken. Verfrachten wir die Anzeigen hingegen unter diesen Abschnitt, werden ihn höchstens die paar Leute sehen, die ohnehin den XdW/WdS/Zitate-Abschnitt bis zum Ende lesen und dann feststellen, dass da noch was drunter ist, für die EP-Sachen werden die wenigsten ans Ende der HS scrollen. Mit anderen Worten: Man riskiert, dass niemand die Ausschreibungen sieht und das wäre so ziemlich das Gegenteil von dem, was wir erreichne wollten. Man könnte natürlich darüber nachdenken, die News nach da unten zu verschieben, aber ich kann mir gut vorstellen, dass die Leute diese gerne sehen und daher vermissen würden. Alternativ wäre es vielleicht auch möglich, eine der bereits bestehenden Boxen zu erweitern. Das könnte vielleicht etwas platzsparender sein und uns erlauben, die Ausschreibungen weit oben zu platzieren, ohne dass sie störend wirken. Aber da wird man vermutlich einfach testen müssen, was passt.
Abschließend noch kurz: Am Handy scheinen die Boxen nicht ganz zu passen, ich weiß aber ehrlich gesagt nicht, wie genau das zustande kommt, ich lass das einfach mal mit Bild da, vielleicht kannst du da ja noch mal drauf schauen, DeXter. -- RobbiRobb 19:19, 1. Apr. 2020 (CEST)
Ich finde das zweite Design deutlich angenehmer und vor allem praktikabler, bei meinen XdWs gibt es einfach keine Möglichkeit noch andere Bilder reinzubasteln. Ich würde jedoch versuchen auf die Scrollbars zu verzichten. Man könnte ja zum Beispiel auch weniger Wds-Sätze einbinden und auch in der Stellenanzeige die angezeigten Punkte durch Zufall einbinden lassen. Was mir jetzt noch als Idee kam, sorry, falls das schon irgendwo stand, wäre die News zu verschmälern und die Stellenanzeigen da noch neben zu packen. Vielleicht nicht in der gleichen Breite wie Wds- und Zitatekästchen, sonst sieht das so komisch aus. Aber diese Newsbox besteht eh aus unglaublich viel Whitespace. Oder das Stellenanzeigenkästchen dann links und die News rechts. Ich denke, wir sollten auf jeden Fall bis zum Chattreffen die Optionen optimieren bzw. da noch bequatschen und dann mal ganz dringend eine Abstimmung starten ;). Btw. ich finde den zugefügten Text in Beispiel 1 beim PdW echt awesome :D. Lg --Vorsicht, heiß! Killuu 19:36, 28. Apr. 2020 (CET)
Ich habe, nach Killus wunderbarer Idee, mal eine paar Varianten hier auf meiner Testseite hinzugefügt. Da gefällt mir Version 3 schon ganz gut (bei Version 2 sieht die Stellenanzeigen-Box mMn irgendwie an den Rand gequetscht aus). Ob mit Scrollbar, zufällig angezeigten Stellenanzeigen oder anderem Schnickschnack, kann man noch entscheiden. Das hat denke ich auf jeden Fall Potenzial. Jetzt möchte ich noch etwas zum anderen kritischen Thema sagen - den Stellenanzeigen selbst. Wie Robbi auf Discord im VC schon meinte, dürfen keine wichtigen Sachen warten, bloß, damit sie als Anzeigen genutzt werden können. Deswegen könnten sich da die allseits bekannten müsste-man-mal-machen-Aufgaben wunderbar eignen. Wäre dann natürlich wieder Thema, ob man da genügend anfänger-freundliche auftreiben kann. Außerdem dachte ich mir, dass manche Aufgaben angeworben werden können, während sie jemand bearbeitet (z. B. weil die Sache dringend erledigt werden muss). Dann wird die Sache bearbeitet und Neulinge können zusätzlich etwas dazu beitragen und, wenn der Punkt erledigt ist, kommt die Stellenanzeige wieder raus. Mal als Denkanstoß bis zum Chattreffen. --DeXter 22:11, 28. Apr. 2020 (CEST)
Unabhängig der Mühe die sich Dexter gemacht hat... ich finde die Idee mit "Halbierung" und alle 3 Versionen schrecklich. Und bin dagegen. Es gab da schon deutlich optisch bessere Versionen. Eine weitere Box daneben macht die Newsline ziemlich dick und unschön. Und der Whitespace kommt je nachdem was in der News steht. Persönlich halte ich dieses Thema für ziemlich aufgebauscht, ähnlich wie das Mentorenthema damals. Es worden schon viel zu oft User auf Baustellen hingewiesen. Wir haben Mühen in Mitmachen, To-Dos usw. gelegt. Im Endeffekt hat sich allerdings nichts als hilfreiches Mittel erwiesen. Die Leserschaft will die Informationen vorgesetzt bekommen. Allerdings wollen die wenigsten Verstehen das ein Wiki nur durch Mitarbeit weiter wächst. Und solange sich das nicht ändert (und ich sehe Stellenanzeigen als kein mögliches Mittel) werden solche Sachen nur Perlen vor die Säue sein. Daher denke ich auch nicht das sowas das ganze verbessern wird. Das überlasse ich aber jedem selbst. Allerdings sollte dieser Stellenanzeiger, wenn die Mehrheit ihn will, nicht das Gesamtbild verschlechtern sondern sich in dessen Integrieren oder verbessern. Ich glaub auch nicht das dieses Ding groß jemand auf Dauer füllen wird, außer den paar euphorischen am Anfang. Man sieht ja wie schwer es ist das News hinzugefügt werden.* Ryuichi ~ 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-manMäh 00:56, 29. Apr. 2020 (CEST)
Sehe ich ganz anders. Die Breite der News über die gesamte Seite ist bewusst gewählt. Sie trennt die Navigation von wechselndem Wikizeugs. Durch die Splittung geht die klare Struktur verloren und die Leute wollen News, daher fände ich es verkehrt eine so wichtige Box zu halbieren. Die damalige Abstimmung war lediglich für Ja und Nein zur Box gedacht und wenn man sich die ansieht zeigt sich das die Gegenteiligen Argumente überwiegen. Allerdings zählen hier lediglich die Anzahl der Stimmen. Mmn kann sowas auf die Seite Mitmachen. Da ich wette das über 75% der Leser nicht über die Hauptseite ins Wiki gelangen. Und die restlichen 25% sollten Mitmachen bereits entdeckt haben ka.gif Denn User die aktiv mithelfen wollen werden auch auf Mitmachen klicken oder könnten darauf verwiesen werden. Halte ich zumindest für besser, wie die Verschandelung der Hauptseite durch etwas was nicht einmal einen Bruchteil der Leser interessiert. Hier können auch Postings auf SocialMedia zur stärkeren Promotion von Mitmachen weiter helfen. Statt über das Design dieser Box zu reden wäre erstmal der Inhalt zu klären. Denn hierzu gibt es (wenn man die Baustellenbanner mit einrechnet) außer die Projekte suchen Mitarbeiter seit Eröffnung der Diskussionen keine weiteren ersichtlichen Inhalte. Und diese Müsste-man-mal-machen-Sachen bleiben liegen weil sie einfach viel zu umfangreich sind. Da wirst du auch keinen Neuling für begeistern können. * Ryuichi ~ 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-manMäh 12:11, 29. Apr. 2020 (CEST)

Welche Zeitung schreibt ihre Stellenanzeigen auf die Hauptseite? Sie stehen i.d.R. im entsprechenden Bereich. das könnte auch ganz unten über der EP Leiste sein... oder wir kürzen/verlängern das XdW einfach um paar Wörter. so das eine Box darunter oder daneben passt. Ist eine Idee. Aber im Großen und ganzen gehört dies nicht auf die HS sondern nach Mitmachen. und du hast selbst das Beste argument geliefert da werden eh nur Leute hinkommen, die mithelfen wollen. Genau diese Leute wollen wir doch. User die es wollen und nicht welche die sich genötigt fühlen oder aus langweile eher verschlimmbessern. * Ryuichi ~ 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-manMäh 13:34, 29. Apr. 2020 (CEST)
Es war für mich noch nie so schwer einen gescheiten Diskussionsbeitrag zu schreiben. Meine Gedanken schwirren von einem Argument von Ryu zum anderen. Deshalb hier die komplett überarbeitete Version (ist hoffentlich besser als mein erster Entwurf (der nur lokal auf meinem PC ist)):
Das Ziel der Stellenanzeigen ist das offene Zeigen und aufmerksam machen. Deswegen der Platz auf der Hauptseite. Schön und gut, wenn Seiten wie "Mitmachen" oder die To-do-Liste verbessert wurden, aber das bringt wenig, wenn keiner sie findet. Auf der HS haben wir meines Wissens nach eine Fläche, die auf "Mitmachen" verlinkt und die ist zum Teil transparent, neben großen Bannern, die die Aufmerksamkeits-Erreger der Hauptseite sind. Das geht daneben einfach unter und noch allgemeiner als der Text davon gehts denke ich nicht. Das ist genau richtig für so eine Fläche, spricht aber mMn kaum einen an. Und natürlich finden trotzdem einige Leute die Seite, aber viele bemerken es einfach nicht und die wegfallen zu lassen, wäre höchst ineffizient. Links zu Seiten wie "Missionsbrett" oder "To-do-Liste" haben wir glaube ich bei den meisten Seiten nur versteckt in der Sidebar und dort gehen sie in der Masse der anderen Links unter. Da ist eben wieder der Vorteil, dass diese beiden Seiten durch die Stellenanzeigen-Box offen verlinkt werden würden. Außerdem soll die News-Box nicht halbiert werden, wurde sie auch in keinem Entwurf. "Aktuelles" war immer breiter und dominanter und hatte mehr Platz als die Stellenanzeigen-Box.
Etwas, das Mec in seinem Beitrag in etwa auch angesprochen hat: Meiner Ansicht nach besteht bei vielen Leuten der Mythos, dass Wikis bereits vollständig sind, sie nichts mit ihrem Wissen beitragen können oder ähnliches. Und diesen Irrglauben anzugehen sollte eines der wichtigsten Ziele von uns beim Thema Usergewinnung sein (und genau dafür sind die Stellenanzeigen wunderbar geeignet). Und wir haben doch bereits Beispiele, die zeigen, dass Leute aktiv geworden sind, als sie bemerkten, dass etwas fehlt (spontan fallen mir Luca und ich ein, es gibt aber auf jeden Fall noch weitere).
Dann noch etwas zur vergangenen Abstimmung, die Ryu angesprochen hat: Die Argumente der Contra-Seite der Abstimmung damals waren grob zusammengefasst: "Der Einstieg ist zu schwierig, wir brauchen ein Konzept, wie wir den neuen Usern helfen können." Und das ist ein völlig anderes Thema, weshalb die Kritik, dass bei der Abstimmung die Pro-Seite weniger Argumente aber mehr Stimmen hatte, meiner Ansicht nach unberechtigt ist.
Abschließend: Ryu, direkte Wortwahl ist ja schön und gut. Aber deine Direktheit geht teils klar in den beleidigenden Bereich. Und etwas, an dem viele Leute mit Ideen und Entwürfen gearbeitet haben, etwas, das ich mühsam im TestWiki nachgebaut habe, einfach als "Verschandelung" und "schrecklich" abzustempeln ist respektlos und unangemessen. Direktheit ist gut, aber es gibt einen Unterschied zwischen "Das gefällt mir nicht, das, das und das sollte geändert werden" und "Das ist scheiße". --DeXter 14:53, 29. Apr. 2020 (CEST)
Ich hatte eigentlich vorgehabt, mich hier vorerst noch zurückzuhalten, aber es gibt doch ein paar Sachen, die ich gerne loswerden würde. Ich kann Ryus Argumente grundsätzlich nachvollziehen. Wir weisen an vielen Stellen darauf hin, dass es Baustellen im Wiki gibt und sind jederzeit bereit, zu helfen, wenn jemand etwas machen möchte, aber nicht so richtig den Einstieg findet. Das Problem ist: Sowas passiert so gut wie nie. Ob es daran liegt, dass die Leute nicht wissen, dass sie helfen können, oder schlicht nicht helfen wollen, lässt sich natürlich nur schwer mit sicherheit sagen, aber es ist davon auszugehen, dass tatsächlich beides der Fall ist. Und so, wie sich momentan die VBW entwickeln, würde ich sogar so weit gehen und behaupten, dass letzteres in den vergangenen paar Jahren deutlich stärker auftritt als zuvor. Woran das jetzt liegt, sei mal dahingestellt, aber führt auf jeden Fall etwas interessantes auf: Bei den Leuten bringt uns auch nen Haufen Stellenanzeigen nichts. Für die, die ohnehin interessiert sind, muss ich Ryu dahingehend recht geben, dass diese sich auch freiwillig umsehen werden und beim Mitmachen und in der globalen To-Do fündig werden. Selbstverständlich würde es denen aber auch nicht schaden, wenn sie die Stellenanzeigen hätten. Und dann gibt es noch die, die unvoreingenommen im Wiki unterwegs sind und weder direkt dagegen sind, zu helfen, noch bewusst hier sind, um zu helfen. Auf die würden sich die Stellenanzeigen vermutlich am ehesten auswirken. Zu der Positionierung möchte ich mich an dieser Stelle nicht wirklich äußern, ich habe jetzt einige Designs gesehen, die teils mehr oder weniger vielversprechend waren, habe mir selber auch einige Gedanken gemacht, wo man die Box platzieren könnte und bin zu dem Schluss gekommen, dass es keine perfekte Möglichkeit gibt, mit der man alle zufrieden stellen kann. Man wird hier also irgendwie einen Kompromiss finden oder eine Abstimmung durchführen und danach eine harte Linie fahren müssen.
Etwas, dass mich aber schon länger bei den Stellenanzeigen stört und das ich schon mehrfach erwähnt habe, für das mir aber bisher niemand eine Lösung liefern konnte: Der Inhalt dieser Anzeigen. Sinnvollerweise würde man möglichst einfache Aufgaben angeben, damit Neulinge sich einfacher im Wiki einfinden können, ohne großartiges Vorwissen mitzubringen. Bisher ist es mir aber nicht gelungen, in einem meiner eigenen Projekte eine Aufgabe zu finden, die einfach genug ist, um diesem Anspruch gerecht zu werden und gleichzeitig nicht schnell genug einfach von mir selbst erledigt werden könnte. Vielfach ist es dabei auch wichtig, dass Aufgaben dringend sind, obwohl sie einfach sind. Ich werde unter keinen Umständen Aufgaben zurückstellen, die dringen erledigt werden müssen, nur weil sie einfach genug sind, dass sie ein blutiger Anfänger übernehmen könnte. Und damit wird auch meine Sorge offensichtlich: Einfaches ist häufig dringend und so einfach, dass ich es am schnellsten selber erledige, während lediglich komplexe Aufgaben liegen bleiben. Ich leite zwar "nur" drei Projekte im Wiki, gehe aber davon aus, dass es anderen genau so gehen wird, dass sie nicht in der Lage sein werden, Aufgaben zu stellen. Und dadurch befürchte ich, dass die Stellenanzeigen über kurz oder lang entweder (nahezu) leer stehen werden oder wieder aufwendige Aufgaben, wie sie bislang im Missionsbrett zu finden sind, hinzugefügt werden.
Abschließend noch zwei Punkte: Zum einen hatte mich damals bei der Abstimmung für die Stellenanzeigen ausgesprochen, obwohl ich bereits damals besorgt war, dass sich kein sinnvolles Konzept für den Inhalt finden würde und bislang scheint sich diese Sorge zu bewahrheiten. Sollten andere ebenfalls besorgt sein, dass sie selbst nichts zu den Anzeigen hinzuzufügen haben, möchte ich dazu aufrufen, zu überdenken, wie zukunftsfähig diese Idee tatsächlich ist. Wenn ich da mit meinem Projekt alleine stehe, dass ich dem nichts hinzufügen könnte, werde ich dem ganzen aber natürlich nicht im Weg stehen. Zum anderen muss ich mich auch gegen Ryus Wortwahl aussprechen. Ich kann nachvollziehen, dass du nicht ganz zufrieden mit dem Design und der Ausführung bist, aber das lässt sich definitiv anders ausdrücken. Eine weitere Verfolgung der Umsetzung wurde damals in einer fairen Abstimmung beschlossen, und wie alle Abstimmungen werden wir mit dem Ergebnis leben und nicht einfach alles umwerfen, nur weil einer nicht zufrieden ist. Du kannst aber natürlich wie sonst auch versuchen, einen besseren Vorschlag einzureichen; wenn es dir die Arbeit wert ist, kannst du sogar einen Vorschlag erstellen, der in eine vollkommen andere Richtung geht und die erzielten Punkte auf einem völlig anderen Weg erreicht. Ich behaupte einfach mal, dass wir grundsätzlich auch von den Stellenanzeigen als solchen absehen, wenn es einen Vorschlag gibt, der unseres Erachtens nach das Ziel der Nutzer-Anwerbung besser erreicht. Bis dahin wird die aktuelle Diskussion aber weiter verfolgt, du kannst zusätzliches Feedback angeben, aber das Vorhaben zu Stoppen ist definitiv nicht Sinn der Diskussion. -- RobbiRobb 15:41, 29. Apr. 2020 (CEST)
Sorry wenn du oder sonst wer sich auf den Schlips getreten fühlt. Ich werde allerdings meine Meinung nicht ändern nur damit sie jemanden gefällt. Und wie du sagst ich bin direkt. Wenn etwas Scheiße ist, dann kannst du sicher gehen das ich auch schreibe das es Scheiße ist. In dem Fall finde ich es lediglich Schrecklich, da es mMn das Gesamtbild verschlechtert. Und dabei bleibe ich auch. Klärt erstmal was in diese Box rein soll. Davon steht nirgends etwas. Und ich glaube auch nicht wenn eine Liste mit sämtlichen Projekten und davor nem "dieses Projekt braucht Mitarbeiter" die User animiert den Sinn und Zweck eines Wikis zu verstehen. Das dies zum Ziel führen wird, glaube ich seit der Baustellenbanner Diskussion nicht mehr. Auch so müsste-man-mal-machen-Sachen.... Es gibt unzähliges was was auf der To-Do versauert oder allgemein bekannt ist oder (an die Leute gerichtet die mich privat bzgl. Klamotten aus StSd angeschrieben haben mit Worten du hast es doch sonst auch immer gemacht, wann machst du es endlich mal, hoffe das ist dann auch vollständig...) Es wird einfach immer abgewälzt, da die Leute selbst keine Intention haben oder es für sie zu aufwendig ist. Und wenn es für "erfahrene" User zu aufwendig ist, dann wird sich ein Neuling dessen garantiert nicht annehmen. Daher sollte mMn andere Optionen angedacht werden. Und aus diesem Grund habe ich mich größtenteils aus dieser Diskussion raus gehalten. Nun geht es aber darum das News (ich betone halbierung das heißt: aus einer Box zwei zu machen) oder ein anderer Bereich dessen weichen soll. Und da bin ich wie gesagt dagegen. Zurück zum Kernpunkt was soll in diese Box rein, wie wäre es mal mit einer Liste der Angaben die da rein soll! So eine Projektliste scheitert ja schon am Wort XdW... Sobald der Inhalt geklärt ist starten wir einfach ne Abstimmung wo das Ding hin soll. Sollte die Mehrheit es auf die HS wollen so sei es... Auf die Hauptseite gehört es mMn aus vielen Gründen die bereits ellenlang diskutiert worden nicht hin. Ich werde diese hier nicht wiederholen. Das kann ja jeder selber nachlesen. Sobald Inhalt und Ort geklärt ist kann sich daran gemacht werden sich hier ein Design zu überlegen. * Ryuichi ~ 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-manMäh 17:10, 29. Apr. 2020 (CEST)

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

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

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

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

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

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

Abstimmung: Design der Stellenanzeigen-Box auf der Hauptseite

Abstimmung beendet. Variante 3 wird umgesetzt

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, Pokémon-Icon_674.png 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-manMä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. ka.gif 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

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! Pokémon-Icon_674.png 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:

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 ka.gif 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. Pokémon-Icon_674.png 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-manMä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-manMä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-manMä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. 🤔 ~ 418.gif 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-manMä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... -- 359.png 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-manMä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 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)