MarioWiki:Proposals

Current time: Wednesday, September 18th, 02:25 GMT

Proposals can be new features, the removal of previously-added features that have tired out, or new policies that must be approved via consensus before any action is taken. "Vote" periods last for one week. Any user can support or oppose, but must have a strong reason for doing so (not, e.g., "I like this idea!"). 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.

A proposal section works like a discussion page: comments are brought up and replied to using indents (colons, such as : or ::::) and all edits are signed using the code {{User|User name}}.

How to

Rules

1. If users have 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 the other users, who will then vote about whether or not they think the idea should be used. Proposals should include links to all relevant pages and writing guidelines. Proposals must include a link to the draft page. Any pages that would be largely affected by the proposal should be marked with {{proposal notice}}.
2. Only registered, autoconfirmed users can create, comment in, or vote on proposals and talk page proposals. Users may vote for more than one option, but they may not vote for every option available.
3. Proposals end at the end of the day (23:59) one week after voting starts, except for writing guidelines and talk page proposals, which run for two weeks (all times GMT).
   • For example, if a proposal is added at any time on Monday, August 1, 2011, the voting starts immediately and the deadline is one week later on Monday, August 8, at 23:59 GMT.
4. Every vote should have a strong, sensible reason accompanying it. Agreeing with a previously mentioned reason given by another user is accepted (including "per" votes), but tangential comments, heavy sarcasm, and other misleading or irrelevant quips are just as invalid as providing no reason at all.
5. 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 administrators.
   • 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.
6. 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 "(banned)" 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.
7. No proposal can overturn the decision of a previous proposal that is less than 4 weeks (28 days) old.
8. 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.
9. If a proposal reaches its deadline and there is a tie for first place, then the proposal is extended for another week.
10. 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% support to win. If the margin is only one or two votes, then the first place option must have at least 60% support to win. If the required support threshold is not met, then the proposal is extended for another week.
    • Use the {{proposal check}} tool to automate this calculation; see the template page for usage instructions and examples.
11. Proposals can only be extended up to three times. If a consensus has not been reached by the fourth deadline, then the proposal fails and can only be re-proposed after four weeks (at the earliest).
12. All proposals are archived. The original proposer must take action accordingly if the outcome of the proposal dictates it. If it requires the help of an administrator, the proposer can ask for that help.
13. If the administrators deem a proposal unnecessary or potentially detrimental to the upkeep of the Super Mario Wiki, they have the right to remove it at any time.
14. Proposals can only be rewritten or canceled by their proposer within the first three days of their creation (six days for talk page proposals). However, proposers can request that their proposal be canceled by an administrator at any time, provided they have a valid reason for it. Please note that canceled proposals must also be archived.
15. 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.
16. Proposals cannot be made about promotions and demotions. Users can only be promoted and demoted by the will of the administration.
17. No joke proposals. Proposals are serious wiki matters and should be handled professionally. Joke proposals will be deleted on sight.
18. Proposals must have a status quo option (e.g. Oppose, Do nothing) unless the status quo itself violates policy.

Basic proposal and support/oppose format

This is an example of what your proposal must look like, if you want it to be acknowledged. If you are inexperienced or unsure how to set up this format, simply copy the following and paste it into the fitting section. Then replace the [subject] - variables with information to customize your proposal, so it says what you wish. If you insert the information, be sure to replace the whole variable including the squared brackets, so "[insert info here]" becomes "This is the inserted information", not "[This is the inserted information]". Proposals presenting multiple alternative courses of action can have more than two voting options, but what each voting section is supporting 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|[enter your username here]}}<br>
'''Deadline''': [insert a deadline here, 7 days after the proposal was created (14 for writing guidelines and talk page proposals), at 23:59 GMT, in the format: "September 18, 2024, 23:59 GMT"]

====Support====
#{{User|[enter your username here]}} [make a statement indicating that you support your proposal]

====Oppose====

====Comments====

---

Users will now be able to vote on your proposal, until the set deadline is reached. Remember, you are a user as well, so you can vote on your own proposal just like the others.

