MarioWiki:Proposals

Always use past tense when describing pre-release and unused content
Fairly self-explanatory. These kinds of pages need to be more consistent in this way. The only time present tense should be used is when drawing comparisons to the final release.

Example: "At the start of Lap 3, Lakitu's sign said 'Final Lap'; in the final version, it says '3/3'."

Proposer: Deadline: April 8, 2022, 23:59 GMT

Support

 * 1) Per proposal.
 * 2) Yeah, makes sense. Per proposal.

Oppose

 * 1) I'd say this matter has to be explored on a case-by-case basis. In some situations, we only have some form of documentation to attest the existence of a game's early state, and, with no present whereabouts of its physical existence, it's indeed sensible to use past tense in any references to it until proven otherwise. But as Doc pointed out in the comments, some prototype builds are known to exist in the present and may even be readily available to the public--what would be the logic in referring to these using past-tense, then?
 * 2) I agree with Koopa con Carne -- the last sentence (about prototype builds resurfacing) is especially true.
 * 3) Per all. We're not going around changing everything regarding Super Mario Bros. 35 or Dr. Mario World to past tense either, so I wouldn't say this is necessary.
 * 4) Per all.

Comments
What about leaked prototype builds? They still exist in a current state. Doc von Schmeltwick (talk) 14:46, March 29, 2022 (EDT)

@Koopa @Doc Fair point. When making this proposal I was primarily thinking of that "early state documentation", like E3 footage. But in terms of prototype builds, the wiki has used past-tense for them before (See Super Mario 64 and Luigi's Mansion). 02:49, March 30, 2022 (EDT)
 * Those haven't been leaked, though. I'm thinking of like Diddy Kong Pilot, where only prototype builds exist anyway. Doc von Schmeltwick (talk) 23:06, April 6, 2022 (EDT)

Forbid "special symbols" from being used in article titles
This page - ★ door - basically describes it. While it is true that the source refers to the Star Door as the "★ Door", I believe this is unintuitive for readers of this wiki. It makes more sense for an average user to search for the "star door" instead of copypasting a character that isn't even present on many keyboards. The name "★ door" should still be used in the article itself, but the title should transcribe the symbol instead of using that symbol. This would also be consistent with other articles:


 * World 1-Castle (New Super Mario Bros.), where the title uses the transcribed name instead of a castle emoji (🏰).
 * Minna de Atsumete!, where the title of this official SMM2 course does not use the Japanese symbols.

I believe, for the overall consistency of naming pages and unneeded complexity for readers of this wiki, uncommon symbols such as the star or emojis should be forbidden from being used in the names of articles.

Proposer: Deadline: April 12, 2022, 23:59 GMT

Support

 * 1) per my proposal.

Oppose

 * 1) The problem with the ★ door example is that "Big Star Door" is already pending a move (and currently redirects) to "Star Door" due to that being the in-game name, which complicates matters. Additionally, how levels are titled is generally consistent with official guides, and I don't think romanization systems for foreign characters can be compared since they're an established rule-based process. Overall, I don't think this comes up enough to be an issue like the use of hashtag at the start of a name. The only other one I can think of at the top of my head is ♥ from Yoshi's Story, which is deemed a unique subject from other heart articles.
 * 2) It's still the official name of the subject, and people not being able to type it isn't a problem because of redirects. By this logic we should also move Pokémon to Pokemon (just as an example, there are loads of pages with accents in their titles).
 * 3) This is a little bit like censoring content.
 * 4) There is a fine line to draw between accessibility and accuracy, and this is pushing it a bit too much. Redirects will work just fine.
 * 5) Per all.

New features
None at the moment.

Removals
None at the moment.

