MarioWiki:Proposals

Current time: Thursday, December 26th, 15:43 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. Voting periods last for two weeks, but can close early or be extended (see below). Any autoconfirmed user can support or oppose, but must have a strong reason for doing so. 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.

If you would like to get feedback on an idea before formally proposing it here, you may do so on the proposals talk. For talk page proposals, you can discuss the changes on the talk page itself before creating the TPP there.

How to

If someone has 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 other users, who will then vote on whether or not they think the idea should be implemented. 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}}.

Rules

1. Only autoconfirmed users may create or vote on proposals. Anyone is free to comment on proposals (provided that the page's protection level allows them to edit).
2. Proposals conclude 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.
3. Users may vote for more than one option, but they may not vote for every option available.
4. Every vote should have a strong, sensible reason accompanying it. Agreeing with a previously mentioned reason given by another user is acceptable (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 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.
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 "(blocked)" 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. Proposals cannot contradict an already ongoing proposal or overturn the decision of a previous proposal that concluded less than four weeks (28 days) ago.
8. 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.
   • Tag the proposal with {{early notice}} if it is on track for an early close. Use {{proposal check|early=yes}} to perform the check.
9. 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.
10. If a proposal reaches its deadline and there is a tie for first place, then the proposal is extended for another week.
11. 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.
12. 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.
13. 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.
14. After a proposal passes, it is added to the appropriate list of "unimplemented proposals" below and is removed once it has been sufficiently implemented.
15. If the wiki staff deem a proposal unnecessary or potentially detrimental to the upkeep of the Super Mario Wiki, they have the right to cancel it at any time.
16. 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.
17. 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.
18. Proposals cannot be made about promotions and demotions. Staff changes are discussed internally and handled by the bureaucrats.
19. No joke proposals. Proposals are serious wiki matters and should be handled professionally. Joke proposals will be deleted on sight.
20. Proposals must have a status quo option (e.g. Oppose, Do nothing) unless the status quo itself violates policy.

Basic proposal formatting

Below is an example of what your proposal must look like. If you are unsure how to set up this format, simply copy the following and paste it into the fitting section. When updating the bracketed variables with actual information, be sure to replace the whole variable including the square brackets, so "[insert info here]" becomes "This is the inserted information" and not "[This is the inserted information]". Proposals presenting multiple alternative courses of action can have more than two voting options, but the objective(s) of each voting option 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|{{subst:REVISIONUSER}}}}<br>
'''Deadline''': {{subst:#time:F j, Y|+2 weeks}}, 23:59 GMT

====[option title (e.g. Support, Option 1)]: [brief summary of option]====
#{{User|{{subst:REVISIONUSER}}}} [make a statement indicating that you support your proposal]

====[option title (e.g. Oppose, Option 2)]: [brief summary of option]====

====Comments ([brief proposal title])====

Autoconfirmed users will now be able to vote on your proposal. Remember that you can vote on your own proposal just like the others.

To vote for an option, just insert #{{User|[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 simply say "Per 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. All of the above proposal rules also apply to talk page proposals. 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

• Make changes to List of Smash Taunt characters (discuss) Deadline: December 27, 2024, 23:59 GMT
• Tighten Category:Deceased characters (discuss) Deadline: December 27, 2024, 23:59 GMT
• Merge Cascading Stone, vanishing platform, and moon platform with Falling Platform (discuss) Deadline: December 28, 2024, 23:59 GMT
• Rename the NES Template (discuss) Deadline: January 4, 2025, 23:59 GMT
• Merge the list of show hosts in All Night Nippon: Super Mario Bros. (discuss) Deadline: January 4, 2025, 23:59 GMT
• Split the theme songs from the list of Donkey Kong Country (television series) songs (discuss) Deadline: January 5, 2025, 23:59 GMT
• Rename Mario & Sonic (series) to Mario & Sonic at the Olympic Games (series) (discuss) Deadline: January 6, 2025, 23:59 GMT
• Rename Shadow to Shadow (enemy), and rename either Shadow (character) or Shadow (disambiguation) to Shadow (discuss) Deadline: January 6, 2025, 23:59 GMT
• Decide what to do with Category:Siblings and Category:Twins (discuss) Deadline: January 7, 2025, 23:59 GMT
• Merge Candy Block with Hard Block (discuss) Deadline: January 7, 2025, 23:59 GMT
• Merge ON/OFF Conveyor Belt with Conveyor Belt, or expand to cover all reversible conveyor belts (discuss) Deadline: January 8, 2025, 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)

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.

Split off the Mario Kart Tour template(s), MightyMario (ended November 24, 2024)

Split major RPG appearances of recurring locations, EvieMaybe (ended December 16, 2024)

Stop integrating templates under the names of planets and areas in the Super Mario Galaxy games, Nintendo101 (ended December 25, 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)

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)

Determine how to handle the Tattle Log images from Paper Mario: The Thousand-Year Door (Nintendo Switch), Technetium (ended November 30, 2024)

