MarioWiki:Proposals/Archive/44

Split Badge and Clothing by game
Badge and Clothing are currently long articles with several different lists; in Badge's case, you have both Paper Mario and Mario & Luigi games lumped in there. I think these lists, when split by game, are more manageable and serviceable when they are separate articles. In navigation templates, readers can look up the appropriate section rather than have their browser load a huge page with several irrelevant games. It would also be consistent to split them by game, since we already have other charts split by game. Finally, in Badge, while Dream Team and Bowser's Inside Story sections are rather small, I think it's still doable to leave them separate for consistency sake they can work if they get merged to their parent page, which is also consistent in other cases, which Walkazo has pointed out in her support.

Both will still stay as a lone article, but it's there to link all the badge/clothing lists by game into one article, and, at least in Badge's case, it will retain its history section.

Finally, the List of badge names in other languages (and clothing, if it has one; as far as I know, it doesn't) can be merged into these split articles, so it also eliminates an odd page that was created due to the badly-organized nature of those pages.

Proposer: Deadline: November 30, 2015, 23:59 GMT.

Support

 * 1) I think these two pages are better off split by game. Yeah, Badge is probably not going to remain featured, but that shouldn't be a reason against the merge, IMO. Featured articles were unfeatured as a result of organization and deletion proposals before, so that reason in of itself isn't good.
 * 2) - I supported the idea on the forum, and I support it here too. Except the part about splitting the BIS and DT badges: I disagree that it needs to be done for consistency, since we have plenty of cases where something split for one game remains merged in another (usually merged to the parent game article, rather than a separate page, but whatever, close enough). EDIT: Including the part about merging the BIS and DT badges to the game articles.
 * 3) – Per Walkazo, especially about leaving the Mario & Luigi: Bowser's Inside Story and Mario & Luigi: Dream Team Bros. information already present on the article as is.
 * 4) - Per Walkazo.
 * 5) Per all.
 * 6) Per proposal but not Walkzao, I think everything should be separated for both consistency and because it's still two separate games.
 * 7) Per all.

Comments
RandomYoshi: I think what Walkazo is trying to say is that the small information in Bowser's Inside Story and That Other Game can be just moved to a subsection in their parent articles. E.g. we remove Mario & Luigi: Bowser's Inside Story in Badge and add this same section under "Items" in Mario & Luigi: Bowser's Inside Story. 17:47, 24 November 2015 (EST)
 * If this is what was meant, then I understand the situation better. In fact, it's way better that way, so yay. 14:42, 26 November 2015 (EST)
 * I was actually advocating to leave the badges where they are, but moving them to the game pages makes more sense, and is more in line with existing coverage practices (which I was referring to as being similar to my original idea). -
 * I myself thought your implications (along with the "whatever, close enough" at the end) were that the moving method is the preferred and usual method. 16:15, 26 November 2015 (EST)
 * Nope, just that separate pages weren't the only way, as game pages retained things sometimes, so why not the badge page too? - or so I was arguing (but not anymore). -

Do not relegate charts to templates
This proposal affects, , , and any other similar templates that have been overlooked. These three are charts that were once part of their respective articles (Super Smash Bros. for Wii U, Mario Kart 7, and Mario Kart 8), but were unceremoniously split into those templates. Nobody complained, and here we are. I think it's about time somebody complained. Simply put, the advantages do not outweigh the disadvantages. I brought the topic up on one of the template's talk pages, and Walkazo, BL, and LGM chimed in with their own comments. Moving the charts doesn't make editing all that much simpler, since that's what editing via section is for, and it just makes editing the charts more complicated. Since the article still has to load the template as well, I believe that it wouldn't help all that much for loading times either. Meanwhile, sticking the charts on a template by themselves is inconvenient and makes no sense considering that they're only going to be used on one or two articles, max. These charts can easily be reincorporated back into their articles.

This proposal is not affecting rules and other protected page, such as the proposal header, since they are kept separate in order to ensure that they can only be edited by the right people.

Proposer: Deadline: December 17, 2015, 23:59 GMT

Support

 * 1) I support my proposal.
 * 2) Per proposal. Having them as templates makes it slightly more difficult/time-consuming to edit them. Templates are mainly for use on multiple pages, it makes no sense to create an entire template just for one page...
 * 3) Per myself and all involved in the talk. Get rid of 'em.
 * 4) - Per TT, I see no benefits in the current situation.
 * 5) I actually complained in person with Baby Luigi and was about to bring it up, but the latter never occurred to me. Anyway, per my comment in the talk page; templates are intended to save repetition on particular coding when it is used several times, such as navtemplates, infoboxes, notice templates, and button input. This may save text or so when you're editing an entire page, but the savings are measly when it is much more inconvenient for editors and has virtually no advantages for our readers. So, yeah, just move them back to their parent page.
 * 6) Per all.
 * 7) Just because I have no idea what "relegate" means doesn't mean a chart isn't the same as a template. Per all.
 * 8) Per all.
 * 9) Per all.
 * 10) – Per all.
 * 11) - It would make sense if content was being duplicated on multiple pages, but simply outsourcing chunks of a single page is unnecessary added complication with very little gain: long sections aren't that big of a deal, and this trend should be stopped before it spreads any further.

Comments
Wording title is kind of weird, the proposal's strength in the future may be better if it said "Stop outsourcing entire chart content to templates"; "stop" is more precise since the outsourcing is ongoing; "relegate" is vague compared to "outsource". 15:53, 10 December 2015 (EST)
 * That seems pedantic.
 * I don't see why you're always so defensive to my wording suggestions. IMO, making the wording more precise makes it easier for referrals in the future. 17:35, 11 December 2015 (EST)
 * You didn't have to make it personal. The title gets the point of the proposal across and it can be clarified as needed in the archive.

Poking around a bit more, I actually found a bit more justification for the SSB4 template: it was meant to go on both Super Smash Bros. for Wii U and Super Smash Bros. for Nintendo 3DS, so rather than having all the identical info duplicated, it'd just be in one central place, saving space and making upkeep easier, which, assuming the two games remain identical in their rosters, does make sense. The guy who made the template initially put it on both pages, but then there was an edit war on the 3DS page and ended in the removal of the template, but really, looking at the two charts, I fail to see a difference, and really, that edit summary is contradictory to what the chart was envisioned to do (and I checked, and it looks like the pre-template version of the 3DS chart was indeed the same as the Wii U / current one). I agree that a one-template-to-one-page substitution is needless complication (we actually told people to stop doing it on userpsace years ago), but it could make sense for pages that share large chunks of content. (But even then, prior discussion would be better than just striking out on one's own.) - 16:01, 10 December 2015 (EST)
 * For this case I do see the use in having the template. Maybe the proposal could be modified to say templates only used on one page are useless whereas if they're used on more than one it's fine to have them? --
 * My sister brought it up previously: "it's more convenient to edit the template once than go through it twice" but it may not have been clear to you at the time. Anyway, I've said this already: templates are supposed to make repetitive content easier to implement, but I think we can go through case-by-case rather than make a flimsy qualifier in this proposal. 16:10, 10 December 2015 (EST)


 * Just to note: the difference in the Smash Bros. tables is that certain characters that are unlockable in the Nintendo 3DS version (Bowser Jr., Ganondorf, and Ness) are available by default in the Wii U version, and both tables reflect that by listing those characters in the appropriate sections. If we were to use one table then we would have to show that difference.


 * -Toa 95 (talk)
 * Well, there goes that. There is no reason to create the template for those either. I knew there was some catch between the 3DS and Wii U games when it comes to characters. 16:18, 10 December 2015 (EST)
 * I didn't see the talk page again after I made my comment - got too busy and forgot to check back. And ah, okay, I didn't catch the different between-header placements: I just thought there were arbitrary order differences at times and the headers blended into everything. Too bad - it'd be easier to manage one set of info, but yeah, setting up a switch function to have those characters appear in different places depending on the page would probably be too much trouble for most peoples' tastes. - 16:35, 10 December 2015 (EST)

Create a Account creation encouragement template
Sometimes there are great ip users who make tons of useful contributions that help this wiki grow. Those ips are extremely welcome contributors who unfortunately, are ineligible to do advance things such as editing semi-protected pages, moving pages, creating new pages, and various other useful contributions due to their non-registered status. I think we should create a template to encourage them to join as registered. The template would be placed on ip user talk pages. I have drafted a design for this template:

Hello [ insert ip address here ], have you considered creating an account here. Your contributions to this wiki have been very appreciated but in order to unlock various other useful feature in this wiki, you will need to have an account. Having an account will increase your tool options by allowing you to create new pages, edit protected pages, vote in proposals and other discussions, upload new file media, rename pages, have a personal username and userpage. We strongly recommend you create an account to unlock these feature. Proposer: Deadline: December 25, 2015, 23:59 GMT

Support

 * 1) per proposal.

Oppose

 * 1) Per the arguments that were brought up the last time this idea was proposed: it's tedious and frankly unreasonable to have someone or even several people keeping track of every IP that pops up, IP's can be accessed by numerous individuals, and a blanket template probably won't convince them to sign up if they hadn't done so already.
 * 2) There are two main reasons this probably wouldn't work: 1.) Most IPs edit once and leave, others edit about once every few months. I haven't noticed all that many IPs who make enough edits (that is, within a reasonable time period) to make an account in the three years I've been here. 2.) Rather than a template, couldn't we just tell them in an informal message?
 * 3) Just leave it up to the individual operating the IP to see if they want to have an account or not, no need to nag them with an unnecessary template. Per Time Turner.
 * 4) - Per all here, and per the opposers of the last proposal. Also, that template is garish and painful to look at.
 * 5) Per all.
 * 6) I think this template will actually discourage users. If there are anons that are being super active and helpful, then it's better to thank them formally to encourage their signing up than to give a less caring, automated template.
 * 7) – Per all.
 * 8) Per all. I really don't think this is something we'll ever agree to doing.
 * 9) Per all.
 * 10) IPs can be IPs if they WANT to, they don't need an account to edit. per all.
 * 11) Per all; If an IP doesn't want an account, they don't need to make one.
 * 12) I don't see this going well. A lot of IP's make useful edits, but a lot of them also make edits that are very unnecessary. If we incourage them to make an account, especially the bad ones, we're going to have a problem. A lot of IP's only make one edit and leave anyway. Plus, why can't we just say it in an informal message?
 * 13) While I usually dismiss such arguments like "no one can do it" as laziness, in this case, it really is near impossible to keep track of all the IPs. No one is going to be like, "hey, I recognize that IP before!" Additionally, it's highly unlikely for IPs to check their talk pages; most just edit casually. And if the IPs really want an account, they will choose to do it themselves; I doubt that many people who acceses this site are actually aware of the account feature. They're staying an IP for a reason.

The Wording on Proposals Archived by Their Proposer
As you know, nowadays, whenever someone archives their own proposal, it is filed under "DELETED BY PROPOSER." It used to be the case that it would say "WITHDRAWN BY PROPOSER" instead. I bring this up because saying "deleted" is wrong. Deleting is more along the lines of removing altogether; this wording is odd in the case we're using it with. Here are some scenarios:

Deleted: Removed entirely from the wiki. Removed: Removed entirely from the wiki. Withdrawn: Voluntarily archived.

I'm sure there are others that could work but these are the only ones I can think of.

The two on top are misleading. The proposals aren't being obliterated from existence, except for some cases. When someone archives a proposal voluntarily because they don't want it up, they aren't really deleting it per se, only withdrawing it.

Finally, this wouldn't affect proposals vetoed by the admins and archived; they always have the wording "VETOED BY THE ADMINISTRATION." This would only affect ones removed by the proposer.

Proposer: Deadline: December 26, 2015, 23:59 GMT

Change the Wording

 * 1) My proposal.

Do Nothing

 * 1) - Seeing as most pass/fail messages are customized and unique, I feel like it's not worth bending over backwards to make the cancellation messages uniform. "Deleted" is by far the most popular choice, especially in older archives, and it works perfectly well unless you want to be really pedantic; "cancelled" and "removed" have been used as well and are also fine (but really, as long as it's grey, that's what matters most). It's simpler to just let users continue to choose whatever wording they want as long as it's clear, concise and professional, regardless of whether their proposal passed, failed or was taken down early.

Comments
For such administrators actions, it's better to contact them directly. I don't think it's important to move this thing through the slow process of proposals.-- 17:01, 19 December 2015 (EST)

Redesign RPG infoboxes and bestiaries
Having multiple infoboxes side-by-side in stats sections looks terrible, so after months of forum discussion and design drafting in my userspace, I am proposing complete redesigns of all the RPG infoboxes, primarily to allow for them to be able to toggle between vertical and horizontal forms. Vertical forms can be used like normal, at the tops of enemy pages as their main infoboxes: clutter is bad), but now for stats sections, the horizontal forms can be stacked on top of each other instead of haphazardly floating side-by-side and at the whims of varying screen widths. This is the main purpose for this proposal (hence it's in "new features"), but at the same time, various other changes will happen:


 * 1) All RPG infoboxes will toggle between vertical and horizontal forms - See above. Note that the vertical forms are the defaults so this won't cause mass appearance chaos as soon as the templates are changed.
 * 2) All RPG infoboxes will use the same colour-scheme as navigation templates (as seen here) - This will create consistency and ensures neatness and easy readability.
 * 3) All RPG infobox pages will have usage instructions and an input chart - This will make them easier to use.
 * 4) All RPG infoboxes will use consistent inputs whenever possible - This will also make them easier to use (less memorization and guessing), although it also means some inputs are being renamed and/or combined and will need to be updated on the articles (noted in red on the draft pages below).
 * 5) Some RPG infoboxes will be expanded with additional info - The infoboxes should have all the stats that we know of present, rather than forcing folks to look up supplemental charts in the bestiaries or elsewhere.
 * 6)  will need to be (re)created - Right now, Paper Mario and TTYD use the same infobox, but once all the new stats and featured are added, that won't be possible anymore, plus it's inconsistent and unnecessary to have two games in one.
 * 7) RPG infoboxes embedded in History sections should be moved to stats sections - If it's not the enemy's overall infobox, it should be in a stats section: it's just inconsistent clutter anywhere else.

It sounds like a lot, but the redesigned templates have all been drafted and are completely ready to go. All that needs to be done is updating the articles themselves by adding inputs to bring the templates up-to-date, and reorganizing the stats sections (including moving some infoboxes down there from History sections). Examples of the templates in action can be found here, and the drafts are as follows:


 * User:Walkazo/Test9 - - Super Mario RPG
 * User:Walkazo/Test1 - - Paper Mario
 * User:Walkazo/Test3 - - Paper Mario: The Thousand-Year Door
 * User:Walkazo/Test4 - - Super Paper Mario
 * User:Walkazo/Test6 - - Paper Mario: Sticker Star
 * User:Walkazo/Test2 - - Mario & Luigi: Superstar Saga
 * User:Walkazo/Test5 - - Mario & Luigi: Partners in Time
 * User:Walkazo/Test7 - - Mario & Luigi: Bowser's Inside Story
 * User:Walkazo/Test8 - - Mario & Luigi: Dream Team

As seen in the proposal's title, bestiaries are also on the slab here, and the reason why is because, rather than having multiple and/or too-wide-for-1024px-screen tables that force readers to scroll up and down and back and forth, from now on, bestiaries should take the form of multiple stacked horizontal infoboxes. Basically, anyway - as seen on Megadardery's test pages here and here, a slightly different template will be used to change the headers from the game titles to just the enemy names, and the bestiaries will still need to include the templates in an overall table for slightly more compact stacking and uniform column widths. However, the important part is that the bestiaries' inputs will all be the same as the corresponding infoboxes', making it a simple matter of cutting and pasting to move and update information between the bestiaries and the enemy pages, or at least make it easier to use both (even the how-to information is mostly the same). A final note is that the bestiaries will now use colour-coding in the names to denote enemy types (bosses vs. enemies vs. support), as explained in the nice legend at the top of the first test page I liked to in this paragraph.

Unlike the infoboxes, only the Paper Mario bestiary is drafted and ready, but I think it's still better to get the ball rolling on this overall stats project sooner than later and start working on getting those horizontal infoboxes out there: more bestiaries can follow in time.

Proposer: (with input from  and others; bestiary work by ) Deadline: January 11, 2016, 23:59 GMT

