MarioWiki:Proposals

Writing guidelines
None at the moment.

New features
None at the moment.

Removals
None at the moment.

Replace enemy sections with an infobox entry
Add an  section to  and move "Enemies" sections (like World 1-1 (Super Mario Bros.)) 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 here (any suggestions for changes are welcome).

EDIT 2: 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. I just moved it to a new proposal, for semantic distinctiveness, and a slightly increased voting period.

Proposer: Deadline: May 7, 2018, 23:59 GMT

Move all enemies sections to the levelbox, with the enemies section being collapsible.
- I suppose I'll agree with myself.  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. 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.
 * 1) Per Alex95
 * 2) Per
 * 3) The concern over a long enemy list isn't a big one because MediaWiki CSS styles we use start the list collapsed . See 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

 * 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. 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.
 * 1) 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

 * 1) -Some levels have MASSIVE amounts of enemy variation, which would cause a cluster if in the infobox.
 * 2) Second choice: less is more, especially with infoboxes. Per Doc.
 * 3) Per Doc's comments. 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.
 * 4) Per all, this would just be overfilling the infobox.
 * 5) Per all. I also don't feel we should add it to the infobox and keep it in the article, as that seems redundant.
 * 6) Per all.
 * 7) Per all, utterly redundant.
 * 8) Per all.
 * 9) - 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. --The  Retro   Gamer  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. --The   Retro   Gamer  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. --The   Retro   Gamer  21:25, 29 April 2018 (EDT)

Ok, for reference, here's a list of the top 11 most-enemy populated levels:
 * 1) The Great Maze: 71 enemies
 * 2) Super Star Dash: 42 enemies
 * 3) Nisekoi: Tsugumi & Marika: 39 enemies
 * 4) NWC 2015-2: 32 enemies
 * 5) World 16-2 (Super Mario Maker for Nintendo 3DS): 30 enemies
 * 6) Wavy Beach 5-5: 23 enemies
 * 7) World 12-2 (Super Mario Maker for Nintendo 3DS): 22 enemies
 * 8) Bowser's Chambers of Doom: 21 enemies
 * 9) Ship Love: 21 enemies
 * 10) NWC 2015-3: 20 enemies
 * 11) Wavy Beach 5-4: 20 enemies

--The  Retro   Gamer  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. 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. --The   Retro   Gamer  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 ) 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. --The   Retro   Gamer  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?) 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. --The   Retro   Gamer  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." 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. --The   Retro   Gamer  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. 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. --The   Retro   Gamer  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. 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. 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. 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. --The   Retro   Gamer  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. Doc von Schmeltwick (talk) 17:31, 30 April 2018 (EDT)
 * I just read over 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. --The   Retro   Gamer  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. 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. --The   Retro   Gamer  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. 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). --The   Retro   Gamer  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. 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. 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. 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). --The  Retro   Gamer  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. 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.


 * If others express concern though, I will split it out into its own proposal. 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. --The   Retro   Gamer  13:24, 1 May 2018 (EDT) (Edited: 13:44, 1 May 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)
 * 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). --The   Retro   Gamer  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 ). 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. -- 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. Doc von Schmeltwick (talk) 16:50, 1 May 2018 (EDT)
 * I am reminded of Bulbapedia and routes (Kanto Route 9 and 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? -- 16:57, 1 May 2018 (EDT)

Part 2: What should be included in enemies lists?
I think enemy lists should include counts, because that helps define the level: a level with one throwaway enemy is quite different from a level heavily populated by a certain enemy. As a corollary to this point, I have removed my vote from my original main option of the other proposal, since enemy counts as a defining factor in the level means they probably deserve their own section. Obviously, implementing this would be a long-term process, but I think if we're already listing the enemies, it's not too hard to gradually add the counts (and situational specifications, like counts in different versions) as well.

Proposer: Deadline: May 8, 2018, 23:59 GMT

Include enemy link and enemy counts

 * 1) (Proposer)

Create a template for reception tables
According to the reception and sales policy:

''"A review listing template has been created to more efficiently present the information and prevent the summary from being a succession of "so and so said X, while so and so said Y". Here's the code and an explanation of the parameters:

"

However, I don't see why this is actually a template yet. It won't really hurt to add one (and given the many prior proposals to templatize certain repetitive features of the wiki), hence why I am proposing this. There are still many reviewers and aggregators out there, so it may take a while to add them in, but I've added quite a bit in the meantime. The only real problem is figuring out how to configure the URLs (since some links are inconsistent with others on the same site), but it's also something we can fix as we go on.

One big change that supersedes the original is listing the reviews and aggregators in respective alphabetical order. I think that's a good way to go since none of the other possible methods seem doable.

I have an aforementioned draft, which you can view here.

Proposer: Deadline: May 8, 2018, 23:59 GMT

Support

 * 1) Let's get rid of the raw coding in favor of a template; per proposal.
 * 2) Per proposal.

Oppose

 * 1) - I honestly think it's easier to code a table from scratch rather than using templates, but that may be just me. Especially when there's a ready-made code listed as above. Even if it's the same type of table, transclusions for tables/charts can be finicky. And by "template" in the policy, it means there's a ready-made code ready to be used, not necessarily the "templates" we use to transclude information.

Comments
I'm pretty split on this proposal. On one hand, I'm not a huge fan of copying this very specific table with its raw-coding displayed article to article to article but on the other hand, I just don't see too much benefit from creating a template out of this either because of the sheer number of variables this review table has, unlike the proposal outcome template which is far simpler to write out. I don't have particularly strong opinions either way, though I am leaning on support there because I also think displayed the raw coding for this table in our policy page looks really messy from our end. 22:43, 6 May 2018 (EDT)

Miscellaneous
None at the moment.