MarioWiki:Proposals/Archive/51

Create a template for FA archives
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: Deadline: February 18, 2018, 23:59 GMT

Support

 * 1) Per proposal.
 * 2) Per proposal, although I think it should look more like the one used for proposals.
 * 3) Per proposal.
 * 4) - A template like this would be more consistent and useful.
 * 5) Per proposal.
 * 6) Looks clean enough, and a template should always help with consistency.

Comments
@YoshiFlutterJump: This was Baby Luigi's intended layout, and I don't see how structuring it the way you suggested is entirely possible anyways. 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 Appeals in the reminder/warning/last warning templates
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: Deadline: February 18, 2018, 23:59 GMT

Support

 * 1) Strong Support: It should be clear for users what to do if they feel they were formally warned for no reason. It just SHOULD be clear, period. I also strongly agree that appeal rule #1 should be repealed, since admins (like any other user) may make mistakes, and appealing a warning issued by an administrator would make zero difference compared to appealing a warning issued by an normal user. Baby Luigi clearly knows what she's doing, and I intend to stand by this proposal by all means.
 * 2) Both users have really good points. Per both Toadette the Achiever and Baby Luigi.
 * 3) Per proposal. Can't see any reason not to do this.
 * 4) Per all. Users should be able easily learn about their options.
 * 5) Per all. The only downside is that we’ll get a LOT more bad faith appeals, but that’s not a major issue.
 * 6) Per all, I only found out it existed after someone recommended I used it, so it should be more visible.
 * 7) Per all.
 * 8) I didn't even know appealing was a thing until I saw this proposal. Per all.
 * 9) Per all.
 * 10) - This is so trivial, I honestly thought we would've done this day one. This gets all my support, and then some.
 * 11) Per everyone except LuigiMaster123 and especially YoshiFlutterJump.
 * 12) From what I can see, the current way to access it is through a maintenance template....which isn't particularly helpful. In fact, it's a hindrance.
 * 1) From what I can see, the current way to access it is through a maintenance template....which isn't particularly helpful. In fact, it's a hindrance.

Comments
Regarding 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. 22:17, 11 February 2018 (EST)
 * I did bring this up in the admin boards like I said I would. I'm honestly not sure where we all stand on the Appeals line, but we've unanimously agreed that admin warnings should not be appealed. 23:02, 11 February 2018 (EST)
 * I like how I don't count. --Glowsquid (talk) 23:06, 11 February 2018 (EST)
 * ...I misread your post, so never mind I guess. 23:16, 11 February 2018 (EST)
 * Two edit conflicts in a row?! Anyway, one reason we have that rule is that admins can already remove warnings without appeals, so what’s the point of appealing an admin warning if you can just personally ask the admin who gave it to you to remove it?  Sounds illogical to me.  And by the way, we used to have that link on the userspace reminder, but it was removed when the template was repurposed for unknown reasons. - 23:19, 11 February 2018 (EST)
 * I had argued that if that was the case, then why do we even need MarioWiki:Appeals in the first place? Why can't we settle it internally with emails, pm's, DM on chat, etc.? I mean, with this system, there will already be discussion taking place on the staff boards regardless if the administrator themselves issued a warning or not if that was made in bad faith. 23:31, 11 February 2018 (EST)

For reference, here’s what the old userspace reminder said: This notice is official and is considered to be a permanent record'' focusing on the edit history for your account. This notice is not to be removed under any circumstances; any attempt to remove this notice will lead to a warning being issued. If this notice was not issued by an administrator and you feel you have received it in error, you may appeal it.'' - 11:12, 14 February 2018 (EST)


 * @YoshiFlutterJump In your first comment, you stated that there is no point in appealing an admin warning because that admin won't let it be removed. There's more than one admin. So the issuer is clearly going to vote for it to stay, but that doesn't mean that the other admins will. It is for this reason that I support an allowance for admin warning appeals. None will probably succeed, and it's not up to me, but that's what I have to say.
 * 19:37, 16 February 2018 (EST)
 * Yeah, I understand, but you can’t change anything big about how the wiki works unless you’re an admin, and as Alex95 said, the admins are in favor of their own warnings not being appealed...which makes sense because it’s their issued warnings in question. And while it may not be a technical right of the admins, they have the right to remove ANY warning, without an appeal, even if another admin issued it, so long as they are doing so for good reason. - 20:58, 16 February 2018 (EST)

Delete the articles for Galaxy and Galaxy 2's conjecturally-named "minigames"
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 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 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:


 * Delete all of the conjecturally-named minigames: If this option passes, Bob-omb Blasting, Bubble Blowing, Star Ball Rolling, Crate Burning, and Fluzzard Gliding all go, with only ray surfing surviving. Any relevant content these articles contain will be merged into other articles.
 * Delete Star Ball Rolling and Bubble Blowing only: If you feel that the others should stay, let's at least get rid of the "minigames" that can't even be called that.
 * Do nothing: Self-explanatory. Star Ball Rolling and Bubble Blowing continue their meaningless existence.

