MarioWiki:Proposals

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.

This page observes the No-Signature Policy.

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 Guideline proposals must include a link to the draft page.
 * 2) 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.)
 * 3) *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 reason accompanying it. Agreeing with or seconding a previously mentioned reason given by another user is accepted.
 * 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 at any time, but the final decision to remove another user's vote lies solely with the administrators.
 * 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 that has three votes or less at deadline will automatically be listed as "NO QUORUM." The original proposer then has the option to relist said proposal to generate more discussion.
 * 9) All proposals that end up in a tie will be extended for another week.
 * 10) If a proposal has more than ten votes, it can only pass or fail by a margin of three votes. If a proposal reaches the deadline and the total number of votes for each option differ by two or less votes, the deadline will be extended for another week.
 * 11) Proposals can only be extended up to three times. If a consensus has not been reached by the fourth deadline, 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) Proposals can only be rewritten or deleted by their proposer within the first three days of their creation. However, proposers can request that their proposal be deleted by an administrator at any time, provided they have a valid reason for it. Please note that cancelled proposals must also be archived.
 * 14) 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.
 * 15) There should not be proposals about creating articles on an underrepresented or completely absent subject, unless there is major disagreement about whether the content should be included. To organize efforts about completing articles on 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.

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. - ===[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: Deadline: [insert a deadline here, 7 days after the proposal was created, at 23:59 GMT. (14 days for Writing Guidelines and Talk Page Proposals)

====Support====
 * 1) [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 " # 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 All proposals dealing with a single article or a specific group of articles are held on the talk page of one of the articles in question. Proposals dealing with massive amounts 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 here.

Rules
 * 1) All active talk page proposals must be listed below in chronological order (new proposals go at the bottom). All pages affected must be mentioned in the brief description, with the talk page housing the discussion linked to directly via "". If the proposal involved a page that is not yet made, use to communicate its title. The Deadline must also be included in the entry. Linking to pages not directly involved in the talk page proposal is not recommended, as it clutters the list with unnecessary links. Place  under the section's header, and once the proposal is over, replace the template with.
 * 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.)
 * 4) *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.
 * 5) Talk page proposals may be closed by the proposer at any time if both the support and the oppose sides each have fewer than five votes.
 * 6) The talk page proposal must pertain to the article it is posted on.

List of Talk Page Proposals

 * Split Whomp and Big Whomp. (Discuss) Deadline: September 26, 2012, 23:59 GMT
 * Merge Fire Breath (Yoshi) with Fire Breath (Discuss) Deadline: September 28, 2012, 23:59 GMT
 * Split Giga Carrot and Carrot. (Discuss) Deadline: October 04, 2012, 23:59 GMT

Writing Guidelines
None at the moment.

New Features
None at the moment.

Removals
None at the moment.

Merge All Game Modes Into Their Respective Game Articles They Appear In
This a matter that has become very important recently, because I've seen users making game modes in articles of their own and has created some incosistency on game articles that have their modes within - in special those latest game articles like Mario Party 9 ' s modes, New Super Mario Bros. 2 ' s Coin Rush, and New Super Mario Bros. U ' s Boost Mode. Aside of the fundamental issue, the game articles are becoming less lenghty and less deep in information without them, and look also incomplete without all the info the game modes provide just for the sake of making an article for them and because game articles are overly long. Another fact is we don't have categories for game modes, and thus, users make up for adding game mechanics categories (and as a rule of thumb, game mechanics are for gameplay options like movesets, strategies, and whatnot) and in the worst of the cases cataloguing as mini-games, and technically they aren't mini-games, they are game modes, unless Nintendo or the game itself tells that way - if the game officially calls them mini-game, then they will have their own article but otherwise won't.

Actually a solution, if we can merge the game modes into the game articles is simply rewritng all the section, making it less wordy and keeping the essential to prevent that users consider the game article "just too long".

Another solution is to make a new feature to trait game modes, creating a category (clearly called "") to keep them. However, treating game modes articles in this way may create a radical change over other games that also have game modes, for example, the Mario sport games, Mario Kart games and many other games (modes such as Balloon Battle, Time Trial, Story Mode, etc.).

