MarioWiki:Proposals

http://i143.photobucket.com/albums/r149/Deadringerforlove/dessert1.jpg A proposal section works like a discussion page: comments are brought up and replied to using indents (colons, such as : or ::::) and all edits are signed using the code.

This page observes the No-Signature Policy.

How To
 * 1) Actions that users feel are appropriate to have community approval first can be added by anyone, but they must have a strong argument.
 * 2) Users then vote and discuss on the issue during that week. The "deadline" for the proposal is one week from posting at: (All times GMT)
 * 3) *Monday to Thursday: 23:00 (11pm)
 * 4) *Friday and Saturday: 2:00 (2 am) of the next day. A proposal posted on a Friday ends the following Saturday morning; a proposal posted on a Saturday ends the following Sunday morning.
 * 5) *Sunday: 21:00 (9pm)
 * 6) Every vote should have a reason accompanying it.
 * 7) Users who feel that certain votes were cast in bad faith or which truly have no merit can address the votes in the Comments section. Users can ask a voter to clarify their position, point out mistakes or flaws in their arguments, or call for the outright removal of the vote if it lacks sufficient reasoning. Users may not remove or alter the content of anyone else's votes. The voter can remove or rewrite their own vote at any time, but the final decision to remove another User's vote lies solely with the Administrators.
 * 8) " # " should be added under the last vote of each support/oppose section to show another blank line.
 * 9) All proposals that end up in a tie will be extended for another week.
 * 10) If a proposal has more than ten votes, it can only pass or fail by a margin of three votes. If a proposal reaches the deadline and the total number of votes for each option differ by two or less votes, the deadline will be extended for another week.
 * 11) Any proposal that has three votes or less at deadline will automatically be listed as "NO QUORUM." The original proposer then has the option to relist said proposal to generate more discussion.
 * 12) No proposal can overturn the decision of a previous proposal that is less than 4 weeks (28 days) old.
 * 13) Proposals can only be rewritten or deleted by their proposer within the first three days of their creation. However, the proposer can request that their proposal be deleted by a Sysop at any time, provided they have a valid reason for it.
 * 14) All proposals are archived. The original proposer must take action accordingly if the outcome of the proposal dictates it. If it requires the help of a Sysop, the proposer can ask for that help.
 * 15) There shouldn't be proposals about creating articles on a underrepresented or completely absent subject, unless there is major disagreement about whether the content should be included. To organize efforts about completing articles on missing subjects, try creating a PipeProject.
 * 16) Proposals cannot be made about System Operator promotions and demotions. Sysops can only be promoted and demoted by the will of Bureaucrats.
 * 17) If the Sysops deem a proposal unnecessary or potentially detrimental to the upkeep of the Super Mario Wiki, they have the right to remove it at any time.
 * 18) No joke proposals. Proposals are serious wiki matters, and should be handled professionally. Joke proposals will be deleted on sight.

The times are in GMT, and are set so that the user is more likely to be online at those times (after work/school, weekend nights). If a proposal is added on Monday night at 11:59 PM GMT, the deadline is the next Monday night at 11:00 PM. If it is posted a minute later, the deadline is a week Tuesday, since midnight is considered to be part of the next day, as 00:00 AM.

Basic Proposal and Support/Oppose Format
This is an example how your proposal should look like, if you want it to be acknowledged. If you are inexperienced or unsure how to set up this format, simply copy the following and paste it into the fitting section. Then replace the [subject] - variables with information to customize your proposal, so it says what you wish. If you insert the information, be sure to replace the whole variable including the squared brackets, so "[insert info here]" becomes "This is the inserted information", not "[This is the inserted information]". - ===[insert a title for your Proposal here]=== [describe what you want this Proposal to be like, what changes you would suggest and what this is about]

Proposer: Deadline: [insert a deadline here, f.e. "5 January, 2010, 17:00". Rule 2 above explains how to determine a deadline]

====Support====

====Oppose====

====Comments==== - Users will now be able to vote on your Proposal, until the set deadline is reached. Remember, you are a user as well, so you can vote on your own Proposal just like the others.

