View source for MarioWiki:Proposals/Archive/45

{{MarioWiki:Proposals/Archive Template|current=yes}}

<div style="font-size:95%">__TOC__</div>

===Vote For More Than One Option On Proposals With More Than Two Choices===
{{ProposalOutcome|passed|7-3|Can vote more than once each proposal}}
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:

* [https://www.youtube.com/watch?v=orybDrUj4vA 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''': {{user|Wildgoosespeeder}}<br>
'''Deadline''': May 10, 2016, 23:59 GMT

====Support====
#{{user|Wildgoosespeeder}} I'm curious what other people think.
#{{User|Megadardery}} 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?
#{{User|Tucayo}} - Per all. 
#{{User|TabuuandPeach}} Strong support. Great Video!
#{{User|AfternoonLight}} That's OK by me and I strongly support!
#{{User|Fawful's Minion}} I am fully fine so I support.
#{{User|Niiue}} Per all.

====Oppose====
#{{User|Chocolate Mario}} 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.
#{{User|Reboot}}. 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).
#{{User|Roy Koopa}} Per Reboot.

====Comments====
I feel like this works better as a case-by-case basis thing rather than a hard, straight rule. {{User:Baby Luigi/sig}} 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). --{{User:Wildgoosespeeder/sig}} 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? --{{User:Henry Tucayo Clay/sig}} 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.--{{User:Megadardery/sig}} 17:47, 3 May 2016 (EDT)