Support

 * 1) - Per proposal.
 * 2) Per proposal.
 * 3) Though I haven't commented, I've been in support of an RPG infobox template overhaul since the day it was suggested. It, at the current moment, is extrmeley unsightly, ugly, and most importantly, horribly formatted to not fit in with the stats and the like. Therefore, I'm in major support with this proposal and I want it to pass ASAP.
 * 4) – Per proposal.
 * 5) The way the vertical layout of RPG infobox templates are used is utterly miserable. Here are some examples: Dry Bones, Fawful, Lava Piranha, Blooper, Spiny, Buzzy Beetle, Elite Trio, the list goes on, but it's no small sample. They leave behind lots of white space, are extremely cluttery and overall messy, and they're not very reader-friendly. Worse, practically any recurring enemy article from a MaRPG game is doomed to have several of these templates, which are not designed with recurring enemies in mind. I also support moving infoboxes that otherwise clutter the article like in Boo or Hammer Bro. to stats section and get converted to the horizontal design. I'm glad we're going to redesign some of the wiki's biggest eyesores.
 * 6) Very sharp looking compared to the dated templates we are using now.
 * 7) per all
 * 8) - Per Walkazo.
 * 9) Per Walkazo
 * 10) Per all.
 * 11) Per Bazooka Mario and proposal.
 * 12) Definitely per proposal
 * 13) – Per all, this looks a lot better than what we currently have.

Comments
While I'm supportive of the redesign, I have a few suggestions to go with it. 15:48, 5 January 2016 (EST)
 * 1) Infoboxes should probably ignore the direction parameter in the mobile version, as it looks pretty bad when vertical there. (I'm not entirely sure yet how that'd work though.)
 * 2) You should put the CSS that goes into these infoboxes into Common.css to avoid all that clutter.


 * The mobile stuff's beyond my abilities, I'm afraid, and I generally prefer not to add stuff to the css if I can help it. Most of the clutter you're highlighting is unavoidable anyway, as things like the widths, colours and underlining aren't uniform for cells, rows and columns, and will always have to be specified in the templates. Other things like the float and margin coding are affected by the switch function, so again, they have to be in the templates afaik. All the ugly-looking border-radius stuff is just because of the use of, so in the actual editing windows, there's not nearly that much clutter up top, and it's not like this small handful of templates will need to be edited often either way (hopefully). - 12:19, 6 January 2016 (EST)


 * I generally prefer not to add stuff to the css if I can help it. – These templates are included in 1046 pages in total as of now. All those pages include the same coding over and over again, which is exactly what CSS files were invented for; styling similar elements with the same code multiple times. Not to mention the loading times and stress on the server by keeping everything self-contained.
 * Most of the clutter you're highlighting is unavoidable anyway, as things like the widths, colours and underlining aren't uniform for cells, rows and columns, and will always have to be specified in the templates. – It is not unavoidable at all, quite the opposite. I have made this page with an example of . You can see here that the tables and a few special cells where just assigned a few CSS classes, and the rest all gets filled in by the complimenting CSS.
 * Other things like the float and margin coding are affected by the switch function, so again, they have to be in the templates afaik. – These things also can be generalized in the CSS, see the first five selectors in the CSS on the example page, and the align parameter in the Wikicode. (btw, your margin code doesn't work, it needs a default or it will be left empty.)
 * All the ugly-looking border-radius stuff is just because of the use of  – Yeah about that, only border-radius: xx is needed, the rest really is unnecessary clutter. But that is a thing that can be accounted for on a different occasion.
 * 14:29, 7 January 2016 (EST)

There's not a infobox for Mario & Luigi: Paper Jam enemies or there will be one, but it is not done yet?-- 15:22, 7 January 2016 (EST)


 * Okay, I switched everything to "border-radius:5px" to get rid of that clutter, and having "horizontal" in the align function rather than its own thing is a good idea too, so I'll convert the templates to that (skips a bit of redundancy and fixes a really trivial irritation I had with the lack of margin in the template pages). But I'm still against outsourcing the designs to the css. Navigation templates are much more widespread, yet we don't bother doing anything more than the series-specific background colours and basic franchise-wide things like the borders, text and link colours. It's just easier to deal with template design when the design's in the template, not off in the css, which the vast majority of users would have no idea how to deal with - including admins. Plus, we're the only ones who can edit the css anyway, adding another level of complication to what should be an accessible operation: wikis are supposed to be user-friendly, but needing to get help to change a column width is not user-friendly. @LudwigVon: There wasn't a M&L:PJ template while I was working on the designs, and not knowing anything about the stats that might be applicable to the game, I didn't want to hazard a guess at a template design - then someone did make a template at the last-minute, which I didn't find out about until after I made the proposal, but its a bit dodgy and currently only in use on one page, so I was going to hold off on making a new draft for it until I've had time to check out the game mechanics myself, or see other users vetting it. - 16:04, 7 January 2016 (EST)


 * I can see where you are coming from, but I don't agree about keeping everything in the templates themselves. Making it less open may be true to an extend, but infoboxes (and navtemplates too) are things that are supposed to look uniform on the wiki in whole, and I don't suppose there is a lot of reason to change the width of a column any time soon. I think it would protect the design rather than 'closing' the openness.
 * If not moving to the common css, I would at least suggest updating obsolete code. On your Essay page with all those templates, the W3C's Validator return 329 errors. I was going to bring this up at some point anyway as it is a wikiwide problem, but now is as good a time as any.
 * 17:47, 7 January 2016 (EST)


 * Every time an input needs to be added, it'll potentially force things to be shuffled around, and it'll be easier to design new templates with old ones readily available in full. The only thing I'd concede to for the css is a proper, overall infobox class or two to cover the basics (cellpadding, cellspacing, maybe border and font stuff), the way there's an overall nav template class, but that's a whole other kettle of fish since there are a lot of infoboxes that will have to be dealt with: it's beyond the scope of what this proposal is about. Anyway, I fixed all the non-padding/spacing obsolete coding in my drafts here (and there weren't 329 errors from the templates alone - the essays page had a lot more content on it). You're not the first to voice concerns about the wiki as a whole having a lot of depreciated coding, but no one's ever really cared enough to try to do anything about something that basically seems like an invisible non-issue that's beyond the knowledge of the majority of users. You could try to set up a wiki collab about it if you really wanted to. - 23:15, 7 January 2016 (EST)


 * If there where at least some base classes that would be a big improvement already (seeing the table opening tag is the worst offender everywhere), but you are right that this is outside the scope of this proposal.
 * I have been planning on making some form of collab sometime already as 'non-issue' is not really the case but that also is outside this proposal's scope so that's a discussion for then. 11:05, 8 January 2016 (EST)
 * Yeah, I was surprised when I checked common.css and found that there actually wasn't an "infobox" class, even though all the infoboxes start out that way: fixing that's definitely on my to-do list now (maybe after the rollout of this proposal's done). - 11:28, 8 January 2016 (EST)

A quick note, regarding the, the score and card how (under the name: card location) have been added to all the templates, the tattle was changed to card description and the tippi was changed to tattle for better clarity. The draft should be updated accordingly.-- 05:59, 9 January 2016 (EST)
 * Alright, updated, thanks. Changing the "tippi"/"tattle" thing was definitely a good idea, although tbh I would've recommended shorthand rather than long "card location" and "card description" inputs, but ah well, too late now. -
 * pssst, you forgot to change the second card how...-- 16:19, 9 January 2016 (EST)

Prohibit the Usage of in Headers
Using in headers has a couple of issues. For one, it looks ugly and inconsistent with how other headers look like. The only acceptable text formatting in headers should be italicising as to indicate that it's a piece of fiction being talked about. Underlining text in headers is very bad. Furthermore, it breaks the Recent Changes. Using the Recent Changes, a user may jump directly to a section of an article if only a section was edited. However, should the header contain, this feature is broken. Having a feature that breaks a vital function of the Wiki should never be allowed. Sure, you could just hop to the section manually, but why would you do that when the Wiki can provide you a function that does that for you automatically?

I do realise and acknowledge that there is an issue with this: how do we notify the reader that these names are conjectural? The solution is simple.

===Thing that is conjecturally named===  is a thing blah blah blah blah

That way, we get the information that it's conjecturally named across, it doesn't break the Recent Changes, and it makes headers look consistent. This means that all information is preserved, and we don't have to implement a feature that breaks a very vital function of the Wiki. Alternatively and depending on the kind of section being worked with, the text doesn't need to be in a bold typeface. This also gives us the possibility to quickly summarise what the section is about in one sentence before describing the rest of the subject in greater detail. Furthermore, this methodology ensures no unnecessary and ugly notification templates need to be used at all. Additionally, removing does not break section linking at all, so all links that already exist and link to headers that already contain  will not be broken and still work.

But how do we go about finding these? The answer here is also simple. This is how.

EDIT: The old link for finding the instances of the template did not work, so this will be used instead.

Proposer: {{User|RandomYoshi}} Deadline: January 11, 2016, 23:59 GMT

Support

 * 1) – Per proposal.
 * 2) - Per RandomYoshi.
 * 3) Per RandomYoshi.
 * 4) – Per RandomYoshi.
 * 5) - Per Pi.
 * 6) - Per π
 * 7) &mdash; Per RandomYoshi.
 * 8) I hate the use of the conjectural text template in headers, it's time to end that practice once and for all.
 * 9) Per all.
 * 10) Sure thing.
 * 11) Per all.
 * 12) per all
 * 13) Per all.
 * 14) Per everyone except Wildgoosespeeder.

Oppose

 * 1) To me, this could just be a MediaWiki bug. Before making changes to pages to adapt around the bug, have  update the software that MarioWiki uses and report the bug to the developers of MediaWiki if the bug persists.

Comments
Unfortunately MediaWiki search is broken, so the link you provided will not help us find the pages. But as far as I've seen, the only pages with conjectural section titles are the Galaxies and list of Glitches, which should be easy enough to track down. Otherwise, how is the suggested workaround going to work in the list of glitches pages? It doesn't seem efficient to specify the glitch name in every section. I think we need a better idea to over all say "Yo guys, these are all made up names so don't quote us on them will ya?".-- 12:03, 4 January 2016 (EST)
 * How about making a similar template to Template:Conjecture, but that states something like "The titles of the following sections of this article are conjectural; [and the rest is equal to the base template]"? It could have a "section=" variable that, if set to yes, states "The title of the following subsections of this section [equal to normal]". The first is used in glitch pages, the second in Galaxies pages.
 * Having additional notice templates is only going to help in increasing how messy pages look like. It's not going to be the end of the world if we repeat it for every subject we talk about. In fact, it's better to first aptly summarise a subject in one concise sentence before prattling on about the minor details of a subject: that way, readers who only wish to gain an elementary understanding of a topic can choose only to read the first sentence of a paragraph, whilst others that feel like they want a more in-depth analysis can do so by continuing to read about the subject. Because is used in the beginning of the sentence and has the subject bolded (or not), the information that they're conjecturally named is still going to be conveyed in the same way it's done at this point, except it won't break the Recent Changes and generate unprofessional-looking headers. To summarise, it won't hurt us, it won't hurt the reader, it won't hurt the page by introducing a whole batch of notice templates, and it certainly won't hurt the Recent Changes.  13:47, 4 January 2016 (EST)
 * No, it would be repetitive to state the nonofficial name of the glitch underneath every glitch section with that exact same title, it seems okay in the introduction of main articles, because you really are introducing the main element of the page, however in glitches' pages, it becomes overly annoying to read the same thing over and over again. It's like going over every section in the Mario article starting it with "[..] is a game that Mario stars in." which would be insane. Don't get me wrong, I support this proposal, because this issue is super annoying when it comes to actual editing and linking. However, the consequences of doing it this way is not something I support. I don't support the idea of the notice template either, it would be an eye catcher. However, adding it to the introduction of the list in one short sentence is not something I'm keen on, but not something I'm against either.-- 15:10, 4 January 2016 (EST)
 * I agree with RandomYoshi at this point. However, I have another idea: if templates are not good, let's just add a sentence just before the various section start. It should say "NOTE: All the glitches'/galaxies' names in this page are conjectural. Fitting names have been given by the editors.". This may seem repetitive, but remember that phone users have no way to read the message shown by hovering the cursor over conjectural text.

So, I used the link above to track down all the pages that have conjecturaltext templates in at least an header, and oooh boy, there's a very long list awaiting...

I figured out how we're going to deal with the Super Mario Galaxy and the Super Mario Galaxy 2 Galaxy levels with their planets and such. In each section about a planetoid, a picture of this planetoid should be accompanied. In this picture is usually found a small description of the planetoid. In this thumbnail should the name of the planetoid always be found. This is the instance that can have on it. How does this sound? 15:59, 5 January 2016 (EST)
 * It's a good idea. I don't know, however, if everyone reading the Galaxies' pages would stop to read thumbnails. Should we make the planet's name bold in the thumbnail, so it's more apparent?

So, we're about to settle about how to apply conjecturaltext changes on the various types of pages, but there's still an archetype: 50 pages about Wario Land II pages. Here, the problem is in the Hidden Treasure section: a conjectural name, stating what's the treasure, is in the header. However, the paragraph doesn't ever repeat this name, and we can't do the same thing RandomYoshi proposed for Galaxies because the images are far too small. The only idea I have is removing that name altogheter: I don't think it's even needed. Do you have any other ideas?


 * Been mulling it over, and I think just having a "Note: all these names are conjectural." message (in bold, even) at the tops of the "Planets/Areas" sections (on the galaxy and mission pages) would be the most efficient way to deal with the situation, avoiding the use of the specific template at all (or the need to hide the names in the thumbnail descriptions - which would be inconsistent with the rest of the wiki). As for the WLII items, I agree that it'd be simpler to remove them from the headers, and instead just describe them in the body text without having to pass them off as names. For example, Turn off the alarm clock!'s header would be "Hidden Treasure : Viking Helmet " and then the text will simply read "...The treasure of this level is a horned viking helmet that bears some resemblance to the Bull Pot..." (underline showing new content). - 12:38, 6 January 2016 (EST)
 * There are some areas that are officially named, like Cosmic Cove Galaxy's Twin Falls and Cosmic Cavern. Should we note that these are exceptions to the rule by just saying "NOTE: This area is officially named.", and provide a source for its name? 13:10, 6 January 2016 (EST)
 * Or just say "NOTE: Unless otherwise marked, all names are unofficial." and then for the ones with real names, do specifically mention and bold the names in the text with a ref ("The Twin Falls[1] area consists of..."), and that should be enough to tip readers off that those are the official ones. Then the mission articles could go a step further and say "NOTE: Unless otherwise marked with a reference, all names are unofficial." since there's no headers to worry about gunking up, just thumbnails (of if using refs for the mission pages seems like overkill, asterisks could work instead). - 13:40, 6 January 2016 (EST)
 * Deal. 13:55, 6 January 2016 (EST)

See my opposition vote for details about my thoughts. I don't know what version of MediaWiki MarioWiki is using. -- 17:49, 7 January 2016 (EST)
 * Actually even if this issue persists forever there is an easy workaround. That is, use the template under each section. Just sayin, I still agree with this proposal because the look of the hovertext in the section titles.-- 09:50, 8 January 2016 (EST)
 * Like Megadargery states above me, getting rid of the hover text is also one that needs to be done. Even if we were to place s everywhere, it would be ugly and awful. The solution that is proposed is fine. 15:57, 8 January 2016 (EST)

Protect all series page
What I mean by series, I mean the page name like, Mario (series), Paper Mario (series), Mario & Luigi (series) so that only autoconfirmed user can edit them.

The reason I wanted all this page to be protect is because, I think these pages are often vandalized and that several false information on those pages are added. In addition, when a new official game comes out, it is also impossible for those who are not autoconfirmed user to created a page for this game.

Proposer: Deadline: January 24, 2016, 23:59 GMT

Support

 * 1) Protect those page indefinitely.

Oppose

 * 1) We should protect these pages only on a case-by-case basis, as some series are not as popular as others, and making a blanket ban on them would be in my opinion unwise. It's best left to see what peoples do to this page in the first place and drive-by wandals who wandalize the page aren't really common anyway.

Comments
I agree with Baby Luigi, I found that my proposal is pointless after all.-- 12:47, 17 January 2016 (EST)