Proposer: Deadline: February 20, 2018, 23:59 GMT

Delete all of the conjecturally-named minigames

 * 1) My preferred option.
 * 2) Second preferred choice. After all, we'd basically be the Department of Redundancy if the articles stick around, but I digress. Per 7feetunder.

Delete Star Ball Rolling and Bubble Blowing only

 * 1) Even if my preferred option doesn't win, these need to go.
 * 2) Yeah, we really need to say bye-bye to these.  Why do we have these articles anyway?  But I don’t quite agree with deleting the others; they’re minigames, just like ray surfing, and as such need to stay.  The other minigames just need a  template, not outright deletion, and we do need to give the nameless minigames from other games articles as well.
 * 3) Per YoshiFlutterJump.
 * 4) Per all.
 * 5) - Per all. I always wondered why they were there, but I never bothered to do anything about it :P
 * 6) Per all.
 * 7) Preferred choice. Star Ball Rolling and Bubble Blowing aren't minigames; they're just fancy ways to traverse the galaxies. Per all.
 * 8) Per all.
 * 9) Per all.
 * 10) - Wait, we classed these as minigames? I didn't even know we did that. While the others are certainly mini-games by some definition, these... Aren't. They need to go.
 * 11) It's practically the same as riding Plessie, and that doesn't require a separate article, but I think the others should be classed as minigames, per all.
 * 12) Those two surely aren't minigames, but rather mechanics used in a few galaxies.
 * 13) Per all.

Change the link in the Category bar
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. 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: Deadline: March 4, 2018, 23:59 GMT Cancellation date: February 25, 2018, 21:00 GMT

Support

 * 1) - We strive to be helpful!
 * 2) Per proposal.
 * 3) Per Alex95.
 * 4) Per proposal.

Comments
I do support the proposal, but your options are rather... biased. 13:08, 25 February 2018 (EST)
 * How so? 13:11, 25 February 2018 (EST)
 * "Keep things unnecessarily complex" is your opinion, and it immediately paints anyone voting for that option in a negative light. "Support/oppose" works fine. 13:20, 25 February 2018 (EST)
 * Ah. I like trying to put a humorous spin on things, but I see what you mean. Corrected. 13:22, 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 at some point and see the categories link. The target audience of 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! -- 14:33, 25 February 2018 (EST)
 * Would it be beneficial to add a quick explanation of categories at the top of Categories? 15:11, 25 February 2018 (EST)
 * A link to an overall comprehensive list both does and doesn't seem all that useful to me. It really depends on the situation. Is it a reader looking through the categories, or is it an editor trying to figure out how the categories should be placed? If anything, they should lead to each other.
 * ...That might be a better idea, actually. 15:24, 25 February 2018 (EST)
 * Even if it is an editor, we don't just link to policy pages in the body of an article. Special:Categories is a neutral thing that covers the entire wiki. You could be on someone's talk archive, click the Categories link, and it's about mainspace categorization. Doesn't fit in all cases. As editors, you're naturally biased to want to make the site tuned for editors, but the wider audience has no use for our policy pages. Special:Categories at least allows for more exploration of the wiki, which is why they're visiting. -- 15:48, 25 February 2018 (EST)
 * Hmm, alright, I guess that make sense. From the reader's point of view, a comprehensive explanation of how categories are set up would make no sense to them. And if you're an editor, chances are you already know of MarioWiki:Categories anyway. I'll cancel this, however, a link between both of them would be helpful to both sides, whether you want to get into editing and want to know more or you need to find the category that needs to be added. 16:00, 25 February 2018 (EST)

Move "proposals" from "community" to "navigation" on the sidebar
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: Deadline: March 4, 2018, 23:59 GMT

Support

 * 1) Per my proposal.

Oppose

 * 1) - The main proposals page is under "community" because it involves the community. Users come here to propose new changes and to vote on said changes. It's as much of a community project as The 'Shroom or the forums.
 * 2) Per Alex95.
 * 3) Per Alex95.
 * 4) Per Alex95.
 * 5) Per Alex95.
 * 6) Per Alex95.

Comments
Do have any idea how visually unappealing that would look? Yikes! -- 14:33, 25 February 2018 (EST)
 * I hate to question the person who runs the wiki but could you explain why it would be visually unappealing.
 * For the reasons Alex95 brought forth, I guess. 16:00, 26 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". 18:11, 28 February 2018 (EST)
 * I would support that. - 20:15, 28 February 2018 (EST)
 * So would I. 22:49, 28 February 2018 (EST)
 * FA's are the best articles the wiki has to offer. Sure they're picked by the community, but the final list of articles for people to peruse are just wiki articles, and wiki articles are navigation. Proposals are 100% community input on changes to make. -- 14:28, 1 March 2018 (EST)

