MarioWiki:Proposals

Writing guidelines
None at the moment.

Create an archive system for talk page proposals
Once more, with feeling. I'm aware of the previous failed proposal, but frankly, I don't agree with the opposition. Yes, talk page proposals don't affect as many pages as regular proposals (usually), but at the same time, they're still affecting pages, and that can easily have repercussions as well as set a precedent for the future. If a user is unsure if there's anything to support something that they want to do, they can look through the archive of proposals and see if any similar proposals have happened as well as their outcomes. That's certainly something I've done with the regular proposals, so I don't think it's unreasonable to do the same for talk page proposals. To use a concrete example, for my proposal on implied subjects, I had to dig through history pages and rely on my terrible memory to find talk page proposals that were relevant to my own; why not make the process simpler? Also, pointing people to the category as a suitable substitute when it gives no details about the content of the proposals, when they happened, what their outcome was, or even if multiple proposals happened on the same page is not satisfactory for me. Banana's talk page has six separate proposals (and it's hardly the only one of its kind), but that fact becomes completely obfuscated if we only use the category. Also, if we relied on categories for everything, we wouldn't have navigation templates. Besides, this only requires a single page.

Like the original proposal, I'm not planning on literally making an archive that houses every talk page proposal: I want to create a page that emulates Proposals/Archive, but instead of linking to subpages with every proposal, I would be simply linking to the original talk pages. This gives added clarification and convenience, and I really don't see why we shouldn't have it.

Proposer: Deadline: August 11, 2017, 23:59 GMT

Support

 * 1) Per proposal.
 * 2) - I was thinking about making a proposal like this myself, but I wasn't sure how to go about it. I get lost looking for TPPs, especially if it's one I wasn't aware existed in the first place (and there have been a few occasions where finding a past TPP would've help me, but I just couldn't find it). A condensed page similar to the main proposal archive can work, so I support.
 * 3) I really see the benefit of this. Per all.
 * 4) Per all.
 * 5) Per all.
 * 6) Per all.
 * 7) I don't like the argument that "it's not hard to find TPPs" which was the primary reason to oppose in the previous proposal. History has shown and some users stated, yes, it IS harder to find the proposals by browsing through an endless assortment of pages listed by categories. And I don't understand why we can't take the time and effort to improve navigation and organization of these things: depending on your perspective, TPPs can be more major than main space proposals, and it has spawned paragraphs and paragraphs of discussion. Plus, I don't see how lesser importance means that we should completely ignore still facets that have an influence in changing around policy, regardless of scale. I say, the correct move is to take effort and organize them better and it'd would benefit pretty much everyone in the long-term.
 * 8)  with its category Category:Settled talk page proposals is insufficient compared to Proposals/Archive.

Comments
I think you should have drafted a sandbox page for this before you made a proposal out of it, see what it looks like before we cast a vote on this. 22:50, 4 August 2017 (EDT)
 * It's ostensibly going to be the same as Proposals/Archive, just with different links. Still, I can try to quickly whip something up. 22:52, 4 August 2017 (EDT)
 * I have a very rough draft here: it'll obviously be increased and adjusted as time goes on. 23:56, 4 August 2017 (EDT)

