MarioWiki:Proposals
|
Saturday, November 23rd, 09:55 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.
|
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
- 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}}.
- Only autoconfirmed users may create or vote on proposals and talk page proposals. While only autoconfirmed users can comment on proposals, anyone is free to comment on talk page proposals.
- Proposals end at the end of the day (23:59) two weeks after voting starts (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 two weeks later on Monday, August 15, at 23:59 GMT.
- Users may vote for more than one option, but they may not vote for every option available.
- 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.
- 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 "(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.
- Proposals cannot contradict an already ongoing proposal or overturn the decision of a previous proposal that concluded less than four weeks (28 days) ago.
- 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.
- Use {{proposal check|early=yes}} to automate this calculation; see the template page for usage instructions and examples.
- 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.
- 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.
- After a proposal or talk page proposal passes, it is added to the corresponding list of "unimplemented proposals" below and is removed once it has been sufficiently implemented.
- If the wiki staff 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.
- Proposals can only be rewritten or canceled by their proposer within the first four days of their creation. However, proposers can request that their proposal be canceled by a staff member at any time, provided they have a valid reason for it. Please note that canceled proposals must also be archived.
- 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 handled by the bureaucrats.
- No joke proposals. Proposals are serious wiki matters and should be handled professionally. Joke proposals will be deleted on sight.
- 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, 14 days after the proposal was created, at 23:59 GMT, in the format: "November 23, 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. Place {{TPP}} under the section's header, 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 {{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.
List of ongoing talk page proposals
- Decide whether to create articles for Ashita ni Nattara and Banana Tengoku and/or include them on List of Donkey Kong Country (television series) songs (discuss) Deadline: November 23, 2024, 23:59 GMT
- Determine how to handle the Tattle Log images from Paper Mario: The Thousand-Year Door (Nintendo Switch) (discuss) Deadline: November 30, 2024, 23:59 GMT
- Merge False Character and the Fighting Polygon/Wireframe/Alloy/Mii Teams to List of Super Smash Bros. series bosses (discuss) Deadline: December 2, 2024, 23:59 GMT
Unimplemented proposals
Proposals
Break alphabetical order in enemy lists to list enemy variants below their base form, EvieMaybe (ended May 21, 2024) |
Standardize sectioning for Super Mario series game articles, Nintendo101 (ended July 3, 2024) |
- ^ NOTE: Not yet integrated for the Super Mario Maker titles, Super Mario Run, and Super Mario Bros. Wonder.
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) |
Add film and television ratings to Template:Ratings, TheUndescribableGhost (ended October 1, 2024) |
Use the classic and classic-link templates when discussing classic courses in Mario Kart Tour, YoYo (ended October 2, 2024) |
Split articles for the alternate-named reskins from All Night Nippon: Super Mario Bros., Doc von Schmeltwick (ended October 3, 2024) |
Clarify coverage of the Super Smash Bros. series, Doc von Schmeltwick (ended October 17, 2024) |
Remove all subpage and redirect links from all navigational templates, JanMisali (ended October 31, 2024) |
Prioritize MESEN/NEStopia palette for NES sprites and screenshots, Doc von Schmeltwick (ended November 3, 2024) |
Stop considering reused voice clips as references (usually), Waluigi Time (ended November 8, 2024) |
Allow English names from closed captions, Koopa con Carne (ended November 12, 2024) |
- ^ NOTE: A number of names coming from closed captions are listed here.
Remove identifiers for Steve (NES Open Tournament Golf) and Ike (The Super Mario Bros. Super Show!), Starluxe (ended November 21, 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) |
Split Banana Peel from Banana, Doc von Schmeltwick (ended September 18, 2024) |
Merge Spiked Thwomp with Thwomp, Blinker (ended November 2, 2024) |
Create articles for specified special buildings in Super Mario Run, Salmancer (ended November 15, 2024) |
Expand and rename List of characters by game to List of characters by first appearance, Hewer (ended November 20, 2024) |
List of talk page proposals
Template:TPPDiscuss Template:TPPDiscuss Template:TPPDiscuss Template:TPPDiscuss Template:TPPDiscuss Template:TPPDiscuss Template:TPPDiscuss Template:TPPDiscuss Template:TPPDiscuss
Writing guidelines
None at the moment.
New features
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 MarioWiki: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: Time Turner (talk)
Deadline: August 11, 2017, 23:59 GMT
Support
- Time Turner (talk) Per proposal.
- Alex95 (talk) - 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.
- Yoshi the SSM (talk) I really see the benefit of this. Per all.
- Niiue (talk) Per all.
- TheFlameChomp (talk) Per all.
- Supermariofan67 (talk) Per all.
- Baby Luigi (talk) 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.
- Wildgoosespeeder (talk) {{SettledTPP}} with its category Category:Settled talk page proposals is insufficient compared to MarioWiki:Proposals/Archive.
- Chester Alan Arthur (talk) I agree from a navigational perspective this would be much better.
- Ghost Jam (talk) Per all.
Oppose
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. Ray Trace(T|C) 22:50, 4 August 2017 (EDT)
- It's ostensibly going to be the same as MarioWiki:Proposals/Archive, just with different links. Still, I can try to quickly whip something up. Hello, I'm Time Turner. 22:52, 4 August 2017 (EDT)
- I have a very rough draft here: it'll obviously be increased and adjusted as time goes on. Hello, I'm Time Turner. 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). Hello, I'm Time Turner. 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. Hello, I'm Time Turner. 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. Yoshi the SSM (talk) 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. Hello, I'm Time Turner. 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. Hello, I'm Time Turner. 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. Hello, I'm Time Turner. 18:32, 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)
- 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. Hello, I'm Time Turner. 18:11, 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)
- It'd be hard to distinguish between light blue and regular blue at a glance, especially since our current blue is already fairly light. Hello, I'm Time Turner. 17:41, 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. Yoshi the SSM (talk) 17:39, 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. Hello, I'm Time Turner. 11:46, 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. Hello, I'm Time Turner. 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. Hello, I'm Time Turner. 19:00, 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)
Removals
None at the moment.
Changes
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 [[Blooper|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 Alex95 (talk). However, I'm not entirely in agreement with the outcome.. To outline the pros and cons of the current situation:
Pros:
- It's historically accurate.
Considering that these names were consistently used until they happened to be changed, it naturally follows that our articles reflect that.
- It's what people familiar with the old names would look for.
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.
Cons:
- It's not currently accurate.
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 confusing, especially for newcomers.
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.
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: Time Turner (talk)
Deadline: August 8, 2017 23:59
Use new names for articles
- Time Turner (talk) My personal preference.
- Niiue (talk) As much as I dislike certain new names (looking at you, Bull's-Eye Bill), standardization is best.
Use old names for articles
- Alex95 (talk) - 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.
- Doc von Schmeltwick (talk) - Fire Chomp, Podoboo, Grand Goomba, Venus Fire Trap, and Missile Bill for life!
- 7feetunder (talk) - Per my comments below.
- TheFlameChomp (talk) Per all.
- Yoshi the SSM (talk) Per all.
- LuigiMaster123 (talk) Per all.
- Mister Wu (talk) 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 ?
- Chester Alan Arthur (talk) 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. Hello, I'm Time Turner. 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." – Shokora (talk · edits) 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. Hello, I'm Time Turner. 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? Hello, I'm Time Turner. 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: 7feetunder (talk)
Deadline: August 12, 2017, 23:59 GMT
Support
- 7feetunder (talk) Per proposal.
- Niiue (talk) Per proposal.
- Yoshi the SSM (talk) Per Proposal
- Baby Luigi (talk) 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.
- Alex95 (talk) - The mission articles go into detail about the secret areas anyway. Support.
- TheFlameChomp (talk) Per all.
- Mister Wu (talk) 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
- Doc von Schmeltwick (talk) 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.
Comments
Miscellaneous
Standardization of Species Templates' Endings
This is a simple issue: when it comes to navigation templates based on species, some are pluralized (e.g. {{Boos}} and {{Koopa Troopas}}), and some are singularized (e.g. {{Human}} and {{Koopa Paratroopa}}). 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: Time Turner (talk)
Deadline: August 7, 2017, 23:59 GMT
Pluralize
- Time Turner (talk) Makes the most sense to me.
- Alex95 (talk) Per. I assume a bot will take care of this. If not, I'm willing to help.
- Doc von Schmeltwick (talk) 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.
- Yoshi the SSM (talk) 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.
- Ultimate Mr. L (talk) Singular just sounds wrong.
- TheFlameChomp (talk) Per all.
- YoshiFlutterJump (talk) Per all.
- Supermariofan67 (talk) Per all.
- Niiue (talk) Per all.
- Toadette the Achiever (talk) I see no reason not to do this, so per all.
- Tails777 (talk) I mean we're mostly covering multiple subjects so... yeah, per all.
- Jazama (talk) Per all
Singularize
Do nothing
Comments
Full list of covered templates:
- Already plural:
- {{Bandits}}
- {{Barrels}}
- {{Blarggs}}
- {{Blocks}}
- {{Bloopers}}
- {{Boos}}
- {{Buzzy Beetles}}
- {{Chain Chomps}}
- {{Cheep Cheeps}}
- {{Doors}}
- {{Flowers}}
- {{Goals}}
- {{Hammer Bros.}}
- {{Koopa Troopas}}
- {{Kremlings}}
- {{Lava Bubbles}}
- {{Magikoopas}}
- {{Morphs}}
- {{Mushrooms}}
- {{Octoombas}}
- {{People}}
- {{Piranha Plants}}
- {{Shamans}}
- {{Shy Guys}}
- {{Snifits}}
- {{Spikes}}
- {{Spinies}}
- {{Stars}}
- {{Toads}}
- {{Wigglers}}
- {{Yoshis}}
- Already singular:
- {{Bob-omb}}
- {{Bullet Bill}}
- {{Fuzzy}}
- {{Goomba}}
- {{Human}}
- {{Kong}}
- {{Koopa Paratroopa}}
- {{Lakitu}}
- {{Little Mouser}}
- {{MontyMole}}
- {{Pianta}}
- {{Pokey}}
- {{Thwomp}}
@Alex: The plan is to have a bot take care of the dirty work. Hello, I'm Time Turner. 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: Niiue (talk)
Deadline: August 8, 2017, 23:59 GMT
Use species categories only for non-hostile, non-item, non-object species
- Niiue (talk) Per proposal.
- 3D Player 2010 (talk) per all.
- Time Turner (talk) 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.
- Alex95 (talk) Woo boy, this looks messy. Per all.
- Jazama (talk) Per all
- TheFlameChomp (talk) Per all.
- Yoshi the SSM (talk) Sure. Per all.
Use species categories only for non-hostile species
Delete species categories
Do nothing
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.