Make an exception for the Super Smash Bros. series in our coverage policy
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: (with input from ) Deadline: March 9, 2018, 23:59 GMT

Support

 * 1) Per proposal.
 * 2) Per proposal.
 * 3) Per proposal.
 * 4) Per proposal.  I was actually more than ready to tag these pages for deletion anyway.
 * 5) Per proposal.
 * 6) Per proposal.
 * 7) Sounds good. If someone wants to find out more information about anything in the SSB series, they go to either the Smash Wiki or another Wiki which deals with the character they are looking for. Per proposal.
 * 8) - Per proposal... I can't say anything else here, it's all been said, weh.

Comments
Per 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 through  I kinda have to anyway   :)  19:43, 23 February 2018 (EST)
 * I find we cover a lot of non-Mario things than Mario things when covering the Super Smash Bros. series, since Time Turner says that Mario content doesn't even come close to the majority of Smash's total content. I am neutral, just like Alex95, but because I don't know what this proposal will imply in the future. My hope is less non-Mario content gets covered on as SmashWiki offers the best coverage and is the most cited source. We should just merely link to SmashWiki for non-Mario things but use  for Mario game fighters/items/stages/etc., but I realize a lot of people are not on-board with that idea so easily. Don't think of my thoughts as negative. We should take pride in our ability to specialize in the Mario franchise instead of overreaching into other series that those articles end up mostly getting neglected for longer periods of time. -- 00:01, 24 February 2018 (EST)


 * I do agree that our coverage of Smash is probably more comprehensive that necessary, but I don't think that there is really anything wrong with it. Nevertheless, I do see what Time Turner is saying. I would support this, but choose not to until I have some idea of exactly what we are changing. It's not enough for me to decide whether or not to make a change; I need to agree with whatever change is specifically proposed.
 * 14:09, 25 February 2018 (EST)
 * To be clear, no specific change is being proposed at the moment. This proposal's goal is to allow those future changes, whatever they may be, to occur in the first place. 14:10, 25 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! -- 14:33, 25 February 2018 (EST)
 * I definitely intend this to be a start. I have thoughts on what should and shouldn't stay, but so does everyone else, and charging forward with "a, b, and d should all be deleted, but not c and e" would be more trouble than its worth (and that'd contradict our coverage policy in the first place, hence this proposal). 14:46, 25 February 2018 (EST)
 * Steve's comment is exactly why I'm not voting in this proposal. I've already DM'ed Time Turner how I felt about this and his comment is pretty much my reasons for concern. 18:12, 28 February 2018 (EST)
 * Exact same reason why I'm neutral myself. 15:18, 1 March 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. My name is Nae. I'm Ghost Jam's partner. You might have noticed his absence the last several weeks. While that in of itself isn't odd behavior for him, he's still normally home at least some of the time. But I haven't seen him either. I was starting to worry, so I poked through his study. I knew this wasn't a good idea. It's an unspoken rule that the untrained don't mess with tools from the unknown. On his desk was a dark leather case with a few files inside. There were several things about this that were strange. Firstly, the case was open. It might be difficult to understand why this is odd, but if you live with someone who dabbles in the ethereal enough, you begin to learn that nothing stays open long. Secondly, the contents appeared be a combination of both paper documents and holo-constructs from a datascape. Thirdly...well, the fact that it was a holo-construct from the infosphere in analog space. That requires either an enormous source of magic or a supreme act of mechanical engineering. But...it was just sitting there, like any old stack of papers. I had to look. Forgive me, I had to look. It's too late now, by the way. You can't leave, you can't scroll on. All roads will lead back here. As many of you know, Ghost Jam is one of various notable talents thaumaturgical study that find employ in the Infosphere. I knew I shouldn't have looked, he's warned me before that the untrained shouldn't mess with the occult, but I was just so worried. I can only hope that you...and so we're clear, when I say you, I don't mean that in the general, open sense, I'm speaking specifically to you, the one reading this...are strong enough to withstand what is to come. Otherwise we're all in a lot of trouble. The following is the content of the file I found. I really am sorry for this. But I have to share it. And now that you've come this far, you have to read it. There is no choice for either of us now.

--

Anomaly #0103-Wiki Notes - September 2007 This isn't going to read like my normal reports. Normally, I attempt to list the facts of my discovery, rate the danger level and jot down how I plan to handle the problem, perhaps going into more details about collaborations with other thaumaturgical researchers. And trust me when I say, in the days since Porplemontage first gave me access to the datascape, I've discovered several scary...let's call them monsters...down here. But this one is different. This is something big, that broke in from the Infoshpere outside of our little Wiki bubble and began to fester under the weight of information we've piled on over the years. I'm not yet sure where or when it got in, but dealing with it is the first problem to be solved, stopping the spread will be the next.

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 I've learned more about this meme, which I'm now calling an infohazzard after some consultation with Foundation researchers. It acts on people knowing about it. Knowing what it does, what it is, causes a person to act out in the way described in my previously submitted notes. However, an knowing about it is only the first part. The second part is taking it seriously. Most individuals take what is given to them at face value and so fall subject to the infohazzards effect. The key, I think, is identifying when the infohazzard is in effect and then finding a way to make people think it's a joke and not worth engaging with.

