MarioWiki:Proposals

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

Current time:
January 20, 2026, 15:02 (UTC)

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.
  • For past proposals, see the proposal archive and the talk page proposal archive.

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.

How to

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

  1. Only autoconfirmed users may create or vote on proposals. Proposals can be created by one user or co-authored by two users.[Proposal 1]
  2. A given user may author/co-author a maximum of five total ongoing/unimplemented proposals. Any new proposals over this limit will be immediately canceled.
  3. Anyone is free to comment on proposals (provided that the page's protection level allows them to edit).[Proposal 2]
  4. 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).
  5. Proposals cannot contradict an already ongoing proposal or overturn the decision of a previous proposal that concluded less than four weeks (28 days) ago.
  6. Proposals must have a status quo option (e.g. "Oppose", "Do nothing") unless the status quo itself violates policy.
  7. 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]
  8. 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.
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. If a proposal reaches its deadline and there is a tie for first place, then the proposal is extended for another week.
  14. 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.
  15. 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.
  16. 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]
  17. 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]
  18. For sizeable projects, a proposal author or wiki staff member may create a PipeProject page to serve as a portal for an unimplemented proposal. This is linked from the unimplemented proposals list and can contain progress tracking, implementation guidelines, resource links, a list of users working on the project, etc.
  19. All proposals are archived. Please note that canceled proposals must also be archived, including their date of cancellation.[Proposal 8]
  20. 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 wait three days before submitting any new proposal.
  21. Proposers can request their proposal be canceled by a 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.
  22. 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.
  23. 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.
  24. Proposals cannot be made about promotions and demotions. Staff changes are discussed internally and carried out by the bureaucrats.
  25. No joke proposals. Proposals are serious wiki matters and should be handled professionally. Joke proposals will be deleted on sight.

Basic 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 basic 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 9] 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.

Relevant discussions

Talk page proposals

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.

List of ongoing talk page proposals

Deletions

None at the moment.

Moves

Merges

Splits

Miscellaneous

Unimplemented proposals

Proposals

Break alphabetical order in enemy lists to list enemy variants below their base form, EvieMaybe (ended May 21, 2024)
Standardize sectioning for Super Mario series game articles, Nintendo101 (ended July 3, 2024)
Note: Not yet integrated for the Super Mario Maker titles and Super Mario Run.
Use the classic and classic link templates when discussing classic courses in Mario Kart Tour, YoYo (ended October 2, 2024)
Split major RPG appearances of recurring locations, EvieMaybe (ended December 16, 2024)
Note: Implemented for all except Bowser's Inside Story's Bowser's Castle and Kingdom Battle's Peach's Castle
Split Mario & Luigi badges and remaining accessories, Camwoodstock (ended February 1, 2025)
Merge intro/outro sections, rename Gameplay section to "Overview" for Mario Party minigame articles, ToxBoxity64 (ended March 1, 2025)
Note: Not yet implemented in any Mario Party game, except Mario Party 8
Allow English Super Mario Bros. Encyclopedia names to be mentioned on articles where they are not the title, Hewer (ended March 27, 2025)
Split every song from the "List of (show) songs" articles, Kaptain Skurvy (ended May 31, 2025)
Overhaul sponsor pages, Seandwalsh (ended June 26, 2025)
Reorganize recurring theme articles to use history sections, Ahemtoday (ended July 2, 2025)
Permit creation of categories based on microgame themes, PawPatroler (ended August 3, 2025)
Revamp colorful tables, Camwoodstock (ended August 14, 2025)
Make articles for the licensed songs in The Super Mario Bros. Movie, Sargent Deez (ended September 17, 2025)
Change game quote lists to game scripts, Scrooge200 (ended September 21, 2025)
Create an article for Gourmandise, Sargent Deez (ended October 4, 2025)
Stop using icon-based level names for Super Mario Bros. 3, PopitTart (ended October 21, 2025)

Talk page proposals

