MarioWiki:Proposals

Proposals can be new features (such as an extension), removals of previously added features that have tired out, or new policies that must be approved via consensus before any action is taken. Any user can support or oppose but must have a strong reason for doing so, not, e.g., "I like this idea!" "Vote" periods last for one week. All past proposals are archived. All proposals must pass by a majority, including proposals with more than two options.

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 {{User|User name}}.

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. Anyone can comment on proposals whether logged-in or not, but only registered users can create or vote on proposals.
3. 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.)
   • 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. Proposals with more than two options must also be extended another week if any single option does not have a majority support: i.e. more than half of all votes cast must be for a single option, rather than one option simply having more votes than the other options.
10. If a proposal has more than ten votes, it can only pass or fail by a margin of three votes. In other words, one option must have 50% + 3 of all votes cast. This means that if a basic two-option 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. Proposals with more than two options require more precise counting of votes to determine if an extension is necessary.
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. 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.
14. 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.
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''': {{User|[enter your username here]}}<br>
'''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====
#{{User|[enter your username here]}} [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 "#{{User|[add 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 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 "(Template:Fakelink)". If the proposal involved a page that is not yet made, use {{fakelink}} 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 {{TPP}} under the section's header, and once the proposal is over, replace the template with {{SettledTPP}}.
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.)
   • 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.
4. 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.
5. The talk page proposal must pertain to the article it is posted on.

List of Talk Page Proposals

• Remove the "Notable Members" section on the article Human. (Discuss) Deadline: February 24, 2013, 23:59 GMT
• Create a page for the colored Bloopers seen in Super Mario Sunshine. (Discuss) Deadline: February 25, 2013, 23:59 GMT

Writing Guidelines

None at the moment.

New Features

Quick identification for patrollers, sysops, etc.

We all know that there's different ranks of users here at the SMW. It'd make sense that we'd want to know who's who. We can already see who's a patroller, sysop, etc. by going to a special list or sometimes going to their user page. But if you want to know who's who quickly for a specific reason (i.e. a bureaucrat for a name change) then there should be some sort of identification on or next to their name on the Who's Online template, or better, wherever their name is displayed. I was thinking maybe a specially-colored name, a picture of some sort next to their name, or at least an acronym. (ex. BC for bureaucrat, PT for patroller, etc.) Because really, who (other than the staff themselves, of course) is going to be able to name every single SMW staff member right off the top of their head, hmm?

Proposer: Goomba (talk)
Deadline: February 26, 2013, 23:59 GMT

Support

1. Goomba (talk) I've had trouble looking at who's a staff member before; I almost got just an ordinary user to change my name. More reasons of mine above.
2. YoshiKong (talk) We do have something like this on the forums, where users with ranks are given different-colored profiles. I think it would be good to implement this here as well in case new users needed to report something to an admin asap, but haven't quite learned who's who yet. As long as we are able to implement this feature, I support it.
3. YoshiFan1200 (talk) Not a bad idea. Maybe this could help new users to find help with a adm.
4. Mario4Ever (talk) Per proposal.
5. Electrical Bowser jr. (talk) Per proposal.
6. King Pikante (talk) That should definetely be there, because if new users enter the wiki, they do not know who can help them and who is experienced. Anyways, that should be there without an argument.
7. ThePremiumYoshi (talk) - Yeah, yeah, per all.
8. Aokage (talk) Per all.
9. Super Mario Bros. (talk) — Although Porplemontage has already endorsed this idea and plans to implement it, I'd like to indicate my support for the proposal. Per Goomba.
10. Turboo (talk) - Per all.
11. Walkazo (talk) - Per SMB.
12. BowserJunior (talk) - Per all.
13. BabyLuigiOnFire (talk) Per all.
14. L151 (talk) - Per all.
15. Tucayo (talk) - Per SMB.

Comments

Just voted, but I've noticed that you singled out Autoconfirmed users in the title. Unlike admins, I don't believe they need special identification on Who's Online. --YoshiKong (talk) 02:49, 19 February 2013 (EST)

Now that I think about it, you're right... --Goomba (talk) 02:53, 19 February 2013 (EST)

It might be a good idea to find out whether this sort of thing is even possible. The last thing you want to happen is to have this proposal pass and have no way of implementing whatever means of additional identification is decided upon. Mario4Ever (talk)

This is possible and I will do this. --Steve (talk) 03:16, 19 February 2013 (EST)

Just curious, but any word on Autopatrolled users? BabyLuigiOnFire (talk)