Notes - November 2007 I think...we've done it. Took some collaboration with some of the other wikis talents, but I believe we have the infohazzard contained and a vaccine being spread. Basically, I created an "serious" proposal with the intent of luring in the infection (about pies, of all things), which I then played off like a joke, the seriousness of the idea being the joke. Once I had confirmed infection (Son of Sons will be missed.....), a framework of paracode created by Wayoshi was set up to act as a kind of cage on the Infosphere side. The cage was then seeded by Walkazo with breed of healing flower she specifically crafted for our needs. While on the analog plane, I tossed a net of thaumaturgical energies around the database entry. In effect, we've locked it down to one place, and, via Walkazo's plants, created a way to spread the 'anti-meme' to anyone who reads the entry. We'll monitor it, but....I think we've got this under control for now.

Note - April 2014 I've been away from the wiki proper for some time now, so I thought it a good idea to check in on the 'cage'. For lack of a less complicated and more precise way to explain this, the cage needed some maintenance. Sadly, Wayoshi has long since left us and we don't any anyone else on hand with the same level of skill in paracode to work out improvements to the cages framework. It took some doing, but I believe the shielding magic Walkazo had learned once assuming her 'Kazo form mixed with stronger 'ropes' in my thaumaturgical net, the framework should hold up. We had to create another joke proposal, however, to make the cage bigger. We'll need to find a new solution, though.

Note - April 2015 We've had to expand the cage again. It's becoming too much and the Walkazo's vaccine is becoming less effective. I've taken my 'net' and anchored it on the analog plane, in the form of, well, forms. I feel rather proud of myself on this one, since the analog plane operates on a different set of physics, so long as the documents stay were I put them, a large chunk of the infection will stay put. Given these additions, we agree that the cage should hold, as is, for at least a few more years. We'll be taking the time to come up something better. We have to.

Notes - The Age of Pies Pies. Pies. Pies. PIES. PIES. P.I.E.S. Damn it, damn it, hold on. Ok, here's the deal. The infection has grown too strong to touch, but not strong enough to break the cage. I've had people contacting me near constantly for years with 'new joke ideas' for further pie proposals and the bound document in my office has become a spread vector. Just seeing it compels a person to read it and reading it causes full infection and with a completely new symptom to needing to spread it. I'd rather not pie about how I know about that pie, if you see what I'm pie-ing. Crap, this is hard to resist. I'm going to lock this thing up and hope the physical lock holds. If anyone is reading this document, know this: You're screwed. This version of the infection is not like the one you just read about this. This one can't be ignored or make a joke of. It'll spread and you will spread it. However, and this kills me to say, I've come up with the only counter measure I could think of. I've laced this paragraph with a counter-meme or sorts. You'll be compelled to post this to the proposals page first. With any luck, the measures we set up will slow the infection enough to set off the security alarms and get someone on the job.

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: Proposed Deadline: When the deed is done, by the will of PIE.

Support

 * 1) Pie
 * 2) - I WANT PIE!
 * 3) - Pie is the best food ever. Anybody who says otherwise is wrong. :)
 * 4) i demand pie
 * 5) Pie is the best! We all need pie!
 * 6) Sure, I can go for pie.
 * 7) Ладно, почему бы и нет.

SUPPORT

 * 1) PIE

S.U.P.P.O.R.T

 * 1) P.I.E.
 * 2) I have always been depressed that I was not there to turn the tides of those old PIE proposals. LONG LIVE PIE!!!!
 * 3) It's too late. I can only vote, and hope that I can find a way.

Praises for the Word of Pie

 * 1) PRAISE THE PIE
 * 2) – You got me at the word 'Pie'.
 * 3) Amen all
 * 4) pie
 * 5) Pie was created for our sins.

Do not create Super Mario Odyssey sublocation pages
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:
 * Do not create any Odyssey sublocation article: Put the information about these spots in the kingdom articles only.
 * Create separate articles for notable sublocations only: Another possibility is to create separate pages for well-defined structures and areas which are unique within their kingdom: the Top-Hat Tower, Tostarena Town, Tostarena Ruins (as a whole), Jaxi Ruins, Inverted Pyramid, Deep Woods, Water Plaza (as a whole), Underground Power Plant, Snowline Circuit, Underground Moon Caverns keep/get their articles. An overview of every location (notable or not) would go on the main article.
 * Leave everything as it is: Create articles for every Checkpoint Flag location of the game.

Proposer: Deadline: April 9, 2018, 23:59 GMT Date Withdrawn: April 2, 2018

