From the Super Mario Wiki
Jump to: navigation, search

Current time:
Friday, April 28th, 06:14 GMT

Proposals can be new features (such as an extension), removals of previously added features that have tired out, or new policies that must be approved via consensus before any action is taken.
  • Any user can support or oppose but must have a strong reason for doing so, not, e.g., "I like this idea!"
  • "Vote" periods last for one week.
  • All past proposals are archived.
  • All proposals must be approved by a majority of voters, including proposals with more than two options.

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 {{User|User name}}.

How to


  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. Only registered, autoconfirmed users can create, comment in or vote on proposals. Users may vote for more than one option on proposals with more than two choices.
  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).
    • 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.
  4. Every vote should have a strong, sensible reason accompanying it. Agreeing with a previously mentioned reason given by another user is accepted (including "per" votes), but tangential comments, heavy sarcasm, and other misleading or irrelevant quips are just as invalid as providing no reason at all.
  5. 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.
  6. 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.
  7. No proposal can overturn the decision of a previous proposal that is less than 4 weeks (28 days) old.
  8. 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.
  9. 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 the total number of voters must appear in a single voting option, rather than one option simply having more votes than the other options.
  10. If a proposal has more than ten votes, it can only pass or fail by a margin of three votes, otherwise the deadline will be extended for another week as if no majority was reached at all.
  11. 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.
  12. 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.
  13. 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.
  14. 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.
  15. Unless there is major disagreement about whether certain content should be included, there should not be proposals about creating, expanding, rewriting or otherwise fixing up pages. To organize efforts about improving articles on neglected or completely missing subjects, try setting up a collaboration thread on the forums.
  16. Proposals cannot be made about promotions and demotions. Users can only be promoted and demoted by the will of the administration.
  17. 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''': {{User|[enter your username here]}}<br>
'''Deadline''': [insert a deadline here, 7 days after the proposal was created (14 for writing guidelines and talk page proposals), at 23:59 GMT, in the format: "August 8, 2011, 23:59 GMT"]

#{{User|[enter your username here]}} [make a statement indicating that you support your proposal]



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 "#{{User|[add your username here]}}" 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 Category:Settled talk page proposals.


  1. All active talk page proposals must be listed below in chronological order (new proposals go at the bottom) using {{TPPDiscuss}}. Include a brief description of the proposal while also mentioning any pages affected by it, a link to the talk page housing the discussion, and the deadline. If the proposal involves a page that is not yet made, use {{fakelink}} to communicate its title in the description. Linking to pages not directly involved in the talk page proposal is not recommended, as it clutters the list with unnecessary links. Place {{TPP}} under the section's header, and once the proposal is over, replace the template with {{SettledTPP}}.
  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).
    • 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.
  4. 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.
  5. The talk page proposal must pertain to the article it is posted on.
  6. When a talk page proposal passes, replace its deadline with "Passed" but do not remove it from the list below until the proposed changes have been enacted.

List of talk page proposals

Writing guidelines

None at the moment.

New features

None at the moment.


None at the moment.


Discourage OGG Extension (Not Format)

The *.ogg extension is a generic extension to describe the *.ogv and *.oga file formats. To put that into perspective, that would be like clumping all *.jpg, *.png, and *.gif file extensions to be under *.img or something*.html, *.xml, and *.rtf formats to be included with what we expect of the *.txt extension. Yes, those files all contain easily readable text if opened in Notepad, but it would be very hard to tell each file apart if all HTML, XML, and RTF files all had the TXT extension instead. To make things more easily identifiable on MarioWiki, I propose that *.ogg be a discouraged extension for a file of this type when uploading. Sure, MediaWiki can detect the MIME type regardless of extension, but that's not immediately clear when sifting through categories.

Xiph.Org Foundation, the developers of OGG, recommend the extensions I am proposing[1]. VLC Media Player already registers all known extensions of this standard. My guess is back in the day, OGG was just audio (such as DX-Ball 2) but things were getting more complex so they needed to have a better extension to represent the complexities of the standard and discourage the old extension.

To be clear, I am not looking to discourage the format, just the one extension of the format. OGV and OGA are perfectly safe. There are around 1,000 files to check and move. Let's get them changed before we end up with a insurmountable amount of files to make changes to. I think Pywikibot can do this stuff automatically.

Files tested to be moved successfully
Categories to sift through (recommended order to do them in)
  1. Category:Fair use video samples
  2. Category:Fair use music samples
Affected templates that need consideration
  • {{media}} - Update it to allow for OGV and OGA as well? Code for row one but apply similar code for each row after it:
  • {{media/OGV}} - Behaves like row but for OGV only
  • {{media/OGA}} - Behaves like row but for OGA only
  • {{media/row}} - Only works for files with extension OGG. Deprecate it?
Related proposals

Proposer: Wildgoosespeeder (talk)
Deadline: May 02, 2017, 23:59:59 GMT


  1. Wildgoosespeeder (talk) Per proposal.
  2. Niiue (talk) Per proposal.
  3. Yoshi the Space Station Manager (talk) My browser (at least the one I use the most as I also have Google Chrome, but I not really going to mess with ogg) doesn't even support OGG, OGA, or OGV. But, OGA and OGV are very different from each other. Banning use of OGG for both audio and video sounds good. But, what about applications if they ever become part of this wiki? What will happen to those? (I am only asking to point out all possibilities.) As for vandels that happen during this, there is a option not to show/hide bots which I have chosen to hide them and this is the only thing I have chosen to hide due to when bots work, it makes a lot of changes reflected on Recent Changes. Overall, I will support this decision.
  4. Supermariofan67 (talk) Per proposal.
  5. TheFlameChomp (talk) Per proposal.
  6. Mario4Ever (talk) Per proposal.
  7. Baby Luigi (talk) Nothing wrong with encouraging a better extension than a blanket one. The proposal previously supported a complete ban on .ogg which was too extreme for my tastes, but this is something I could get behind.
  8. Toadette the Achiever (talk) I'm now convinced that this proposal will succeed. Per Baby Luigi and my comment below.
  9. Mister Wu (talk) If this simplifies life for the Wiki editors and staff, I support the idea. It is recommended by the Xiph.Org Foundation anyway.


#Lord Bowser (talk) There is apparently no technical difference between .oga and .ogv, while there are differences between .png, .jpg, .gif, etc, which renders that point in the proposal moot. I can't really imagine a scenario where only having .ogg would hinder the wiki in any aspect, and besides, .ogg files are relatively infrequently uploaded and used here. Banning the .ogg extension in place of .ogv and .oga seems like a lot of hassle for little benefit, as like you said, thousands of files would need to be moved; however, even more articles than that would have to be edited in order to correctly reflect the moved files, which is a pretty big task even with bots. This is a good idea on paper, but the benefits of implementing this seem to be outweighed by the sheer level of editing that needs to be done across every article that uses .ogg files.
#Toadette the Achiever (talk) Per Lord Bowser. It indeed sounds rock-solid on paper, but if you think more deeply about it, why would it even be necessary to ban one extension when the two umbrella extensions work very similarly to each other, yet are used differently? If anything, I say we ban OGA and OGV because sometimes having less options can actually benefit and relieve more than harm. Unless you can give some other reason for banning OGG, I'm afraid I'll have to oppose.
#Baby Luigi (talk) The idea to split the sound files and video files into their own compartments sounds like a good idea on paper, but I think the creation of another category specifically dealing with .OGV versions of .OGG would be more useful in the long run, as we don't have to bend backward to change this rather common file extension across the wiki. As the above two stated, I think too much energy required is worth the hassle of what amounts simply a name change with very little benefit to it whatsoever. Furthermore, .OGG is the default extension for many programs I use such as VLC and Audacity, and I think it's just too much of a hassle going through the extra step of renaming the extension to meet these proposed standards. If you want to rename extensions from .OGG to .OGA or .OGV, no one is stopping you, since that's technically allowed, but I don't support an official, outright ban on .OGG formats either.


Sort of we still need {{requirescortado}}? I thought browsers supported this by default. --SuperMarioNSMBWii.PNGMarioKoopa Troopa Artwork - New Super Mario Bros. 2.pngFan 67 17:43, 25 April 2017 (EDT)

With HTML5 supported video playback with the version of MediaWiki MarioWiki uses, that feature seems worthy of {{abandoned}}. --Wildgoosespeeder (talk) (Stats - Contribs) 18:01, 25 April 2017 (EDT)

And what exactly is the difference between .oga and .ogv? Is it really significant enough to warrant banning the .ogg extension? This should really be further elaborated upon for those less experienced. Bowserhead.png Lord Bowser (talkeditsforum) 03:01, 26 April 2017 (EDT)

Technically, no difference between *.ogg, *.oga, and *.ogv. They are all defined by one standard, as I linked at the very beginning of the proposal. For MarioWiki, it would make maintenance easier by making all files by the standard easily identifiable by file extension rather than by MIME type. We should assign *.oga for audio, assign *.ogv for video, and forbid *.ogg rather than use the extensions interchangeably with audio and video data streams. By posing these restrictions, we can integrate {{media/OGA}} and {{media/OGV}} better than what is currently being done with the restrictive {{media/row}} for *.ogg files only. --Wildgoosespeeder (talk) (Stats - Contribs) 04:33, 26 April 2017 (EDT)
No article editing required because the templates force .ogg, .ogv, and .oga for {{media/row}}, {{media/OGV}}, and {{media/OGA}} respectively. Only one edit will take place, on {{media}}. The rest is moving. You don't specify the extension if you use the template. Not sure why but OK. All that needs to be done is the move bot work, which I have my credentials hooked to, so this work is all me. I have done thousands of edits before at a time with Category:Beta Images by moving the remaining hundreds of images to Category:Pre-release and unused images. It got done in two hours or so. If a vandal runs rampant during the transition, I immediately stop the bot so that way Special:RecentChanges doesn't render the vandal unnoticed. --Wildgoosespeeder (talk) (Stats - Contribs) 17:33, 26 April 2017 (EDT)

Yoshi the Space Station Manager (talk), this is just a browser issue. Chrome supports MP4, WebM, and OGG/OGV/OGA. Internet Explorer just MP4 (automatically) and WebM (with a codec installation by Google). For some reason, Internet Explorer forces you out of being able to play OGG/OGV/OGA. Just open up the file in an external application, such as VLC Media Player.

Applications? You mean like *.exe, *.zip, *.rar, *.7z? That's Porplemontage (talk)'s decision and I don't blame him for it.

People have brought up to flag my account as a bot temporarily but I don't use the bot often enough for it to be worth it. --Wildgoosespeeder (talk) (Stats - Contribs) 18:21, 26 April 2017 (EDT)

When I say applications, I am referring to something else the OGG covers which can be viewed on the Wikipedia site provided. SMR Red Yoshi.jpg Yoshi the SSM (talk) Easter (the tomb is empty, so is this egg) 18:26, 26 April 2017 (EDT)
I'm not entirely sure how MarioWiki can take advantage of those added perks of the OGG standard. Because of how the four media templates are coded, we just create additional templates for each extension and amend the switch.
  • .ogg
  • .ogv
  • .oga
  • .ogx
  • .ogm
  • .spx
  • .opus
If I really had my way with the four templates, I would delete the subpages and code everything into {{media}}. --Wildgoosespeeder (talk) (Stats - Contribs) 18:56, 26 April 2017 (EDT)

Xiph.Org Foundation recommends the extensions I am proposing. [2] --Wildgoosespeeder (talk) (Stats - Contribs) 18:56, 26 April 2017 (EDT)

Again, I'll be doing the work to get things up to standards. It's a one time deal. Title changed so the file extension is acceptable but should be moved to a better extension. --Wildgoosespeeder (talk) (Stats - Contribs) 20:39, 26 April 2017 (EDT)

Yeah...dissuasion is usually better than an outright ban. MLPJToadetteWink.gif ToadettetheAchiever 21:02, 26 April 2017 (EDT)
@Wildgoosespeeder, I've read everything, and I understand what you want to do, but I don't entirely understand why. First, you mention that "it would make maintenance easier by making all files by the standard easily identifiable by file extension rather than by MIME type." From an organizational standpoint, it makes sense, but what do you mean by "maintenance," and how does keeping the .ogg extension currently complicate things? Second, you said that "by posing these restrictions, we can integrate {{media/OGA}} and {{media/OGV}} better than what is currently being done with the restrictive {{media/row}} for *.ogg files only." Is there only an organizational benefit here, or am I missing the bigger picture? Mario4Ever (talk)
Proposal now has a reason to move over each file to the extension based on standards by Xiph. Consider each subcategory of Category:Media by game. They contain a mixture of audio and video under the extension OGG in most cases (only five uploaded files are up to Xiph's extension standards). I also explain a better example with text files why keeping the OGG extension is a bad idea. Right now, {{media}} is calling {{media/row}} only 30 times. With the switch code I can implement very easily, {{media}} could call {{media/row}}, {{media/OGA}}, or {{media/OGV}} depending on the type specified. The OGA and OGV templates were proposed, passed, and created, just never properly implemented. Also, Media/OGA and Media/OGV isn't transcluded very much compared to Media/row. The special thing about templates and categories is that if you edit the template to change its category, it affects all places it is transcluded, autosorting everything in Category:Pages with media files to go into Category:Pages with audio files and Category:Pages with video files. --Wildgoosespeeder (talk) (Stats - Contribs) 21:55, 26 April 2017 (EDT)

Baby Luigi (talk), you don't even need to do it through Audacity. You can just use Windows Explorer (or equivalent file manager) to change the extension or redlink with the OGA/OGV extension and upload the source file that kept OGG. File contents doesn't change. Just the file name extension. This is similar to how you can upload a file with the *.jpg extension onto a file using *.jpeg because File:New Nintendo 3DS and New Nintendo 3DS XL.jpg can exist separately. --Wildgoosespeeder (talk) (Stats - Contribs) 21:09, 27 April 2017 (EDT)

Just as I suspected. So it's just like changing a notepad file to a .bat file, nothing would really change if I edited the extension. Thanks for clearing that up. BabyLuigiFire.png(T|C) 22:55, 27 April 2017 (EDT)
Exactly. To make it even more clear, MediaWiki would have thrown an error if I were to move an PNG image to a page with a JPEG extension for example. I tested OGV and OGA moves with two OGG files, described in the proposal, and MediaWiki didn't throw any errors. --Wildgoosespeeder (talk) (Stats - Contribs) 02:14, 28 April 2017 (EDT)

Create Template:Pmitem-infobox

I've noticed that pages for Paper Mario series items don't really have a consistent format, usually having either Template:Item-infobox or Template:Recipe-Infobox. The problem is, neither template works very well, especially in terms of documenting the items' descriptions between games (the item infobox looks bad with multiple descriptions stacked on each other, and the recipe infobox doesn't even have a description field). Because of that, I propose that we create a new infobox for Paper Mario items, that way it's easier to document series-specific info in a convenient way.

Here's the current draft in my sandbox, which is mostly incomplete at the moment.

Proposer: Niiue (talk)
Deadline: May 04, 2017, 23:59 GMT


  1. Niiue (talk) Per proposal.
  2. Yoshi the Space Station Manager (talk) Sure, but we would have to get rid of recipe-info box because it repeats everything already mentioned, while what is proposed will bring new info as well. I also like the proposed name better than the recipe one.
  3. Baby Luigi (talk) Sounds like a good idea to me. Per proposal.
  4. TheFlameChomp (talk) Per all. Would the Template:Recipe-Infobox be necessary anymore? All of the pages it is used on are Paper Mario items, and the new infobox would repeat certain information.
  5. Toadette the Achiever (talk) That definitely sounds fine to me. I also agree that Template:Recipe-Infobox would no longer be needed should this proposal pass. However, I wonder if we can do the same to the Mario & Luigi series, since the items listed are also in need of an infobox. Nonetheless, it's a good idea, and I see no reason to oppose in the long run.
  6. Alex95 (talk) I don't know why we don't have this already. Per all.
  7. Mario4Ever (talk) Per all.
  8. Mister Wu (talk) The new template makes more sense, so I approve!




None at the moment.