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)

Amend Size Requirements for the Featured Article Process of the Super Mario Wiki
Ok, this proposal will eliminate the size requirement of a Featured Article system. "'If smaller pages deserve to be recognized, lowering (or even eliminating) the minimum length of the FAs seems like a better way to go about things than installing a second system; the sizes of individual sections are already taken into consideration when people vote on FAs, so having the overall size of the page left to the voters' discretion doesn't seem unreasonable.'" &mdash; Walkazo So that should basically sum it up.

Deadline: Friday, 25 September 2009, 20:00 Proposer: &

Amend Size Requirements

 * 1) Per my comment below.
 * 2) - Don't judge a book by it's cover. Or in this case, don't judge an article by its size. That is what we've been doing, it's time to stop.
 * 3) - Relatively short articles can be well-written and representative as well, so why not removing the size-requirements or at least decreasing them? I'll support this.
 * 4) - Per me (see below).
 * 5) Shorter articles usually require less work to be good, but that doesn't stop them from representing the best the wiki has to offer.
 * 6) - Per all, how can we write 4000 characters about things like.... uh.... dunno, but here are some examples.
 * 7) - Per all.
 * 8) - Per all. There's plenty of great articles on the wiki -- or articles with the potential to be great -- that will never legitimately reach our current size limit.

Comments
The last proposal I made was starting to fail, so I rewrote it. Common sense can be used for the size, if it is a well-written article and meets all of the requirements except for the current size-limit, it would still deserve to be featured, except in the case of stubs. As I said, common sense can be used. 16:22, 18 September 2009 (EDT)

For the record, this was originally my idea (made in response to SPMB's original proposal): "'If smaller pages deserve to be recognized, lowering (or even eliminating) the minimum length of the FAs seems like a better way to go about things than installing a second system; the sizes of individual sections are already taken into consideration when people vote on FAs, so having the overall size of the page left to the voters' discretion doesn't seem unreasonable.'" Credit is as credit does... Or however that expression goes. -
 * Yes, you are correct. Sorry for forgetting to credit you, I'm pretty busy with other things, and often have to get up in the middle of editing and the such, which gets me off track. I have rewritten the proposal accordingly to correct my wrong.
 * Ok, thanks. -

Maybe you should also remove the rule that says the article must have 50 entries.

Get Rid of the New Userspace Requirements
A mans userspace is his castle, so why is there so many rules on what should be on it and what shouldn’t. What’s on someone’s userspace is supposed to be like what describes them and if you are not allowed to go out of the lines of the requirements, you simply can’t do that. I think we should get rid of those rules so users can express themselves better. I really just don’t think those new rules are fair at all. Also, it will take a lot of users time a lot of time and effort to change their userspace to fit the requirements. Some of the user space rules I agree with, such as “no illegal game links”, but some like “No discussion not related to the Super Mario Wiki” and “No excessive personal information” are completely unfair. It is like living in a house, but you are only allowed to have stuff from “Home Depot” in it. "Home Depot" doesn’t sell all of life’s necessities, just like Super Mario Wiki doesn’t have all of the information you need. If this Proposal passes, users will be free to use their userspace any way the want to except there will still be no more illeagal game links.

Proposer: Deadline: September 26, 2009, 20:00

Support

 * 1) of course I would Support my own Proposal

Oppose

 * 1) Well... Rules are rules.
 * 2) - The server of this site has limitations too. A few restrictions are unavoidable if you look at the size of the community. If "user expression" becomes too excessive, the whole server will eventually collaps, and then you have absolutely no userspace left at all! Maybe you have noticed the server getting very slow from time to time? A little moderation shouldn't hurt anyone.
 * 3) - Per Edofenrir. There are plenty of sites dedicated to self-expression on the Internet, but the Super Mario Wiki is not one of them. Here, userspace is a privilege, not a right, and the only information we "need" to provide is located in the mainspace pages of the encyclopedia.
 * 4) - We are a Mario wiki not a user wiki, i recommend you to check Userpedia. I also say we should delete this proposal, admins?
 * 5) - Your userspace belongs to the wiki first and you second, and it's better for the wiki if these rules are followed. Also, these are not new rules, we've just started cracking down on those who break them.
 * 6) - Per all.
 * 7) - Why did we make these rules in the first place? That reason still stands. Next time you decide to make a proposal like this, I suggest you specify which rule you want to delete don't say all of them because all of these rules are for the wiki user's own good. A wiki should be a relatively safe place, these rules keep it that way. Don't delete the rules!
 * 8) - Per all.
 * 9) Egg Yoshi, if you are retiring because you can't observe our policies, then good ridance. I was, at first, against giving up my subpages, but I complied with the rules and went even further, as to get my user page itself deleted. I now only have proposal-related subpages for archiviing-sake. I see that many users also have stories in their userspace. I feel this should be moved over to Userpedia, in fact, that was the original reason why it was invented was so that we would have more space here, and that more users wouldn't get distracted with the stories. User-related content isn't the main purpose of this wiki, the Mario series and other related games is our focus. We have these rules so that our server will have more room for our main purpose. Per all, particularly Edofenrir and Twentytwofiftyseven.