Split all the clothing, Doc von Schmeltwick (ended September 12, 2021)
Note: Not yet split for Partners in Time, Bowser's Inside Story, Dream Team, Paper Jam, and Brothership
Make bestiary list pages for the Minion Quest and Bowser Jr.'s Journey modes, Doc von Schmeltwick (ended January 11, 2024)
Allow separate articles for Diddy Kong Pilot (2003)'s subjects, Doc von Schmeltwick (ended August 3, 2024)
Create articles for specified special buildings in Super Mario Run, Salmancer (ended November 15, 2024)
Note: Missing Rainbow Bridge, Red Bonus Game House, Blue Bonus Game House, and Yellow Bonus Game House articles.
Give the Cluck-A-Pop Prizes articles, Camwoodstock (ended January 31, 2025)
Split the Animal Crossing series (now Crossovers with Animal Crossing), Kaptain Skurvy (ended February 12, 2025)
Split Super Luigi subjects into a dedicated list article (Draft page), EvieMaybe (ended April 3, 2025)
Clean up Prohibited Command, PrincessPeachFan (ended May 13, 2025)
Determine which subjects belong in Category:Aliens, Technetium (ended June 14, 2025)
Note: Not yet implemented for Super Mario Galaxy and Super Mario Galaxy 2 subjects.
Split A Magical Tour of Yoshi's Island from Super Mario World 2: Yoshi's Island, Rykitu (ended July 9, 2025)
Decide how to handle hammer-based moves in Category:Hammers, SolemnStormcloud (ended July 21, 2025)
Treat Pyoro as a series, janMisali (ended September 1, 2025)
Determine whether a Final Smash is one of a fighter's special moves, Salmancer (ended September 13, 2025)
Split Challenge, VS. Game/You VS. Boo, the Album and the Toy Box + its individual toys from Super Mario Bros. Deluxe, Snessy (ended December 23, 2025)
Decide whether to use title case in English meanings of foreign names where applicable when not present in the source language, PaperSplash (ended December 26, 2025)
Merge Bob-omba, Goombob and Hulu with Bob-omb Buddy, Galoomba and Bamboo Dancer respectively, Snessy (ended December 30, 2025)
Treat courses that debuted in Mario Kart Tour and Mario Kart 8 Deluxe as Tour and 8 Deluxe courses respectively, Polterpup (ended January 1, 2026)
Determine the scope of Mini Rocket, EvieMaybe (ended January 9, 2026)
Consider "LUCKY" misses from the Paper Mario series to be a game mechanic, Pizza Master (ended January 13, 2026)
Tighten Toad, DesaMatt (ended January 17, 2026)
Move Wakkiki info to Akiki, FanOfYoshi (ended January 17, 2026)

Writing guidelines

Establish a "character article" structure

This proposal is partially inspired by Nintendo101's proposal to standardize sectioning for Super Mario series game articles.

While our character articles largely already follow a decent structure, they aren't entirely consistent with each other. We have their creation, their history, their general information, then... everything else?... and then a nice and easy Naming, Notes, See also and finally References and sometimes External Links. Everything between the "General information" and "Naming/Names in other languages" sections is vaguely defined and usually varies in at least some way between articles. This also includes subsections of "General information". Mario and Luigi have their "List of game appearances" and "Profiles and statistics" swapped. Bowser has "Portrayals" between both of them. Mario and Princess Peach have sections about their most recurring themes in different places. Luigi also has his "See also" in the middle of the article between "Quotes" and "Voice samples", and had two creation sections until I merged them. Rosalina has her "List of appearances" all the way at the bottom.

Not to mention the inconsistent section names themselves. Sometimes "Creation" is "Creation and development", sometimes it is "Concept and Creation". "List of appearances" can also be "List of game appearances" and "List of appearances by date", among others.

