MarioWiki:Proposals/Archive/45

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)

Change rule 9 to centre on voters rather than votes
In the wake of this proposal passing, rule 9 is slightly vague - it says a multi-option proposal must have majority support, and a majority of all votes. It's now possible to pass the first criterion (more than half of voters support something) but fail the second (because of multiple votes).

This proposal would make two changes:
 * 1) Change the section of Rule 9 that says "more than half of all votes cast must be for a single option" to "more than half of all voters must have cast votes for a single option"
 * 2) Change the last bullet point in the summary brown box at the top of this page from "All proposals must pass by a majority, including proposals with more than two options." to "All proposals must be approved by a majority of voters, including proposals with more than two options."

This won't change much, it's more cleanup to reflect the new status quo than a major revision.

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

Support

 * 1) . Per above.
 * 2) Per my comments below, provided the language is expanded.
 * 3) per all.
 * 4) per all.
 * 5) I agree! Per all.

Oppose

 * 1) Your worry about my proposal passing skewing results unfavorably or proposals ending in NO QUORUM is all theoretical. The voting system I proposed was vote for the outcome(s) you are comfortable with if one were to win rather than vote for your favored outcome. The votes operate as an OR gate of sorts. It's a rather simple change and it is as simple as it gets for voting. Also the majority requirement may not be as bad as it sounds because the new algorithm could reveal how controversial the proposed change was (controversy not meaning good or bad just meaning there was a lot of debate). I say you should just see how things go after several more than two choice proposals have run their course before this should be thought about. Until the results are in, then we review our voting system handling more than two choices. Also if you really think the voting system is flawed, then we should overhaul it for more than two choice proposals but keep the same rules for two-choice proposals.
 * 2) - I will oppose for the time being because I don't see the benefit in doing this and I don't want the proposal to pass before I get an answer.
 * 3) I oppose this for one of the same reasons I didn't like the proposal mentioned; having the multiple vote function seriously screws with the outcome because people who vote more than once for the same option (i.e. 10 vote for option 1, 10 vote for option 2, and 7 vote for option 3; with option 1 and option 2 being made up of only people who vote more than once) result in margins that are not wide enough (for TPPs) or ties (in normal proposals). That's related to this proposal in that in a proposal with 15 voters and 3 options, 8 can vote for option 1, 7 (who are people who only voted once) can vote for option 2, and 1 (who voted twice) can vote for option 3; but then option 1 passes but by a rather narrow margin, which in TPPs would be extended. However, this seems flawed because a margin of 8-7 is nowhere near a majority, and the saying "majority rules" comes into play here. Because of this, I would consider changing my vote if, and only if, the passing margin was changed to either 3/4 or 2/3. This allows for the community to actually agree on what they want, and not have the 7 who voted for option 2 in my example proposal to be constantly complaining about how "this system is flawed" and "we need to change this but can't for 28 days." However, until the margin is changed according to my aforementioned point, I won't be changing my vote.

Comments
Re: Wildgoosespeeder. The situation as it stands after your proposal is not an OR gate because of the "majority of all votes" requirement - this proposal would make it more like an OR gate. It would make literally no difference to Yes/No proposals. It can only affect A/B/C(/etc) proposals where enough people have voted more than once to cause a proposal outcome that fulfils every other requirement to get a definitive result to fail purely on majority of votes, while still getting a majority from voters. So that last sentence is irrelevant.
 * OR gates as in if(a || b || !c){OK with winning change}else{Not OK with winning change}}, not if(a && b && !c){OK with winning change}else{Not OK with winning change}} . One will have more trues (OK) than falses (Not OK) if you were to do a Truth table if you were to set one of the variables to true and the rest to false . The boolean inside the if is just a sample how the user voted (! meaning no vote). Majority vote on the other hand, let's say three options are 45%/25%/30%. That would be a NO QUORUM based on a majority needed for one option. 55% of the votes didn't want the option that got 45% of the votes. Looking at those numbers, there is quite a split how people felt about the proposed change. I say the system is working in that case. -- 23:23, 25 May 2016 (EDT)

And I see no reason to let a bunch of proposals with popular support fall as inquorate just to prove that the situation after your proposal is flawed - this is the simplest way to patch the main problem without having to overhaul everything. - Reboot (talk) 23:08, 25 May 2016 (EDT)
 * It's hard to visualize your wanted changes to the rules. It has to be easy to understand. -- 23:23, 25 May 2016 (EDT)

Until another three plus choice proposal comes along, all of these rule patches are basically conjecture. For the purposes of this discussion, I'd agree to the proposed change if it only applies to the previous rule patch. The current text of this proposal suggests that it's across the board change. -- Ghost Jam 23:26, 28 May 2016 (EDT)
 * It only applies to the previous rule patch. (While technically it applies across the board, in practice it is 100% identical when one member=one vote. The only reason I didn't spell this out was that it's just more words to the same effect.) - Reboot (talk) 00:33, 29 May 2016 (EDT)
 * Spell it out in future, no one enjoys semantics fights. -- Ghost Jam[[Image:Shyghost.PNG]] 15:03, 29 May 2016 (EDT)
 * I can't edit it now though without admin permission - it's been going for more than three days. - Reboot (talk) 16:54, 29 May 2016 (EDT)
 * Which is why I said "in future". :D -- 22:58, 29 May 2016 (EDT)

I must not be getting it but can someone explain what this proposal does? I feel that my oppose vote and its explanation are way off the mark and has been that way for several days. If it is just a wording change and that's it, OK, but if this proposal is changing how we determine the winning option, then my oppose vote stands as this proposal could be in violation of rule #7. -- 16:07, 29 May 2016 (EDT)
 * If you're even looking at Rule #7 (no overturning votes within a month), you're definitely way off the mark, but I don't see how to explain it to you in any way I've not already tried. In no way, shape or form does this reset things to the way they were before your proposal, so R7 is irrelevant. - Reboot (talk) 16:54, 29 May 2016 (EDT)
 * Googling for "define overturn", overturn doesn't necessarily mean to reverse or undo. It can also mean to invalidate. So it is just a change of words and NOT how we evaluate a winning option (if NO QUORUM). Since that is the case, why put in that much effort into a proposal for such a tiny change? Past experience with proposals I made dealing with small changes lead people to vote against it claiming the payoff is very little. -- 17:03, 29 May 2016 (EDT)
 * Defining it vs. how it's enforced. We don't enforce rule #7 the way Google has defined the specific words for you, so it's not going to be an issue. That said, we've made far more fiddly changes in the past for much more minor aspects of the site, so arguments to that effect are going to be less effective. -- 22:58, 29 May 2016 (EDT)

