MarioWiki:Proposals/Archive/51: Difference between revisions
No edit summary |
(Archiving) |
||
Line 521: | Line 521: | ||
This proposal would seemingly have [[Para-Goomba (Mario Clash)|this enemy]] be in the same nebulous group as [[Goomba|this enemy]], without listing [[Galoomba|the steps]] [[Flying Goomba|in between]]. What we have now makes the most sense to me, and doesn't lump a bunch of stuff into an unworkable mess. <small>(Also, what do you have against obsessing over taxonomy? It's one of the few ways I can distract myself from my bouts of depression...)</small> [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 21:47, 17 April 2018 (EDT) | This proposal would seemingly have [[Para-Goomba (Mario Clash)|this enemy]] be in the same nebulous group as [[Goomba|this enemy]], without listing [[Galoomba|the steps]] [[Flying Goomba|in between]]. What we have now makes the most sense to me, and doesn't lump a bunch of stuff into an unworkable mess. <small>(Also, what do you have against obsessing over taxonomy? It's one of the few ways I can distract myself from my bouts of depression...)</small> [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 21:47, 17 April 2018 (EDT) | ||
:There's also the fact that a current proposal of mine is dependent on the current system, and this proposal's time will end before that one's will; ergo, if this wins, it will render mine invalid, and as such, this seems like little more than an attempt to sweep the rug out from under my feet to me. And I don't particularly like that. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 02:26, 19 April 2018 (EDT) | :There's also the fact that a current proposal of mine is dependent on the current system, and this proposal's time will end before that one's will; ergo, if this wins, it will render mine invalid, and as such, this seems like little more than an attempt to sweep the rug out from under my feet to me. And I don't particularly like that. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 02:26, 19 April 2018 (EDT) | ||
===Replace enemy sections with an infobox entry=== | |||
{{ProposalOutcome|failed|2-2-9|no change}} | |||
Add an <code><nowiki>|</nowiki>enemies=</code> section to <nowiki>{{</nowiki>[[Template:Levelbox|Levelbox]]<nowiki>}}</nowiki> and move "Enemies" sections (like [[World 1-1 (Super Mario Bros.)#Enemies]]) to the infobox. This information doesn't seem like it's worth a whole section since it's already covered in the overview section, and small lists (which is the case in most levels) would fit perfect in an infobox, especially if they were comma separated instead of bulleted. | |||
While it's true that having some level articles with enemies sections and some with enemies in the levelbox would be inconsistent, I think this has to be considered with the usefulness of having sections with small lists of enemies. | |||
'''EDIT:''' Alex95 suggested the enemies levelbox section could be collapsible, solving my main concern with adding enemies sections to the levelbox. I've made an example of how this could look [[User:The Retro Gamer/Levelbox|here]] (any suggestions for changes are welcome). | |||
'''EDIT 2:''' <s>I think there's another important point that needs to be addressed: what ''should'' be included in the enemies sections? As this may directly affect this proposal's outcome, I've opted to add it in, as I'm still within the editing window for the proposal.</s> I just moved it to a new proposal, for semantic distinctiveness, and a slightly increased voting period. | |||
'''Proposer''': {{User|The Retro Gamer}}<br> | |||
'''Deadline''': May 7, 2018, 23:59 GMT | |||
====Move all enemies sections to the levelbox, with the enemies section being collapsible.==== | |||
<s>{{User|Alex95}} - I suppose I'll agree with myself.</s> | |||
<br \><s>{{User|The Retro Gamer}} <s>Per my proposal. Edit 1: I'm thinking about how to (and if I will) revise my proposal; I don't think this reformatting will work well on a grand scale for levels with more than 20 enemies.</s> Edit 2: Alex95 suggested that the infobox section could be collapsible, and I like this option very much; it elegantly solves the space concern while putting infobox-appropriate information in the infobox. '''Edit:''' No longer my preferred option; see my vote above. | |||
<br><s>#{{User|Supermariofan67}} Per Alex95</s> | |||
#{{User|Reboot}} Per | |||
#{{user|Wildgoosespeeder}} The concern over a long enemy list isn't a big one because MediaWiki CSS styles we use start the list collapsed (<code><nowiki>mw-collapsible mw-collapsed</nowiki></code>). See [[mediawiki.org:Manual:Collapsible elements|here]]. Leaving an enemy list as an article section instead of in an infobox makes the specific vital level information look excluded. A level infobox should include basic level information, such as time limit, world-level, music, etc., which I see enemies as that type of information. | |||
====Add enemies to the levelbox, but keep the enemy sections==== | |||
#{{User|The Retro Gamer}}: <s>I would prefer the other option, but I'll still vote here as a fallback. While the enemies sections do fill space, I honestly think most of the content regarding the level's enemies should be covered in the level's description (usually in the section titled "Layout"). The list of enemies is side information that might be good in certain circumstances, but I don't think it's useful to the general reader.</s> However, I still support this option because I don't think it's bad to have some infobox/article redundancy, since an infobox allows for a concentrated organization of information. '''Regarding Yoshi the SSM's vote, see my comment below; implementing this change would not be that much work with a bot process.''' | |||
#{{User|Toadette the Achiever}} While I still think less is more, especially with infoboxes, I can envision this solution working as an alternative. This is my first choice. | |||
====Don't add enemies to the levelbox==== | |||
#{{User|Doc von Schmeltwick}} -Some levels have MASSIVE amounts of enemy variation, which would cause a cluster if in the infobox. | |||
#{{User|Toadette the Achiever}} Second choice: less is more, especially with infoboxes. Per Doc. | |||
#{{User|Yoshi the SSM}} Per Doc's comments. <s>Also, this would require a lot of work (hundreds of pages) with very little difference. This slight difference doesn't warrant that massive work for it to be done. Whether it is just the proposer or multiple users.</s> | |||
#{{User|BBQ Turtle}} Per all, this would just be overfilling the infobox. | |||
#{{User|TheFlameChomp}} Per all. I also don't feel we should add it to the infobox and keep it in the article, as that seems redundant. | |||
#{{User|Waluigi Time}} Per all. | |||
#{{User|L151}} Per all, utterly redundant. | |||
#{{User|Chester Alan Arthur}} Per all. | |||
#{{User|Alex95}} - Despite giving you the collapsed chart information, I'm going to have to oppose. Having the same list in two places seems repetitive and outright relocating the list to the infobox just seems detrimental. It's easier to keep the lists where they are, not just for readability, but it's also easier editing-wise. | |||
====Comments==== | |||
@Doc von Schmeltwick: Can you provide an example of a level article with a large amount of enemy variation? I'm not trying to doubt you, I just want some context so I can understand better. [[User:The Retro Gamer|<span style="color:red;">--The</span>]] [[User talk:The Retro Gamer|<span style="color:green;">Retro</span>]] [[Special:Contributions/The Retro Gamer|<span style="color:blue;">Gamer</span>]] 20:49, 29 April 2018 (EDT) | |||
:Actually, I see what you mean, I really underestimated the amount of enemy variation in some levels, how annoying: [[The Great Maze]] takes the cake, with a whopping ''71'' enemies! I'll think about how to revise (or whether to remove) my proposal. [[User:The Retro Gamer|<span style="color:red;">--The</span>]] [[User talk:The Retro Gamer|<span style="color:green;">Retro</span>]] [[Special:Contributions/The Retro Gamer|<span style="color:blue;">Gamer</span>]] 21:17, 29 April 2018 (EDT) | |||
::Although on the other hand, "The Great Maze" is kind of an exception, with the next-most enemy populated level being [[Super Star Dash]], with 42. It's still a lot, though. [[User:The Retro Gamer|<span style="color:red;">--The</span>]] [[User talk:The Retro Gamer|<span style="color:green;">Retro</span>]] [[Special:Contributions/The Retro Gamer|<span style="color:blue;">Gamer</span>]] 21:25, 29 April 2018 (EDT) | |||
Ok, for reference, here's a list of the top 11 most-enemy populated levels: | |||
<span class="mw-collapsible mw-collapsed"> | |||
#[[The Great Maze]]: 71 enemies | |||
#[[Super Star Dash]]: 42 enemies | |||
#[[Nisekoi: Tsugumi & Marika]]: 39 enemies | |||
#[[NWC 2015-2]]: 32 enemies | |||
#[[World 16-2 (Super Mario Maker for Nintendo 3DS)]]: 30 enemies | |||
#[[Wavy Beach 5-5]]: 23 enemies | |||
#[[World 12-2 (Super Mario Maker for Nintendo 3DS)]]: 22 enemies | |||
#[[Bowser's Chambers of Doom]]: 21 enemies | |||
#[[Ship Love]]: 21 enemies | |||
#[[NWC 2015-3]]: 20 enemies | |||
#[[Wavy Beach 5-4]]: 20 enemies</span> | |||
[[User:The Retro Gamer|<span style="color:red;">--The</span>]] [[User talk:The Retro Gamer|<span style="color:green;">Retro</span>]] [[Special:Contributions/The Retro Gamer|<span style="color:blue;">Gamer</span>]] 21:44, 29 April 2018 (EDT) | |||
:To me, any list of more than like 5 things is too much for an infobox, as it invariably either stretches it down or looks cluttered if there's any more than that. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 21:55, 29 April 2018 (EDT) | |||
::That's the thing... ''most'' levels are not even in the 20's range. I would imagine 10 is the average, but I'm doing counts right now. [[User:The Retro Gamer|<span style="color:red;">--The</span>]] [[User talk:The Retro Gamer|<span style="color:green;">Retro</span>]] [[Special:Contributions/The Retro Gamer|<span style="color:blue;">Gamer</span>]] 22:07, 29 April 2018 (EDT) | |||
:::Here are the counts I've got. They're slightly overcounted because they include some worlds, but the bias shouldn't affect the general trend. For those interested, these numbers were calculated from an iterative regular expression search (using regex of the form <code><nowiki>== ?Enemies ?==(?>\n\*[^\n]*){</nowiki>''#''<nowiki>}(?!\n\*)</nowiki></code>) of a export generated from a recursive subcategory and page search of [[:Category:Levels]]; if anyone else does a count and gets different results, please tell me. | |||
*19 enemies: 4 pages | |||
*18 enemies: 1 page | |||
*17 enemies: 7 pages | |||
*16 enemies: 8 pages | |||
*15 enemies: 8 pages | |||
*14 enemies: 11 pages | |||
*13 enemies: 19 pages | |||
*12 enemies: 12 pages | |||
*11 enemies: 38 pages | |||
*10 enemies: 41 pages | |||
*9 enemies: 56 pages | |||
*8 enemies: 72 pages | |||
*7 enemies: 82 pages | |||
*6 enemies: 148 pages | |||
*5 enemies: 216 pages | |||
*4 enemies: 281 pages | |||
*3 enemies: 332 pages | |||
*2 enemies: 307 pages | |||
*1 enemy: 208 pages | |||
::This proposal could also have a boundary, where only levels with under a certain amount of enemies would have the enemies relegated to the infobox. My concern is that the renovation of the ''DKC'' levels will add a lot of small lists of enemies, when these could just be in the infobox. [[User:The Retro Gamer|<span style="color:red;">--The</span>]] [[User talk:The Retro Gamer|<span style="color:green;">Retro</span>]] [[Special:Contributions/The Retro Gamer|<span style="color:blue;">Gamer</span>]] 22:43, 29 April 2018 (EDT) | |||
:::We really do not need ''every'' statistic in the infobox, especially regarding variance.... (also geeze how did you get all those so fast?) [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 23:00, 29 April 2018 (EDT) | |||
::::It's directly relevant to this proposal, since you brought up the question of enemy lists being too long for the infobox. The point there is, ''most'' enemy lists are shorter than 6 enemies. I could make the votes more nuanced by having one section voting for specific limits. And I'm also aware of the next question: inconsistency. I don't think it's unreasonable to have certain pages to have enemies in the infobox, while others have it in the article body; one could consider that levels over a certain number of enemies are notable in their number of enemies, rather than considering the general case requiring a section. [[User:The Retro Gamer|<span style="color:red;">--The</span>]] [[User talk:The Retro Gamer|<span style="color:green;">Retro</span>]] [[Special:Contributions/The Retro Gamer|<span style="color:blue;">Gamer</span>]] 23:24, 29 April 2018 (EDT) | |||
:::::I think this should be an all-or-nothing deal so as to not have arbitrary exceptions happen, and I'm going with "nothing." [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 23:25, 29 April 2018 (EDT) | |||
::::::But the exceptions wouldn't really be arbitrary, since they could be based off the statistics above. You're welcome to vote how you please, but I think lists under a certain amount of enemies shouldn't be kept in the article body just for the sake of consistency. [[User:The Retro Gamer|<span style="color:red;">--The</span>]] [[User talk:The Retro Gamer|<span style="color:green;">Retro</span>]] [[Special:Contributions/The Retro Gamer|<span style="color:blue;">Gamer</span>]] 23:35, 29 April 2018 (EDT) | |||
Still thinking over, so I'm not going to vote yet, but keep in mind that a "spoiler box" is a thing as well. Like in [[Template:Species-infobox]]. Perhaps this new section can be coded like that, if space is the main issue. {{User:Alex95/sig}} 00:20, 30 April 2018 (EDT) | |||
:I was not aware of that option. I think that option would be the optimal outcome, solving the space issue completely. I'll add that to the list of options and add my vote to that. [[User:The Retro Gamer|<span style="color:red;">--The</span>]] [[User talk:The Retro Gamer|<span style="color:green;">Retro</span>]] [[Special:Contributions/The Retro Gamer|<span style="color:blue;">Gamer</span>]] 00:36, 30 April 2018 (EDT) | |||
::The collapsability changes nothing for me, as I still find it looks bad, and is a detrimental change in general. Enemy lists are too ''important'' to be relegated to the small text, particularly that is hidden. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 14:17, 30 April 2018 (EDT) | |||
:::Oh, I thought we were still keeping the information in the article anyway. Misread the proposal. Yeah, the list of enemies in the level is rather important to have confined to an easily missable section in the infobox, so either both should be there or nothing should change imo. {{User:Alex95/sig}} 14:23, 30 April 2018 (EDT) | |||
::::...I don't understand: both of what? '''''Just''''' relegating the sections to the infoboxes (rather than also keeping the current sections) seems to look rather unprofessional and make all of the articles look more short than they need to be IMHO. {{User:Toadette the Achiever/sig}} 15:16, 30 April 2018 (EDT) | |||
:::::How about the new option "Add enemies to the levelbox, but keep the enemy sections": it seems like most people don't have a problem with the enemies being in the levelbox, but some (most?) would also prefer to keep the enemies sections. Another thought: the levelboxes could just be a pure list, while the enemies section in the article could include counts. [[User:The Retro Gamer|<span style="color:red;">--The</span>]] [[User talk:The Retro Gamer|<span style="color:green;">Retro</span>]] [[Special:Contributions/The Retro Gamer|<span style="color:blue;">Gamer</span>]] 15:39, 30 April 2018 (EDT) | |||
::::::I still think this should not be added to the infobox at all. Mariowiki's policy is "only once," and having it in the infobox is less preferable than having a list on the article itself. Ergo, it should not be on the infobox at all, as that would be either redundant or pushed out of the way unnecessarily. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 17:31, 30 April 2018 (EDT) | |||
:::::::I just read over [[MarioWiki:Once and only once]]. That policy is sort of vague and appears to have been written to address multiple pages about the same thing, no infobox redundancy. In particular, I ''don't'' think it should apply to infobox redundancy, because infoboxes ''are'' basically mostly redundant information reorganized; the article's lead section usually covers much of the same information. But it is true that some of the same points ("One of the versions will soon be out of date") could possibly apply to this kind of redundancy. | |||
:::::::I think this proposal hinges on the importance this wiki's community places on enemy lists to an article; I do not find them particularly important because they are (or should be) covered in the level layout section, but others (like yourself) are free to disagree. [[User:The Retro Gamer|<span style="color:red;">--The</span>]] [[User talk:The Retro Gamer|<span style="color:green;">Retro</span>]] [[Special:Contributions/The Retro Gamer|<span style="color:blue;">Gamer</span>]] 18:13, 30 April 2018 (EDT) | |||
::::::::I just don't think they should be in the infobox. Furthermore, that starts a slippery slope: Should we mention how many coins/bananas appear, and which are situational? Should we list how many containers of various types, such as boxes, crates and barrels? How many areas of weak ground with secrets under them there are? How many springs? How many background elements? How many points are feasible? The point is, this could go on recursively until eventually we're at how many a-presses it takes, and we don't need to go there. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 18:28, 30 April 2018 (EDT) | |||
:::::::::I just think lists without descriptions look a bit ugly in the middle of articles which otherwise have sections filled with descriptions. I can see your slippery slope argument, and I do think we have to be careful about adding things to the infobox. In your ''Should we list how many...'' sentences, I'm a bit unclear if you think non-noteworthy things will get shoehorned into the infobox to avoid the scrutiny of an article section, or if you're worried about nuanced things being simplified in the infobox. [[User:The Retro Gamer|<span style="color:red;">--The</span>]] [[User talk:The Retro Gamer|<span style="color:green;">Retro</span>]] [[Special:Contributions/The Retro Gamer|<span style="color:blue;">Gamer</span>]] 18:49, 30 April 2018 (EDT) | |||
::::::::::My point is, we don't want the infobox to cover absolutely everything; that's what the article itself is for. And large lists look ''far'' uglier in the infobox than they do on the page itself, because infoboxes are intended to be shorter than the article, regardless of collapsability. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 18:52, 30 April 2018 (EDT) | |||
:::::::::::The reason why it looks ugly in the article to me is all the whitespace to the right when browsing articles on desktop. I think infoboxes are meant to provide quick access to basic information about an article, and enemies are basic information about a level that also usually isn't ambiguous (like coin counting) or trivial (like the number of background elements). [[User:The Retro Gamer|<span style="color:red;">--The</span>]] [[User talk:The Retro Gamer|<span style="color:green;">Retro</span>]] [[Special:Contributions/The Retro Gamer|<span style="color:blue;">Gamer</span>]] 19:04, 30 April 2018 (EDT) | |||
::::::::::::I prefer whitespace to bloated infoboxes, myself. If need really be, we could always feature a gallery of sprites/model renders/screenshots, which would take up empty space and not be brushed out of the way. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 19:21, 30 April 2018 (EDT) | |||
::::::::I want to point out that they are covered in the level layouts if they are really relevant to the layout. Just, not in a list form. The enemy section helps us to know which enemies appear without searching for them in the layout. {{User:Yoshi the Space Station Manager/sig}} 18:36, 30 April 2018 (EDT) | |||
:::::::::Which is why we have them listed in reasonably-sized text under a header that ''isn't'' in the infobox, where the text is small, and easily-missable if it's collapsed. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 18:49, 30 April 2018 (EDT) | |||
@Yoshi the SSM: Regarding the amount of work, keep in mind the changes could be implemented smoothly using a bot process with a bit of care (I used the same strategy to count the number of enemies in enemy sections above). [[User:The Retro Gamer|<span style="color:red;">--The</span>]] [[User talk:The Retro Gamer|<span style="color:green;">Retro</span>]] [[Special:Contributions/The Retro Gamer|<span style="color:blue;">Gamer</span>]] 19:34, 30 April 2018 (EDT) | |||
:Oh. Ok. I'll change it soon. But won't entire remove due to Doc's comments. Also, Part 1 doesn't need to be part of the proposal. That needs to be an entirely new proposal. Otherwise that would make two different outcomes the same proposal. And if one pass and the other didn't, we don't have anything for it. Also, if one ended in a tie and the other didn't... yeah. {{User:Yoshi the Space Station Manager/sig}} 10:49, 1 May 2018 (EDT) | |||
::The outcomes are directly related, I think, because the viability of moving enemies sections to the levelbox is directly related to whether the enemies sections (in the loosest sense of the term: both levelbox sections and article sections) include enemy counts. It was intended to be a matrix of options, where one can choose what degree the enemy lists should specifically cover, while. We already have multi-option proposals, so I don't see how this would confuse the system. But I don't have a deep understanding of closure specifications in multi-option proposals; Pass/fail is a bit oversimplified for them, since different pass outcomes may be radically different. If something was a tie, then status quo would be kept for that part of the proposal. | |||
::<s>If others express concern though, I will split it out into its own proposal.</s> I've thought this over again (with TheFlameChomp also commenting in an edit summary), and I remembered there's already precedent for related but separate simultaneous proposals, so I've moved that to a separate proposal. [[User:The Retro Gamer|<span style="color:red;">--The</span>]] [[User talk:The Retro Gamer|<span style="color:green;">Retro</span>]] [[Special:Contributions/The Retro Gamer|<span style="color:blue;">Gamer</span>]] 13:24, 1 May 2018 (EDT) <small>(Edited: 13:44, 1 May 2018 (EDT))</small> | |||
@Wildgoosespeeder What I worry about is how it will look '''un-'''collapsed, when the "show" button is clicked. Not to mention that it still starts a slippery slope of what "basic level information" is. Every type of item? Every type of object? Every type of NPC species? Every type of obstacle? Amount of signs? Amount of trees? Amount of ''butterflies''? Note how those got progressively more and more absurd. This is another thing I'm worried about. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 13:21, 1 May 2018 (EDT) | |||
:It could start a slippery slope, but I think that enemies is both basic enough (after all, it already has its own section in most articles) and unambiguous enough to have a list in the levelbox. Since we already have infoboxes with hideable contents, I don't see how adding collapsed contents here would be a problem if the contents are semantically suitable for an infobox (the point of contention). [[User:The Retro Gamer|<span style="color:red;">--The</span>]] [[User talk:The Retro Gamer|<span style="color:green;">Retro</span>]] [[Special:Contributions/The Retro Gamer|<span style="color:blue;">Gamer</span>]] 13:33, 1 May 2018 (EDT) | |||
::I'm not too concerned about the whitespace created if the infobox is overly long uncollapsed. If worse comes to worse, I believe we can add scroll bars (see {{tem|wide image}}). The infobox should only include basic information for a quick overview, as the body of the article should have the details. Listing enemies is rather basic compared to describing how to get through a level. --{{User:Wildgoosespeeder/sig}} 16:46, 1 May 2018 (EDT) | |||
:::But is much less basic than, say, time allotted, level number, theme, etc, as those are either statistics or single variables, not big lists. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 16:50, 1 May 2018 (EDT) | |||
::::I am reminded of Bulbapedia and routes ([[Bulbapedia:Kanto Route 9|Kanto Route 9]] and [[Bulbapedia:Sinnoh Route 209|Sinnoh Route 209]]). Maybe something with more pizazz would do better than a very basic and boring list? Maybe the problem is not the infobox but rather presentation? --{{User:Wildgoosespeeder/sig}} 16:57, 1 May 2018 (EDT) |
Revision as of 21:04, May 7, 2018
Create a template for FA archivesTemplate:ProposalOutcome Baby Luigi's proposed system has been a success so far. However, since we use a template for most archives, why not this one? The table columns are long and repetitive enough to get cumbersome to archive, anyways, so I propose we use a template for archiving featuring (as well as unfeaturing) nominations. I have two drafts, which you can view here and here. Let me know in the comments if there are any issues or possible fixes you have in mind with the templates. Proposer: Toadette the Achiever (talk) Support
OpposeComments@YoshiFlutterJump: This was Baby Luigi's intended layout, and I don't see how structuring it the way you suggested is entirely possible anyways. (T|C) 20:15, 11 February 2018 (EST) I suggest putting a few rows as example next time so we can see how the template looks when used properly.--Mister Wu (talk) 19:49, 16 February 2018 (EST) Add a small link to MarioWiki:Appeals in the reminder/warning/last warning templatesTemplate:ProposalOutcome We have an appeal system that is not used a whole lot, and one of the reasons it's not used is simply because it's not that visible; it requires digging around our maintenance and policy pages to find it, so many users may not even know that such a system exists. Some of us do manually link to there when we occasionally hand out the templates, but why not make the process automatic? After all, this system is directly linked to those templates, and I don't see any reason to segregate the two processes entirely. Here's an example of what I want these to look like
Any changes to wording or comments, please note. Proposer: Baby Luigi (talk) Support
OpposeCommentsRegarding a rule in MarioWiki: Appeals, (1#: Reminders and/or Warnings given by an administrator cannot be appealed.), I had challenged it on Discord and I want to see that rule removed, hence why I haven't added an extra line saying that "Keep in mind that X given out by a member of staff cannot be appealed). But I don't know what the staff's official final say on that rule is, so I will edit that line accordingly once I get official confirmation. Ray Trace(T|C) 22:17, 11 February 2018 (EST)
For reference, here’s what the old userspace reminder said:
Delete the articles for Galaxy and Galaxy 2's conjecturally-named "minigames"Template:ProposalOutcome We currently have articles on four "minigames" from Super Mario Galaxy, namely ray surfing, Bob-omb Blasting, Bubble Blowing, and Star Ball Rolling, as well as two more from Galaxy 2, Crate Burning and Fluzzard Gliding. However, out of all of these, only ray surfing is officially called that in-game. I slapped {{ref needed}} templates on the other Galaxy "minigames'" articles, but I'm pretty sure they're outright conjecture. The ones from SMG2, Crate Burning and Fluzzard Gliding, actually have {{conjecture}} templates. Even worse, "Star Ball Rolling" and "Bubble Blowing" aren't even minigames. The Star Ball and Bubble are just game mechanics that change how Mario or Luigi move through a level, and these "minigames" only exist in this wiki's imagination. The Star Ball Rolling article is completely redundant with the Star Ball article. Galaxy's bubbles don't have their own article, but even if they do deserve a separate article, the correct answer would be to simply split them off, not create an article for a nonexistent minigame. Which is why when I brought this up on Galaxy's talk page a couple months ago, my thoughts were that these two specifically were the ones that needed to be put down. After all, Bob-omb Blasting, Crate Burning, and Fluzzard Gliding are conjecturally-named too, but at least they're actual minigames, right? But now that I've thought about it, those don't deserve articles either. There exist plenty of nameless minigames, such as the Hoohoo Spirit collecting and Guffawha Ruins platform jumping games from Mario & Luigi: Superstar Saga, numerous bonus games from the Donkey Kong Country series, and several racing games from Donkey Kong 64, which don't have articles, and I can't think of any that do. In other words, there's no precedent for the existence of articles on nameless minigames. Stuff like "Bob-omb Blasting" and "Crate Burning" can simply be described in the articles for the missions that feature these "minigames", which is how stuff like this is handled for other games (like the Blooper surfing missions or Roller Coaster Balloons from Sunshine), so why should Galaxy and Galaxy 2 be any different? So let's solve this inconsistency. Here are our options:
Proposer: 7feetunder (talk) Delete all of the conjecturally-named minigames
Delete Star Ball Rolling and Bubble Blowing only
Do nothingCommentsChange the link in the Category barTemplate:ProposalOutcome In the category bar at the bottom of most pages whenever a category is included on the page is a link that leads to Special:Categories. This helps absolutely no one. Special:Categories is simply an alphabetical list of every category used on the wiki, but gives no information on how editors, both present and future, should set them up. MarioWiki:Categories on the other hand gives a comprehensive explanation on how categories should be used, from category trees to the order and specifics of the categories. This proposal is simply meant to see who agrees with changing the link in MediaWiki:Pagecategorieslink from Special:Categories to MarioWiki:Categories. Here's an example of how this can be helpful. A reader who wants to get into editing is looking over a page as an example, say Goomba's. There's an infobox, article structure, images, etc. At the bottom is a bar with a list of categories. Wanting to know more about how these categories are structured, they may expect the "Categories" link to lead somewhere useful. It doesn't, and now this reader has to search through pages or ask for help on where to go. Even long-time editors, such as myself, would like an quick and easy way to get to the page they're looking for. Rather than go through those steps, the category link should just lead to the page with an explanation. Special:Categories gives a list of what categories are in use, but MarioWiki:Categories actually tells you how to use them. Proposer: Alex95 (talk) Support
OpposeCommentsI do support the proposal, but your options are rather... biased. Hello, I'm Time Turner. 13:08, 25 February 2018 (EST)
The link is really there for the reader (99% of wiki visitors), not the editors. Your scenario imagines a reader who wants to get into editing, but that is a very low percentage case. The vast majority of our traffic only reads. If they want to get into editing, they will be introduced to our help pages and {{Wikipolicy}} at some point and see the categories link. The target audience of MarioWiki:Categories is the editor and isn't as useful as Special:Categories if your only goal is exploring the site. A reader can use the search box on Special:Categories to check out different categories we have, for example. The info on MarioWiki:Categories about our category structure and where to put categories probably isn't the reading that visitors came to the site for (deep Mario lore). Editors and would-be editors seeking category help will find MarioWiki:Categories through our help pages, where as visitors are not going to know that Special:Categories exists without the link since they're not roaming through Special:SpecialPages. That Categories link appears across the wiki, on every namespace, and it takes you to a page that let's you explore all the wiki's categories (makes sense). Not sure it should take you to a policy page instead! --Steve (talk) 14:33, 25 February 2018 (EST)
Template:ProposalOutcome I was browsing the wiki for the first time for a while and I sawdust Proposals is currently llisted under community alongside the 'Shroom, the chat and Mario Boards. The thing is though those other three things all fall under the social part of this site and less so the wiki part of the site Whilst proposals is less so part of the social aspect and more related into improving the wiki. The Navigation area the other hand has links that is all related to the wiki it's self and many of the links inside it are related to helping improve the wiki. I just think it would make far more sense Proposals was under navigation rather than community. Proposer: NSY (talk) SupportOppose
CommentsDo have any idea how visually unappealing that would look? Yikes! --Steve (talk) 14:33, 25 February 2018 (EST)
You know, you *could* argue that "Featured Articles" are just as "community"-based like proposals are and thus would argue to put that under "community". Ray Trace(T|C) 18:11, 28 February 2018 (EST)
Make an exception for the Super Smash Bros. series in our coverage policyTemplate:ProposalOutcome This proposal stems largely from a discussion thread started by Blocky, and it's recommended to read that first. If we wanted to change our current coverage of the Super Smash Bros. series, our current coverage policy offers two logical options: the series is either a guest appearance or a crossover. Calling it a guest appearance is not that good: there are a notable amount of characters, locations, items, and other elements pulled directly from the Mario franchise, and it figures heavily into the Smash series' promotion, so it doesn't seem particularly right to say that the Mario content is on the same level as Captain Rainbow or SSX on Tour. At the same time, however, calling it a crossover (which is the option that the wiki currently uses) isn't satisfying either: as much as the Mario content factors into the series, it doesn't take up a majority in the slightest, so it's disingenuous to treat it as if its content is equal in stature to Mario & Sonic or Fortune Street. Keep in mind that, as a crossover, every single subject within the series should get an individual page, and there's a certain point where covering every single special move and Smash Run enemy feels like it oversteps a boundary (which is to say nothing of smashwiki:the SmashWiki that already covers these subjects better than we ever could). The wiki already has made judgements about what content shouldn't be given individual pages, mainly with various stage elements, but that completely contradicts our existing policy. If neither option available to us is acceptable, then what should we do? Simple: make a third option. This proposal aims to add an exception to our coverage policy, essentially saying that the Smash series is neither a crossover nor a guest appearance, but something unique unto itself. If it is excluded from the other sections, then it would be entirely possible to come up with systematic changes that wouldn't involve broadly changing how every series is covered. Note that this proposal doesn't say what will change; it merely leaves the door open for changes in the first place. Discussions and proposals about the particulars can take place afterwards. A draft of the proposed section can be found at this link. Proposer: Time Turner (talk) (with input from Superchao (talk)) Support
OpposeCommentsPer what I said in the thread. I see no issue with how we are presently doing things, but I'm also open to a change. Due to that, I can neither support nor oppose, but I'll agree with whatever option goes throughI kinda have to anyway :) 19:43, 23 February 2018 (EST)
Sort of a nebulous proposal. Can't pass this and then make major changes because there's no detail of changes to be made here (other than make Smash its own thing, but we don't know what that really means yet). So then you'd need a new proposal of the changes you'd like to make, but you could have just made that proposal without this one. Anyway, it's a start! --Steve (talk) 14:33, 25 February 2018 (EST)
Pie for Everyone. Pie for EVERYONE. Pie. For. ALL.I know what you're expecting. It's the first of April, I know many of you hope for one of Ghost Jam's little pie stories. I'm sorry to tell you this, but...this isn't going to be one. Or at least not precisely. If you've jumped straight to this paragraph and didn't look at the proposal title, I'd suggest maybe scrolling down to something else that needs voting on. This is your last chance. Don't look up, don't read on, don't vote. Just either scroll on quickly or close your browser tab.
Anomaly #0103-Wiki This...effect, I guess would be the way to think of it, is a meme of sorts that effects users who take on the title of editor, either granted by others or taken by personal choice, and encourages them to add or otherwise embellish false information articles in a given Wiki's database. In the first stages, this is nearly indistinguishable from standard 'new editor' behavior. As the meme takes hold, however, this escalates into anger and destructive behavior. In several cases I've observed, effected users will continue to add false information and argue the point well past a reasonable point. Eventually, and I don't believe this part is an effect of the meme, rather a result of general human frustration, users will begin to not engage effected users and allow the changes they have forced to stay. The transition between these two states seems to happen fairly quickly and is highly contagious. You see, the third stage starts as soon as the changes made by effected users is no longer disputed. At this point, the article becomes an instance of the meme and is capable to spreading it to others. Infection happens instantaneously to anyone who reads the article. User infected with the meme in this way jump directly to the second stage of infection. Really, the contagious part is what makes this thing so scary. I've seen it jump across a few users all ready, but it seems to be...growing, if that makes sense, with each person. I fear that if this isn't gotten under control soon, it could grow large enough to engulf entire userbases in a matter of minutes. I'll see what I can come up with. Notes - October 2007 Notes - November 2007 Note - April 2014 Note - April 2015 Notes - The Age of Pies Pie help you all. So there you have it. I can already feel the urge to spread this to other places tapering off...but it's still there. Try to resist, that's my only advice. For the love of Pie, you have to. PIE. Proposer: Ghost Jam (talk) Support
SUPPORT
S.U.P.P.O.R.T
Praises for the Word of Pie
Do not create Super Mario Odyssey sublocation pagesTemplate:ProposalOutcome The current Super Mario Odyssey Kingdom nav-template has (mostly red) links for all the named locations within every kingdom in the game. I think each one of these locations getting an article is a bad idea. While some of these locations are pretty big and unique, like the Deep Woods and Snowline Circuit, most of them are simply extentions of the main world or too small and not so relevant by themselves, and presenting them disconnected from each other would make these pages feel short on content. Island in the Sky (Bowser's Castle), Rocky Mountain Summit (Forgotten Isle), Heliport (New Donk City), Glass Palace (Bubblaine) and Salt-Pile Isle (Mount Volbono) are some examples of locations which are, at most, glorified platforms with a Checkpoint Flag on/near them. There are also three Tostarena Ruins locations, three Water Plaza locations, two Iron Path locations; having an article for each one is unnecessary as they are part of a whole rather than defined places (which is also the case of things like the Waterfall Basin and Stone Bridge in Fossil Falls and the Tostarena Northwest Reaches). I believe there is enough space for information about these areas in the actual kingdom articles. An overview (what it is, where it is on the map, general layout, what enemies and characters are there) can be written in five lines or so. We do not have articles for Super Mario Galaxy planets, not even for the giant, named ones like the Haunted Mansion in Ghostly Galaxy. Even if (unlike the planets) the SMO locations are named in-game, they are as relevant to their game as planets are to SMG. So, I propose:
Proposer: Shiny K-Troopa (talk) Do not create any Odyssey sublocation article
Create separate articles for notable sublocations only
Leave everything as it is
Comments@TimeTurner, I see where you're going, actually. My problem is with locations that really do not have anything significant happening in them and those that blend in with the kingdom overworld. I was thinking more about how the Super Mario 64 world pages include sub-areas like the Lethal Lava Land volcano and the Snowman's Land igloo. In my perception the Courtyard in the Lake Kingdom is as important as the starting location in Tiny-Huge Island, for example, but I fully understand that the name can make a difference and that people might oppose because of it. About the selection, it might not be 100% complete, I confess. Shiny K-Troopa Talk 19:09, 2 April 2018 (EDT)
Add a section to MarioWiki:Naming regarding technical restrictionsTemplate:ProposalOutcome I'm surprised no one has talked in depth about this yet. Sure, we don't have that many technically restricted names, but we still have some, so I think we should set in stone a policy for these titles. Take the castle levels from Super Mario World as an example. "#1 Iggy's Castle" is located at "Iggy's Castle" rather than "1 Iggy's Castle"; while the former title is fine, it might still cause some initial confusion for the newer readers. Basically, what I'm proposing is that we start officially use closely-matched titles for subjects if the correct title is technically restricted. A draft of the proposed text can be found here. Also, if you're wondering, Porplemontage green-lighted this proposal. Proposer: Toadette the Achiever (talk) Support
Oppose
CommentsSo if this succeeds, what will happen to the Iggy's Castle article? (Also, remind me for when I start my own franchise, to name a character "<[[#klunk]]>''," symbols included, just to mess with the ensuing wiki.) Doc von Schmeltwick (talk) 02:04, 29 March 2018 (EDT)
Just thought about it but how about a notice template for such pages? --Wildgoosespeeder (talk) (Stats - Contribs) 17:00, 29 March 2018 (EDT)
@Reboot: It's not on the "assumption" that "#1" is parsed "Number One", it's about whether or not to use close matches for otherwise technically restricted titles. (T|C) 16:47, 3 April 2018 (EDT) Give the seven boss Tikis from DKCR their own articlesTemplate:ProposalOutcome Because the rest of their official names have just been discovered in a datamine of the original game. Proposer: BooDestroyer (talk) Support
Oppose
CommentsI forgot to mention, but in order, they're called: Kalimba, Maraca Gang, Gong-Oh, Banjo Bottom, Wacky Pipes, Xylobone, and Cordian. BooDestroyer (talk) 18:07, 29 March 2018 (EDT) @YoshiFlutterJump They are different from the Koopalings in that the Koopalings are:
also, why should Gary or Johnson not have articles? They deserve articles as much as Otto or Heronicus. Doc von Schmeltwick (talk) 23:05, 30 March 2018 (EDT)
I fail to see how character personalities is any sort of viable argument against article creation. I can get on board with their extremely minor role and their appearance, but not their personality. Ray Trace(T|C) 00:54, 31 March 2018 (EDT) I should point out one thing: we don’t even have an article for them as a group. Tiki Tak Tribe just covers every enemy in the game, and is not devoted to the boss Tikis. At the very least, we need an article for them as a group. -YFJ (talk · edits) 13:19, 31 March 2018 (EDT) Smash Bros. Articles: What Stays and What Goes?Template:ProposalOutcome The previous Super Smash Bros. proposal allowed us to justify previous exceptions to Smash coverage (i.e. the stage hazards and Smash Taunt characters) and paved a path for future exceptions. After the discussion on the forums, this proposal will outline exactly what further exceptions will be made, as in which pages will be merged and which pages will remain intact. With that out of the way, let's dive in!
Note that this proposal isn't completely exhaustive: there are scattered pages like List of Mii Outfits and List of bonuses in Super Smash Bros. that also deserve scrutiny, but considering the subtle differences between each of them, it'd be best to tackle those individually and not overburden this proposal. Still, there's plenty that's already being covered here. It's a lot to take in, but these are changes that should be taken for all the same reasons as before. It's disingenuous to treat the Super Smash Bros. series as if its Mario content is even close to that of existing crossovers with the franchise like Fortune Street and Mario & Sonic. The wiki should strive to reflect that. Proposer: Time Turner (talk), with input from Superchao (talk) Support
Oppose
CommentsDoc von Schmeltwick (talk), if you have problems with malware or whatever on SmashWiki, take it up with Porplemontage (talk), as he is the wiki owner, so that way future malware doesn't spread. Oh yeah, just because the name Super Smash Bros. is one word off from Super Mario Bros. doesn't make it a derivative series. In early development, it wasn't even going to have Nintendo characters.
@Time Turner: Why would we merge all special moves to the character that uses them? Wouldn't that cause inconsistencies? (T|C) 18:33, 2 April 2018 (EDT)
Shouldn't, on this basis, Meta-Ridley be merged with (the due to be kept) Ridley article rather than with a List of bosses article? It's the same character, after all. - Reboot (talk) 19:09, 2 April 2018 (EDT)
Template:ProposalOutcome As Doc von Schmeltwick (talk) has been so energetically pointing out recently, the way we handle "species" bears little-to-no resemblance to reality - an octopus is not a species related to a mushroom, even if an Octoomba is obviously derived from a Goomba, and trying to justify it is waaay beyond the bounds of a simple infobox list. And the likes of fish skeletons for one example aren't even breedable! And, generally, obsessing over taxonomy seems rather misplaced for a Mario fansite. This primarily affects {{species-infobox}}. In the immediate aftermath, this proposal will be achieved by putting all three variables in the "See also" line (with appropriate {{#if:*}}s so that they can be stacked vertically), inside a new {{{see also}}} variable, which will be on the documentation and override the older variables if both the new and old variables are used. In the longer term, it may require use of a bot to make wiki-wide changes, especially if full alphabetisation (as opposed to priority-based sorting) is desired. Proposer: Reboot (talk) SupportOppose
CommentsSmall question: You bring up alphabetical ordering vs. priority ordering, but which one is this proposal rolling with? Hello, I'm Time Turner. 13:57, 17 April 2018 (EDT)
This proposal would seemingly have this enemy be in the same nebulous group as this enemy, without listing the steps in between. What we have now makes the most sense to me, and doesn't lump a bunch of stuff into an unworkable mess. (Also, what do you have against obsessing over taxonomy? It's one of the few ways I can distract myself from my bouts of depression...) Doc von Schmeltwick (talk) 21:47, 17 April 2018 (EDT)
Replace enemy sections with an infobox entryTemplate:ProposalOutcome
Add an While it's true that having some level articles with enemies sections and some with enemies in the levelbox would be inconsistent, I think this has to be considered with the usefulness of having sections with small lists of enemies. EDIT: Alex95 suggested the enemies levelbox section could be collapsible, solving my main concern with adding enemies sections to the levelbox. I've made an example of how this could look here (any suggestions for changes are welcome). EDIT 2: Proposer: The Retro Gamer (talk) Move all enemies sections to the levelbox, with the enemies section being collapsible.
Add enemies to the levelbox, but keep the enemy sections
Don't add enemies to the levelbox
Comments@Doc von Schmeltwick: Can you provide an example of a level article with a large amount of enemy variation? I'm not trying to doubt you, I just want some context so I can understand better. --The Retro Gamer 20:49, 29 April 2018 (EDT)
Ok, for reference, here's a list of the top 11 most-enemy populated levels:
--The Retro Gamer 21:44, 29 April 2018 (EDT)
Still thinking over, so I'm not going to vote yet, but keep in mind that a "spoiler box" is a thing as well. Like in Template:Species-infobox. Perhaps this new section can be coded like that, if space is the main issue. 00:20, 30 April 2018 (EDT)
@Yoshi the SSM: Regarding the amount of work, keep in mind the changes could be implemented smoothly using a bot process with a bit of care (I used the same strategy to count the number of enemies in enemy sections above). --The Retro Gamer 19:34, 30 April 2018 (EDT)
@Wildgoosespeeder What I worry about is how it will look un-collapsed, when the "show" button is clicked. Not to mention that it still starts a slippery slope of what "basic level information" is. Every type of item? Every type of object? Every type of NPC species? Every type of obstacle? Amount of signs? Amount of trees? Amount of butterflies? Note how those got progressively more and more absurd. This is another thing I'm worried about. Doc von Schmeltwick (talk) 13:21, 1 May 2018 (EDT)
|