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)

User Highlights
I know Mario Wiki isn't Userpedia, but I feel guilty when I find out somebody's prrromotion to a higher user rank just happened and I didn't congratulate them is an annoyance. The same with birthdays. Yes, I am a Userpedia user, but I'm thinking more about people limited to only Mario Wiki. It could just be a small box showing something, (sorry about putting myself in this, but oh well: "Hyper Guy's Birthday is coming up on___" or "User___ has reached Sysop rank) just a small box with a bit of information about the users, who could be recognized for their efforts on Mario Wiki, might make our community look much, much better by giving users credit, no matter how small the alert is. (NOTE: I'm not talking about edits! Just marking important moments for our brilliant users) THANKS FOR READING THIS!

Proposer: Deadline: August 28, 2009, 20:00

Oppose

 * 1) If you mean a box on the Main Page, it isn't necessary. For the promotion issue you stated, the promotion is usually listed in the Pipe Plaza, usually as, "*Insert User Name Here* has been promoted to *insert rank here*! Congratulations!" And the problem with the birthdays can be solved with the 'Shroom (we have the calendar, one of the sections is for birthdays). If anybody is not content with what we have, then that is too bad for them.
 * 2) The wiki isn't a forum, so we will not have a database for something like birthdays - creating an automatic system or handling it manual sounds like too much work for me. If you want to congratulate certain users, write down those users' birthdays on your own list. SysOp promotions are noted on the Pipe Plaza.
 * 3) – Per Cobold
 * Per all.
 * 1) - Per all.
 * 2) Per all.
 * 3) - It's simple, not a forum, there's already one that exists for the site. Per Cobold.
 * 4) Per all the Main page is for the wiki not the users

Removals
'None at the moment.

Merge Keys Articles
Yeah, I was just looking at the articles linked to this template, and most of them are stubs. That is why I am suggesting that the community allows me to go ahead and merge them, as well as turn the original articles into redirects and changing the links so that they lead to the merged article. An example can be found here, and the discussion page will be a replica at first, but it will be so that users can change it as opposed to suggesting changes to me (such as moving images, sections, fixing links, etc.). So, to reiterate, if you want to suggest a change to my example, do the change on the talk page. If you have other comments, put them below on this page. NO COMMENTS GO ON THE TALK PAGE! ''Note: A change in the proposed article has been made. See my large comment below.'' Proposer: Deadline: Saturday, 22 August 2009, 20:00 Extended: Saturday, 29 August 2009, 20:00

Support

 * 1) I think this will improve the articles. Per Walkazo.
 * 2) - I like your article. It's long and combines a bunch of stubs. To Time Q below, the need would be that there are currently too many stubs. but I saw a problem. There is only supposed to be one image requested tag at the top if you have multiple sections because at the top it says "It has been requested that image(s) be added to this article/section" See what I mean (it says images).
 * 3) Per SMB.
 * 4) Yeah, what's with all the keys anyway? The articles are terrible!
 * 5) - Per my comments below. Supplementing the nameless key list in Key with "List of Keys in the Paper Mario series" and  "List of Keys in Super Mario 64 DS" pages in place of numerous stubs seems a more organized way of doing things. Use (and  in the sections for the few keys who merit full articles) to make the lists presentable.

Oppose

 * I see no need for doing this change. Those keys are unrelated to each other, they all deserve their own articles (or at least some of them, which means we can't merge them all together). If they're stubs, we should expand them rather than cramming them all together in a rather unattractive list.
 * Per Time Q. Additionally, as you have it set up, all the categories and navboxes are applied to the article as a whole, which is rather imprecise. To someone who's unfamiliar with what's going on, it may seem that (e.g.) Category:Animate Objects applies to all of the items on that list. In fact, it applies to just two. And having some items under the subheader "key" when the article itself is also called "key" is redundant.
 * Per All!
 * 1) - Per all.
 * 2) - Per all
 * 3) Per all.
 * 4) per all.
 * 5) - Some keys may need to be merged, but not all of them, like you suggest. Per Time Q.
 * 6) Yes they could be in an "Other Keys" article, but there are some important keys.
 * 7) Per all.
 * 8) - Per all.

Comments
Marioguy1, I fixed the problem. Does it look good now?
 * Yup, I was there when you fixed it. I'll strike that point in my article.

I think the Key article itself should stay (and the introduction should be expanded a bit to explain more about the essense of Mario keys), with the rest of the keys going into a "List of Keys" page. Yakkey should keep his seperate page, since he's a character, not just an item. Skeleton Key also has enough appearances and information (plus, its animate) to merit its own article as well. The list entries for Key, Skeleton Key and Yakkey would all use to link to the separate articles. -

I think Marioguy1's vote is invalid. The only reason he states is "I like your article", which is not enough. Why would it be a change for the better? Please expand your vote, otherwise I vote for its removal.

