MarioWiki:Proposals

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 Rules
 * 1) If users have an idea about improving the wiki or managing its community, but feel that they need community approval before acting upon that idea, they may make a proposal about it. They must have a strong argument supporting their idea and be willing to discuss it in detail with the other users, who will then vote about whether or not they think the idea should be used. Proposals should include links to all relevant pages and Writing Guideline proposals must include a link to the draft page.
 * 2) Anyone can comment on proposals whether logged-in or not, but only registered users can create or vote on proposals.
 * 3) Proposals end at the end of the day (23:59) one week after voting starts, except for Writing Guidelines and Talk Page Proposals, which run for two weeks. (All times GMT.)
 * 4) *For example, if a proposal is added at any time on Monday, August 1, 2011, the voting starts immediately and the deadline is one week later on Monday, August 8, at 23:59 GMT.
 * 5) Every vote should have a reason accompanying it. Agreeing with or seconding a previously mentioned reason given by another user is accepted.
 * 6) 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. Voters 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.
 * 7) If a user makes a vote and is subsequently blocked for any amount of time, their vote is removed. However, if the block ends before the proposal ends, then the user in question holds the right to re-cast their vote. If a proposer is blocked, their vote is removed and "(banned)" is added next to their name in the "Proposer:" line of the proposal, which runs until its deadline as normal. If the proposal passes, it falls to the supporters of the idea to enact any changes in a timely manner.
 * 8) No proposal can overturn the decision of a previous proposal that is less than 4 weeks (28 days) old.
 * 9) 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.
 * 10) All proposals that end up in a tie will be extended for another week. Proposals with more than two options must also be extended another week if any single option does not have a majority support: i.e. more than half of all votes cast must be for a single option, rather than one option simply having more votes than the other options.
 * 11) If a proposal has more than ten votes, it can only pass or fail by a margin of three votes. In other words, one option must have 50% + 3 of all votes cast. This means that if a basic two-option 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. Proposals with more than two options require more precise counting of votes to determine if an extension is necessary.
 * 12) Proposals can only be extended up to three times. If a consensus has not been reached by the fourth deadline, the proposal fails and can only be re-proposed after four weeks, at the earliest.
 * 13) 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 an administrator, the proposer can ask for that help.
 * 14) If the administrators 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.
 * 15) Proposals can only be rewritten or deleted by their proposer within the first three days of their creation. However, proposers can request that their proposal be deleted by an administrator at any time, provided they have a valid reason for it. Please note that cancelled proposals must also be archived.
 * 16) There should not be proposals about creating articles on an 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 setting up a collaboration thread on the forums.
 * 17) Proposals cannot be made about promotions and demotions. Users can only be promoted and demoted by the will of the administration.
 * 18) No joke proposals. Proposals are serious wiki matters and should be handled professionally. Joke proposals will be deleted on sight.

Basic Proposal and Support/Oppose Format This is an example of what your proposal must 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]". Proposals presenting multiple alternative courses of action can have more than two voting options, but what each voting section is supporting must be clearly defined. - ===[insert a title for your proposal here]=== [describe what issue this proposal is about and what changes you think should be made to improve how the wiki handles that issue]

Proposer: Deadline: [insert a deadline here, 7 days after the proposal was created, at 23:59 GMT. (14 days for Writing Guidelines and Talk Page Proposals)

====Support====
 * 1) [make a statement indicating that you support your proposal]

====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 another 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.


 * For a list of all settled Talk Page Proposals, see here.

Rules
 * 1) All active talk page proposals must be listed below in chronological order (new proposals go at the bottom). All pages affected 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 section's header, and once the proposal is over, replace the template with.
 * 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 and 4 as follows:
 * 3) Voting in talk page proposals will be open for two weeks, not one. (All times GMT.)
 * 4) *For example, if a proposal is added at any time on Monday, August 1, 2011, it ends two weeks later on Monday, August 15, 2011, at 23:59 GMT.
 * 5) Talk page proposals may be closed by the proposer at any time if both the support and the oppose sides each have fewer than five votes.
 * 6) The talk page proposal must pertain to the article it is posted on.