OK, clear something up for me regarding your point #1. For example, we have a proposal with three options. Reboot, Ghost Jam, and myself voted for option #1; Reboot and myself voted for option #2; Ghost Jam and Wildgoosespeeder voted for option #3. Which one do we prefer? What is better for proposals? -- 23:09, 29 May 2016 (EDT)
 * "more than half of all votes cast must be for a single option", which is how we have it right now. This way, the proposal would not pass.
 * "more than half of all voters must have cast votes for a single option", which is the proposed change. This way, the proposal would pass.
 * You have it right (except for the fact that point 2 is the same as point 1, it's just because the thing is written in two separate places), and this was the question I was asking by making this proposal!
 * Clearly, I prefer the second one - my whole reason for doing this, as I think I've made clear, is that I see this situation as a bug caused by a rule that SHOULD have been part of the prior proposal but wasn't because it wasn't thought through enough. (I listed alternatives there, but this was by far the simplest option). Having proposals with majority support which fulfil all other requirements (number of votes, margin of victory, etc) fall as inquorate because some voters have cast secondary votes, when the reason it falls as inquorate is a rule which never envisaged secondary votes as a possibility... it's a bug, to my eyes. - Reboot (talk) 00:16, 30 May 2016 (EDT)
 * MarioWiki's proposal system is supposed to be the right balance of fairness and understandability with its participants. Getting really technical with the rules would likely not be in the best interest of MarioWiki. A proposal system shouldn't favor the proposer but rather favor those who contribute. Your rule change proposal suggests this. If my 45%/25%/30% example is NO QUORUM, so be it. The proposed change was likely not a good one anyways. -- 00:38, 30 May 2016 (EDT)
 * Thing is, I would see your 45%/25%/30% proposal, with some users giving multiple votes, as (e.g.) 60%/35%/30%. It's all about "can it command majority support". If yes, then - if it fulfils the other criteria such as "margin of three if there are more than ten votes" - it has received enough support to pass. I really wonder why you're so angry about this... - Reboot (talk) 01:00, 30 May 2016 (EDT)
 * That's 115%. I'm not angry. I am disappointed. This proposal feels like it is trying to dodge rule #7 in a technically non-violating way to reduce the power of voting more than once without giving it enough time to see the actual results first before considering making another amendment if voting more than once causes issues. -- 01:40, 30 May 2016 (EDT)
 * If you are right about that, that was my initial concern about this proposal messing around with rules, which had me concerned this proposal could be violating rule #7 because the result of my proposal was enforced since May 10 (almost three weeks, which isn't enough time). Also, has another proposal active on Talk:Skull Switch that has more than two options, which ends two days later than this one. This is striking me as kind of odd. -- 23:32, 29 May 2016 (EDT)
 * Again, as Ghost Jam has now pointed out to you as well (above), Rule #7 doesn't come into it. This is not in fact nor in intention, in the way MarioWiki habitually uses the word, overturning a vote. (And the Skull Switch one requires a huge last-minute inrush of votes not to be inquorate no matter what, so it hardly matters.) - Reboot (talk) 00:16, 30 May 2016 (EDT)
 * It doesn't hurt to see what other admins think about my thoughts about your proposal. It would be in the best interest of MarioWiki if they acted as a group instead of individually with something as complicated as a proposal. The individuality they possess would be more useful in stopping vandals or something, but not proposals. -- 00:29, 30 May 2016 (EDT)
 * The administration team is an assortment of individuals, not a hive mind. The fact that we can openly disagree with each other is part of why admins are allowed to participate in proposals in the first place. I'll thank you to not tell us how to do our job or what our place is. -- 00:56, 30 May 2016 (EDT)
 * OK, wrong phrasing. What I mean is that one admin saying I am wrong about rule #7 does not mean all admins would think that. You weren't telling me that on behalf of the others and I should stop saying that. You were telling me that on your own judgments. Unless a lot of the admins think what you are thinking, I'll stop saying that. That is what I meant "as a group". I think that is what thought the case was. I wasn't telling you how to do your job. Sorry if you thought that. -- 01:33, 30 May 2016 (EDT)

@RoyKoopa: ...8-7 is not a winning margin. If there are seven against, it needs to be at least 10-7 to pass, per Rule #10 ("If a proposal has more than ten votes, it can only pass or fail by a margin of three votes, otherwise the deadline will be extended for another week as if no majority was reached at all."). That isn't changed at all by this. - Reboot (talk) 09:33, 30 May 2016 (EDT)
 * That's right. I forgot that rule. But still, my point stands that the margin of 50% of all voters being enough to pass is too small. If you do consider that, I might change my vote. 09:41, 30 May 2016 (EDT)
 * I think changing from a simple majority to a supermajority is a very different proposal, which would affect every proposal and TPP on the wiki going forward, not just a small minority. Besides, far too late to edit this one, which ends today. - Reboot (talk) 11:14, 30 May 2016 (EDT)

Okay, it's passed but I can't make the change myself. Ghost Jam, if you want to expand it (without changing the substance), I have no objection. - Reboot (talk) 19:14, 30 May 2016 (EDT)

Automatically pass proposals if the outcome is clearly unanimous
When someone write a proposal that's already been discussed, especially when it comes to TPPs, we have to wait for 7 or 14 days for it to pass, even though the proposal has a good majority of votes. Because this wait can be needless when it comes to unanimous proposals, I'm proposing that proposals with at least 15 support votes (two or more of which should be from an admin) and no oppose votes be automatically passed after 48 hours so that, like I said, proposals we know are going to pass will pass without the unnecessary wait.

Proposer: Deadline: June 20, 2016, 23:59 GMT

Support

 * 1) My proposal.

Oppose

 * 1) New information can come to light during the last few days that makes passing the proposal a bad idea. Near-unanimous proposals have been cancelled in the past, and this proposal would go against that.
 * 2) &mdash; Per Time Turner; there's a reason why this isn't usually done. Also the specific guidelines seem unnecessary.
 * 3) - Per Time Turner. 48 hours, is too short to allow a proposal to passed, even with a good majority of support, the result may change after a few days if other information about the subject (like Time Turner said) that makes passing the proposal a bad idea. 7 and 14 days is sufficient time to allow the proposal to passed.
 * 4) Per all!
 * 5) Bad idea. It's better to let a proposal simply run its course. It has happened before: something with seemingly unanimous support suddenly gets turned on its head. One example: a lot of voters were siding with "do nothing" until I,, voted along with  and . Note my comment, "I'll probably be the minority vote here". Also, minority votes can still prove to be valuable and we always invite dissenting votes to try to minimize groupthink; this proposal encourages this anti-intellectual groupthink behavior, and I find that dangerous. While the provision of 15 votes to 0 sounds like a mighty achievement, it's still better to just let the system handle itself rather than create wholly unnecessary rules on the negligible benefit of reducing wait times (hardly any of these proposals are urgent).
 * 6) - Per all; there's no urgency in rushing through the process.
 * 7) Per all.
 * 8) per all

Enforce a timestamp with user signatures
According to Signatures, signature and datestamp are preferable, referring to when users sign their comments. While clicking the pen icon in the editing interface produces ~ and automatically inputs a generic signature with a timestamp, several custom user signatures still either have the user manually inputting to transclude their signature page, or just typing. Neither of these options will give a timestamp (which is an important part of the signature, according to the guideline page) and therefore makes it harder when looking back on older conversations to know when the comment was actually made without having to look at the talk page edit history. The solution is simple; enforce users to either set up their custom signatures to display the timestamp (a simple process even for new users who are inexperienced with wiki syntax, as shown in Help:Signature), or just have them use the plain default signature which already includes a timestamp. If this were to pass then the appropriate changes would be made to Signatures to cover this. tl;dr simply transcluding the signature page as many users do, fails to provide a timestamp and can make reading older messages confusing; the process of setting it up to include a timestamp should be enforced to prevent this.

Proposer: Deadline: June 20, 2016 23:59 GMT

Support

 * 1) Per my reasoning.
 * 2) Abso-astheysay-lutely (or "Per driftmaster"). Hell, make it simpler - you MUST sign with ~ . It is entirely possible to make that produce  in your settings if you want to use that sort of sig.
 * 3) - I am fine with encouraging users to sign with ~ and even to add timestamps to, but not signing with timestamps should not be a warnable offense. I'm saying this just in case users start giving out warnings for not using timestamps if this passes. An informal reminder would do best unless it's extremely recurring, in which case an official reminder would be the best course, but definitely not a warning.
 * 4) I will agree with all of you! This is a very good idea to use it so, per all.
 * 5) I'll be one hundred percent honest, I'm not to keen on saying you MUST use a timestamp or truly enforce the idea, however I do see the usefulness of the idea and how it makes it easier to tell when comments were posted and that's mainly why I'm supporting. If anything, I more agree with Tucayo's point of encouraging it rather than outright forcing it.
 * 6) Per Tucayo.
 * 7) Per Tucayo.
 * 8) Per Tucayo.
 * 9) Per Tucayo.
 * 10) Per all.
 * 11) Per Tucayo.

Oppose

 * 1) I agree with Tucayo, in that encouraging users to use timestamps isn't bad, but I'm not comfortable with the proposal wanting to enforce timestamps, especially if the rule is enforced on all talk pages.

Comments
I'm also very annoyed by the lack of timestamps in some signatures, but if users do not sign with timestamps, should we fill it in for them or not? Also, should we add a timestamp to ? 21:37, 13 June 2016 (EDT)
 * If this passes and users still don't implement a timestamp, then yes (though not having a timestamp would be a reason to issue a and it would be enforced like any other signature rule). Also adding it to the unsigned template is a good idea.  21:49, 13 June 2016 (EDT)

Would this be mandatory whenever a signature is used, regardless of whether it's on a user talkpage or a mainspace talkpage? [No timestamp given]
 * @Time Turner Yes, although on a mainspace discussion page it's easier to know the timestamp since all the conversation takes place on the same page and at least one user will likely include a timestamp; it's still important to know when the individual comments were posted.
 * @Tucayo and Tails777 That was the underlying idea of this proposal, although I used the term "enforce" because "encourage" might have caused some misunderstanding and led people to believe that a timestamp is preferable but not very essential. Also as I said above, if this is implemented the addition of a timestamp will be added as an official signature rule and having a custom signature without a timestamp would be a reason for a . Same with other signature violations (e.g. having a large image or text), it's unlikely that the user will recieve a warning unless they stubbornly refuse to change it (in which case, still, only another informal message or a reminder would be issued, or an admin would change it for them). In short, having a trascluded signature without a timestamp would be treated like any other minor signature violation. 11:45, 14 June 2016 (EDT)

I think if (when?) this passes, at least three things: - Reboot (talk) 07:55, 14 June 2016 (EDT)
 * 1) (Re)Create MediaWiki:Talkpagetext with the text (probably boxed out) This is a talk page. Sign your posts with - ~ and a small-text link direct to an explanation of how to edit your signature on Special:Preferences as raw wikitext for those that want signatures.
 * 2) Add a MediaWiki:Sitenotice for a week or so to the same effect.
 * 3) Make it so that it has to be any time a post is made (basically any time other than a proposal vote).
 * Note that pages that change texts in the MediaWiki namespace are language-specific, editing just the Talkpagetext page may only change or add the English variant. I might be mistaken, as it doesn't apply to all (Sitenotice being one), but keep this is mind. 15:00, 14 June 2016 (EDT)
 * ...MarioWiki.net (German) and MarioCastle.it (Italian) are entirely separate sites. MarioWiki.com is an English-only (in essence) site. - Reboot (talk) 17:58, 14 June 2016 (EDT)
 * That is not what I mean. You can set your language on the main preferences page, which shows all MediaWiki text in that language. Example. These texts are (mostly) editable with the MediaWiki namespace, but you only edit the English one, others remain unchanged. 11:09, 15 June 2016 (EDT)
 * ...I am honestly struggling to see the point of changing the interface language when essentially ALL the content text is in English. All the moreso when we're talking about an instruction re: posting on a talk page. In English. - Reboot (talk) 19:29, 15 June 2016 (EDT)