@Megadardery (in particular) - One case to consider. 3 is status quo. The vote ends (after extensions):
*Option 1: 11
*Option 2: 10
*Option 3: 3
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? - [[User:Reboot|Reboot]] ([[User talk:Reboot|talk]]) 21:23, 3 May 2016 (EDT)
: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. --{{User:Wildgoosespeeder/sig}} 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. --{{User:Henry Tucayo Clay/sig}} 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.
:::- [[User:Reboot|Reboot]] ([[User talk: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. --{{User:Wildgoosespeeder/sig}} 16:01, 6 May 2016 (EDT)
Define '''''strong reason''''' {{user|Chocolate Mario}}. 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. --{{User:Wildgoosespeeder/sig}} 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. --{{User:Wildgoosespeeder/sig}} 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. -- [[User:Ghost Jam|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. --{{User:Wildgoosespeeder/sig}} 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. --{{User:Henry Tucayo Clay/sig}} 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. {{User:Bazooka Mario/sig}} 20:31, 6 May 2016 (EDT)

===Change rule 9 to centre on voters rather than votes===
{{ProposalOutcome|passed|5-3|CHANGE RULE}}
In the wake of [[MarioWiki:Proposals/Archive 44#Vote For More Than One Option On Proposals With More Than Two Choices|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:
#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"
#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:''' {{User|Reboot}}<br>
'''Deadline:''' May 30, 2016, 23:59 GMT

====Support====
#{{user|Reboot}}. Per above.
#{{user|Ghost Jam}} Per my comments below, provided the language is expanded.
#{{user|3D Player 2010}} per all.
#{{User|Fawful's Minion}} per all.
#{{User|AfternoonLight}} I agree! Per all.

====Oppose====
#{{user|Wildgoosespeeder}} 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 ''[[Wikipedia:OR gate|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.
#{{User|Tucayo}} - 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.
#{{User|Roy Koopa}} 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 vote'''r'''s. So that last sentence is irrelevant.
:OR gates as in <kbd><nowiki>if(a || b || !c){OK with winning change}else{Not OK with winning change}}</nowiki></kbd>, not <kbd><nowiki>if(a && b && !c){OK with winning change}else{Not OK with winning change}}</nowiki></kbd>. One will have more trues (OK) than falses (Not OK) if you were to do a [[Wikipedia:Truth table|Truth table]] if you were to set one of the variables to <kbd>true</kbd> and the rest to <kbd>false</kbd>. 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. --{{User:Wildgoosespeeder/sig}} 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. - [[User:Reboot|Reboot]] ([[User talk: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. --{{User:Wildgoosespeeder/sig}} 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. -- [[User:Ghost Jam|Ghost Jam]][[Image:Shyghost.PNG]] 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.) - [[User:Reboot|Reboot]] ([[User talk:Reboot|talk]]) 00:33, 29 May 2016 (EDT)
::Spell it out in future, no one enjoys semantics fights. -- [[User:Ghost Jam|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. - [[User:Reboot|Reboot]] ([[User talk:Reboot|talk]]) 16:54, 29 May 2016 (EDT)
::::Which is why I said "in future". :D -- {{User:Ghost Jam/sig}} 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. --{{User:Wildgoosespeeder/sig}} 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. - [[User:Reboot|Reboot]] ([[User talk: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. --{{User:Wildgoosespeeder/sig}} 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. -- {{User:Ghost Jam/sig}} 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.
*"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. 
Which one do we prefer? What is better for proposals? --{{User:Henry Tucayo Clay/sig}} 23:09, 29 May 2016 (EDT)
: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. - [[User:Reboot|Reboot]] ([[User talk: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. --{{User:Wildgoosespeeder/sig}} 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... - [[User:Reboot|Reboot]] ([[User talk: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. --{{User:Wildgoosespeeder/sig}} 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, {{user|Reboot}} 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. --{{User:Wildgoosespeeder/sig}} 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.) - [[User:Reboot|Reboot]] ([[User talk: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. --{{User:Wildgoosespeeder/sig}} 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. -- {{User:Ghost Jam/sig}} 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 {{user|Reboot}} thought the case was. I wasn't telling you how to do your job. Sorry if you thought that. --{{User:Wildgoosespeeder/sig}} 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. - [[User:Reboot|Reboot]] ([[User talk: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. {{User:Roy Koopa/sig}} 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. - [[User:Reboot|Reboot]] ([[User talk: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. - [[User:Reboot|Reboot]] ([[User talk:Reboot|talk]]) 19:14, 30 May 2016 (EDT)

===Automatically pass proposals if the outcome is clearly unanimous===
{{ProposalOutcome|canceled}}
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''': {{User|Roy Koopa}}<br>
'''Deadline''': June 20, 2016, 23:59 GMT

====Support====
#{{User|Roy Koopa}} My proposal.

====Oppose====
#{{User|Time Turner}} 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.
#{{user|driftmaster130}}&mdash; Per Time Turner; there's a reason why this isn't usually done. Also the specific guidelines seem unnecessary.
#{{user|LudwigVon}} - 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.
#{{user|AfternoonLight}} Per all!
#{{User|Bazooka Mario}} 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. [http://www.mariowiki.com/Talk:Captain_Toad#TPP:_Merge_Toad_Brigade_Captain_and_Captain_Toad One example]: a lot of voters were siding with "do nothing" until I, {{User|Mario}}, voted along with {{User|Baby Luigi}} and {{User|MarioYoshi2}}. 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).
#{{User|Tucayo}} - Per all; there's no urgency in rushing through the process.
#{{User|Andymii}} Per all.
#{{User|Baby Luigi}} per all

====Comments====

===Enforce a timestamp with user signatures===
{{ProposalOutcome|passed|11-1|ASK USERS TO USE A TIMESTAMP WITH THEIR SIGNATURES}}
According to [[MarioWiki:Signature]], ''signature and datestamp are preferable'', referring to when users sign their comments. While clicking the pen icon in the editing interface produces <nowiki>~~~~</nowiki> and automatically inputs a generic signature with a timestamp, several custom user signatures still either have the user manually inputting <nowiki>{{User:Username/sig}}</nowiki> to transclude their signature page, or just typing <nowiki>{{User|Username}}</nowiki>. 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#Usage|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 [[MarioWiki:Signature]] to cover this.<br>
'''''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''': {{User|driftmaster130}}<br>
'''Deadline''': June 20, 2016 23:59 GMT

====Support====
#{{User|driftmaster130}} Per my reasoning.
#{{User|Reboot}} Abso-astheysay-lutely (or "Per driftmaster"). Hell, make it simpler - you MUST sign with <nowiki>~~~~</nowiki>. It is entirely possible to make that produce <nowiki>{{User:Username/sig}} <timestamp></nowiki> in your settings if you want to use that sort of sig.
#{{User|Tucayo}} - I am fine with ''encouraging'' users to sign with <nowiki>~~~~</nowiki> and even to add timestamps to {{tem|unsigned}}, 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.
#{{User|AfternoonLight}} I will agree with all of you! This is a very good idea to use it so, per all.
#{{User|Tails777}} 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.
#{{User|Baby Luigi}} Per Tucayo.
#{{User|Roy Koopa}} Per Tucayo.
#{{User|Ghost Jam}} Per Tucayo.
#{{User|Fawful's Minion}} Per Tucayo.
#{{User|Niiue}} Per all.
#{{User|Andymii}} Per Tucayo.

====Oppose====
#{{User|Time Turner}} 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 {{tem|unsigned}}? {{User:Bazooka Mario/sig}} 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 {{tem|sigfix}} and it would be enforced like any other signature rule). Also adding it to the unsigned template is a good idea. {{User:Driftmaster130/sig}} 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? {{User:Time Turner/sig}} <small><nowiki>[No timestamp given]</nowiki></small>
:'''@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 {{tem|sigfix}}. 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. {{User:Driftmaster130/sig}} 11:45, 14 June 2016 (EDT)
I think if (when?) this passes, at least three things:
#(Re)Create [[MediaWiki:Talkpagetext]] with the text (probably boxed out) <nowiki>'''This is a talk page. Sign your posts with - ~~~~'''</nowiki> 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 <nowiki>{{User:USERNAME/sig}}</nowiki> signatures.
#Add a [[MediaWiki:Sitenotice]] for a week or so to the same effect.
#Make it so that it has to be any time a post is made (basically any time other than a proposal vote).
- [[User:Reboot|Reboot]] ([[User talk:Reboot|talk]]) 07:55, 14 June 2016 (EDT)
:Note that pages that change texts in the MediaWiki namespace are language-specific, editing just the [[MediaWiki:Talkpagetext|Talkpagetext]] page may only change or add the English variant. I might be mistaken, as it doesn't apply to all ([[MediaWiki:Sitenotice|Sitenotice]] being one), but keep this is mind. {{User:Lakituthequick/sig}} 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. - [[User:Reboot|Reboot]] ([[User talk: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. [http://images.ltquick.nl/mariowikiDutch.png Example.] These texts are (mostly) editable with the MediaWiki namespace, but you only edit the English one, others remain unchanged. {{User:Lakituthequick/sig}} 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. - [[User:Reboot|Reboot]] ([[User talk:Reboot|talk]]) 19:29, 15 June 2016 (EDT)

If a user enters <nowiki>~~~~</nowiki>, the signature as set in their preferences is automatically inserted, plus timestamp. If they manually enter their /sig as template, or go for {{tem|user}}, they should add <nowiki>~~~~~</nowiki> after it, as five tildes only insert the timestamp.<br>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: {{User|Lakituthequick}} 15:00, 14 June 2016 (EDT)
:Setting it up in preferences may be easier though to save users from having to type out <nowiki>~~~~~</nowiki> 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. {{User:Driftmaster130/sig}} 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 <nowiki>~~~~~</nowiki> behind your transcluded signature, or configuring it to automatically display a timestamp in preferences isn't that hard, either. {{User:Driftmaster130/sig}} 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 [[user:driftmaster130/work|here]]. {{User:Driftmaster130/sig}} 12:21, 18 June 2016 (EDT)
:"''mandatory''". No, we will not use the word mandatory but "encouraged". --{{User:Henry Tucayo Clay/sig}} 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. {{User:Driftmaster130/sig}} 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 <nowiki>~~~~</nowiki> (e.g. "[[MarioWiki:Signature|Signature and datestamp are preferable.]]" {{User:Bazooka Mario/sig}} 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 {{tem|sigfix}} 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). {{User:Driftmaster130/sig}} 11:53, 19 June 2016 (EDT)

===Move Mario Party 3 Duel Maps back to their old capitalization===
{{ProposalOutcome|passed|11-2|MOVE PAGES BACK}}
I've been patiently waiting for the 4 weeks to pass so I can address [[Talk:GATE_GUY#Move_to_all-caps_names|this]] with an actual proposal, as it should have been done, not with a TPP.<br>

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 {{fakelink|AROWHEAD}}([http://gamesdbase.com/Media/SYSTEM/Nintendo_N64//Manual/formated/Mario_Party_3_-_2001_-_Nintendo.pdf]). But in all seriousness, these all-caps names don't even look good and the linked TPP should be reverted.<br>

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

'''Proposer''': {{User|Tucayo}}<br>
'''Deadline''': June 21, 2016 23:59 GMT

====Move back====
#{{User|Tucayo}} - Per proposal.
#{{User|Glowsquid}} - lmao I had no idea this happened. This is like writing all the SMRPG item and enemy names in CamelCase. Laughable.
#{{user|driftmaster130}}&mdash; The current form is useless, per Tuacyo and Glowsquid.
#{{User|Time Turner}} There's a certain point where the letter of the law should really take a backburner to the neater solution. Per all.
#{{User|Bazooka Mario}} Per all.
#{{User|Reboot}} - Per all.
#{{User|Baby Luigi}} Question, will the Sonic series names in [[Green Hill Zone]] be changed as well?
#{{User|AfternoonLight}} Let's move it back, shall we?
#{{User|LudwigVon}} - Per all.
#{{User|Megadardery}} - Per all, also to be consistent with literally everything else on the wiki.
#{{User|Andymii}} Per Tucayo and Glowsquid.

====Keep all-caps names====
#{{User|3D Player 2010}} Per all the reasons why the move was done originally.
#{{User|Roy Koopa}} 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. [[User:Tails777|Tails777]] ([[User talk: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. {{User:Time Turner/sig}} 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. <br>
EDIT: Wait, I don't even know why are those capitalized, there's no reason they should be. --{{User:Henry Tucayo Clay/sig}} 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. {{User:Baby Luigi/sig}} 23:07, 14 June 2016 (EDT)