Comments
I don't know wether to suport or oppose, because it's true that rules are rules but I'm afraid the "only talk about MarioWiki-related stuff" rule is somewhat...strict, but I completely understand the "no excessive personal info" because there are some not-nice people out there, but I'm not gonna take sides for this one.

I don't see the problem with this. The rules were created to disburden the server and it is necessary if you look at how slow it gets from time to time. There's still the forum, the chat and userpedia left for personal discussions and contents. But sacrificing the whole wiki for the sake of self-portrayal? I doubt that's in your interest as well. -

THATS IT! I AM RETIREING FROM THE WIKI! I'VE BEEN THINKING ABOUT DOING IT, BUT NOW ITS OFFICIAL! wWHO WOULD BE STUPID ENEUGH TO MAKE A WIKI WHERE YOU CAN ONLY TALK ABOUT THINGS ON THE WIKI! I will still rwrite my 'shroom articles and survivor, though...
 * To be honest... I would be that stupid. If protecting the own project from a possible server crash is stupid, then yes, I admit it: I would be stupid. And before making rush conclusions, note the comment of Tucayo below this, and understand what exactly will be deleted in the next week. Thank you. -

*sigh* WE ARE NOT GETTING RID OF USER PAGES, BUT OF USER SUB PAGES

Merge & Split: Enemies Inside Pages
Clever title there. Anyway, I was thinking- Instead of having all the enemy names in Bowser's Inside Story on the same page, and then having to click a link to go to the page which turns out being a stub, and then having to click the back button on your browser, wouldn't it be much easier to split the enemies to split the enemies and merge all the enemy articles onto one page? I'll do this myself if there's enough good feedback. This saves having to tire yourself by clicking on different links all the time!

Deadline Sunday 27 15:00 Proposer

Oppose

 * 1) - I don't quite understand this proposal, but I assume you mean you want merge all MLBiS enemy articles into one article. I believe enemies are entitled to their own articles.

Comments
Split to split to merge? Did you say it twice or something?

You want to split the enemy articles, split them again and then merge them all together? If you want to merge them, why splitting them in the first place? There's clarification needed here. -

New Policy
Sometimes, there's an article that is created with one or two lines of text. It starts building up after after a while. When we see these articles, we simply slap a stub template on it in hopes that someone will expand it. This kind of thinking has created more than a 1000 stubs. That means more than 1/10th of all the articles on the wiki are stubbed. We need to fix this proportion for the sake of the wiki. There is no quick fix, but we can reduce this if we add this new policy to the Rules.

Any article two complete sentences or less is subject to deletion under the following conditions:


 * The article is linked to from 9 or less mainspace articles. Links from a template page are acceptable.
 * The article has no images.
 * The article belongs to 2 mainspace categories or less.
 * The article has 4 or less different contributers, not including edits by sockpuppets or trolls.
 * The article is at least a week old.
 * The article is not a disambiguation page.

So basically, any two sentence article that fits under ALL these conditions is deleted. If an article has sentence fragments or redundant sentences, they will not be counted. An article like "Goomba Pirates are Goomba pirates. There are lots of Goomba Pirates. They appear in Mario Party 8. They are found on (whatever board that was). They throw players into a cannon and shoot them to the start if they land on a ! Space." will not work.