Do not create any Odyssey sublocation article

 * Per my proposal.

Create separate articles for notable sublocations only

 * Per my proposal (I'm fine with either).
 * 1) Not giving pages to any of the locations at all, especially when they have official names and notable events take place there, seems incredibly inconsistent with how the rest of the wiki handles its locations. There's nothing wrong with Llama's Temple being separate from Angry Aztec, or Shine Gate being separate from Isle Delfino, so there should be nothing wrong with the other locations having separate articles. The planets in Super Mario Galaxy are not perfectly analogous to the locations in Super Mario Odyssey, considering how the vast majority of them don't even have names. Is the "Haunted Mansion" named officially (beyond Luigi and the Haunted Mansion, although using that as evidence is sketchy when every star mission uses capitalized titles and it could easily be referring to a generic mansion).
 * 2) Per all.

Leave everything as it is

 * 1) I'm a bit skeptical that your list is fully comprehensive, so I'd rather err on the side of caution and let things stay the same, per what I said above.

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)
 * Names are an important factor in this. One of our most general policies is that, if something has a name, it should get an article (although I usually stress that they shouldn't be the deciding factor). The biggest difference between the locations you mentioned from Super Mario 64 and the ones from Super Mario Odyssey is that Odyssey names them. It gives them an official and clear-cut declaration that this place in particular is important. As I said, I don't necessarily think that all of them should have separate articles, but not giving any of them pages is too broad. 18:43, 2 April 2018 (EDT)
 * Probably I jumped the gun with this one. Maybe we should see how the pages look first, since I don't want to cause consistency issues with this proposal. I wonder if I can withdraw it for now. Shiny K-Troopa   Talk  19:09, 2 April 2018 (EDT)
 * You are able to remove your proposal so long as it's within three days of its creation (and you must also properly archive it). 19:54, 2 April 2018 (EDT)

Add a section to Naming regarding technical restrictions
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: Deadline: April 5, 2018, 23:59 GMT

Support

 * 1) Per proposal.
 * 2) - Per proposal.
 * 3) Per proposal.
 * 4) Per proposal.
 * 5) Per proposal.
 * 6) Sounds good to me! Per proposal.
 * 7) Considering that we can't use the actual name, the closest match surely makes sense.
 * 8) Per all, this just seems like the sensible thing to do anyway.
 * 9) Per all.
 * 10) The proposal is about allowing as many characters in the original title as possible, if the suggested title has technical issues. When such a case occurs, use the   MediaWiki Magic Word to correct the title.   in URLs are used for linking to headers in a page name, like this example. Even forcing URL encoding brings up an error.  I couldn't get MediaWiki to parse this normally, so a forced URL is used to demonstrate.

Oppose

 * 1) I'm not 100% sure this has been thought through fully. Using   to add characters to the visible title that aren't in the URL (as opposed to, say, italicising a game title in a (disambig tag) seems ill-advised all by itself, and the example given of "#1 Iggy's Castle"  doesn't reassure, since it ignores that the # is pronounced as 'number' - i.e., "Number One, Iggy's Castle". "1 Iggy's Castle" is the same as "one pizza", "#1 Iggy's Castle" is the same as "Action Comics #1000".

Comments
So 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 "<>'' ," symbols included, just to mess with the ensuing wiki.) Doc von Schmeltwick (talk) 02:04, 29 March 2018 (EDT)
 * It'll be moved to "1 Iggy's Castle", with the display title unchanged so it still shows the proper title. MediaWiki doesn't like certain symbols in page titles, so have fun with that hypothetical wiki if it comes ;) 11:09, 29 March 2018 (EDT)

Just thought about it but how about a notice template for such pages? -- 17:00, 29 March 2018 (EDT)
 * That's not needed unless even cannot display the correct title.  10:56, 31 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. 16:47, 3 April 2018 (EDT)

Give the seven boss Tikis from DKCR their own articles
Because the rest of their official names have just been discovered in a datamine of the original game.

Proposer: Deadline: April 5, 2018, 23:59 GMT

Support

 * 1) Need I say more?
 * 2) These guys are like the Seven Notorious Koopalings.  Each one not only has a name, but is also a character and a boss.  It’s not quite like Gary or Johnson (whose articles SHOULD be deleted) or even the Sammer Guys.  The Tikis are characters—major boss characters at that, and not just minor NPCs.  One of them, Kalimba, even has a Smash 4 trophy.  And the fact that the Tikis only appear in a single DK game should not stop us from giving them articles.

Oppose

 * 1) A name, in and of itself, is not enough to substantiate having separate articles (see: List of Sammer Guys). Is there another reason they should have articles?
 * 2) - Per Time Turner. They may all have a name, but they aren't diverse enough (they all do the exact same thing) to justify individual articles.
 * 3) Per Time Turner.
 * 4) Per all. Plus, they're not even fought normally at all, which that case would guarantee articles.