To support, or oppose, just insert " # at the bottom of the section of your choice. Just don't forget to add a valid reason for your vote behind that tag if you are voting on anoother user's Proposal. If you are voting on your own Proposal, you can just say "Per my Proposal".

Talk Page Proposals
All proposals dealing with a single article or a specific group of articles are held on the talk page of one of the articles in question. Proposals dealing with massive amounts of splits, merges or deletions across the Wiki should still be held on this page.

How To

 * 1) All active talk page proposals must be listed below in chronological order (new proposals go at the bottom). All pages effected must be mentioned in the brief description, with the talk page housing the discussion linked to directly via "". If the proposal involved a page that is not yet made, use to communicate its title. The Deadline must also be included in the entry. Linking to pages not directly involved in the talk page proposal is not recommended, as it clutters the list with unnecessary links. Place  under the heading.
 * 2) All rules for talk page proposals are the same as mainspace proposals (see the "How To" section above), with the exceptions made by Rules 3, 4 and 5, as follows:
 * 3) Voting in talk page proposals will be open for two weeks, not one.
 * 4) Talk page proposals may closed by the proposer if both the support and the oppose sides each have fewer than five votes.
 * 5) After two weeks, a clear majority of three votes is required. Without the majority, the talk page proposal will be listed as "NO QUORUM".
 * 6) The talk page proposal must pertain to the article it is posted on.

List of Talk Page Proposals

 * Merge information pertaining to generic Blue and Yellow Toads into Toad (species) and Toad Brigade, leaving the separate Blue Toad and Yellow Toad pages for the specific Toad characters that appeared in New Super Mario Bros. Wii. Whether or not these pages will be named "" and "" or "" and "" is also being voted on. (Discuss) Passed
 * Merge Nintendo GameCube Microphone into Nintendo GameCube. (Discuss) Passed
 * Merge Banana Bunch into Banana. (Discuss) Passed
 * Merge Special Kit 1 and Special Kit 2 into Mario vs. Donkey Kong 2: March of the Minis. (Discuss) Passed
 * Split SSX on Tour from Video game references. (Discuss) Deadline: 20 February 2010, 20:00
 * Merge Whip Shuri into Shuri. (Discuss) Deadline: 20 February 2010, 20:00
 * Split NBA Street V3 from Video game references. (Discuss) Deadline: 20 February 2010, 20:00
 * Merge Triple Bananas and Giant Banana into Banana. (Discuss) Deadline: 12 February 2010 20:00. Extended:20 February, 2010, 20:00
 * Split Mushroom (Super Mario RPG info) into Mushroom and (Discuss) Deadline: 20 February 2010, 20:00
 * Merge Metal Luigi into Metal Mario (character). (Discuss) Deadline: 13 February 2010, 20:00 Extended: 20 February, 2010 20:00
 * Merge M into Graffiti. (Discuss) Deadline: 23 February 2010, 17:00
 * Merge all colored Yoshies into Yoshi (species) (Discuss) Deadline: 24, February 2010 20:00
 * Merge Mushroom (SMRPG info), Bad Mushroom, Mid Mushroom, Max Mushroom onto one page. (Discuss) Deadline: 25 February 2010, 20:00
 * Merge Standard Bike M, Standard Bike L, and Standard Bike S into Bike. (Discuss) Deadline: 25 February 2010, 20:00
 * Merge Standard Kart S, Standard Kart M, and Standard Kart L into Kart. (Discuss) Deadline: 25 February 2010, 20:00
 * Merge Entei and similar pages, where characters appear as stage trophies into . (Discuss) Deadline: 4 March 2010, 23:00
 * Merge Turtle (Super Smash Bros.) into Trophy Descriptions (Super Smash Bros. Melee) (Discuss) Deadline: 6 March 2010, 2:00
 * Merge King Bulblin and Lord Bullbo into Bridge of Eldin (Discuss) Deadline: 6 March 2010, 2:00

New Features
''None at the moment.