Split the Mario & Luigi and Super Mario RPG consumables into separate articles
Remember back in the day when the word "stub" was thrown around like it was going out of fashion and everything smaller than Bowser's article was a stub? This resulted in a lot of articles being clumped together into one superarticle, which is kind of like Superman if he had to wear Kryptonite. What I want to bring up today involves several articles merged during that period, including Super Syrup, Ultra Syrup, Max Syrup, Super Mushroom, Ultra Mushroom, Max Mushroom, and plenty more (including subjects that were affected long after the merges). Every article that I want to split will be listed in the comments. So, the reason I want to split these articles is because there's no reason for them to be merged in the first place. They're individual items with individual names, individual effects, individual buying/selling prices, and individual locations that the games treat like individuals. In some cases, they even have individual appearances, and no, some items having the same appearance is not enough to keep them merged when everything else about them is different. The clumped articles themselves aren't all that pleasant, trying to hop from several topics in rapid succession when that information would be more easily presented in separate articles. Also, having a bunch of Foreignname templates stacked on top of each other is not good in the slightest. I was one of the people who supported those proposals, but looking back, I simply cannot see how the articles are "clearly not working seperate". In light of the recent splits, I thought this would be appropriate.

Proposer: Deadline: January 17, 2016, 23:59 GMT

Split

 * 1) Per proposal.
 * 2) Per proposal.
 * 3) – Consistency is key. Per proposal.
 * 4) - Per Time Turner.
 * 5) Per proposal.
 * 6) Per all.
 * 7) Should've happened earlier.
 * 8) - Per TT.
 * 9) - Cautious support. I agree with the general thrust of the proposal, but there does have to be a threshold below which two things are similar/minor enough to go on the same page. One-sentence pages, even if notionally complete, don't help anything. (I presume that last sentence doesn't apply to any of these specific splits)
 * 10) Per all
 * 11) Per proposal

Comments
Full list: I'm tempted to thrown in the Peppers alongside this proposal, but they're not quite in the same boat as the other ones. There's also the Mushroom that the Triplets give, which has a completely different effect to a regular Mushroom, but I don't know how the article would be properly identified if split.
 * Mushroom - Super Mushroom, Ultra Mushroom, Max Mushroom, Mid Mushroom, Bad Mushroom
 * Syrup - Super Syrup, Ultra Syrup, Max Syrup
 * Nuts - Super Nuts, Ultra Nuts, Max Nuts (on a side note, shouldn't it be "Nut"?)
 * Nut - Super Nut, Ultra Nut, Max Nut
 * 1-Up Mushroom - 1-Up Deluxe, Double 1-Up Mushroom
 * Drumstick - Hot Drumstick, Fiery Drumstick, TNT Drumstick
 * Candy - Super Candy, Ultra Candy, Max Candy
 * Any others that I've missed
 * It most definitely should be Nut instead of Nuts. It shouldn't be renamed right away, but it should be renamed after you've made the different Nut articles. You're allowed to link to just even if that would generate a red link.  20:17, 9 January 2016 (EST)

@Reboot: We're not giving articles to every subject under the angry sun (see: Fan (souvenirs), Lightwand), but the articles that I've listed all have more than enough information to support themselves individually.
 * I'm not sure if I understand the plan for the mushrooms. Is the intention to give the Super Mushroom from the various RPGs its own article(s), or merely move the information around to the existing one? Either way, it should be noted that the Mid/Super Mushroom and Max/Ultra Mushroom had identical Japanese names. It would appear to be another example of a translator – Ted Woolsey in this case – providing one-off separate names which would later be changed or reverted. The mushrooms in Super Mario RPG do heal different amounts of health, but those values are also inconsistent within the Mario & Luigi series itself. Mid/Super Mushroom definitely seems straightforward enough, but there is confusion with the Max Mushroom since it was actually introduced separately from Ultra Mushroom in the Mario & Luigi series, and it performs just like the original Super Mario RPG version in Superstar Saga and Partners in Time. That's not even considering Super Shroom and Ultra Shroom from Paper Mario (albeit colored differently). How does that all work out under this proposal? LinkTheLefty (talk) 03:00, 10 January 2016 (EST)

Pretty late in the proposal, but should Woo Beans, Hee Beans, Chuckle Beans, and Hoo Beans be added to this list? They're currently in Bean but I feel they can get their own article here. Does this proposal cover those? 00:14, 15 January 2016 (EST)
 * At this point, it's too late to change the proposal, but to me, they're in the same boat as the Peppers. I would like to see them split ASAP, but this proposal was meant for reverting the merges of yesteryear, and I felt that neither the Beans nor the Peppers were really a part of that. From day one, they were a part of the same article before the merges even started, so it would have been misleading to include them here. That's what talk page proposals are for!
 * I actually was about to contact you in your talk page, but better ask here now: are you planning on creating separate article for those aforementioned beans? It doesn't seem like something that would be a contentious issue since the four are pretty distinct enough, but I could be wrong... 00:28, 15 January 2016 (EST)
 * Considering their different locations, different appearances, different uses, and different names, I'm all for each Bean having its own article. I might also extend this to the stat-up Beans from later games, though I don't know enough about them to give a definite "yes this is a good idea".
 * Let's just stick with the Superstar Saga beans stuff. I think the stat-up beans shouldn't get their own page; as far as I remember, they all have the same sprite and don't differ as drastically as the Superstar Saga stuff. 00:47, 15 January 2016 (EST)
 * The Beans have different sprites in Dream Team, and considering they all increase a different stat and can be found in different locations, I wouldn't mind bringing them along for the split.
 * Fair point. Let's do that too. 16:19, 15 January 2016 (EST)

Require short detail of change in future Support/Oppose/Comment/etc proposal headers
The reason for this is similar to the proposal above - when adding a vote or comment on a page that has a prior (usually settled) proposal, you get sent to the equivalent section for the first proposal. Similarly, the section link from RecentChanges will also send you to the wrong section in the same way (in either case, you're sent to, e.g., when the section you're looking for has an anchor along the lines of, even though the header is just ====Support==== ).

It wouldn't have to be long or complicated (e.g., this proposal could have headers of something like "Support/Oppose requiring short detail"/"Comment on requiring short detail"), the point is just for it to be unique on the page (although simplicity of rule-writing means that it would be better to include the first proposal on a page in it). Headers in past proposals wouldn't need to be changed; this would only apply to proposals, including Talk Page Proposals, started after the new policy would come into effect.

Proposer: Deadline: January 17, 2016, 23:59 GMT

Support

 * 1) . Per own proposal.

Oppose

 * 1) - Too much screwing around for something as superfluous as where you appear in the page after saving. The Table of Contents brings you to the right header, and when you try to edit, you're in the right section, so there's really no problem. Maybe someday the MediaWiki bug will be fixed, but in the meantime, it's not worth complicating basic header stuff.
 * 2) Aside from per Walkazo, since the page load bug is a bug, it's not something we can really fix.
 * 3) Per Walkazo and the comments below. It's a MediaWiki glitch that most likely won't be fixed in the near future. All this does is add unneeded tedium to the process of proposal creation; even though  does this, it doesn't mean we should all be required to do this. I get that we're trying to work around something the can possibly get very irritating (I actually talked to Porple about it because at that point, I didn't know it was a well known MediaWiki glitch), but like I said, all this rule (for lack of a better word) would do is add unnecessary and unwanted tedium to creating proposals; and besides, the only thing it would really be absolutely necessary for is TPPs because on this page, it doesn't take much effort to go from one proposal to the next, because scrolling from Proposal A over Proposal B to Proposal C does not take much effort at all. To sum up, it really should just be an option, not a requirement.
 * 4) Per all. I'd rather ignore the bug than go through an extra step in making creative proposal headers.
 * 5) Per all.

Comments
Ghost Jam: Isn't this what this proposal is all about, though? Circumventing a bug? 19:05, 11 January 2016 (EST)
 * Exactly. We can't fix it (it's more or less baked in - the only ways to technologically fix it would be [a] prohibit more than one section with the same name on a page by throwing an error when someone tries to save it as such or [b] make section anchors something like a random alphanumeric code with no connection to the actual header text. The former is a more extreme version of what I'm suggesting, and no-one anywhere wants the latter), but we can work around it. - Reboot (talk) 00:42, 12 January 2016 (EST)
 * Or just ignore it. It's a minor bug: not worth bending over backwards over and adding another, confusingly fiddly step to proposal-making - one that promotes inconsistency and needless wordiness, at that, which will then look terrible in the archives forever. Both the long-term and short-terms costs far outweigh any benefit from avoiding a glitch that causes a second's worth of inconvenience at a time: we've shrugged and carried on for over 8 years, and we should continue with that path of least resistance. - 01:12, 12 January 2016 (EST)

Split the Mario & Luigi: Superstar Saga and Partners in Time badges into separate articles
'''Note: This proposal is not advocating to split the lists from the Badge article into separate articles. It is advocating for every single badge in those lists to have their own, respective articles (excluding Bowser's Inside Story and Dream Team). This is to prevent any confusion.'''

Please, put away your snap judgments and hear me out.

The tables in the Badge article are not adequate as fully comprehensive sources of information. At best, they can be used to summarize the basics of each badge, like the tables in various game articles, but they would benefit greatly from having individual articles. The locations of each badge beyond "this entire area", as well as when they can be obtained in shops as the story progresses; a more detailed description of each of the badges' effects, and while this may not apply to several badges in Superstar Saga that only increases stats, every badge in Partners in Time has a secondary effect, and there's no reason to drag them down just because of a few outliers; each of the badges' names in other languages, and no, I don't consider the giant and garish list to be a suitable alternative; both their base buying and selling prices; and this is just what I cam come up with off the top of my head. In theory, several of these elements could be stuffed into the tables, but at some point it'd just become bloated to the point where it'd be better to split the badges out of convenience. The tables are already showing signs of bloat: frankly, a table that requires ten footnotes and two sets of asterisks on top of that is laughably inefficient. Even if they don't have a unique sprite, they're still clearly unique items with unique attributes. There's also another recent proposal from me that wants to split some items that also share appearances, so that alone is not strong enough to keep them merged. If the game treats the items like individuals, we should do the same. From where I'm standing, this is a natural follow-up to my last proposal that involved splitting the Paper Mario badges. This can only increase the wealth of information on the wiki and limit the need to rely on an imperfect list.

As there are notable differences between the use of badges in the first two and later two games of the Mario & Luigi series, this proposal only covers said first two games.

Proposer: Deadline: January 24, 2016, 23:59 GMT

Split

 * 1) Per proposal.
 * 2) Per proposal.
 * 3) - Per TT.

Don't split

 * 1) - Yeah, "a page for every named thing" is a valid stance, and one we generally follow, but this is starting to seem like overkill, especially when the clothing/equipment is taken into account, as if we okay this, for consistency, we should okay all those hundreds of splits too since they're basically in the same boat. And while there is enough info to make decent little pages, do we really need to? The tables aren't actually that bloated (yet - and if we want to add more stuff, we could just do similar setups to the new PM bestiary pages with stacked stats) and the Names in other language summary table isn't a bad solution at all (maybe just move it to the corresponding list page). Meanwhile, there are no unique images, all the "specific location" stuff starts to sound like walkthrough material, what the stores are up to should be covered in their respective pages already, and the "too many footnotes" argument doesn't sway me at all since the aforementioned PM bestiary pages have much more expansive "what the words mean" sections up top, and the M&L:SS footnotes is actually pretty straightforward to understand, since it's not like ten special cases requiring discussion, but ten (mostly-)recurring types of effects: just move them up top as a proper legend and it's fine. Overall, I can't help shake the feeling of "do not want" when it comes to this idea.
 * 2) Have to agree with Walkazo on this
 * 3) Per Walkazo.
 * 4) It's a good idea, but I gotta go with Walkazo here.
 * 5) Per Walkazo.

Comments
Wait, but don't we have these articles on the two subjects already? 00:14, 18 January 2016 (EST)
 * You thought the same thing with the last proposal. This proposal is not about splitting those lists into individual articles, but giving individual articles for every item in those lists.
 * Sorry. I'm probably too tired and too stupid to read things through before farting something out of my trap. But is there something the Partners in Time list misses? Only the Superstar Saga list seems convoluted as hell unless I'm being mistaken (being the dumb person I am to repeat the same comment) and even so, why don't the Bowser's Inside Story and Dream Team badges need a split? And what about the battle cards from Paper Jam? What will you do about those? Do those even have names? 00:36, 18 January 2016 (EST)
 * One step at a time. As I described in the proposal, the lists miss out on detailed locations (exact drop rates as well), names in other languages, specific buying/selling prices, and more detail for a badge's effects. While the PiT table isn't as convoluted, it's still missing a wealth of information that could be easily added if the Badges were given individual articles. The BIS and DT Badges were left out due to their radically different nature than the SS and PiT Badges. If this proposal goes well, they can be covered in due time, alongside the Battle Cards (which I, admittedly, don't know much about).

We could make the same case for Equipment. Specific ones make several effects and can be explained in detail, some are obtained specifically (although most are random if I recall correctly), and all have completely different foreign names. Yeah, equipment are more "generic" than badges but their function is quite similar to badges in many cases. Overall, I'm skeptical of this proposal. 15:19, 18 January 2016 (EST)
 * You made a case for equipment sharing properties with the badges, but what about it? Are you saying that the Badges shouldn't be split if the Equipment isn't split? Are you saying that the Badges don't deserve to be split because other articles in a similar position are merged (as I said, baby steps)? What are you skeptical about?
 * I'm just pointing out facts that might give this proposal some trouble since splitting Equipment sounds like overkill; therefore splitting badges would be overkill. 15:49, 18 January 2016 (EST)
 * And why would splitting the Equipment be overkill? If you're just referring to the pants in the M&L games, then they're basically badges of a different name, only they increase defence instead of attack (in Superstar Saga, at least). As you said yourself, pretty much everything that could be used to expand the badges could also be used to expand the equipment, and the point I want to stress the most is that the tables we have now are far from adequate enough to properly cover them. I didn't even give them a second thought while writing this proposal, but this just gives me more motivation to push forward. If you're talking about the SMRPG stuff, then I don't know enough about them to say something definitive.
 * Check the link. I've referred to the Super Smash Bros. variety of Equipment. 00:10, 22 January 2016 (EST)

Please create an example article in a subpage of your userpage so that I can judge this more accurately. 04:57, 22 January 2016 (EST)
 * I don't have the time nor the brainpower to give a bunch of fully fleshed-out examples with school just starting, but here's a start.
 * I'm not digging the excessive fluff here at all. It reads like a walkthrough and the information it contains is already present in the tables. 02:46, 24 January 2016 (EST)

Remerge most Super Mario Bros. film information
It's a pretty complex problem, so it's important that you read and understand what exactly is going on in this proposal. The general crux of this proposal is to overturn the previous proposals mentioned below, thus remerging the film information to their parent articles, but there are a few exceptions that have to be made, and they'll be explained below.

Some history: we had a few proposals related to the Super Mario Bros. film. This one in 2009 set the idea that film information should be separate because, the reasoning went, the film depictions are drastically different and unfaithful to the games for the most part. Later, this proposal (by me) reinforced it. The biggest problem with this reasoning is that is singles out the Super Mario Bros. film for being different from the games but other media and even the games themselves don't exactly follow the standards for character designs all the time. One example is Mario, which if we did went by "they look super different", we may have to split live action depictions of Mario (such as in the cartoons) because there's no way to faithfully replicate Mario's design in live-action. Another example, we don't separate King Koopa from the cartoons from Bowser even though King Koopa is completely green, has no hair, wears a crown, and has yellow underbelly that extends to his tail, traits Bowser does not have. It may be argued that King Koopa isn't different enough and the cartoons want us to treat this character the same as Bowser. What is the line between "different" enough, though? This is entirely subjective and while King Koopa indeed shares more traits with games Bowser than film Bowser does with games Bowser, I feel this is the wrong point to make. This film also wants its viewers to treat this human as Bowser, but simply "evolved" to look more human, and we get to see this character as a reptilian later in the film anyway. Furthermore, there is at least one enemy that largely resembles its game counterpart, the Bob-omb, but that isn't split.