If a user enters ~, the signature as set in their preferences is automatically inserted, plus timestamp. If they manually enter their /sig as template, or go for, they should add after it, as five tildes only insert the timestamp. This means that if this proposal passes, no changes should (have to) be done to the user's preferences or signature pages. Example to sign off: 15:00, 14 June 2016 (EDT)
 * Setting it up in preferences may be easier though to save users from having to type out each time (adding onto typing out the signature transclusion each time as well). Both the five tildes and preferences method could be listed on the signature page (as well as the former being added to Help:Signature) since they have the same effect. As long as there's an identifying signature with a timestamp, that's the most important part.  16:33, 14 June 2016 (EDT)

@Time Turner Read my comment in response to Tucayo: the word "enforce" is only used to express the importance of having a timestamp; not having one would be treated like any other minor signature violation and is extremely unlikely to result in a warning being issued. Also I don't see a reason for not having one, as LTQ pointed out you can just type behind your transcluded signature, or configuring it to automatically display a timestamp in preferences isn't that hard, either. 12:01, 16 June 2016 (EDT)

Seeing as this will probably pass, the signature policy page and help page should be updated to say that having a timestamp is mandatory (as another signature rule, like I said above). In general, both of them seem poorly written and could use a revamp while we're at it; I tried to rewrite both of them here. 12:21, 18 June 2016 (EDT)
 * "mandatory". No, we will not use the word mandatory but "encouraged". -- 12:24, 18 June 2016 (EDT)
 * Does that still mean that it will be enforced like any of the other signature rules? I don't care the wording used but it's just to make a point that the timestamp is important. 12:32, 18 June 2016 (EDT)
 * But if it's "encouraged", then how will this rule affect anything? This proposal would be likely pointless otherwise if we changed to "encouraged". We already encourage people by default to sign with ~ (e.g. "Signature and datestamp are preferable." 20:19, 18 June 2016 (EDT)
 * As I said above (multiple times), it'll be added as another signature rule, and not having a timestamp would warrant a and would be treated like any other signature rule violation, such as having large images, no links, etc. It seems however, that the admins want to only add that a timestamp is encouraged and not as an official rule (based on Tucayo's comments earlier).  11:53, 19 June 2016 (EDT)

Move Mario Party 3 Duel Maps back to their old capitalization
I've been patiently waiting for the 4 weeks to pass so I can address this with an actual proposal, as it should have been done, not with a TPP.

These names in all-caps (such as GATE GUY) are merely stylizations and do not reflect the actual name of the subject. They are only written once in the manual, and as such this should not reflect how they should be capitalized. Common sense should take precedence here; in all likelihood, the manual is just writing them in all-caps so they stand out. And the game writes the regular boards in all-caps as well and yet we have them as Chilly Waters, so I don't see why we can't have the Duel Maps capitalized the same way; it's also the most consistent thing to do. Hell, if we want to strictly follow the manual, ARROWHEAD should then be renamed to. But in all seriousness, these all-caps names don't even look good and the linked TPP should be reverted.

I'll address the Mario Party 2 minigames later on.

Proposer: Deadline: June 21, 2016 23:59 GMT

Move back

 * 1) - Per proposal.
 * 2) - lmao I had no idea this happened. This is like writing all the SMRPG item and enemy names in CamelCase. Laughable.
 * 3) &mdash; The current form is useless, per Tuacyo and Glowsquid.
 * 4) There's a certain point where the letter of the law should really take a backburner to the neater solution. Per all.
 * 5) Per all.
 * 6) - Per all.
 * 7) Question, will the Sonic series names in Green Hill Zone be changed as well?
 * 8) Let's move it back, shall we?
 * 9) - Per all.
 * 10) - Per all, also to be consistent with literally everything else on the wiki.
 * 11) Per Tucayo and Glowsquid.

Keep all-caps names

 * 1) Per all the reasons why the move was done originally.
 * 2) The all-caps names aren't just from the manual, they appear in-game multiple times. Therefore, I think they should stay how they are.

Comments
In game text also writes the Duel Maps in all caps though. Talking to the Millennium Star on the main menu, he'll give a board suggestion, followed by the character who won the most times on said map. Whenever he mentions a Duel Board map, the title is in all caps. Tails777 (talk) 16:34, 14 June 2016 (EDT)

For the record, the Prima guide for Mario Party 2 uses the same capitalization as the games (so TOAD in the Box is literally written as "TOAD in the Box"). Not that I necessarily agree with the wiki using this capitalization, but just thought I'd throw that out there. 16:53, 14 June 2016 (EDT)

@Baby Luigi: If this passes I hope this can set a precedent so that they can be changed without the need for another proposal. EDIT: Wait, I don't even know why are those capitalized, there's no reason they should be. -- 20:24, 14 June 2016 (EDT)
 * They're all-caps in the game, that's why they're like that in MarioWiki. You can change it to proper caps if you like. You should probably take in account Pac-Man in Smash 4 as well, I remember his stuff was all caps as well. 23:07, 14 June 2016 (EDT)

Merge M&L and PM Wiggler articles with Wiggler
Seeing Wiggly and the Wiggler from M&L PJ and the other M&L and Paper Mario Wigglers excluding Swiggler split makes me question why aren't any of these merged in the proper Wiggler article. I mean sure they have a different role from other Wigglers but they all have the same name and there really is no real reason to keep these split.

Proposer: Deadline: June 29 2016 23:59 GMT

Support

 * 1) Per my reason above 🔼 # per my comments below
 * 2) - Per Baby Luigi
 * 3) Until we figure out a solid way of determining which generic enemy characters get articles, I think it's best to merge these Wigglers.
 * 4) Per all.
 * 5) Per all.
 * 6) Per all. This is a very good idea to try!

Oppose

 * 1) The Wiggler article serves as a species page, which covers each officially recognized appearance of the Wiggler. When a Wiggler is given a specific role in a game or appearance such as appearing as a boss, they are treated as an individual character which is separate from the generic species, such as the Wiggler enemies in Super Mario World. For example, Wiggler (Super Mario Sunshine) is also a separate article. But it is given a brief section on the Wiggler page to cover a variation or character as part of the species, and then a reference is made to the main article. I believe this should always be done when Wigglers are treated as a character rather than having a common appearance such as an enemy. Sharing the same name isn't a deciding reason to merge two separate articles.
 * 2) For now I will oppose. I will give my reasoning below. There is more to this proposal than initially thought by the proposer.
 * 3) If this proposal included Wiggler from Sticker Star, I'd vote in favor. As I stated below, it and the one from Paper Jam are extremely similar in terms of both personality and role in the story, so a merge proposal that includes one and not the other is one I can't support.
 * 4) per 7feetunder
 * 5) per BazookaMario's comment bellow: "This proposal doesn't seem well-thought out." It seems pretty clear to me that this isn't going to be sorted out to the satisfaction of all parties in the length of a proposal discussion, particularly when issues that are greater and deeper than the main topic keep cropping up.
 * 6) The proposal seems vague, listing off two Wigglers before stating "and the other M&L and Paper Mario Wigglers," which leaves me worried as to what exactly will happen if this proposal will pass. Per all.
 * 7) Per Ghost Jam. The main reason for that remark is that we have had an extensive discussion and  has had very little participation in the thread and has shown very little understanding for the situation, so I concluded that the user had made this proposal in impulse rather than understanding all points and thinking this through.
 * 8) I changed my vote. While I still support the entire premise of it, as others said, I also have to agree it's poorly planned and thought out, so, per Bazooka Mario and Ghost Jam.
 * 9) Per everyone except YoshiKong. I'd like a proposal to redefine which articles should be split, and which should be merged.
 * 10) Per all