Non-Mario Appearances in Infoboxes
In infoboxes (the boxes that appear in the top right corner of many articles) e.g. for characters there is information about the first and latest appearances of the characters. While this is fine in my opinion, I propose to get rid of any information about appearances of the characters in question outside of the Marioverse (for lack of a better term; with "Marioverse" I mean all sources and appearances our wiki covers). For example, look at Bomberman (character). He first appeared in a non-Mario game and it's mentioned in the infobox. This kind of information is completely irrelevant to our wiki and just clutters up the infobox. It can be mentioned in an introductory sentence to the article, though, but there's no need to put it in the infobox. It's even worse with the "latest appearance"; there's really no need to keep track of each new appearance of a character outside the Marioverse.

Thus, I propose to only put relevant Mario information (including Yoshi, Donkey Kong, Super Smash Bros. and so on) in the infoboxes and get rid of sources that are irrelevant to the MarioWiki. This applies to every kind of infobox, not only those for characters.

Proposer: Deadline: February 22, 2010, 23:00

Support

 * Per the reasons given above.
 * 1) - Per Time Q again, I mean this wiki is the Super Mario Wiki not the Metroid Wiki, Zelda Wiki, Pokémon Wiki...
 * 2) Per Time Q.
 * 3) – Per all.
 * 4) Per Time Q, especially because of the latest appearance. Why would we have to keep track of the latest Bomberman game, for example?
 * 5) - Of course. Per all above me.
 * 6) Well, this is the Super Mario not one of those Zelda Wikis, or Metroid Wikis.
 * 7) We can link them to the wikipedia article or to the article in their wikis or wikias.
 * 8) - Per all.
 * 9) - Per Time Q and Grandy.

Oppose

 * 1) I am Zero! It's not like we give information of every game that charactered appeared, so it won't hurt just to leave it as: Mario characters: first appearence and latest appearence and if they appeared on a 3rd-party game then put that in also as a latest appearence with the name of the game in paraentheses. Third party characters: first actual appearence, then Mario game appearence; latest appearence, then latest Mario game appearence or vice versa. Zero signing out.

Comments
I don't think it'll work out right. Does this include Kirby, Ike, Meta Knight, and others for the first appearance thing being irrelevant.
 * None of those characters you mentioned has those infoboxes I'm talking about. But if they had them, we'd put a SSB game as their first appearance rather than a Kirby or Fire Emblem game. Those original appearances can be mentioned in the article itself (for example: "Ike is a character who first appeared in the game Fire Emblem: Path of Radiance...").
 * Oh, okay, that sounds better.
 * But would that not be equally irrelevant? --
 * I think it is interesting to know where a character originated from. It's the same as with introductory sentences such as "Link is the protagonist of The Legend of Zelda series". Even though we don't cover The Legend of Zelda series: it's simply good information to introduce a character. However, there's no reason to clutter up the infobox with this piece of information. And this is especially true for "latest appearances". Why should MarioWiki readers care when and where Link last appeared outside of the Marioverse?

@Reversinator: Well yes, the reason we don't cover the information is because it's completely irrelevant here. We can still link to the Wikipedia article about the original appearance outside the Marioverse in the introductory sentence. No need to clutter up the infobox with it.

@Zero777: Since you just per'd Reversinator, please read my comment above. No relevant information will be lost if this proposal passes.

@King Bean: See above. Seriously, what is your reason for opposing?

Question: Are Banjo and Conker games also to be excluded from the infobox? --
 * I'd say no, since we do cover those games (even though there are only articles about the series).

@Time Q: Alright, sorry for the delay. I really don't see how it's cluttering up the infobox. There's my big reply.
 * Okay, this is a matter of opinion. Yet I don't think your vote is valid. The only reason you gave is that with the information in the infobox, we can link to those appearances. But we could do exactly the same if we removed that kind of info (from the infobox). In no way do I propose to get rid of the links, so your reasoning doesn't really fit to what I'm proposing.