So that's why I'm here. The aim of this proposal isn't to demand that every article have these sections but, but to provide a structure for the sections an article already has. For sections that are specific to only a few characters, their positioning can be decided on a case-by-case basis, such as Mario's cultural impact or Donkey Kong's identity. Without further ado, here's my proposed character article structure guideline, with further notes detailing wiggle room between them:

  1. Creation: Presented first since it covers how they were first conceptualized and created.
  2. History: The main bulk of information in most articles its own sub-structure is already well established in our guidelines.
  3. General information: Usually the second largest section, and usually also divided into its own subsections
    1. Physical description: Perhaps the most objective, apparent and easy to glance information about a character. Should always come first unless a character needs a section talking about their overall identity as a whole, such as Donkey Kong's. Per article needs, can also have its own sections such as Alternate outfits.
    2. Personality: Should always follow physical description.
    3. Speech: Not the most common section to have, but a character's speech is almost always determined by their personality, physical appearance, or both, hence its placement here.
    4. Power and abilities: I don't have a strong reasoning for this section, but it ended up here and it feels like a natural progression from talking about how a character looks and acts.
    5. Other subsections: Other miscellaneous sections can fall here, such as Theme(s), Occupations, Gender, etc. Decided per article needs.
    6. Relationships: How a character relates to other characters should be the last subsection, as it no longer pertains to just the character itself. Relationship subsections generally go from family, to friends, to enemies.
  4. Profiles and statistics: As profiles and statistics are kind of official "general information" about a character, this section follows it in the structure. Marks the start of the chunk of the article where lots of lists in various forms go.
  5. Gallery: Not much to say, it falls here as it is one of the "big list sections"
  6. Portrayals: Which actors and voice actors have portrayed a character should go close to the list of voice lines of that character, along with quotes they might've recorded themselves.
  7. Quotes: See above.
    1. Voice samples: Contained within quotes as it is a very simple section by itself.
  8. List of appearances: Usually one of the longest pages without much information. Placed at the bottom, out of the way of most of the article.
  9. Naming/Names in other languages: Unless it relates to another section, information on their names should be moved here. If the name is related to a character's creation then it can be included in the top section instead, for example. By now everything is generally as you'd expect it. Not much else to say.
  10. Notes: See above.
  11. See also: See also above.
  12. References: See above. Although unlikely to happen for characters, External Links would go below this section.

Once again, I'd like to emphasize that this structure is meant as a general guideline for the order of existing sections, and does not imply the creation or removal of any section. Character articles are often tailored to emphasize different aspects of them, so this proposal hopefully ensures a consistent standard while allowing room for variation when necessary. A big thank you to users in our Discord server who offered their feedback while I made this structure.

Proposer: LadySophie17 (talk)
Deadline: February 3, 2026, 23:59 (UTC)

Support: Establish the structure

  1. LadySophie17 (talk) Per proposal.
  2. EvieMaybe (talk) per proposal
  3. The Dab Master (talk) Per proposal.

Oppose: Status quo

Comments (Character article structure)

Before voting, I have a question: what will happen to the Battle section used on some boss pages? Sorbetti Sorbetti Sorbetti (talk) 15:02, January 20, 2026 (UTC)

Removals

None at the moment.

New features

None at the moment.

Changes

Limit the amount of game series logos in their infoboxes to one

I have noticed a major inconsistency with some of the game series pages, and that their infoboxes have multiple logos, whether to represent the multiple eras, different formatting, or both. While most game pages have only one logo in their infobox, some of them have multiple logos, creating a weird inconsistency, not to mention that only showing the latest version of the logo in the infobox would be enough to get readers to understand the franchise.

This proposal will aim to limit the amount of logos in their infoboxes to just one, and extra logos will be moved to the gallery. This will not only remove unneeded bulk from the infoboxes, but would also make them consistent with each other. Extra logos, like alternate formatting and historical logos, are important enough to keep on the page, but only in the gallery where they don't take up the main bulk of the page.

"But Altendo, these logos signify different eras of a game series and can give a look at the past!" Well, they can still get that look through the gallery, but even if this argument is taken into account, it still wouldn't be consistent. Take Mario Party (series), in which the logo used for the first three games and would inspire the logo for the future Hudson Soft-era games isn't even on the page. And don't even get me started with Super Smash Bros. (series), which has five logos, yet only the one used for Super Smash Bros. Ultimate is in the infobox.

The affected pages include:

Hopefully this will lead to more consistent series infoboxes without any additional bulk (good god, Donkey Kong Country has THREE logos).

Proposer: Altendo (talk)
Deadline: January 24, 2026, 23:59 (UTC)

Move all of the extra logos to the gallery

  1. Altendo (talk) Per proposal.
  2. Yoshi18 (talk) Per proposal.
  3. Wandering Poplin (talk) Especially for any series that might've never had a consistent logo to begin with. (Not that I can think of any at the moment...)
  4. Camwoodstock (talk) Makes sense to us. Per proposal.
  5. SuperGamer18 (talk) Per all.
  6. Mario (talk) The extra logos only serve to clutter the infobox. There may be special cases but I don't think they're enough to undermine the guideline being proposed here.
  7. Mushroom Head (talk) Per all.

Move only the historic logos to the gallery, but leave the alternate formatting intact

  1. Altendo (talk) Second choice.
  2. Yoshi18 (talk) Second choice.

Do not move logos