Comments
YoshiKong: So if we give a article for each time Wiggler appears as a boss, should we do the same when Wiggler appears as a playable character and give it a page each appearance of Wiggler as a playable character?-- 19:06, 23 June 2016 (EDT)


 * This issue has been discussed in a past proposal. I agree with the opposing arguments there. 19:41, 23 June 2016 (EDT)
 * Your decision to oppose goes against a lot of what has been established in the wiki. For example, various Koopa Troopa plays specific roles in Mario Party, especially in Mario Party 4 where there's an outfitted Koopa Troopa who's the host (there's a proposal that failed to gain traction because of some dispute, despite that the game clearly intended them to be their own characters). Another example is a single Dry Bones appearing as a boss in Mario Party DS, where bio descriptions specifically list the Dry Bones as his own character in the game, where they use singular pronouns to describe him. In the Mario Baseball games, there's a specific Lakitu who plays the role of the referee, complete with his own dialogue and personality, as well as the only Lakitu appearing in the game. There's a single character called Pink Boo in Mario Party 5 where she was given her own personality as well as even given a gender pronoun, making her technically separate from her species. Calling to split all generic subjects who have been having a unique role at one point unnecessary complicates piping, and I believe it's better off to have articles such as the Wigglers from the RPGs be merged with the general Wiggler article, as, aside from the personality, the single Wiggler is just as relevant as those aforementioned characters I mentioned, yet I don't see the other enemy characters getting split any time soon. Hell, the playable Lakitu character from Mario Kart 7 doesn't even have his own article because the game bios acknowledge that he's the same guy as the guy who held races in the past despite his different shell color from the Lakitu referee. I know Mario Party is a pretty ubiquitous mention here, but it, alongside the RPGs, are the game series most defined for giving generic enemies specific roles and characters, so, we can't ignore what those two game genres did to the generic characters. 20:01, 23 June 2016 (EDT)
 * Pink Boo's gender and personality were introduced in Mario Party 6, not 5. Nitpicking aside, shouldn't this proposal include the Wiggler from Sticker Star? It and the one from Paper Jam are so similar anyway, there's no reason to merge one and not the other. 20:45, 23 June 2016 (EDT)
 * Yeah, probably. Giving all of the Wigglers their own page also unnecessarily complicates piping and navigation. Keeping those appearances all under one article is sufficient enough. 20:51, 23 June 2016 (EDT)

My question is, what makes a character a character worthy of an individual article? What is this "specific role"? The example (Wiggler (Super Mario Sunshine)) provided is a weak one: this one has a drastically different appearance (it also turns into sand when defeated) and has a different Japanese name. 21:05, 23 June 2016 (EDT)
 * There's the Mario Party Advance characters... 22:07, 23 June 2016 (EDT)
 * According to Time Turning (here), they get articles cause "they're found in unique circumstances, interact with the player in a unique manner compared to other games, have unique dialogue, give unique items and quests..." In a sense, I understand that, but at the same time I feel like there are plenty of characters who meet these requirements. Many of the characters in Mario Super Sluggers have unique personalities, outright challenge the player to missions, a few give quests to the player. I'm not fully sure, but do we have a real way of determining which generic characters get articles? I mean characters from most RPGs are exceptions for their more unique designs, actual names and such, but what of the characters who differ very little from their parent species? 23:09, 23 June 2016 (EDT)
 * I think for characters that differ very little from their parent species, we just assume they're a member of that species and list information about them in the parent species article. Of course, Goombob, Goombetty, and Akiki will still keep their own pages, but for the other members, I think they should be remerged. The logic that Time Turner gives can be applied to pretty much anything with a dialogue and a role, including the Wiggler giving out hootenannies in Mario Party 3, the Lakitu in Mario Kart 7, the Bob-omb host for Mario Party 4's duels, the Para-Beetle in Super Mario Momotarō, and a lot of characters in Mario Super Sluggers. Keeping their articles because Goombob, Goombetty, and Akiki have their articles doesn't seem like a great justification for me. There also raises the question for articles like Yoshi, Toad, Boom Boom, and maybe even Fry Guy but whole confusion about the identities of characters named after their species is a tricky question and frequent contentious issue in this wiki. 19:49, 24 June 2016 (EDT)
 * Honestly, the fact that Akiki, Coach, Goombetty, Goombob, and Hulu have articles should be reason enough for the rest to have articles. The characters with more generic names play exactly the same role as the ones with names, so to sweep them aside solely for their name is incredibly inconsistent. I wouldn't agree with citing other games, either, since, as far as I can tell, this is the only game to give distinct, non-general names to some of its NPC's while also giving general names to other NPC's. This game is the one setting the track record for others to follow. Beyond that, per the stuff I've said every other time this has been brought up.
 * also it's time turner
 * The names and appearance make all the difference, though, in the Mario Party Advance case. How do you know that these names are as distinct? What about Rex, Thwomp, and Dino-Torch in Super Mario-Kun (though I do think the baby Boo, the Thwomp's grandfather, its mother, and the Buzzy Beetle boss should get their own articles)? The Koopa Troopa in the Super Show that's in the same group as Mouser and Tryclyde (Mouser has his own article though)? They are named like that, you think they should get their own articles? The characters are referred to their species name. They also differ very little from their parent species. What's wrong with the alternative to make them a redirect to a section in their parent species's articles? Generic referrals are shaky at best and alleged consistency don't really convince me that much. 20:25, 24 June 2016 (EDT)
 * @Time Turner: My bad, sorry about the name misspelling there. 21:11, 24 June 2016 (EDT)
 * I'll admit, you most likely know much more about Super Mario-Kun than I do, but you're contradicting yourself in your own post when you say that you want other generically named characters to receive articles and Mouser even has his own article. I still haven't been convinced that the MPA characters shouldn't receive articles just because their names happen to be generic. A name shouldn't be the one element that decides whether or not a subject should have an article, especially when other subject have articles when their only difference is a more unique name. I mean, if I go to Mushroom Pool and I see the article mention Coach and Cheep Cheep, I may want to find out more about the characters; if I click on the link to "Coach", I get a short-but-sweet article, but going by what you're suggesting, if I click on Cheep Cheep, I'd get sent to the main article, where I'd have to sort out the unique Cheep Cheep from the generic Cheep Cheep that appear in minigames and the like. I just don't think that it makes sense.
 * I must be typing it half-asleep, but we have a consistency issue on this wiki, and I'm not sure how to handle it, that's what my questions are, especially why Mouser (The Super Mario Bros. Super Show!) is its own article separate from Mouser when Mouser is a character too... and noting the inconsistency of that page and Tryclyde and Koopa Troopa. On searching Coach, the redirect anchors are there for a reason; you'll be directed straight to the respective Mario Party Advance section. Anyway, with the logic, should those characters I mentioned have their own pages? What should the line be drawn between a generically-named member of a species compared to a character that happens to share the name of its species? 20:02, 25 June 2016 (EDT)
 * My point about linking to the Cheep Cheep species page is that MPA features generic Cheep Cheep throughout, albeit in areas that let the notable Cheep Cheep distinguish itself. For example, Reel Cheep features Cheep Cheeps, Chomp Walker and Barrel Peril feature Chain Chomps, See Monkey? features Ukikis, Amplifried features Amps, and so on. Also, the Cheep Cheep article doesn't have a specific section for Mario Party Advance, but rather a single section for the entire Mario Party franchise, which would only make directing users to the character more complicated; besides, if we're going to directly send users to the section instead of the general article, why not just send them directly to an article about the character they clicked on? Honestly, the biggest reason I'm fighting for the MPA characters is because of the existence of Hulu and Goombetty and Goombob (this one literally looks like a generic Galoomba) and the rest: I simply don't see the logic in giving articles to some, but not others. If we wanted to look at which characters deserved articles, their roles in the story, their interactions with the player, and their overall importance should require more attention than anything else, including their name. 21:14, 26 June 2016 (EDT)

There are many other Wigglers to move. These should be considered for merge as well. Although I agree with the merge, I am going to oppose until we consider the other Wigglers I mentioned. If there should be more to consider, refer to Category:Wigglers. -- 20:49, 24 June 2016 (EDT)
 * Wiggler (Mario & Luigi: Dream Team)
 * Wiggler (Mario & Luigi: Paper Jam)
 * Wiggler (Paper Mario: Sticker Star)
 * Wiggler (Super Mario Sunshine)
 * Big Wiggler (maybe)
 * Wiggler (Super Mario Sunshine) is distinct (note the dramatically different appearance and Japanese name), so it should not be merged. Big Wiggler shouldn't be merged either, otherwise we wouldn't have articles for other giant versions of enemies such as Big Boo and Mega Goomba. 21:03, 24 June 2016 (EDT)
 * ^Yep, literally just what I was about to say. 21:05, 24 June 2016 (EDT)
 * Grey areas with that Sunshine Wiggler. Definitely difficult to work with to make a Wiki cohesive. I guess you have a valid point about giant enemies though. What about Klambers and Scuttlebugs? I consider the official Nintendo guides a better source than Prima, if they are both available, which they are for this thing. -- 21:07, 24 June 2016 (EDT)
 * For the record, I'm not going to support proposals that start mass-merging articles, such as the larger variants. The wiki has taken on a "more-the-merrier" approach to articles, and I'd generally like to support that.
 * I'm for creating more articles but I feel that some article creation here is not really called for or feels forced, just to say we have x amount of articles. I think more effort should be with the creation of wanted articles than worrying about splits to create more articles. -- 23:01, 24 June 2016 (EDT)
 * Maybe Fawful's Minion should consider reinstating this proposal so that it includes all the RPG variants of Wiggler instead of those he mentioned? 21:14, 24 June 2016 (EDT)

@Time Turner I'm not trying to sound rude here but did you vote? 21:13, 24 June 2016 (EDT)
 * For now, I don't have a strong opinion one way or another. Besides, someone mentioning Mario Party Advance is basically a cue for me to come in. 21:14, 24 June 2016 (EDT)

@Baby Luigi Will Do. 🙂 21:17, 24 June 2016 (EDT)
 * You forgot about the one from Sticker Star. 21:30, 24 June 2016 (EDT)
 * This proposal doesn't seem well-thought out. 20:02, 25 June 2016 (EDT)
 * Also, Time Turner votes when he wants to vote. Simple. 20:03, 25 June 2016 (EDT)
 * @LeftyGreenMario Okay Mario. 😏 00:18, 26 June 2016 (EDT)
 * Here are my two cents about this: The 'more the merrier' approach the wiki have been slowly taking is not something I support. It feels more organized when all incarnations of a character are in one big article. The only thing that should be split are clearly identified characters, that includes both drastically different designs (This, but not this) and characters that are identified as characters, maybe by a different name. However, I feel this proposal needs more thought though, so I wish if the admins withdraw the proposal until it's more thought and studied.-- 08:49, 26 June 2016 (EDT)
 * @Ghost Jam: Not meaning to tell you what you should do or anything, but wouldn't vetoing the proposal be a good idea in that situation?-- 10:20, 28 June 2016 (EDT)
 * Nah, I believe proposals with vague and uncertain provisions will eventually be opposed. 18:54, 28 June 2016 (EDT)
 * @LeftyGreenMario I made this proposal because I felt like there was no point in keeping them merged anymore, also if it wins I will merge all the Wiggler articles except Swiggler. 19:57, 28 June 2016 (EDT)
 * @LeftyGreenMario And what do you mean by it isn't though out. 20:00, 28 June 2016 (EDT)
 * "all the Wiggler articles" is not a good idea. Does that include the Wiggler Family, or the Wiggler Segments or the Super Mario Sunshine Wiggler, or even the various subspecies? You need to clearly outline what this proposal will cover.
 * I thought I explained it you,, that you can notice: the proposal isn't thorough and you have little involvement in the discussion of the Wiggler; you just came in and said "I'll make a proposal". Sure, we kinda agreed to it, but I don't think you handled it well. 17:58, 29 June 2016 (EDT)
 * @LGM Sure it may be eventually opposed, but it is still a good idea to cancel it outright. Opposing usually means that the idea is rejected. Vetoing means that the proposal is flawed.-- 21:12, 28 June 2016 (EDT)
 * I agree with that a veto is called for here. -- 15:19, 29 June 2016 (EDT)
 * Generally speaking, we only out right veto proposals that are against policy, outright impossible or some rule prevents the proposal from proceeding normally. For general topics like this, we normally let them run their course unless there is a large outcry for early closure (per a lose interpretation of rule 5) or if the proposer requests it (per rule 14). -- 19:16, 29 June 2016 (EDT)
 * Yeah I kinda feel like deleting this proposal thanks. 19:43, 29 June 2016 (EDT)

Create a page for Minecraft: Wii U Edition as a guest appearance
Following Coverage, a proposal must be formed before an article can be created for a guest appearance.

Minecraft has been recently ported to the Wii U, and it comes with some free DLC. Part of that DLC includes a Super Mario Mash-Up Pack, which includes a bunch of Mario-themed skins for the player, nearly every item, block, and entities being retextured to fit the Mario theme, music straight from Super Mario 64, an entirely new world that features a bunch of Mario designs and settings, including recreations of Princess Peach's Castle and Delfino Plaza. Everything is changed to look like it's a blockier Mario game: squids are Bloopers, villagers are Piantas, crafting tables are ? Blocks, note blocks are Note Blocks, wolves are Poochy, and if I listed every change, this proposal would be insanely long. Simply put, Minecraft not only receives a visual overhaul, but an entirely new world that isn't randomly generated. The only caveat is that the core gameplay of Minecraft still remains the same, but when you're playing as Mario, entering Warp Pipes, breaking blocks, and fighting Dry Bones and Hammer Bros. in a world that Nintendo had a hand in creating, I don't think it can be argued that it doesn't have an impact on the game.

Proposer: Deadline: July 6, 2016, 23:59 GMT

Support

 * 1) Per proposal.
 * 2) - Per TT.
 * 3) - Mario content is substantial enough.
 * 4) Per proposal
 * 5) - Per proposal.
 * 6) Per proposal.
 * 7) Per proposal.
 * 8) Par *hic* ale.
 * 9) Per all.
 * 10) - Per all.
 * 11) Sounds like a great proposal and I agree! Let's do it!
 * 12) per all.
 * 13) per all, when I first saw this new edition I thought it already had an article, apparently not.
 * 14) Per all.

