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:
 * 3) *Monday to Thursday: 17:00 (5pm)
 * 4) *Friday and Saturday: 20:00 (8pm)
 * 5) *Sunday: 15:00 (3pm)
 * 6) Every vote should have a reason accompanying it.
 * 7) At any time a vote may be rejected if at least three active users believe the vote truly has no merit or was cast in bad faith. However, there must be strong reasons supporting the invalidation.
 * 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 can not 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 EDT (UTC -4:00), 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 Saturday night at 11:59 PM EDT, the deadline is the next Saturday night at 8:00 PM. If it is a minute later, the deadline is a day plus 15 hours (Sunday), as opposed to a day minus 4 hours.

CURRENTLY: , 27 2024 (EDT)

Create a Definition of Stub Articles
This Proposal is actually a mere bureaucratic issue, but in order to keep up the democratic structure, we will go through this procedure first.

This proposal concerns Stubs, those annoying articles that make our wiki look unproffessional. Regarding the fact that we have about 1'000 of these articles, it sort of becomes necessary to have a definition for them. At the moment, articles are at the users' mercy to get tagged as stubs or not. An article might get flagged by one user, while another one disagrees. Of course, both sides have their own equally right definitions, and the situation would turn into an edit war if the tag would be removed again. Using Stub tags seems to be based upon decisions made by subjectivity and vastly differs from case to case.

This Proposal's purpose is to take these decisions out of subjectivity's hands and to hand them over to a Guideline that will help us to identify Stubs, without having those horrendous differences between cases. I think this is necessary. How are you supposed to fight something if you cannot even identify it?

As for the contents of this definition, I think the guidelines from Knife's PipeProject would give us a general idea what it could be like. With this, every article that doesn't provide the viewer with answers to the most basic questions becomes stub material; basic questions like:
 * 1) What is the origin of the subject?
 * 2) Where is it located? How is it accessed? How can it be unlocked?
 * 3) What does it do? What is its purpose?
 * 4) Which characters can it be used by? What things are a part of it?
 * 5) What templates or categories can be applied within possibility? If possible, what images can be added?

Of course the resulting definition will not be a mere rip-off of this questions. Something like this needs to be planned thoroughly. This Proposal's point is just to check what users think about a Stub definition in general, !

And now, to end this load of text: Since I based this Proposal largely on a definition from, I bestow the same rights as the proposer holds upon him, meaning that he can edit or remove this Proposal like he pleases.

Proposer: (with  holding the same rights) Deadline: 26. November 2009, 17:00

A Definition of Stubs will be helpful

 * 1) - Having a four-didgit amount of them makes it kind of necessary. I think we will profit from this.

Comments
I don't get it. What exactly are we voting for? Panchito
 * A more simplified version of the Proposal is: "Do you want a clear definition for what a stub is, or do you want that everyone decides on his/her own about that (which would result in very different opinions)." I hoped I didn't make it too complicated. -

Removals
''None at the moment.

Put Waffle Kingdom and all the related places into "List of Implied Locations"
Some of you may know Waffle Kingdom. I propose this article and all the locations related to it to be merged with List of Implied Locations.

The reason is quite simple: The Waffle Kingdom is never actually visited in any game, and is therefore an implied location (duh). If that isn't enough reason, then there are plenty of other ones. It is f.e. impossible to add images to these articles and there's not much info available for them. Too few to fill a whole article. So, for the sake of fighting stubs and such, let us merge this articles.

Another thing: Since I can change this proposal within the first three days, I will use this to add another thing. Like SMB said, Princess Eclaire should also be merged with the List of Implied Characters if this proposal passes. Not sure about the Chestnut King, because this could also be a mistranslation of the Goomba King.

Proposer: Deadline: 21. November 2009, 15:00

Merge them

 * 1) - Per consistency and myself.
 * 2) Per Edofenrir, and we also would have to merge the Princess Eclair page and the Chestnut King into List of Implied Characters.
 * 3) I am Zero! Merge them, no picture and little info, belongs to implied locations. Zero signing out.
 * 4) - Per Edo. If this proposal somehow fails then I am adding an image tag!
 * 5) - PEr Edo.
 * 6) Per all.
 * 7) Per Edo.
 * 8) Per Edo.
 * 9) - Per Edo; I've always meant to make a proposal just like this for the exact same reason.
 * 10) Per all of the above.