If this proposal passes, articles on the wiki will be deleted if they meet these conditions and will become an enforced rule and a new policy will be added. The editors in no way will be punished for creating an article under these conditions, unless it is vandalism. If you have any suggestions or questions about proposal, please leave them.

Proposer: Deadline: September 22, 2009, 17:00

Support

 * 1) My support is a given.
 * 2) - Per Knife. We have many stubs, quality before quantity.
 * 3) - This rule is actually pretty good! It should be easy to attain it. Per Knife.
 * 4) Great proposal there are much too many stubs and it needs to stop.
 * 5) Per Knife and Tucayo. There are too many stubs that are sometimes poorly written and need to be expanded/marked for deletion by patrolers/sysops. There are about 1500+ Stubs and that needs to be fixed!
 * 6) - I think every article that happens to meet ALL the conditions mentioned above could be considered very extreme, even for a stub. Removing those shouln't be harmful.
 * 7) Super Paper Mario Bros. Per all. Good idea, we need less pointless articles that don't help.
 * 8) - He did what I suggested; now the limits are good.

Oppose

 * 1) - There was a (largely ignored) rule created over a year ago (I think) against creating new stubs, but as for existing short pages, it really has to be dealt with on a case-by-case basis. Putting more emphasis on merging short pages and deleting unnecessary stubs would be beneficial to the Wiki, but that's more PipeProject fare than Proposal.
 * 2) - A little picky, aren't we? Just because an article doesn't have as much information as your picky standards dictate it should, that doesn't mean you should remove perfectly valid articles.
 * 3) - Per all.
 * 4) - Per all.
 * 5) - I don't really understand how cutting down on stubs helps the wiki in the first place. Even if that was desirable, very, very few articles would fit under these rules.

Comments
What rule says that this proposal can be given a long deadline?
 * None, so I corrected it.

@Marioguy1: Actually he says that there have to be at least 19 links TO the page, not FROM the page. -

@Ralphfan: I loosened up the rules a little, but I think 2 categories instead of 1 is a better fit since we have so many categories. It still has to pass all those conditions before being deleted anyway, so I don't think it is too strict. @Walkazo: That is exactly what I have been doing. If we deal with these case-by-case, we will get nowhere. Stubs are created much faster than they are fixed/deleted. It has gone far beyond Pipeproject repair. This is more of a deterrent for future stubs and hopefully will encourage users to not to make short articles for the sake of filling a red link (the manual of style has that bolded, but that isn't an enforcable rule).

I thought we could manipulate the deadline. Sorry for assuming that.
 * Knife, may I add a suggestion? If the article has an image in it, it passes.


 * Good idea.

All rules are enforceable, so if you see someone creating a one-liner (to fill a red link, or for whatever other motivation) you can stop them. The old no-new-stubs rule also lets you delete new stubs; I think the problem has been that we don't always catch them right when they're made and later assume they were there all along (granted, that's what checking the History is for). Personally, I always worry about removing what little information the stub does provide: there should be more emphasis that when you delete a stub, you have to make sure the info goes somewhere else (i.e. delete a Level page and the info gets pasted on the World article instead). -

The no-new stubs rule. If you could point out where it was passed, I would have a better understanding of it. Even if it was passed, why isn't it on any policy page? While this proposal is also supposed to cut down on stubs, it has two major differences. The first being that new stubs are still allowed if any of the conditions don't fit. The second being that existing stubs can still be deleted. You are also worried about valuable information being lost. Don't fret. If a user creates an article with only two sentences, there are two conclusions:


 * The user doesn't know enough about the article and probably shouldn't be creating an article on it.
 * The subject in the article does not have enough information that can be written about it and should not have its own article.

I can't think of any two sentence article with information so valuable that it needs to be merged/stay as an article. I wish we had an extended deadline so that we can discuss this further, but we only have 3 days left.


 * I'll search the archives for the no-new-stub proposal tomorrow (I can't tonight because of time and computer constraints) - regrettably, most policies that pass via Proposals can only be found there (people love making new ideas, but if implementing them is hard, they don't always follow through). For some examples of informative 2-liner stubs (albeit ones that have images and templates) see Chocolate Islands 1 and 3, and to a lesser extent, Chocolate Secret. Some of the other Chocolate Island levels have a decent amount of writing to their name, but I think the whole lot could be merged into Chocolate Island quite handily. (I'll admit, that's more relevant to the old "should every level get a page" debate, but it's the only example I could come up with off the top of my head.) -


 * Those examples don't work for me. The first one has no important text and wouldn't be deleted under this new rule. The second one has 4 sentences (the sentences in the level template), therefore is not relevant at all. I believe the old proposals should be better organized instead of just archiving them by date, but that's a different issue. Let me know when you find the old proposal.