Overhaul the no quorum proposal rule (#8)
The current rule no quorum proposals is vague, flawed, and counterproductive. Per rule 8, if a proposal has three votes or less at deadline, it NQs, ending with no action taken. In other words it needs at least four votes overall to pass. I have two major problems with this.

Problem #1: A blanket minimum number of votes means that opposition can actually cause a proposal to pass.

Take these hypothetical proposals, for instance.
 * Proposal A reaches its deadline with 3 support and 0 oppose votes. That's a total of 3, exactly one shy of the minimum 4. Therefore, the proposal NQs.
 * Proposal B reaches its deadline with 3 support and 2 oppose votes. That's a total of 5, enough to avoid NQ. Since there are too few votes for rule 10 to apply, and there's more support than opposition, the proposal passes.

See the problem here? Proposal B has the same amount of support as Proposal A, but more opposition, yet Proposal B passes while Proposal A does not. If Proposal B did not have those oppose votes, it wouldn't have enough votes to avoid NQ. Therefore, the opposition actually causes the proposal to pass. This should not be possible. Proposals should only ever pass in spite of opposition, never because of it.

Three-or-more-option proposals have the same problem, especially since you can vote for more than one option - the rule does not clarify whether or not multiple votes from the same user counts toward quorum. This proposal is a good example - it only met the minimum four because one of the voters picked two options.

Solution: Instead of a minimum total of 4 overall votes, make it so at least one option must have a minimum of 4 votes.

This retains the current minimum number of supports necessary to pass a proposal where no other options receive votes, but eliminates the "opposition backfire" issue mentioned above. Under this new rule, Proposal B would NQ, just like Proposal A. This rule would also apply to proposals with three or more options - at least one option would need at least 4 votes to avoid NQ.

Now for the other problem.

Problem #2: No quorum proposals just end immediately upon reaching their deadline, when we could be extending them.

Imagine the frustration. Your TPP has three supports and no opposition. If just one more person would vote, you'd be golden. But before it can happen, that deadline comes. Your proposal's over. You waited two weeks for nothing. Hey, at least you have "the option to relist said proposal to generate more discussion", even though that's an extremely vague statement that is not clear at all about what it actually means. I guess it just means "redo the proposal from scratch", but why should you have to do that?

Solution: Apply the three-week extension rule to no quorum proposals.

Why do no quorum proposals have to end right then and there? Why not just extend them, like we do with proposals that do not reach a consensus by deadline? This would help give vote-starved proposals more of a chance to gain attention and reduce the number of frustrating NQs. I'm not sure if we should apply the four-week waiting period for proposals that do NQ under this new rule, but I'm leaning towards no. If you think it should, feel free to comment on it.

Proposer: Deadline: April 14, 2022, 23:59 GMT

Apply both solutions

 * 1) Preferred option.

Apply problem #1's solution

 * 1) Second option.

Apply problem #2's solution

 * 1) Better than nothing.
 * 2) I'm neutral about the other point, but per proposal on this one (I was actually thinking of this problem recently after this proposal).
 * 3) While I disagree on some points in problem #1, namely the proposed solution, I do believe extending the NQ proposals is better than relisting them.

Establish proper size of the Media section for game articles with a dedicated media list
Most Media sections of game articles link to a separate list of media (mostly music). It has been the standard for Media sections to have a small sample of files to give an approximate preview of the full list, but the wiki is inconsistent in how many are chosen. At the time of writing, the Media section for Super Mario 64 has five audio files (plus a video), yet Mario Kart Wii and Mario Kart 7 show only one file each. Mario Party 8 has seven!

This proposal should settle on how many audio files should be chosen for Media sections. This would be more of a strong recommendation than a hard rule, but consistency is the goal here.

Video files are uncommon, but they should still be kept to one per Media section where applicable (see Super Mario Sunshine).

Proposer: Deadline: April 5, 2022, 23:59 GMT

4-5 audio files

 * 1) My preferred option. Leaves room for more diverse choices.
 * 2) Per proposal. This gives us plenty of diversity options while not over-crowding pages with media.
 * 3) Per proposal.
 * 4) Per proposal.
 * 5) 4-5 audio files is a good sweet spot for this.
 * 6) Per all.