Now that I'm going through the talk page proposals, I'm noticing that there are a few proposals that are canceled and then immediately put into effect, usually because the proposed change is valid but the whole proposal process is unnecessary. Would anyone object if I added a color for these situations? I'm thinking mauve would look alright (and it's on the mock-up; search for Axem or Gargantua). 11:02, 5 August 2017 (EDT)
 * I think white would be better, as mauve might be confusing for color-blind people (like me) with purple. I think blue is what's normally used in this case, though. 11:42, 5 August 2017 (EDT)
 * Blue is meant for proposals that fail, but whose proposed changes are later implemented anyways. A canceled proposal is different from a failed proposal - that's why we have both red and pink. I can definitely change the color, but since white is also what generically appears if a color hasn't been inputted correctly, I think that might be confusing. EDIT: Actually, if we're concerning ourselves with colorblindness, then the current color system has its own issues. 11:46, 5 August 2017 (EDT)
 * Here is a suggestion. If a proposal was cancelled but changes took place after the proposal, than it would be light blue. It's not much of a difference, but a difference nevertheless. 17:39, 5 August 2017 (EDT)
 * It'd be hard to distinguish between light blue and regular blue at a glance, especially since our current blue is already fairly light. 17:41, 5 August 2017 (EDT)
 * We could use black, but then the text would have to change accordingly. As for blue, apparently the color we're using is lighter than the #0000FF code for standard blue. So with that in mind, maybe dark blue? 17:50, 5 August 2017 (EDT)
 * If the blue's too dark, then we come to the same issue as using black (and in fact, the standard "DarkBlue" or "Navy" is definitely too dark). The template also isn't currently set up for changing the text color, and in any case, I think that it'd be best to keep the text uniform. For now, I've thrown more colors onto the table at the top for demonstrative purposes. If you have a particular color in mind, this website works well for testing how it would like against black text. 18:11, 5 August 2017 (EDT)
 * The problem I think we're having is we've used all the basic colors; any others we chose aside from a very light or a very dark color will end up looking close to ones we're already using. Dark blue doesn't look too bad, imo, though ivory, light yellow, slate, and chartreuse (as ugly as that is) are some other possible options. 18:23, 5 August 2017 (EDT)
 * It'd be more convenient if you could provide hex color codes that show exactly what you're talking about, if you don't mind. 18:32, 5 August 2017 (EDT)
 * Ivory: #FFFFF0, Light yellow: #FFFFE0, Slate: #708090, and Chartreuse: #7FFF00. The dark blue I was thinking of was actually Dark cyan, my mistake there: #008B8B. 18:41, 5 August 2017 (EDT)
 * Threw all of those colors up there for good measure. Now that they're all up there, I'm partial to dark cyan. Everything else is either illegible or too similar to another (established) color. 18:47, 5 August 2017 (EDT)
 * darkcyan looks the best out of them all, imo. Is there a chance this new parameter could be added to main proposals as well, just in case something like that happens here in the future? 18:51, 5 August 2017 (EDT)
 * I'll start using that for now, then (although I'll call the parameter "teal" for convenience). I'll leave the discussion of implementing it with the main proposals to you administrators. 19:00, 5 August 2017 (EDT)

Removals
None at the moment.

The Usage of Old Names in Articles
Currently, it's standard practice to use the old name of a subject while writing about in at a point in time where that old name was in use. For example, Blooper was called "Bloober" in Super Mario Bros., so "Bloober" would be used when talking about Super Mario Bros. instead of the more recent name. If a link is involved, it would be coded as Bloober, always maintaining the old name. Though this isn't outlined in the policy pages, as far as I can tell, there was a proposal that set out to outline this exact issue, and ultimately decided to use old names when relevant (thank you . However, I'm not entirely in agreement with the outcome.. To outline the pros and cons of the current situation:

Pros:

Considering that these names were consistently used until they happened to be changed, it naturally follows that our articles reflect that.
 * It's historically accurate.

To use the cartoons as an example, they regularly and consistently refer to Princess Peach as "Princess Toadstool". Anyone who is familiar with the cartoons would be looking for the name Toadstool and not Peach. This extends to any of the old names, really: whether it was in the cartoons, the manuals, or the guides, these names were prominent.
 * It's what people familiar with the old names would look for.

Cons:

Regardless of how consistently the old names were used, these are not the names being used today. For an encyclopedia, using the old names in articles and templates without so much as a note seems misleading.
 * It's not currently accurate.

Not everyone knows that Princess Peach's old name was "Princess Toadstool". The similarities in the names are there, but it's certainly not a given that these two names refer to the same subject. To use the cartoons as an example, someone with little knowledge of the series may read one of its pages and leave without realizing that Princess Toadstool actually refers to Princess Peach.
 * It's confusing, especially for newcomers.

To me, it makes more sense to keep articles up-to-date rather than potentially mislead readers, though I'm giving each option equal opportunity. (For the record, the MarioWiki:Naming does state that "the newer name will replace the older one" while using Blooper as an example, but as far as I can tell, that hasn't been put into effect beyond the article's name and usage in modern games.)

Proposer: Deadline: August 8, 2017 23:59

Use new names for articles

 * 1) My personal preference.
 * 2) As much as I dislike certain new names (looking at you, Bull's-Eye Bill), standardization is best.

Use old names for articles

 * 1) - I'm leaning towards to result of the original proposal. While yes, some readers may get confused, the purpose of the wiki is to display and show information as accurately as possible.
 * 2) - Fire Chomp, Podoboo, Grand Goomba, Venus Fire Trap, and Missile Bill for life!
 * 3) - Per my comments below.
 * 4) Per all.
 * 5) Per all.
 * 6) Per all.
 * 7) Since ultimately the links then reveal what the current name of the subject is, I think that using the modern names can be extremely confusing in the case of games where the old name is showed by the game itself, especially for bestiaries where we are supposed to show the actual name used by the game. As an example, we just discovered in the 30th anniversary books that the bats of Super Mario Galaxy games have the same Japanese name of Enigmas and are thus very likely to be those bats, but there they are known in English as Bats. What would happen if we ended up using the new name also in the pages and tables related to Super Mario RPG: Legend of the Seven Stars ?
 * 8) Gonna have to agree with Alex since those were the names at the time.

