MarioWiki:Proposals

Current time: Wednesday, September 18th, 02:35 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

None at the moment.

Removals

None at the moment.

Changes

Shorten disambiguation identifiers "(Super) Nintendo Entertainment System" to "(S)NES"

The console names "Nintendo Entertainment System" and "Super Nintendo Entertainment System" are way too long and clunky, so much so that the abbreviations "NES" and "SNES" are commonly used in the body of articles throughout the wiki, even though we usually don't use abbreviations. And yet, we still use the full console names in the disambiguation identifiers of article names:

• Mario is Missing! (Nintendo Entertainment System)
• Mario is Missing! (Super Nintendo Entertainment System)
• Wario's Woods (Nintendo Entertainment System)
• Wario's Woods (Super Nintendo Entertainment System)

The identifiers are so long that they take up more than half of the article name and are less immediately legible than their respective abbreviations. This is particularly jarring on the Mario is Missing! disambiguation page because the abbreviations are used on the page (e.g., "Mario is Missing!, the NES game") but it links to articles with names containing the full console names ("Mario is Missing! (Nintendo Entertainment System)").

That's why I propose to shorten "Nintendo Entertainment System" and "Super Nintendo Entertainment System" to "NES" and "SNES" respectively in disambiguation identifiers of article names:

• Mario is Missing! (NES)
• Mario is Missing! (SNES)
• Wario's Woods (NES)
• Wario's Woods (SNES)

Please note that there is already an article which uses an abbreviated identifier: "Building World (Mario's Early Years! Fun with Letters for SNES)", although if we decide to keep the full identifiers, maybe we should rename it to "Building World (Mario's Early Years! Fun with Letters for Super Nintendo Entertainment System)" for consistency?

Proposer: Jdtendo (talk)
Deadline: August 20, 2024, 23:59 GMT Extended to August 27, 2024, 23:59 GMT Extended to September 3, 2024, 23:59 GMT

Support (SNES)

1. Jdtendo (talk) Per proposal.
2. Super Mario RPG (talk) Per proposal and similarly passed earlier proposal on shortening identifiers of the second and third Donkey Kong Country games.
3. Technetium (talk) Per all.
4. Mario shroom (talk) too long, agree.
5. SeanWheeler (talk) Let's simplify the names.
6. PaperSplash (talk) Per proposal and the earlier Donkey Kong Country proposal that Super Mario RPG mentioned, as well as Technetium and Jdtendo in the comments.

#Pseudo (talk) Per all.

Oppose (Super Nintendo Entertainment System)