NUKE: Bring ALL of the logos into the infobox

  1. Yoshi18 (talk) Tertiary choice.

Logo comments

Change the order of media navigation templates at the bottom of pages

True story: Category:Super Smash Bros. series objects is oddly empty. There are like, 22 different stages within our purview as a wiki (inexact count), including monstrosities that are full of distinct objects like Super Mario Maker (stage), Rainbow Cruise, Golden Plains, and 3D Land. (Curse you scrolling and randomized stages!) There's no way there are only 30 or so objects that already have articles on the wiki that have appeared at least once in Super Smash Bros. So on October 10, 2025 I added about 14 more... then got too agitated to continue. Why?

Okay, so adding game categories to articles is dead simple: place the new category with the existing categories such that alphabetical order is maintained. Everyone understands that. But when I was adding the Smash object category, I also had to add the corresponding navigation template for each Super Smash Bros. game, since obviously interactive objects are important enough to have each game's navigation template even if they are not being listed within the navigation template. Let me tell you, adding a series worth of navigation templates to pages is a colossal pain. Navigation templates are placed on articles in the order of the release dates for each game. This means, to place the one to three navigation templates most of these articles required, I had to flick between the articles for the Super Smash Bros. games and games released around their release dates to make sure I was getting the order right. This was taking several orders of magnitude of forever, and I hate when things take forever. Admittedly, it would have taken a couple fewer forevers if I remembered List of games by date exists, so I would have only needed to use the Find tool to scroll up and down and all around one page, but that's still one forever too many.

Drawing board: Every Super Mario Wiki article has three different game orders to keep in mind when adding to it:

  • History sections: MarioWiki:Manual of Style#History defines that each article's History section is ordered in two tiers. Series headers are placed in chronological order, with the date for each series being the first entry in that series the subject is featured in. Then, underneath series headers, the headers for each piece of media for that are in chronological order.
  • Categories: MarioWiki:Categories#Order on pages says that categories regarding media should be placed in alphabetical order
  • Navigation templates and Gallery images: MarioWiki:Navigation templates#Order on pages says that navigation templates for media should be placed in chronological order, with no tiering like History sections use. Galleries for articles work identically regarding the order their images should be placed, though I could find no corresponding policy.

I think that keeping track of three different orders is too much for the average wiki user, let alone me, and so I think we should change navigation templates to use one of the other two orders. (Yes this means that articles would still have three orders overall, but galleries benefit from strict chronological ordering because something's visual depiction in one series can very easily directly affect its visual depiction in a different series. Therefore, having galleries maintain strict chronological order is worth the cost of them using an order system that the rest of the wiki does not use.

Pros and cons of navigation template orders
V> Pros Cons
Chronological series, then chronological media
  • Wiki editors know this order by heart
  • Easy to add to as long as the relevant media just released or an entry in the series already has a navbox on the article
    • It is more likely for an editor adding content about media to an article to forget to add its navboxes than forget to add its History section, meaning an editor going through adding navboxes would be able to use the History section as a refererence for correct navbox order.
  • Navboxes for media in the same series always stay together
  • Could allow for navboxes for the same series to be hidden within a dropdown for that series, making articles with a large number of navboxes more manageable without having to use Template:Navboxes as quickly.
    • Especially useful if the majority of an article's navboxes are for a single series, because then with a series specific dropdown for the offending series Template:Navboxes would not be necessary to use. This would make the navboxes unreleated to that series faster to access for the readers that need them, but not make accessing the navboxes for that series and slower to access than the current system.
  • Not intuitively understood
Alphabetical
  • Intuitively understood
  • Extremely easy to add to
  • Navboxes for media in the same series are usually kept together
  • Sometimes grouping is broken up by Nintendo's... quirkiness when naming their products
  • Gets harder to add to when more media with similar names are released.
Strict chronological (current)
  • Intuitively understood
  • Easy to add to if the relevant media just released
  • Hard to find specific games at times. While the coloring of navigation templates by series is supposed to help with this, it does not succeed on articles with a lot of navigation templates.
  • Hard to add to if the relevant media did not just release, as in my Super Smash Bros. series anecdote.

Changing the order that media navigation templates are listed on pages will make it easier to add such templates to pages that mistakenly do not have them, which will make more people able and willing to do this wiki busywork. For instance, if this proposal passes, I would be able to finish categorizing all of the Super Smash Bros. series objects without it taking an inordinate amount of time compared to the comparatively not very impressive result of having a fully populated category. (Okay, technically I could just add the categories to the articles without adding the navboxes, but I dislike doing jobs halfway so therefore I cannot.)

Proposer: Salmancer (talk)
Deadline: February 2, 2026, 23:59 (UTC)

Support: Media navigation templates are placed in an order matching History sections

  1. Salmancer (talk) This proposal isn't just me trying to shirk work, honest! I just don't want to have "adding navboxes" be a task best performed by first memorizing the release dates of games relevant to the wiki. Plus, this change would make the wiki able to make navbox dropdowns specific to each series, which is a legitimate improvement over the current "if there are 10+ navboxes, hide all of them under Template:Navboxes."
  2. The Dab Master (talk) Per Salamancer
  3. EvieMaybe (talk) i wasn't sold, until you mentioned being able to collapse groups of navboxes by series. very much into this now
  4. LadySophie17 (talk) I like the idea, but I'd like clarification on when would series navboxes be collapsed, and what would happen if there are still 10+ rows of navboxes left in an article after series are collapsed.

Support: Media navigation templates are placed in alphabetical order

Status Quo: Media navigation templates remain ordered strictly chronologically

  1. Hewer (talk) I'm not really seeing the issue here. I personally think chronological order for all games without having to worry about series classifications is much more intuitive and straightforward. You claim that "wiki editors know this order by heart" but personally I don't find this to be the case, I'd find strict chronological order more memorable (especially since it's always the same order, whereas the series order changes for each subject due to how it lists the series in the order that particular subject first appeared in them). If you don't know what order the games should go in when adding them, just look at List of games by date and all your problems are solved. And if you want to just look at navboxes of one series, you can do that fairly easily since they're colour-coded by series. History sections are different because the way they are written often assumes the reader to be familiar with the subject's previous appearances in that series (e.g. saying that an item works the same as it did in previous games without elaborating), which would be unreasonable if the sections for one series weren't all kept together; navboxes don't have this quirk.