Comments
I know I helped you find some of the information, but I'm voting against. Blooper's name in Super Mario Bros. was "Bloober", for example, so it makes sense to call it by that name where relevant. If readers end up trying to correct the name to its modern variant, we can always revert it; posting something in the edit summary or their talk page if needed. 00:25, 1 August 2017 (EDT)
 * Not every user is an editor who plans on changing the wiki. The average person wouldn't know about the name change, so they'd fully believe that the white squid enemy from Super Mario Bros was a Bloober, and not a Blooper. It seems rather disingenuous to use old names without ever mentioned that they've changed names. 00:28, 1 August 2017 (EDT)

Why can't we just advise users to say "Bloober, later known as Bloopers, appear in Super Mario Bros.. Bloobers blob around in water levels, etc." 01:53, 1 August 2017 (EDT)

Definitely opposing this. While I can kind of see the benefit to enacting this change for franchise mainstays with a "dominant" new name, like Peach and Blooper, for less prominent stuff, it's just confusing and awkward. For example, Goomba King/Goomboss. He only appears in three games. His article uses "Goomboss" because that's his most recent name, but people looking up information on Paper Mario are going to be annoyed/confused if we call him "Goomboss" even on those articles. His name in that game is clearly "Goomba King", so that's what articles relating to PM call him. I see no reason to change this. Or, for another example, the Sluggish/Slow 'Shroom Orb, an item only appearing in two games within the same series. Mario Party 6 calls it a Sluggish 'Shroom, Mario Party 7 calls it a Slow 'Shroom. Neither name is more "correct" than the other, so MP6 articles use "Sluggish" and MP7 articles use "Slow". 01:59, 1 August 2017 (EDT)


 * On one hand, it's somewhat retroactive to apply the newer names to certain articles; on the other hand, it's more consistent, is already noted just fine in the body of their own articles, and there have been official cases where more recent names were used in re-releases in favor of the older ones (like in remakes and some Virtual Console digital manuals; for example, mushroom retainers are called Toads in the 3DS Virtual Console and Wii Super Mario All-Stars manuals for Super Mario Bros., and "Magic Mushroom" completely fell by the wayside). Then there are others like Blooper and Nipper Plant that were in use in strategy guides, or instances where a given subject was only named in foreign content at times and its newer English name is preferred instead. We're specifically talking about video games, right? It would be iffy to use Peach and Bowser when referring to the DIC cartoons when they were nothing but Toadstool and Koopa during the entire run. It'd also be confusing to do this for the RPG bestiaries and info boxes, if that's considered under this proposal. What about obvious misspellings like Racoon Mario and pirana plant? Are we sticking to those just because they were contemporary? I feel like there should be a middle ground: in-game and manual elements could use whatever name they had at the time (universally preserving the very well-known changes of Peach/Toadstool, Bowser/Koopa, Starman/Super Star, RPG name changes, etc.), but names that only came from old guides are most probably obscure enough to be standardized with the more recent material. Basically, make it into a source hierarchy like the naming policy. LinkTheLefty (talk) 02:40, 1 August 2017 (EDT)
 * @Mister Wu: This is just an aside, but I very much doubt that Enigma example is intentional because Square/Square Enix most likely holds the copyright for it. LinkTheLefty (talk) 10:46, 1 August 2017 (EDT)
 * I definitely concede that mass-changing every name would do more harm than good, but at the same time, I agree with LTL in that there should be some sort of hierarchy or a well-defined system for deciding how names should be used in articles. Your point about "pirana plant" is good too: why does Super Mario Bros. uses "Bloober" for Blooper but not "pirana plant" for Piranha Plant? I'm not sure if manuals should take the same precedence as games, though, especially since most games don't require the use of the manual. 16:27, 2 August 2017 (EDT)