Oppose

 * 1) See comments below for more info. This fits more under List of Mario references in video games as a section rather than its own standalone article.

Comments
Does anyone happen to have a full list of the changes, or at the very least a video that covers most of the changes? I don't own a copy of the game myself, so all I can really do is hunt through videos and make sure I haven't missed anything. 22:44, 29 June 2016 (EDT)
 * This may help. And this. -- 23:12, 29 June 2016 (EDT)

@Wildgoosespeeder: Could you elaborate on why you think it should be considered a cameo and not a guest appearance? 23:03, 29 June 2016 (EDT)
 * I've always thought that the in order to quality for a standalone page on MarioWiki, it has to be its own mechanics and have at least one character be the primary focus of the game that have residence in the Mushroom Kingdom, such as Super Mario (series), Mario Kart (series), or Mario Party (series) (there's more but these are handpicked examples). Since the DLC requires Minecraft for Wii U as a base and the base game very unrelated to the Mario (franchise), it shouldn't qualify. I also share this with any game covered on MarioWiki that I am unaware of that has this concern, such as Tetris DS. The ultimate gripe I have is coverage of Donkey Kong (series) and Super Smash Bros. (series) since we have Donkey Kong Wiki and SmashWiki, but that is an entirely different can of worms for another time. If Minecraft shouldn't be in List of Mario references in video games, I would be in favor of creating List of crossovers featuring the Mario series, or something like that. -- 17:07, 30 June 2016 (EDT)
 * What you're suggesting, especially in regards to the Donkey Kong and Smash series, is simply not a view that I agree with. To clarify, we give a single article to games marked as guest appearances (NBA Street V3, SSX on Tour, Captain Rainbow, Densetsu no Stafy 3, Punch-Out!!, Rhythm Tengoku: The Best+, and Skylanders: SuperChargers) and we give articles to nearly every element of games marked as crossovers (Super Smash Bros. series, Mario & Sonic series, Itadaki Street DS, Fortune Street, Wario Blast: Featuring Bomberman!, Game & Watch Gallery, Mario Hoops 3-on-3, and Mario Sports Mix). However, we take a different approach to covering these articles in order to distinguish them from their interwiki counterparts. For example, Ike's article only uses the intro paragraph to describe the character's backstory and then reserves the rest of the article exclusively for the character's role in the games that we cover; the Smash Wiki, on the other hand, not only describes Ike's backstory in detail, but also reserves whole articles for the technical details on how Ike fights in the Smash games, something that the Mario Wiki doesn't do. The article that you put forth wouldn't work with Minecraft mostly because it's not a crossover but rather a guest appearance (unless you want to expand the definition of "crossover"), but also because of the reasons I put forth in the proposal; from my point of view, it should be given its own article. 20:21, 30 June 2016 (EDT)
 * Crossover - That should be the definition to use for non-NPC character (Mario & Sonic (series), the series is owned by SEGA which Nintendo allowed two of their IP series' characters to compete with Sonic characters). The references should be limited to the characters in "NPC mode" (such as how Mario characters are being used as mentioned in List of Mario references in video games). -- 23:57, 1 July 2016 (EDT)

Merge M&L (Dream Team and Paper Jam) and PM (Sticker Star) Wigglers with Wiggler
This proposal come from the ideas from this previous proposal and discussion from here and here. This proposal cover Wiggler (Paper Mario: Sticker Star), Wiggler (Mario & Luigi: Dream Team) and Wiggler (Mario & Luigi: Paper Jam).

I think we should merge all these pages with Wiggler (the species article). The reasons that lead me to believe it is better to do this is because all these Wiggler don’t have a different characteristics from the species in general (Wigglers are usually shown to be calm and gentle, but when threatened or attacked, they become angry and chase after their foes, which mostly described the personality of the three Wiggler above).

If we merge all these Wiggler, should we merge the Wiggler from Super Mario Sunshine? No, this Wiggler has a different appearance and also has a different japanese name which means that it is described as a different Wiggler.

When generic enemies appears as boss in Mario Party 9 and 10, they don’t get articles, even if in 10 most of this enemies are known as a mega form (Mega Sledge Bro., Mega Cheep Chomp, Mega Blooper, Mega Mechakoopa and Mega Monty Mole).

The Super Mario Wiki probably don’t have a good indicator of what make a character, a character worthy for a article especially when it comes to generic enemy that appears as boss/playable character otherwise, we would not have this problem and until there is not a rule or something clear for that matter (how generic enemy get the character treatment), we should merge this. Because I think it gives open doors to generic enemies that appear as bosses/playable character getting pages while some others don’t get a pages and it can become difficult to the coverage. Remaining consistent while the administration is considering creating a rule or something that would help in how a generic enemy can be treated as a character is probably the best solution to this problem. I think that discussion for this kind of matter is also required.

Proposer: Deadline: July 8, 2016, 23:59 GMT

Support

 * 1) per proposal
 * 2) per all (in the end there is no reason to keep them split)
 * 3) Better proposal but not the best. See my comments below.
 * 4) I still support the idea of merging those three Wigglers so per proposal.
 * 5) Per all.
 * 6) Merge it! Per all!
 * 7) Per all.
 * 1) Per all.