Comments
I have also come across a few Media sections that merely display the beginning few files from the media list. (Until I recently changed it, the Media section for Mario Super Sluggers showed the first four in the list. This was a problem because it was largely unrepresentative; the first two were an unused theme and a repetitive 20-second loop heard once in the entire game.) I almost made a proposal about prohibiting this kind of thing, but it seems too uncommon to be worth doing that. 05:20, March 29, 2022 (EDT)
 * There technically is a rule against that sort of thing (the policy doesn't mention media but it can be reasonably assumed to extend to that), so we should probably just add a mention of media sections there. 10:31, March 29, 2022 (EDT)
 * I feel that it would definitely make sense to add a mention of media sections onto that policy page. -- 10:46, March 29, 2022 (EDT)

Allow/prohibit fan work by former Nintendo staff
After their contractual obligations for Nintendo have ended, certain affiliates such as Steve Mayles and Masanori Sato have continued to celebrate the franchises they helped shape through various pieces of artwork. These works, consequently, are not direct promotional material nor are they endorsed or acknowledged by Nintendo, pertaining potentially to the realm of fan art more than what this wiki outlines as official material. Nevertheless, the notability that tailgates these people was reason enough for me to have already uploaded a number of their post-contractual works on the wiki.

The proposal's aim is to sort out whether this practice should be further allowed--and on what conditions.

In hashing over the proposal's options, I will divide these "fan" works by two paradigms, so to speak: those that portray at least one specific character from the Mario franchise (which can be modified but otherwise still recognizable), and those that are parodies or feature vaguely-represented elements pertaining to the franchise, but do not otherwise portray any officially recognised character. Examples from the former include an illustration of Dixie Kong by Steve Mayles (twitter.com), a sketch of Yoshi by Masanori Sato (instagram.com) , and a Bob-omb King-like creature accompanied by an actual Bob-omb (instagram.com) , also by Sato; examples of the latter include an illustration of two Mario&Luigi-like characters (instagram.com) , another of a turtle-esque fairy (instagram.com) resembling Boom Boom or Pom Pom, and yet another of a distinctly Wario-looking fellow (instagram.com).

In this respect, I propose three directions:
 * 1) Allow any and all such works;
 * 2) Allow only works that portray at least one recognised Mario element, but not those that are derivative of the Mario franchise; could likely help the wiki avoid legal stuff;
 * 3) Prohibit all such works and delete existing uploads. If Nintendo didn't recognise them, they don't belong here.

I should note that the proposal excludes work that has had a function in the promotion or development of a certain media product or the franchise in general, such as Miyamoto's drawn cover for the Edge magazine, or the Super Smash Bros. Ultimate Mario-Rathalos artwork.

Proposer: Deadline: April 5, 2022, 23:59 GMT

Option 1: Allow all

 * 1) My choice.
 * 2) - Makes sense to me
 * 3) Per all.
 * 4) Per all.
 * 5) Per all.
 * 6) Very interesting proposal that raises some good points. I'd say that because the staff are still recognized for when they were involved with the Mario franchise, their artworks should be allowed, especially because a lot of stems from when they were involved & many of the subscribers and viewers would perceive it this way as well.

Option 2: Allow only on-brand depictions

 * 1) While I do love Sato's Mickey & Goofy artwork, I don't think it or any image that only belongs in the artists' gallery section should be uploaded here.
 * 2) This is a cool idea, but let's at least try to keep it relevant to the namesake of this fan wiki, mkay?
 * 3) Per all.
 * 4) I think having a bit of a limit on what kind of art can be uploaded is best. Do we know how much art they shared that isn't Mario? Can we expect that number to grow in the future?

Comments
At any rate, what do the users in here think of Sato's Mario & Luigi-esque portrayal of Mickey and Goofy? Is it worth keeping it on the wiki for the stylistic and dynamic similarities alone? 17:44, March 30, 2022 (EDT)

@RHG1951 @Somethingone I pointed out the Mickey and Goofy image as an individual case, because I thought some users may find its connection to Mario way too tenuous, and probably only coincidental given the fact that an artist can practice their style without this necessarily connecting their works. The artwork deprecated by the second option still relates to Mario in more than just style; do keep this in mind. 20:01, March 30, 2022 (EDT)