Proposals can be new features, the removal of previously-added features that have tired out, or new policies that must be approved via consensus before any action is taken.
Voting periods last for two weeks, but can close early or be extended (see below).
Any autoconfirmed user can support or oppose, but must have a strong reason for doing so.
All proposals must be approved by a majority of voters, including proposals with more than two options.
If you would like to get feedback on an idea before formally proposing it here, you may do so on the proposals talk. For talk page proposals, you can discuss the changes on the talk page itself before creating the TPP there.
If someone has 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 other users, who will then vote on whether or not they think the idea should be implemented. Proposals should include links to all relevant pages and writing guidelines. Proposals must include a detailed description of the proposed changes and may link to a draft page. Any pages that would be largely affected by the proposal should be marked with {{proposal notice}}.
Rules
Only autoconfirmed users may create or vote on proposals. Proposals can be created by one user or co-authored by two users.[Proposal 1]
Anyone is free to comment on proposals (provided that the page's protection level allows them to edit).[Proposal 2]
Proposals conclude at the end of the day (23:59) two weeks after voting starts (all times UTC).[Proposal 3][Proposal 4]
For example, if a proposal is added at any time on Monday, August 1, 2011, the voting starts immediately and the deadline is two weeks later on Monday, August 15, at 23:59 (UTC).
Proposals cannot contradict an already ongoing proposal or overturn the decision of a previous proposal that concluded less than four weeks (28 days) ago.
Proposals must have a status quo option (e.g. "Oppose", "Do nothing") unless the status quo itself violates policy.
Users may vote for more than one option, but they may not vote for every option available. Keep in mind that we use approval voting, so all of your votes count equally regardless of preferred order.[Proposal 5]
Every vote should have a strong, sensible reason accompanying it. Agreeing with a previously mentioned reason given by another user is acceptable (including "per" votes), but tangential comments, heavy sarcasm, and other misleading or irrelevant quips are just as invalid as providing no reason at all.
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(s) at any time, but the final decision to remove another user's vote lies solely with the wiki staff.
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.
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 "(blocked)" 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.
If one week before a proposal's initial deadline, the first place option is ahead of the second place option by eight or more votes and the first place option has at least 80% approval, then the proposal concludes early. Wiki staff may tag a proposal with "Do not close early" at any time to prevent an early close, if needed.
Tag the proposal with {{early notice}} if it is on track for an early close. Use {{proposal check|early=yes}} to perform the check.
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.
If a proposal reaches its deadline and there is a tie for first place, then the proposal is extended for another week.
If a proposal reaches its deadline and the first place option is ahead of the second place option by three or more votes, then the first place option must have over 50% approval to win. If the margin is only one or two votes, then the first place option must have at least 60% approval to win. If the required approval threshold is not met, then the proposal is extended for another week.
Use {{proposal check}} to automate this calculation; see the template page for usage instructions and examples.
Proposals can be extended a maximum of three times. If a consensus has not been reached by the fourth deadline, then the proposal fails and cannot be re-proposed until at least four weeks after the last deadline.
After a proposal passes, it is added to the appropriate list of "unimplemented proposals" below and is removed once it has been sufficiently implemented.[Proposal 6]
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 should ask for that help. Proposals that result in changes to policy pages or general guidelines must be cited accordingly.[Proposal 7]
All proposals are archived. Please note that canceled proposals must also be archived, including their date of cancellation.[Proposal 8]
Proposals can only be rewritten or canceled by their proposer within the first four days of their creation. If a proposer cancels their own proposal, they must provide a reason and wait three days before submitting any new proposal.[Proposal 9]
A proposer cannot cancel their proposal and then implement it anyway. Only wiki staff can cancel a proposal and immediately put it into effect.
Proposers can request their proposal be canceled by a wiki staff member after the self-cancellation cutoff, but they must provide a valid reason for doing so. In most cases, the proposal should simply run its course.
If the wiki staff deem a proposal unnecessary or potentially detrimental to the upkeep of the Super Mario Wiki, they have the right to cancel it at any time.
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.
Proposals cannot be made about promotions and demotions. Staff changes are discussed internally and carried out by the bureaucrats.
No joke proposals. Proposals are serious wiki matters and should be handled professionally. Joke proposals will be deleted on sight.
Proposal formatting
Copy and paste the formatting below to get started; your username and the proposal deadline will automatically be substituted when you save the page. Update the bracketed variables with actual information, and be sure to replace the whole variable including the square brackets, so "[insert info here]" becomes "This is the inserted information" and not "[This is the inserted information]". Proposals presenting multiple alternative courses of action can have more than two voting options, but the objective(s) of each voting option 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|{{subst:REVISIONUSER}}}}<br>
'''Deadline''': {{subst:#time:F j, Y|+2 weeks}}, 23:59 (UTC)
====[option title (e.g. Support, Option 1)]: [brief summary of option]====
#{{user|{{subst:REVISIONUSER}}}} Per proposal.
====[option title (e.g. Oppose, Option 2)]: [brief summary of option]====
====Comments ([brief proposal title])====
Autoconfirmed users will now be able to vote on your proposal. Remember that you can vote on your own proposal just like the others.
To vote for an option, just insert #{{user|[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 simply say "Per proposal".
Poll proposal formatting
As an alternative to the standard proposal format, users may choose to create a poll proposal when one larger issue can be broken down into multiple subissues that can be resolved independently of each other.[Proposal 10] Poll proposals concerning multiple pages must have good justification for using the poll proposal format rather than individual talk page proposals or else will be canceled (for example, in the case of the princesses poll proposal, there are valid consistency concerns which make it worthwhile to consider these three articles simultaneously, but for routine article size splits, there is no need to abandon using standard TPPs for each).
In a poll proposal, each option is essentially its own mini-proposal with a deadline and suboption headings. A poll proposal can have a maximum of 15 options, and the rules above apply to each option as if it were its own proposal: users may vote on any number of options they wish, and individual options may close early or be extended separately from the rest. If an option fails to achieve quorum or reach a consensus after three extensions, then the status quo wins for that option by default. If all options fail, then nothing will be done.
To create a poll proposal, copy and paste the formatting below to get started; your username and the option deadlines will automatically be substituted when you save the page. Update the bracketed variables with actual information, and be sure to replace the whole variable including the square brackets, so "[insert info here]" becomes "This is the inserted information" and not "[This is the inserted information]".
===[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|{{subst:REVISIONUSER}}}}
====[option title (e.g. Option 1)]: [brief summary of option]====
'''Deadline''': {{subst:#time:F j, Y|+2 weeks}}, 23:59 (UTC)
;Support
#{{user|{{subst:REVISIONUSER}}}} Per proposal.
;Oppose
====[option title (e.g. Option 2)]: [brief summary of option]====
'''Deadline''': {{subst:#time:F j, Y|+2 weeks}}, 23:59 (UTC)
;Support
#{{user|{{subst:REVISIONUSER}}}} Per proposal.
;Oppose
====[option title (e.g. Option 3)]: [brief summary of option]====
'''Deadline''': {{subst:#time:F j, Y|+2 weeks}}, 23:59 (UTC)
;Support
#{{user|{{subst:REVISIONUSER}}}} Per proposal.
;Oppose
====Comments ([brief proposal title])====
For the purposes of the ongoing proposals list, a poll proposal's deadline is the latest deadline of any ongoing option(s). A poll proposal is archived after all of its options have settled, and it is listed as one single proposal in the archive. It is considered to have "passed" if one or more options were approved by voters (resulting in a change from the status quo), and it is considered to have "failed" if all options were rejected by voters and no change in the status quo was made.
Proposals concerning a single page or a limited group of pages are held on the most relevant talk page regarding the matter. All of the above proposal rules also apply to talk page proposals. Place {{TPP}} under the section's heading, and once the proposal is over, replace the template with {{settled TPP}}. Proposals dealing with a large amount of splits, merges, or deletions across the wiki should still be held on this page.
All active talk page proposals must be listed below in chronological order (new proposals go at the bottom) using {{ongoing TPP}}. Include a brief description of the proposal while also mentioning any pages affected by it, a link to the talk page housing the discussion, the proposal author(s), 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.
Talk page proposal formatting
==[insert a title for your proposal here]==
{{TPP}}
[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|{{subst:REVISIONUSER}}}}<br>
'''Deadline''': {{subst:#time:F j, Y|+2 weeks}}, 23:59 (UTC)
===[option title (e.g. Support, Option 1)]: [brief summary of option]===
#{{user|{{subst:REVISIONUSER}}}} Per proposal.
===[option title (e.g. Oppose, Option 2)]: [brief summary of option]===
===Comments ([brief proposal title])===
==[insert a title for your proposal here]==
{{TPP}}
[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|{{subst:REVISIONUSER}}}}
===[option title (e.g. Option 1)]: [brief summary of option]===
'''Deadline''': {{subst:#time:F j, Y|+2 weeks}}, 23:59 (UTC)
;Support
#{{user|{{subst:REVISIONUSER}}}} Per proposal.
;Oppose
===[option title (e.g. Option 2)]: [brief summary of option]===
'''Deadline''': {{subst:#time:F j, Y|+2 weeks}}, 23:59 (UTC)
;Support
#{{user|{{subst:REVISIONUSER}}}} Per proposal.
;Oppose
===[option title (e.g. Option 3)]: [brief summary of option]===
'''Deadline''': {{subst:#time:F j, Y|+2 weeks}}, 23:59 (UTC)
;Support
#{{user|{{subst:REVISIONUSER}}}} Per proposal.
;Oppose
===Comments ([brief proposal title])===
Overhaul present merchandise coverage (discuss) by Nelsonic; Deadline: November 18, 2026, 23:59 (UTC)
Split physical appearances of Super Mario characters and objects from the Lists of references into a List of appearances in third-party media (discuss) by Nelsonic; Deadline: November 20, 2026, 23:59 (UTC)
Split unique levels appearing in browser games into their own articles (discuss) by Nelsonic; Deadline: November 20, 2026, 23:59 (UTC)
Require the use of lang tag for text with CJK characters
This concerns a matter that is more subtle to average readers and editors, but is a long-running issue that would undoubtedly be helpful for the wiki if solved.
Here is some background information for those unfamiliar with the topic. CJK characters, also called Han characters, are the graphemes used in Chinese (漢字 / 汉字, Mandarin hanzi), Japanese (漢字kanji), Korean (漢字hanja), and some other languages. The digitalization of CJK characters was a difficult task, where myriads of these characters have to be encoded as code points. Due to technological constraints back then, a decision to encode multiple regional variants into one single code point in Unicode was executed, as long as they have the same etymological root and abstract meaning (and no regional standards have differentiated them before). This process is known as Han unification. The responsibility of displaying a specific preferred variant of the character in a language, therefore, is shifted to the typeface used.
Nowadays, the display of multilingual characters, such as names in other language or quotes in other localizations as documented on this wiki, still relies on Unicode. For most languages, the specific form of glyphs is not a problem (or is not enough to constitute a significant problem). But for languages using CJK characters as logographs, the specific form of a glyph is of concern for the languages. Yet the unification of code points mean that your computer would not automatically know that a sentence is supposed to use the specific shape of a character in a particular context - unless we manually specify the language the passage is in, in which the device would render the character using a font of the specific language, allowing it to show up properly. The problem is that a lot of people (who are not native speakers of these languages) do not do this because they do not realize it, resulting in inaccuracies in the display of these languages. These inaccuracies, while minor when viewed in isolation, can build up significantly across multiple characters and across passages. I will follow with a couple of examples; feel free to zoom in to examine each characters carefully.
The font fallback for most users would cause the CJK characters to fall back to the orthography by the PRC. Then, if we do not specify the text language as Japanese, the Japanese name of Tadashi Sugiyama杉山 直 would be rendered as 杉山 直. Notice how the form of 直 (U+76F4) is highly different, and how the form of 山 (U+5C71) becomes asymmetrical - a form commonly seen in mainland China, but never in Japan's printed forms.
Conversely, those who are learning Japanese, as well as native speakers of Japanese, might have their font fallbacks adjusted such that CJK characters are rendered as Japanese by default. Then the opposite problem occurs. Consider the passage in simplified Chinese:
齐心协力制作苹果汁吧。将分为3个队伍："采苹果"、"装瓶"、"装车"。
If we do not specify that this passage is in simplified Chinese, then the passage would be displayed as such to them:
齐心协力制作苹果汁吧。将分为3个队伍："采苹果"、"装瓶"、"装车"。
The shapes of some characters, especially on 苹 (U+82F9) and 将 (U+5C06) are different from the convention used in simplified Chinese. In addition, Japanese fonts do not support most simplified characters such as 齐, 协 and 队, resulting in the passage being rendered as a mishmash of two system fonts from two regions (which can range from looking normal to very weird, depending on how well the two system fonts "harmonize" with each other on your device).
The above are just the tip of the iceberg regarding the Han unification situation. These difference in orthographies across regions can be seen everywhere across common characters, and can range from the following:
Subtle differences, such as whether the direction of dot strokes is vertical or slanted, and whether some strokes touch each other or not (e.g. 立 / 立U+7ACB, 護 / 護U+8B77).
Significant differences, such as the addition or removal of a stroke, or the placement of strokes (e.g. 漢 / 漢U+6F22, 謎 / 謎U+8B0E, 誤 / 誤 / 誤 / 誤U+8AA4).
The entire shape of the glyph being different (e.g. 直 / 直 (U+76F4, 祗 / 祗U+7957, 瑜 / 瑜U+745C).
Below are some differences in glyph shapes according to regional standards or norms:
Language
Text
Chinese (Taiwan MoE)
骨刃令直麻茨雪週逾龜
Chinese (HK Education)
骨刃令直麻茨雪週逾龜
Chinese (Mainland)
骨刃令直麻茨雪週逾龜
Japanese
骨刃令直麻茨雪週逾龜
Korean
骨刃令直麻茨雪週逾龜
Even if counting only the notable differences in glyph shapes between Taiwan and HK's orthographies (more specifically their educational forms) - which are thought to be highly similar to each other - as much as 12.34% of the commonly used characters have significant orthography differences between the two regions, and 23.88% of them have subtle differences. Do remember that most of these differences are unified as single code points in Unicode. This is not even considering the orthographies of other regions, which are more different in other ways.
As noted above, since CJK characters are logographs, the specific form of a glyph is an important concerns for the languages. As the code points of CJK characters do not give information about the language the text is in, we can solve the problem by enclosing CJK text in lang tag, most commonly on this wiki by using the lang template. The way lang tags work is to internally specify the language the enclosed text is in, which allows your browser to prioritize rendering the text in the specified language's font. See the source code of this proposal for a few examples. The lang tag is already applied to text displayed in templates like Foreign names and Cite. However, in running text, many editors do not use the lang tag, resulting in the same character being displayed differently in different locations (even if they are in the same language), which can either confuse or mislead readers.
This proposal would thus be about requiring the use of the lang tag to enclose Chinese, Japanese and Korean text whenever CJK characters are involved in the text, similar to how Wikipedia requires the use of the lang template. CJK characters that are included as part of a text in a particular language should be marked using the corresponding ISO code (or, in the case of traditional Chinese, marked to the corresponding regional orthography according to the documentation of the lang template).
Of course, given the sheer amount of Japanese text already documented on the wiki, to tag all Japanese text appropriately would be more than an uphill task. If the proposal succeeds, then we can simply tag any existing untagged text when we come across any, as well as tag any new text we add that includes CJK languages. It is more beneficial for us to address this now instead of waiting for later.
Proposer: Dominoes (talk) Deadline: November 25, 2026, 23:59 (UTC)
Create a fact backlog page for Template:DidYouKnow
There was a recent failed proposal to create a pool of facts for Template:DidYouKnow via Discord DMs or a spreadsheet managed by an appointed user. I agree with the opposing voters that this is too much off-wiki work and bureaucracy for the issue, but I do still believe that there is an issue here, and a different, more casual solution is possible. As it stands, whoever updates the DYK template essentially has to come up with four interesting facts on the spot, while making sure they do not focus too much on a specific series. This essentially makes it impossible for someone like me to contribute, as although my head is full of Mario Fun Facts, they are overwhelmingly focused on Super Mario Maker and adjacent Super Mario games.
My proposal is to create a new, on-wiki page - I imagine something like "Template:DidYouKnow/suggestions" which could be linked to on the parent template page - where users can write out any number of facts at any time, essentially forming a backlog of facts. Users are free to modify the list without any special restrictions. If a fact someone submitted doesn't seem up to snuff, such as being too "Super Mario 64 is a popular game"-y, it can just be removed from the list or edited. Images could be included in contributed facts if they provide further illustration, but should be lower priority than standalone facts as only one image can be used per DYK set. (Such facts should also use <br> to keep the list organized) Since the template explicitly requires the facts come from a variety of series, the list can be initially sorted into groups for Super Mario, Yoshi, Donkey Kong, Wario, and miscellaneous facts so that editors can pick from each one. Further granularity could be added later on if the backlog grows too much.
When it comes time to update the template, whoever decides to may look at the page and take facts from it, come up with their own facts like it is currently, or even do both. After using a fact from the list, the editor should then delete it to indicate its no longer in the backlog and shouldn't be reused. Under this system I would be freely able to add my Mess of Maker Minutiae to the list, as would someone else who knows a lot about a different sub-series, and our collective knowledge would still be able to contribute to the Main Page while retaining the variety the template requires.
Proposer: PopitTart (talk) Deadline: November 29, 2026, 23:59 (UTC)
Xiahou Ba, The Nasty Warrior (talk) This is a much better set-up than what we currently have. It makes it easier for people to pool down their ideas in a convenient spot and remember to put it for later when Saturday comes up, and this would work similarly to our upcoming FA list, except this would probably be even more useful than that because you can already tell what's coming up for FAs because they're queued by their featured date. My biggest feedback would be asking how it's organized (right now, seems to be just series), but we'll see how this plays out so we can adjust and edit accordingly these lists.
Illuminoid (talk) Per all. This will make the template much more collaborative with its facts.
Iand255 (talk) Per all. As someone who has wanted to contribute to the DYK for a while, but hasn't been able to, this is the exact type of solution solves the issues that were barring me from doing such.
Oppose - No DYK Pool
Did You Know? Comments give commentary
Changes
Reword infobox image guidelines to allow miscellaneous renders and upcoming games
Based on the vote so far, this proposal may be eligible to close one week early. Please use {{proposal check|early=yes}} on November 16, 2026 at 23:59 (UTC) and close the proposal if applicable.
I know we have a lot of ongoing infobox proposals right now, but what's one more?
This proposal concerns the images used for infoboxes (mainly {{character infobox}} and {{species infobox}}, along with any other applicable one). For years, our guidelines for images in infoboxes state that the image used should be "ideally, artwork from the most recently released game". It intentionally excludes upcoming releases due to possibility of the subject depicted changing prior to its release. I believe that may be a somewhat outdated fear, and it hasn't happened in any release I can think of. The rule is also inconsistently applied regarding new subjects. The page for Snoutlet was made many months prior to the release of Mario & Luigi: Brothership, image included. If we're afraid Mario's design in that game might change, why not Snoutlet's? My point is, that hasn't happened nearly enough (or at all) to warrant this worry, and removing an outdated guideline helps streamline the editing process just a little bit.
The rule also has a secondary effect: By restricting the image to released games, it restricts the image to games entirely. This may have been an unintentional consequence of its wording, but it has been invoked in some cases. The reality is that generic promotional renders are often just as high quality as game-specific promotional renders, and both are often used interchangeably. A generic render might easily end up on a web page or blog post for a future game, just as easily as a game-specific render might eventually become Mario's main render on Play Nintendo. Here are a few examples (compiled by other users following a discussion on our Discord server) that I think are better representations of their subjects than our current infobox images:
Current infobox
Generic promotional image
Notes
The current image for Fire Mario comes from Super Mario Bros. Wonder. It features a shadow behind Mario, along with the simpler textures used in the game. The promotional render features a higher level of detail that matches Mario's design in newer releases since Super Mario Odyssey.
The current image for ground pound comes from a guide for Super Mario 3D World. It is ridiculously small, uses an in-game model as opposed to a high quality promotional one, and in my opinion has a somewhat awkward pose. The promotional render is higher quality, matches the level of detail seen from modern renders and has a stronger pose overall. While some may think the presence of the blocks detracts from the image, I think they serve an important purpose in contextualizing that the ground pound move is an attack targeted downwards, conveyed a lot better than against a transparent void.
This one might be more of a nitpick. The current image for Mario is perfectly fine. Both renders have a similar level of quality and detail, but the generic promotional render features him in, arguably, his most famous pose. The quintessential Mario jump. It's just more iconic than his presenting pose. As a side note, it amuses me that the game render is named "MarioAlternate