Comments
I still find Wiggler (Super Mario Sunshine) be merge worthy because it behaves like a Wiggler or Big Wiggler would. It gets mad and runs when disturbed and has a flower on its head. The only difference is its death sequence and color. That is how we are going to distinguish it? It should be merged with Wiggler (because of name) or Big Wiggler (because of size). -- 23:07, 30 June 2016 (EDT)
 * I'm normally one to agree to merging something under this situation (as I've made clear here), but it's clear that because that Wiggler has a notable name in Japanese that it qualifies as being described as a different wiggler all together, as LudwigVon said. It's the same deal with other enemies with this similarity: the aforementioned Piranha Plants from TTYD are split because multiple things imply that they are different all together, despite similar looks and acts. The multiple proposals on the Parabuzzy/Para-Beetle relations clearly show they are different enemies, regardless of same Japanese/different English names. Sunshine's Wiggler is the same case: different Japaneses name implies that it's a boss amongst Wigglers, it probably just didn't make it through English translating. 23:30, 30 June 2016 (EDT)

Split Donkey Kong Jungle Beat levels from their kingdoms
I brought this up on the game's talk page but no one responded at all.

Currently, we inexplicably don't have any articles for the levels in this game. Instead, the level details are given in the articles for the kingdoms (essentially worlds). This contradicts the whole wiki, where even small worlds like the ones in Wario World have their levels split off.

Ergo, we should split the levels into their own articles. Seriously, is there any reason not to split them off?

Proposer: Deadline: July 14, 2016 at 23:59 GMT

Support

 * 1) - Per proposal. The only things we gain from having these merged are blatant inconsistency and an added layer of tedium for anyone trying to find articles on the levels in this game.
 * 2) - This is indeed the most consistent course of action. I have one question, though; where will the information for the boss battles be left? In the articles for the kingdoms? I haven't played the game so I don't know what would make the most sense.
 * 3) Well, we have to split levels in articles anyway. It's pretty much the standard for this wiki.
 * 4) I'll take it! If the Start Dash was split from the Rocket Start, why not this? Per all on this case because the levels must have their own pages!
 * 5) Why do we need a proposal for this? I get the feeling that the work to create these level pages was abandoned or never gotten around too. The Worlds of Super Mario Bros. and Super Mario Bros. 3 have this issue as well. See World 2 (Super Mario Bros.) and World 1 (Super Mario Bros. 3) for examples to see what I mean.
 * 6) Per All
 * 7) Yeah we should split them so we can find more information on the levels as well like we have with SPM's levels.
 * 8) It doesn't require a proposal since it's consistent with policy.
 * 9) Per all.

Comments
Question: is there anything that's actually preventing the levels from being split, like a proposal or a large discussion? 23:40, 7 July 2016 (EDT)
 * Now that you mention it, if there's nothing like that they could just be split. I understand the proposer's intent, which is likely to get some input as he got none in the talk page, but if there is nothing preventing them from being split it can just be done. -- 23:42, 7 July 2016 (EDT)
 * I kind of figured a proposal wouldn't actually be necessary for this; it was just the easiest way to generate discussion since my talk page post was ignored entirely. I couldn't find any discussion regarding the levels in this game, and since not a single one of these kingdoms had their levels split off, I was legitimately unsure if there was an actual reason why they were merged or that simply no one bothered to split them yet. So if this proposal is unnecessary, then yeah, I'd like to split these ASAP.


 * BTW, about those boss battles: There isn't much to say about them since much like other Donkey Kong bosses, they have their own stages. The details of these battles are usually given in the bosses' articles. (VS. Cactus King and VS. Ghastly King are exceptions since those have actual level content.) 21:53, 8 July 2016 (EDT)


 * Okay you wanna hear my opinion: we should split them because we have all the Super Paper Mario areas split e.g.. The Basement Face-Off and The Menace of King Croacus so we should split them and I've barely played the game and I would like more information just in case I do get it thanks :). 21:57, 8 July 2016 (EDT)
 * Yeah, talk pages are sometimes a hit-or-miss if you want answers. It's why I regularly check any changes to mainspace talk pages, though I wasn't available the past few days. I understand your frustration. 22:30, 8 July 2016 (EDT)
 * My solution is to post on the forums about stuff. You're almost guaranteed to get someone to notice it, and though it may be buried by a previous conversation in the thread, it's much less likely to get buried than if you just posted on a talk page on the wiki. 22:47, 8 July 2016 (EDT)

Create Play Nintendo Article
We don't have Play Nintendo as an article. I am not entirely sure if the article should be created though and how to structure it so it doesn't violate creation of stubs policy. We have Club Nintendo and My Nintendo and those articles are not Mario-specific but they do have things related to the Mario (franchise). Also there are these images that claims are from Play Nintendo:

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

Support

 * 1) Let's see what others think.
 * 2) Per all.
 * 3) I like it! We have Club Nintendo, Nintendo, My Nintendo, and even DIC Entertainment! So, let's go for it!
 * 4) - Plenty of Mario content from what I can see. Per proposal.
 * 5) Per all
 * 6) Per all. It would make a small, but informative article. And there's nothing to lose by covering it. There are plenty of Mario character descriptions to note down. Though I believe the main purpose of the article would be to describe the young child-focused destination of Nintendo's website, and how Mario franchise elements are used to provide its content (like that "rainy day" activity section, for instance).
 * 7) It definitely contains Mario-related material, so it should be given its own page.
 * 8) Per all.
 * 9) Per all.
 * 10) Per proposal.
 * 11) - Per all.

Comments

 * 1) Wait. I took them from Play Nintendo, but they are not only used for that. They are used for many other things. When they need artwork not related to a game, they use that. For example: http://www.nintendo.com/birthday-wallpaper . I saw them in various Nintendo promotional materials.
 * Well, if you need other material, there is this artwork I took from the site.--Mister Wu (talk) 22:45, 18 July 2016 (EDT)
 * I guess Play Nintendo will be the primary usage of these images then. Secondary usage will come later as information surfaces. For now, this discussion seems to be heading in the direction of just how to get the article started. -- 14:52, 19 July 2016 (EDT)

The article was created but the proposal didn't reach its deadline yet. -- 17:05, 23 July 2016 (EDT)

Change all critic ratings on series pages to display only Metacritic or remove ratings on series pages altogether
Right now a lot of series pages (particularly Mario (franchise)) display ratings critics and these are mostly limited to IGN and Gamesport. While these two are the most well known critics, their reviews are often subjective and are based on one person's opinion. Metacritic (which is mostly not present) on the other hand displays an aggregate score based on all critics and gives a much more accurate view on the actual quality of a game and I believe that if we're going to have ratings listed next to games on these pages then only Metacritic should be displayed because of these reasons.

However I also willing to propose that we remove ratings on these pages altogether if people prefer that.

Proposer: Deadline: August 8, 2016, 23:59 GMT

Only display metacritic

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

Remove ratings altogether

 * 1) Honestly, I'd advocate getting rid of the ratings in the table altogether. A lot of entries are created before MetaCritic's inception (until after N64 Paper Mario's release), so a good chunk of games would display the too abundant "Ratings unavailable" statement. Another issue is that different versions of the game can be released and may have different MetaCritic scores, prime examples being games re-released in the Virtual Console, so we have to fit those ratings in that small bar. I personally don't like the formatting of that small bar below the game descriptions in the first place, it meshes pretty badly with the table design. And finally, GameRankings is another reliable review aggregate score and I don't understand why MetaCritic takes priority over it, especially when GameRankings is not far more obscure than MetaCritic.
 * 2) – Per BLOF.
 * 3) Lose it! Per both!
 * 4) Per all.
 * 5) - I don't see ratings as being really necessary in the series pages. They should be left for the articles "Reception" sections where we can have more detail and it works better. I'd even suggest a table similar to Wikipedia's for those sections, but that's subject for another discussion.
 * 6) Per Tucayo an BLOF.
 * 7) per all.
 * 8) Per all (especially my sister). Tucayo has also brought up a point I like to consider, particularly, how Wikipedia handles ratings for their series pages, which is a small table. Still, a better example would be this since it shows the entire series rather than just one game. The biggest thing, though, is that how the ratings are handled are only a drop compared to the ocean of problems the series pages are, so maybe the removal should be part of this giant overhaul package we've been discussing for some time.