Proposer: Deadline: September 22, 2012, 23:59 GMT.

Don't merge game modes

 * 1) Some game modes, including the second one you mentioned are very far from the "minor subject" state and are pretty significant.
 * 2) Per MarioSmasher and the reason I opposed to merge Coin Rush with New Super Mario Bros. 2.

Create Game modes category

 * 1) This way can solve the problem... Though creating a proposal for a category shouldn't be necessary, but well.

Comments
@Mariosmasher, The fact that a game mode articles is in general long does not make it relevant as to have its own page. Additionally I never said that are a minor subject, they must need a proper treat that settles everything.
 * I know I pointed something that you didn't say, but the fact you want all game modes be merged in their respective games may count as saying "nearly every minigame is about a minor subject". -- 09:30, 16 September 2012 (EDT)

As a general rule, topics should receive their own articles (as long as a decent amount of information can be put together). This is perfect usage of the empty section policy and article size policy that we're not just throwing all that specific info on the page about the game. -- 16:37, 15 September 2012 (EDT)

We've always had game modes being merged with the respective game article. @Porplemontage: I don't think that applies to game pages because if you split off the story, game modes, reviews, etc. what you have left is a fancy template page. Even Wikipedia retains some sections on their video game articles and they're all about splitting stuff.-- 23:19, 20 September 2012 (EDT)

Overturn Excessive Userspace Regulations and Improve Ability to Log and Enforce Userpage Editing Rules
I would like to suggest that we overturn some regulations on the userspace of the wiki that I feel that, although once had a legitimate purpose on the wiki, now might serve as an obstruction to editing or are simply no longer necessary to enforce.

Userspace Policies
 * "A navigation template for the talk page archives (This can only be made if it's used on all the archives; if you only want to put the directory on your current page, just build it right into your talk page, rather than creating a whole separate template.)" (section) &mdash; This proposal calls for the elimination of the bolded part. I think that whether a user wants to use the page on all or one of their user talk pages is their decision. The navigation template would exist no matter what, so it is pointless to involve ourselves with the enforcement of such minutia when we have better things to focus on as a community.
 * Would be rewritten as: "A navigation template for the talk page archives."
 * "A status page (Like the archive template, this should only be made if it's meant to be used on multiple pages; if it's only going to go on the userpage or the user talk page, just build the message into the page itself.)" (section) &mdash; Would be overturned as per my reasons for overturning the same rule that this one references.
 * Would be rewritten as: "A status page."
 * "Pages that are just meant to be transcluded onto another page (I.e. a status update that only goes on one page, a subpage that just contains the userbox tower, or some other component of the userpage: just put the content on the page directly. If you find that it makes your userpage too cluttered, consider lessening the amount of content.)" (section) &mdash; This is sort of a silly policy when used to cover all said pages. Users should not be forced to trim down their pages (for example, sometimes coding gets long for a small aspect of the userpage– sometimes it is simpler to outsource these longer components of the userpage to a sub-page in order to reduce clutter). If it makes editing the userpage easier and makes it neater and more trim, I think that is something that should be encouraged as it makes sifting through these pages easier for all parties involved (the user the page belongs to, administrators having to perform maintenance on a userpage, etc.). Anything that would not belong on a user sub-page would already be covered by other policies (such as whether it contributes to the wiki or community in any fashion, if it is spam, etc.).
 * Would not immediately be replaced with anything.
 * The creation of another proposal that specifies certain instances in which a page should not be created for the sole purpose of being transcluded onto another one (which are not clearly defined in the "What should I avoid?" section) is suggested in order to close potential loopholes that could lead to abuse.
 * "Archives of deleted content (If something you want to keep is being deleted, save it on your computer - it has no place here anymore.)" (section) &mdash; I do not think that this should be specifically disallowed, but that restrictions perhaps be put on it. For example, storing deleted content for the sake of storing it should be disallowed as, at that point, it is spam content (already covered by other restrictions). However, if there are ongoing changes being made to an archive of a once-existent article in order to perhaps revive discussion on its legitimacy or whatnot, that should be allowed.
 * Would not be replaced with anything.
 * "Pages that do not serve the Super Mario Wiki (I.e. fiction, opinion pieces, polls, sign-up sheets, additional information about yourself, etc.: please restrict these sorts of user-content to your main userpage. When in doubt, ask an admin, or simply err on the side of caution and do not create a new subpage.)" (section) &mdash; Same reasons as provided for the first three points. Anything that does not belong on the wiki will also have already been banned as per userspace content restrictions.
 * Would be rewritten as: "Pages that do not serve the Super Mario Wiki (see below for the sorts of things you shouldn't be doing here at all). When in doubt, ask an admin, or simply do not add content or create a subpage."
 * "Excessive swearing" (section) &mdash; Rather than outright ban it, I think we could instead place restrictions on swearing, such as perhaps requiring userpages with strong swear words to display a warning notice at the top or to find a way to make viewing these words optional. Repetitive and mindless use of such words would, of course, constitute spamming (as covered in that same section) anyway, and could potentially also violate the "flaming and defamation" policy.
 * Would be rewritten as: "Excessive swearing (unless a disclaimer is placed at the top of the page or the swearing is somehow hidden from immediate view)."
 * An advanced template that can be used to hide away strong language can be developed for those who are more familiar with syntax.
 * "Mainspace templates (while you can't post actual templates, you can copy the codes of things like infoboxes and repurpose them for your page; warning templates may not be copied, however)" (section) &mdash; I feel that the copying of warning template codes should be allowed for testing purposes only. Any other uses would violate already-existing policies on the warning templates and joke warning notices.
 * Would be rewritten as: "Mainspace templates (while you can't post actual templates, you can copy the codes of things like infoboxes and repurpose them for your page; warning templates may only be copied for testing purposes and must be restricted to a specific test subpage or section)."