Another Proposal on removing the FI
We voted to keep the FI via this old proposal -. The FI is like idle and most of the pictures that are there are kind of bad (pixelly, logo everywhere, too small, etc.). and Per the reasons of the old proposal.

An alternative is to reuse old pictures like the Featured Articles, as said in the old proposal.

Proposer: Deadline: February 25, 2010, 23:00

Remove the FI

 * 1) Per proposal.
 * Per my reasoning on the old proposal. I don't think the main problem is running out of images. I think the main problem is that the concept of FIs is rubbish. Unlike articles, images are not our work. Also see my comment below.
 * 1) -- Per all.
 * 2) - Per Time Q.

Keep as it is

 * 1) - There are still a lot of images that deserves to be featured. We haven't ran out of them yet.
 * 2) If you keep a sharp eye out for images, you eventually find a nice one. And of course SMG2 doesn't have any artwork yet, it doesn't even have a release date yet! I think we'll have enough images for quite a while, though.
 * 3) There's no release date of SMG2, and you're expecting artwork from that game to just fall from the sky? Per all.
 * 4) As I said before, the wiki still has plenty of images worthy of being featured. Images might not be our work but they give a break from all the writing on the main page, If we get rid of them there wont be any thing but writing on the main page.
 * 5) - Per all.
 * 6) They're still Mario stuff, even if it wasn't our own work. Besides, Featured Images give color and touch to the main page. Come on, think of main page with just two images and the rest are text. Plus, not everyone would look at the 'Shroom anyway.
 * 7) How many times is this proposal gonna come up? Per all. And what do you mean it's been a week and no pics of SMG2? >_>'
 * 8) - As I said in the last proposal of this, and the fact that your impatient and too literal to realize that SMG2 won't be out in a week, so give it time and enjoy the great images we have around the wiki.
 * 9) I am Zero! Per all. Zero signing out.

Comments
First of all: Super Mario Galaxy 2 has not been released yet. I don't know what you're talking about. Second: You can't just propose to "reuse old pictures", you should at least propose rules of when to do so. For example, if an image has less than 10 positive votes at the end of a week, reuse an old picture. Third: one of the reasons for opposing my old proposal was that the Main Page wouldn't be balanced anymore without the FIs. Look at our current Main Page. Since talk page proposals were added to it, it's not balanced anymore at all. Now if we remove the FIs and move the talk page proposals to the right, we could balance it out again.

About the "not our work" thing for the images. I would think of something like this to be going on the shroom', but what if we had some thing like FIs where we could have fan made Mario images made by us users? And the one with the most votes gets on the main page? Maybe? I'm not sure if this is a stupid idea or not so...
 * I wouldn't recommend that. We only have official content on the wiki, no fanon articles etc., so we shouldn't encourage users to make images themselves. But of course we could have all that in the 'Shroom. Just like the FIs ;)

Everyone, I checked on a bunch of websites and it says that it comes out on February 11th, 2010.

You seriously think that it came out last week? Wow.
 * Where did you hear that nonsense? It's supposed to come out around summer time...
 * I checked a bunch a websites, and they all said "TBA 2010". And I look at the official ones. Gamefaqs, IGN, Gamespot, you know, what you should rely on.
 * Same at the Nintendo website. Nintendo is the most official and exact one (obviously).

Okay... But we still have to get rid of the FI.

24-Hour Delay Before Voting on Proposals
I propose to introduce a 24-hour delay for each proposal after it is made before users can vote on it.

Currently, as soon as a proposal is put on this page, users are allowed to vote on it. This is a problem for the following reason: Sometimes, proposals are made that seem very worthy to support, and within few hours, many votes are added. This is bad for people who are not online during that time but who would like to discuss points of the proposal they don't agree with. When they come online after a few hours and already find dozens of votes, they have no change to argue against them, and some of the voters might not even visit the Proposals page anymore after they have voted. Also, during the 24-hour period the proposal can be discussed and, if needed, edited, before any overhasty votes are made.