Comments
While I agree with what BLOF is saying about older games not having meta critic scores, having the section there increases the readers understanding of how well the game was received (or how "good" it is), which is what I'm guessing a lot of people would want to see when looking into buying a game, which is why we have the section in the first place. I'm not saying that every page should have a reception page, however I'm thinking that making a critical reception section should only be placed onto newer games that can receive that rating, which is sort of what we're doing now anyway. I still haven't made up my mind, I'll think about this more before voting. - 01:46, 4 August 2016 (EDT)
 * Never mind, just realised that this is for series pages. - 01:50, 4 August 2016 (EDT)

I'd honestly rather just get rid of critic ratings from the wiki entirely. 07:16, 4 August 2016 (EDT)
 * Like I said, they still serve a purpose, hence the reason for their existence. We could change how we make them but I think that they're pretty decent, although older games don't have as much. On series pages I don't think that they need to be there at all. - 07:29, 4 August 2016 (EDT)

This proposal doesn't actually have a "none of the above" option, as in something to vote under if you want to keep the status quo. It didn't seem to matter this time around, but it's something to keep in mind. 22:16, 4 August 2016 (EDT)
 * The "oppose" option? It was there, but it was accidentally removed, but I restored it. You might have overlooked that. 22:16, 4 August 2016 (EDT)
 * Welp, that's what I get for making assumptions. 22:22, 4 August 2016 (EDT)

If the Mario Kart series has a rating page, then I say lose it! AfternoonLight (talk) 17:05, 7 August 2016 (EDT)

Create a template for the TTYD badge drop rates
On most of the pages created for the badges that appear in TTYD, there's a handy infobox that shows the rates of badges being held or dropped by enemies during a battle. An example is shown below.

It looks pretty clean and professional. Its code, however, is a much different story.

The code is fairly complex for such a frequently used infobox, and users inexperienced with code can easily ruin the entire infobox by making a typo in the wrong spot. I propose creating a template which streamlines the code found in these infoboxes, making them more accessible and far easier to edit.

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

Create template

 * 1) Per my proposal.
 * 2) That definitely seems a little complex for a template that's repeated that many times, especially with the alt-text on Hold Rate and Drop Rate.
 * 3) Sounds like fun. We have created many templates including the staff, the games, and the companies so, let's do it!
 * 4) The point of a template is to reduce redundancy by only passing in parameters that need to change how something displays. I agree with this just to make things easier to maintain.

Leave as is

 * 1) Until I see what the proposed template would actually look like, I'm hesitant to support this proposal.
 * 2) The code may look complicated, but if you use copy and paste for the main areas, you will have the thing right. If I see the proposed finish, I might change my vote, but it just needs to be just right. Otherwise, I will say "Leave as is." Reason why? There are a lot of badges. It will be used for all of them. If it doesn't fit like this one fits, I will have a lot of trouble trying to support this.
 * 3) A proposal merely pointing out the flaws in the current template design is no good.

Comments
Of course the coding looks complicated when you paste it without line breaks, that's not what is seen when editing a page. Anyway before I vote, I would like to see your proposed template coding. I think a template would be beneficial to standardize the "drop rate percentage", "hold rate" and "drop rate" messages on the top of the table, and a template would also allow that message coding to not appear on the article page.

However, I have concerns about how an automated template could calculating those percentages. Additionally, you would need to consider how you will allow users to input notes about the unused drop rates, such as those seen at Jumpman (Badge). – 06:08, 10 August 2016 (EDT)

I agree! AfternoonLight (talk) 09:13, 10 August 2016 (EDT)

I received an email from just now. They said that these rates are now outdated. For example, the drop rate of HP Plus for Gloomba is now implied to be 2/249, not 2/200, according to the newer version of the document I cited below. I'm not sure if there is urgent need to update them, but if someone wants, I would suggest displaying the demical form on the page and the fraction form in the mouseover text, since fractions with varying denominators are hard to read.


 * Sounds like a Wikidata for MarioWiki  (By the way, the original data is two-dimensional, meaning they can also be sorted by enemy. Would an update to  be appropriate? There are so much data in that document!)

But the enemy infobox already displays items which could be potentially dropped by an enemy. Unless I misunderstood your suggestion? – 16:51, 10 August 2016 (EDT)

Time Turner: I imagine that the created template would be a generic version of the templates that are currently used on this article (like the one shown above). Pseudo-dino (talk) 03:46, 11 August 2016 (EDT)
 * I'd rather see it put into practice first than simply imagine what it would look like. 15:38, 11 August 2016 (EDT)
 * Here's an example of what I mean:


 * This might be bad template design, I'm not sure, but someone with more experience could do it better, I'm sure. It just matches the current design (but probably uses too many parameters). Pseudo-dino (talk) 18:50, 11 August 2016 (EDT)
 * It's... not exactly user-friendly. This kind of code can get easily tangled up with vague variables, especially when there are a lot of them. I'm also interested in seeing the proposer's rendition of the template. 19:31, 11 August 2016 (EDT)
 * honestly I'm rubbish when it comes to making templates but my design would probably end up being very similar to the one Pseudo-dino did. 22:18, 12 August 2016 (EDT)
 * How about two templates where the main template is responsible for the table as a whole and a sub-template that is responsible for each table row? -- 15:29, 12 August 2016 (EDT)
 * Or you know, just have the beginning of the design put in a template, then use it as normal:
 * Or you know, just have the beginning of the design put in a template, then use it as normal:


 * Poison Puff
 * 0/200
 * 2/300
 * Spiny #2 (Glitz Pit, Spike Storm)
 * 0/200
 * 2/300
 * }
 * Other than this option (which is actually preferred, because if a change is needed in the code, it's better to update it in one location), I wouldn't support the proposal, having countless parameters is just silly.-- 06:45, 12 August 2016 (EDT)
 * yeah I would likely end up using this design template if the proposal were to pass. 05:38, 16 August 2016 (EDT)
 * yeah I would likely end up using this design template if the proposal were to pass. 05:38, 16 August 2016 (EDT)

also, I apologize for not being too clear on the proposal; creating a template sounded like a good idea on paper, but after seeing that a proposed template would likely be just as clunky as the original, I'm beginning to have mixed feelings about this myself. I guess I still need to get used to the wiki, lol. 05:38, 16 August 2016 (EDT)

Okay. But remember that it's one thing to simply get an idea passed through the proposal process. You must also be sure that you are capable of actually creating and implementing what you are proposing. If you require help or advice, then you can ask for that help, either from users who may have relevant experience, or any of us from the admin team if you had any doubts. Preferably, such communications with other users should take place before proposing. If it's unclear for voters on how a proposed idea would be followed through, then generally they'd be reluctant to support it. – 07:20, 16 August 2016 (EDT)

Deleting shadow or shadowless versions of artworks
Occasionally (but often enough to have happened repeatedly), users including myself have uploaded both shadow and no shadow versions of the same artwork, and treated them as separate pictures in galleries. Several times, I've seen users questioning the necessity of having both versions stored on this website. Therefore I feel we are obliged to establish a decision through a proposal as to which version we should keep.

An example of the difference may be seen on revisions of File:Dixie Kong - Donkey Kong Country Tropical Freeze.png. Most of the other artworks concerned by this proposal are versions of Super Smash Bros. for Nintendo 3DS / Wii U character artworks.

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

Replace shadowless with shadows

 * – I would like to see us keep the artworks with shadows, as they would aesthetically be the most true and complete version of the artwork. Onwards, users should be more careful when cropping artworks with shadows. Sometimes it is difficult to be sure when a shadow ends, due to the pixels fading as they move away from the character. We would not want users cropping out parts of a shadow accidentally. – See my most recent comment.


 * 1) - Per proposer.

Replace shadows with shadowless

 * Although this is not my preference, I will explain the advantages nevertheless. Artworks without a shadow are able to be cropped tighter (there will be less space around the image). This means that the artworks will be displayed more clearly when placed in galleries and other small thumbnails.


 * 1) - I'm OK with the other option as well.
 * 2) - Shadows waste too much space, typically unnecessarily. Voting both other options to oppose "Replace shadowless with shadows"

Keep both versions available on the wiki

 * This would set a precedent to upload and document every minor variation of an existing artwork, which I believe is quite excessive.


 * 1) This is an incorrect premise. Supporting to keep both versions do not necessarily open invitations to keep every minor variation in the wiki. As Mister Wu pointed out, shadow and shadowless versions are both used in official media, which can bring up the question of which one is the "real" one. It's less complicated, I think, to just use our own discretion on what variation to use and which variation not to use. It's not much of a huge deal to keep both shadow and shadowless versions in the big picture either, so I don't see the harm in keeping both versions.
 * 2) - Shadows waste too much space, typically unnecessarily. Voting both other options to oppose "Replace shadowless with shadows"
 * 3) Both are necessary.
 * 4) I agree so, let's keep it!
 * 5) Per all.
 * 6) Per all.
 * 7) Per all.
 * 8) Per all
 * 9) While both images do not need to be on the same gallery, the aboutfile template suggests linking the image with any other versions, which would make it easier to see or use both. Per all.
 * 10) Per all.