I think the old names should be kept for the games where they were used, while including notes of the names that are currently used. For example, "Princess Toadstool (early name of Princess Peach until Super Mario 64)" or "Flopsy Fish (the name used of Cheep Cheep in this game)". SmokedChili (talk) 05:20, 4 August 2017 (EDT)
 * What do you mean by "the games where they were used"? Are manuals and official guides also counted under that? 13:17, 5 August 2017 (EDT)
 * I was thinking "a game and its manual and possibly a guide", although I could have worded that better like "material where they were used". I wrote that comment rather roughly at the time. SmokedChili (talk) 13:50, 5 August 2017 (EDT)

Merge Super Mario Sunshine sub-level articles into their missions' articles
We currently have articles for various sub-levels from Super Mario Sunshine (e.g. Sand Portal, Bottle). These are obviously just artifacts from before the game's missions were split off. Now that we have the mission articles, the sub-level articles themselves are completely obsolete; we now have several pairs of articles covering the exact same thing. Some of them even have conjectural names derived right from the mission names (Hotel Lobby's Secret, Shell's Secret), which not only emphasizes the redundancy but adds confusion. So any relevant content on these articles not already on the mission articles should just be moved to those. It's not like we generally have separate articles for sub-levels anyway; we don't have articles for Shifting Sand Land's pyramid or Lethal Lava Land's volcano.

Here are what the results of this proposal will be if it passes:
 * Hillside Cave --> The Hillside Cave Secret
 * Cliff Spring Cave --> The Secret of the Dirty Lake
 * Ricco Tower --> The Secret of Ricco Tower
 * Sand Portal --> Dune Bud Sand Castle Secret
 * The Yoshi-Go-Round --> The Yoshi-Go-Round's Secret
 * Hotel Lobby's Secret --> The Hotel Lobby's Secret
 * Bottle --> Red Coins in a Bottle
 * Shell's Secret --> The Shell's Secret

The secret levels in Delfino Plaza (Super Slide, Pachinko Game, Lily Pad Ride, Turbo Track, Red Coin Field) are not affected by this proposal. They fall under the same category as levels like The Princess's Secret Slide and The Secret Under the Moat, and should stay.

Proposer: Deadline: August 12, 2017, 23:59 GMT

Support

 * 1) Per proposal.
 * 2) Per proposal.
 * 3) Per Proposal
 * 4) Some of these names aren't even "names" per se, they're just descriptive locations, like hillside cave. Anyway, most of these are pretty much the equivalent of our planet sections in the Super Mario Galaxy articles, so I think a merge is sufficient.
 * 5) - The mission articles go into detail about the secret areas anyway. Support.
 * 6) Per all.
 * 7) If we can indeed cover the sub-levels in the mission pages without losing any amount of relevant detail and without creating pages that are too long and difficult to browse, I definitely support the idea of writing everything in one page.

Oppose

 * 1) I think the Episode description should describe the entire mission, including getting to the secret, but not getted bogged down with every geographical detail of said secret level's layout, which the article for the secret area should have instead.

Standardization of Species Templates' Endings
This is a simple issue: when it comes to navigation templates based on species, some are pluralized (e.g. and ), and some are singularized (e.g.  and ). A majority of them are already plural, but most of the singular templates are for the well-known species. There's no reason why we shouldn't have consistency, so enough's enough. I personally think that it makes much more sense to pluralize all of them, but considering the number of templates that are singular, I'm including both options for fairness. Obviously, this is not even close to a major issue, but at the same time, for such a minor issue, it has yet to be cleared up, and having a uniform system makes the wiki seem all the more professional.

Proposer: Deadline: August 7, 2017, 23:59 GMT