Ok, hopefully I fixed most of the problems. The minor Paper Mario keys would all be merged, as well as a few of the other Super Mario 64 DS keys (Mario Key, Luigi Key, Wario Key). The bigger Key article, as well as the Skeleton Key article and the Yakkey article would be left alone as seperate articles. This would allow to stay, and the Keys category to remain as well. Any more suggestions?


 * That still suggests that (eg) "Wario Key" falls under "Paper Mario: The Thousand-Year Door Special Items," which is wrong. And the fact that there's really no simple way to get to Key, Skeleton Key, or Yakkey from that article is also inconvenient.
 * What? We have the to link to Key, Skeleton Key, and Yakkey. So, should we split the list into two lists (one for the Super Mario 64 DS keys and one for the Paper Mario keys)? We could still have the Paper Mario series keys on one article, even though they would share categories, I think it would be easy to tell due to the beginning of each paragraph having the game it appears in.
 * Actually, there's been talk that templates like should be scrapped, seeing as they're just categories in template form, and are often based on "common sense" as opposed to canon (i.e.  vs.  and ). But that's beside the point: as I said before, those other independent articles should be linked to via  in the list, though with the two lists idea, that'd only be needed for Yakkey, since Skeleton Key  has a series unto itself (barring the conspicuously pageless Bowser Keys). Considering how the three SM64DS Keys can almost be combined as-is, I think the two list idea is good. I'm always a fan of combining stubs and saving space; all that can be done to expand those key articles is writing their exact locations (Walkthrough fare, IMO) and maybe some more context - but after a point, it starts to look off-topic and/or reachy. Also, the "if it's named it gets an article" mantra seems to be an underlying part of this discussion; to be frank, I've always felt that ideal was misguided. The keys in Luigi's Mansion essentially play the same role as the Fortress Keys and Ruins Keys, except the named PM keys get stubs while the plain LM key merely gets a section of the Key article. If the "Key"s from LM, SMB2, SMW, SMW2:YI, SM64 and SSBB are shoved together, why not the "___ Key"s from the Paper Mario series? It's a double-standard born of the desire to not have dozens of "Key (game X)" pages, which is understandable, but also fixable if we weren't so bent on having dozens of "___ Key" pages instead. The list(s) just needs some fixing-up; with proper retooling, it won't look so bad. -

Allowing YouTube Videos Outside Userpages
Before you all think, "It's been like that for a good while, why should it be changed?!", think about how better articles could look. Sometimes when I make edits, like I've been editing the Pyoro pages recently, I don't want to keep on writing things I know don't make much sense, but I can't show a viewer of the page an example of how the game would be played, and so that users can check if I'm right or not. It could also encourage people who don't want to read long articles. Instead of sitting on a chair for hours on end, they can scroll down the page until they find a YouTube video explaining it for them. I'm not saying we should stop writing and just spam YouTube videos on the pages, but this idea came to me when a friend asked me the other day, while I was showing him an article so he could see what you can do when you join, he asked "Y'know, I'm not actually reading all this c**p, can you just add a YouTube video on here or something?". After that, I started thinking about other people's opinions on this, and I personally think adding YouTube Videos to pages outside user pages would be like adding pictures to a book!

Proposer: Deadline: August 30, 2009, 15:00

Support

 * 1) - Per above.
 * 2) - Why Not, per Hyper Guy!
 * 3) Per all.
 * 4) I am Zero! It depends on what video, it's quality, is proffesionally done, and how small is the article, because, if the article is big then it will take a longer time to load. Zero signing out.
 * 5) Yoshi! I think they should extend it to Shroom pages.
 * 6) Per HG

Oppose

 * 1) Some pages, like Mario's, and really big, and, for some computers, are long to load. With Youtube videos, these pages will be extremely long to load.
 * 2) – Per Itachi 96. We can always external link to YouTube videos.
 * 3) see comment section
 * 4) Per all
 * 5) - Per Steve comments
 * 6) - Per all.
 * 7) - Per all.
 * 8) - Per Itachi 96 and Steve's comment below.
 * 9) - Itachi 96, your reason is invalid to me. Per my reasons below.
 * 10) Per Itachi... (about the comment about "per all"...) Yes It´s true some old computers and the memory fulled this would be a nightmare.

Comments
An external link would work fine in your example. Right now we host all our content when it comes to articles--the text and images. Embedding videos and making them part of the actual article means we are outsourcing content which relies on YouTube and their servers, as well as the user who uploaded the video. Having embedded Flash in the articles looks sloppy. Most everything can be described in words and if videos are an option we could rely on them too much; "This video shows how the gameplay works." Blah Blah
 * I agree. YouTube videos would also take away content from the article, as people might say they don't need to describe what is shown in the video. -

It's a wiki, it's supposed to have content in usually a text form, a reference to an external link TO a YouTube video is better. The video would extend loading time, like on Peach's page mainly, and content and formatting may be harder to replicate. Also, just a little off-topic note, I hate it when someone says "Per all."

Miscellaneous
None at the moment.