From the Super Mario Wiki, the Mario encyclopedia
Jump to navigationJump to search
Image used as a banner for the Proposals page

Current time:
Monday, May 23rd, 20:37 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 here, while talk page proposals are archived here.
  • 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 guidelines. Proposals must include a link to the draft page. Any pages that would be largely affected by the proposal should be marked with {{proposal notice}}.
  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.
    • Users can also use the Comments section to bring up any concerns or mistakes in regards to the proposal itself. In such cases, it's important the proposer addresses any concerns raised as soon as possible. Even if the supporting side might be winning by a wide margin, that should be no reason for such questions to be left unanswered. They may point out any missing details that might have been overlooked by the proposer, so it's a good idea as the proposer to check them frequently to achieve the most accurate outcome possible.
  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 where none of the options have at least four votes will be extended for another week. If after three extensions, no options have at least four votes, the proposal will 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 with only two voting options 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 (six days for talk page proposals). 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. Such options should also be kept to a minimum, and if something comes up in the comments, the proposal can be amended as necessary.

===[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 MarioWiki:Proposals/TPP archive and 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 {{fake link}} 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. The talk page proposal must pertain to the article it is posted on.
  5. When a talk page proposal passes, it should be removed from the list and included in the table under the "Unimplemented proposals" section until the proposed changes have been enacted.

List of ongoing talk page proposals

Unimplemented proposals


Decide how to cover recurring events in the Mario & Sonic series, BBQ Turtle (ended July 17, 2018)
Reorganize and split Gallery:Toys and other Merchandise galleries, Results May Vary (ended July 30, 2019)
Split the attacks from Paper Mario: Sticker Star and Paper Mario: Color Splash, Scrooge200 (ended July 4, 2020)
Reorganize images in levelboxes pertaining to games with remakes, remasters, etc., DarkNight (ended September 30, 2020)
Create an article for Froggy, BBQ Turtle (ended November 25, 2020)
Use indicators for pre-release images, Scrooge200 (ended March 27, 2021)
Do not allow WildBrain to be used as a source, PanchamBro (ended May 23, 2021)
Use a hybrid of prose and bullet points when listing changes on articles for ports, remakes, and remasters, 0blivion (ended June 5, 2021)
Define the scope of "Other appearances" sections (only third-party media we don't cover), Koopa con Carne (ended November 18, 2021)
Create "Unused appearances" sections in history, Waluigi Time (ended January 11, 2022)
Merge the Wrecking Crew and VS. Wrecking Crew phases into list articles, Spectrogram (ended February 24, 2022)
Create a stat table template for Mario Kart DS karts, ShootingStar7X (ended March 3, 2022)
Do not consider usage of classic recurring themes as references to the game of origin, Swallow (ended March 9, 2022)
Create a collective article for the Sonic the Hedgehog animal friends that cross over with Mario, BBQ Turtle (ended March 20, 2022)
Establish a guideline for the number of files in Media sections on game articles, DannyTheDingo (ended April 5, 2022)
Allow Pinball to receive full coverage, Spectrogram (ended April 15, 2022)
Classify Art Style: PiCTOBiTS as a guest appearance and give it its own page, Jacklavin (ended April 19, 2022)
Determine The Legend of Zelda: Link's Awakening as a guest appearance and create articles covering it and its Mario-related subjects, Results May Vary (ended April 20, 2022)
Split Mario Kart Tour character variants into list articles, Tails777 (ended May 4, 2022)
Use a separate table for internal names, Somethingone (ended May 14, 2022)

Talk page proposals

Include information on Construction Zone for the rest of the Mario vs. Donkey Kong series, Koopa con Carne (ended November 24, 2019)
Make pages for Deku Baba and other non-Mario elements appearing in Mario Kart 8, Koopa con Carne (ended August 5, 2021)
Create a generic Koopa Shell article and reorganize the colored shell articles, Ray Trace (ended August 29, 2021)
Clean up Partner, 7feetunder (ended September 12, 2021)
Split all the clothing, Doc von Schmeltwick (ended September 12, 2021)
Split X-Nauts (platoon) from X-Naut, Doc von Schmeltwick (ended September 18, 2021)
Merge Solo Toady to Toady and split Kamek's Toadies, FanOfYoshi (ended November 16, 2021)
Add a list of languages a game supports to the game infobox, Zachruff (ended February 26, 2022)
Split Blumiere's father and Scarlette from List of implied characters, Waluigi Time (ended March 17, 2022)
Merge Piro Dangle to Spark, Doc von Schmeltwick (ended March 24, 2022)
Split the Super Smash Bros. Ultimate spirit page into smaller lists, Koopa con Carne (ended March 30, 2022)
Merge Neo Bowser Castle (Mario & Luigi: Dream Team) and Neo Bowser Castle (Mario & Luigi: Paper Jam) into a single Neo Bowser Castle article, Doc von Schmeltwick (ended April 3, 2022)
Split Rare's handheld Donkey Kong Country series reissues, Doc von Schmeltwick (ended April 21, 2022)
Split the various reissues of Mario Bros., Doc von Schmeltwick (ended April 22, 2022)
Merge Naval Bud with Naval Piranha and Bungee Bud with Big Bungee Piranha, FanOfYoshi (ended April 23, 2022)
Split named sub-locations from Super Mario RPG: Legend of the Seven Stars, Doc von Schmeltwick (ended April 24, 2022)
Split Shelly from Birdo, Doc von Schmeltwick (ended April 24, 2022)
Recreate Giant Donkey Kong, Doc von Schmeltwick (ended April 25, 2022)
Merge Big Boo (boss) to Big Boo, Doc von Schmeltwick (ended May 11, 2022)

Writing guidelines

None at the moment.

New features

None at the moment.


Remove the dktable-brown class

This is a really minor issue, but something that's been bugging me for a while. Most articles around the wiki relating to the Donkey Kong franchise use a unique brown coloration for their tables (see example). This contrasts with the rest of the wiki, which generally uses white/light gray tables (see example). Apparently, this is something we got as a result of the DK Wiki merge, though I can't find any evidence that it was ever actually used there.

I have two problems with this. First of all, it seems strange to single out Donkey Kong with these. Yoshi doesn't have it, Wario doesn't have it, none of the Mario spin-offs have it, Smash doesn't have it. Because of that, it's kind of jarring, and I don't see why we need a visual indicator like this to separate just one area of the franchise. Second, it just clashes with the aesthetic of the wiki in general (that's why I'm not proposing to fix the first issue just by adding more). We have a pretty clean, Wikipedia-esque look that focuses on whites and grays, with splashes of color used sparingly and when necessary. The alternating browns don't even match the conventions of our other tables, which have the same, consistent coloration for all cells of the same "priority", so to speak.

If this passes, all tables using dktable-brown will be switched to the standard wikitable class used everywhere else on the wiki.

Proposer: Waluigi Time (talk)
Deadline: May 27, 2022, 23:59 GMT


  1. Waluigi Time (talk) Per myself.
  2. Ray Trace (talk) I like adding color myself to some tables and I'm not opposed to some flair to basic formatting (see Dr. Mario World, Super Mario World, and Yoshi's New Island) but I think the coloration for the dktable is excessive, and I don't think a class specifically designed for a particular series of games is necessary. Wikitable colors for video game articles should at least be consistent with the nav template their series is based off of (ie Mario Party using yellow, Mario RPGs using blue, etc). If we were to color tables, I'd limit it to just the title headers on the top and make sure it matches the nav template color. Super Mario Land is a bit guilty of this so I think we should also establish some sort of standard for wikitable coloration, not just removing the dktable class.
  3. PanchamBro (talk) Per Waluigi.
  4. TheFlameChomp (talk) Per proposal.
  5. Archivist Toadette (talk) Yeah, sure.


  1. Doc von Schmeltwick (talk) - per LGM in the comments. Also, we need to avoid bleeding white from sprites into the backgrounds (Super Mario Land being the exception since in-game "white" is transparency).


I don't mind the series styling, but what do you think about how some Yoshi's Island tables are handled? See Yoshi's New Island and Super Mario World 2: Yoshi's Island. Dr. Mario World does the same. Are you saying we should remove styling all together or just remove that particular CSS class? Why not just change the css class to both avoid repetitive styling text in the wiki and also change the colors a bit to fit the aesthetic of the wiki? I'm no css expert, but what are the advantages of these styling classes? Mario Green.pngBazooka Mario BadaBoom! 16:31, May 20, 2022 (EDT)

One immediate advantage I can think of is that you don't need to manually input colors every time you make a table: just insert "raytraceclass" and you'll get the colors you want. BabyLuigiFire.png Ray Trace(T|C) 16:37, May 20, 2022 (EDT)
Didn't realize it was done there too. I don't care for the Yoshi table styling either for similar reasons, though I don't dislike it as much as the DK one. Maybe it's because the lightest green there is actually pretty subtle, while all the browns on the DK table stand out? Dr. Mario World's is fine but seems a bit unnecessary, but then again I've never played the game so the coloration could very well make more sense there. Personally I'd just prefer to do away with the styling altogether and leave it for cases where it's actually warranted by what's in-game (i.e. characters being associated with specific colors), but if it's going to stay I wouldn't mind either toning things down a bit or doing something closer to what's done with Dr. Mario World. --Waluigi's head icon in Mario Kart 8 Deluxe. Too Bad! Waluigi Time! 16:41, May 20, 2022 (EDT)
The color in Dr. Mario World's table is based on the nav template colors we currently employ for series articles. BabyLuigiFire.png Ray Trace(T|C) 16:44, May 20, 2022 (EDT)
Ahh that makes a lot more sense. That's not a bad idea, though the way the colors are picked for the navboxes in the first place is pretty arbitrary, so I don't know. --Waluigi's head icon in Mario Kart 8 Deluxe. Too Bad! Waluigi Time! 16:48, May 20, 2022 (EDT)
(edit conflict) The table colors match the navigation templates, which I think is a neat touch (though I'd personally choose another color for Dr. Mario series rather than... sewage yellow, see MarioWiki:Navigation templates). I do think probably the headers should be restricted to the color, but it really depends on the context; I don't find the world tables that bad; also the alternating colored row do help guide the eyes around the table. As for what color is determined, I'm seeing a rainbow pattern, with series grouped with each other with appropriate color (Peach is Pink, Mario is red, Wario is purple, Luigi is dark green, Yoshi is light green, DK is brown), and maybe the other colors were up for grabs, with the yellows and blues being the most arbitrary ones. Buuut, that's another topic. Mario Green.pngBazooka Mario BadaBoom! 16:54, May 20, 2022 (EDT)

I do find it useful for Donkey Kong Land since so many sprites use white (which bleeds into the background), but I am just a tad miffed that this is being run when I am in the process of an extremely lengthy splitting process of DK games. Doc von Schmeltwick (talk) 13:32, May 22, 2022 (EDT)

Well I think there's room for discretion in those specific cases, I wouldn't support changing, say, the Costume Mario table either. That's a great example of this, actually, as the coloration is only used where it's absolutely necessary, which I've been saying this whole time re: using colors. The proposal isn't about prohibiting it entirely anyway, it only affects a single class (though would likely set a precedent). I don't think every single Donkey Kong-related table across the wiki needs to be fully colored in contrast with everything else just because of some sprites. (Not sure what the DKC splits have to do with this though, it'll most likely just be a very simple bot process.) --Waluigi's head icon in Mario Kart 8 Deluxe. Too Bad! Waluigi Time! 13:55, May 22, 2022 (EDT)
Some subheaders needed specifically colored in. But as LGM said, the banding helps to guide the eyes regardless. Doc von Schmeltwick (talk) 14:04, May 22, 2022 (EDT)
Yeah, but as Waluigi Time said, I don't think the proposal forbids styling but more of just discontinues using the css class. Though my concern is that maybe we can redesign the css class instead; our wiki already practices some sort of series-consistent styling with example articles, so why not introduce new classes to make it easier? Mario Green.pngBazooka Mario BadaBoom! 14:39, May 22, 2022 (EDT)
That's about what I'm thinking. Doc von Schmeltwick (talk) 15:09, May 22, 2022 (EDT)


Change Monobook's background image to the one used on our Vector skin

For nearly a decade now, we've been using this background with the text "Super Mario Wiki" as our default background for Monobook, and subsequently the rest of the wiki. However, as our wiki continues to change, it can be argued that our look should change to better represent the Super Mario franchise, as we have done with our logo. Our Vector skin, for its part, has been using this nice background with various Mario-related symbols. As such I would like to suggest making the Vector background the default background for the Monobook skin.

Proposer: PanchamBro (talk)
Deadline: May 27, 2022, 23:59 GMT


  1. PanchamBro (talk) Per proposal
  2. Waluigi Time (talk) Today the wiki background, tomorrow the editing field! Per proposal.
  3. Ray Trace (talk) Per proposal.
  4. TheFlameChomp (talk) Per proposal.
  5. Bazooka Mario (talk) That proposals background is just a mishmash of logos and crap. Can we change that too? An animated sprite of Bowser Jr. seen during loading screens in the Bowser's Fury campaign of Super Mario 3D World + Bowser's Fury
  6. Somethingone (talk) Sure!
  7. Archivist Toadette (talk) Sure feels more in line with what one would expect from a wiki themed around a certain franchise. On Bazooka Mario's note, the source editing background feels dated as well, and should likely be changed to 2D vector art.
  8. Mario4Ever (talk) Per proposal.



Make tables, templates, and other areas in the mainspace compliant with WCAG 2.1

Going off from Waluigi Time's proposal to remove the dktable-brown class, I've noticed that there are currently plenty of tables, templates, and other areas within our mainspace that have glaring accessibility issues in accordance to the Web Content Accessibility Guidlines (WCAG) from the World Wide Web Consortium. For this instance, WCAG is split with two levels: AA and AAA. WCAG Level AA mandates a contrast ratio of at least 4.5:1 for normal text, 3:1 for larger text, and 3:1 for any graphical object and interface. WCAG Level AAA is also recommended, with a contrast ratio mandate of 7:1 for normal text, and 4.5:1 for larger text (it is still 3:1 for graphical objects and user interface components per WCAG 2.1).

When looking at our articles, some of these tables or templates with colors are below this contrast ratio mandate. For instance, these table headers fail with a contrast ratio of 1.88:1 (calculations done on this website). Then as Bazooka Mario pointed out, there are tables on the Yoshi's New Island page with headers that also fail with a low contrast ratio. We also have Template:AppealOutcome, and the "amended" category shown in the last example is hard to read with a contrast ratio of 1.33:1.

These are the type of issues we need to address. We can either go with Level AA, as with a lower ratio requirement it means we can still have access to plenty of colors. We can also decide to go with Level AAA, but it would mean we would be a lot strict with what colors to choose from and many tables or template could lose stylizations as a result. This will not be an easy task to make, as we would need to go through each mainspace article and fix this problem up. But I do hope that we are able to make our text more easier to read if this proposal passes.

Note though, I do not want this applied to anywhere other than the mainspace and templates. Other namespaces can be decided on its own, but I think it's more important to address this for the articles that our readers will look at.

Proposer: PanchamBro (talk)
Deadline: May 29, 2022, 23:59 GMT


  1. PanchamBro (talk) Second option, though it mean we have less colors to work with in general.


  1. PanchamBro (talk) Preferred option since it means we can keep much of our stylization, but still be accessible for readers.
  2. Mario4Ever (talk) I think getting things AA-compliant makes the most sense at this point in time. Transitioning to AAA-compliance could always be done later on an as-needed basis.

Do nothing

  1. Somethingone (talk) Eh, I don't really see the problem with those examples. They all look fine and readable (except the aforementioned last warning amended thing that yellow needs to be fixed), and I'd rather us not have to check if every new color we try to add is acceptable to an arbitrary contrast limit. It just seems like a bit of an unnecessary hassle.


Somethingone: People with more issues with seeing contrast may not, however. Mario Green.pngBazooka Mario BadaBoom! 14:41, May 22, 2022 (EDT)

I'd say this should be a guideline for userspace as well, as I've seen several talk pages that are difficult to read. Mario Green.pngBazooka Mario BadaBoom! 14:56, May 22, 2022 (EDT)

I agree. Some user's talk pages are known to be a nightmare to read in some instances. -- PanchamBro (talkcontributions) 15:00, May 22, 2022 (EDT)


None at the moment.