(Chat log) 20:36	Tucayo	when i was a n00b 20:36	Tucayo	and searched for a random article 20:36	Tucayo	i saw it didnt exist 20:36	Tucayo	and created it myself

I'm really torn on this proposal. As incredibly annoying as it is to see well over 1,000 stubs on the wiki that either haven't been edited in so long because it's such an obscure subject, because so few actually can find information on it, or even because of pure laziness, I still feel that all articles should be given a chance. If an article is just one line, then yeah, it's likely to be deleted as soon as a Sysop finds it, because there's always enough information for at least two well-detailed sentences, but just completely ridding all small stubs of having the chance to become a really impressive page seems rather extreme.


 * I understand. You're thinking about each stub having potential to be a great article. But as time passes, those stubs are less likely to be expanded. In general, older subjects often have less information. The potential is still there of course. Why does it hurt the wiki? We currently have 9500+ articles (as displayed on the Main Page). 1500+ of those articles are stubs (not two sentences). How is that anything but bad? Why are stubbed articles bad for the wiki? Because they mean the articles are incomplete and are under some kind of construction (I realize no article is really complete since this is a wiki). Why is page count important anyway? Because we seem to boast that statistic to all our visitors who go through the Main Page. I simply want to get rid of stubs to make that statistic more accurate.


 * Now some of you may be confused about how this proposal will help get rid of stubs. It is true that this proposal will affect only a few stubs. The main purpose is to cut down newer stubs from forming and encouraging users to provide a more complete article before creating it. When is the most information added? Usually when the article is created. We could just start enforcing the no-new stubs rule. However, that rule is also flawed. Users can simply not mark the subject as a stub or a good 4 sentence stub could be deleted. Even if a stub is deleted, it can always be recreated as a better article. Not all stubs are bad. It's the shorter ones with little hope of being expanded that need to be deleted.

Time Limit Before New Game Spoilers Added to Other Articles
First, I hope I've added this proposal correctly; my apologies if I've messed up somewhere. To the point, I'm proposing there be some sort of time limit, a statute of limitations if you will, before spoilers for an as-yet unreleased game begin to filter their way into other articles. For example, Mario & Luigi: Bowser's Inside Story is not out in North America yet, but as I was reading over several Partners in Time entries, I came upon numerous spoilers for the unreleased game. I understand if spoilers for BIS would be in the M&L:BIS entry, as that would be a "read at your own risk" situation, but should someone who is just trying to get caught up be forced to find out things they don't want to until they get a chance to play the game?

Proposer: Deadline: September 20, 2009, 15:00

Support

 * 1) - I am aware, that this is of little point, but anyways... My opinion is, that spoilers are something one has to expect on a wiki. But major spoilers should only be found on the respective games article or in a paragraph dealing with that game on another article. That means, a spoiler about M6L:BiS on the M6L:PiT is fine, as long as the paragraph it is in is concerning BiS in general. That would not just increase user-friendlyness, it would also make the wiki more orderly and more structured.
 * 2) - As per Edofenrir.  Looking back, it seems the bigger issue is more with the nature of the Trivia sections as a conduit for such spoilers to appear in other unrelated articles.  It's one thing to go into Bowser's entry and know which section to avoid, but another to look up a form of his from one game and see "guess what?"
 * 3) - Per all

Oppose

 * We're not a random fan site, but an encyclopedia, and as such are our task is to cover everything Mario-related in the most objective and neutral way possible. Thus, hiding information from our readers, no matter for what reason, is bad. If someone doesn't want to know something about Mario, they shouldn't read this wiki, it's as simple as that.
 * 1) – Per Time Q
 * 2) – Per Time Q. He said everything I wanted to.
 * 3) - This is censoring Bob Hoskins all over again, no, no and no again! Besides, if SMG had just come out two days ago and I somehow got it at that early date and got as far as I am in it now, how would I have figured out how to beat Bowser?
 * 4) - Per Time Q.
 * 5) Per Time Q
 * 6) - Per Time Q. We should just get rid of the Spoiler templates and say the entire site's a "read at your own risk" database (like everything else on the Internet).
 * 7) Per Time Q and Walkazo.
 * 8) - There's a warning.  If you ignore it, that's your fault.
 * 9) Per Walkazo.
 * 10) Per all.
 * 11) - Per all.