List of Talk Page Proposals

 * Move Mini Door to . (Discuss) Deadline: February 20, 2013, 23:59 GMT
 * Remove the "Notable Members" section on the article Human. (Discuss) Deadline: February 24, 2013, 23:59 GMT
 * Create a page for the colored Bloopers seen in Super Mario Sunshine. (Discuss) Deadline: February 25, 2013, 23:59 GMT

Writing Guidelines
None at the moment.

Quick identification for patrollers, sysops, etc.
We all know that there's different ranks of users here at the SMW. It'd make sense that we'd want to know who's who. We can already see who's a patroller, sysop, etc. by going to a special list or sometimes going to their user page. But if you want to know who's who quickly for a specific reason (i.e. a bureaucrat for a name change) then there should be some sort of identification on or next to their name on the Who's Online template, or better, wherever their name is displayed. I was thinking maybe a specially-colored name, a picture of some sort next to their name, or at least an acronym. (ex. BC for bureaucrat, PT for patroller, etc.) Because really, who (other than the staff themselves, of course) is going to be able to name every single SMW staff member right off the top of their head, hmm?

Proposer: Deadline: February 26, 2013, 23:59 GMT

Support

 * 1) I've had trouble looking at who's a staff member before; I almost got just an ordinary user to change my name. More reasons of mine above.
 * 2) We do have something like this on the forums, where users with ranks are given different-colored profiles. I think it would be good to implement this here as well in case new users needed to report something to an admin asap, but haven't quite learned who's who yet. As long as we are able to implement this feature, I support it.
 * 3) Not a bad idea. Maybe this could help new users to find help with a adm.
 * 4) Per proposal.
 * 5) Per proposal.
 * 6) That should definetely be there, because if new users enter the wiki, they do not know who can help them and who is experienced. Anyways, that should be there without an argument.
 * 7) - Yeah, yeah, per all.
 * 8) Per all.
 * 9) &mdash; Although Porplemontage has already endorsed this idea and plans to implement it, I'd like to indicate my support for the proposal. Per Goomba.
 * 10) - Per all.
 * 11) - Per SMB.
 * 12) - Per all.
 * 13) Per all.
 * 14) - Per all.

Comments
Just voted, but I've noticed that you singled out Autoconfirmed users in the title. Unlike admins, I don't believe they need special identification on Who's Online. -- 02:49, 19 February 2013 (EST)
 * Now that I think about it, you're right... -- 02:53, 19 February 2013 (EST)
 * It might be a good idea to find out whether this sort of thing is even possible. The last thing you want to happen is to have this proposal pass and have no way of implementing whatever means of additional identification is decided upon.
 * This is possible and I will do this. -- 03:16, 19 February 2013 (EST)

Just curious, but any word on Autopatrolled users?
 * No point. They're just regular users who make good edits and/or who were admins: being autopatrolled simply makes the admins' job easier, and doesn't affect other users at all. The point of this (as I understand it) is that users can either get to know the staffs' names, or more importantly, find one in a pinch if there's a flame war, or a troll attack or some other problem that needs a current admin's attention. Having too many colours (or icons or whatever) muddies it up and makes it harder to find what you need, so it's best to keep it straightforward and only single out the current staff, I think. -
 * So would we settle on one color for the staff or different colors for each rank within the staff? -- 00:17, 20 February 2013 (EST)

Removals
None at the moment

Series' articles
There is some discrepancy on this wiki involving around the series' articles and it is that all those articles completely mismatch with each other when it comes to listing the installments in the series. Some get listed in a very different way which, in my opinion, is actually a mess. Many articles use a wikitable that lists the release year, a breif description, and some game ratings, the Mario (series) article is a good example; other simply list the year release, the system or console and a link to the beta elements for said game, the Mario Kart (series) article is pretty obvious; few articles got lazier a simply have a paragraph describing the game and the boxart on a thumbnail, the Mario vs. Donkey Kong (series) article says hi; and finally the rarest of all: an infobox for every game is used instead, the Mario & Luigi (series) article is the case here. Seeing how this messy is, I got into the conclusion of using a single format for every series' article, I propose choosing one single format for all these articles as I don't see a reason to have multiple and different formats when we can just simply have one.

