MarioWiki:Proposals

Writing guidelines
None at the moment.

New features
None at the moment.

Trim extraneous Game & Watch coverage
As it currently stands, we cover too much information on a lot of our Game & Watch pages. As the result of a proposal a couple years back, aside from the ones that are Mario-related, we only cover the games that appeared in the Game & Watch Gallery games with modern remakes that include Mario information. But those games that remain covered are covered in full, leaving us with a lot of information that's irrelevant to the scope of the wiki. If you need an example, just look at the page for Ball and see how much of the information here isn't related to Mario at all. Therefore, I propose that we cut these articles down and focus on their Mario-relevant appearances as minigames in the Game & Watch Gallery series, while still taking care to properly acknowledge and address their origins.

This will remove coverage of the original systems themselves, the classic versions of the games, ports, and other miscellaneous pieces of information, such as references to the original games in Smash. Basically, if it doesn't relate to the modern, Mario-relevant versions of the game, or isn't relevant to Mario in some other way (i.e. Ball's Mario-themed appearance in the SMB Game & Watch), it goes.

Affected articles:
 * Ball
 * Boxing
 * Chef
 * Egg (Game & Watch)
 * Fire (Game & Watch)
 * Helmet (Game & Watch)
 * Manhole (Game & Watch)
 * Octopus (Game & Watch)
 * Oil Panic
 * Parachute (Game & Watch)
 * Rain Shower
 * Turtle Bridge
 * Vermin

I've intentionally omitted Greenhouse from the scope of this proposal since it's the first appearance of Stanley the Bugman and has some relevance, but it can be re-assessed at a later time if preferred.

Proposer: Deadline: June 10, 2022, 23:59 GMT

Support

 * 1) Beep boop (per all).
 * 2) 011100000110010101110010 (per)
 * 3) Per all.

Comments
Do you think those article this information could be moved to NintendoWiki? 18:29, June 3, 2022 (EDT)


 * If this is to pass, I definitely think we should help move all our information to the NWiki. It could potentially be a lot of hard work and thoroughly researched information disappearing.
 * They seem to have pages already, but if there's any information that's missing over there, I don't see why not. -- 19:19, June 3, 2022 (EDT)

Discount resized enemies from Mario Kart Tour as "big" variants of the base enemy
The wiki currently regards upscaled enemies from Mario Kart Tour as distinct, "Big" derivatives of the template enemy, e.g. the large Piranha Plants from SNES Choco Island 2T, SNES Ghost House 1R etc. are taken to be "Big Piranha Plants". Admittedly, I was the one who made this distinction back when I set up the "course elements" table on the game's article, listing large-sized Piranha Plants separately from normal-sized counterparts; later on, an article for Big Sidestepper, an upscaled Sidestepper that only appears in Mario Kart Tour, was created and a corresponding entry was added to the aforementioned table.

One issue with the above is that, regardless of their size, Piranha Plants all share a "Piranha Plant" label on the in-game action display. The other enemies to appear with upscaled models, namely large Goombas and large Sidesteppers, are not labelled at all since they only appear in bonus challenges, where player actions are typically not displayed (except for Combo Attack, which to my recollection has yet to feature any instances of the latter two). Another issue stems from the fact that these enemies may not have been rescaled at a consistent size: for instance, RMX Choco Island 1R/T features an exceptionally humongous Piranha Plant (youtube.com) that visibly tops other already large-sized Piranha Plants appearing in other courses (youtube.com). If there isn't one specific "L" size these enemies comply with, is it warranted to have the larger enemies lumped together as the "Big" variant considering larger-but-still-intermediary-sized enemies, such as Hefty Goombas from New Super Mario Bros. Wii, are considered separate from their maximum-sized counterparts despite having a few shared names? In addition to everything said here, an enemy always behaves the same regardless of its model's size, as opposed to, say, Super Mario Maker big variants which, while not specifically labelled in-game as "big", may feature distinctive quirks from their normal counterparts.

In light of these points, I propose the following two courses of action as options:
 * 1) remove any listings of these rescaled enemies as distinct counterparts for Mario Kart Tour (i.e. remove their entries from the "Course elements" table, the MKT template, and the Mario Kart Tour enemies category), and restrict any mention of them appearing in different sizes to the base enemy's article (i.e. purge such information from the "Big [enemy]" articles);
 * 2) remove any listings of these rescaled enemies as distinct counterparts for Mario Kart Tour (i.e. remove their entries from the "Course elements" table, the MKT template, and the Mario Kart Tour enemies category), but retain/allow mentions of them appearing in different sizes on the "Big [enemy]" articles.

In either scenario, the Big Sidestepper article gets deleted, since Big Sidesteppers have yet to actually appear in a game where they are acknowledged as such or behave differently.

Proposer: Deadline: June 9, 2022, 23:59 GMT

Option 2

 * 1) I prefer this option myself. Despite the game's stance, a large enemy should have a passing mention where size is of interest.
 * 2) Per proposal. Even if both sized Piranha Plants appear, it’s worth mentioning as much at least.

Comments
This may be an issue for the Mario Kart series in general as several guides don't use the "big" distinction. What about cases like Mega Rabbit from Super Mario 3D World, which is referred to as just a "Rabbit" in Bowser's Fury missions (main article is currently mistaken)? LinkTheLefty (talk) 11:00, June 4, 2022 (EDT)
 * I feel like that's just be a case of "If one design of an enemy is officially called larger and big designs of that enemy are used in later games, leave it on the big page", similar to how the Big Amps from MP5 are just called amps and are only slightly bigger than normal amps, but they're still on the Big Amp page. Somethingone (talk) 11:19, June 4, 2022 (EDT)

Decide how to cover Mario Kart Tour bonus challenges on course articles
The layout of each bonus challenge in Mario Kart Tour (e.g. Ring Race) depends on the course in which it is set. It tracks, therefore, that these challenges should be covered in detail on their relevant course articles in addition to their parent article. If you wish to see how a course article would look with coverage of its bonus challenges, scroll down to the "Mario Kart Tour" section in the "History" section here.

However, bonus challenges have been observed to appear multiple times across the game's tours, sometimes with changed objectives, which prompts wiki users to regularly update their list entries. Simply copying and pasting these entries onto another article would make it more difficult for users to be aware of which needs to be updated where. On the other hand, adding a way to transclude entire entries (allow information entered on a page to be automatically transferred to another) would spaghettify the original code and potentially deter users from updating it with new information. For instance, this is how the code for an average bonus challenge entry currently looks:


 * MKT Tour1 YoshiCupChallenge.png
 * New York Minute
 * MKT Icon Yoshi.png Yoshi
 * MKT Icon PipeFrameLimeGreen.png Pipe Frame
 * MKT Icon SuperGliderLimeGreen.png Super Glider
 * 5
 * 8
 * 12
 * New York Tour
 * 12
 * New York Tour

(source: Do Jump Boosts article)

and this is how it would look with a transclusion mechanism in place:

A bit ugly, innit? On average, this would only save a small number of bytes on the target article--less than 100, really. Picture, now, an entire table with the same code plastered repeatedly. I believe the wiki should account for editor friendliness too, especially when the returns of optimisation are disappointing.

I am not sure how to proceed here. I am unwilling to go ahead with either option unless I have a clear-cut vision of each one's net advantages. I will thus be resorting to the community's choice.

Proposer: Deadline: June 9, 2022, 23:59 GMT