Comments
I agree with TimeQ, but i HATE spoilers.

Is there a way to add a spoiler tag or something, then? Again, not saying no spoilers at all, but spreading them throughout to articles only slightly related seems a bit like overdoing it. If I just want to learn more about Partners in Time, is it really necessary that the first piece of trivia I see in one entry spoils a game that's not even out yet before I even read the more relevant info? And Marioguy1, would that info not be in the SMG article? That would be a different situation from what I'm speaking of.
 * No actually, how to beat a boss is a spoiler :). BTW, you cannot propose to hide the spoilers from view in some kind of template that says "Click for Spoilers" as it hasn't been a month since Electrogoomba tried the same thing.
 * It is, but a Super Mario Galaxy spoiler in a Super Mario Galaxy article makes sense. What I'm talking about is akin to putting a Super Mario Galaxy endgame spoiler in an article about Super Mario 64 or Sunshine.

As far as I understand a major concern of this proposal is that spoilers are available outside of the respective game article, and I can perfectly understand that. Spoilers belong to the game's article or paragraphs in other articles that deal with that game. What situation would rectify it to post a spoiler outside of an article or paragraph of the respective game? Are there examples? -
 * Ah, you get what I mean. As noted, why am I being spoiled for Bowser's Inside Story when I'm just trying to read about Partners in Time?
 * How about some specific examples (i.e. individual pages)? I can think of many reasons for PiT articles to have M&L3 spoilers: one of the Super Mario Wiki's aims is to identify and present common themes running through series, and plots are an integral part to any RPG coverage, spoilers and all. Character articles are guaranteed to have spoilers, as will prominent items, enemies and areas is many cases. Granted, some editors might go overboard and spill the beans where a page could be perfectly complete without the spoilers, but other times omitting the spoiler would be denying the unconcerned (spoiler-wise) readers all the information we could give them, which goes against everything the Wiki stands for. -
 * Yes, in many cases, spoilers have to be pointed out for the sake of being informative. I won't argue that. But is there a reason why spoilers have to be given outside of a respective paragraph? I mean, there may be f.e. paragraphs like "Role in BiS" on a character article and putting spoilers in there would be fine. What I wouldn't understand is, when someone would put spoilers outside of an existing BiS paragraph. I mean, that would not just be unnecessary, but make the article itself appear less structured. -
 * All bets are off when it comes to Introductions, Trivia sections (which are discouraged, as they do make the page look disorganized), and other little bits like "Personality", "Powers and Abilities" or "Relationships with Character X" (another defunct section, by the way). The writers could be more discrete about the ending details, but I doubt more anti-spoiler rules will change that (we tell people to use proper grammar, but a lot of crud still gets posted day in and day out). -
 * Examples. The main one which led me to this was the first trivia item here: here. Various Shroob entries also reference a battle in the latest game, though those seem relatively minor by comparison.  I suppose this may act as much as a discouragement to the Trivia sections lamented above. -
 * That Bowsletta/Shrowser/Dark Bowser point is perfectly reasonable, as it is undeniably true that Bowser's essence is combined with that of the main villain of all three Mario & Luigi titles; not mentioning the trend would be a grievous omission. The fact that the Shroobs appear later also has to be included, as it is part of the history - the backbone of almost every page on the Wiki - of these characters; just as we mention every game Mario appears in, so too must the Shroob cameos be noted. -
 * But must it be put out there before the game is even out here? Can it not at least wait until the game ships? I understand why you'd want the stuff to be there, but is it really that crucial that it be up here before the game even comes out? And I know it's out in Japan, but are that many users going to be importing it first? -

We could just do like the ArchieSonicWiki and just add a blanket statement to the Mainpage saying 'Warning: These Wiki Contains Spoilers, Read At Your Own Peril', or something to that effect. --