1. Hewer (talk) I don't see much of a problem with long names, and I'd rather go without the inconsistency created by these being the only shortened console names. And yes, I suppose we should move the Building World page too, like how "Beach Volleyball (Mario & Sonic at the London 2012 Olympic Games for 3DS)" got moved to "Beach Volleyball (Mario & Sonic at the London 2012 Olympic Games for Nintendo 3DS)".
2. Camwoodstock (talk) Per Hewer. While these shortened versions do make for fine redirects (and honestly, I kinda hope these do get made for other games in the form of redirects, but that's neither here nor there), we probably shouldn't be enforcing these as being the default name unless it's a part of a global move to abbreviate the console names for the articles of every game--not just one random edutainment game.
3. JanMisali (talk) Per all.
4. Pseudo (talk) Per Hewer and Camwoodstock.
5. Sdman213 (talk) Per all.
6. FanOfRosalina2007 (talk) Per all.
7. Jazama (talk) Per all
8. ThePowerPlayer (talk) Per all.
9. Axii (talk) Per all.

Comments (Mario's Early Years! Fun with Letters for SNES)

now there's a bit of a grey area here, what about consoles like Nintendo 64, Nintendo Switch and so on? It'd feel somewhat weird to abbreviate one but not the others, there'd be an inconsistency. - YoYo (Talk) 09:33, August 13, 2024 (EDT)

The thing with those is that the "Nintendo" part is needed or else it could just be confused as a random number (64) or word (switch). They also just aren't as long. Technetium (talk) 09:57, August 13, 2024 (EDT)

Besides, as I said in the proposal, the abbreviations "NES" and "SNES" are commonly used in the body of articles, but other console names are not abbreviated as frequently. For example, here is an extract of the LodgeNet article: "for the SNES, Nintendo 64, and Nintendo GameCube"; note how only the Super Nintendo Entertainment System's name is abbreviated whereas the other console names are written in full. Jdtendo^(T|C) 10:09, August 13, 2024 (EDT)

I think the shortening of N64, GCN, GBA, etc. could use another propasal. SeanWheeler (talk) 21:30, August 13, 2024 (EDT)

@Hewer Okay, The Old Psychic Lady with the Evil Eye Who Reads Fortunes and Knows Everything Before It Happens' name is ridiculous. I want to propose a shortening of the title, but I don't know enough about the character. But that just shows why page names shouldn't be too long. SeanWheeler (talk) 20:27, August 14, 2024 (EDT)

...Not to burst your bubble, but we actually had a proposal to move it to its current name last month. Prior to that, the article was merely titled "The Old Psychic Lady", which from what I can tell was actually never actually used like that in the episode. She introduced herself by the full title of "The Old Psychic Lady with the Evil Eye Who Reads Fortunes and Knows Everything Before It Happens" (whether it used capital letters or not is unknown), and the Marios simply refer her to as the "crazy lady" or "that psycho lady" since they can't properly remember such a long name. Since "The Old Psychic Lady" never was used as one of the official names, and the wiki refers to her by her full name anyway, it was proposed to move the article to the lady's full title (I mean, at least "NES" and "SNES" are officially used abbreviations by Nintendo themselves and their full names were not created for comedic purposes). rend (talk) (edits) 20:50, August 14, 2024 (EDT)

Arguments about the name being "ridiculous" or "too long" were used in the proposal linked to by Arend, and much like with those arguments, you haven't substantiated the claim very well. Why is a long page name "ridiculous" when it's just accurately referring to the subject? Why should we sacrifice accuracy in favour of a shorter page name? What about long page names is in any way disadvantageous? Hewer (talk · contributions · edit count) 05:37, August 15, 2024 (EDT)

Tbh, I'd merge the two Building Worlds together if it were up to me, they're still both represented by the same icon in the map screen and differences can easily be mentioned in the article, it'd also be consistent with the rest of the Mario's Early Years Worlds. Ray Trace^(T|C) 20:09, August 15, 2024 (EDT)

Adjust proposal rule 9 to prevent exploitation

So I realized an issue with Proposal Rule 9 while I was whinily bitching about a proposal I didn't like passing like the selfish little megalomaniac I am (long story there... at least a good realization came out of it) and that is that, by the current setup, the "difference of three votes" only applies for two-option proposal. If a proposal has more than that many options, it is solely decided by being over 50%... regardless of how many options actually have votes in them. This has the potential for abuse: someone could add in an option no one would vote for to try and work around the "difference" requirement. As such, I propose that the rule be amended so that unless there are three options with at least one vote that isn't the proposer's own, it be treated the same as a two-option proposal.

Proposer: Doc von Schmeltwick (talk)
Deadline: September 5, 2024, 23:59 GMT

Support

1. Doc von Schmeltwick (talk) - Per
2. Arend (talk) Doc's points in the comments have enlightened me more to understand the necessity of this amendment. Also it makes multi-option proposals where there's really only two options being voted for more consistent with our regular two-option proposals.
3. Shoey (talk) Per Doc it's silly that a proposal like https://www.mariowiki.com/Talk:Coin_bag#Split_the_Mario_Party_Coin_Bag_from_the_Super_Princess_Peach_Coin_Bag can pass because of options that have almost no support.
4. Mario (talk) Given the confusion time and time again this rule has inflicted on the wiki historically,[1][2] due to going against basic intuition (and relying too much on head spinning percentages) I rather just kill this particular clause of that rule with fire and simply have multioption proposals follow a similar rule to two-option proposals: one option with majority of votes over a 3 vote margin passes, which this proposal is going. If not, extend it. A 6-5-1-0 is NOT a consensus; neither is 9-8. Both of these should've been extended.

Oppose

1. Super Mario RPG (talk) This has never been an issue for all these years we've had proposals, otherwise the amendment would've been proposed and/or added long ago. There's also the margin-of-three-votes rule for proposals with ten or more votes. Also, keep in mind the user proposing this was vehemently opposed to a proposal that I made that passed with a 9-1-1-8 vote and is trying any means possible to undo it, including the drafting of another proposal in late September that is sneaking in a provision to undo the one that passed yesterday, which is another way of saying "we want Pokemon content back on the wiki despite the Poke Ball lists being removed for the reason of lacking any further connection to Super Mario than any other franchises in the Super Smash Bros. series.
2. SeanWheeler (talk) If you want to reverse a recent proposal, you have to wait a month to do so.

Reverse the rule order, change none of the text

1. Doc von Schmeltwick (talk) - This is an exaggerated example of what I'm trying to prevent, don't take it seriously.

Comments

I'm kinda half-on-half on this. On the one hand, amendments like these to prevent exploiting loopholes like those is always fine, but on the other hand, I wonder if it's even necessary? Proposers can only change and edit their proposals in the first three days since launch (or first six days if it's a TPP). This is just under halfway through the proposal length, which gives other users ample time to consider voting for a new third option if it's being added at the latest time possible. Even when an option has been added in bad faith, users can bring notice to it in the comments or report it to admins. So while I'm not opposed to this amendment, I think I'm more favoring it for the sake of consistency, rather than to combat exploits, since the 3-6-day limit thing already does that as well.
The rules section might need a bit of an overhaul regardless: There's been talks already how Rule 9 sounds a bit confusing due to its wording regarding the required amount of voters, and it's also been stated that the entire section is an unsorted mess with little to no examples for clarity. rend (talk) (edits) 18:07, August 29, 2024 (EDT)

It's not about retroactively adding an option. Doc von Schmeltwick (talk) 18:25, August 29, 2024 (EDT)

...did you misinterpret my whole message or something?
You literally said "This has the potential for abuse: someone could add in an option no one would vote for to try and work around the "difference" requirement." That is LITERALLY "retroactively adding an option", isn't it? And this proposal is about preventing such an exploit, right? As in, what I literally have been talking about as well? rend (talk) (edits) 19:12, August 29, 2024 (EDT)

You seem to have missed the point. This is about putting in a dummy option in general, not about doing so at a specific time. Doc von Schmeltwick (talk) 19:56, August 29, 2024 (EDT)

So you HAVE misinterpreted my message (at least somewhat), because I AM well aware that this is about putting a dummy option in general. The thing is, as I stated before, proposers can only edit their proposals within the first three days since launch, which is to say, they cannot add a third option like 5 minutes before the deadline to cheat the system. After those three days, they're locked from editing the proposal, and other users have four days to consider voting for that third option (which is more than the 3 days the proposer was allowed to edit their proposal.
All this stuff I said about specific time limits is to say that we already have a method to combat exploits like this, making this extra stipulation for combatting the same exploit kind of redundant, as the most this does is treating multi-option proposals where really only two sides are being voted on, the same as a regular two-option proposal (which admittedly is at least consistent).
If you're worried about people using these exploits within the 3-day limit, that's technically also addressed, as I already stated "Even when an option has been added in bad faith, users can bring notice to it in the comments or report it to admins."
If you're still worried that this doesn't solve your problem, then I think it's better to add a rule to not add (bad-faith) dummy options (or editing proposals in bad faith in general) for the sake of exploiting the rules. I'll admit that your proposed changes will help bring consistency across proposals, and also will help with preventing third-option exploits from being passed so easily, but I don't think it'll prevent proposers from attempting them within those first three days anyway (hoping in the off-chance that someone will vote for that dummy option), so it'd be wise to remind them that editing a proposal in bad faith is against the rules. rend (talk) (edits) 21:16, August 29, 2024 (EDT)

Where are you getting the "after the proposal is created" part from? This is including if it's made with three options, one of which is valid-but-undesirable-to-anyone-involved. Doc von Schmeltwick (talk) 21:22, August 29, 2024 (EDT)

The statement of yours I quoted before: "This has the potential for abuse: someone could add in an option no one would vote for to try and work around the "difference" requirement.". I interpreted that as someone adding it in later, as opposed to it being already there from the beginning. Thank you for clarifying that you meant both of those instead of only the former, though. rend (talk) (edits) 21:30, August 29, 2024 (EDT)

...yes, "add in" as in a synonym to "include." Sorry for the confusion. Doc von Schmeltwick (talk) 21:38, August 29, 2024 (EDT)

It's OK man. Perhaps I was being too pigheaded myself to realize other interpretations.
Anyway, with that in mind, I understand the necessity to add this stipulation a bit more now, because the 3-day edit limit obviously cannot prevent what's there from the beginning, and now there's a 3-day limit to convince the proposer to remove the dummy option instead. rend (talk) (edits) 21:48, August 29, 2024 (EDT)

@Super Mario RPG - You're ignoring that our rules for proposal passing and failing have changed several times over the past few years thanks to various proposals. This is just something that was overlooked (the fact a sysop thanked me for bringing this up initially helps me think this was a good idea). Also, I'm not trying to "undo" your proposal by a retroactive rule change, that's not how amendments work. Doc von Schmeltwick (talk) 20:19, August 29, 2024 (EDT)

If this proposal passes and gets enforced, wouldn't that proposal be affected? Probably should wait four weeks to do make this proposal. Like how I decided to wait after the proposal to move Shadow (character) back to Shadow the Hedgehog to fail before I could start the proposal to move the crossover characters back to their proper names. I could have started that proposal yesterday, but I need to find instances of the Mario & Sonic games referring to the Sonic characters by their full names before I could start that proposal. SeanWheeler (talk) 23:51, August 29, 2024 (EDT)

No? You can't (and shouldn't) retroactively enforce a rule that did not exist yet, that's not fair (also that would probably affect a lot of other proposals, and I'm not interested in going down that rabbit trail even if it was ethical). That's why when prohibition was passed everyone who had drank alcohol before wasn't arrested. It's the same deal here. While I want to repeal that proposal, I want to do so the fair-and-square way in a month, not through some dirty underhanded trick. Doc von Schmeltwick (talk) 00:13, August 30, 2024 (EDT)

I feel like this proposal has actually nothing to do with Rule 9: a margin of votes has nothing to do with majority support. I think we should amend Rule 10 instead to remove the reference to "proposals with only voting options" and extend it to multioption proposals. For example: "Rule 10: If the two most voted options of a proposal gather more than ten votes between them and the vote count difference of those two options is less than three, then the deadline will be extended for another week as if no majority was reached at all." That way, Rule 10 would still work the same as it does now for proposals with only two options, and multioption proposals would need to satisfy both Rule 9 (majority support is needed to ensure that most voters have voted for the winning option) and Rule 10. Jdtendo^(T|C) 01:44, August 30, 2024 (EDT)

Miscellaneous

Do not use t-posing models as infobox images

Self-explainatory aim for this proposal with the title, I'm proposing because I personally don't think t-posing models look good as introductory images. One case in point is on the Mega Baby Bowser article which used a t-posing model as its infobox image but was changed to a screenshot. Angler Poplin is an article that currently uses a t-posing model. Should this proposal pass, in-game screenshots will be used instead of t-posing images, or if possible a model which is not in a t-pose.

Proposer: Nightwicked Bowser (talk)
Deadline: September 1, 2024, 23:59 GMT

Support

1. Nightwicked Bowser (talk) Per proposal
2. Super Mario RPG (talk) Per Nightwicked Bowser.
3. Nintendo101 (talk) Per proposal.
4. Technetium (talk) Per proposal.
5. Sparks (talk) Per all.
6. ThePowerPlayer (talk) T-poses are clearly not how the characters are meant to be portrayed.
7. Camwoodstock (talk) Makes sense to us! Per proposal.
8. Ray Trace (talk) This should also include non-t-posed bind models (a-posed models, nonbipedal characters) as well but that's a matter of jargon really.
9. SeanWheeler (talk) Considering I went through the effort of posing the characters of my game Speed Prix before I uploaded them to the Speed Prix Wiki, I know T-poses are not good infobox images. And in the context of Mario games that you're not developing yourself, if artwork is not available, just use screenshots. That is much easier to get. The Models Resource is incomplete. And with other media, we have to.
10. Axii (talk) Per proposal.
11. Killer Moth (talk) Per proposal.
12. FanOfRosalina2007 (talk) Yeah, it looks strange and creepy with the t-poses. Per proposal.
13. PaperSplash (talk) Per proposal. I especially agree that screenshots would be better.
14. Arend (talk) Pose accuracy should take priority over asserting dominance.

Comments

There's an issue in that many models in earlier 3D games do not have an easily decipherable rigging or animation system. For instance, on The Models Resource, the Luigi's Mansion model uploads lack proper pose data, so they're just automatically T-posed. I do think non T-posed ones should be prioritized, but prohibiting them fully is not the way to go because that's sometimes the only clear option. EDIT: Never mind, I didn't see the "infobox" part of the proposal. I mistook this for a blanket ban. My apologies. Doc von Schmeltwick (talk) 21:53, August 25, 2024 (EDT)

Screenshots of the subjects in the game are strongly preferred regardless. Ray Trace^(T|C) 21:58, August 25, 2024 (EDT)

I agree with Ray Trace. If one did not have an organic looking model, couldn't one just use a screenshot? - Nintendo101 (talk) 22:01, August 25, 2024 (EDT)

That's still assuming you either have an emulator available or can find a high enough quality video at the proper dimensions. In several cases, the preview image on The Models Resource is the most available option (such as for the Mario Party games on N64). Doc von Schmeltwick (talk) 22:04, August 25, 2024 (EDT)

There is no shame in taking a screenshot of a YouTube let's play. Not ideal, but I think it is more serviceable than a t-posed model. - Nintendo101 (talk) 22:08, August 25, 2024 (EDT)

Well I mean that's still assuming you can find one at all. Doc von Schmeltwick (talk) 22:09, August 25, 2024 (EDT)

Editors should take all their screenshots with emulation regardless. Ray Trace^(T|C) 23:27, August 25, 2024 (EDT)

With how rabid Nintendo can be about ROMs and such, that's sometimes easier said than done. (Plus plenty games have outright never been dumped or officially ported, particularly the more obscure ones; there's a reason there's no maps or screenshots for "Champions' Course" in Golf: Japan Course.) That also assumes one's device has the ability to actually run said emulators or the space for them; even with high-dollar gaming laptops I've had trouble with more advanced game system emulation in that regard. Doc von Schmeltwick (talk) 23:49, August 25, 2024 (EDT)

With the right tools and resources, ROMs aren't difficult to find at all. And, by the way, those are rare cases and have little to do with the proposal which deals with models. Ray Trace^(T|C) 21:59, August 26, 2024 (EDT)

Create new sections for gallery pages to cover "unused/pre-release/prototype/etc." graphics separate from the ones that appear in the finalized games

This has been bouncing around in my head ever since the so-called "gigaleak" happened. This would do exactly as the header says: sprites and models and such that do not appear in gameplay of the finalized game they represent would be moved to a separate gallery, similar to what we do with non-game artwork relative to game artwork. This would allow more easy coverage on them without bloating the "main" gallery with them, particularly in cases where the subject does appear in the final game with different sprites (or with different colors), and would also help encourage more unused sprites to be uploaded in the first place. The other gallery section would be placed underneath the main one.

Proposer: Doc von Schmeltwick (talk)
Deadline: September 2, 2024, 23:59 GMT

Support

1. Doc von Schmeltwick (talk) - Per
2. DrippingYellow (talk) Nothing wrong I can see with this. Per proposal, and Doc in the comments.
3. Ahemtoday (talk) Seems like a straightforwardly good idea to me.
4. Axii (talk) Per proposal
5. FanOfRosalina2007 (talk) Per Doc von Schmeltwick in the comments (and per proposal as well).
6. Arend (talk) Per all
7. PaperSplash (talk) Per comments.
8. Killer Moth (talk) Per all.
9. OmegaRuby (talk) Per all, and per the discussion in the comments.

Oppose

1. Super Mario RPG (talk) - Opposing because this was done with the gigaleak in mind. The gigaleak consists of unlawfully stolen assets, and one could propose to remove those instead, out of courtesy towards Nintendo.

Comments

@SMRPG They haven't gone after TCRF so far despite them documenting everything from it. I get there's some "fruit of the poisoned tree" moral concern, but as it is, our role is to document known facts. Doc von Schmeltwick (talk) 17:02, August 26, 2024 (EDT)

In addition, the current wording of the proposal implies a section for all unused/prototype/pre-release content, not just those that came from the gigaleak (e.g. various prototype/prerelease things from Mario Kart DS came from the kiosk demo, which was distributed to toy stores and game stores by Nintendo themselves). If SMRPG was concerned that hypothetically, those assets would have to be removed as well for Nintendo's concern (in a "one bad apple spoils the bunch" kind of way), then not separating them at all might actually be worse, because hypothetically speaking, Nintendo might request to remove the entire gallery purely because assets from the gigaleak were being included; this of course helps no one. rend (talk) (edits) 12:52, August 27, 2024 (EDT)

Indeed, I think it would be a good idea even without the gigaleak occurring, though the fact that the hyper-litigious Nintendo hasn't gone after anyone as far as I can tell (most notably TCRF, who documents that sort of thing as the entire purpose of their existence) for reposting them, it doesn't seem to bother them. And while it makes sense for The Spriters Resource to have a blanket ban on what was uncovered there (they're based on assets that actually do appear and are only barely able to keep the site up monetarily), it makes little sense for us to resort solely to using descriptions and offsite links. Doc von Schmeltwick (talk) 15:14, August 27, 2024 (EDT)

Being a TCRF user myself, I agree with Doc von Schmeltwick. -- FanOfRosalina2007 (talk · edits) 16:10, August 27, 2024 (EDT)

Right indeed. I personally think the whole fearmongering aspect of SMRPG's oppose vote is generally... well, not quite in bad faith, but at the very least somewhat misleading or misunderstanding of the situation. As you said, Nintendo hasn't been witchhunting sites like TCRF for detailing things from the gigaleak even four years after the fact, so we should be safe (and again, these sections would include prototypes that weren't part of the gigaleak, too). Though I simply don't think that oppose vote makes a lot of sense even if Nintendo did send their ninjas to anyone detailing the gigaleak, so we might as well make separate sections for any unused/prototype content regardless. rend (talk) (edits) 16:54, August 27, 2024 (EDT)