To support, or oppose, just insert "#{{User|[add 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 just say "Per my proposal".

Talk page proposals

Proposals concerning a single page or a limited group of pages are held on the most relevant talk page regarding the matter. Proposals dealing with a large amount of splits, merges, or deletions across the wiki should still be held on this page.

For a list of all settled talk page proposals, see MarioWiki:Proposals/TPP archive and Category:Settled talk page proposals.

Rules

1. All active talk page proposals must be listed below in chronological order (new proposals go at the bottom) using {{TPP discuss}}. Include a brief description of the proposal while also mentioning any pages affected by it, a link to the talk page housing the discussion, and the deadline. If the proposal involves a page that is not yet made, use {{fake link}} to communicate its title in the description. Linking to pages not directly involved in the talk page proposal is not recommended, as it clutters the list with unnecessary links. Place {{TPP}} under the section's header, and once the proposal is over, replace the template with {{settled TPP}}.
2. All rules for talk page proposals are the same as mainspace proposals (see the "How to" section above), with the exceptions made by Rules 3 and 4 as follows:
3. Voting in talk page proposals will be open for two weeks, not one (all times GMT).
   • For example, if a proposal is added at any time on Monday, August 1, 2011, it ends two weeks later on Monday, August 15, 2011, at 23:59 GMT.
4. The talk page proposal must pertain to the subject page of the talk page it is posted on.
5. When a talk page proposal passes, it should be removed from this list and included in the list under the "Unimplemented proposals" section until the proposed changes have been enacted.

List of ongoing talk page proposals

• Split Bowser's Flame from Fire Breath (discuss) Deadline: September 18, 2024, 23:59 GMT
• Split Banana Peel from Banana (discuss) Deadline: September 18, 2024, 23:59 GMT
• Consider the "Blurp" and "Deep Cheep" in the Super Mario Maker games an alternate design of Cheep Cheep with the former twos' designs as a cameo rather than a full appearance of the former two, in line with the game's own classification (discuss) Deadline: September 18, 2024, 23:59 GMT
• Split truck into cargo truck and pickup truck (discuss) Deadline: September 21, 2024, 23:59 GMT
• Split the navigation template for Donkey Kong between arcade and Game Boy versions (discuss) Deadline: September 21, 2024, 23:59 GMT
• Merge Crocodile Isle (Donkey Kong 64) to Crocodile Isle (discuss) Deadline: September 21, 2024, 23:59 GMT
• Prune "sports" games from Black Shy Guy in line with White Shy Guy and Red Boo (discuss) Deadline: September 21, 2024, 23:59 GMT
• Determine what to do with the feather item from Super Mario 64 DS (currently on Wing Cap) (discuss) Deadline: September 21, 2024, 23:59 GMT
• Add English to {{foreign names}} and retitle to {{international names}} (discuss) Deadline: September 26, 2024, 23:59 GMT
• Allow usage of {{Release}} as a generic "flag list" template (discuss) Deadline: September 27, 2024, 23:59 GMT
• Merge Preying Mantas with Jellyfish (discuss) Deadline: September 28, 2024, 23:59 GMT
• Create article(s) for the SM64DS character rooms (discuss) Deadline: September 30, 2024, 23:59 GMT
• Create an article for the Peach doll from Super Mario RPG: Legend of the Seven Stars (discuss) Deadline: September 30, 2024, 23:59 GMT
• Remove the remaining non-Super Mario "stage gimmicks and hazards" from Super Smash Bros. (discuss) Deadline: October 1, 2024, 23:59 GMT
• Remove non-Super Mario "stage cameos" from Super Smash Bros. (discuss) Deadline: October 1, 2024, 23:59 GMT

Unimplemented proposals

Proposals

Establish a standard for long course listings in articles for characters/enemies/items/etc., Koopa con Carne (ended June 8, 2023)

Break alphabetical order in enemy lists to list enemy variants below their base form, EvieMaybe (ended May 21, 2024)