If this proposal passes, the following changes will be made:
 * Additionally to the "proposer" and "deadline" lines, there will be a line "Voting start" which will be 24 hours after the proposal is made.
 * The voting start time can be exactly 24 hours after the creation of the proposal, however in order to not make things too complicated, proposers can also round one hour up or down (e.g. if the proposal is created at 17:14, one may put 17:00, and if it's created at 17:33, one may put 18:00).
 * The deadline will be one week after the voting start rather than after the creation of the proposal. The usual deadline rules apply (e.g. if voting time starts on a Monday at 18:00, the deadline will be next Monday at 23:00).

This proposal would not abolish the possibility for the proposer to support their own proposal right away.

Proposer: Deadline: February 22, 2010, 23:00

Support

 * Per the reasons given above.
 * 1) - Per Time Q, this is really necessary.
 * 2) This sounds pretty good, so users can discuss it before voting right away.
 * 3) - Per TimeQ. Many proposals get modified in that time-span, making it so that old votes may be inaccurate.
 * 4) - Per proposal
 * 5) – Per all!
 * 6) per all.
 * 7) If people vote right away, well the proposal could be edited the votes could be disproven and become useless.
 * 8) - Per TimeQ.
 * 9) - Per Time Q.
 * 10) yeah, per all
 * 11) Per Time Q.
 * 12) - Per Time Q.
 * 13) - as most voters do not have their own arguments, but just "per" somebody else, this will allow for a more controversial discussion of the subject in question.

Comments
How exactly would we regulate this? –
 * By taking off votes that users put up before the 24-hour period is up. It would be quite simple. My only question is this: would we allow comments during the 24-hour period? Being unable to comment would be counterproductive. OOps, missed a line in the proposal.

Change Proposal Archives
Our current method of archiving gets the job done, but it isn't very efficient when we want to look back and find a specific proposal. You might need to look through 15 archives (which take a long time to load) to find the proposal you're looking for. When the proposal archiving method started, we didn't feel the need to create separate sub-pages for each proposal. Now we have 18 archives and growing, so I feel that we need to create a new system before the number of archives grows too big and it becomes virtually impossible to find a specific proposal.

Things that would change if this proposal passes:


 * Each proposal would have its own subpage which would be linked as something like . That link is supposed to link to the first proposal that ended in 2009. This is to prevent extremely long titles and allow two different proposals of the same name to have different pages.
 * Sub-proposals will be split into regular proposals. For example, this proposal would be split into two different sub-pages since the results are different. Since the second part is not given a formal title, a new title will be created for it like "Rules for Talk Page Proposals".
 * Repeated, overturned, and amended proposals would link to each other. For instance, a page for "Bring back Banjo & Conker" will link to other "Bring back Banjo & Conker" proposals.
 * Scroll boxes would be removed since they are unnecessary on separate pages.
 * Extremely long, erratic, and misleading proposal titles will renamed to something shorter or more appropriate.
 * Proposal archive pages themselves will be deleted, leaving only one centralized archive page which links to multiple sub-pages.
 * The main archive page will remain unprotected and the proposal sub-pages will be unprotected. This is so that relevant information about the proposal (such a recently passed proposal overturning an older proposal) can be added by regular users.

Things that would not change if this proposal passes:


 * No content about the proposals will be altered in any way. The only thing about a proposal that can be changed is the title itself (which only happens if there is a good reason for the title change).
 * Results will not be changed and all results (if applicable) will still be in effect.

Finally, look at this template created by. The template will be used to list Proposal entries. This is how the each proposal will be linked from the main archive page. All the parameters are described on the page itself.

Proposer: and Deadline: 20 February, 2010, 20:00

Support

 * 1) – Per proposal.
 * 2) Per Knife.
 * 3) - Per Knife, and proposal.
 * 4) Per Knife.
 * 5) - Ditto
 * 6) Don't you hate you try to search for a past proposal, but have to search through all the archives!? I agree with the proposal.
 * 7) - Per all.
 * 8) - Per Proposal.
 * 9) – Per all.
 * 10) Per all.
 * 11) - Per Knife (mostly: see comment below).
 * 12) - Per Knife.