Comments
I 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)
 * A: Bosses themselves
 * B: Characters with actual personality
 * Let me tell you one thing. The Seven Notorious Koopalings (that’s what Minion Quest calls them) hardly had personalities before Paper Jam (to the extent of having NO dialogue), and we had articles for them long before then.  While the Tikis are not bosses, they possess bosses and are key to the story.  As for your second point...minor NPCs shouldn’t get articles just because they have names.  The Tikis are not minor, though. - 23:18, 30 March 2018 (EDT)
 * Even just regarding Super Mario Bros. 3, the Koopalings had enough diversity to justify their own articles if the wiki was around then. They each had the same role, but different names and abilities. Regarding the SMB3 cartoon as well, they also had different personalities. The same cannot be said for these Tikis.
 * Gary and Johnson, according to Minor NPCs, their articles are valid. 23:23, 30 March 2018 (EDT)
 * Saying the Koopalings didn't have personalities before Paper Jam is outright wrong, remember their individual speech balloons in the SMB3 manual? The depictions in the cartoons and comics? Their pre-battle behavior in NSMBW? The Tikis all act exactly the same, and are only ever on screen for like 5 seconds each, and have no dialog. Doc von Schmeltwick (talk) 23:27, 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. 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. - 13:19, 31 March 2018 (EDT)

Smash Bros. Articles: What Stays and What Goes?
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!


 * Fighters: No changes are planned.
 * Stages: No changes are planned.
 * Items: No changes are planned.
 * Bosses: The inconsequential bosses of Subspace Emissary (Duon, Galleom, Porky, Porky Statue, and Rayquaza) will be merged to a page specifically for the mode's bosses. Tabuu and Ancient Minister remain separate due to significant relevance to the story, with Tabuu also being the final boss. By that same token, Crazy Hand, Master Hand, and Master Core will remain due to also being final bosses. Separately, Ridley will stay due to multiple appearances across more than one game.
 * Enemies: The Adventure Mode, Subspace Emissary, and Smash Run enemies will be merged into separate lists (i.e. "List of Smash Run enemies" and so on), exactly like the ones that existed previously.
 * Stage hazards: Despite my previous comment about stage hazards being exceptions, there are exceptions to that, including Dark Emperor, Flying Man, Metal Face, and Yellow Devil. These pages will be merged to the stages that they respectively appear in.
 * Assist Trophies: They will be merged to Assist Trophy, as it was previously.
 * Pokémon: They will be merged to Pokémon, as it was previously.
 * Moves: Special moves will be merged to the character that uses them (e.g. Mach Tornado, Drill Rush, Shuttle Loop, Dimensional Cape, and Galaxia Darkness will be merged to Meta Knight; for moves that are used by multiple fighters, the information will be split between them, such as with Shield Breaker), as it was previously. The exception to this is with moves performed by characters from the Mario franchise; they will remain separate.

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:, with input from Deadline: April 9, 2018, 23:59 GMT

Support

 * 1) Per proposal.
 * 2) Per proposal.
 * 3) Per proposal.
 * 4) Per proposal.
 * 5) Per proposal.
 * 6) Per proposal.
 * 7) Per proposal.
 * 8) Seems like the proposal is taking baby steps to get closer to the goal of having more limited coverage of SSB series. One day, I hope, it will be just be Mario-related content where the rest of Nintendo content (Solid Snake and Sonic too) is linked to either their respective NIWA wikis or specifically SmashWiki.
 * 9) I'm happy with these merges.
 * 10) Per everyone except Wildgoosespeeder.
 * 11) Sounds like a good idea. Per proposal. Although, moves related to Mario characters probably should stay separate. Just a thought.
 * 12) I'm fine with all of these merges as well.

Oppose

 * 1) The Bosses and enemies should stay separate from each other. Period. I will not be moved on that. They are different things with different biological categories. And why should we merge them? The Super Smash Bros. series is derivative of the Super Mario Bros. franchise. It's right there in the name. You want this all on SmashWiki? I've gotten viruses from the site before; I don't trust it. And merging stage hazards with stages makes little sense, as they are under the "Locations" category, and attempting to make an article overviewing two things of fundamentally different gameplay type invariably ends up as a cluttered cluster, because of the aforementioned icompatibility. All I see this doing is costing us a lot of information for arbitrary reasons. All, in all, very detrimental.