Proposer: Deadline: February 24, 2013, at 23:59 GMT.

Use wikitables

 * 1) - I personally think this is the best option, and because changing the whole Mario (series) article would be a lazy process.
 * 2) - consistency's good.
 * 3) This is the best organized one. There is a reason we use tables much to organize information in this wiki. All the rest either look lazy, cluttered, or just plain ugly when it comes to displaying information.
 * 4) - This is the best way to organize the information. Per all.
 * 5) Per all.
 * 6) Per Glowsquid.
 * 7) Per all.
 * 8) - Per all.
 * 9) - Per all.
 * 10) - Per all.
 * 11) Per all.
 * 12) It would make these articles more organized. Per all.
 * 13) - Per all.
 * 14) &mdash; Per Byllant's proposal and Glowsquid's voting reason.

Comments
Should anything else be added into the wikitables, aside the features already listed? -
 * I think it's fine the way it is. All necessary information is already there. In my opinion, adding anything else would probably make the information redundant or not needed.

Increase the file size limit for OGG videos
A problem I've noticed when trying to deal with cutscene recordings from games is that while they can usually be compressed to under 10 MB, the quality suffers especially if the cutscene is a few minutes long (this is especially noticeable with GBA games).

However, my main issue is not the inability to upload higher quality cutscenes, but rather it being outright impossible to upload some cutscenes regardless of quality. I had planned to upload some from Mario Super Sluggers along with some other Wii games, but even with extremely low video quality (64kbps bitrate), the files were around 15 MB. It would be nice to raise the limit to around 25 - 30 MB (50 MB or so would allow for longer cutscenes, but is our priority getting them uploaded even with very low quality, or supplying them at a reasonable (but not exactly HD) quality?); I don't know how much of a strain this would put on the server, but in my opinion, raising it for these videos (I don't know if it's possible to raise the size limit just for certain file types, but I doubt people would start uploading 25 MB images anyway) would be helpful.

Proposer: Deadline: February 24, 2013, 23:59 GMT

Increase size limit (an appropriate amount can be discussed in the comments)

 * 1) - Per proposal. Somewhere around 25 - 30 MB would be good enough for me.
 * 2) I've had similar issues in the past involving video size restrictions, so if we were able to increase the file size limit then I'm supporting it.
 * 3) &mdash; If Porplemontage confirms that this would be possible and that it wouldn't be too much of a weight on the server, then I support Turboo's proposal. Expanding the file size limit for these videos can allow us to be more inclusive with our coverage of cutscenes on the wiki itself. In the end, the fuller coverage is something we should strive for. We could always try to regulate, through proposals, any specifics to cut down on abuses of the expanded file size (such as restrictions on files not being used for the mainspace articles and whatnot).

Do Nothing (keep the size limit at 10 MB)

 * 1) It's much easier to link to the video, and that limit is there for a reason – for some people, this would make loading times horrendous, on my iPod anything larger than 4mb can cause safari to crash.
 * 2) - Per BowserJunior.
 * 3) I don't see the need for this, especially if we can use YouTube as an external link to these OGG videos.
 * 4) Per all.

Comments
You should ask Porplemontage about this: he's the one who calls the shots on file limits. Either way, seeing as YouTube is already pretty much the go-to place for cutsenes, afaik, it seems easier just to keep externally linking, rather than burning our server space on this kinda thing. -
 * I kind of figured it would be up to him, but I don't know how strict we are on YouTube; do we just forbid people from using the tags in mainspace articles and allow linking of cutscenes in the External Links section? -
 * Yeah, still no tags on the articles: it makes them too large and cumbersome to load. External links are one way to do it, but I think using references would be even more effective. -

@BowserJunior: The only way this would affect loading times on certain pages is if the videos were loaded on the page (they aren't)/if people started uploading huge images and placing them on pages if the size limit were increased for every file type. I can't say I know how overall server strain/load times would be affected by larger files, though. - Turboo (talk) 20:08, 18 February 2013 (EST)

Miscellaneous
None at the moment.