Which brings me another problem: the split job from those proposals is inconsistent. Mario Brothers Plumbing, Snifit, Tweeter, and Bullet Bill/Banzai Bill are also not split. Why not just split them instead of merging the rest? Because there are no very good reasons to keep them split, as the only reasoning was that "they're super different". After you look past the drastic depictions, the split invites canon arguments in the wiki and suggests that the film is "less canon" than the games/cartoons/whatever, which violates a well-enforced policy, which appears to be a major blind spot or double standard for outsiders to this wiki. We've had users trying to add film information to these character's articles, which may have highlighted the problem with this split.


 * To be merged
 * Mario (film character)
 * Luigi (film character)
 * Toad (film character)
 * Princess Daisy (film character) (similarities to Princess Peach can be noted if needed; do NOT add extensive infant Daisy's information to Baby Daisy aside from a side note, similar to how Toddler Terrors of Time Travel is handled in Baby Mario and Baby Luigi)
 * President Koopa (to Bowser)
 * Yoshi (film character)
 * Goomba (film) (reptilian forms can be noted as a possible parallel to Koopa Troopas, although I don't know if the film ever refers to these as even Koopa Troopas.
 * Iggy (film character)
 * King (film character) to Mushroom King

Sure, some of these will vastly expand the parent characters (which may be heavy in content to begin with), but that means a rewrite not a reason to keep articles split. Our own MaRPG plot information is arguably just as detailed as the film's plot information, but we don't split information.


 * To remain split
 * Big Bertha (film character) (no individual Big Bertha character; there is a Big Bertha character in Fins and Roses, although its article isn't created as I speak, so the film identifier is fine)
 * Spike (film character) (there was no individual Spike character in the games; rename to Spike (character))


 * Needs information
 * Mario Brothers Plumbing
 * Snifit (Shy Guy could also use a mention if not there already)
 * Banzai Bill (it resembles a Banzai Bill and is linked as Banzai Bill in the film's article, so a mention in Banzai Bill needs to be made)
 * Monkey!

The general idea is that there has to be some parallel to these two characters. If there is an individual in the film (Mario) that is an individual in the games (Mario), then it should be merged. If there is an individual in the film (Big Bertha) that is a generic species in the game (a Big Bertha) then it should get its own article.

Proposer:, suggestions by Deadline: February 4, 2016, 23:59 GMT

Support

 * 1) - Per proposal, per consistency with how we deal with every other conflicting piece of media, including games that don't quite fit. Even for species we split for being different in certain appearances, it's because there's different names to justify it, but that's not really applicable here, and besides, there's no reasonable question that characters like the film's Mario is Mario, just a different take on him, and that's too subjective to split pages over. If the to-be-merged character pages are massive, that's only because they're doing a poor job of summarizing the film and should be cut down: the film has its own article for a scene-by-scene breakdown, on character pages, it's padding (regardless of whether the articles are merged or standalone).
 * 2) Per all.
 * 3) Per all.
 * 4) Per all.
 * 5) Per all.
 * 6) Per all. I always thought this splitting was inconsistent.
 * 1) Per all. I always thought this splitting was inconsistent.

Oppose

 * 1) - If we are going to have pages for all paper characters (see Paper Mario (character)) on the basis of them being different characters, I see no reason why the film characters should be re-merged. Paper Mario is way more similar to Game Mario than Film Mario, and it makes little sense to state that Paper Mario is "its own entity", as Film Mario clearly doesn't follow the general story and concept of Game Mario and should therefore be its own entity.
 * 2) - Mario's article is too long, so I don't want a film continuity crammed into it. Besides, we have had different forms of Mario as separate pages and different versions of Mario on the same screen. I'm aware of Canoncity, but I would prefer the separate pages for Other Media forms of Mario and other characters that are too different from the games.
 * 3) - The post-credits scene where Iggy and Spike are brainstorming video game ideas to Japanese executives is meant to show the "true" origin of Nintendo's Super Mario Bros. due to language difficulties. This isn't reading between the lines - this was somewhat recently confirmed as the actual intent by one of the directors, and is apparently the sole reason the entire movie feels "different" from the rest of the series (which backfired with audiences). That alone should tell us the film's characters are not exactly meant to be the same entities that fans are familiar with.

Comments
Who would we merge Iggy with? He's clearly not Iggy Koopa. -- 18:27, 28 January 2016 (EST)
 * How is he not "Iggy Koopa", though? I know, he appears different and the rest of the Koopalings aren't there, but I'm sure he was created with the Koopaling in mind, with him being a cousin rather than a sibling. 18:35, 28 January 2016 (EST)
 * Possibly, but the only similarity besides the name (which could be a coincedence) is that he's a Koopa who serves Bowser. I would believe he was based on Iggy if the other Koopalings actually existed. -- 18:39, 28 January 2016 (EST)
 * So he's Koopa's adult cousin in the film instead of the (now-retconned) parent-child connection? Big whup - it's no more drastic a change than Daisy being the Mushroom princess, Koopa being President instead of King, Goombas being giant pea-headed men, Yoshi being a pet, Toad being a busker, a bare-faced Luigi being much younger than Mario, etc. It's pretty obvious that they got the name and inspiration from the Koopaling, so let's call a spade a spade and put the info in that article. -
 * Fair enough, you got me :P -- 18:41, 28 January 2016 (EST)

@Tucayo: Just because the film does a poor job at handling the depiction of the Mario characters doesn't make it grounds for disqualification within the Mario series. That's pretty much the base of your entire argument, something this proposal thoroughly debunked in its opening statements, regarding how differently various characters were portrayed in the cartoon (including the live-action version of the Super Mario Bros. Super Show, should we also split that information off considering how vastly different their roles are?) and even within the games themselves. Whereas, it's arguable within not only storyline matters but also gameplay matters that Paper Mario is his own character. Film Mario had never been referred as separate from regular Mario in the Mario series. The movie clearly established that it's the same Mario as this Mario, no matter how bad of a job they did with it or how deviating from the canon it is (and we know that this wiki has a firm stance against established canonicity), so therefore, they should be merged. 13:12, 1 February 2016 (EST)
 * "disqualification within the Mario series". The fact that the movie is not part of the Mario series makes it grounds for disqualification within the Mario series. I'd actually support splitting those appearances as well, but that should be a debate for another time. --
 * And may I ask exactly how is it not part of the Mario series? 13:21, 1 February 2016 (EST)
 * From Mario (series):
 * "The Mario series is a long-running video game series published by the popular gaming company, Nintendo. The Mario series has been running for more than a quarter of a century, and in its lifespan has released more than two hundred video games. The series also holds the title of best-selling video game franchise in history, with over 262 million combined units sold."
 * Video game series. I'm aware we classify it as "Other Media", and it's exactly that, it's other media. Our own name for it indicates it's "other", not a main part of the series but rather something additional. My vote stands. -- 13:25, 1 February 2016 (EST)
 * Are you going to advocate splitting off the Mario as depicted in other media aside from the film as well? Like, any appearances in Super Mario Adventures, Super Mario-Kun, Super Mario Bros. Super Show, Amada Anime Series: Super Mario Bros., and whatnot as well? Keep in mind, this is not a Mario series argument. This is an argument whether to integrate the film depiction of Mario into Mario's article, Luigi film character into Luigi, and others. We don't have the cartoon series and what not in the Mario series article simply because you are correct, the Mario series is a video game series. However, we are talking about individual character articles, not a video game series one, and that allows more leeway of interpretations of the character into them, in which, film Mario has the criteria of being included into Mario the characters article. 13:38, 1 February 2016 (EST)

Tucayo: Where did you get that conclusion from? What does Paper Mario have to do with the film? We're splitting Paper Mario because he's treated as a different character in Mario & Luigi: Paper Jam (he's considered a third partner, he has his own stats, and Flesh Mario interacts with him as if he's his own character). Film Mario should be merged because he's supposed to be a take on Mario; if this Mario interacted with Game Mario, it would be feasible, but no, this is supposed to be the Mario. This has nothing to do with how "different" a Mario is or "he's made of paper" or this conclusion based on faulty logic that "Paper Mario is different and his own character; Bob Hoskins Mario is different, so therefore, he should be his own character". Frankly, your logic behind why "the movie is not part of the Mario series" is ridiculous. You're even contradicting yourself in your definition: first, you're saying it's not part of the series, but then you go around and say it's not a "main" part of the series but something additional. The external media does count as part of the Mario series, but the Mario series is primarily about the games, especially when the other media are based off these games. The only barometer of what makes media worthy of coverage is if Nintendo officially was involved in it. How closely a medium (or a series of it!) adheres to Nintendo's world of Mario invites canon arguments like you're arguing here, specifically "it's not faithful so it shouldn't be covered alongside everything else", which is just a different way of saying "it's less canon/it's less authentic" when we shouldn't even begin to focus on that. As Canonicity states, "the organization of an article is simply a way to convey information in the most effective and efficient manner possible." The current split-off is not effective or efficient due to its inconsistent nature and that it singles out the Super Mario Bros. film just for being different. 15:27, 1 February 2016 (EST)
 * Show me what the article would look like if it's merged. That way I'll decide if this is indeed efficient and effective. -- 15:56, 1 February 2016 (EST)
 * This is what it may look like. 16:29, 1 February 2016 (EST)
 * Alright, looks OK. -- 21:46, 1 February 2016 (EST)

LinktheLefty: I think that verges on speculation. And even if you do accept the intent of the filmmakers, that the game developers "bastardized" Super Mario Bros., exactly how would this make film Mario a separate character from game Mario? 01:41, 4 February 2016 (EST)

SeanWheeler: Your entire vote is invalid and it is easily refuted by the arguments made in the proposal here and in this forum post here. Your argument carries no weight and I don't think your vote should count unless you actually argue your points more thoroughly. 01:43, 4 February 2016 (EST)


 * This isn't speculation, though: it's laid out pretty clearly in the aforementioned Rocky Morton interview.


 * “Well, the concept that I came up with for the movie — because it wasn’t an original script, which I didn’t like, and I went away and thought about it and then pitched to the producers my new idea — was to create a backstory that only tentatively related to the final game. The idea being that we were going to tell the real story, and that the game itself was a perversion of the original story, which the movie is. That’s why it’s different, you know; the characters are slightly different and everything because [the story] was discovered by the Japanese and they reinterpreted it, but got a few things wrong in the actual video game. Of course, [that] backfired, because people thought "They got it wrong!" ... Well the original script was like that, was like more of a direct lift from the game. And I thought well, we all know the game, wouldn’t it be interesting to create a game that was kind of darker and was the "true" story. And, you know, in history, myths get distorted — this would be the same thing, the origin of the myth, and then it got reinterpreted by the Japanese — like, you see, at the end the two executives from Nintendo come at the end to to talk to Mario and Luigi, and they tell the story of their adventure verbally and then [Nintendo] kind of writes it down and gets it all wrong, and that’s why the game is different from the film. ... I wanted to find a reason to free myself from the game, and the reason I came up with was this was the original story, and everything else was a distortion from this being the truth. And once with that concept, it freed me from being shackled to any portrayal of the video game. Of course, that p*****d a lot of people off — but that was what we decided to do!“


 * Best as I can tell, this was brought up because it was decided feeling "too different" was not a valid reason in itself, which is true. However, there's a very deliberate rationale for this, officially explaining that the film does not consciously represent what is depicted in the franchise proper. I don't know what the thought process was for reserving this key detail until after the credits when most viewers would've gone up and left the room (and those remaining would probably not think of it as anything more than an ill-executed gag), but either way, the scene definitely isn't an afterthought - according to the co-director, it is actually the entire basis that the final shooting script revolves around, specifically so the film wouldn't have to be restrained down. Essentially, it comes down to a game of telephone - can something that started out entirely differently and got mangled over time and communication troubles really be considered the thing it started out as? Same applies to the characters, setting and story as a whole. To me, this is ample grounds for segregating the information. I'm generally all for wiki policy, but I think that's really supposed to be enforced if the intent is unconfirmed and unknowable. Policy shouldn't come at the expense of overriding well-documented creator intent (whether we agree with it or not). LinkTheLefty (talk) 17:32, 4 February 2016 (EST)

I'm ebarassed to say I actually knew about the Rocky Morton comment (even wrote about it on the film's page), but I didn't consider the implications for this proposal until LTL posted.

To add to the above, this trading card for the film also hint at Rocky Morton's explanation of the movie. It even directly says "Nintendo video game". --Glowsquid (talk) 22:24, 4 February 2016 (EST)

Deal with the duplicate Paper subjects in Mario & Luigi: Paper Jam
Since we started hearing about the subject matter of Mario & Luigi: Paper Jam, there has been questions about what that means for the Paper Mario series and how we cover it and its subjects. There are three options:


 * 1) Make separate pages for the duplicate Paper characters/species/etc. that appear in Mario & Luigi: Paper Jam alongside their flesh/real/3D counterparts, ONLY covering their appearances in that one game, and NOT in any preceding Paper Mario games. It follows the same logic that splits Metal Mario (character) from regular Mario (or Metal Mario (form)) and Baby characters from their adult counterparts, in that the two versions of the characters appear in at least one game simultaneously and function separately from each other. Separate characters (or species, etc.) in the context of the applicable games getting separate articles makes coverage easier (one characters' plot overview per page, one set of stats per page, etc.), and, since the subjects have specific names and identities, it's likely that people will search for them, and we want to make sure that traffic comes to us and finds what they want. This is what I suggest we do.
 * 2) Split coverage of the Paper Mario series entirely due to the M&L:PJ showing that the paper world exists in a book in the regular Mario universe. This means that for consistency, everything that appeared in both series should get split, which is insane from an organizational/comprehensive coverage standpoint and runs afoul of numerous policies and fundamental organization standards. For one thing, the mere assertion that all previous Paper Mario games happened in the M&L:PJ book is reading between the lines and linking unrelated games together into a single narrative, which is against the rules. It also comes dangerously close to making forbidden canon judgments about the Paper Mario series, and even ignoring the "the book's not the real world" angle, it's still placing Paper Mario into its own chronology by separating it from the regular Histories of all the subjects, and we haven't organized articles like that for MANY years, much less split them over it. The only vestige of that sort of thinking is the separation of the film characters, under a biased "they're different" excuse, and that is currently being fixed by another proposal. Even Dr. Mario, while superficially splitting out info based on series origin, is actually more along the lines of the aforementioned Baby characters (as well as other things like Dry Bowser and different forms of boss enemies), in that he's split because he has a specific name, appearance and function with self-contained info that folks are likely to search for, with extra justification that he appears alongside the regular Mario in SSB. And so, because this flies in the face of how we cover things in the Super Mario Wiki and would result in the creation of hundreds of superfluous pages that would snarl up organization forever, I strongly suggest we do NOT do this.
 * 3) Make no new articles and talk about both versions of every co-occurring pair of Paper and flesh/3D subjects in single pages. While this would keep all the Paper things together in one page, I think the resulting clutter in those sections will outweigh any advantage that not splitting it apart would bring, plus M&L:PJ isn't even a Paper Mario game, so the Paper content within it will still be far from the actual Paper Mario content on pages with any sort of History built up. Unless there's two M&L:PJ sections per History section, one for the flesh/3D stuff, one for the Paper stuff, but that would be awkward, and could even make both sections seem incomplete or repetitive, depending on how they're handled, plus it's unlike any other aspect of our coverage of any game, and inconsistency is bad. So I suggest we don't do this either.

Hopefully there were enough pros and cons in there to convince everyone that Option 1 is the simplest way, and is the most consistent with current standards and policies. If you want more words, I also made a big forum post going through all the different sorts of doppelgangers we cover. That forum discussion actually exists because someone already went and made a Paper Mario (character) article, without any discussion, and initially as an "option 2"-style Paper Mario series-wide page, although I've since cut it back to M&L:PJ only. I'm hoping this proposal will make it clear that the community as a whole is behind that decision of mine, and will continue in that direction to move forward with that article, and the ones to follow.

I'm not going to bother making a list of pages that will need creating if Option 1 passes, but it's basically every Paper character in M&L:PJ, including Paper Luigi and his cameo, as well as the Paper Toads and Paper enemies, assuming their stats, attacks and/or other non-superficial aspects about them are different from their non-Paper counterparts (but if, for example, Paper Goombas are the same as regular Goombas except for how they look, and same goes for all the other enemies too, don't bother splitting them). Unfortunately, I don't have the game yet, so I don't know enough to even attempt to split anything myself, so others are feel free to have at it: I'm just here to establish the overall game plan.

Proposer: Deadline: February 9, 2016, 23:59 GMT

Option 1: Separate pages for M&L:PJ characters only

 * 1) - Per proposal. Even if subsequent SSB trophies or whatever vaguely characterize the M&L:PJ character as the "Paper Mario" from earlier games, I think it'd be disastrous to split the series: everything being canon and equal and organized through release dates only is the simplest and best solution, and the current practice of giving pages to simultaneously occurring alternate forms of characters is a logical, straightforward and consistent exception that should work for Paper Jam too.
 * 2) Supported this stance from the beginning, supported it in the forums, will continue doing so.
 * 3) Per Walkazo.
 * 4) Per Walkazo. I was skeptical at first, but after playing Mario & Luigi: Paper Jam and have read discussions, I finally agree to separates paper characters and only those of Mario & Luigi: Paper Jam.
 * 5) I've supported this stance, and Walkazo's points only reinforce my position.
 * 6) This is the most reasonable solution. The enemies were likely going to get separate articles anyway seeing as they were fully classified as separate enemies in game, but it does fully clear up what we'd do with characters like Paper Mario, Paper Peach and Paper Bowser (due to his incredibly small role, I'll assume Paper Luigi doesn't fully count, or does he?). Either way, per all.
 * 7) Per Walkazo in the comments.
 * 8) Per all.