Comments
, if you have problems with malware or whatever on SmashWiki, take it up with, 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.
 * OK, well by that logic we shouldn't cover aspects of Diddy Kong Racing, since it was, in early development, not going to have any Donkey Kong influence. I think the idea of "only pure Mario content" is bad, as it is a rather nebulous franchise, and to be honest a good amount of the other wikis suffer from extremely bad writing. This is, plain and simply, a bad idea, which will only have detrimental effects to the wiki. Doc von Schmeltwick (talk) 18:20, 2 April 2018 (EDT)
 * Really, Doc, don't insult the wikis that we're partnered with so casually. It's irrelevant to this proposal, and it completely disparages the work that has been put into them, including the work done by several users that write for this very wiki. Making broad generalizations does not help anyone. If you think that a particular page is poorly written, you have the ability to fix it yourself, but not every single page is like that. 18:31, 2 April 2018 (EDT)
 * Except several of them don't allow IP edits, period, and require making accounts on other sites to have an account on them. And have you seen the ad amounts on many of them? My poor browser will slow even worse than when I had to deal with Norton Security! "A good amount" isn't necessarily "broad," either, it is perhaps the most nonspecific phrase one can use. Anyways, the point is, I find this proposal so fundamentally flawed and misguided that I might give up hope on this place entirely if it goes through. Doc von Schmeltwick (talk) 18:36, 2 April 2018 (EDT)
 * Why did I forget to sign again? Stupid me. Anyways, I already feel we shouldn't be covering most of Donkey Kong's games since I feel we are robbing Donkey Kong Wiki site traffic, but I don't want to stir up that hive of bees again (*shutters at my talk page*). I've given up that idea and won't push that anymore. Let's try a different game example. -- 18:35, 2 April 2018 (EDT)
 * It works both ways, regardless of your bias. Doc von Schmeltwick (talk) 18:36, 2 April 2018 (EDT)
 * The example you gave me was one I would be in support of rather than against, which you were hoping I would be against. Has nothing to do with bias. I merely suggest a different game that I would be against not covering or shifting coverage elsewhere. -- 18:44, 2 April 2018 (EDT)
 * No, I know fully well about your feelings on the matter. OK, well how about that the original Donkey Kong was going to be a Popeye game? Doc von Schmeltwick (talk) 18:48, 2 April 2018 (EDT)
 * Donkey Kong should be covered because it aids writing about Mario's rivalry with Donkey Kong (I am aware of Cranky Kong unique position, but I digress). Turns out there is an NES . Also, can't remember where I said it, but the is merely a story telling trope. Any similarities with  are just products of the trope and not rip-offs or wherever the conversation was going. -- 18:57, 2 April 2018 (EDT)
 * That doesn't change the original plan for the game. Yes, they did end up making an arcade Popeye game after Donkey Kong<'> became successful, but saying "it's different because tropes" is an irrelevant argument. Smash Bros. has storytelling tropes in the Subspace Emissary, after all. Doc von Schmeltwick (talk) 19:06, 2 April 2018 (EDT)
 * I never said they were different because tropes, but the point I was trying to make is that the conclusion of DK being a rip-off of Popeye is wrong because it dismisses the love triangle trope being a bigger factor why the game appeared similar to Popeye. -- 19:14, 2 April 2018 (EDT)
 * Literally no one but you said "rip-off." The fact is that it was going to be a Popeye game, but was retooled after they weren't given the liscence (though they later were afterwards). It's comparable to Mega Man<'>s relation to Astro-Boy. Doc von Schmeltwick (talk) 19:22, 2 April 2018 (EDT)
 * My memory is fuzzy on the details, as I remember my general feelings and reaction towards the conversation better, but the vibe that conversation some time ago was making me feel like people were implying rip-off when analyzing Popeye cartoon and Donkey Kong arcade. -- 19:26, 2 April 2018 (EDT)
 * @Wildgoosespeeder: dkwiki:Forum:Merge_with_Super_Mario_Wiki - Reboot (talk) 19:09, 2 April 2018 (EDT)

@Time Turner: Why would we merge all special moves to the character that uses them? Wouldn't that cause inconsistencies? 18:33, 2 April 2018 (EDT)
 * If you could clarify, what would be inconsistent? 18:34, 2 April 2018 (EDT)
 * Well, at the very least, shouldn't the special moves performed by Mario characters stay? 18:40, 2 April 2018 (EDT)
 * That slipped my mind. Considering past proposals, I think that it'd make sense to leave the moves performed specifically by Mario characters. I'll adjust the proposal. 18:54, 2 April 2018 (EDT)
 * I personally would think that the ones with a non-Smash equivalent, like the Fireballs, should probably stay. I personally have no problem with the idea of merging the moves, as those are less concrete and more abstract things than the enemies and bosses. Doc von Schmeltwick (talk) 18:42, 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)
 * See this can of worms as to why I'm sidestepping the issue. 19:16, 2 April 2018 (EDT)
 * The basis has been changed though - if this passes, Meta Ridley is Going Away and the examples given (since they're of Mario characters which aren't affected by the change in Mariowiki's scope re: SSB) are invalid, it's just where it goes. And it makes more sense to consolidate it together than split it over a "real" page and a list page. Plus, it's in-line with the way this proposal treats characters' moves. - Reboot (talk) 19:21, 2 April 2018 (EDT)
 * (Similarly, I feel Ancient Minister should be merged with R.O.B., not kept separate) - Reboot (talk) 19:23, 2 April 2018 (EDT)
 * You definitely raise good points, but I do think there's merit in merging Meta Ridley to the more general list. This is certainly a debatable point, though, so Meta Ridley will be removed from this proposal for the moment. The matter can be settled in the future with a talk page proposal, where it can be discussed in more depth; the same applies to Ancient Minister. 21:50, 3 April 2018 (EDT)

Replace all related species/etc lines in infoboxes with a single "See also" line
As 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. In the immediate aftermath, this proposal will be achieved by putting all three variables in the "See also" line (with appropriate s so that they can be stacked vertically), inside a new 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: Deadline: April 24, 2018, 23:59 GMT

Support

 * 1) I support my own proposal :)
 * 2) yeah I agree

