|
Current time:
September 5, 2026, 13:23 (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
- 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]
- All proposals are archived. Please note that canceled proposals must also be archived, including their date of cancellation.[Proposal 8]
- Proposals can only be rewritten or canceled by their proposer within the first four days of their creation. If a proposer cancels their own proposal, they must provide a reason and wait three days before submitting any new proposal.[Proposal 9]
- A proposer cannot cancel their proposal and then implement it anyway. Only wiki staff can cancel a proposal and immediately put it into effect.
- Proposers can request their proposal be canceled by a wiki staff member after the self-cancellation cutoff, but they must provide a valid reason for doing so. In most cases, the proposal should simply run its course.
- If the wiki staff deem a proposal unnecessary or potentially detrimental to the upkeep of the Super Mario Wiki, they have the right to cancel it at any time.
- Unless there is major disagreement about whether certain content should be included, there should not be proposals about creating, expanding, rewriting, or otherwise fixing up pages. To organize efforts about improving articles on neglected or completely missing subjects, try setting up a collaboration thread on the forums.
- Proposals cannot be made about promotions and demotions. Staff changes are discussed internally and carried out by the bureaucrats.
- No joke proposals. Proposals are serious wiki matters and should be handled professionally. Joke proposals will be deleted on sight.
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 10] Poll proposals concerning multiple pages must have good justification for using the poll proposal format rather than individual talk page proposals or else will be canceled (for example, in the case of the princesses poll proposal, there are valid consistency concerns which make it worthwhile to consider these three articles simultaneously, but for routine article size splits, there is no need to abandon using standard TPPs for each).
In a poll proposal, each option is essentially its own mini-proposal with a deadline and suboption headings. A poll proposal can have a maximum of 15 options, and the rules above apply to each option as if it were its own proposal: users may vote on any number of options they wish, and individual options may close early or be extended separately from the rest. If an option fails to achieve quorum or reach a consensus after three extensions, then the status quo wins for that option by default. If all options fail, then nothing will be done.
To create a poll proposal, copy and paste the formatting below to get started; your username and the option deadlines will automatically be substituted when you save the page. Update the bracketed variables with actual information, and be sure to replace the whole variable including the square brackets, so "[insert info here]" becomes "This is the inserted information" and not "[This is the inserted information]".
===[insert a title for your proposal here]===
[describe what issue this proposal is about and what changes you think should be made to improve how the wiki handles that issue]
'''Proposer''': {{user|{{subst:REVISIONUSER}}}}
====[option title (e.g. Option 1)]: [brief summary of option]====
'''Deadline''': {{subst:#time:F j, Y|+2 weeks}}, 23:59 (UTC)
;Support
#{{user|{{subst:REVISIONUSER}}}} Per proposal.
;Oppose
====[option title (e.g. Option 2)]: [brief summary of option]====
'''Deadline''': {{subst:#time:F j, Y|+2 weeks}}, 23:59 (UTC)
;Support
#{{user|{{subst:REVISIONUSER}}}} Per proposal.
;Oppose
====[option title (e.g. Option 3)]: [brief summary of option]====
'''Deadline''': {{subst:#time:F j, Y|+2 weeks}}, 23:59 (UTC)
;Support
#{{user|{{subst:REVISIONUSER}}}} Per proposal.
;Oppose
====Comments ([brief proposal title])====
For the purposes of the ongoing proposals list, a poll proposal's deadline is the latest deadline of any ongoing option(s). A poll proposal is archived after all of its options have settled, and it is listed as one single proposal in the archive. It is considered to have "passed" if one or more options were approved by voters (resulting in a change from the status quo), and it is considered to have "failed" if all options were rejected by voters and no change in the status quo was made.
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 "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
- Remove the identifier from Bat (Super Mario Galaxy) (discuss) by Mr. Sorbetti; Deadline: September 15, 2026, 23:59 (UTC)
- Remove the identifier from Moneybag (enemy) (discuss) by Mr. Sorbetti; Deadline: September 15, 2026, 23:59 (UTC)
- Move List of New Super Mario Bros. Wii trading cards, List of Super Mario Galaxy trading cards, List of Mario Kart Wii trading cards, and List of Super Paper Mario trading cards to their official product names (discuss) by Nelsonic; Deadline: September 16, 2026, 23:59 (UTC)
- Remove the identifier from Tracks (enemy) (discuss) by Mr. Sorbetti; Deadline: September 18, 2026, 23:59 (UTC)
- Remove the identifier from Phantom (character) (discuss) by Mr. Sorbetti; Deadline: September 19, 2026, 23:59 (UTC)
Merges
Splits
Miscellaneous
- Modify the wordmark on MarioWiki:BJAODN and its subpages (discuss) by Illuminoid; Deadline: September 5, 2026, 23:59 (UTC)
- Decide how to handle progression for the Course infobox (discuss) by I... am R.O.B.; Deadline: September 8, 2026, 23:59 (UTC)
- Add progression to the Race course infobox (discuss) by Iand255; Deadline: September 18, 2026, 23:59 (UTC)
Unimplemented proposals
Proposals
Note: Implemented for all except Bowser's Inside Story's Bowser's Castle and Kingdom Battle's Peach's Castle
Note: Article for "Battle Without Honor or Humanity" has not been created yet
Talk page proposals
Note: Missing Rainbow Bridge, Blue Bonus Game House, and Yellow Bonus Game House articles.
Note: Currently split clothing should be merged back
Writing guidelines
None at the moment.
Removals
None at the moment.
Additions
Create subject-based subcategories for the Gallery and Multimedia categories
For clarity's sake! This has no relation to the presently-ongoing "Representative galleries on category pages" category proposal. It did give us the idea for this proposal during a Discord conversation that happened regarding it, but in the event either both pass, or this passes and that one doesn't, neither of these things should interfere with one another. Just want to make this clear immediately, since we imagine people might get confused seeing two proposals involving the words "Gallery" and "Categories".
No, what this is about are the literal categories for Gallery and Multimedia pages, the aptly named Category:Galleries and Category:Multimedia. These are two super-categories which pertain to every single Gallery and Multimedia page, and contain 790 and 165 pages at time of writing... They are also entirely unorganized beyond this single category, making navigating these rather difficult. While categories aren't exactly the end-all-be-all of our wiki's organization, they're not unimportant, either. Especially for a pair of categories whose only real categories above them are the Main one, for all fictional elements, making it pretty likely someone might actually find these categories while using the system as intended, the lack of any further attempt at organization here really sticks out like a sore thumb.
What we want is relatively straightforward. Just make a few sub-categories, based on subject, and to sort these pages accordingly to them. If one gallery/multimedia page doesn't fit a category that has its own sub-category, then it just stays in the root Galleries category or Multimedia category, since that's how we usually handle things. In particular, we plan to create each of the following:
- Game (galleries/multimedia)
- Character (galleries/multimedia)
- Ally (galleries)
- Enemy (galleries)
- Location (galleries)
- Object (galleries)
Note that some of these don't have Multimedia listed as an option yet, for one key reason; there's just not enough examples of locations/items with Multimedia pages to warrant a category for them yet, and the Character one is only just scraping by as-is, hence no sub-sub-categories for allies/enemies. It should go without saying, but in case it needs to be said, in the event that we end up with enough multimedia pages for each of these subjects, those could be made without an proposal (provided this one passes, of course).
Proposer: Camwoodstock (talk)
Deadline: September 10, 2026, 23:59 (UTC)
Create subcategories
- Camwoodstock (talk) Per ourselves, of course. Normally we wouldn't even think to propose this, but considering this would impact roughly 950 gallery and multimedia pages, no matter how minor the changes actually are, we figure it's better to ask than to not. ;P
- Illuminoid (talk) It is good to clean up categories. If someone does want to view an unsorted list of galleries or multimedia pages, they can simply visit Special:AllPages or Special:PrefixIndex.
- P-Tux7 (talk) I agree. I think it would be best to hew to the categories (Characters, Species, Objects, Locations, etc.) seen in Template:Galleries. If this is judged lacking, perhaps the template itself can be edited. All I care about is that it provides a consistent experience for the user.
- Iand255 (talk) Per all. This seems no different realistically than the way a category like Category:Music is sorted.
- Yoshi18 (talk) Per all.
- Brett (talk) Per all. These categories contain way too much pages.
- Spencer PK (talk) Per all. This would really help the usability of this part of the wiki.
- The Dab Master (talk) Per all.
Don't create subcategories (status quo)
Create screenshot subcategories for the Mario & Luigi games to contain collectable location screenshots
Screenshots following this style are what is being talked about here.
I went to use the category containing Mario & Luigi: Dream Team screenshots to see what giant battle screenshots the wiki has, but I encountered a problem as I tried looking: the category is flooded with screenshots intended to show the locations of collectables. I noticed how Category talk:Mario & Luigi: Dream Team images featured a discussion pointing out this same problem, but it went nowhere. I revived that discussion, which made it clear that a proposal should probably be made regarding this. These "collectable location screenshots" as I will be calling them basically show where every block, bean, item given by an NPC, coin, rocks that give a coin when broken, and each petrified Pi'illo are. What makes these screenshots a pain to sift through are that:
- These screenshots all have a filename structure that does not group them all together. Each area's set of screenshots are together, but the screenshots as a whole are not in a row, meaning they constantly interrupt the non-collectable screenshots.
- These screenshots are formatted in a way that makes them unfit for use other than showing the location of a specific collectable. They arrange the screens into a horizontal layout to better fit into tables when viewing the wiki with a computer. The minimaps being in these screenshots is a big problem; many screenshots crop out an entire screen as it hurts the ability to present something in the game.
- There are hundreds, potentially over a thousand of these screenshots.
These screenshots for GBA
Superstar Saga do not have a map as part of the image, but are still considered in this proposal.
Now...let us take a step back and look at the other Mario & Luigi games' screenshots categories and the same problem is happening to all eight games. The screenshots for the GBA version of Superstar Saga do not have minimaps in their screenshots, so they are more flexible, but there are still a lot of them. Brothership is on the Switch, so it does not have a bottom screen minimap, but its pause menu does feature a map of each area. Each Brothership collectable location screenshot is actually two screenshots, one of normal gameplay showing the collectable, one of the full screen pause menu map, and the two screenshots are then arranged horizontally into one file making them function in a similar way to the DS and 3DS game screenshots. For Partners in Time, of the 764 files in its screenshots category, I counted that 607 are these collectable location screenshots.
Stepping even further back, it seems like this problem is also happening with Super Mario RPG and the Paper Mario series. I do not feel comfortable broadening the scope of this proposal this much, so I want to keep it focused on Mario & Luigi, which is what I am most familiar with. Additionally, I want to make it clear that this proposal is not aiming to set the precedent that there should be subcategories broadly made for screenshots of collectable locations. This proposal aims to solve the usability problems with the Mario & Luigi screenshot categories; the usability problems just so happen to be collectable location screenshots. The proper precedent that should be set from this proposal is that screenshot subcategories should be considered if a large number of screenshots are causing a disruption.
This proposal aims to solve the problem with the Mario & Luigi screenshot categories by creating a subcategory for each affected game that would be named GAME collectable location screenshots. This name makes it clear what it contains, while also being more loose, as some collectables are not tangible items that are collected, like Pi'illos and item patches. The text of the category itself would be something like "This category contains screenshots from GAME showing the location of a collectable.".
Here are helpful links to view the current state of each game's screenshots category.
Should this proposal pass, I think the only realistic way to properly recategorize everything would be combing through each category, making a list of file prefixes that belong to what need recategorizing, then having PorpleBot go though it. For Partners in Time and beyond, maybe recategorizing files with a specific resolution, because these images are arrange the screens in a unique way, would work?
Proposer: Spencer PK (talk)
Deadline: September 15, 2026, 23:59 (UTC)
Collect the collectable location screenshots and place them in subcategories
- Spencer PK (talk) Per proposal. The scope of this being thousands of files spanning eight games makes a proposal needed to verify if this should be done.
- The Real Mario & Luigi Fan (talk) Per proposal.
- LadySophie17 (talk) Having created Category:Mario Kart World mission screenshots for screenshots of specific things that don't work as general gameplay screenshots, I support this standardization.
- Camwoodstock (talk) What, is September Category Season now? ...Us cracking jokes aside, this definitely makes sense to us. Was kinda silently hoping this'd get proposed after seeing it got brought up in Discord about a week ago. Per proposal.
- Collectable Brett (talk) Per all.
Do nothing
- I feel like this should extend beyond the Mario & Luigi series. Games such as Super Mario Odyssey and Donkey Kong Bananza feature a lot of collectibles, and therefore have nearly thousands of collectible screenshots that could and should probably receive their own categories.
The Dab Master 14:52, September 1, 2026 (UTC)
- The idea behind this proposal could be applied really broadly (I just forgot to include a mention of more than just the Mario RPGs). I did not want to expand this proposal even further because I do not have a good idea of just how much would be affected. Power Moons and Banandium Gems are clearly in this at first, but then what about the 240 blue coins of Super Mario Sunshine? And I just realized as I was writing this comment that this could even apply to each colored banana from Donkey Kong 64. By limiting the scope of this proposal to Mario & Luigi where the problem is clearly happening, should the proposal pass, the idea can be tested and implemented with limited scope, and the idea can then be taken further by others who better know other games. --Spencer PK (talk) 17:04, September 1, 2026 (UTC)
Changes
Merging Fiery Block, Bonfire Block, and Flame Block
This is mostly following up on an old talk page conversation for the Fiery block, but seeing as we're proposing a change that'll impact a whole third page, we reckon it should be a mainspace proposal.
The Fiery Block and Bonfire Block are mostly split for two reasons: their names, and the mechanical difference... of how fire abilities work in Wario games, versus the Fire Flower's. Both of these are similar in terms of their own mechanics, being destroyed by using the corresponding game's Fire power, but because of the difference between Fire Mario and Flaming Wario, as well as the ever so slightly different names (the Bonfire Block being occasionally called the "Flame Block" and "Fire Block", but never the "Fiery Block"), they remain split.
...Except, uh, is that really that much of a mechanical difference? Even if the actual usage in levels varies, and the context of the surrounding game is different, the fundamentals are still identical. These are blocks destroyed by fire abilities. That is their sole function. And while a power-up is different from one of Wario's reactions... In comes Virtual Boy Wario Land, which has blocks that function identically, are visually similar, and are in a game that doesn't have Wario's reactions. You need a Dragon Crystal, turning Wario into either Sea Dragon Wario or King Dragon Wario, to destroy the blocks. This is a very standard power-up ability! And to boot, these blocks are visually similarMedia:VBWL Stage 3 Second Room.png to the Bonfire Blocks of Wario Land 4. The arguments for splitting the two apart don't really apply to Virtual Boy Wario Land, and since it's the first appearance of the subject... You can see where this is going, right?
Lastly, there's the Flame block from Wario Land 3. It's a block that is destroyed by Hot Wario, and if you hover over the link in question, you can probably see why we've opted to include it in this proposal, even if it wasn't originally in the conversation. In short, if we're going to merge Bonfire Block to Fiery Block, there's no reason to keep Flame Block split off from it just because Flaming Wario was called "Hot Wario" in Wario Land 3.
UPDATE: We've created a rough draft for the tri-merged page for those curious. It's still a work-in-progress, of course, but this is what you can roughly expect the resulting page to look like.
UPDATE 2: As Doc Von pointed out in the comments, Flame Blocks do technically have one thing going for them; you destroy them by igniting all of the Torches in the room, not just the blocks themselves. While we're not too hot (hah) on it, we will acknowledge this is at least a bespoke mechanical difference beyond "the way the game's fire power is formatted", and have provided an option to keep it split off. It's worth noting that, should that option pass, we will probably still mention the Flame Block in the resulting merged page, albeit in a much different context since explaining its mechanics and where it appears would naturally be reserved for its own page; the mention would be more along the lines of the Snowman Block mention currently on the draft.
Proposer: Camwoodstock (talk)
Deadline: September 14, 2026, 23:59 (UTC)
Merge all (flames burn brighter together!)
- Camwoodstock (talk) Secondary option. We do think this is still ultimately defensible, but we can see the merit in keeping the Flame Block split after having its mechanics illuminated. Like some kinda torch.
- Yoshi Block (talk) Per proposal.
- Iand255 (talk) Per proposal.
#Mr. Sorbetti (talk) Per proposal.
#Wilben (talk) They are all blocks that can be destroyed exclusively with fire. Seems pretty cut and dried to me.
Merge Fiery and Bonfire Blocks, keep the Flame Blocks split (flames of a feather, uh, scald together?)
- Camwoodstock (talk) Hey, these actually have A unique gameplay element to them! ...Sure, it's not much, and it's tied in with Torches, which already have their own page, but the difference in gameplay is significant enough, especially compared to "well, one's from a Mario game, and one's from a Wario game", that we think keeping these two split up is justifiable... Though, the similarities should definitely be acknowledged, of course.
- Hewer (talk) I'm neutral on Fiery Block but the Bonfire Block and Flame Block should stay split because they are two separate objects that both appear in the same game (Wario Land 3).
- LinkTheLefty (talk) The rest are similar enough, but the torch version definitely is dissimilar and functions more like a barrier that has a totally separate requirement (and the other block is in the same game).
- Doc von Schmeltwick (talk) - Per my comments and prior discussion.
- Mr. Sorbetti (talk) Per Doc.
- Wilben (talk) Per all.
Keep split (status quo) (it's a controlled burn!)
- WLIII's giant, "fades out of existence when a group of torches nearby are lit" Flame Block appears alongside the smaller, recurring "touch directly with fire to destroy" Flame Blocks. Different appearance and function within the same game. That's why I didn't include it in the prior conversation. Doc von Schmeltwick (talk) 23:17, September 3, 2026 (UTC)
- The wording on the actual page was a little ambiguous about that. We would still personally merge them, especially since the two are meant to be fairly similar in terms of gameplay, even if one happens to have the extra condition of "you light the Torches and not the blocks themselves", but we could understand wanting a split for that, since it's certainly more different gameplay-wise than Fiery Blocks and Bonfire Blocks are.
~Camwoodstock ( talk ☯ contribs ) 
00:12, September 4, 2026 (UTC)
- Wonder why that could be... Doc von Schmeltwick (talk) 00:27, September 4, 2026 (UTC)
- Yeah, that tracks. ;P ~Camwoodstock ( talk ☯ contribs ) 00:39, September 4, 2026 (UTC)
- Could you add an option to exclude that one? Doc von Schmeltwick (talk) 02:06, September 4, 2026 (UTC)
- Can do! ...Honestly, after thinking about it for a bit, we can see the merit of keeping it split up, ourselves. ~Camwoodstock ( talk ☯ contribs ) 07:35, September 4, 2026 (UTC)
- Can we actually add an option that just moves the Virtual Boy Wario Land block over to fiery block (possibly with a part-conjecture)? Those are functionally identical and the argument isn't as strong when the also-similar-looking flame block is a separate object. LinkTheLefty (talk) 14:44, September 4, 2026 (UTC)
Miscellaneous
None at the moment.