Comments
While I'm not suggesting we should split all Paper Mario content, I'd like to hear your thoughts on why Baby Mario is different. His article covers all his appearances as Baby Mario, even when he doesn't appear alongside adult Mario (apart from Super Mario Momotarō and "The Early Years", for a reason I admittedly don't quite grasp). Why should we not cover Baby Mario's appearances when he doesn't meet Adult Mario in the main Mario article, which is what you guys are suggesting to do for Paper Mario? 17:22, 2 February 2016 (EST)
 * There's a very specific, consistent and explicitly named characterization of Baby Mario, and covering half his appearances on one page and half on the other would be messy, confusing and make both articles look incomplete. Dr. Mario and Dry Bowser are covered independently from the main character pages for similar reasons. But this Mario / Paper Mario co-occurence is a one-off so far, so it doesn't need to reconcile recurring solo/duo adventures. Plus, there were four games and many years where there was no distinction between Paper Mario and "real" Mario: they don't call him "Paper Mario" in the earlier games, just "Mario", so it would be wrong of us to go back and say "actually, it was this different Paper Mario all along because a game created years later says so". By contrast, Baby Mario was always "B/baby Mario", and Dr. Mario was always "Dr. Mario", etc., so we're not making stuff up to say there were distinctions from the start. The only times an infant Mario wasn't "Baby Mario" were things like Super Mario Momotarō, Family Album "The Early Years" or "Toddler Terrors of Time Travel", hence they're not covered in Baby Mario's article: that'd be us making connections/appearances that don't exist - same as retroactively making all Paper Marios feature the M&L:PJ "Paper Mario" would be. - 22:25, 2 February 2016 (EST)

To fully clarify, where will we put Paper Luigi in this case? I'm leading to assume he won't get an article due to how minor his appearance was.
 * Paper Luigi should get his own article. Sure, it's extremely minor, but it's a harmless small article. 20:40, 3 February 2016 (EST)
 * The proposal specifically states that Paper Luigi would get his own page like all the rest of the characters. - 21:44, 3 February 2016 (EST)
 * Alright then, fair enough.

Create articles for the hosts of Mario Party 4
Looking back at a proposal I made like two years ago or so, I suggested deleting the articles for Mario Party Advanced characters. I withdrew said proposal after getting a clear view on why we have said articles. Now, two years later, I've been playing a lot of Mario Party 4 recently and came to realize that 4 out of 6 hosts seem to fit in with the explanation gave to explain why we have the Mario Party advanced character articles. Long story short, I believe we should give articles for the Goomba, Boo, Shy Guy and Koopa Troopa (And potentially the Thwomp and Whomp in the extra room) as they play an important NPC role in their game as both hosts of the party mode and certain other modes (Mini-Game mode, present room etc) and they have distinct personalities. Toad and Koopa Kid don't apply here as we know that its the Toad character and Koopa Kid's various roles are all lumped together in the same article (which, now that I think about it, is arguable, but not the point in this case).

Proposer: Deadline: February 15, 2016, 23:59 GMT

Support

 * 1) As long as the creation is reserved for Goomba, Boo, Shy Guy, and Koopa Troopa, I'm fine with it.
 * 1) As long as the creation is reserved for Goomba, Boo, Shy Guy, and Koopa Troopa, I'm fine with it.

Oppose

 * 1) I thought I would support the proposal, believing that with the different clothes every hosts wear, they would be unique characters. Then, seeing that in the Mario Party 4's credit that the characters appear normally and that the Toads, the Goombas, Shy Guys, the Koopas and Boos all play different roles in the Mario Party series, I opposed. What about Mario Party 7's unique characters style? Chinese or Japan Koopa, Egypt Goomba, Top-hat Shy Guy. Koopa Bank's manager. Koopa Troopa that appear in Mario Party DS's story Mode (not the old one). Should we create a page for each of them? What about Mario Party DS, 9 and 10's species boss (Dry Bones, Blooper, Wiggler...)?

Comments
For clarification, the primary reason for the Mario Party Advance characters having articles is that they tick off the necessary requirements. They have names (they're not very original names, but they're 100% names), they have unique characteristics that separate themselves from the rest of their species (unique personalities, unique roles in quests, etc.), and there's a precedence for giving the MPA characters articles set by Hulu, Goombob, Akiki, and others, who occupy the same space as the more generically named characters and yet were given articles while the large majority of the others weren't (until I started mass-producing them). It's the combination of all of those elements that makes them warrant articles. I'm not intimately familiar with Mario Party 4, but I'll provide this: the characters are individually referred to as "Goomba", "Koopa Troopa", and so on according to the manual (with genders, too!), and they have unique appearances, but there's not exactly a precedence for this. To play devil's advocate, are these characters unique enough to warrant individual articles?
 * Well it may not be the strongest reasoning, but they play the important role as hosts for the boards and other modes, thus giving out stars to players. The aforementioned unique personalities can be a reasoning (though the idea of a Boo interested in scaring or a shy Shy Guy may be simply tying into their species as a whole), the Goomba was shown to be a bit greedy and the Koopa Troopa was shown to be laid back, which is something notable about them from their species as a whole. And even if the Shy Guy was still shy, he also showed an interest in exploration. I just feel that the fact they had unique personalities and looks and played an important host role in the game is enough to say they can be split off.
 * Well, just a bit of information, but in the credits sequence, these hosts are shown as "normal" creatures. Not sure how useful it is, but it kind of muddles with their identity, IMO. 15:48, 9 February 2016 (EST)
 * Literally, the hosts are "normal" members of their species, there's no denying that, but their unique roles in the game is what Tails is pushing for. "No one cared who I was until I put on the mask," or capes, cloaks, and vests in this case.
 * Well, I get probably splitting off the hosts in Mario Party 4, with their clothes being their most defining characteristic, but the rest (like Whomp, Ztar, Thwomp, etc.) I don't agree. Might as well split other "generic" hosts such as the Koopa Troopa from Koopa Bank and the Goomba in the battle minigames in Mario Party 2 and the "hootenanny" Wiggler in Western Land (which was merged) and the Bob-omb that appears when someone lands on a Battle Space. I don't know, just because it has dialogue, some characteristic role, and some individuality doesn't mean we should create an article on it. 16:17, 9 February 2016 (EST)
 * Also, these same characters are playable in Beach Volley Folley without their party clothes, so there's that. About Toad... yeah... I'm really not sure if we should delve into identity discussions on whenever he is THE Toad or not... 16:20, 9 February 2016 (EST)
 * Sorry again, but also, these characters' dialogues, if notable, might be a species quirk. Indiana Shy Guy, for instance, makes frequent "um"s and expresses overall uncertainty, but I recall that the shop and lottery Shy Guys have the sameish dialogue... 16:23, 9 February 2016 (EST)

@LudwigVon: The Koopa from Mario Party DS does have his own article. As for the characters in Mario Party 7, they aren't shown to be nearly as separate from the species. My point doesn't really direct at that fact that they wear unique clothing, it's a mix of notable personalities and important role in the game. Item shop owners don't really show much that separates them from their species (example being the Koopa Troopa from Mario Party 2) - @BazookaMario In all honesty, the Thwomp, Whomp and Ztar don't fully count in my opinion as there isn't much that separates them from their normal species. I mentioned them for the sake of staying consistent (as if we were to split the hosts, they'd probably be the center of a few questions). And if the characters in the Beach Volley Folley ARE the hosts without their clothes, I feel that's all the more reason to split them. This game is clearly treating them as independent characters of their species if they are getting these kinds of perks.
 * I suppose so, but part of me still feels like they're just generic species in different clothes. 17:14, 9 February 2016 (EST)


 * The personalities of all of this species also varied on the Mario Party series. Look at Shy Guy who appear to be on Bowser's side in Mario Party 9 (before to be unlocked). Yes, this is perhaps not the same Shy Guy, but created a page because of a personality is a little complicated, because, as I said, most of these species have different personalities depending on the game and especially in the Mario Party series.-- 18:05, 9 February 2016 (EST)
 * There is a subtle difference between the NPCs and the playable characters. I went about splitting the playable characters from their species a while ago, but it failed as there wasn't any proof that the playable characters were the same in their various appearances. This is talking about a group of NPCs who played specifically important roles in their game and in a case where the game itself seems to treat them more as independent characters over generic members of their species.
 * Not sure if the game treat them more as independant characters, seeing the game's credit where they appear as generic species before they wear different clothes. This is where I see them failed to be distinct characters. I wouldn't say no to a page if it would be their clothing from the beginning, but taking precedence on the personalities is complicated, as all this species (Boos, Goombas, Koopas, Boos, Shy Guys) all have various personalities (yes, I repeat) from game to game (especially in the Mario Party series and all of Mario RPG). It's a generic Boo, a generic Shy Guy, a generic Goomba, a generic Toad and a generic Koopa that appear at this moment and start a party. What they seems less important than the different styles of Koopas, Goombas and Shy Guys that appears in Mario Party 7. If we create a page for this, we should create a page for the playable characters, because most of the time, when a species appear as a playable characters, no others is seen as NPC (I didn't remember seeing NPC Koopa when he was playable in Mario Party 9 and the same thing applied for Shy Guy in 9, Dry Bones in 7 and 8 and some others characters). We should also split Glasses Koopa in Paper Mario games, because they are on Bowser's side and "hate" Mario and the good NPC Koopas in Paper Mario games.-- 00:33, 10 February 2016 (EST)
 * I guess this is a matter that's easier to discuss than to fully decide. You are making many good points, but tying all our points together makes an outcome difficult. You are correct in ways regarding the various character personalities showcased throughout the Mario series, but the way I see it, they are all coming from very minor NPC characters.


 * As for the point regarding playable representatives of these species, that's another hard deal to work around. I know one reason the playable species characters don't have articles is because we have no solid proof that it is the same recurring character each time, but another reason I think is because it's easier to just put it all in one page. While I'd personally agree with making an article that simply goes over the playable appearances of a single species character (example like a Koopa Troopa (Playable Character)), I think that'd easily be disagreeable, as it borders on speculation and it's flat out unnecessary. These are all just my opinions though.


 * The species characters in MP4, as I see it, are a group of characters the game is viewing as notable members of said species through host status and even playable status. The whole deal of them just being generic characters as seen in the credits is another thing I'm having troubles explaining. To me, it seems more like how they became the characters the game is portraying more than just a bunch of characters playing dress up. I will likely stand by my opinion on this matter, but I won't deny you have a lot of valid points.

I don't think playing a "unique role" is a valid point to make. This would mean that we have to split that guide Lakitu in the Mario Baseball series from the other Lakitus, the Koopa Troopa who makes that guess in the N64 Mario Party games, the Boo NPCs from the Boo Houses, the Pink Boo from the Pink Boo species (that big Pink Boo in Mario Party 6 even has her own personality and has her own gender as well). The outfits they wear do make a good case for being individual but that's really about it. I'm leaning more on oppose with this proposal. 00:22, 16 February 2016 (EST)

Move Affiliate Buttons to the Wiki
On Links, there is a section with various affiliate buttons for Super Mario Wiki's affiliates. However, all these images are currently hotlinked from various other places on the internet (sometimes the website in question, sometimes third party image hosts, etc).

This means that when said sites update, the images often break.

So I propose we host these icons on the wiki somewhere, so we know they won't break whenever our affiliates change their file structure or move domain name. We can then delete the respective images if the sites ever close down.

Proposer: Deadline: April 3, 2016, 23:59 GMT

Support

 * 1) This will make it much easier to maintain the page.
 * 2) Per proposal, but this doesn't really need a proposal...
 * 3) Makes sense to me. Tag images with  as an extra step.
 * 4) Doesn't require a proposal. This is pure common sense to link the images appropriately.
 * 5) – Per all, especially.

Comments
I don't really think general maintenance like this needs a proposal. I think just more time dedicated to working that part of the wiki would be good. 22:27, 27 March 2016 (EDT)
 * Makes me wonder why we can't upload images here and use the image link function like how some articles do it (namely Mario Kart 8 and my signature pops into mind). As Bazooka Mario said, there's really no downsides to not opposing this proposal, which can be accomplished by talk page consensus, so in my opinion, I say you just do it. 11:00, 28 March 2016 (EDT)

Rename instances of "Cancelled games and vaporware" to "Unreleased media"
The current name "Cancelled[sic] games and vaporware" does not cover other unreleased media of the Mario franchise. This leaves information such as the failed Mario Archie comic pitch floating out there when it should be covered alongside the games. Fortunately, we can simply broaden the scope of those pages and categories by simply renaming them to "List of unreleased media" so we can find a home for these related media while retaining the focus on covering the dead games and games in purgatory. Also, in the future, we may discover more nongame media that never had the chance to see the light of the day, so it is best we make the change now. The distinction of tech demos will still be made, so there shouldn't be a question of those either.

Articles affected
 * List of cancelled games and vaporware
 * Create an additional category called "Category:Unreleased media" and nest Category:Cancelled Games (please rename it to "Category:Canceled Games") under there.
 * Template:CancelledGames (please also rename the header of the template from "Vaporware" to "unreleased media"

Proposer: Deadline: April 10, 2016, 23:59 (GMT)

Support

 * 1) - Per proposal. The name even sounds better.
 * 2) Per all
 * 3) Broader scope is good, and I like it to cover also other unreleased media so that its retrieval is easier!
 * 4) Per all
 * 5) - Per all.
 * 6) Sure, sounds good. Easier to type and remember too.
 * 7) Per all.
 * 8) Per all.
 * 9) Professional-sounding!
 * 1) Professional-sounding!

Comments
Question about the category - are you intending for Cat:Cancelled Games to be removed entirely, or made a subcategory of Cat:Unreleased media (possibly renamed to Cat:Unreleased games)? - Reboot (talk) 20:50, 3 April 2016 (EDT)
 * Good question, but for the time being, we'll have to rename it to "unreleased media" because the only nongame stuff I'm aware of is the Super Mario Archie pitch so there's no point in having two nearly identical categories for the time being. 10:05, 4 April 2016 (EDT)
 * I was suggesting having Cat:Unreleased media containing Cat:Unreleased games (or Cancelled games), not double-catting. Doing this would allow the unreleased games category to be sorted in Category:Games (specifically, continuing to be in Category:Games by misc. status) without putting the Archie comic under Cat:Games or losing that part of the category tree. - Reboot (talk) 15:06, 5 April 2016 (EDT)
 * Hm, my concern would be the amount of media. From what I'm thinking, we're going to get a category with one known item and a link to Category:Unreleased Games, and by category standards, it doesn't contain enough items to be its own category. It's definitely worth thinking about, although I do think Category:Games by misc. status could stand to lose unreleased games just for the sake of a neater inclusion of nongame media. 21:32, 5 April 2016 (EDT)
 * See, if it was going to be removed from the Cat:Games tree, I'd have to oppose. I think Cancelled/Unreleased games definitely need to be categorised in there as such. - Reboot (talk) 08:34, 6 April 2016 (EDT)
 * Hm, I'll think of something. I'm not going to remove it from the Games category, and I'm also iffy on doing it in the first place. I think I'll incorporate your idea just for now, and we'll see how this goes. 16:38, 6 April 2016 (EDT)

Would this include changing all instances of "cancelled" to "canceled"? This isn't even part of the proposal proper, but I noticed the request to rename the page to "canceled" and from what I've seen, "cancelled" is the most common spelling of the word on this wiki. 00:41, 8 April 2016 (EDT)
 * No. For British vs American English, first come first stays. --Glowsquid (talk) 09:36, 8 April 2016 (EDT)
 * Just to clarify, so (please rename it to "Category:Canceled Games") would not happen? 19:22, 8 April 2016 (EDT)
 * Probably not, but I still don't see exactly why since we use American names for naming game articles. 09:39, 9 April 2016 (EDT)