Standardize sectioning for Super Mario series game articles, Nintendo101 (ended July 3, 2024)

^ NOTE: Not yet integrated for the New Super Mario Bros. games, the Super Mario Maker games, Super Mario Run, or Super Mario Bros. Wonder

Expand use of "rawsize" gallery class, Doc von Schmeltwick (ended July 19, 2024)

Do not use t-posing models as infobox images, Nightwicked Bowser (ended September 1, 2024)

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

Tag sections regarding the unofficially named planets/area in Super Mario Galaxy games with "Conjecture" and "Dev data" templates, GuntherBayBeee (ended September 10, 2024)

Talk page proposals

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

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

Make bestiary list pages for the Minion Quest and Bowser Jr.'s Journey modes, Doc von Schmeltwick (ended January 11, 2024)

Allow separate articles for Diddy Kong Pilot (2003)'s subjects, Doc von Schmeltwick (ended August 3, 2024)

Writing guidelines

None at the moment.

New features

Expand use of "rawsize" gallery class

So Porple helped me with creating a method to keep sprites at their raw size in galleries (yay!), which replaces the somewhat awkward way I previously did it for mostly-consistently-sized sprites (see the page history for Gallery:Golf (Game Boy), which is what I specifically directed him towards while doing it), and it's also highly useful for icons (especially when we don't have the raw parameters already, like the car icons for Mario Kart Wii), and cases where a size comparison is useful (like Bigger Boo's growth). In general, it's a good way to keep them from looking bloated and crusty with inconsistently-sized pixels, which I feel looks bad and degrades their quality, while keeping an upper limit on size so "huge" sprites don't take up all the space (and shrunken large sprites are preferable to bloated small sprites, in my opinion).

Now what I want to see consensus on, is whether this concept should be expanded to more common usage for sprite galleries, so that people can actually see the size difference between these entities. For example:

• 

  Fat rat

• 

  Pixel snake

• 

  Frying my eyes

• 

  Is this the crusty crab?

• 

  Lots of warts, all square

compared to

• 

  Rat's all, folks!

• 

  Snake me wanna shout

• 

  Pretty fly for a Fry Guy

• 

  I'm NOT a crusty crab!

• 

  The frog is coming!

or

• 

  This is a big sprite

• 

  Onward, bumpy Chomp!

• 

  Is this the crusty Koop?

• 

  I'm blue, dabba dee dabba died

• 

  Everything's so blurrrrrrrrrrry...

• 

  ...and everything's so fake...

compared to

• 

  This is still a lot bigger than this box

• 

  Onward, small Chomp!

• 

  I'm not a crusty Koop!

• 

  I'm small, dabba dee dabbadied

• 

  Everything's so big...

• 

  ...and I'm trapped in this white box!

Now, you'll notice, that on ones where there is difference in size, the smaller ones will appear just that: small, but their bounding boxes are the same as the others (which is an issue my old "give separate galleries with different widths and heights as well as inline-block display" strategy didn't have, but costed a lot more HTML data). I can see how some people may have issues with that, though speaking as a spriter, I find it preferable to blown up pixels. Also, you may notice some stretched captions there, that of course won't be much of an issue with the usually short captions sprites in galleries have.

Proposer: Doc von Schmeltwick (talk)
Deadline: July 19, 2024, 23:59 GMT

Support - allow it for general use in sprite galleries

