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.
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.
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
Only autoconfirmed users may create or vote on proposals. Proposals can be created by one user or co-authored by two users.
Anyone is free to comment on proposals (provided that the page's protection level allows them to edit).
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.
Users may vote for more than one option, but they may not vote for every option available.
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.
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.
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.
Proposals cannot contradict an already ongoing proposal or overturn the decision of a previous proposal that concluded less than four weeks (28 days) ago.
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.
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.
If a proposal reaches its deadline and there is a tie for first place, then the proposal is extended for another week.
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.
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.
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.
After a proposal passes, it is added to the appropriate list of "unimplemented proposals" below and is removed once it has been sufficiently implemented.
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.
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.
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.
Proposals cannot be made about promotions and demotions. Staff changes are discussed internally and handled by the bureaucrats.
No joke proposals. Proposals are serious wiki matters and should be handled professionally. Joke proposals will be deleted on sight.
Proposals must have a status quo option (e.g. Oppose, Do nothing) unless the status quo itself violates policy.
Basic proposal formatting
Copy and paste the formatting below to get started; your username and the proposal deadline will automatically be substituted when you save the page. Update the bracketed variables with actual information, and 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}}}} Per 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 heading, 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.
Having multiple infoboxes side-by-side in stats sections looks terrible, so after months of forum discussion and design drafting in my userspace, I am proposing complete redesigns of all the RPG infoboxes, primarily to allow for them to be able to toggle between vertical and horizontal forms. Vertical forms can be used like normal, at the tops of enemy pages as their main infoboxes: clutter is bad), but now for stats sections, the horizontal forms can be stacked on top of each other instead of haphazardly floating side-by-side and at the whims of varying screen widths. This is the main purpose for this proposal (hence it's in "new features"), but at the same time, various other changes will happen:
All RPG infoboxes will toggle between vertical and horizontal forms - See above. Note that the vertical forms are the defaults so this won't cause mass appearance chaos as soon as the templates are changed.
All RPG infoboxes will use the same colour-scheme as navigation templates(as seen here) - This will create consistency and ensures neatness and easy readability.
All RPG infobox pages will have usage instructions and an input chart - This will make them easier to use.
All RPG infoboxes will use consistent inputs whenever possible - This will also make them easier to use (less memorization and guessing), although it also means some inputs are being renamed and/or combined and will need to be updated on the articles (noted in red on the draft pages below).
Some RPG infoboxes will be expanded with additional info - The infoboxes should have all the stats that we know of present, rather than forcing folks to look up supplemental charts in the bestiaries or elsewhere.
{{pm2enemybox}} will need to be (re)created - Right now, Paper Mario and TTYD use the same infobox, but once all the new stats and featured are added, that won't be possible anymore, plus it's inconsistent and unnecessary to have two games in one.
RPG infoboxes embedded in History sections should be moved to stats sections - If it's not the enemy's overall infobox, it should be in a stats section: it's just inconsistent clutter anywhere else.
It sounds like a lot, but the redesigned templates have all been drafted and are completely ready to go. All that needs to be done is updating the articles themselves by adding inputs to bring the templates up-to-date, and reorganizing the stats sections (including moving some infoboxes down there from History sections). Examples of the templates in action can be found here, and the drafts are as follows:
As seen in the proposal's title, bestiaries are also on the slab here, and the reason why is because, rather than having multiple and/or too-wide-for-1024px-screen tables that force readers to scroll up and down and back and forth, from now on, bestiaries should take the form of multiple stacked horizontal infoboxes. Basically, anyway - as seen on Megadardery's test pages here and here, a slightly different template will be used to change the headers from the game titles to just the enemy names, and the bestiaries will still need to include the templates in an overall table for slightly more compact stacking and uniform column widths. However, the important part is that the bestiaries' inputs will all be the same as the corresponding infoboxes', making it a simple matter of cutting and pasting to move and update information between the bestiaries and the enemy pages, or at least make it easier to use both (even the how-to information is mostly the same). A final note is that the bestiaries will now use colour-coding in the names to denote enemy types (bosses vs. enemies vs. support), as explained in the nice legend at the top of the first test page I liked to in this paragraph.
Unlike the infoboxes, only the Paper Mario bestiary is drafted and ready, but I think it's still better to get the ball rolling on this overall stats project sooner than later and start working on getting those horizontal infoboxes out there: more bestiaries can follow in time.
Baby Luigi (talk) Though I haven't commented, I've been in support of an RPG infobox template overhaul since the day it was suggested. It, at the current moment, is extrmeley unsightly, ugly, and most importantly, horribly formatted to not fit in with the stats and the like. Therefore, I'm in major support with this proposal and I want it to pass ASAP.
Bazooka Mario (talk) The way the vertical layout of RPG infobox templates are used is utterly miserable. Here are some examples: Dry Bones, Fawful, Lava Piranha, Blooper, Spiny, Buzzy Beetle, Elite Trio, the list goes on, but it's no small sample. They leave behind lots of white space, are extremely cluttery and overall messy, and they're not very reader-friendly. Worse, practically any recurring enemy article from a MaRPG game is doomed to have several of these templates, which are not designed with recurring enemies in mind. I also support moving infoboxes that otherwise clutter the article like in Boo or Hammer Bro. to stats section and get converted to the horizontal design. I'm glad we're going to redesign some of the wiki's biggest eyesores.
Wildgoosespeeder (talk) Very sharp looking compared to the dated templates we are using now.
Using {{conjecturaltext}} in headers has a couple of issues. For one, it looks ugly and inconsistent with how other headers look like. The only acceptable text formatting in headers should be italicising as to indicate that it's a piece of fiction being talked about. Underlining text in headers is very bad. Furthermore, it breaks the Recent Changes. Using the Recent Changes, a user may jump directly to a section of an article if only a section was edited. However, should the header contain {{conjecturaltext}}, this feature is broken. Having a feature that breaks a vital function of the Wiki should never be allowed. Sure, you could just hop to the section manually, but why would you do that when the Wiki can provide you a function that does that for you automatically?
I do realise and acknowledge that there is an issue with this: how do we notify the reader that these names are conjectural? The solution is simple.
===Thing that is conjecturally named===
'''{{conjecturaltext|Thing that is conjecturally named}}''' is a thing blah blah blah blah
That way, we get the information that it's conjecturally named across, it doesn't break the Recent Changes, and it makes headers look consistent. This means that all information is preserved, and we don't have to implement a feature that breaks a very vital function of the Wiki. Alternatively and depending on the kind of section being worked with, the text doesn't need to be in a bold typeface. This also gives us the possibility to quickly summarise what the section is about in one sentence before describing the rest of the subject in greater detail. Furthermore, this methodology ensures no unnecessary and ugly notification templates need to be used at all. Additionally, removing {{conjecturaltext}} does not break section linking at all, so all links that already exist and link to headers that already contain {{conjecturaltext}} will not be broken and still work.
But how do we go about finding these? The answer here is also simple. This is how.
EDIT: The old link for finding the instances of the template did not work, so this will be used instead.
Proposer: RandomYoshi (talk) Deadline: January 11, 2016, 23:59 GMT
Unfortunately MediaWiki search is broken, so the link you provided will not help us find the pages. But as far as I've seen, the only pages with conjectural section titles are the Galaxies and list of Glitches, which should be easy enough to track down. Otherwise, how is the suggested workaround going to work in the list of glitches pages? It doesn't seem efficient to specify the glitch name in every section. I think we need a better idea to over all say "Yo guys, these are all made up names so don't quote us on them will ya?".--
12:03, 4 January 2016 (EST)
How about making a similar template to Template:Conjecture, but that states something like "The titles of the following sections of this article are conjectural; [and the rest is equal to the base template]"? It could have a "section=" variable that, if set to yes, states "The title of the following subsections of this section [equal to normal]". The first is used in glitch pages, the second in Galaxies pages. TSUNAMI
Having additional notice templates is only going to help in increasing how messy pages look like. It's not going to be the end of the world if we repeat it for every subject we talk about. In fact, it's better to first aptly summarise a subject in one concise sentence before prattling on about the minor details of a subject: that way, readers who only wish to gain an elementary understanding of a topic can choose only to read the first sentence of a paragraph, whilst others that feel like they want a more in-depth analysis can do so by continuing to read about the subject. Because {{conjecturaltext}} is used in the beginning of the sentence and has the subject bolded (or not), the information that they're conjecturally named is still going to be conveyed in the same way it's done at this point, except it won't break the Recent Changes and generate unprofessional-looking headers. To summarise, it won't hurt us, it won't hurt the reader, it won't hurt the page by introducing a whole batch of notice templates, and it certainly won't hurt the Recent Changes. RandomYoshi(Talk • PMs • C) 13:47, 4 January 2016 (EST)
No, it would be repetitive to state the nonofficial name of the glitch underneath every glitch section with that exact same title, it seems okay in the introduction of main articles, because you really are introducing the main element of the page, however in glitches' pages, it becomes overly annoying to read the same thing over and over again. It's like going over every section in the Mario article starting it with "[..] is a game that Mario stars in." which would be insane. Don't get me wrong, I support this proposal, because this issue is super annoying when it comes to actual editing and linking. However, the consequences of doing it this way is not something I support. I don't support the idea of the notice template either, it would be an eye catcher. However, adding it to the introduction of the list in one short sentence is not something I'm keen on, but not something I'm against either.--
15:10, 4 January 2016 (EST)
I agree with RandomYoshi at this point. However, I have another idea: if templates are not good, let's just add a sentence just before the various section start. It should say "NOTE: All the glitches'/galaxies' names in this page are conjectural. Fitting names have been given by the editors.". This may seem repetitive, but remember that phone users have no way to read the message shown by hovering the cursor over conjectural text. TSUNAMI
TSUNAMI
RandomYoshi( • PMs • ) 13:47, 4 January 2016 (EST)