Stricter Image Quality Tag Policy, Additional Image Quality Sub-templates, and Dividing Images in Category:Quality requested Into Subcategories
Over the course of me checking the quality of images I have come across and potentially uploading better quality images anyways, there has been some controversy with me and maybe a few other users of using in the best possible way. Some people have claimed that some usage has been too liberal and the image should be left alone while others agree that the tag should be issued, even if the image isn't that bad in quality but could use a better replacement anyways. To be fair, there isn't much of a definition to on when to use it. This leaves too much room for interpretation, which can lead to conflicts. The current state of Category:Quality requested is overflowing with images (at this time, over 1,000 images need to be fixed). Ultimately, I think we can all agree that MarioWiki deserves the best possible imagery. One tag to keep ~70,000 files in check isn't going to cut it anymore. I think I have come up with a solution that can stop these debates.

First part of this proposal is coming up with rules how to use these image quality tags. See User:Wildgoosespeeder/QualityRequestTypes/sandbox. This sandbox user page is based on my observations of how other people interpreted the current and  tags. The color coding is just a way to convey severity very clearly. This may or may not be part of the final product.
 * Part 1

The next part of this proposal is showing you the additional tags and how they would look when transcluded in image pages.
 * Part 2
 * File:Glide64 2.png
 * User:Wildgoosespeeder/PNG/sandbox
 * User:Wildgoosespeeder/Tweak/sandbox

As for why the copied code from looks thin on the PNG and Tweak sandbox pages, I don't have any idea. The only thing that was changed was the display text. I can't figure out why this is happening. So, for now, pretend the thinness doesn't exist. Also notice how my additional image quality sandbox templates don't put File:Glide64 2.png in Category:Quality requested but rather Category:PNG requested or Category:Images that need improvement instead. That way, congestion in Category:Quality requested will be reduced and be more manageable.

The last part of the proposal is hierarchy of categories:
 * Part 3


 * Category:Image requested <--Click this to see current hierarchy of categories.
 * Category:Articles that need more images
 * Category:Quality requested
 * Category:Images that need improvement
 * Category:PNG requested
 * Category:SVG requested
 * Category:SVG requested moved to a subcategory of Category:Quality requested

The category names are not final and is subject to change. Category:PNG requested and Category:Images that need improvement will just be a subcategory of Category:Quality requested. The two subcategory links will appear in Category:Quality requested and nothing more.

If this proposal passes, images currently in Category:Quality requested will be reevaluated and organized accordingly. Category:PNG requested and Category:Images that need improvement will be created with categorization contents of .The  and  tags will have the contents of User:Wildgoosespeeder/QualityRequestTypes/sandbox and have additional rules and guidelines added somewhere in its   coding, just like User:Wildgoosespeeder/PNG/sandbox and User:Wildgoosespeeder/Tweak/sandbox currently do.
 * Conclusion

Proposer: Deadline: April 16, 23:59 GMT

Support

 * 1) I'm very certain this would be appreciated by all. I hope this proposal passes because it will be needed to make User:Wildgoosespeeder/sandbox more acceptable for a future proposal (TBD).

Oppose

 * 1) I like some of the ideas in this proposal namely splitting off the quality requested tag to different categories of maintenance, but some of the new features introduced here are things I really don't like, which includes the idea of having a tag on any image that isn't perfect. Bazooka Mario and Megadardery has basically explained why that feature in particular is bad; as Mega said and as I previously thought before writing this, it's like tagging not perfectly-written articles on MarioWiki with an improvement tag and we'll have those dotted all over the wiki and we'll look particularly bad to readers. However, considering that this proposal is an all or nothing proposal, I have to go with Oppose here because of how much I don't like adding yet another image tag that we would add to 70% of images due to its very vague and unclear guideline to what exactly constitutes as that, not to mention that there are a lot of parameters and variables into determining whether an image is bad enough or not. You should bring this up in discussions and the collab boards in Marioboards for more input. I strongly feel that this proposal isn't ready yet to be inputted, and it should go back to the drawing boards before we consider the option of implementing it.
 * 2) Per all, including myself: But my biggest feeling towards this kind of thing: We provide information, along with nifty images for clarification. Terrible quality images urge to be replaced, because they do not represent the console-quality nor the subject in question, Decent quality is good, of course Perfect quality is preferred, but it's not the main concern. And very very select amount of people bother regularly with the images. It's also why I don't like how Wii/GCN images are oversized, and N64 images are proposed to be undersized.

Comments
As for the proposal, I'm not sure how feasible this would be. No one likes bad quality images on the wiki, but even moderate quality images would have to be tagged with maintenance categories, and I'm not on board with that. Although we have some more organization, the majority the images could just be recategorized under "Category:Images that are almost perfect", which may also be a place for acceptable images, not categorized prior to this proposal, to be newly lumped in a new, vague maintenance category. This is goes against the proposal's idea, to help sort through the stuffy "quality requested" category. In other words, if this proposal passes, this (lack of transparency), this (.jpg and lack of transparency), this (.jpg), this (watermark), this (low resolution), this (low resolution), and who knows how many more will qualify under the "almost perfect" category because they all have some flaws, in parentheses. This might free up the original quality-requested maintenance category to leave just the potatoes behind, but the problem of a bloated category would be transferred to your proposed one.

I think the "images to be in PNG format" is a step in the right direction since the category is specific, but its function itself, I don't agree. This invites users to replace .jpgs for .pngs for the sake of it despite no benefit other than nice-looking thumbnail images, but loss of bandwidth and bloated file size. We have some strange stigma against .jpg quality images when there shouldn't be. People don't appreciate how much compression a .jpg can have. Some images simply cannot be uploaded as .png due to the sheer file size (this Mario Tennis Ultra Smash artwork cannot be uploaded as a .png without serious scaling). I imagine that the category would work if static sprites were in the inferior .gif format, but that's already covered by policy, so the static .gif sprites should be replaced. Furthermore, given that static .gifs are usually old and confined, it's not worth creating another maintenance category.

On the other hand, I think we can definitely add more subcategories under quality-requested. Off the top of my head, we could organize it by screenshot, artwork, sprite, render rather than the subjective "almost perfect images". We could add more specific reasons for reupload requests such as resolution, poor color quality, but I also think those in general is already covered by organizing by type of image (e.g. there would be little reason to request higher resolution for sprites so resolution requests would logically apply to screenshots and artworks only). This is an idea, though, not a very developed one. It's feasible to add additional categories by type of image, but it's going to take a lot of effort. Still, I think it might work to organize all low-quality sprites in one spot and all low-quality screenshots in another spot and then we can more easily examine at a glance what needs tweaks and what doesn't.

In the end is intended to be for images that seriously need uploading. I think users are taking it too far by scrutinizing every flaw a screenshot or artwork has and then slapping this template there. However, I acknowledge that there is indeed a problem of trying to communicate these flaws due to the lack of options. For instance, you end up lumping decent images like this into the same category as actual potatoes like this by using your image request template as a means of explaining the flaws. Creating a maintenance category of "almost perfect images" is a good attempt, but I think it has unintended issues such as decent images that are at a modest resolution or has a ugly white background going into a category intended for images with slight, but bothersome glitches. This stems from the vague and subjective definition of what an "almost-perfect" image is, which is the core of the problem of this proposal. 22:37, 9 April 2016 (EDT)
 * The categories are not final. Naming, definitions, and amount of additional categories need work.
 * Keep in mind, I am coming from a place of dealing with in-game content, such as screenshots, sprites, and 3D renders, and not so much the artwork accompanying it. We can add a clause to the PNG template that discretion should be advised for images tagged with or  for examples. Images tagged with, , or  that are not in the appropriate format, there is no doubt to tag with the PNG category. For PNG, GIF, and JPEG, I think that a lot of people are misinformed on when to use those formats so they end up using those formats interchangeably, resulting in haphazard uploads. Also we should implement a policy relating to not converting between formats before upload as that process has unwanted byproducts, such as color loss (to GIF), artifacting (to JPEG), and file size bloating (specific to JPEG to PNG literal conversion). As for static GIF replacement with PNG, who's going to go searching? A tag just makes already known things be put into a log of sorts and increases its chances of getting a suitable replacement. When we mean convert, we mean a resampling of the image and save in a more appropriate format.
 * I am very on-board the idea of removing as much of the subjectivity surrounding the use of and any other new tag that may have unintended consequence of excess subjectivity as possible. How do we do that?
 * The tag with Category:Images that are almost perfect Category:Images that need improvement as the category name was an attempt for already existing PNGs tagged as, , or  to need a certain quality upload, free of unwanted artifacts suitable for Wikis. The  tag with Category:Images to be in PNG format Category:PNG requested as the category name is to get images tagged with , , or  to be in a more appropriate format, but resampled first and not literally converted to the format. -- 23:54, 9 April 2016 (EDT)

I need some changes/questions answered before supporting. -- 00:00, 10 April 2016 (EDT)
 * 1) Category:Images to be in PNG format should be Category:PNG requested to keep it consistent.
 * 2) Is there going to be a guideline for which images need to be in PNG format or does this pretend to convert every other format into PNG? Because, as Bazooka Mario pointed out, not all files need to be PNG's.
 * 3) Rename Category:Images that are almost perfect to Category:Images that need improvement. It's an important change because almost perfect is way too broad of a concept. Needing improvement, on the other hand, is a tad more specific.
 * I agree with every point you made ! I'll put in those changes. As for guidelines, already started out working that out in a commented directed to . -- 00:11, 10 April 2016 (EDT)

Ok, for starters, this should have been a collab/discussion on the forums, it has too many options and details to be a direct proposal.

I agree with LGM on many points, but here is my semi-detailed take on this: The "Category:Images that are almost perfect" would be good, that is in a perfect world, it is like putting a rewrite-expand on every single page missing a small piece of information, which doesn't only clutter things, but it makes some users, who are willing to help, feel a bit overwhelmed -for my lake of a better word- when they are replacing images. For starters, sometimes a replacement cannot be found at all, especially when it comes to unreleased games and some old artworks, putting a request of improvement in that case would be completely wrong. Making this category will just increase the "to do maintence work", which doesn't get that much attention anyway, at least from most users.

However, renaming the category to "Category:Images that need improvement" would actually kinda solve my issues. But still, I fear that 70% of the wiki images will have this tag, even though they would not deserve it, for example, a Paper Mario image that is 20px off the preferred size should not get this category and should not get any "quality" categories. This and this (if it wasn't oversized) seem almost perfect to me, perfect enough to not have a tag. this is undersized and should get a tag (and a better name, for that matter). It's just, you can't make a rule for this thing.

However, I agree with separating it into multiple categories for the shots, sprites and artworks and whatnot. It would reduce the clutter in quality image category.

Convert to SVG needs to be deleted. First, it encourages fan-made logo SVG, which should not be allowed. Second, afaik, it was briefly used on old small sprites, because on the old mediawiki, resizing those sprites would blur the image, right now, nearest-pixel zoom is enabled on all browsers. So it doesn't currently have a use.

Last thing... why? The images are here to show one thing, the subject that we are talking about, sure it is better to have it bigger, but why bother and make countless improvements to the system, instead of improvements to the images themselves if possible? We already had the sweat guy User:RAP make a mile long list of images that need improvements, it didn't even reach 10% done. More tags are not going to help it, if the image is terrible, than it deserves a tag, otherwise, if the subject is clear, and the image is of a reasonable size, it's good to go, move on to another image. Priorities.

I might continue talking about this later, I just don't have much time right now.-- 17:09, 10 April 2016 (EDT)
 * I haven't directly addressed pre-release images yet but in User:Wildgoosespeeder/sandbox (future proposal), I revised the introduction to narrow down what should require a PNG (unused content) and what can be left alone in its current format (pre-release screenshots). I'm split. I definitely don't agree with 's tagging of some pre-release images, unless there is a BMP source and someone didn't think twice and used JPEG or GIF.
 * File:Koloradocamp.png, that would be tagged on the grounds of a JPEG not resampled but rather directly converted into the PNG format and was not sampled in native resolution, which I'm against. File:PM 64thTriviaQuiz-off.jpg, there is a lot more consistency with screenshot taking in native resolution in an N64 emulator than Dolphin Emulator (different story). I'm not oversizing GameCube and Wii emulator images because it is HD versions of a SD game. I'm doing it because it is just easier than the work-around way that really needs to be recoded. Generally speaking, oversized images cause terrible blurring to HUD elements because most are sprite-based, especially N64 images. I have found two offenders and since corrected the problem (File:Peach's message.png and File:PMBowserBattle1.png).
 * I'll consider splitting into screenshots, sprites, etc., but at a later point in time. First we need to see how the first implementation goes (if it passes).
 * I honestly thought that was used to have scalable logos and not for making graphics more scalable without blur. If that is the case, I merely thought that the tag was repurposed for better things.
 * I find that personal lists don't solve the problem of getting better replacement images. A tag is an easy-to-spot flag that catalogs into a category while a personal list is mostly hidden from direct public view because it is not a page considered maintenance. Who's going to know about it? Only a few users know about it. -- 20:17, 10 April 2016 (EDT)


 * Voting comments

I can understand where you are coming from with your concerns surrounding tagging in general because it can be an eyesore to the flow of the article. When you think about it, isn't that part of a tag's design? The tag isn't supposed to be there but it is (if there is a good enough reason for it to be there, even more so if an exact reason is specified by the tag's parameter). It should let anyone know that the article or section needs attention. No tag on articles means the article has less of a chance of getting attention. I can also understand over-tagging things too as meaning can be lost. I always thought that, , , , , and carried, from highest to lowest, a sense of how much an article needs to be improved. I'm not very clear on when to use those tags anyways because even those tags have vague to no description on how they should be used which leaves room for interpretation. I feel like I am running on interpretations, which leads to unwanted debates and confusion. Same goes for and. MarioWiki is striving for professionalism so wouldn't it make sense to have professional-looking images be in higher demand to give the impression the articles show a professionally-taken image? -- 16:05, 11 April 2016 (EDT)

I can't help but feel some of my commentary towards you is being ignored or you are picking out certain things in this discussion that have little to nothing to do with the proposal at hand. I am not suggesting N64 images to be undersized. I think you are confusing internal resolution with output resolution of real hardware with your N64 argument. The internal resolution of an N64 is mostly going to be 320x240, with a few exceptions of having the resolution be 640x480 or some weird resolution (based on angrylion's graphics plug-in found on TCRF), but the analog video signal converter thing that any Nintendo console has before Wii U converts the internal resolution into a signal a SDTV can understand, which is 640x480 composite video. That is why NES and SNES games tend to look pixelated on TVs but an emulator looks sharp because the internal resolution is 256x224 or 256x240 and that resolution is being stretched to fit a 640x480 TV screen. As for oversized GCN and Wii game screenshots, I told you many times I am not advocating oversized imagery. I find it much easier to take screenshots in that manner. I advocate a bare minimum, which is 640x480 for 4:3 and 854x480 for 16:9. A few exceptions to this rule exist because general game hackers are finding true internal resolutions of some of these games being a little bit smaller than those resolutions but my experiences and uploads are based on outdated code that still needs to be fixed that Dolphin Emulator developers haven't fixed yet. -- 16:05, 11 April 2016 (EDT)

On your points.

Pre-release screenshots are another issue. There should be much more leeway given their limited means of getting them. I wouldn't worry too much about them nor would I be tagging them with image-quality unless they're really bad.

If naming and defining categories are a work in progress, you should discuss it first before firing a proposal. That way, there won't be any confusion and questions on them, and it would free time and energy to discuss the actual proposal. And that's another issue: I agree with Baby Luigi that the proposal is premature. These big changes aren't established yet. I also agree with Megadardery on elaborating "almost perfect" category's issues. I also share concerns on his proposed "images that need improvement"; due to the heavy overlap with the current template, the name might as well be the current tag in another name.

Also repeating Megadardery: .svg requests should be removed. We have had this issue with Smash Bros. emblems. Although they are in .png, the problem remains: vector programs such as Adobe Illustrator are far from perfect. To create .svgs from .pngs, you need to trace them with those programs, but the result leaves much to be desired and, worse, is misleading. If you have .svg images straight from the press such as this Mario image, however, you can replace the existing .png. The .svg here is far superior here and is closer to the vector-nature of original artwork, thus retaining the main advantage of vector graphics: scaling them.