Comments
Frankly, I have good use for both versions on the wiki. I like having official shadows on some areas where I need to use artwork, like scene-building with artworks, and sometimes, when building a wallpaper, I prefer using the version without shadows as it's far more convenient that way than cropping out shadows. Though I don't believe in documenting every single minor variation of artwork, I'd keep having shadows and no shadows. 17:59, 11 August 2016 (EDT)


 * I understand that there are advantages in having both versions. But I have seen users bringing up time and time again whether we really should be storing all these versions. Websites like PidgiWiki are dedicated to documenting and archiving every artwork variation. I just felt that it wasn't within our goal. Of course we want to archive all the different artwork across all games and media, but I feel that the "different artwork" scope we are going by is becoming too narrow when it comes to shadows/non-shadows. Although they're nice resources to have (for user purposes, like you said), it's not necessary for our article/gallery commentary. – 18:25, 11 August 2016 (EDT)


 * I was one person that questioned needing shadow and shadowless where we should only require only one of the two but I never got a response. Gallery talk:Super Smash Bros. for Nintendo 3DS / Wii U -- 18:34, 11 August 2016 (EDT)
 * To be honest, I just stumbled upon the case of the arcade version of Mario & Sonic at the Rio 2016 Olympic Games that uses a shadowless versions of an artwork as main artwork of the character in the official site, while other versions use the same artwork with shadow in other contexts. So, there can be situations in which both of them are useful - if most artwork used in the page is shadowless, an artwork with shadow feels out of place to me.--Mister Wu (talk) 19:14, 11 August 2016 (EDT)

This may be a dumb question, but aren't the shadowless versions technically unofficial, as they have been edited out after the fact by a fan? 19:27, 11 August 2016 (EDT)
 * I wouldn't really say so, because some files are kept in a .pdf format that separates shadows and nonshadows with different layers. You might argue that disabling the shadow layer makes it a "fan" edit, but that they separate layers in the first place is an official move. It's kind of like separating the characters in File:MLPSSXTour.png, but of course, the characters are more important than shadows, so it's not a perfect analogy. 20:37, 11 August 2016 (EDT)

I would not support losing shadowless altogether. Look at Dixie Kong's infobox. Forcing the shadowed image would have the character on the left half of the image and nothing but empty space and a shadow on the right. I agree that galleries shouldn't show both. Shadowless has the advantage that it will always show more of the character. I could support 1) only shadowless or 2) status quo with a new rule that galleries should include one or the other and not both. -- 07:19, 12 August 2016 (EDT)


 * Mister Wu, and Bazooka Mario's vote has brought up some points which I hadn't considered. Seeing as this is generating some discussion, I will leave the proposal to continue until the deadline. And then I'll plan a follow-up proposal to cover Porple's point. – 10:30, 12 August 2016 (EDT)
 * I don't think that the proposal's aim is to only settle on one kind of image and force editing images that have shadows when we don't have an official shadowless image. The priority should be first come, first serve. Easiest maintenance that way. Whatever is unedited and available. -- 20:35, 12 August 2016 (EDT)

Remove critic ratings from the wiki entirely
So in a recent proposal, it was decided that series pages such as Mario (franchise) should have critic ratings removed. My proposal here is to go beyond the scope of that proposal, and expand the decision to every article on the wiki.

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

Eradicate critic ratings on the wiki

 * 1) Critic ratings have bias to them based on the opinion of the critic, and biases are not desirable on the wiki.

Keep critic ratings on the wiki

 * 1) Reviews are important for gauging the public's reaction to a game. They're also supposed to be professional, meaning that the reviewer's biases shouldn't make themselves apparent in the review.
 * 2) - Very strong oppose; ratings are an important part of how the game was received and we don't feature just any review that pops up, only the more reputable ones.
 * 3) The reasons for removing critic ratings in the (series) pages, for a good reason, do not extend to here. The previous proposal was dealing specifically with the formatting of the ratings content in the (series) pages rather than having ratings information in of itself. This proposal also runs directly against an established MarioWiki policy: Reception and sales, so this proposal may not even be allowed, especially without any sort of lengthy discussion. As the policy puts it, "illustrating its real-world impact and popularity is just as important [as] detailing the fictional minutiae of the Mario franchise" and if this proposal passes, it will leave a major gap in our coverage of everything Mario, which runs against encyclopedia philosophy.
 * 4) Per all. It's an important part of the reception a game has received. IGN and GameSpot (the ones we usually feature) are very reputable sources, so there's no reason to remove them.
 * 5) As I mentioned in that said proposal, having critical reception on these pages does serve a purpose, unlike on the series' pages. It shows the game's general reception, showcases why the sales might be the way that they are and can help the reader decide on whether or not to buy the game.
 * 6) per all.
 * 7) Definitely per all.
 * 8) Per Tucky and the lady with the bazooka.
 * 9) As the proposer of the last proposal, I wanted critic ratings removed (although replaced) on series pages due to the subjective reviews (only ign and gamespot are shown) and how insignificant they are to the rest of the details shown. However the game pages share a much wider range of ratings and also aggregate scores as well. Per all.
 * 10) Per Bazooka Mario.

Comments
@AfternoonLight: no offense, but either I'm completely missing the point, but your argument seems a little weak. I know I'm supporting the same choice as you, but could you still explain how Metacritic's score of 88 on Mario Kart justifies that reviews should be kept on pages? --Andymii (talk) 23:44, 11 August 2016 (EDT)

Create "Mini" article
I think there should be a Minis article. This article will be about the Mario Toy Company line of toys that describe Mini Mario, Mini Toad, Mini Peach, Mini Donkey Kong, Mini Pauline, and any other Minis I may be missing. A few titles in the series refers to them as Minis.

The only concerns I have are how to format it so it doesn't violate policy about stubs. Should it be considered a species? Should it follow a similar structure to Koopa (species)?

Proposer: Deadline: August 20, 2016, 23:59 GMT

Create the article

 * 1) Let's go
 * 2) Per all.
 * 3) I agree! I created Pacific Rim Productions, Inc. in the past
 * 4) Yes, make it a species article. This article will be easier to find (by searching) than the categories page. I have some concerns tough. With my proposal out there, I say we should hold on until it is finish (at least the merge part) to expand this proposal to include Toys and Dolls. It is not about doing more than one proposal at a time, it is about these two proposals might go against each other. Even if there was one, I wouldn't vote until mine was done (like I said, at least the merge part).
 * 5) Create it!
 * 6) per all.

Comments
This isn't something that really needs a proposal. A forum topic or asking on the talk page for the most active mini's page would probably have sufficed. -- 02:11, 18 August 2016 (EDT)
 * I don't want to register on the forum yet and didn't think putting the discussion on that talk page would generate enough attention so I thought a proposal would have been the best way to handle this. -- 15:03, 21 August 2016 (EDT)

Reinforce the use of image maps
These would really help people who need help with certain areas of the Mario games. This wiki is an encyclopaedia so we need it to have the most information on the Mario franchise as possible, so I propose to bring back image maps for the following reasons though disagreement may come here:


 * 1) They can really be a help in layout of levels and it entirely shows what one level looks like rather than just having a single image shown.
 * 2) They may've been out of place before but we can easily make a section like this ==Map== in the article for the map. I personally feel that is a perfect solution for someone who wants to see what levels look like and we strive to have the most information on the Mario Series.
 * 3) Maps like and  really might help people (Non-Users) find their way through if it's their first time playing it like it helped me too.
 * 4) Articles without them have less information on them. They may not be stubs but maps can really help guide people who have trouble finding their way through the game (especially kids) so not having maps is redundant.


 * So those are my suggestions so feel free to vote. Just be sure to think very carefully before making your final choice.

Proposer: Deadline: September 1 2016 23:59 GMT

Reinforce Image Maps

 * 1) Per proposal.
 * 2) I know this may take some time to put together, but I'm all for it!

Don't Do It

 * 1) per all the reasons they were removed in the first place.
 * 2) I was never a fan of the really clunky and inconsistent, mystery meat-like navigation that were the image maps. We let a few remain because of various exceptions, but we removed several because their purpose was made redundant by the actual linking in lists, navigation templates, galleries, infoboxes, etc. Furthermore I think we should handle the creation of new image maps on a case by case basis, not a blanket proposal like this, as different image maps are more potent than others.
 * 3) Per all. Also, the wiki is not a guide.
 * 4) Per all on this case.
 * 5) – Per the causes for deletion as discussed in the previous proposal. The image maps you are proposing to restore are redundant because they were already labelled with the level names on the image itself. I don't agree with your reasoning against this. It's simple enough and easy to navigate when using clear and properly-listed links instead. And the relevant world images can still be shown on the article for reference.
 * 6) per all.
 * 7) Per YoshiKong.

Comments

 * Back around May of last year (before I created an account on this wiki) I found image maps very useful for my liking it helped my get through YIDS easily seeing as I'd just purchased it at the time. 20:06, 25 August 2016 (EDT)
 * Actually never mind this proposal will never win. I think I should cancel it. 16:39, 26 August 2016 (EDT)