Signature Policies
 * "Your signature must link to your userpage. It can also have links to your talk page, contributions, etc., but never to other users' pages. You may have a maximum of five word links, internal or external, including the mandatory user page link." (section) &mdash; The only thing I suggest for this is that the obvious exception to non-existent userpages be codified. Other than that, I have nothing to suggest for this policy.
 * Would be rewritten as: "Your signature must link to your userpage (the only exception is in the case that you do not have a userpage at all). It can also have links to your talk page, contributions, etc., but never to other users' pages. You may have a maximum of five word links, internal or external, including the user page link."

In addition to the proposed overturns or amendments to those policies, I would like to provide for provisions that increase the transparency of changes made by the administrative team to userspace policies, and also allow for the improvement of being able to track down changes made to the userspace policies.


 * A log must be created and maintained that contains an extensive record of new policies that are implemented that affect the userspace that includes what the policy does, how it effects the community, the date of when it is/was approved and/or implemented, and citing any publicly available discussions behind the policy.
 * Any and all new userspace policies enacted by the administration must be logged by the administration in the public log that is to be created.
 * Any and all userspace policies enacted via proposal or decided upon by the community at-large must also be logged. The entry in this log must also link to the proposal itself that made the change effective.
 * Administrators may not edit anybody's userpages or sub-userpages except for in the cases of performing a maintenance task, enforcing the rules that bind said pages, or upon request of the user that the page is assigned to.

Finally, for the purposes of simplicity, any current userspace rule that is overturned in this proposal will not be "un-applied" post de facto (which means any changes made under said rules will be kept and not undone- the reversals will simply provide that the rule will no longer be actively enforced). New userspace policies and restrictions proposed can, however, be made to apply to all appropriate situations.

Thank you for your time.

Proposer: (with modifications suggested by  and  in the comments section, as well as various changes suggested by the Wiki Administrative Board) Deadline: September 27, 2012, 23:59 GMT.

Endorse

 * 1) &mdash; Per me.
 * 2) Per proposal. We may be allowing a bit more freedom throughout certain aspects of the userspace, but in my opinion, it is all very logical and fair.