Pluralize

 * 1) Makes the most sense to me.
 * 2) Per. I assume a bot will take care of this. If not, I'm willing to help.
 * 3) Having them in singular at all is confusing, and there's only a few singular as it is, instead of the large amount of plurals there is. Less bot work.
 * 4) The templates that are singular have plural names on their headers. Also, I should point out that you didn't include an oppose. Which, I would have chosen if I didn't look at the templates.
 * 5) Singular just sounds wrong.
 * 6) Per all.
 * 7) Per all.
 * 8) Per all.
 * 9) Per all.
 * 10) I see no reason not to do this, so per all.
 * 11) I mean we're mostly covering multiple subjects so... yeah, per all.
 * 12) Per all

Comments
Full list of covered templates:
 * Already plural:
 * Already singular:
 * Already singular:
 * Already singular:
 * Already singular:
 * Already singular:
 * Already singular:
 * Already singular:
 * Already singular:
 * Already singular:
 * Already singular:
 * Already singular:
 * Already singular:
 * Already singular:
 * Already singular:
 * Already singular:
 * Already singular:
 * Already singular:
 * Already singular:
 * Already singular:
 * Already singular:
 * Already singular:
 * Already singular:
 * Already singular:
 * Already singular:
 * Already singular:
 * Already singular:
 * Already singular:
 * Already singular:
 * Already singular:
 * Already singular:
 * Already singular:
 * Already singular:

@Alex: The plan is to have a bot take care of the dirty work. 00:25, 31 July 2017 (EDT)

Do Something With Game-Specific Species Categories
So, Time Turner noticed a while back that Category:Super Mario Bros. 3 Species (and most games' species categories as a whole) are basically duplicates of their enemy categories, with maybe one or two different pages. Overall, species categories as they currently stand are useless and redundant. I've included a few options on how to fix this:

Use species categories only for non-hostile, non-item, non-object species: This would redefine species categories to only count creatures that aren't enemies, aren't items, and aren't objects. In other words, they'd only be for things like Egg-Plants, Humans, Piantas, and the like.

Use species categories only for non-hostile species: Similar to the previous option, except it would also include things like Fire Flowers and Beanstalks. The problem I see here is that items and objects already have their own categories, so we'd just end up with another set of redundancies.

Delete species categories: One of the simpler options. Just get rid of every game-specific species category on the wiki, and leave articles like Bird (Super Mario Sunshine) in categories like Category:Real World Animals.

Do nothing: The simplest option. As this would involve not changing anything, I feel it'd be the most detrimental option.

Proposer: Deadline: August 8, 2017, 23:59 GMT

Use species categories only for non-hostile, non-item, non-object species

 * 1) Per proposal.
 * 2) per all.
 * 3) I think this is the best option. It gives a home to a small, but well-defined, group of articles that wouldn't otherwise have a place in one of the main categories, while also ensuring that there's little to no overlap.
 * 4) Woo boy, this looks messy. Per all.
 * 5) Per all
 * 6) Per all.
 * 7) Sure. Per all.

Comments
Obligatory list of affected categories:

Category:Donkey Kong Species Category:Donkey Kong 64 Species Category:Donkey Kong Country Returns Species Category:Donkey Kong Country: Tropical Freeze Species Category:Mario & Luigi: Bowser's Inside Story Species Category:Mario & Luigi: Partners in Time Species Category:Mario & Luigi: Superstar Saga Species Category:Mario Power Tennis Species Category:Mario Strikers Charged Species Category:New Super Mario Bros. Species Category:New Super Mario Bros. 2 Species Category:New Super Mario Bros. U Species Category:New Super Mario Bros. Wii Species Category:Paper Mario Species Category:Paper Mario: Color Splash Species Category:Paper Mario Series Species Category:Paper Mario: Sticker Star Species Category:Paper Mario: The Thousand-Year Door Species Category:Super Mario 3D Land Species Category:Super Mario 3D World Species Category:Super Mario 64 Species Category:Super Mario Bros. Species Category:Super Mario Bros. 2 Species Category:Super Mario Bros. 3 Species Category:Super Mario Galaxy Species Category:Super Mario Galaxy 2 Species Category:Super Mario Strikers Species Category:Super Mario Sunshine Species Category:Super Mario World Species Category:Super Paper Mario Species Category:Super Smash Bros. Series Species Category:Wario Species Category:WarioWare Series Species Category:Yoshi Species

A lot of these could probably be deleted, since a lot of them (especially platformer ones) have pretty much 100% overlap with their games' respective enemy categories.

Also: wut Niiue (talk) 20:44, 31 July 2017 (EDT)