1. Doc von Schmeltwick (talk) - Per proposal (and the crusty crab)
2. Super Mario RPG (talk) - I don't like the argument of "it doesn't look good." This provides the immediate benefit of showing the reader the original sizes of the sprites without having to click on each and every file link. Per proposer.
3. LinkTheLefty (talk) I always found the size discrepancy to be an eyesore.
4. Ahemtoday (talk) The inconsistent pixel sizes on the SMB2 examples are very apparent to me — you highlight Clawgrip, but I think Tryclyde has it the worst, personally. Now that we have the ability to upscale these by consistent amounts to keep them at reasonable sizes while not introducing nearest-neighbor weirdness, that takes me off the fence in voting for it provided we do that. I still don't really see the issue with the MP6 renders, though. Ahemtoday (talk) 22:23, July 14, 2024 (EDT)
5. Mario (talk) Cautious support after the option to scale sprites was implemented. I'd like to see this implemented in some galleries, such as Super Mario Bros. 2, as it's much easier to ascertain the scale of these sprites and it's more attractive to see them in this kind of array vs all being scaled to the same portion. Certainly not a fan of how the current method scales some sprites; Wart and Tricylyde's sprite do have inconsistent pixelation when scaled up due to the scale factor not evenly affecting all pixels, and forcing scales at factors seems to be a feasible solution. I don't think it needs to be applied in other galleries, however; Mario Party 6 doesn't really need to preserve pixel display, and the large Mario sprite has to be scaled down, so kind of defeating the purpose of keeping these scaled down to show relative scales (imo).
6. Hewer (talk) Don't see why not to allow this on a case-by-case basis.
7. Nintendo101 (talk) The examples above look a lot nicer than they did first time around. As long as users still have some curatorial discretion with how galleries are laid out, I think this is a nice tool to have available.
8. Shokora (talk) – Per all. If galleries are more presentable with this option, it's worth doing.
9. Sparks (talk) Per all.
10. Pseudo (talk) Alright, if display options will be available, then I’m sold.
11. LadySophie17 (talk) This new option changed my mind.
12. Waluigi Time (talk) Porple's changes fix the issues I had with implementing this, so I'm good with moving forward. I don't think this needs to be used for every sprite gallery though, per Mario.

Oppose - leave it exclusive to consistent sized icons and other special cases

1. Technetium (talk) Per all.
2. Sdman213 (talk) Per all.
3. FanOfYoshi (talk) NO!!! THIS IS PATRICK!!! Per all.
4. Murphmario (talk) Per all.

#LadySophie17 (talk) None of the pixels look blurry or blown out to me, they're just larger, which is generally how they would appear on any modern screen displaying them anyway. Displaying them in their original size makes details harder to see (important!), and the empty space around the boxes is just unappealing. As long as the wiki has these images saved at their true resolution, I see no issue in displaying them at a larger scale for clarity and convenience.

#Mario (talk) See comment

#Nintendo101 (talk) I think a nice benefit in supporting reference material or an encyclopedia is in allowing readers to view subjects in contexts otherwise tough to see, especially for galleries that are intended to support visual material. I have a number of books on small artefacts or organisms (insects, microbes, etc.) where they are not displayed to scale. I know and have seen users change the scaling of individual subcategories on galleries, but I'd rather that was up to their discretion rather than blanket policy. As long as the true dimensions of the uploaded files have not been messed with, I do not think there is much harm in allowing users to scale assets on the gallery pages.

#Sparks (talk) Per all.

#Pseudo (talk) Per Lady Sophie. The point of a gallery is to allow wiki visitors to look at the images therein, and leaving them too tiny to inspect closely feels counterintuitive, even if it’s not the original state of the images.

#Waluigi Time (talk) Per Lady Sophie. I'd rather sacrifice a little bit of quality than have these be too tiny to tell what anything is.

Comments

Regarding "detail," when it's all the same pixels anyway with no "zoom and enhance" going on, making them larger doesn't add any detail. That's why we upload sprites in their native res to begin with. The only "detail" you're going to see is how any dithering looks when it's not blending as intended, which is what "crusty" generally means in this case. Doc von Schmeltwick (talk) 12:46, July 13, 2024 (EDT)

I am perfectly aware that making an image larger does not create pixels out of nowhere, thank you very much. What it does is make small pixels (and therefore details) larger and easier to see.— Lady Sophie ^(T|C) 13:11, July 13, 2024 (EDT)

Problem is that the ruined dithering actually makes detail harder to see. Doc von Schmeltwick (talk) 13:38, July 13, 2024 (EDT)

