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.
 * 5) I get what this proposal's going for, and I agree to an extent since we're usually going to be addressing pre-release material in the context of comparing with the final, but then you've got things like "Super Donkey" where it's hard to ascertain if it should be its own thing.

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.
 * 4) I feel like a better solution to problem #1 would be to modify rule 10 so that it applies to all proposals, not just ones with >10 votes, and/or maybe reduce its margin from 3 to 2. That said, I do think solution #2 is a good idea.

Leave the rule as is

 * 1) I'm admittedly working from vague memories at the moment, so I apologize if anything I say is flat-out wrong, but my understanding is the portion of the rule about relisting NQ proposals is there because there isn't always enough information in them for users to make an informed decision and cast a vote. Other times, what information is there might be at odds with the stated goal. Maybe a proposed solution wouldn't adequately address a problem raised. Maybe someone points out (or realizes) the problem itself is larger in scope than originally outlined or an entirely different problem altogether. Since these sorts of discussions tend to happen after the deadline for editing the proposal has passed, it's an opportunity to incorporate whatever comes out of those into the next iteration of the proposal (in part because of rule 5). The initial deadline is usually enough time for those sorts of discussions to take place, and there are ways of getting people to weigh in if the specific issue is a lack of attention (an ever-present one regardless of what the deadline is). That said, sometimes, unfortunately, there aren't a significant number of people concerned about/invested in a particular thing, and I think the proposed more-votes-per-option solution could therefore result in more NQs or failed proposals.

Comments
Another problem with no quorum is that it also means that the proposal is treated as failed, as if it was a clear opposed result. I disagree; I think it should be treated as if the proposal didn't happen, opening the door for resolution to occur via discussion. LinkTheLefty (talk) 10:32, April 8, 2022 (EDT)

@Somethingone: I'm not going to say I'm against a rule 10 modification, but such a thing would require a separate proposal, since it would need different options for reducing the voting margin or not reducing it (or only reducing it for proposals with ten votes or less). Additionally, rule 10 only applies to two-option proposals, so it would not solve problem #1 for proposals with more than two options like the one I linked. I would also like the know the issue with implementing my solution so I can improve it or come up with an alternative. 13:50, April 8, 2022 (EDT)

Pinball (1984): full coverage or guest appearance?
Should Pinball, an NES game released in 1984, be classified as a guest appearance or a part of the Mario series? This proposal was created following User:Mario jc's comment here.

I believe this game features enough Mario-related content to justify full coverage of this game on this wiki. 1 out of 3 scenes is dedicated to Mario. In the scene C the player is controlling Mario to save Pauline, Mario is also heavily used in promotional material, including being on the cover-art for this game.

Alternatively, we can only allow coverage for the scene C, which features Mario as a playable character and Pauline.

Affected pages:
 * Template:Pinball
 * Card (Pinball)

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

Allow full coverage

 * 1) per proposal.
 * 2) - if Alleyway can get full coverage, so can this.
 * 3) Per all.
 * 4) I feel like this is one of the loosest games you can consider part of the franchise (and Mario is not references or advertised at all on the Famicom box), but Lady/Pauline is mentioned in the manual's "plot"/objective, so I say it barely counts. Also, Pinball is already a small enough article that I don't feel like it's worth trimming.

Allow coverage for the Mario scene (scene C) only (and classify as a guest appearance)

 * 1) Second option.

Miscellaneous
None at the moment.