Merge False Character and Fighting Polygon/Wireframe/Alloy/Mii Teams into List of Super Smash Bros. series bosses, Doc von Schmeltwick (ended December 2, 2024)

Unimplemented proposals

#	Proposal	User	Date
1	Create boss level articles for Donkey Kong Country and Donkey Kong Land series Notes: The DK: King of Swing boss levels, while not explicitly covered by this proposal, should receive the same treatment. All Donkey Kong Land boss levels have been created.	Aokage (talk)	January 3, 2015
2	Create a template for the Paper Mario: The Thousand-Year Door badge drop rates	Lord Bowser (talk)	August 17, 2016
3	Expand the Behemoth King article	Owencrazyboy9 (talk)	December 23, 2017
4	Decide how to cover recurring events in the Mario & Sonic series	BBQ Turtle (talk)	July 17, 2018
5	Create articles on Play Nintendo games	Obsessive Mario Fan (talk)	June 23, 2019
6	Reorganize Map	LudwigVon (talk)	July 17, 2019
7	Split Jump Block (Mario & Wario) from Note Block	Alternis (talk)	July 21, 2019
8	Reorganize and split Gallery:Toys and other Merchandise galleries	Results May Vary (talk)	July 30, 2019
9	Split the Ice Skate and Swim Ring variants of the Goomba	FanOfYoshi (talk)	August 17, 2019
10	Split Buckies from Noki	FanOfYoshi (talk)	August 28, 2019
11	Create articles on the River Survival routes in Super Mario Party	Toadette the Achiever (talk)	November 2, 2019
12	Include information on Construction Zone for the rest of the Mario vs. Donkey Kong series	Bye Guy (talk)	November 24, 2019
13	Split Fireball (Donkey Kong) from Fire	LinkTheLefty (talk)	February 4, 2020
14	Merge the raven-like Nitpicker with Kuro	LinkTheLefty (talk)	February 4, 2020
15	Split Big/Giant Shy Guy from Mega Guy	LinkTheLefty (talk)	February 11, 2020
16	Delete the {{tense}} template	Trig Jegman (talk)	February 18, 2020

Writing guidelines

None at the moment.

New features

New Template:Gamma Image

An interesting oddity that I and few other users have noticed while dealing with images is a very interesting type of metadata called Gamma Brightening. In short, what gamma brightening does is change the way the colors of an image are displayed. This is generally very rare, but it is important as the differences between images is severely drastic. After some internal discussion, most notably with Steve, the unspoken policy course of action is to not optimize images with gamma brightening, and leave that metadata on the image if it is the way the source image provides the picture.

The purpose of the proposal is to make this unspoken policy a spoken policy. People should know when an image has a special property and should be treated differently.

The following template, {{Gamma-Brightening}}, would be placed on the documented images with gamma brightening:

This image contains gamma brightening, and should not be optimized.

<div class="notice-template" style="display:flex;text-align:center;background:#BF5FFF;margin:0.675em 2% 1.75em;padding:0 1em;border:2px solid black;color:black"> '''This image contains ''[[User:Trig Jegman#What's Gamma Brightening?|gamma brightening]]'', and should not be optimized.''' </div><includeonly>[[Category:Gamma Image|{{PAGENAME}}]]</includeonly><noinclude>

Such images seen thus far is:

• File:Hammer Bro-NSMBU.png
• File:MP8 Hammer Bro Artwork.png
• File:NSMBDS Goomba Artwork.png
• File:BulletBillWii.png
• File:NSMBDS Buzzy Beetle Artwork.png
• File:NSMBW Mario Holding Green Shell Artwork.png
• File:NSMBW Mario Jumping Artwork.png
• File:Blueboostblock.png

It would also be suggested, but not required, to create a MarioWiki page discussing gamma brightening over using a section on my user page.

Comparison image:

Proposer: Trig Jegman (talk)

Deadline: Feb 19, 2020, 23:59 GMT

Support (Create template)

1. Trig Jegman (talk) Per proposal
2. Bye Guy (talk) per proposal
3. TheDarkStar (talk) - Per proposal.
4. Results May Vary (talk) - It might be odd seeing this on many image pages, but otherwise it is a reasonable decision. We want to preserve the original nature of the image as much we can. Although personally I prefer the Gamma brightness removed for the Hammer Bro pic but just in this case, and it's only my opinion.
5. mister Wu (talk) I’m still wondering if removing metadata doesn’t create more problems than it solves (it’s often a few bytes of data where the IDAT chunk is orders of magnitude bigger), but since current optimization software removes them and since the gAMA chunk definitely must not be removed, it’s better to add this template.
6. FanOfYoshi (talk) Per all.

Comments

I mentioned you could simply say this information in the aboutfile template. Because of that, I don't see a need for this template, as it would only really apply to a handfull of images. But I'll remain neutral, as I'm not directly opposed to it, either. 11:21, February 12, 2020 (EST)

Not sure what to think of this yet, but I think the purple should be a lighter color to make the text more readable. --DeepFriedCabbage 14:46, February 13, 2020 (EST)