File:Koloradocamp.png is not in an appropriate format (a bloated .png), but .jpg is acceptable for screenshots. The advantages of .png, transparency and color preservation, are less important in screenshots, and the .jpg format saves significant file space, .jpg should be the recommended format for screenshots rather than .png. As for oversized resolutions, we're not as stringent as Bulbapedia or SmashWiki in retaining native resolutions. While retaking screenshots at native resolutions helps and we really don't need screenshots at multi-K pixel resolution, it is also not worth the effort to go backward and reupload them all just because resolution is incorrect (but the aspect ratio is good). We're concerned mostly about aspect ratio and the sheer quality of the screenshot. So, some of these images shouldn't be tagged, and that includes the screenshot I linked.

I've suggested personal lists in the past because image management is mostly a small-scale job i.e. it's done by a few users. If you'd like to have users make great use from your list, then organize a project in our Wiki Collaborations forum and link to the appropriate userspaces as resources. You can also link to RAP's page as well as, again, a resource. We all appreciate it. It has worked in the past; on enemy stats, Megadardery let us use his sandbox as a neat spot for data collecting and I also believe as a template, and it's a tremendous help.

I'll help clarify on improvement tag hierarchy. Actually, there really isn't a hierarchy except construction and stub are reserved for lacking and barren articles. The rest are also meant to be serious, but not as much as construction and stub.


 * generally very lacking article or the article is currently undergoing major changes. The tables are visibly incomplete, sections are clearly missing information, big changes are currently being made in the article, most information are in a mere list, and other big problems that would be considered an "informal appearance".
 * the article has serious problems, be grammar, writing style, organization, image clutter, formatting, and other reasons the user can specify.
 * the article is seriously missing information. This generally includes entire games that should be there, but are absent. Or, if it's a level article, there isn't enough information on its layout.
 * a minor issue. Could overlap with rewrite.
 * the article could use serious expansion. Unlike rewrite-expand, this is reserved for tiny articles that lack sufficient information. This is not to be confused with short, but complete articles, which provide all possible information without having to pad. For instance, if all of Mario's page is just the opening paragraph, it would be a stub. Even then, it would be longer than complete short articles. Point being, length partially determines if an article is a stub or not, but it's mostly completeness, or how incomplete it is.
 * the section is seriously lacking information and is often a one-liner. The Wario article, for instance, has this template in its Mario & Sonic at the Olympic Games sections. It is one sentence stating the obvious, yet there is a whole story mode in that game, and Wario even has his own dialogue and role.

Keep in mind, these aren't set-in-stone rules, but based on my observations and experience with the wiki. Either way, I hope I gave you a clearer image for these templates. Finally, don't worry if there isn't a written rule, just use your common sense and keep Don't Shoot Your Foot Off in mind. 18:05, 11 April 2016 (EDT)


 * Images such as File:SMG2 dark mario.jpg I can definitely agree with you do not need but an image such as File:3DMARIO.png does need.
 * Honestly, I didn't expect more work was to be done to my proposal. Seeing the response so far, I may just as an admin for approval to cancel the proposal and postpone it to a later date.
 * OK, I guess removal of is in order but I am not 100% sure it should be removed.
 * I'm 50:50 with PNG vs. JPEG use for screenshots. JPEG would definitely not be acceptable for screenshots of sprite-based games (such as NES, SNES, GB, GBC, and GBA games as well as some games that don't utilize true 3D of N64, GCN, Wii, Wii U, DS, and 3DS games). Compression for those screenshots would almost always be lower in the PNG format than the JPEG format. PNG is great for solid colors while JPEG is great for images with shading. I just default to PNG almost always because it is a very easy format to work with. My experiences with JPEG, I have to fiddle around with compression settings to not be too high in file size while the image doesn't look like it suffers from JPEG artifacting. It's usually a pain for me to work with JPEGs.
 * I feel that personal lists risk being exclusionary and obscure to regular users. 's project failed mostly from what I heard (only up to 1/10th of the images were replaced over the course of a few years and there are still images in poor quality). Tagging an image that could be better is more up-front about it, increases replacement request exposure, and invites people who don't know about the personal lists to contribute better images to the Wiki because that is how the tag functions by design and implementation. I think I was able to replace more images by the tagging method than the personal list method.
 * Wow. I wished those details were included in each of the template's code. I remember  proposing something about  being used incorrectly (something about articles truly being informal). I could never really fully understand what the proposal was asking because the tag itself had a lot of subjectivity surrounding its use. If the tag's description had what you described to me is its proper use, I'm sure his proposal wouldn't need to have been proposed.

Thanks for all your helpful feedback. You and have been the most helpful. -- 19:17, 11 April 2016 (EDT)


 * Not sure why you are prematuarly jumping to conclusions, I believe you are incorrect. First, My oppose was based on my comment and the reasoning I put in the vote. So I was not just picking random things to make a vote. Second, I brang the issue of N64 and Wii resolutions because, as your current proposal implies, these would not be of a perfect quality, and that could make them have this tag as well. And no, I'm not confusing IR and the actual resolution, I said clearly, and multiple times that images should match how the game looks.. nativally on a console, as if emulators never existed, if you take an N64 shot using a capture card it will be 640x480. You also can take Wii/GCN screenshots in a close-to-native resolution easily, but it is not a major issue, that's why I didn't make a serious action against oversized screenshots.

"[...] .jpg format saves significant file space, .jpg should be the recommended format for screenshots rather than .png.", Porple said before that disk space is not a concern, and if that's the case, quality over bandwidth in my opinion.

I stay by my point that should be reserved for images in urge for replacement, and not further, less-serious, templates should be created.-- 19:12, 11 April 2016 (EDT)
 * OK, some misunderstandings occurred. We both misunderstood each other. I hope I can be clearer. First, I have since dropped the original name I gave the categories as provided a less subjective name and I have adopted it. The category will no longer look for "perfect images" but rather something that is clean. Technically, yes, the screenshots I have uploaded of GCN and Wii games would qualify for one of my new proposed tags or go against my own guidelines because they aren't in the right resolution but where those images came from and the faults of the program that produced them is a different story that I have no real control over so it isn't as easy as you make it out to be. If the program wasn't faulty at native resolution when taking screenshots, I'm sure we wouldn't be having this conversation. As for what qualifies as a good N64 screenshot, the capture card method looks at the composite video signal, which is analog, which analog signals are known to degrade over a distance. Longer distances means the degradations get more noticeable. The internal resolution is digital. Digital has no degradation. Screenshots should be taken from this source instead. If that source happens to be 320x240, this is considered the highest quality possible screenshot that is the closest to actual hardware. A few exceptions exist, but it will most likely be 320x240. I see a lot of N64 screenshots forced into 640x480. If I went to the exact spot one of those screenshots are referencing, the pixel-perfect plug-ins I use would be saying the screenshot I selected is 2x in width and height and any HUD elements would see terrible anti-aliasing or pixilation. That means that the emulator-produced image is processing graphics far beyond what the N64 is capable of and is doing so inaccurately. The digital-to-analog converter thing is also a form of inaccuracy. In the case of a capture card, it is just taking a screenshot of an upscaled 320x240 image with some level of analog degradation. That is subpar quality.
 * I also get the need for JPEG, but it should be used with caution, just like PNG. JPEG, I have such a hard time figuring out the right level to set the lossy compression at. If I didn't have such a love for PNG and I wasn't stupid with JPEG, I would say upload the version of the image that is space-efficient (after PNG Monster compression). I will admit that it is hard to tell the difference between a high-quality JPEG with a properly captured PNG of the same subject, especially 3DS game screenshots. It's easier to point out JPEG quality loss if solid colors are involved. PNG is better for solid colors, getting even smaller than JPEG sometimes.

Implement or Delete
I created this template as a draft with the idea of placing it on every wiki page for Mario Party boards. I do not, however, want to put it on before passing this idea to the community. I think this template would allow for easier navigation and support its implementation for that reason.

Proposer: Deadline: April, 12, 2016, 23:59 GMT"

Implement

 * 1) per proposal
 * 2) This definitely works and will benefit navigating the wiki although I must agree with my sister. Next time, create a draft page in your userspace first so you can edit and stuff without having other users possibly notice this template and then start using it, especially if you're just going to end up creating a proposal on its existence.
 * 3) Per Bazooka Mario.
 * 4) - Per Bazooka Mario.
 * 5) Per all.
 * 6) Seems extremely useful, implement it.
 * 7) Per all.
 * 8) This is useful indeed! Per everyone!
 * 9) Per all.
 * 10) Per all, noting BabyLuigi's comments below.

Comments
You should have created a specific draft page for your project before you create an official template. Anyway, your colors are all wrong. Look at how other Mario Party games format their cell colors (an example being Mario Party 5's nav template). Your first style background should be #FAFA00, not #FFFF00, and the second color should be #FFFF33. And if you're going to separate the boards into two categories, you need to specify and create specific cells for each type (split the single player and multiplayer boards into their own cells, not lumped under a single game). The text on the left cells should be centered and bolded. I do support the addition of a navtemplate for the Mario Party boards, as I think it could get one considering Mario Party is a big series, like Mario Kart, that probably should get navtemplates in a similar vein to how it gets racetracks, but please format it correctly when you create new navtemplates. 17:50, 5 April 2016 (EDT)

Merge all YWW [X] Patch Articles with Their Non-Patch Articles
In Yoshi's Woolly World, some enemies, such as the Ruffin Tumble, have a patch form, that is simply a pixelated version of the original enemy; they're the exact same as the originals, except that they look different and that the patch forms are seen in blocks, and are released after the block is eaten. I don't think that one minor difference is enough to warrant separate articles for the original and the patch form. The only thing that might be a problem is their positions in the Scrapbook Theater, but I'm not sure that warrants separate articles either.

Proposer: Deadline: April 18, 2016, 23:59 GMT

Support

 * 1) My proposal.

Oppose

 * 1) Looking at the Dream Team enemies, the R enemies all have separate changes, despite being only recolors with different stats. For consistency, the patch enemies should keep their own pages.
 * 2) per Superchao
 * 3) - Per Superchao.
 * 4) I don't necessarily agree with comparison Superchao is trying to make. We separate R enemies because they're treated as separate enemies, supported by stats and a recolor. We do sometimes merge mere aesthetic variants such as the Scarescraper ghosts. I do oppose because there are only four patch enemies in the game, so all we're getting are four harmless small articles on a minor aesthetic variant. You can also argue that the methods for encountering them is different compared to the standard enemy as another case to leave them split, but just the amount of articles alone tells me it's okay to leave them as standalone.
 * 5) Per Superchao and Bazooka Mario.
 * 6) Completely different enemies. Per all.
 * 7) Per Bazooka Mario.
 * 8) Per Bazooka Mario!

Comments
It may be an issue if all enemies have a patch form, but it seems to me that we have only Bullet Bill Patch, Monty Mole Patch, Nipper Spore Patch, and Ruffin' Tumble Patch that exist. Maybe it's not so bad that we leave it as it is? 19:14, 11 April 2016 (EDT)

Create a template for proposal outcomes
The current coding for the proposal outcome is repetitive and cumbersome to remember every single time we need to archive a proposal, which has resulted in inconsistent headers (we first used Times New Roman, then switched to Comic Sans, and we're allowed to do that because one, there's virtually no guideline on this, and two, the coding is a crap to remember). So, exactly why isn't the outcomes in a template again? Repetitive coding is essentially template fodder, and there's no reason why we need to remember and duplicate difficult to remember coding when we can simply remember a template and use switchers to depend on the outcomes of a proposal. has created various templates in his sandbox pages to demonstrate how we can use the template to make archiving proposals easier.


 * A test on how the new template will look like.
 * Draft page for the template

In the long term, I believe this will greatly benefit users who want to archive older proposals and will make remembering the exact coding less of a hassle.

Also, this will eliminate the egregious misplacement of the notorious and extremely unprofessional Comic Sans font, which will be replaced by Verdana. Comic Sans is not a web-safe font, and any browser who doesn't have it installed will fallback to Arial and therefore look incredibly inconsistent with different browsers, whereas, Verdana is a web-safe standard font that should be used for more professional headers, especially those that notify readers the outcomes of important wiki matters. If past "minor" problems such as the misuse of subspecies and beta elements can be addressed, I don't see why it's particularly difficult to address what is essentially a design problem, which is more important to others than others, like terminology. The little things matter too.

Update: Both options have been merged into one, increasing flexibility of the template.

Proposer:, with great help from Deadline: April 26, 2016, 23:59 GMT

Implement

 * 1) - Why shouldn't we make things easier whenever we can?
 * 2) I agreed before, I'll agree now! A template is better to avoid errors and inconsistencies!
 * 3) - Per proposal. Much better than what it is currently used.
 * 4) Per all, I always found it annoying to copy-paste old codes, this template is going to make it more consistent and easier to use.
 * 5) It's worth standardizing the formatting for the proposal outcomes, especially since such text should go in a template since they're repetitive and are found in several pages, exactly what templates are for. While comic sans dominates proposal outcomes, we also have a few off Times New Roman-styled outcome text lying around, so we should fix that too. That means getting rid of the comic sans: the typeface clashes with everything else (especially since we're supposed to be a serious wiki) and, as a result, the casual, unsophisticated typeface appears ugly and sloppy, which goes against our idea that proposals should be serious matters. Years of careless handling with typefaces do not justify continued mishandling nor do years of editor oversight on what should've been a template in the first place. The only reason it is tedious to change them is the result of that error. Once the changes are done, everything will be much easier to manage, from the template itself to how proposals should be archived. I also think we don't really need to change to Verdana since the font (the colors, size, and bold, that is) does a good job at helping it stand out. Sure, it might seem all minor in the end, but the little stuff shouldn't be disregarded. We should regard every aspect of the wiki as if we care; the egregious use of comic sans gives off the vibe of carelessness. This is an easy, harmless fix. The biggest issue I find is that many of these outcomes are tucked under protected archives, but that in of itself shouldn't be a reason against this change.
 * 6) This will make things so much easier. Per all.
 * 7) Ho boy this has bothered me for ages. Per proposal.
 * 8) Per all
 * 9) Please do. This'll definitely make our work easier.
 * 10) Per all.
 * 1) Per all.

Comments
Maybe we can take a step further and color-code proposal outcomes similar to color legend in the proposals archive? 18:47, 18 April 2016 (EDT)
 * i don't know, i think it's a bit complex to remember what passed and what didn't, and over time, we might have to remember to change it. I think sticking to a three color scheme would keep those simpler. You also have to keep in mind that this also applies to TPP, not simply mainspace proposals, so more stuff gets affected. 19:02, 18 April 2016 (EDT)
 * It is the simplest thing currently: green passed, red failed, gray has no impact.-- 19:05, 18 April 2016 (EDT)
 * ---A spontaneous idea is that we could technically allow both ways of using the template.-- 19:09, 18 April 2016 (EDT)
 * I wouldn't be 100% opposed to this, but wouldn't it overcomplicate things? 19:10, 18 April 2016 (EDT)
 * I did it with a slight modification. If you feel that this creates an inconsistency you can revert it, it's your idea after all.-- 19:13, 18 April 2016 (EDT)
 * I'm a stupid layperson, so it's pretty unclear to me what you changed. 19:15, 18 April 2016 (EDT)

"Comic Sans is not a web-safe font, and any browser who doesn't have it installed will fallback to Times New Roman"

It'll actually fallback to the default Arial typeface, so that's not a valid point. 20:41, 18 April 2016 (EDT)
 * whatever 21:33, 18 April 2016 (EDT)
 * It will depend on the browser really, it can be either but something completely different as well. Inconsistent just the same though. 14:12, 20 April 2016 (EDT)
 * @Mister Wu: tie is basically no-quorum, I created that because it is certainly easier to write than no-quorum, even if it is technically incorrect. The end result is the same. In reality, the template defaults to the no-quorum if you don't specify/specify something incorrectly.
 * @Baby Luigi: right now, if you specify a color (red,green,gray/grey) in the first parameter you can use the second format, otherwise you default to the first format. The usage didn't even get a slight change. And the template edit is just ~55 bytes. Fundamentally I removed the second version so this proposal can focus on the idea of implementing a template in the first place.-- 05:13, 19 April 2016 (EDT)
 * Sounds good. I think I'll just remove option 2 and I'll reset the votes considering that options have been changed (but not the proposal itself). btw, which link to the coding itself is the updated one, so i can link it to my proposal? 10:57, 19 April 2016 (EDT)