Comments
Regarding the "Chestnut King", this is a mistranslation for Goomba King/Goomboss for sure, his Japanese name is always the same, while his English name changes from Goomba King to Chestnut King to Goomboss. There could still be a reference for that in the List of Implied Characters, but information about "Chestnut King" should go to the Goomboss article. --

Update Character-infobox Templates
I'm proposing we update the character info boxes a bit; in different areas.

They are currently set up so it has:


 * character's name
 * a current image with a small description
 * their full name
 * their first appearance
 * their species, all media
 * their affiliations, any amount
 * their latest appearance
 * who they are portrayed by, ever

Will be changed to:


 * character's name
 * a current image with a small description
 * their full name
 * their first appearance
 * their species, current depiction only unless first appearance is different
 * their affiliations, set amount
 * their latest appearance
 * who they are portrayed by, most recently

I'm proposing we change it so that unless their first appearance was in a media type other than a video game, it not be mentioned what they may have been in that media type. Sure it makes sense to mention what a character's species was in the film, but that's what the film section is for. To mention that difference. On the other hand if for some reason a character has showed up in the film first, it would make sense to mention that in their species category in the template box. Otherwise you're focusing on information that is widely far apart from their actual design. Toad and Daisy are two good examples of characters that should not have this information in their infoboxes. Neither of them are actually reptilian(dinosaur) in any manner of speaking, so why mention it here rather than where it is relevant?

Next, I'm proposing to change it so that affiliations can have no more than three things listed. Some articles seem to mention far too much such as Wario's. Naming one friend, one enemy, and one location is not hard. And it's not like it doesn't explain interactions in the section for this information. That doesn't mean it has to be a friend an enemy then a place, but it means the list can not exceed three things(friend, friend, place/enemy, enemy, friend/etc.)

Change portrayed by section to latest portrayal. There's a reason there are sections explaining who portrayed characters in what game on each page. It's so viewers can read who played who in what. However, stating in the infobox EVERY person that has played the character in EVERYTHING they've ever been in is unnecessary and messy. Stating who their latest voice actor is should be no problem. If somebody wanted to know who played Toad in the film, they could go to either the film or portrayals section and find out. But if somebody just wants to know who most recently voiced Toad, they should be able to look at his infobox, and then know instantly. Oh, that's the actress who currently(most recently) voices Toad. Also, this will go along with their latest appearance because that way they know who voiced them in what game most recently.

Each section change or addition will be broken up into numerous different proposals below.

Proposer: FD09 Deadline: 20 November 2009, 20:00

Change It
Species section will only give the characters actual species; unless first appearance is media outside of current appearance.


 * 1) FD09 Per above.
 * 2) If this will keep Bowser from being classified as human, I'll support. Besides, exceptions made in one single installment shouldn't be in the infobox. If fits better in the respective section.
 * 3) - I agree with Zero, but then I agree with Edo. Bowser a HUMAN!?!? O_o
 * 4) - The information would still be in the page but just closer to the bottom.
 * 5) Toadine - Per all. This wiki desperately needs some new organisation methods..
 * 6) - Per all. The infobox is for general facts-at-a-glance, but if a character was a different species in 1 out of 100 depictions, that's more of a minor detail that may confuse people without the context it needs up in that list.
 * 7) - Per all.
 * 8) Panchito - Per All.
 * 9) - Per all.
 * 10) - Per Edofenrir.

No Change
Species section will give list of species from all appearances; even if they are not current.


 * 1) I am Zero! Even though I like the idea of changing species into there current appearence because I hate of what I heard about the Super Mario Movie's generic version of each character I oppose, the reason why is, even though we should treat the SMW as a community don't forget we are still a free online encyclopedia, so I oppose because we need to show to the guests every bit of information about that article they are looking at, and plus the info-box is like a short summary of only that person or thing on the article, so why should the guest have to look in a enormouse page or a regular size one to find out in one appearence that character has made in, he was another species? Zero signing out.