I'm not opposed to its implementation entirely; I think you can have a case for it. For instance Gallery:Mario Kart Wii#Mugshots already uses a version of it to scale all those 64x64 sprites consistently. Gallery:Super_Smash_Bros.#Icons can also use a more consistent scaling scheme, but using class="rawsize" in the Smash Bros. example is not the solution, as it makes the icons much more difficult to ascertain especially on desktop monitors where zooming is not as easy vs a touchscreen finger swipe.

The reasoning for the proposal I also do not agree with and I believe it's based off trying to preserve how an asset to the perceived display from a game, which I argue is flawed reasoning as we are a wiki with different set of ideal ways and constrictions in how we can display information. This is not to mention that these sprites are often scaled in the games themselves and display differently based on the monitors. Paper Mario sprites for instance, are likely not even intended to be viewed at the resolution they're in; they're scaled up from camera, the game itself, and TV displays (CRT TVs are much less lower-resolution than the monitors we have today, so the original experience on these older games tend to show very blown-up scales), so sometimes details and text screenshots using the native resolution actually appear quite difficult to ascertain, see File:PM Koopa Bros Introducing Themselves Screenshot.png. The games themselves also scale these sprites often; using Smash Bros. 64 again as an example, the stock icon scales from an emulator screenshot in File:SSBStockmatch.png are increased and are filtered applied to blur out the pixels.

Finally, the examples used are flawed. At least from my display, Triclyde and Wart appear to be slightly scaled down, which undermines the point that not not applying scales to sprites maintains the desired factor of 2 that galleries autoscales fail to do (which perhaps the proposal can resolve and should address right away). The solution for this is either applying a consistent scale factor to all sprites, which means scaling them up, increasing the field size that the sprites occupy themselves in, or just going in one-by-one to maintain a consistent look (is this even feasible?). I do recommend trying to apply a scale factor to some low-resolution sprites including the NES/SNES era ones so the pixels display properly. I also recommend the terminologies, for clarity, is resolution (which is referred to as "raw size") vs scale.