Comments (Change the order of media navboxes)

End the use of "new course" and "classic course" as universal definitions within the Mario Kart series

With the introduction of the Mario Kart 8 Deluxe – Booster Course Pass came Mario Kart courses which debuted in one game, but are known to have originally been developed for another. For example, data relating to Sky-High Sundae in both Mario Kart 8 Deluxe and Mario Kart Tour is labeled to suggest that it actually originates from the latter. Likewise, despite debuting in 8 Deluxe and Nintendo acknowledging 8 Deluxe as Sky-High Sundae's first appearance, Nintendo has also referred to all courses in the Booster Course Pass as "remastered courses". This has resulted in the definition of a "new course" becoming significantly less clear than it was previously (an issue which was also the subject of another recent proposal).

Likewise, the definition of a "classic course" also became muddied as Nintendo chose to not include returning Mario Kart Tour courses Merry Mountain, Ninja Hideaway and Piranha Plant Cove in that category (as evidenced by their lack of in-game prefixes and exclusion from the associated Nintendo Music playlist). Since Mario Kart: Super Circuit, there has been a trend of bringing back courses from previous titles, with each game using its own Nintendo-derived labels and terminology (such as "Extra Tracks" in Super Circuit and "retro courses" in Mario Kart 7). From Mario Kart 8 onwards, the line between returning courses and brand-new ones has become less and less clear, with Mario Kart World going as far as having no direct in-game distinction between returning courses and new ones.

With all of that in mind, I believe it no longer makes sense to rely entirely on such terms when they are either lacking the necessary nuance or are ultimately defined at Nintendo's discretion.

With this in mind, the goals of this proposal are as such:

  • Redirect the New course and Classic course pages to the existing Course (Mario Kart series) page and include all relevant information there. The latter page already offers a sufficient overview of all courses across every title both debuting and returning.
  • Use appropriate terminology depending on the courses and/or games in question, with official terminology such as "classic courses" only being used when its use verifiably applies to the situation (Mario Circuit 3 is an Extra Track in Mario Kart: Super Circuit, SNES Mario Circuit 3 is a classic course in Mario Kart 8 Deluxe, Ninja Hideaway is a returning course in Mario Kart 8 Deluxe, Sky-High Sundae first appeared in the Mario Kart 8 Deluxe – Booster Course Pass and later appeared in Mario Kart Tour).