Oppose

 * 1) - The way we have it now is at least reasonably organizeable. No reason to obfuscate a perfectly good system. What I've been pointing out is that it should be consistently followed without people trying to make arbitrary case-specific decisions >.>
 * 2) Per Doc.
 * 3) The proposed system is worst than what is currently in place, only to serve as a fix for one flaw in it. The problem is two-fold. Either it isn't going to be organized like it is currently (which is already in the best way it could be), or it isn't going to be known where the things start and end. Trying to do otherwise would result in the flaw coming back. And in this proposed system, if it does go to the flaw, either there would be no change or it would add stuff that is not needed to the current system (which is the more likely of the two). The proposed system causes more problems than the worth of what it fixes. And thus, I can't support, but oppose.
 * 4) While merging it into one section would deal with the issues that could arise from the initial classification, once it has been classified correctly, this is not an issue. However, this would make it harder for readers to distinguish between how the species are related, and would just be detrimental to the organisation of it. Per all.
 * 5) While I do agree with the general notion of this proposal, I feel it needs a bit more thought before it can actually go into effect, given we've used "species" for quite a while. Per all.
 * 6) Per all (also octoomba's are a goomba cause a prima guide calls them Electrogoomba's)

Comments
Small question: You bring up alphabetical ordering vs. priority ordering, but which one is this proposal rolling with? 13:57, 17 April 2018 (EDT)
 * I'm relatively agnostic. I'd probably prefer priority, since it will roughly mirror the way the "old" variables will stack initially, but if alphabetical was preferred by the consensus I'd be fine with it. It would require a bot to implement, however. - Reboot (talk) 14:00, 17 April 2018 (EDT)
 * I'm inclined to support (especially with the confusion surrounding Rocky Wrenches/Monty Moles), but does that mean the "see also" section will be included in the infobox or near the end of the page? I'd prefer the former, but I'm fine with either. 15:14, 17 April 2018 (EDT)
 * Infobox. (Which does not prohibit end-of-page sections, but that's not what this is about). - Reboot (talk) 15:17, 17 April 2018 (EDT)
 * Does this affect list of species? LinkTheLefty (talk) 15:37, 17 April 2018 (EDT)
 * Or the species categories, for that matter. 16:16, 17 April 2018 (EDT)
 * This is purely a display change on the infoboxes, not a structural change in general. It does not (currently) affect the species categories at all, although I would consider supporting a proposal about those. As for List of species, it doesn't directly affect that either, but that's already tagged rewrite-expand for being an incomplete mess with some stuff sorted under "parent" types and some not, so it doesn't really need a proposal to change to pure alphabetical sorting rather than the current part-alpha, part-hierarchical shambles, does it? - Reboot (talk) 16:29, 17 April 2018 (EDT)
 * It would basically be list of enemies if it's rewritten alphabetically. LinkTheLefty (talk) 16:47, 17 April 2018 (EDT)
 * I would suggest that, if one and only one was going to be done hierarchically, List of enemies would be the more logical option.
 * And re: your "I feel this should be more comprehensive..." edit summary, if you want to put together a more comprehensive proposal that incorporated this, I'd be prepared to withdraw this one in favour of yours. - Reboot (talk) 17:11, 17 April 2018 (EDT)
 * I don't know, I'm all for doing something - maybe just using less specific, more general terminology would suffice - but merging it all in one nebulous spot will probably cause even more confusion. LinkTheLefty (talk) 21:25, 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)
 * 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. Doc von Schmeltwick (talk) 02:26, 19 April 2018 (EDT)

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)
 * 2) Having enemy counts doesn't really seem like a bad idea, if a bit hard to correctly list in longer stages. It lets a reader know if a level is based around a particular enemy or set of enemies.
 * 3) per all
 * 4) Per proposal.

Comments
What would be listed as the enemy count for enemies that are created infinitely in a level, such as Goombas spawned from Pipes and Spinies thrown by Lakitus, if this proposal passes? -- 16:02, 8 May 2018 (EDT)

And how about enemies that respawn infinitely when off-camera, like literally everything in DKCTF? Doc von Schmeltwick (talk) 19:45, 8 May 2018 (EDT)

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)