No point. They're just regular users who make good edits and/or who were admins: being autopatrolled simply makes the admins' job easier, and doesn't affect other users at all. The point of this (as I understand it) is that users can either get to know the staffs' names, or more importantly, find one in a pinch if there's a flame war, or a troll attack or some other problem that needs a current admin's attention. Having too many colours (or icons or whatever) muddies it up and makes it harder to find what you need, so it's best to keep it straightforward and only single out the current staff, I think. - Walkazo (talk)

So would we settle on one color for the staff or different colors for each rank within the staff? --YoshiKong (talk) 00:17, 20 February 2013 (EST)

I'd says different colors for each rank. --Goomba (talk) 02:02, 20 February 2013 (EST)

Just got a good idea on what icons to use if this passes.

We should use the SMG Prankster Comet icons. (, , , , and .)

You guys like the idea? Goomba 03:10, 20 February 2013 (EST)

This is just my opinion, but I think colored names would be better. The icons are a bit too tall for the names on Who's Online, and visually whether the icon is put on either side of the name, it might get confusing to look at. I think staff should be given this color: Username. A red is easy enough to distinguish from the blue: complementary colors. --YoshiKong (talk) 03:49, 20 February 2013 (EST)

That looks like a red link (page doesn't exist). Might get confusing. Aokage (talk) 03:57, 20 February 2013 (EST)

I think using different colors is best (imo, the icons would be going a little overboard), not too sure about red though; as Aokage said, I'd feel like I was looking at red links every time I saw our names. I was thinking green, like how it is on the forum. Phoenix (talk) 04:04, 20 February 2013 (EST)

Green's good. --YoshiKong (talk) 05:37, 20 February 2013 (EST)

Well this feature has been implemented. Looks great. --YoshiKong (talk) 15:57, 20 February 2013 (EST)

I agree, and I have no doubt that this will prove useful. Mario4Ever (talk)

I've got a suggestion for it. Where it has the legend for what the colors mean, can we link to the respective MarioWiki page for that rank? --YoshiKong (talk) 16:07, 20 February 2013 (EST)

Great idea! --Steve (talk) 16:16, 20 February 2013 (EST)

Wow, my first proposal and it passes unanimously. :D Goomba (talk) 19:28, 20 February 2013 (EST)

So... since this proposal has already been put into effect, is there any point in leaving it open? GreenDisaster (talk)

I thought about archiving it yesterday, but folks were still discussing the colours and whatnot, so I decided against it. Things have slowed down now, but ehh, I don't care either way; dunno how others feel, tho - I can only speak for myself. - Walkazo (talk)

Force Show Preview before saving an edit to a page

Title says a bit enough, there should be a little notice when editing a page that could tell the user:

To prevent consecutive minor or major edits on the same page or section, you must click Show preview before saving the edit.

and it blocks the Save page button until the user clicks Show preview to see the edited page or section. This could be applied to unconfirmed users and anonymous editors. There's a JavaScript code here that must be imported into the MediaWiki:common.js page, but this extension is best to use for the case (smart users might disable JavaScript and bypass the force preview function). The JavaScript one lets you, through the code shown, modify who doesn't get affected and who does, for instance:

1: var permittedGroups = [ "autoconfirmed", "sysop", "bureaucrat", "autopatrolled"];
2: var permittedGroups = [];

Code 1 doesn't force the show preview to autoconfirmed users, sysops, bureaucrats and autopatrolled users, code 2 forces the show preview to everyone.

The extension version is more secure and forces to use the Show preview button, even with JavaScript disabled.

Think it is a good idea?

Proposer: NewSMBU (talk)
Deadline: March 1, 2013, 23:59 (G.M.T.)

Support

1. NewSMBU (talk) – Prevent consecutive edits on the same page: no cluttering of the recent changes page.

Oppose

1. Electrical Bowser jr. (talk) It's a good idea to do the preview, but shouldn't be forced.
2. ThePremiumYoshi (talk) - I don't think the preview button should be forced - it would be very bothersome to have to click the preview button when making similar edits to a bunch of pages (i.e., adding {{BoxTop}} to a group of pages), not to mention that it would just hinder edits - people can simply click the button and then save the page without seeing if the changes are constructive.

Identification in user pages

My idea is that there should be a identification in user pages, like the star identifying Featured Articles. The idea of having colored usernames is a good way to identify who is the proprietor, administrators, bureaucrats and patrollers, but you need to find the username in the Who's Online template or in the history of an article. Also, some users haven't confirmed their accounts, but their usernames doesn't appear colored. To solve this, something like the star in featured articles appear in patrollers, etc. user pages and in non confirmed users, it appear in their talk page. The icon should be a mushroom for patrollers, a fire flower for administrators, a star for bureaucrats, a poisonous mushroom for unconfirmed users, something like that. If someone put the cursor above the icon, a text in a white box saying "This user is a XXX. Click for more information." or "This user didn't confirmed his account." appear, and if someone click in the icon he will be redirected to the MarioWiki:Patrollers, MarioWiki:Patrollers, etc. page. To unconfirmed users, nothing happens when someone click in the icon.

Proposer: YoshiFan1200 (talk)
Deadline: March 1, 2013, 23:59 GMT

Support

1. YoshiFan1200 (talk) We don't have to go to the history of an article or wait to the user be online to see who is bureaucrats, administrators and patrollers. This also make easy to see who is confirmed and who isn't confirmed.

Oppose

1. ThePremiumYoshi (talk) - I don't think this is necessary, seeing as there are links on the recent changes to the MarioWiki:Patrollers, MarioWiki:Administrators, and MarioWiki:Bureaucrats pages on the line "Wiki staff".
2. Tucayo (talk) - Per TPY.

Comments

Some user may not see these links in the Wiki staff, because it's colored in orange, purple, green and light blue, and other links are in dark blue. YoshiFan1200 (talk)

Well, I do agree that it's kinda hard to see that those are links, but I still don't think the icon system is necessary - it could be done in a much simpler way. --- ThePremiumYoshi

Removals

None at the moment

Changes

Series' articles

There is some discrepancy on this wiki involving around the series' articles and it is that all those articles completely mismatch with each other when it comes to listing the installments in the series. Some get listed in a very different way which, in my opinion, is actually a mess. Many articles use a wikitable that lists the release year, a breif description, and some game ratings, the Mario (series) article is a good example; other simply list the year release, the system or console and a link to the beta elements for said game, the Mario Kart (series) article is pretty obvious; few articles got lazier a simply have a paragraph describing the game and the boxart on a thumbnail, the Mario vs. Donkey Kong (series) article says hi; and finally the rarest of all: an infobox for every game is used instead, the Mario & Luigi (series) article is the case here. Seeing how this messy is, I got into the conclusion of using a single format for every series' article, I propose choosing one single format for all these articles as I don't see a reason to have multiple and different formats when we can just simply have one.

Proposer: Byllant (talk)
Deadline: February 24, 2013, at 23:59 GMT.

Use wikitables

1. Byllant (talk) - I personally think this is the best option, and because changing the whole Mario (series) article would be a lazy process.
2. Glowsquid (talk) - consistency's good.
3. BabyLuigiOnFire (talk) This is the best organized one. There is a reason we use tables much to organize information in this wiki. All the rest either look lazy, cluttered, or just plain ugly when it comes to displaying information.
4. ThePremiumYoshi (talk) - This is the best way to organize the information. Per all.
5. BowserJunior (talk) Per all.
6. Mario4Ever (talk) Per Glowsquid.
7. King Pikante (talk) Per all.
8. Tucayo (talk) - Per all.
9. Turboo (talk) - Per all.
10. Walkazo (talk) - Per all.
11. YoshiKong (talk) Per all.
12. Tails777 (talk) It would make these articles more organized. Per all.
13. Blue CosmicToad (talk) - Per all.
14. Super Mario Bros. (talk) — Per Byllant's proposal and Glowsquid's voting reason.

Comments

Should anything else be added into the wikitables, aside the features already listed? - Byllant (talk)

I think it's fine the way it is. All necessary information is already there. In my opinion, adding anything else would probably make the information redundant or not needed. BabyLuigiOnFire (talk)

Increase the file size limit for OGG videos

A problem I've noticed when trying to deal with cutscene recordings from games is that while they can usually be compressed to under 10 MB, the quality suffers especially if the cutscene is a few minutes long (this is especially noticeable with GBA games).

However, my main issue is not the inability to upload higher quality cutscenes, but rather it being outright impossible to upload some cutscenes regardless of quality. I had planned to upload some from Mario Super Sluggers along with some other Wii games, but even with extremely low video quality (64kbps bitrate), the files were around 15 MB. It would be nice to raise the limit to around 25 - 30 MB (50 MB or so would allow for longer cutscenes, but is our priority getting them uploaded even with very low quality, or supplying them at a reasonable (but not exactly HD) quality?); I don't know how much of a strain this would put on the server, but in my opinion, raising it for these videos (I don't know if it's possible to raise the size limit just for certain file types, but I doubt people would start uploading 25 MB images anyway) would be helpful.

Proposer: Turboo (talk)
Deadline: February 24, 2013, 23:59 GMT

Increase size limit (an appropriate amount can be discussed in the comments)

1. Turboo (talk) - Per proposal. Somewhere around 25 - 30 MB would be good enough for me.
2. YoshiKong (talk) I've had similar issues in the past involving video size restrictions, so if we were able to increase the file size limit then I'm supporting it.
3. Super Mario Bros. (talk) — If Porplemontage confirms that this would be possible and that it wouldn't be too much of a weight on the server, then I support Turboo's proposal. Expanding the file size limit for these videos can allow us to be more inclusive with our coverage of cutscenes on the wiki itself. In the end, the fuller coverage is something we should strive for. We could always try to regulate, through proposals, any specifics to cut down on abuses of the expanded file size (such as restrictions on files not being used for the mainspace articles and whatnot).
4. Sonic98 (talk) Per all

Do Nothing (keep the size limit at 10 MB)

1. BowserJunior (talk) It's much easier to link to the video, and that limit is there for a reason – for some people, this would make loading times horrendous, on my iPod anything larger than 4mb can cause safari to crash.
2. ThePremiumYoshi (talk) - Per BowserJunior.
3. BabyLuigiOnFire (talk) I don't see the need for this, especially if we can use YouTube as an external link to these OGG videos.
4. King Pikante (talk) Per all.

Comments

You should ask Porplemontage about this: he's the one who calls the shots on file limits. Either way, seeing as YouTube is already pretty much the go-to place for cutsenes, afaik, it seems easier just to keep externally linking, rather than burning our server space on this kinda thing. - Walkazo (talk)

I kind of figured it would be up to him, but I don't know how strict we are on YouTube; do we just forbid people from using the tags in mainspace articles and allow linking of cutscenes in the External Links section? - Turboo (talk)

Yeah, still no tags on the articles: it makes them too large and cumbersome to load. External links are one way to do it, but I think using references would be even more effective. - Walkazo (talk)

@BowserJunior: The only way this would affect loading times on certain pages is if the videos were loaded on the page (they aren't)/if people started uploading huge images and placing them on pages if the size limit were increased for every file type. I can't say I know how overall server strain/load times would be affected by larger files, though. - Turboo (talk) 20:08, 18 February 2013 (EST)

Change the "The Identifiers of Articles" policy to be decided on a case-by-case basis

I recently left this comment about article identifiers and brought it up a few days later in the chatroom. Glowsquid and Marshal Dan Troop informed me that would be going against what this proposal has laid out. This effectively means edits like these, which were made by the creator of the original proposal, are violating policy right now. I propose we change this policy so that it encourages users to move pages based on common sense, not an unclear one-size-fits-all rule.

Proposer: Turboo (talk)
Deadline: March 1, 2013, 23:59 GMT

Support

1. Turboo (talk) - Per proposal. A policy page for this (instead of just remembering it and enforcing it that way) would be helpful as well.
2. YoshiKong (talk) Per Turboo. Consistency is usually desired, but game identifiers aren't always the most suitable for article titles.
3. King Pikante (talk) Per Turboo.
4. ThePremiumYoshi (talk) - Per all.
5. Tucayo (talk) - Per Turb.

Comments

About the policy page, I think it's best to outline the guidelines at MarioWiki:Naming#Shared Titles. --YoshiKong (talk) 03:17, 22 February 2013 (EST)

I think we can nail this down into a formula. If an identifier is needed, the text in parenthesis is determined by:

1. What the thing is. For example: Dribble & Spitz (souvenir) is correct.
2. If the same type of thing appears in multiple games, use the game title. For example, World 1-1 (New Super Mario Bros. 2) and World 1-1 (New Super Mario Bros. Wii) are both levels from different games. We cannot use World 1-1 (level) for obvious reasons because we need to differentiate between games.
3. If just the game identifier is misleading as to what the thing is, use the game title followed by what the thing is. For example, assume there is a "Dribble & Spitz" souvenir in two WarioWare games. We would use Dribble & Spitz (WarioWare: Twisted! souvenir) and Dribble & Spitz (WarioWare: Smooth Moves souvenir) because without the added "souvenir" text, no one would guess the article was about a souvenir and not Dribble & Spitz themselves.

--Steve (talk) 03:38, 22 February 2013 (EST)

I agree with these guidelines. --YoshiKong (talk) 03:57, 22 February 2013 (EST)

Quick question: can I ask why the three articles you mentioned in violation of the policy? GreenDisaster (talk)

Miscellaneous

None at the moment.