MarioWiki:Proposals
|
|
May 23, 2026, 00:42 (UTC) |
|
|
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
- Only autoconfirmed users may create or vote on proposals. Proposals can be created by one user or co-authored by two users.[Proposal 1]
- 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.
- 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]
- 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.[Proposal 8]
- All proposals are archived. Please note that canceled proposals must also be archived, including their date of cancellation.[Proposal 9]
- 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 10]
- 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.
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 11] 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
- ^ Proposal "Allow co-authorship of proposals" (passed on January 24, 2025)
- ^ Proposal "Allow unregistered users to comment under talk page proposals" (passed on November 14, 2024)
- ^ Proposal "Proposals Should End At The end of the day one week after voting starts (In UTC)" (passed on March 3, 2010)
- ^ Proposal "Revise how long proposals take: "IT'S ABOUT (how much) TIME (they take)"" (passed on October 16, 2024)
- ^ Proposal "Vote For More Than One Option On Proposals With More Than Two Choices" (passed on May 10, 2016)
- ^ Proposal "Delete Links to Passed Talk Page Proposals ONLY Until Action Has Been Taken" (passed on May 2, 2013)
- ^ Proposal "Cite relevant proposals and discussions on policy pages and guidelines" (passed on October 17, 2024)
- ^ Proposal "Restore PipeProjects" (passed on May 23, 2026)
- ^ Proposal "Include the date a proposal was withdrawn within the proposal (when applicable)" (passed on September 9, 2017)
- ^ Proposal "Allow users to put a reason for canceling proposals" (passed on May 8, 2026)
- ^ Proposal "Introduce a new type of proposal" (passed on February 14, 2025)
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
- Move Luigi's Mansion organ game to "organ game" (discuss) by Nelsonic; Deadline: May 25, 2026, 23:59 (UTC)
Merges
None at the moment.
Splits
- Split King Hisstocrat and Queen Hisstocrat (discuss) by Mariuigi Khed; Deadline: May 29, 2026, 23:59 (UTC)
- Split Coin Bandit from Bandit (discuss) by Sorbetti; Deadline: May 31, 2026, 23:59 (UTC)
- Split the segments of Frizzy's Silly amiibo Theater (discuss) by Rykitu; Deadline: June 1, 2026, 23:59 (UTC)
- Split objects appearing exclusively in browser games into their own articles (discuss) by Nelsonic; Deadline: June 5, 2026, 23:59 (UTC)
Miscellaneous
- Reconsider Wavy Ride through the Magma Tube's primary power-up to be the Fire Flower (discuss) by Illuminoid; Deadline: May 23, 2026, 23:59 (UTC)
- Decide how to handle terminology regarding levels (discuss) by Illuminoid; Deadline: May 24, 2026, 23:59 (UTC)
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) |
| 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) |
| Retool the Names in other languages section into a more general etymology section, EvieMaybe (ended March 7, 2025) |
| 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, Zing Zang Zote (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) |
| 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) |
| End the use of "new course" and "classic course" as universal definitions within the Mario Kart series, Polley001 (ended January 26, 2026) |
| Make all release dates use individual flags (if possible), Yoshi18 (ended February 8, 2026) |
| Create "recycled assets" sections for asset re-use, and move examples of asset re-use to those sections, Camwoodstock & Yoshi18 (ended March 5, 2026) |
| Prioritize whole integer upscaling for sprite displays, Scrooge200 (ended March 13, 2026) |
| Make an article for the New Super Mario Bros. series (Draft page), Yoshi18 & Sargent Deez (ended March 18, 2026) |
| Establish a consistent format for non-game enemy and obstacle lists, TheCatLover738 (ended March 22, 2026) |
| Allow screenshot in infobox for subjects with an updated design when no proper artworks exist, Brett (ended April 17, 2026) |
| Use manga chapters rather than volumes for subjects' first and last appearances, Brett (ended May 9, 2026) |
| Decide if medias that mention a subject before their first appearance or after their last appearance should be included in their infobox, Brett (ended May 14, 2026) |
Talk page proposals
| 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 (Draft page), Doc von Schmeltwick (ended August 3, 2024) |
| Create articles for specified special buildings in Super Mario Run, Salmancer (ended November 15, 2024) |
| Give the Cluck-A-Pop Prizes articles, Camwoodstock (ended January 31, 2025) |
| Split the Animal Crossing series (now Crossovers with Animal Crossing) (Draft page), Zing Zang Zote (ended February 12, 2025) |
| Restructure Yoshi's Island (series) article into Yoshi series, PopitTart (ended March 19, 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) |
| 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) |
| Treat courses that debuted in Mario Kart Tour and Mario Kart 8 Deluxe as Mario Kart Tour and Mario Kart 8 Deluxe courses respectively, Polterpup (ended January 1, 2026) |
| Consider "LUCKY" misses from the Paper Mario series to be a game mechanic, Pizza Master (ended January 13, 2026) |
| Move Wakkiki info to Akiki, FanOfYoshi (ended January 17, 2026) |
| Determine which clothing and other gear deserves individual articles, Doc von Schmeltwick (ended January 21, 2026) |
| Determine what qualifies as a game (and create appropriate categories in the process), SuperGamer18 (ended February 2, 2026) |
| Declare Super Smash Bros. - Gameplay & Quest for the amiibo! a guest appearance and delete Jack (Quest for the amiibo!), Salmancer (ended February 22, 2026) |
| Add music types to track tables (SSBU Sound Test), The Eggo55 (ended February 27, 2026) |
| Determine whether discontinued media counts as lost media, Pizza Master (ended February 28, 2026) |
| Make articles for the licensed songs in The Super Mario Galaxy Movie, SuperGamer18 (ended April 3, 2026) |
| Clean up the Mini Boo page, Sorbetti (ended April 25, 2026) |
| Split Scrap from Sticker, Jdtendo (ended May 20, 2026) |
Writing guidelines
Standardize the timezone used for internationally-synchronized release dates
As of publishing this proposal, it is about 2AM EST on March 20th, 2026, or 6AM UST on March 21st, 2026. Yoshi and the Mysterious Book has only just released in North America for 2 hours... But it has been out for several more hours in other parts of the world, namely Japan. And in some more western parts of North America, namely in Alaska, the game technically isn't even out! Late yesterday/earlier today, a bit of a conundrum happened on the pages for a few things featured in Yoshi and the Mysterious Book, where their infoboxes were updated to use that game as their "latest appearance" despite the game not being out in neither EST nor UTC... but, it was available in Japan at that point in time.
The original proposal that has been used as a precedent for this sort of thing from 2008 does not specify a timezone, only stating to use the "latest released appearance", putting the emphasis on when the game was released rather than announced, but not when in terms of timezones. We've seen this cause conundrums before; discounting the case with Yoshi and the Mysterious Book that incited this proposal, it's happened recently with The Super Mario Galaxy Movie, Donkey Kong Bananza, with Mario Kart World, with Super Mario Bros. Wonder... Really, any substantially large or dense game will inevitably see at least one over-zealous editor adding these games to infoboxes a few hours too soon, and people feel the need to either debate whether or not they should be reverted, or try to revert them themselves, all over the same lack of a "when" in terms of the timezone.
In this era where more and more Mario games are getting synchronized international releases for most of their release countries, we think it's high time to finally codify a timezone for these. Or in other words, when a game is set to release internationally at the same time for its first release, what time zone should we use? We've got three options here:
- JST (GMT+9): Japan's time zone. If we took that original 2008 proposal literally, this is what we would be doing as a technical status quo, even if, in practice, this usually isn't what we do by a magnitude of literally 13 entire hours.
- UTC (GMT±0): The gold standard for wiki affairs. Proposals use it, signatures use it, edit histories use it (by default, anyways), UTC has been a growing time standard on the wiki.
- EST (GMT-4): This is the de-facto status quo right now. As an American English wiki, it makes sense that the wiki would, on occasion, use the earliest timezone in North America for dates like this.
It was tempting to include NZST (GMT+12) as that is the earliest time zone in a country that sees frequent support from Nintendo (sorry, Kiribati), but we feel like the actual practicality of this is dubious, so we decided to relent. If this is somehow an unpopular stance (beyond just "it'd be fun to put it on the proposal" reasons), we could be swayed to add it as an option.
Proposer: Camwoodstock (talk)
Deadline: June 4, 2026, 23:59 (UTC)
Use JST (technically the status quo)
Use UTC
- Camwoodstock (talk) We've gone on record to be skeptical on UTC before, but as of recently, we've kind of changed our tune, especially after Porplemontage proved the transition from EST to UTC really wasn't that difficult to implement. UTC is late enough in the day for folks in North America that it doesn't really (even in Alaska, you'd only get it "early" insofar as we'd consider the game released at their 4PM), and above all else, UTC is consistent with so many other things on the wiki.
- Illuminoid (talk) Since most things on the wiki use UTC time, it would seem really weird if this one thing did not.
- Rykitu (talk) Per all.
- EvieMaybe (talk) per Illumoid.
- LadySophie17 (talk) We've switched to UTC almost everywhere, makes no sense to stop now.
- Nelsonic (talk) Per.
Use EST
Comments (it's about time!) (...zones)
I'm confused. If a game has released in Japan (or any region), then it is a released game and should count for the "Latest appearance" in the infobox regardless of any other parts of the world, right? Not to mention that Japan-only games count for the latest appearance too (like in the months between the Japanese and international releases of Hello, Mario!). Hewer (talk · contributions · edit count) 16:21, May 21, 2026 (UTC)
- The proposal already states that this applies to simultaneous worldwide releases only. If a Japanese release significantly predates the international one, then yes, we would go by it, but we can be a little patient and wait 9 hours for the release date to roll around in UTC. — eviemaybe
(talk) 15:24, May 22, 2026 (UTC)
- I don't understand the benefit of deliberately being inaccurate for those 9 hours. If a game has released, there's no reason for it to not count as a released game. I would support an option of "use whichever time zone has the earliest release". Hewer (talk · contributions · edit count) 18:55, May 22, 2026 (UTC)
Removals
Delete the individual Yoshi's Island enemy class pages
Based on the vote so far, this proposal may be eligible to close one week early. Please use {{proposal check|early=yes}} on May 22, 2026 at 23:59 (UTC) and close the proposal if applicable.
This concerns the following category, and each of its pages, listed below for convenience:
...In short, these are not anything specified by the game whatsoever. These are strictly sourced from the Nintendo Power Player's Guide for Yoshi's Island: Super Mario Advance 3, said "enemy classes" are strictly used as section headers rather than taken as being definitively about specific enemies, and even within the guide itself, it doesn't list a faux species for every enemy in the game. Pikmin, this certainly isn't; this is just kind of a joke that spans two pages, and yet somehow has six pages and a category. Imagine if every nickname Nintendo or affiliated sources have used for Shy Guys to promote the enemy-naming feature of Yoshi and the Mysterious Book, from "LL Shy G", to "Hanks", got their own not-redirect, fully-featured pages. That's roughly the level we're operating on here!
Obviously, this is kind of an absurd way to handle this, and giving this the scope we have is bordering on a nonsensical Lore™-brained extrapolation. This is the sort of thing we list as a note, or maybe at the end of the game's section on the enemy's page, not given its whole bespoke page... And if this passes, we'll see to it that that's what we do. Just mention these enemy classes on the enemies' pages, either in the section for Yoshi's Island, or in a Notes section if the enemy lacks a history section for one reason or another.
Proposer: Camwoodstock (talk)
Deadline: May 29, 2026, 23:59 (UTC)
Support (It's no Mr. E!)
- Camwoodstock (talk) Per our Democratius Websitius (own proposal).
- TheCatLover738 (talk) Per proposal.
- Rykitu (talk) Per proposal. It is worth mentioning on the enemy's pages and the game's page, but it doesn't deserve an entire article.
- Robipedia (Japannica) Let's get rid of these wastes of pages and either use them to save the Amazon
companyrainforest or put actually important stuff in there. - Wanderia Florius (talk) Didn't we already decide this sometime ago? I thought the issue was just that nobody had gotten around to it yet. Regardless, per all.
- Sorbetti (talk) Per proposal.
- Arend (talk) As the guy who started the whole discussion Camwoodstock mentioned in the comments , per all and per what I said back then
(even if it would be pretty funny if we had a Mysterious Book article on Dave). None of these classes warrant an article, especially if the guide they're from don't have complete enemy lists that lead to a lot of speculation and even incorrect information (e.g. listing Lakitu under Projectilia Ritebakatchia instead of under Harrassimentia Phlyoverus (and Projectilia Ritebakatchia lists Wall Lakitu instead), listing Piranha Plant instead of Spear Guy under Ucantia Defeatus, listing all the games's bosses under Ucantia Defeatus when the guide never specified that, etc). - Yoshi18 (talk) Per all.
- Hewbert P. Edia (talk) It's funny that these articles have been questioned on at least five occasions over 16 years and are only now being dealt with. Anyway, better late than never.
- EvieMaybe (talk) FINALLY! per all.
- Dominoes (talk) Per all.
- ThePowerPlayer (talk) Per all.
- FanOfYoshi (talk) The fact they had articles never sit well with me; I'd say turn it into a redirect.
- FluffyGuardian70 (talk) Per all.
- Xiahou Ba, The Nasty Warrior (talk) "Hmm, this is stupid!"
Oppose (The case is still warm!)
Comments (Joke about "taxonomy" and "Yoshi's tax fraud" here)
@Wandering Poplin - There was a discussion on the category talk page, but it still needed to be outright proposed before we could delete the pages and move the remaining information over to the enemies' pages. This is us making that outright proposal.
~Camwoodstock ( talk ☯ contribs )
01:17, May 15, 2026 (UTC)
Additions
Restore PipeProjects
Based on the vote so far, this proposal may be eligible to close one week early. Please use {{proposal check|early=yes}} on May 23, 2026 at 23:59 (UTC) and close the proposal if applicable.
PipeProjects are portals for major projects that often branch out into multiple articles. With the Super Mario Wiki growing day by day, the need for a system that allows like-minded editors to effectively cover select parts of a franchise that spans decades of history and a variety of mediums is clear.
However, PipeProjects were abandoned fourteen years ago. As such, this proposal aims to restore PipeProjects as a wiki-centered space for collaboration. I will also propose the creation of a new PipeProject, which will serve as an inaugural example of how PipeProjects will benefit the wiki.
PipeProjects will serve as spaces to host discussions, communal drafts, resources, and links to relevant discussions and proposals. Rather than scattering this information around various talk pages and user pages, PipeProjects will work as a centralized hub where interested editors can reasonably keep up to date with the project's latest developments. Specifically, PipeProject pages will provide the following sections in order:
- an introduction providing an overview of the project and its goals;
- a curated list of links to relevant proposals, talk page proposals, and unimplemented proposals;
- a curated list of links to relevant;
- an overview of the resources provided by the project, including subpages and passed proposals; and
- a non-signature list of editors who actively affiliate themselves with the project.
While PipeProject pages will generally follow this structure, they may also feature images and other elements as personal touches from the projects' contributors.
Project subpages will be encouraged to host specific project resources as an indication that the pages serve the project and are free to edit. Many valuable pages hosted by other editors already are open to edits, but I believe that moving these pages to common ground would provide even more benefit to editors.
PipeProjects will be created by proposal rather than the supporter-based process currently indicated by the PipeProjects page. Proposals should focus on whether projects will be worked on by many editors and have lasting utility outside of changes to a select number of articles. Most unimplemented proposals will not result in the creation of PipeProjects.
Of course, no project is guaranteed to last forever. Starting a year after the creation of a project, if editors determine that the project is not active enough to continue, the project may be considered closed for inactivity. The year-long delay is intentionally set as a barrier to discourage the creation of projects that may not have sufficient evidence that they would last beyond that year. Subpages for closed projects will remain editable, but the project page will generally be considered archived, and the proposals and discussions lists will not be kept up to date. The existing projects from the previous iteration of PipeProjects will additionally be considered closed. Contributors to a project may close the project earlier than a year via proposal, assuming that the project's goals have been met. Contributors are permitted to reasonably expand a project's scope via consensus, allowing projects to focus on one priority (for example, documenting a portion of the mainline Super Mario series) before continuing with another (doing the same for the broader Super Mario franchise).
As an optional addendum to the restoration of PipeProjects, I recommend that a forum channel be created in the affiliated Discord server, where each post in the channel corresponds to an open PipeProject. I have observed that a system of project-focused channels works well in other wiki communities such as WiKirby, and I believe that implementing these channels would not detract from the ideal of discussions taking place primarily on the wiki.
Now that I have introduced my thoughts for PipeProjects as a whole, I would like the propose the creation of PipeProject Music. Over the past few years, a variety of editors including myself have developed the wiki's coverage of music. This progress shows no signs of slowing down, and the resources available and discussions needed would serve well under the structure of a PipeProject.
Specifically, I would like to nominate the following editors who I have seen work on music coverage and the relevant resources that they have contributed:
If created, the project's scope would cover articles, sections, templates, and categories for musical themes, sound effects, soundtracks, sheet music, live performances, streaming services such as Nintendo Music, composers and other sound artists, and references to these topics in media, as well as any other music-related topics covered by the wiki.
Finally, I would like call out @Nintendo101's work on citations and mainline subjects. While I will not propose for those projects to become PipeProjects on Nintendo101's behalf, I believe both stand out today as incredible examples of the wiki's collaboration that PipeProjects could further enrich.
Proposer: B700465189a9 (talk)
Deadline: May 30, 2026, 23:59 (UTC)
Support: Restore PipeProjects
- B700465189a9 (talk) Per proposal.
- SuperGamer18 (talk) I was NOT around when this was a thing, but we should absolutely bring this back. I even have an idea for a new banner if the PipeProjects name is kept.
- Camwoodstock (talk) Pardon our excitement, but... WE'VE BEEN SAYING THIS FOR YEARS!!! While the Discord and the Boards are adequate for organized efforts, having something on the wiki itself to coordinate these things would go a long way, both for accessibility and making sure those efforts don't get easily lost in the flotsam and jetsam of Actual Conversation. It clearly spells out what is actively being organized, who is working on it, lets people better determine who's handling what, and most of all, puts it in a very obvious space for it that editors are likely to actually see. We could even bolster it with our more recent infrastructure; something like a widget on the main page to show ongoing Pipe Projects to editors akin to the To-Do Bar (and maybe even listing a count of active Pipe Projects on the To-Do Bar itself for good measure), or using a variant of the {{todo}} templates to show that a page is being handled by a specific Pipe Project. We have a lot of options to bring Pipe Projects up to more modern standards, is what we're getting at! (A bit more pragmatically, this will also hopefully offload some of the long-standing "proposals to implement" from that list, by opening them up to more editors willing to pitch in. If this passes, we definitely plan to turn our "reused assets" section proposal in particular into a Pipe Project.)
- PopitTartProjects (talk) Yes, please. I can't even count the discussions on the Discord server that have culminated in "It sure would be nice if we had the infrastructure to do a big project like this." It has reached the point of being a sarcastic in-joke.
- Spencer PK (talk) The wiki really needs some way for large projects to be managed so stuff can get done. I left a talk page topic at the main page detailing how the wiki's current documentation of locations in RPGs are poor, but without the ability to orchestrate a project, I could only really just say "there is a problem with the wiki" and leave it at that. The ability to make a project for that would lead to that discussion getting resolved, begin discussion for how RPG location articles should be improved, and would be a natural place for discussion on handling issues as they come up.
- Aomaf (talk) Per proposalツ
- PipeProject:Nelsonic (talk) Per proposal. I was actually considering proposing this myself at some point.
- Reese Rivers (talk) Per all. I especially like the idea of the Discord forum channel to go alongside the projects, which I think would be very helpful for realtime collaboration.
- PipeProject:Rykitu (talk) Per all. I always wondered why a perfectly good idea like that was deprecated, and I'm glad it's returning. My only complaint is Discord, which I don't have (and I don't want one after recent events), but I have a Boards account so that could be a good substitute if I ever decide to start one.
- EvieMaybe (talk) It's nice to see this finally happen.
- Sorbetti (talk) Per proposal and Rykitu.
- TheDabProject (talk) PER ALL!!!
- DominoProjects (talk) If this gives a good way to organize large-scale projects, I don't see why not.
- PaperSplash (talk) Per all.
- ThePowerProjects (talk) Per all. About time.
- SONIC123CDMANIA+&K(B&ATSA) (talk) Per all.
- Polley001 (Nintendo Music spreadsheets) (talk) Sounds good to me. I recently brought up a certain grievance with music coverage on Discord, but have not pursued doing something about it largely because bringing attention to it at scale would pretty much require jumping into a massive proposal, which is... not fun. Having a dedicated space to discuss music coverage as a whole would definitely help there.
- Brett (talk) Per all.
- Dive Rocket Launcher (talk) Would love to have a way to coordinate with other wiki editors without having to join the Discord server or forum.
- Illuminoid (talk) Per all.
- Nintendo101 (talk) I respect the long-term concerns of our compatriots in the opposition, but, TBH, I have long been a bit wary of the community divide between wikispaces, Mario Boards, and Discord. I think PipeProjects can be a potential supplemental for coordinating general wiki-wide projects. I do know a few excellent users of the wiki who I would like to collaborate with that are not interested in Discord or Mario Boards. I can see the infrastructure of PipeProjects being a potentially good avenue for things like that. And even if it does not work out in the long-term, I don't think there's any harm in trying.
Oppose: Flush PipeProjects
- Stache (talk) Honestly, I don't really get the hype for this (not that I was active when it was still a thing). I understand that some people are not keen on having a Discord and/or forum accounts, but wouldn't having another place to coordinate on wiki subjects makes the situation on its fragmentation worse, unless we choose do deprecate the use of Discord server and Mario Boards for that?
- Xiahou Ba, The Nasty Warrior (talk) Per Stache, but I'll further elaborate his points because, as very long-time, old user with much experience who has been here for a decade and a half, who has seen what happened when stuff like this happened (PipeProjects died, moved to the Wiki Collaborations forum with its threads, which had plenty of steam at first, and then also ended up dying over time as interest faded out), this is a vote that voices criticism and concern of this idea, with hints of cynicism (pardon me for that) with the long term prospects of trying to revitalize such a thing that died, without really knowing why it died to begin with than it really is amount to changing anything or persuading anyone to stop despite the surrounding hype I observe, but I honestly don't think this will take off in the long term (and I'm talking many years long term, not months, most voters who voted support here have only been around for a few years), once the initial steam dies off. None of us are paid editors who are under any obligation to do something like this, we are all drive-by using our free time to edit as we see fit, and I think attempting to organize editors something with a cool fancy sounding name and all of this oh my god, cool official sounding organization shit and all, notwithstanding that all of us with schedules and off-site responsibilities to focus on something particular is wasted effort for little gains other than the illusion to make people believe they actually are doing something. People who have the skills and goals to coordinate are already talking to other editors in other venues, such as the Discord channel, which is honestly a better outlet at promoting fast, quick chats with active editors than here. Look at the PipeProject page itself, there are only a few "completed" PipeProjects, take a look at the PipeProject:Super Smash Bros. one, how many editors signed up with the promise of completing these pages, and how many of them you think actually did anything substantial other than a few handful of them, who are likely were already improving these pages before the PipeProject got organized. On the flipside of the "completed" ones, the vast majority of earlier PipeProjects are incomplete, and they languished like this for most of the PipeProject's history, and some got migrated to MarioBoards before also being abandoned (like PipeProject:Unstubify, a problem we still have of this wiki to this day and frankly, we will still have long after we have exhausted our interest editing here). I'm not saying that any of this is a bad idea, and yes, I do see there is interest in this organization...initially, because PipeProjects was also proposed with initial interest and passion, but where will this end up in, say 5 years, when many editors who wanted this moved on and new editors come in and not really know about this or how to deal with this, which is unnecessary convoluted for the sake of it? It is also concerning to me that zero of the concerns that Glowsquid and other voters who had voiced support and their reasons had written up in the initial scrapping the PipeProjects are completely unaddressed, and they are criticisms that I think are still extremely relevant to this day, there is a history of this being attempted many times already. Another massive concern of mine is a heavily reliance on Discord, which is a massive issue in of itself, such as being unsearchable and relatively inaccessible for some users (imagine there being a Discord outage or Discord did something that is extremely cancelable and a chunk of the enraged userbase migrates to another platform out of protest, further splintering collab between communities, now what?)
- LadySophie17 (talk) Honestly I wasn't gonna vote so I wouldn't be raining on anyone's parades, but since others have voiced their concerns, I'll share mine. From my personal experience in trying to coordinate effort between people (specifically for bringing our Mario Tennis Fever coverage up to snuff), I can barely get people to cooperate by directly asking for help. I don't think creating a dedicated space where I can post my requests and passively wait for people to come by would yield better results, or any results at all. Maybe I'm wrong. I hope I am wrong. But I don't think I will be using this feature in my future projects in lieu of directly getting in contact with people I know would be interested (if there are any).
- Mario4Ever (talk) Per Xiahou Ba.
- Hewer (talk) Personally I don't think I fully understand what the benefit of this is meant to be. If you want to improve a particular area of the wiki, you can go and do that. If you want to coordinate with other editors (or even just point out that a certain area of the wiki needs improvement), you can use talk pages or the Discord server. I don't see how adding an extra namespace requiring extra maintenance and providing extra complications is supposed to help in getting anything done. I also don't understand why this is being presented as some sort of way to unite the whole community in one place with even those who aren't on the Discord...when the proposal itself says that PipeProjects would be coordinated on Discord. And coordinating with other editors on Discord is something you can already do. So what is this actually achieving?
- Wandering Poplin (talk) Per all.
Comments (PipeProjects)
I am very interested in this, but I want to ask: is the name "PipeProjects" an integral part of the proposal? I think it could be a good idea to come up with a new name, both to make it more obvious what its role is, and to avoid having to reuse the now-deprecated PipeProject: namespace. — eviemaybe
(talk) 16:49, May 16, 2026 (UTC)
- We personally like the "PipeProjects" name, but we can understand the concerns of rebooting an archived namespace like that. Maybe everything currently on it could be moved to some bespoke archival namespace?
OldPipeProjector something, though we're open to pitches on that.
~Camwoodstock ( talk ☯ contribs )
18:13, May 16, 2026 (UTC)
- A new name to not touch the old deprecated PipeProject namespace sounds like a really good idea, but I don't have any name ideas. Camwoodstock's idea of just moving the old namespace seems like a solution that could work, but I'm not sure if that is the best idea. --Spencer PK (talk) 18:48, May 16, 2026 (UTC)
- I didn't have any specific alternatives in mind, but I do like the alliteration aspect of the current name. There aren't many pages in the namespace to begin with, which is why I think reusing the namespace would be alright. B700465189a9 (talk) 20:57, May 16, 2026 (UTC)
Regarding the creation by proposal, would a new header be placed on this page for these PipeProject creation proposals? --Illuminoid (talk) 17:31, May 16, 2026 (UTC)
- In general, I think that the current sectioning of proposals is more confusing than helpful, but under the current structure, I would say that the project creation proposals should be organized under "Additions." B700465189a9 (talk) 20:57, May 16, 2026 (UTC)
- Since they can go under Additions, can large proposals incorporate a PipeProject if needed? --Illuminoid (talk) 21:48, May 16, 2026 (UTC)
- I would recommend that dedicated proposals to create projects for existing efforts are given, but if needed, other proposals under the section would be able to include the creation of a project. B700465189a9 (talk) 12:51, May 18, 2026 (UTC)
- Since they can go under Additions, can large proposals incorporate a PipeProject if needed? --Illuminoid (talk) 21:48, May 16, 2026 (UTC)
"Proposals should focus on whether projects will be worked on by many editors". If you need people to already want to make edits relating to the project in order to propose the project, then you already have supporters for the proposal. I feel like this will cause the proposal establishing a Pipe Project to just be a formality, and then we're wasting time waiting for proposals to pass. Time where the idea driving the PipeProject is losing momentum as it waits for approval. I really don't think a PipeProject should require a proposal short of it guaranteeing a corresponding discord thread/channel. Salmancer (talk) 21:05, May 22, 2026 (UTC)
Not in love with this proposal
Okay, so the reason I didn't comment earlier was that I didn't want to be the mean old editor who shoots down ideas and wants to stick with status quo as much as possible and I was like, okay, I don't support this really but then again, maybe give it a chance. But then I actually read the proposal and the more I see these provisions the more I dislike them.
Some of these particularly stand out
- Specifically, PipeProject pages will provide the following sections in order: [list]
This is already a bad sign. This puts up a significant barrier of entry that shouldn't have to be there. The requirement that editors comb through proposals and keep up with the current ones, decide which proposals are relevant to the PipeProject, which ones are no longer needed because it was overturned, needs active engaged editors which most will not do or want to bother doing. It's not sustainable. One can say it's not necessarily the responsibility of the PipeProject creator to keep up and others can fill in, but this is the expectation being put in place for possibly interested editors and it can and it will repel newer editors. In most cases, new editors that do want to join will simply leave their name there. The final part requiring a list of editors will either have a lot of no longer active editors or will also have to be actively kept up to date on who's still there on a project which further compounds the issues of long term prospects of PipeProjects. Either way, since anyone can simply leave their name there without significantly contributing to the pages, and most will, the amount of editors between 4 and 40 editors is practically meaningless IMO.
- PipeProjects will be created by proposal rather than the supporter-based process currently indicated by the PipeProjects page.
Very bad idea. There shouldn't be a weekslong process to vet a PipeProject. Users should be able to create PipeProject pages and then editors should be able to judge if this sort of thing is worth following or not. If one thinks this will lead to abuse of the namespace, I will point to Marioboards[1] Wiki Collaborations where anyone can create an account and basically create a new thread on whatever Wiki project needs to be brought attention to. This lower barrier of entry has not led to low quality threads. Also see point above, where there is a remarkable contrast in requirements of creating a PipeProject versus creating a thread in the forums. I am not advocating users create a Marioboards account. Most newer edits have signaled no interest in creating new accounts, much less posting in a largely deprecated community space. However, I just am illustrating this contrast.
- Starting a year after the creation of a project, if editors determine that the project is not active enough to continue, the project may be considered closed for inactivity.
How is this determined? Are users in Project Music editing a couple sentences in Slow and Steady considered active members or not? Should something like Project Music ever be retired because this project is effectively going to be unfinished for decades? This is another layer of maintenance that's practically avoided when it used to be Wiki Collaborations from Marioboards handling all these projects. When projects fall inactive, they sink to the bottom. If there is renewed interest, new posts will pop up. There doesn't need to be community vetting whenever something is worth maintaining or not.
- As an optional addendum to the restoration of PipeProjects, I recommend that a forum channel be created in the affiliated Discord server
MarioWiki Discord is straightforward to navigate and its sort of minimalistic channel count is a design I do enjoy over other servers that have 20 different channels for me to forget where a discussion has taken place. I'm not saying PipeProjects will lead to a lot of channels being created but I also do not want to invite the possibility there will be a maze of threads and channels from creation of a PipeProject. The provisions are not clear if that'll be the case, but even in the best case scenario where only one will be created, why is this different from #mariowiki or #wiki-editing (the second channel is already fairly redundant)? This looks just more like #mariowiki-2. "where each post in the channel corresponds to an open PipeProject" -> What does this even mean? Do you have to be a PipeProject member to partake in this? If not, what's the point?
I don't think PipeProjects will take off with this sort of design. There will be certainly interest when it's new, but once the novelty wears off, I don't see how the trajectory will change. The most successful ones are going to be far and few in between. The proposal does not seem to address reasons for PipeProjects getting mothballed, maybe there was an assumption that with a bigger editor base today there will be renewed activity feasible for PipeProjects; nor are there design choices being made to alleviate the original problems. Another reason for my skepticism is that we can't even coordinate users to expand parts of the wiki that needs expansion such as with Mario Strikers Battle League costume pictures that STILL don't have basic images or Mario + Rabbids (for the longest time, it didn't even have a basic gameplay section). If we can't even coordinate on basic aspects of a wiki, what will a PipeProject do? Be a name in a long list? Have a userbox in a userpage?
I'd like to be proven wrong, maybe this will take off. But some of these provisions are very unwelcome to me and I'd at least rather trim some of these, which will probably require another proposal, probably (to add to the ballooning amounts of proposals over the years which I think has led to the notion that these PipeProjects require literal wiki historians to assist in their creation and maintenance), and I believe will detract from the aims of PipeProjects. I really want to see how this thing will pan out 5 years from now but I have a strong suspicion most of the ~20 (if not more after the time of this post) support voters won't be active and won't see these cumbersome PipeProject pages risking falling to the wayside again.
It's me, Mario! (Talk / Stalk) 21:20, May 22, 2026 (UTC)
Changes
Decide how to handle reissues in the History sections of musical theme articles
A while back, I edited the "Forest of Illusion (Map Screen)" article so that the original theme from the SNES version of Super Mario World and the arrangement from the Game Boy Advance remake were combined into one section, but it was reverted, as I was told on my User talk page that reissues with unique arrangements from the original theme should be separated. So with that mind, I went ahead and edited the "Crocodile Cacophony (K. Rool's Theme)" article so that the original theme from the SNES version of Donkey Kong Country 2: Diddy's Kong Quest and the arrangement from the Game Boy Advance remake were separated into their own sections, but it was later reverted, which I assume is because nearly every musical theme article pertaining to the Donkey Kong Country series has their reissues combined with the original game, regardless if the reissue has a unique arrangement or not. This leads me to believe that the way we currently handle reissues in musical theme articles is not very consistent.
To fix this, I propose two options (EDIT: I added a third option based on B700465189a9's comment):
- Option A: All reissues will be combined with the original game in the History section, regardless if the reissue has a unique arrangement or not.
- Option B: Only reissues with their own unique arrangements will be separated from the original game.
- Option C: Only reissues with distinct soundtracks (as in, most if not every musical theme is rearranged for the reissue) will be separated from the original game.
If Option A passes, all arrangements of musical themes from reissues shall be merged with the original game in the History sections. This means that all of the Super Mario All-Stars and Game Boy Advance arrangements of musical themes from Super Mario Bros., Super Mario Bros. 2, Super Mario Bros. 3, Super Mario World, and Super Mario World 2: Yoshi's Island, the Nintendo 3DS arrangements of musical themes from the Mario & Luigi series, and the Nintendo Switch arrangements of musical themes from Super Mario RPG: Legend of the Seven Stars, will all be merged with their original games in their History sections.
If Option B passes, all reissues with their own exclusive arrangements of musical themes from the original games shall be separated in the History sections. This means that all of the Game Boy Color and Game Boy Advance arrangements of musical themes from Donkey Kong Country, Donkey Kong Country 2: Diddy's Kong Quest, and Donkey Kong Country 3: Dixie Kong's Double Trouble!, will be separated from their original games in their History sections. This also means that the arrangements of "Sweet Sweet Canyon" and "Dragon Driftway" from Mario Kart 8 Deluxe will incidentally be separated from the original Wii U version of Mario Kart 8 in their respective History sections.
If Option C passes, only reissues with completely distinct soundtracks from the original game shall be separated in the History sections. This means that everything that was said about Option B passing will apply, except for the arrangements of "Sweet Sweet Canyon" and "Dragon Driftway" from Mario Kart 8 Deluxe being separated, as Mario Kart 8 Deluxe's soundtrack is not completely distinct from the original Wii U version of Mario Kart 8.
Personally, I prefer Option A, as I think it would make musical theme articles in the future more neatly organized, but I also wouldn't be upset if Option B or C passes, as it would still make it so there will be consistency with how reissues in musical theme articles should be organized going forward, which is what I'm aiming for with this article, so it's a win-win.
Proposer: Wilben (talk)
Deadline: May 22, 2026, 23:59 (UTC)
Option A
- Wilben (talk) My preferred choice.
- Ahemtoday (talk) I strongly believe these sections should be combined in all scenarios, as any other type of article's history section would do. The only reason they're not is because of the old "arrangements" structure.
- Yoshi18 (talk) Primary choice; per all.
- LadySophie17 (talk) Consistency between types of articles is a helpful tool for readers. Those who are familiar with the wiki expect reissues/remakes to be covered under the original games already.
- Mario4Ever (talk) Per all.
Option B
- The Dab Master (Nintendo Switch) Primary choice; this is how we used to do this when a reissue featured at least one other arrangement or remix, and I never really saw a problem with this.
Option C
- Wilben (talk) My secondary choice, though I still prefer Option A.
- Yoshi18 (talk) Secondary choice; per all.
- The Dab Master / The Dab Master Deluxe + Expert in Mewing Secondary choice; per all.
Do nothing
Comments
I personally would separate reissues from their original games in these history sections if the reissues feature distinct soundtracks. After all, articles like that of Koopa the Quick do separate reissues when the reissues can be analyzed separately from their original games. The distinction between the soundtracks of Super Mario Bros. and Super Mario All-Stars should not be handled in the same way as the distinction between the soundtracks of Mario Kart 8 and Mario Kart 8 Deluxe. B700465189a9 (talk) 04:04, May 8, 2026 (UTC)
Could this proposal also account for merged series sections such as Dragon Coin (sound effect) § New Super Mario Bros. series or Fortress BGM § Super Mario Maker series? The Dab Master 16:32, May 9, 2026 (UTC)
- Probably not, as I'm simply proposing for how to handle reissues in musical theme articles, not series or sequels. Wilben (talk) 23:13, May 9, 2026 (UTC)
Miscellaneous
None at the moment.