I can easily change the color to be more reader-friendly. I will hunt for a similar purple that's easier to read. Trig - 16:42, February 13, 2020 (EST)

Thanks! --DeepFriedCabbage 20:07, February 13, 2020 (EST)

is #cb7eff or #debffb more appropriate?

demonstration; original

demonstration; option 1

demonstration; option 2

I personally enjoy the original or lean towards the darker side of purple but it's up to the community. (I've never been great with color) Trig - 17:21, February 14, 2020 (EST)

I'd go with option 1. --DeepFriedCabbage 15:05, February 19, 2020 (EST)

It seems that "original" does not necessarily equal "accurate" in all cases. Take File:Luigi - New Super Mario Bros U.png for example. Note that the optimized version contains a darker green and the gamma ("original") version contains a lighter green. Then look at File:NSMBU FourCharacters.png from the same game, where the opposite is true. Therefore, it seems that there are some images where gamma correction produces an accurate image, and other images where gamma correction produces an inaccurate image. Given this, I think we can't say that gamma should always or never be removed, since it depends on the image. How do we determine when the original is accurate, and when the optimized version is accurate? A side note: it is possible to keep certain metadata, such as the gamma chunk or embedded ICC profiles, while still optimizing the image, such as by passing the --keepchunks=iCCP,gAMA,cHRM option to zopflipng or the -kiCCP,gAMA,cHRM option to pngout. See this page for further explanation. I tested it on File:NSMBDS Goomba Artwork.png. Note: preserving only the iCCP chunk has worked for every image I've tested so far, but theoretically there may be older images that rely on the gAMA or cHRM chunks. Since these legacy chunks are very small, it's probably worth preserving them also. Maybe we could include this information in the policy, so that we can optimize the images without removing gamma.--Super Mario Fan ⁶⁷ (T•C•S) 00:01, February 16, 2020 (EST)

We could modify the template/proposed policy to consider this. Maybe something like:

This image contains gamma brightening, and should not be optimized without preserving iCCP metadata.

--Super Mario Fan ⁶⁷ (T•C•S) 14:31, February 16, 2020 (EST)

The image-critical ancillary chunks are tRNS (used on Captain Toad: Treasure Tracker ripped textures by APNG Optimizer to greatly reduce file size), sBIT, pHYs, and the color space chunks, sRGB (when it specifies a different rendering intent than the default one), gAMA, cHRM and iCCP. So far only the tRNS, sRGB and gAMA/iCCP have been spotted, but I’m not sure if the others are featured as well, press release material might be the most at risk, if it was generated using the AdobeRGB color space.

In any case, this specific proposal deals with the gAMA chunk and possibly the iCCP chunk.—Mister Wu (talk) 18:55, February 16, 2020 (EST)

I'm not sure we should mention performing image optimization on the template at all given that it's now heavily discouraged at best by the image use policy. -- Too Bad! Waluigi Time! 19:24, February 16, 2020 (EST)

The Image Use Policy only discourages "Re-uploading existing images solely to optimize file size," not optimizing images you are planning to upload anyway. There could be other reasons (such as cropping) that one may modify an existing image, and many people such as myself optimize all pngs uploaded, including images to reupload. --Super Mario Fan ⁶⁷ (T•C•S) 19:30, February 16, 2020 (EST)

I would suggest writing a specific new page about Gamma Brightening, and having two sections to the page. One, very general in description, explaining what it is as simply as possible (metadata is a thing and while usually ok is not here and therefore needs to be kept, here's why we keep it), and the second half getting into the really technical stuff involved. While I like the detail that SMF67 and Wu are providing, I have absolutely no idea what just about any of that means. On the second point, I usually optimize uploads that are new nowadays, but I am duplicating them to compare them, just in case. Also, input on the color would be nice. Trig - 20:50, February 16, 2020 (EST)

I like color option 2 the most. --Super Mario Fan ⁶⁷ (T•C•S) 17:58, February 17, 2020 (EST)

@Trig Jegman, @Mister Wu, I made a quick (still incomplete) draft of a page that could describe the technical parts of color-correction metadata and how to safely optimize these images in my sandbox. There are still a few missing details I haven't figured out yet, and anyone is encouraged to add to it or take details from it to make something else (we don't have to use it of course, I don't know if all of the information is relevant/important to include). Additionally, while it might be nitpicky, I think it might be a good idea to refer to the metadata as "color-correction metadata" rather than "gamma brightening," since technically gamma is only one type of color-correction metadata and iCCP seems to be the most common from the images I've tested. --Super Mario Fan ⁶⁷ (T•C•S) 18:24, February 19, 2020 (EST)

Perhaps it would be more appropriate then to use {{color-corrected}}, with the following? The link would be a new page that explains color correction in a much more broad sense with a section on how to properly optimize the images. - 19:00, February 19, 2020 (EST)

This image has color changing metadata and should not be optimized.

Removals

None at the moment.

Changes

None at the moment.

Miscellaneous

None at the moment.