So anyway, this proposal I understand where it's coming from but there are better solutions to address scale factor in galleries, and the practice appears to have already been employed in some galleries, particularly concerning higher resolution UI elements from games that maintain consistent aspect ratios like Mario Kart Wii's 64x64 sprites; these are high enough resolution that displaying them at no scale shows enough detail, but not high enough to occupy too much space for galleries. There might be more cases where this noscale parameter applies well, but I think we have to comb through them due to the amount of specifications Mario Kart Wii had going for it, which likely many galleries won't. Scale differences may be useful, such as in Big Boo's case and perhaps in the Super Mario Bros. 2 case but there is a downside of shrinking sprites too much, especially for variable games like Super Mario RPG that has zoomed out Luigi and big monsters like (??? i haven't played that game lol), which leaves behind empty space in galleries It's me, Mario! (Talk / Stalk) 12:52, July 13, 2024 (EDT)

I put the wrong parameters for the SMB2 one when I made the proposal, it's fixed now. Doc von Schmeltwick (talk) 12:58, July 13, 2024 (EDT)

Ok. Struck out that part. It's me, Mario! (Talk / Stalk) 12:59, July 13, 2024 (EDT)

@FOY Oi, don't use a proposer's own joke against them. That's rude. :( Doc von Schmeltwick (talk) 11:30, July 14, 2024 (EDT)

I guess i could say "Right Back at Ya!", right now.:D -- FanOfYoshi 05:49, July 17, 2024 (EDT)

Is there possibly a way to have scale factors for the galleries? Such as the ability to increase these by 200%. It could be a way to display more easily viewed sprites while maintain relative sizes of sprites. I need to see if it'll work for larger sprites. It's me, Mario! (Talk / Stalk) 12:43, July 14, 2024 (EDT)

As it is, we can't even do that with normal images, unfortunately, I've tried for tables many times for 200% or 50%, depending on the type, doesn't work for either. Guess that's a thing we can ask Porple. Doc von Schmeltwick (talk) 13:41, July 14, 2024 (EDT)

Okay, using a parameter Steve has put in your talk page[1], I've previewed the Super Mario Bros. 2 sprite array with a x2 scale factor. I like it more (not going to show it here; might be subject to change). I wonder what other people think of it. It's me, Mario! (Talk / Stalk)

Well, as that is an update to the rawsize amount, it works about the same for the purposes of this proposal. So long as there's a consistent scale, it's better than what we've had historically. Doc von Schmeltwick (talk) 22:18, July 14, 2024 (EDT)

I was actually thinking to myself "I might back this proposal if we scaled up the sprites by consistent round-number amounts". Ahemtoday (talk) 22:23, July 14, 2024 (EDT)

There has been an update to the parameters which allow scaling of these sprites to larger iterations, which should alleviate concerns about small sprites. Here is what I'm putting out:

Original

• 

  Fat rat

• 

  Pixel snake

• 

  Frying my eyes

• 

  Is this the crusty crab?

• 

  Lots of warts, all square

No scale

• 

  Rat's all, folks!

• 

  Snake me wanna shout

• 

  Pretty fly for a Fry Guy

• 

  I'm NOT a crusty crab!

• 

  The frog is coming!

2x scale

• 

  I smell a rat

• 

  Wingless Ghidorah

• 

  Not a Shy Guy

• 

  I ain't done counting me moneh. NOOO

• 

  Amphibious Bowser

And here's the 4x which I think is too big but it's just proof of concept (set width to 120px, causes sprite to leak out but technical restrictions mean we can't go beyond this)

• 
• 
• 
• 
• 

It's me, Mario! (Talk / Stalk) 22:54, July 18, 2024 (EDT)

Yeah as long as the pixels are squares and not inconsistent near-square rectangles to mess with my OCD (and are relatively consistent between image groups), it's OK by me. Doc von Schmeltwick (talk) 23:01, July 18, 2024 (EDT)

Please do not increase the size of the widths/heights value beyond the default 120px to make room for scaled images (but going smaller is fine). Doing so can cause overflowing on mobile Minerva. Here are a couple more options:

3x scale

• 

  I smell a rat

• 

  Wingless Ghidorah

• 

  Not a Shy Guy

• 

  I ain't done counting me moneh. NOOO

• 

  Amphibious Bowser

Mix of 4x and 3x

• 

  I smell a rat

• 

  Wingless Ghidorah

• 

  Not a Shy Guy

• 

  I ain't done counting me moneh. NOOO

• 

  Amphibious Bowser

--Steve (talk) 00:31, July 19, 2024 (EDT)

Removals

None at the moment.

Changes

Standardize the coverage of elements from guest appearance titles

As brought up by an earlier cancelled proposal, the current coverage of The Legend of Zelda series is very inconsistent, and the worst offender is Bombite. Unlike Spiked Thwomp, Stone Elevator or Mega Thwomp, it has no direct or implied connection to the Mario franchise, but has an article anyway, solely based on its appearance.

MarioWiki:Coverage#Guest_appearances permits giving individual articles for subjects "unique to the [guest appearance] game while also being clearly derived from the Super Mario franchise". I propose to more clearly define on MarioWiki:Coverage what elements from guest appearance titles should be given their own pages:

1. The subject is clearly derived from or based on the Super Mario franchise, as confirmed by Nintendo. (Nintendo Land minigames, Thwomp types exclusive to The Legend of Zelda, etc.)
2. The subject is distinct enough to justify its own article. (Cannot be merged with an existing page. BowWows or Cheep-Sheeps don't get individual articles because they're not distinct enough from their Mario counterparts)
3. Subjects exclusive to Mario-themed stages or minigames (Chili plate, Blue check mark, etc. Monita still doesn't get her own page, despite her role in the Luigi's Ghost Mansion minigame)
4. If the subject derived from the Mario franchise appears in a Nintendo-published or endorsed media that isn't considered guest appearance, a proposal is required before creating a page. (If Nintendo ever releases a game with a unique Mario subject that can't otherwise be considered a guest appearance title, wiki editors have an option to consider if it's worth covering anyway)

This is where Bombite comes into play:

Option 1: Similar appearance isn't enough to justify creating a new article. This option would result in the deletion of Bombite, its contents will be merged with the Zelda section of Bob-omb's article

Option 2: Similar appearance is a good justification for creating a new article for a distinct enemy. Bombite's page remains

Proposer: Axis (talk)
Deadline: July 27, 2024, 23:59 GMT

Option 1

1. Axis (talk) Per proposal
2. Hewer (talk) Connecting Bombite to Bob-omb does feel like a stretch, so yeah it doesn't need an article.

Comments

How is "Option 2" any different from "Oppose"? Doesn't this proposal just decide whether Bombite stays or goes? Hewer (talk · contributions · edit count) 08:23, July 20, 2024 (EDT)

It's about standardizing it so there's something to refer to in case something like this comes up again. Both options support the new standart, the difference is whether or not visual similary qualifies as a connection Axis (talk) 08:31, July 20, 2024 (EDT)

A somewhat recent proposal about the coverage of the Rhythm Heaven series decided that Rhythm Heaven minigames with WarioWare characters in them (including Kung Fu Ball from Rhythm Heaven Fever, the debut of Cicada) should not get dedicated articles. Would this new definition overturn that decision? jan Misali (talk · contributions) 08:33, July 20, 2024 (EDT)

It is not within the scope of this proposal, no Axis (talk) 08:40, July 20, 2024 (EDT)

Miscellaneous

Create a list of official hashtags

This proposal targets the creation of an index for social media hashtags that:

1. relate to the Mario series;
2. were used or otherwise disseminated by Nintendo, a representative, or any other official partner in the context of a Mario product.

If a hashtag meets these two criteria, it's eligible for inclusion no matter which social media network it's used on. It could be YouTube, Twitter, Facebook, Instagram, TikTok, you name it.

These hashtags count as official content, so I figured what's not to gain from having them gathered up in a historical record? I haven't seen anyone complain about the current list of fonts, which has a similarly huge scope and I assume is currently inexhaustive.

You can see how I envision the list's appearance in my sandbox, but this aspect is not enforced by the proposal and I am open to feedback. As you can see here, the list explains the context of each hashtag, cites references, and includes imagery appended to the hashtags upon use when applicable.

Proposer: Koopa con Carne (talk)
Deadline: July 21, 2024, 23:59 GMT

Create a list of official hashtags that only relate to Mario specifically

1. Koopa con Carne (talk) #perproposal
2. Hewer (talk) anything to improve our Wiggler Wednesday coverage Sure, per proposal.
3. Mario (talk) Weak support. Seems really particular and niche, but if someone is willing to do the motions for this, okay. I guess someone will find this useful, but I'm not really a social media user.
4. Jdtendo (talk) Eh, why not.

Comments

I think we're underestimating just how often Play Nintendo uses hashtags. I wouldn't be surprised if a big portion of them are one-offs. Axis (talk) 08:38, July 14, 2024 (EDT)

I don't really see the problem there. I like the idea of being as comprehensive as possible with our coverage. Hewer (talk · contributions · edit count) 14:43, July 17, 2024 (EDT)

The only thing I fear is that eventually people will stop maintaining this list, really. Axis (talk) 09:31, July 19, 2024 (EDT)

I'm hopeful given our very thorough coverage of other online promotional stuff. Hewer (talk · contributions · edit count) 09:35, July 19, 2024 (EDT)

TBH that was mostly maintained by me, Axis, and LuigiMaster123 lol -- KOOPA CON CARNE 10:34, July 19, 2024 (EDT)

As I'm looking for hashtags to fill up that page, I discover that Nintendo has seemingly only ever made one tweet with the hashtag "#Waluigi" across all of their Twitter accounts with "Nintendo" in the name. Just throwing this out there. -- KOOPA CON CARNE 17:11, July 19, 2024 (EDT)

#WaluigiWednesday lives on in our hearts Hewer (talk · contributions · edit count) 08:28, July 20, 2024 (EDT)