Comments
I have to make some things clear.
 * 1) Will there be something like Archive/2009 that links to all 2009 proposals, or will all of them be cluttered in a yet huge page?
 * 2) It may be hard to numer all proposals sonce 2005 or 2006 i dunno, so I suggest numbers are something like #09001 09 for 2009 and 001 because it is the first proposal.
 * 3) Protect old archives and proposals such as the main archive page.


 * No, every single proposal will have its own sub-page. The year is simply there to organize proposal pages by year. Notice the /1 after 2009.
 * 1) It shouldn't be too hard. Even the earliest proposals had deadlines, so we can easily number them chronologically.
 * 2) I'd rather leave all the pages unprotected so that regular users can update the pages as necessary.

22:57, 12 February 2010 (EST)

1 and 2: Ok. 3, update as what? We can protect 2005-2009 archives, and each individual proposal, there wont be any need to edit them.

The pages are supposed to dead and all the discussions shouldn't be edited. However, there are certain things that need to be continually updated. For instance, if a "Bring back Banjo & Conker" proposal actually passes, all previous "Bring back Banjo & Conker" would need a note at the top the page stating that the decision was overturned by a more recent proposal. Protecting pages is more retroactive than proactive. Sure, we may be protecting pages to prevent vandalism, but it also means sysops have more duties and responsibilities.-- 23:17, 12 February 2010 (EST)
 * We'll already have to keep an eye on these pages, and updating a handful of recurring issues is a small price to pay for security; it'd be more trouble for the Sysops if someone goes around changing old, unprotected proposals, forcing us to clean up everything afterwards. Also, wouldn't it be better to simply put related proposals on one page? (I.E. all the "Banjo & Conker" proposals go on the original's page, with the later archive pages being redirects, or bypassed altogether by simply linking to the original page in the main archive entries.) That way, all the information can be viewed at once, without having to bounce between different pages, making it easier to fully understand these often complex issues. Finally, I think your original design for the archive page looks better than RAP's (no offence): the background colour seems like overkill, and the fact that the proposers' names and dates don't line up looks unprofessional, as opposed to the chart design that can be seen at the bottom of this page. My only quibble with the chart is that the "Creator(s)" column's width should be decreased to make more room for the dates, but overall, I think it's the better of the two choices. -
 * Would it be possible to use DPL coding to update that list thing? I think there's a way...


 * 1) From what I've seen, sub-pages rarely get vandalized. Even if they do, users can easily intercept it. An edit on archive page seems pretty suspicious. It is not really necessary to protect over 300 pages for potential vandalism. However, if this does become an issue, we could always change this rule.
 * 2) It doesn't seem right to have one page for similar proposals. Even though the proposals concern the same subject, everything else might be different. For example, one of the Banjo & Conker proposals contains a third option which is a compromise to keep the content, but cover less of it. The same option is not present in the other Banjo & Conker proposals. Other major differences include the date, the users, and the arguments. We might also have problems classifying a proposal by similarity. No proposal is the same and grouping them on one page would imply that they are.
 * 3) This is more of a matter of opinion. I personally like RAP's template over mine. My template was just supposed to be a prototype. I kinda like the color coding backgrounds, it makes it easier to distinguish between passed and failed proposals. BTW, I just kinda copied the template coding from the games page.
 * 4) Concerning 1 & 2: I don't think I could make those major changes if I wanted to anyways. Today is this proposal's last day and Rule 10 forbid me from making any major changes to my proposal. 3 is a different story: You can always bring up issues about the template itself.

@Marioguy: It shouldn't be too hard to update manually. --
 * Like I said in my edit summary, I should have voiced my concerns earlier (dang life - it's always getting in the way); fortunately, like you said, the rules can always been changed down the line if need be (for both points 1 and 2). Point 3 is more of a now-or-never issue, though, since it'd be rather pointless to code all the archives one way initially and then change it all around just because of aesthetics. As long as it works, I'm not inclined to create a huge fuss over it this late in the game. -