Merging option 2 in makes me slightly tempted to oppose. As I said in my original vote, "More parameters might be slightly more complex to use, but make it much less likely that things will end as a mess of inconsistency all over again." I really think this is a serious misstep... - Reboot (talk) 11:07, 19 April 2016 (EDT)


 * @Baby Luigi: It's already been updated. The template draft stayed at User_talk:Megadardery/2 and the usage doc stayed at User_talk:Megadardery/1.
 * @Reboot: The usage didn't get the slightest modification, it was simply merged with the other version. You can use whichever you want. The parameters stayed as simple as they were. Check the usage page again.-- 11:12, 19 April 2016 (EDT)
 * I think his concern is that the extra parameter is overcomplicating things. Like, he would like things to be kept consistent. Besides, uh, is there any use for the color parameter option? I think the simply "passed" or "failed" covers all bases when dealing with proposals. 11:15, 19 April 2016 (EDT)
 * exactly, it is just a different way to use the same template. I told you that you can revert it if you want, I don't mind which way the template is implemented, I only care that a template is implemented.-- 11:23, 19 April 2016 (EDT)


 * Nothing to do what *I* would do, and everything to do with what "random percentage of userbase" would do. Basically, I think if there was only one set of fixed options, it would stop things devolving into a ****ing mess all over again. Having the open "option 2" variables available means things will go wrong.
 * IOW, I think having "option 2" available as well is a Bad Idea if the idea of this is consistency. It should be either/or, and since there's a finite number of outcomes, best to have them locked-in as in "option 1". - Reboot (talk) 17:57, 19 April 2016 (EDT)

Hm, I don't think option 2 is even necessary either, given how superior and cleaner the first one is. The outcomes in the first template are already color-coded and there seems to be no real reason to use different colors outside of red, gray, or green. My suggestion was just a passing thought, but even then, there shouldn't have to be a separate color parameter. 19:12, 19 April 2016 (EDT)

Reorganize species designations in Koopa (species) and Koopa Troopa
See one of Walkazo's essays for a start.

Note: Unless otherwise stated, all referrals here to "Koopa" are intended to mean the Koopa family that consists of turtle-like creatures; examples are Koopa Troopas, Hammer Bros., Lakitus, Shellcreepers, Buzzy Beetles, Spike). The Koopa Troopa species, often shortened in the games as "Koopa", will be referred as the full name; examples are Koopa Paratroopas, Dry Bones, Koopa Striker,

Throughout the wiki's history, there has been confusion surrounding the Koopas as a group of turtle-like creatures and the Koopa Troopa species, mainly how and where to categorize species in these groups. Since there isn't clearly defined taxonomy and "Koopa Troopa" is often shortened to "Koopa", there is always an unclear way of handling these two pages, and, as a result, they're a total mess (with the misuse of subspecies terminology aggravating the situation). The Koopa (species) article, for instance is wildly inconsistent and incomplete. The derived species list under the infobox includes several sorts of stuff including the basic parent species such as Hammer Bro. and Koopa Troopa (not all of them), but also sometimes derived species from them including Ice Bro. and Beach Koopa. By containing several Koopa Troopa derivatives, the article focuses on Koopa Troopas, which feeds into the confusion and leads users to think that this page is redundant with the Koopa Troopa article. The Koopa (species) is needed though, as Bowser, the Koopalings, and Bowser Jr. are not defined aside from being part of the Koopa family, and it would be convenient that other turtle-like Koopa species such as Lakitus, Hammer Bros., and Buzzy Beetles be placed under this article rather than get awkwardly lumped with Koopa Troopas.

The common question is, "What is the difference between a Koopa and a Koopa Troopa?" The logical answer would be that "Koopa" is an umbrella designation to turtle-like creatures in the Mario series. Koopa Troopas are the most common member under this Koopa family. The current state of these articles, however, fail to adequately answer this. While it's true that Koopa Troopas are often shortened to "Koopas" because they're the quintessential Koopa, the focus on Koopa (species) should not be Koopa Troopas. The article instead should cover all creatures that are deemed Koopas (including derivatives), logically or officially, and organize it by basic species. To avoid having it becoming a souped up category or list, the species and their variants will have a short description. Here is one example: There is a section on Lakitu showing a short paragraph on the basic enemy, and Lakitu's variants are listed as one-liner annotated bullet points (the header for this section should be "Lakitu variants" or "Other Lakitu species", though, not just "Lakitus", for the sake of being technical). Unfortunately, the late Walkazo had not brought up the issue of derived species from derived species such as Dull Bones nor is there a discussion on species derived from multiple sources such as Shady Paratroopa. I do, however, suggest that we nest these kinds of species as a double bullet point under their parent species, and creatures with multiple parents are listed twice, similar to how we organize List of species. Check this revision of my sandbox for an idea.

This proposal will not end speculation such as determining Sumo Bro. and Hammer Bro.'s relationship, but it will clear up the confusion between Koopas and Koopa Troopas which lead to illogical statements such as assuming Bowser or Lakitu are types of Koopa Troopa.

Some changes on categorizing Koopas and Koopa Troopas have already been set in place, but this proposal should set these changes rolling into a more organized and concrete form.


 * In short
 * Koopa (species) will include all Koopa creatures. We organize by basic species, alphabetically, and in derived species, we use bullet points followed by a short description.
 * Koopa Troopa will include only species that are or are a type of Koopa Troopa. This means we remove references to Hammer Bros., Magikoopas, Mechakoopas, and Spinies in the list. What is under the Koopa Troopa article infobox should be something like or the in the related species section in the Koopa Troopa gallery page.

Proposer: Deadline: April 26, 2016; 23:59 GMT

Support

 * 1) If this proposal passes, we can expect to clear up confusion that have plagued wiki editors for years, outlined in the Koopa (species) talk page and in Walkazo's essay page I mentioned earlier in this proposal. We can improve the quality greatly of the Koopa (species) article and somewhat of the Koopa Troopa article once this is completed.
 * 2) Per proposal
 * 3) - Per proposal.
 * 4) - Clear definitions are always preferrable over ambiguity. Many pages on this wiki have the problem that they're trying to cover several widely different subjects where one would suffice. If this proposal helps to alleviate that problem, I am all for it.
 * 5) Independently from the simple organization matter, I definitely support this idea!
 * 6) Per all.

Comments
Isn't this why we have the and  templates? -- 21:57, 19 April 2016 (EDT)
 * I believe the issue is more complex than that, though I guess we could make good use of those templates in the meantime. 22:09, 19 April 2016 (EDT)
 * Done. -- 23:32, 19 April 2016 (EDT)
 * Good, now we need to apply major edits to fully clear the confusion once this proposal passes. 19:03, 20 April 2016 (EDT)

I've seen the sandbox, and I'm wondering if it would make sense, in the case of multiple species, to cite the main species among the derived ones, with a "The family of the X species" title to the list (maybe it should be genus, but probably family is easier to understand and, most importantly, its taxonomic sense can be removed to avoid biological speculation). Also, what about an image for each family?--Mister Wu (talk) 22:00, 19 April 2016 (EDT)
 * Well, the paragraph of information already pertains to the main species in the sandbox (which is taken from late Walkazo's prototype), unless you mean derived species with their own derivatives including Paratroopas and Dry Bones. Oh, we can always put the image in each family, no hurry for that. 22:09, 19 April 2016 (EDT)
 * Just a matter of classification - you talk about the generic characteristic of the family and then you list the species - which means that also the species that gives the name to the family is in, just like the red fox (Vulpes Vulpes) is among the other foxes. In your example, you're giving the link to Hammer Bros. in another place, which might be confusing.--Mister Wu (talk) 22:16, 19 April 2016 (EDT)
 * Pardon? Je ne te comprends pas. I organize this by parent species, not necessarily by generic characteristic. Parent species are generally the most well-known of the family so it would make sense to have a paragraph on them and then have the minor derived species with a small description listed underneath. If that's what I'm getting from you. 22:52, 19 April 2016 (EDT)
 * In the case of Hammer Bros., the description is generic enough that it would also fit Boomerang Bros., Fire Bros. and Ice Bros. as well, so it can be interpreted as a description of the members of a family. Which would make sense, this is how it is usually done: you give generic description that fit almost all the members of the family and then list the species. In this case, it would make sense to have the species that give the name to the family in the list. But really, it's just a minor matter on how you want to organize.--Mister Wu (talk) 06:01, 20 April 2016 (EDT)
 * Yeah, I believe I get what you're saying. I do, however, think that it can work both ways. We can list the parent species in one bullet point and just add other bullet points underneath them, but you'll getting into level 4 bullet points, if anyone is okay with that (me, I don't have an issue). Anyhow, either way works. I think I'll be doing the way you suggested, though. 19:03, 20 April 2016 (EDT)
 * I don't think it's always needed to do this, Hammer Bros., Fire Bros., Boomerang Bros. and Ice Bros. could stay on the same level, as they really are variations, while of course Shiny Hammer Bros. would stay as a further level of Hammer Bros. If in some cases (Lakitus and Koopa Troopas come to mind) we indeed end up with a parent species and only derived species, you might use your current layout and just say something like "species derived from X" instead of the single bullet point with many level-2 species. But in the end, I think it's just a case-by-case scenario, just do what you think is better while following Walkazo's suggestions that are indeed a good classification (after all, she studied these topics with passion and dedication!) and, if something else comes to my mind, I might use the sandbox to propose a different classification so that ultimately we can see what works better. This is also why in the end I already voted.--Mister Wu (talk) 22:04, 20 April 2016 (EDT)

Vote For More Than One Option On Proposals With More Than Two Choices
Currently, when there are more than two choices for proposals, we can only vote once. There are fairness concerns with this method. Watch the following video:


 * Example (Duration: 1:35)

If this proposal passes, this should allow for fairer voting if there are more than two options to vote for.

Proposer: Deadline: May 10, 2016, 23:59 GMT

Support

 * 1) I'm curious what other people think.
 * 2) As long as there are no major issues with this, Okay. It's not that common to have such an issue sure, but why not? Sometimes you just don't mind if 1 or 2 wins. You just want 3 to fail. I can't even see a rule against that currently. So maybe technically we could have done that before?
 * 3) - Per all.
 * 4) Strong support. Great Video!
 * 5) That's OK by me and I strongly support!
 * 6) I am fully fine so I support.
 * 7) Per all.

Oppose

 * 1) I'm in the minority here, but in MarioWiki Proposals, users need to have a strong reason to vote for something, and even if there's three options it's unlikely that someone would have strong reasons for two options at once. Letting people vote more than once is confusing too.
 * 2) . In principle I would like to support, but I don't think this has been thought through enough as it stands - in particular, given that Rule #9 requires an absolute majority of votes cast (i.e., 10-6-6 after extensions would fail to give a result as the leading option would only have 10/22 votes), there's a high likelihood that this would cause simply more no-result votes by causing a levelling effect (i.e., all options would get more votes, so any one option getting an absolute majority becomes less likely).
 * 3) Per Reboot.

Comments
I feel like this works better as a case-by-case basis thing rather than a hard, straight rule. 16:52, 3 May 2016 (EDT)
 * I'm not trying to impose a rule about this but rather have it be a possibility. You can always vote for one option only as you always had if there are more than two options to choose from. The only difference is that you can have the freedom to select additional choice(s) if you want to. The outcome is still whatever option has the most votes (margin of three if more than 10 votes). -- 17:16, 3 May 2016 (EDT)
 * It wouldn't quite work case-by-case because who would decide if each proposal falls into this scheme or not? -- 17:30, 3 May 2016 (EDT)
 * It doesn't need to be, I mean, who other than a troll would vote for an option and the opposite.-- 17:47, 3 May 2016 (EDT)

@Megadardery (in particular) - One case to consider. 3 is status quo. The vote ends (after extensions): By the rules, that means 3 de facto prevails. Now, if, say, three people have voted both 1 & 2, do they get to indicate which option they prefer? If they do, do their votes for (e.g.) 2 get knocked out and 1 can go through? - Reboot (talk) 21:23, 3 May 2016 (EDT)
 * Option 1: 11
 * Option 2: 10
 * Option 3: 3
 * There is no preferential voting with my proposed idea how to make our proposals more fair. Preferential voting is more complicated and not a really good fit for something as simple as our proposal system. That is something I recommend for our country's governments, but not here. We just tally votes for each option and whichever option has the most votes wins. Simple as always. The difference is that you can put your name in more than one spot if you do so choose if this proposal passes. -- 23:20, 3 May 2016 (EDT)
 * Indeed we shouldn't over-complicate this. If there's not an option winning by at least three votes when there are more than ten votes, then we keep adding extensions until one option wins or it ends in a No Quorum, as is the case with any proposal now. This proposal doesn't change the rules for defining outcomes but rather how users can vote. -- 23:25, 3 May 2016 (EDT)
 * The thing is I think this will make it harder to get a result. Proposals need an absolute majority of all votes cast to pass (Rule #9 above; so a vote of 10-6-6 is no quorum, not successful - even though it has a four-vote margin, it's still only 10/22). If people are voting twice, this gets harder to achieve unless:
 * Rule #9 is changed to require that more than half of all voters rather than votes support an option.
 * Some sort of preferential system; or
 * A knock-out system where, if an option (or options) are more than three votes behind the leading option when the vote is extended, they are ignored when deciding if subsequent extensions are needed and voters for those options (or all the surviving options) are encouraged to revote.
 * - Reboot (talk) 18:31, 4 May 2016 (EDT)
 * Since you put it that way, I don't think my proposal is flawed but rather how we handle multiple choice votes. -- 16:01, 6 May 2016 (EDT)

Define strong reason. Who is to judge if a reason is strong or not? Also not many people provide much of an explanation with why they are voting a certain way, especially if they say something like per all. Sounds like a stupid rule to have at this point or it needs to be revised. I think that a better term for that would be sensible reason. Not entirely sure how this is more confusing considering that a vote essentially means you are OK with that outcome if it wins. If you place your vote for more than one option, that just means you are OK with any of those outcomes if one of those win. Please elaborate that point. -- 15:12, 4 May 2016 (EDT)
 * Strong reason is outlined above, Rule #4: "Every vote should have a strong, sensible reason accompanying it. Agreeing with a previously mentioned reason given by another user is accepted (including "per" votes), but tangential comments, heavy sarcasm, and other misleading or irrelevant quips are just as invalid as providing no reason at all.". In short, a "strong reason" is one that outlines why you're voting the way you are and doesn't just boil down to "I like it and that's the only actual argument I have". Playing the semantics game here doesn't really change anything, you can replace the words "strong, sensible reason" with all the analogous word you'd like, most people understand the difference between a strong argument and a weak one. To your second question of who is to judge a reasons strength, Rule 5 covers that.
 * I say sensible should be the minimum to strive for. Not everyone has a paragraph to write why they are voting the way they are. I can understand oppose votes doing so, but support votes? Are you just going to repeat what the proposal said? Per all or a short statement is sensible, enough writing in that case. -- 02:30, 5 May 2016 (EDT)
 * Now, all that said, I neither fully agree nor disagree with the proposed idea. It's pretty rare that we have a proposal with more than two voting options, particularly one that lasts more than a few days before being pulled. Given that, this seems like a pointless rule patch. On the other hand, it's such a rare occurrence, have at for all the hell it actually means. -- Ghost Jam[[Image:Shyghost.PNG]] 01:46, 5 May 2016 (EDT)
 * It may seem like a very small change, but it can have some very positive consequences in some proposals. The immediate benefit is more freedom to choose what you would be comfortable with as a change to MarioWiki. You could argue that this could encourage a multiple-choice proposal where proposers could think deeper about their proposals before submission. It could create option(s) that have nicer middlegrounds if the proposer's first choice is seen as too extreme by others but the proposer wants some sort of change to occur anyways. -- 02:30, 5 May 2016 (EDT)

@Reboot: I truly don't see how voting for more than one option would cause that to happen more often. It could go either way and that is completely independent of how many options people can vote for. -- 16:15, 6 May 2016 (EDT)

I agree with Ghost Jam. Rarely, if ever, do proposals have several choices that can combine with each other; i.e. choices are usually mutually exclusive. I don't think this proposal is going to have much an effect if it passes. 20:31, 6 May 2016 (EDT)