A notable example of what I mean by "verifiably applies" in the latter point is with Block Fort in Mario Kart DS. Mario Kart DS itself makes no distinction between it and the new battle courses, in stark contrast to the race courses in the "Retro Grand Prix" (which one can reasonably refer to as "retro courses", or "classic courses" as they have been called in promotional material). As a similar case to the previously mentioned Ninja Hideaway, we would generally refer to it as a "returning course" rather than using specific official terminology, unless evidence is provided to support using said terminology.

Proposer: Polley001 (talk)
Deadline: February 2, 2026, 23:59 (UTC)

Support: Define courses on a case-by-case basis

  1. Polley001 (talk) Per proposal.
  2. The Dab Master (Switch/Tour) Per proposal.
  3. LadySophie17 (talk) Can't believe I'm here but I agree. It's natural for a wiki to have a tendency to "over-categorize" things that seem to fit within certain definitions, and it definitely irked me how the Extra courses from Mario Kart: Super Circuit were lumped in with the classic courses. Like our previous proposal to axe classic prefixes from page names, I think this change in mindset will go a long way to shifting the perception of what a classic course is. On that note I apologize for being somewhat bull-headed about this topic in the past, but this has given me some clarity.
  4. Tails777 (talk) Still have my support here. I don't think we need a concrete dividing line to live by here; Nintendo has become far more loose with the distinction between new courses and classic courses and Mario Kart World was the final nail in the coffin. I feel not much else needs to be said.
  5. Hewer (talk) This makes much more sense for organisation. I feel like "classic course" and especially "new course" have had no reason to be separate pages ever since the relatively recent development of the Course (Mario Kart series) page being created, which would be a handy centralised page to hold all the information.
  6. Altendo (Switch/Tour) Per all.
  7. Mushroom Head (talk) Per all.
  8. EvieMaybe (talk) per all. our coverage of games should be descriptive, not prescriptive.
  9. DS Kingoffire U (talk) Sure, why not.

Oppose: Define courses using the existing binary system

Comments (Mario Kart course definitions)

Back in 2023, a proposal passed to create Mario Kart course redirects with game prefixes for any course that lacks them, with the exceptions of Mario Kart 8, the Mario Kart: Arcade GP series and Mario Kart Live: Home Circuit, due to them not having an established course prefix. What do you propose would happen to the redirects Tour Sky-High Sundae, Tour Squeaky Clean Sprint and Tour Yoshi's Island? — Lady Sophie_17 Wiggler Sophie.png(T|C) 21:51, January 19, 2026 (UTC)

I feel like they're probably popular enough with fans to warrant existing anyway, doesn't seem so different from how Intermission redirects to Route. Polley001 (talk) 21:58, January 19, 2026 (UTC)

Replace profiles with infoboxes for enemies and bosses from the Paper Mario series

This is something that has been bothering me for a long time and is about some enemies and bosses pages from the Paper Mario series. My problem lies in the inconsistency in which these pages are presented and some issues that they bring. A short example of my problem: why do Unicycle Shy Guys use an infobox for their page, but Animal Trainer Shy Guy doesn't use one? Why is Tape (boss) the only member of the Legion of Stationery that uses an infobox? These are some examples of this inconsistency that I have been noticing. But that is not all; the use of these enemy profiles does not provide good navigation. Look at the Hyper Bald Cleft page; it uses an infobox, and with that, I know in which games it appears, what enemies this one is a variant of, their notable members, and if it is a character or just common enemies. With all that info, I can navigate more easily through the pages, and I can understand the overall information better. But in the other case, with the Wild Dino Rhino page, I can't do any of that. And that doesn't make any sense, why use infoboxes on some pages and not on others? And if that were not enough, on mobile, the profile instead of an infobox doesn't look good and is too looooooong. I just want consistency between all these pages, and for that, I propose replacing all the pages of enemies and bosses that use profiles with infoboxes. With that, we are going to have consistency, better navigation, and a better mobile experience. So, just to understand the change that will be made, enemies and bosses that used profiles instead of an infobox will now use an infobox, and the profiles will be moved to Profiles and Statistics.

Proposer: Sorbetti (talk)
Deadline: February 3, 2026, 23:59 (UTC)

Support

  1. Sorbetti (talk) Per proposal.
  2. Hewer (talk) Sure.

Oppose

Comments

Miscellaneous

None at the moment.