Comments
(Since these are actually four proposals, I will make my comment here because it specifically applies to only this section). Gamefreak75: Bowser was a human, or rather a human evolved from a dinosaur in the live-action movie, just like Toad and Princess Daisy. Marioguy1: The point of this proposal is not to ban these informations from the article, it's about moving them. The meaning of a characterbox is to provide the viewer with basic information about a character, so the reader can get a picture of the chara quickly. Listing exceptions within the infobox would be distracting, so the info should rather be moved to the section where this exception applies. No information is lost that way, and more structure is gained. -

Change It
Affiliations section will only list three things. (Not so much a change, as it is simply setting order)


 * 1) FD09 Per above.
 * 2) Sounds good to me. Per FD09.
 * 3) Toadine - Per FD09.

No Change
Self explanatory.


 * 1) I am Zero! The reason why goes the same as the one about the character's species above, although we need to organize some character's affiliations somehow. Zero signing out.
 * 2) - If they are affiliated with more than three things then why limit them to three?
 * 3) - Per Zero and Marioguy.
 * 4) - I would actually support this if it was slightly different. Instead of limiting them to a specific number, they should be limited down to the most basic affiliations (which in some rare cases can be more than three).
 * 5) - Per Edofenrir. Using common sense and discretion is the best way to deal with subjective cases like these.
 * 6) - Per Edo.
 * 7) - Per Edo.

Change It
Portrayed By section will be change to Latest Portrayal and will list only the most recent portrayal of the character.


 * 1) FD09 Per above.
 * 2) As long as the other earlier portrayals are mentioned in the article itself, that sounds organized.
 * 3) YES! Mario's had like, what, 10 voice actors? That's a huge clutter for that tiny infobox. Keep portrayals in their designated section.
 * 4) - Per SMB. Only if the other portrayals are listed somewhere else.
 * 5) - As I said above; the information would be in the article just not in the infobox.
 * 6) Toadine - Per SMB. I like the change as long as we still have earlier portrayals mentioned.
 * 7) - Per SMB.
 * 8) Panchito - Per All.

No Change
Portrayed By section will not change and will list every single actor that has portrayed the character, ever.


 * 1) I am Zero! The maximum portrayals I seen is about ten, even though it will make the info-box a little long, I see no promblem of just putting the portrayer's name, what game or appearence did they made that portrayal (in parenthases of course), and then put   at the end of each portrayer's appearence to make a nice clean list of all the portrayists if you can do that. Zero signing out.
 * 2) - Per Zero: ten names isn't so bad a list, and simply getting them over with in the infobox is the simplest and most concise way to include the actors in the article (as opposed to writing a clunky list in the introduction, making an entire "portrayals" section later on, burying them in the History or stuffing them into the unwanted Trivia catch-all). Also, naming only one actor seems like we're side-lining the rest of them, many of whom were the voices of our iconic characters for years... it just feels wrong.

Comments
One vote per user - srry
 * lol I know that, clearly. While I have this set up as One Proposal it is basically divided into different proposals. They just all happen to concern the same thing. Is it really that confusing? FD09
 * I once made the same thing but it got deleted
 * Nah, I don't find it confusing at all. It is actually kind of clever to divide this proposal into more than one, or else people might have conflicting opinions about the different points which would prevent them from voting. Don't know what the other admins will say though. -

Ah, I see, that doesn't sound good. Should I actually make a diff. proposal for each one though?FD09
 * Hm, yeah it makes sense...I'll vote tomorrow though, I'm pretty beat. I PWND my classmates in Brawl today. XD Different proposals won't be good because then this place would be cluttered and it's organized all right already. :/
 * OK - I guess the all-in-one version works. Anyhow, how will this be archived?