Comments
I think the userspace log is a great idea. Perhaps it can be expanded to include all policy in general. I agree with most of the changes to userspace, and that one change to the signature policy. But I feel that we shouldn't be allowed to create userspace templates for just the userpage. Also, excessive swearing shouldn't be allowed, and the need to hide any offensive comments through coding could be frustrating to users new to wiki syntax.
 * Thanks! And yeah, that is something I would like to be extended to other sets of policies, but for now I think the userspace is probably a good first place to start (for the purposes of this proposal, at least). The reason I suggest removing the limitations from the single-purpose templates is to alleviate space from the user articles and allow editing to become easier. I understand the logic behind the current rule is to prevent unnecessary sub-pages and also to prevent information being scattered everywhere, but I feel that those principles can still be sensibly implemented through spam rules on the userspace policy (as well as other restrictions present in the rule page there). Outsourcing certain information (such as complex coding) can be useful and can allow for us to be able to find problems more quickly (for example, coding on a really long article can take a long time to find&mdash; having them on sub-pages can alleviate this problem by allowing somebody to work with a smaller amount of text and such). I just want to provide the users with that sort of choice in order for them to do what they feel is right. Also, with the swearing rule, I again feel that the same principle can be applied through other rules (namely the spam and flaming rules). Otherwise, if it is not intended to be mindless junk or to offend people, that is where the notices could come into play&mdash; whether it be through fancy coding to block out particular words, or a simple "Warning: This page contains strong language" notice at the top. Of course, I am still open to discussing this, though, so if you still have concerns, feel free to bring them up. :P 00:02, 20 September 2012 (EDT)
 * Hey. I can see single-transclusion userspace templates being allowed, but, (just as a suggestion) we should have restrictions, so users won't see a lot of freedom in that area and create excessive subpages. Large parts of userbox coding should be acceptable, such as the userbox tower. But we should limit miscellaneous subpages such as personal infoboxes, page background code, etc. About the swearing, like you said, as long as any swearing/profanity is not singled out on any particular user, and it keeps to a level where it's not ridiculously excessive, then it should be allowed. A good mainspace example to giving a choice as to hide swearwords can be seen here. But if these new regulations are to come into play, we should organise a simple template that is to be placed at the top of any potentially-offensive page. And we should keep an advanced template which can hide specific words for more syntax-capable users. But other than that, I agree with your proposed changes. Cheers, SMB.

I don't see the problem with specifically addressing "Pages that do not serve the Super Mario Wiki" in the subpage section in addition to the overall "don't do this" section. Rather than redundancy or repetition, I view it as emphasis, and there's nothing wrong with that. However, the point could be modified to say "see below for the sorts of things you shouldn't be doing here at all" rather than "please restrict these sorts of user-content to your main userpage" (which doesn't work if transcluding subpages are allowed again), and maybe the "err on the side of caution" bit could then say "do not add content or create a subpage". I'm also leery about removing the "excessive swearing" point: just because a lot of it could be covered by the spam and flaming rules, ensuring that nothing undesirable gets through the cracks with a general moratorium is a good thing - although I'd be fine with adding, for example, "(unless a disclaimer is placed at the top of the page)" to the point (not that defending people's right to swear excessively is particularly high on my list of concerns, tbh). I also agree with YoshiKong that specifying limitations on transcluded subpages (and userspace templates, which are basically the same thing anyway) would be a good idea, rather than simply removing the rule outright and opening the system up for abuse: most users will be reasonable on their own, but it's good to have solid ammo to stop the one or two troublemakers. Similarly, rather than removing the "warning templates may not be copied, however" bit, adding "(except for testing purposes restricted to a specific test subpage or section)" to the rule would be better - I'm not sure if that's what you intended all along (the bold is vague), so I'd figure I'd address it specifically, and also add the subpage bit to ensure the wiggle room couldn't be abused. Again, like the transclusion stuff, I'm sure most people will be responsible with the templates, but it never hurts to be sure; imo, the best rules are the ones that only need to be used in emergencies. -

I made various changes to the proposal to perhaps make it more acceptable or clear in some cases. Unless I missed something, I tried to meet all of the suggestions in this comments section except for specifying limitations on transcluded userspace pages&mdash; this is because I feel that doing so might be more appropriate for another proposal instead (in fact, I decided to include a point specifically suggesting the creation of such a proposal that covers the topic further in depth). Other than that, if there are more comments, keep them coming! :) 01:17, 21 September 2012 (EDT)

Miscellaneous
None at the moment.