MarioWiki:Proposals

Image used as a banner for the Proposals page

Current time:
Sunday, December 22^nd, 20:08 GMT

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 link to the 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. Anyone is free to comment on proposals (provided that the page's protection level allows them to edit).
Proposals conclude at the end of the day (23:59) two weeks after voting starts (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 two weeks later on Monday, August 15, at 23:59 GMT.
Users may vote for more than one option, but they may not vote for every option available.
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.
Proposals cannot contradict an already ongoing proposal or overturn the decision of a previous proposal that concluded less than four weeks (28 days) ago.
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.
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.
After a proposal passes, it is added to the appropriate list of "unimplemented proposals" below and is removed once it has been sufficiently implemented.
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.
Proposals can only be rewritten or canceled by their proposer within the first four days of their creation. However, proposers can request that their proposal be canceled by a staff member at any time, provided they have a valid reason for it. Please note that canceled proposals must also be archived.
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 handled by the bureaucrats.
No joke proposals. Proposals are serious wiki matters and should be handled professionally. Joke proposals will be deleted on sight.
Proposals must have a status quo option (e.g. Oppose, Do nothing) unless the status quo itself violates policy.

Basic proposal formatting

Below is an example of what your proposal must look like. If you are unsure how to set up this format, simply copy the following and paste it into the fitting section. When updating the bracketed variables with actual information, 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 GMT

====[option title (e.g. Support, Option 1)]: [brief summary of option]====
#{{User|{{subst:REVISIONUSER}}}} [make a statement indicating that you support your 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".

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 header, 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 {{TPP discuss}}. 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.

List of ongoing talk page proposals

Move Shadow (character) to Shadow (Sonic the Hedgehog) (discuss) Deadline: December 23, 2024, 23:59 GMT
Move "Rare Ltd." to "Rareware" or "Rare" (discuss) Deadline: December 25, 2024, 23:59 GMT
Make changes to List of Smash Taunt characters (discuss) Deadline: December 27, 2024, 23:59 GMT
Tighten Category:Deceased characters (discuss) Deadline: December 27, 2024, 23:59 GMT
Merge Cascading Stone, vanishing platform, and moon platform with Falling Platform (discuss) Deadline: December 28, 2024, 23:59 GMT
Add to-do tasks on the Main Page (discuss) Deadline: January 1, 2025, 23:59 GMT
Rename the NES Template (discuss) Deadline: January 4, 2025, 23:59 GMT
Merge the list of show hosts in All Night Nippon: Super Mario Bros. (discuss) Deadline: January 4, 2025, 23:59 GMT
Split the theme songs from the list of Donkey Kong Country (television series) songs (discuss) Deadline: January 5, 2025, 23:59 GMT

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, Super Mario Run, and Super Mario Bros. Wonder.

Create new sections for gallery pages to cover "unused/pre-release/prototype/etc." graphics separate from the ones that appear in the finalized games, Doc von Schmeltwick (ended September 2, 2024)

Add film and television ratings to Template:Ratings, TheUndescribableGhost (ended October 1, 2024)

Use the classic and classic-link templates when discussing classic courses in Mario Kart Tour, YoYo (ended October 2, 2024)

Clarify coverage of the Super Smash Bros. series, Doc von Schmeltwick (ended October 17, 2024)

Remove all subpage and redirect links from all navigational templates, JanMisali (ended October 31, 2024)

Prioritize MESEN/NEStopia palette for NES sprites and screenshots, Doc von Schmeltwick (ended November 3, 2024)

Stop considering reused voice clips as references (usually), Waluigi Time (ended November 8, 2024)

Allow English names from closed captions, Koopa con Carne (ended November 12, 2024)

^ NOTE: A number of names coming from closed captions are listed here.

Split off the Mario Kart Tour template(s), MightyMario (ended November 24, 2024)

Split major RPG appearances of recurring locations, EvieMaybe (ended December 16, 2024)

Talk page proposals

Split all the clothing, Doc von Schmeltwick (ended September 12, 2021)

Split machine parts, Robo-Rabbit, and flag from Super Duel Mode, Doc von Schmeltwick (ended September 30, 2022)

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)

Expand and rename List of characters by game to List of characters by first appearance, Hewer (ended November 20, 2024)

Determine how to handle the Tattle Log images from Paper Mario: The Thousand-Year Door (Nintendo Switch), Technetium (ended November 30, 2024)

Merge False Character and Fighting Polygon/Wireframe/Alloy/Mii Teams into List of Super Smash Bros. series bosses, Doc von Schmeltwick (ended December 2, 2024)

Writing guidelines

Determine a minimum number of glitches in a game to warrant a separate list article

I've noticed some strange discrepancies regarding how glitches are handled when a game has only 3 or 4 of them documented here. Wario Land 4 has a separate article for its 3 glitches (List of Wario Land 4 glitches), but every other game with 3 glitches simply has those glitches merged with the game's page. Specifically, Mario vs. Donkey Kong, Super Mario Strikers, Paper Mario: The Thousand-Year Door (Nintendo Switch), and, most glaringly, Wario Land 3 have sections for glitches rather than separate lists.

More complicated is figuring out how to deal with games with 4 glitches. Of the 6 games with 4 documented glitches:

4 of them have glitches merged into the main article: Super Mario World: Super Mario Advance 2, Donkey Kong Country: Tropical Freeze, Donkey Kong Land, Mario + Rabbids Kingdom Battle
2 of them have separate "List of glitches" articles: Mario vs. Donkey Kong: Mini-Land Mayhem!, Super Mario Advance

I put forward this proposal to determine a minimum number of glitches for the creation of "List of glitches" articles. That way, there is consistency between games with the same number of documented glitches. Additionally, if new glitches are documented later that brings the total number over this minimum, a new page can easily be created without the need for a proposal, as the editor can cite this proposal.

Option 1: The minimum number of glitches should be 3. "List of glitches" pages would be created for Mario vs. Donkey Kong, Paper Mario: The Thousand-Year Door (Nintendo Switch), and Wario Land 3 to match that of Wario Land 4.
Option 2: The minimum number of glitches should be 4. List of Wario Land 4 glitches would be deleted and its glitches merged into the main game's article. "List of glitches" pages would be created for Super Mario World: Super Mario Advance 2, Donkey Kong Country: Tropical Freeze, Donkey Kong Land, and Mario + Rabbids Kingdom Battle.
Option 3: The minimum number of glitches should be 5. List of Wario Land 4 glitches, List of Mario vs. Donkey Kong: Mini-Land Mayhem! glitches, and List of Super Mario Advance glitches would be deleted, with the glitches merged into each game's main article.
Do nothing: There should be no concrete minimum, and whether glitches should be split or not should be discussed on a game-by-game basis.

I could continue with 6, 7, etc., but I feel once this point is reached there is enough to warrant separate "List of glitches" articles, especially since game articles are typically long and images are usually needed to showcase glitches, taking up more space.

Proposer: Technetium (talk)
Deadline: August 29, 2024, 23:59 GMT

Option 1

Option 2

Technetium (talk) Second choice.

Option 3

Technetium (talk) First choice. I am a bit torn between Options 2 and 3, but I prefer this one as I feel 4 glitches can easily fit on a game's page, as seen with the examples above.

Do nothing

Comments

From what I can tell, articles on this wiki are usually split based on size, not the number of headings. It's why List of Fortune Street quotes is split into Dragon Quest characters (A-J / K-Z) and Super Mario characters (A-M / N-Z) and why the number of headings in these articles is inconsistent. I think it'd be weird to split lists of glitches based strictly on the number of sections rather than the amount of text since that could lead to very short articles that only list a few very minor glitches that can be described in just a few sentences. Dive Rocket Launcher 22:50, August 15, 2024 (EDT)

New features

None at the moment.

Removals

Remove remaining uses of tabber

This one's probably a long time coming. Tabber is currently only approved for usage in two infoboxes, which is pretty confusing (to make matters worse, the original proposal allowing it for the minigame infobox seemed to only have Mario Party in mind). I've seen users implement these outside of the approved uses, which is a pretty understandable mistake. If you see a template used in one situation, it makes sense to use it in comparable situations, right? You'd have to go to the template page to find out that it's only for very specific scenarios. More importantly, further attempts to allow tabber have failed under heavy opposition, mainly because tabber requires JavaScript to work. If it's disabled or not supported by your device, it displays the content of every tab at once in an unseemly vertical stack.

Based on the general sentiment in the past two proposals and the inconsistent application on pretty arbitrary standards, I think it makes sense to just repeal the original two proposals and remove the remaining uses of tabber completely. Whether tabber is deleted or remains in a deprecated state will be up to the judgment of the staff.

Proposer: Waluigi Time (talk)
Deadline: August 15, 2024, 23:59 GMT

Support

Waluigi Time (talk) Per me.
Doc von Schmeltwick (talk) - In any case, slideshow is preferable to tabber. Per.
Ahemtoday (talk) Tabbers not functioning on all devices kills them for me.
Nintendo101 (talk) Per proposal. Additionally, I personally find tabbers cumbersome to use as a reader and I am not a fan of how widely they have been integrated into our affiliate ZeldaWiki, where I feel they have substantially degraded the quality of the articles. I would prefer Mario Wiki not go down a similar path, and I think I would support the removal of tabs even if they did not require JavaScript.
Nightwicked Bowser (talk) Per proposal and courtesy of users without JavaScript.
FanOfRosalina2007 (talk) Per all.
Sparks (talk) Per all.
Mario (talk) Something that stuck with me since August 19, 2015: "Tabs are the devil". Even without the javascript issues there's likely fundamental useability issues; tabber I still think(?) is more gimmick than utility. I browse some wikis, I'm usually annoyed to try finding an image I want, only for it to be buried in tabs (ZeldaWiki is an example, the Keese article supplied is a maze of tabs and I actually find it difficult to just easily pinpoint how a Keese looks like in a particular game or across games; Battle Bat does not even provide all images in a gallery section, so I have to click on all these tabs just to see how these bats look like in different games; I'd rather just view all of them).
YoYo (talk) per all.
Sdman213 (talk) Per all.

Oppose

Super Mario RPG (talk) Perhaps it is overkill to have tabber in every single circumstance, but using it to compare between different iterations of the same thing (like Mario Kart courses or Mario Party minigames) is convenient for quick visual comparison and does not clutter the infobox.
Hewer (talk) I think tabber is fine to use in the two cases we currently use it for, as it allows us to show all the race course/minigame iterations in the infobox neatly and without having to just pick one (I think it always looked weird how we used to prioritise older images for just these infoboxes, but tabber provides a handy solution to that problem). As for the JavaScript argument, to quote Camwoodstock in this discussion, "any system too old to load tabbers are too old to connect to the internet at this point--pretty much only leaving severe bandwidth issues causing them to fail to load outright or devices specially configured to prohibit JavaScript in the first place as the only scenarios where tabbers wouldn't work".
Tails777 (talk) I can understand if tabbers are an issue, but I just agree more with the opposition here, especially with the usage for the Mario Kart tracks/Mario Party mini-games. Per Hewer.
DrippingYellow (talk) Not entirely confident in removing the tabbers altogether. As Camwoodstock pointed out, you'd be hard-pressed to find a device that doesn't support JavaScript these days. To be completely honest, the complaints from veteran users about tabbers being more visually confusing just comes off as them being used to the routine of scrolling down to the gallery to browse tiny previews of images. I certainly don't want this to end up like ZeldaWiki, what with the Artwork/Sprites/Models tabs containing sub-tabs, but I'm sure there are ways to get around this that could please both sides, without going full nuclear on tabbers (e.g. finding a way to have galleries contain images only when javascript isn't detected or, failing that, restrictions such as every tabber can only have up to X many images).
Addendum: I didn't consider at first that galleries have the benefit of letting you look at more than one image at a time. While that is a definite disadvantage for using it for stuff with actual artwork, I feel like the screenshots of the minigames/race courses in galleries are generally shrunken down to the point of not being the most readable, so you still have to click on them individually.

Comments

Waluigi Time (talk), for clarification, what are the two instances where tabbers have been permitted? Do you have examples of other pages where tabber has been overimplemented? - Nintendo101 (talk)

Currently it's approved for the minigame infobox (the original proposal was only for Mario Party minigames, but it's crept over to WarioWare) and race course infobox. Aside from the WarioWare edge case, a couple of mistaken uses of it have been on the Wario Land series and Expert world in MvDK. --

Too Bad! Waluigi Time! 19:31, August 8, 2024 (EDT)

Which mini-game/race course would get priority in the info boxes should tabbers be removed? Would it return to using the images from their original games or would the newest games get priority? I ask that mostly because the proposal regarding this question was aiming to decide that answer, but the tabber idea passed in general. So I'm questioning which image would get priority. Tails777 Talk to me!

I would prefer to take the safe route and revert back to the originals for now, and then a new proposal(s) can be made to deal with them afterwards if anyone wants to. --

Too Bad! Waluigi Time! 20:05, August 8, 2024 (EDT)

@Nintendo101 Why drag other wikis into this? Why Zelda Wiki in particular? If you take a look, loads of NIWA wikis use tabber. To give a few examples, the Mario article on SmashWiki; the quotes and game pages on WiKirby, the The Forest of Hope on Pikipedia, Marth on Fire Emblem Wiki, Cerebus on the KHWiki. I'm sure there's more. Super Mario RPG (talk) 21:42, August 8, 2024 (EDT)

This is tangential, but in a past life, ZeldaWiki was the primary NIWA wiki I contributed to, before they ever incorporated tabs, so I have more baseline familiarity with it than the other wikis, and I also personally believe it is the most egregious example of how tabs could be used. Many of the tabs within their infoboxes are completely empty, varyingly proportioned, or contain screencaps/assets best viewed at smaller resolutions. The tabs also obstruct visual material that otherwise could be readily viewed and compared all at once in a gallery if they did not use tabs, and I guess I prefer having that material more immediately available. I understand Zelda entries often adopt widely different artstyles from one another, but I think it would be healthier for their articles to pick one image curatorially for the infobox, and place the other ones in galleries at the bottom of the page. I do not bring up the use of tabs on that wiki to pick on their community; they are good and hardworking people. But it is immediately where my mind went when I started to see tabs incorporated into infoboxes on Super Mario Wiki, and I would rather not see something like that integrated here.

Their use of tabbers came from internal community discussions and proposals, so it does not really matter what I personally think - they should be the ones deciding how they organize their articles - but I do wish they would reconsider the benefits of incorporating tabs of t-posed models and empty files within their infoboxes. Fire Emblem Wiki and KHWiki are not using tabs to flip between varyingly proportioned images that push the text underneath them around; they are instead being used to provide different pieces of information and I think that looks quite nice.

I am honestly not a fan of the examples you have provided from Pikipedia or WiKirby either because of how they shift the underlying text (it makes it a little cumbersome to passively read, a problem shared with ZeldaWiki), but at least none of their tabs are empty. - Nintendo101 (talk) 22:18, August 8, 2024 (EDT)

We're abstaining personally (while we still think tabbers have a use, we do fully acknowledge their use is contentious and it's a bit of a hot button issue where to even draw the line), but we would like to ask that, if this passes, to NOT delete the tabber template outright... Mostly to prevent situations where older page revisions in edit histories just become incomprehensible due to changes in template infrastructure. (Seriously, it's bad enough when infoboxes get renamed, and it would feel a bit silly in this case when one of the reasons for removing them is "they break things if Javascript isn't available"... ;P) ~Camwoodstock (talk) 22:58, August 8, 2024 (EDT)

I see one potential good use for tabber, and that is not infoboxes, but rather for character stat tables on game pages... for instance, showing the information on entities for overbloated games like Mario Kart Tour so it can be communicated without severely increasing the vertical space the page takes up. That of course, would be its own discussion. Doc von Schmeltwick (talk) 17:45, August 9, 2024 (EDT)

I know it's entirely subjective what I am about to say here, but I think that the use of tabbers, especially on the Mario Kart course articles, is just visually so unappealing, especially considering most images have inconsistent or low-res images. Most courses in MKDS, especially retro tracks, will also have images that have the hud, and a lot of tour courses don't even use in-game screenshots. It just is so yucky to look at, for a lack of better words. Only having the image of the original iteration of the course, and then having the remaining images throughout the article, is just an infinitely better way of doing it. I was against tabbers for this exact reason to begin with. - YoYo (Talk) 15:57, August 11, 2024 (EDT)

Is there a reason this wiki can't use Extension:Tabs? Apparently, it doesn't require JavaScript except on older versions of Internet Explorer. Dive Rocket Launcher 22:56, August 15, 2024 (EDT)

Changes

Decide how to add the Final Fantasy Wiki as an interwiki link

Since there are articles about subjects from the Final Fantasy series that have appeared in Mario Hoops 3-on-3, Mario Sports Mix, and/or certain Super Smash Bros. games (Nintendo 3DS / Wii U and/or Ultimate), I'm looking forward to add the Final Fantasy Wiki as an interwiki link. The issue is that there is also a wiki from Fandom (powered by Wikia) that is also named Final Fantasy Wiki. The good news, I've come up with three options:

Option 1: Change the text for Fandom's wiki from "Final Fantasy Wiki" to "Final Fantasy Wiki (Fandom)" on pages AND add the Final Fantasy Wiki as an interwiki link.
Option 2: ONLY add the Final Fantasy Wiki as an interwiki link (even if confusing).
Option 3: Do NOTHING.

Here is an example on the use of the interwiki link for the Final Fantasy Wiki:

{{iw|finalfantasywiki|Cactuar}}

Cactuar

{{iw|finalfantasywiki|Cloud Strife|Cloud}}

Cloud

That way, we'll be able to use the Final Fantasy Wiki interwiki link once it gets added right after either Option 1 or Option 2 passes, as well as change the text for Fandom's wiki from "Final Fantasy Wiki" to "Final Fantasy Wiki (Fandom)" on pages right after only Option 1 passes.

Proposer: GuntherBayBeee (talk)
Deadline: ~~August 1, 2024, 23:59 GMT~~ ~~Extended to August 8, 2024, 23:59 GMT~~ Extended to August 15, 2024, 23:59 GMT