I am Zero! Even though I oppose most of the sections, I just like to say this proposal is welled polished, confusing at first but it's polished really good. Zero signing out.
 * OK, back to my question - will it be called a pass if even one of the sections passes or will it be a fail if one fails? Or will you put pass/fail for every single one of the sub-proposals? Maybe a big long thing like CHANGE SPECIES | DO NOT CHANGE HAIR COLOR...
 * It'd probably be archived as pass/fail for each section, as if they were separate proposals. Leaving them together like the way it is now should be fine, though, seeing as they really are dealing with the same thing. Maybe the paragraphs pertaining to the specific changes could be moved down to the appropriate section (i.e. the reasoning behind changing the species listing would go under the "Species" header, before the voting sections). That would help with reading the proposal (the huge amount of text at the beginning is daunting), voting (one could easily forget the details by the time they make their way down to the later voting sections), and archiving (then what changes have passed or failed will be right besides the pass/fail announcement for that section). Other than that, I think it's a pretty good set-up. -

Format looks great, IMO. FD09: May I have an example of what it would look like on one specific article? It's much easier to visualize when I can see exactly how it'll be.

Add Shortcuts for Mario Kart Wii tracks
My first proposal. Add shortcuts to Mario Kart Wii tracks. This will help struggling racers get the fast staff ghosts, or beat an annoying sibling's best time. Add more spots if necessary.

Proposer: Deadline: 20 November 2009, 20:00

Add Shortcuts

 * 1)   as per above, and for the people who can't find them on their own.
 * 2) If nothing else, it's more encyclopedic.

Don't add Shortcuts

 * 1) Per Coincollector and FunkyK38's comments below.
 * Ok, since the proposer didn't explain his/her intentions further, I have to conclude what it means. And judging from how the proposal is written, I think he/she wants to add mere tricks to get to the goal quickly, instead of built-in shortcuts. And as stated below, I oppose this.
 * 1) I am Zero! Like Funky said, were not a strategy wiki, and I think there are alrady shortcuts on some courses on MKWii, but only if there notable enough. Even though there is such thing as a spoiler section we don't want to spoil the player too much they end up as an ass on online play and are now roten and had to be thrown away (metaphor right there). Zero signing out.
 * 2) Much easier to look up on YouTube. ;D And per Funky's and Coin's comments below.
 * 3) The 'W' in 'SMW' stands for "Wiki," not "Walkthrough."
 * 4) Per Dodoman.
 * 5) Per all. Shortcuts should be found elsewhere, not here.

Comments
What do you mean with shortcuts specificly? Are you talking about shortcuts implemented in the tracks (like secret tunnels) or just driving tricks that help you getting to the finish faster? I'd support the first and oppose the latter one. -
 * Per Edo. Also, your reasoning makes it sound like you're trying to turn those articles into game guides. :/ --
 * Aren't shortcuts already in some of the racecourse articles?

The tone of this proposal makes me to think like a joke (or a walkthrough issue, like explaining bug shortcuts or glitches, eg: the worst shortcut glitch of Grumble Volcano) and that's not a valid question to propose.
 * There's already mentioned shortcuts in articles. I think he's trying to say that he wants EVERY article with a shortcut-explanation guide.
 * We don't really have to put those on there, this isn't a strategy Wiki, we're the Mario wiki.
 * This proposal is not described well enough for me to vote. Describe it better or I will not vote.
 * Same here

Staff pages
I've noticed how we have a bunch of separate articles on the staff of video games. I believe this is fine, but why do we need stand alone articles on the staff pages? Why not just move them to subpages of the games' articles, kinda like the Beta elements sub-pages? The only page they are linked from is the game anyways (the template doesn't count).

Proposer: Deadline: 24 November 2009, 20:00

Support

 * 1) – Per proposal suggestion
 * There's no need for a stand-alone page. Making it a sub-page of the game article makes more sense. Per Knife.
 * 1) - This should actually go without saying, but of course we can't skip the proper channels...
 * 2) Per Knife.
 * 3) Per Knife's proposal.
 * 4) - Per all.
 * 5) - Sounds good :D
 * 6) - Per Knife.

Comments
Vini64: You seem to misunderstand the proposal. It's not about putting the staff information into the game articles themselves. Rather, they would go on a sub-page of the game articles (e.g. ), just like it's already done with the beta elements: Super Mario World/Beta elements.
 * Ohh, now I understood. Sorry about the misunderstanding.
 * No problem!

Vini64: It's not about merging those pages with the article, it's about making the standalone pages to subpages for organisatory meanings. That doesn't consume any room on the original article at all. I was too slow, so, what Time Q just said. -