MarioWiki:Proposals/Archive/33

Automatically Removing Fan Votes from FA Nominations
AUTOMATICALLY REMOVE FAN VOTES 7-0

There have been far too many times where I have seen someone support or oppose the nomination or denomination of a featured article simply because of the fact that they like the character or enjoy the game or whatever. These kinds of votes have no place here, where articles are featured based on their ability to represent the best that the wiki has to offer, not on any personal preference. However, we still have to go through the process of getting three people, at least one of which has to be an admin, to vote to remove his vote and then waiting 24 hours before finally being able to remove it. Enough of these votes can stall either kind of nomination until they have no way of passing when they shouldn't even be there in the first place. So, what I propose is to outright disallow these kinds of votes from being used. If they are used, they're to be removed without going through the longer removal process (for unfeature nominations) or deleting the reasons and leaving the vote (for feature nominations).

Proposer: Deadline: March 30, 2013, 23:59 GMT

Support

 * 1) Supporting.
 * 2) Per proposal, this should hopefully get rid of the fanvote stopping Mario & Luigi: Partners in Time getting unfeatured. EDIT: Articles should be featured/unfeatured on (lack of) quality, not I like this
 * 3) but i liek dat game hav it feachured rite nao!!!!!!!!!!!!!!!!!! Support; that example is not a vote, just pure bias.
 * 4) Per proposal.
 * 5) This proposal is made by my favorite color! It should pass! But really, those types of votes do nothing other than unnecessarily slow the FA process. We should remove them on site. Per proposal.
 * 6) Per all.
 * 7) — Here's what it is up to today (no user cited is real, just examples):
 * " Plz feature this game cuz i liek it!!!!! PLZ!!!!!!"
 * " its an awsome charcter so it shuld be fetured"
 * " i hate gombas so it must be unfetured"
 * " yoshi is so cute he must be fetured he is sooooo cute!!!"
 * Things like these should definitely be cleared out. Per all.

Make an iPhone/iPad app
DO NOT CREATE APP 1-14

My idea is to make an app for the iPhone or iPad that links you straight to the wiki. Since not entirely nessecary, it should be free. I got this idea because Khan Academy has the exact same thing as I'm suggesting. What's more, we'll be the FIRST wiki to do this!

Proposer: Deadline: April 1, 2013, 23:59 GMT

Make an app

 * 1) Per proposal.

Don't make an app

 * 1) &mdash; You yourself state that creating an app is unnecessary. Why would the Wiki garner from a completely unnecessary addition that isn't even provided by the Wiki itself, but some other second-party or alternatively third-party management getting in the way? I just don't see it improving the Wiki at all.
 * 2) It's impractical, it'll be annoying to create in the first place, and it's simply unnecessary for both the average wiki visitor and the average wiki editor.
 * 3) Per all, completely unneccesary.
 * 4) Like what the other's said
 * 5) That is just useless.
 * 6) Like Phoenix said somewhere other than here, why would we need an app when a home screen shortcut does the job?
 * 7) - Per all.
 * 8) - Per all.
 * 9) - Per all.
 * 10) Per all.
 * 11) Per all.
 * 12) Unnecessary, waste of money. Per all.
 * 13) — "…What's more, we'll be the FIRST wiki to do this!". …You probably ignored that Wikipedia has an indipendent iOS app, too. And there's Wikipanion, still for iOS, that did the already done job: you can have more than one wiki in the same app, you can jump to a specific section without going up the page, and several more features… Per all.
 * 14) Like RandomYoshi said, the proposer himself stated that an app is unnecessary. Per all.

Comments
@MortonBoo99--You can view and edit the wiki from those devices. In fact, I'm writing this from my iPod.--

Even though I oppose the app, I think a mobile site might have some use (makes it easier to edit from mobile devices). I don't know though, you'll have to bring up anything like that with .--

I agree with Mariotime11

Spoiler Template
DO NOT ADD SPOILER TEMPLATES 1-15

I think we should use a template for articles that states that the page contains spoilers, a lot of other wikis have them. Like for example, what if someone was thinking of buying Luigi's Mansion: Dark Moon and skimmed the article to read about it a little? The article has spoilers such as the game's ending right out in the open, so at least we should have a template we can put on SECTIONS that contain spoilers.

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

Support

 * 1) Per proposal.

Oppose

 * 1) I'm opposing for the reason that users shouldn't have to manage Spoiler templates and decide when they should be added or removed. And when people visit this site to read our articles, they don't want to see distracting notices littered around. Pages here are to be written and upheld in an encyclopedic view, and we shouldn't bend our standards and consistency just to suit certain individuals.
 * 2) Take pages such as Bowser, which scatters spoilers amongst non-spoilers like salt and pepper and blurs which is which (for example, in this day and age, is it really a spoiler that the final boss is Yoshi's Island is Giant Baby Bowser?). Take pages such as Doopliss or Shadow Queen, where the title or even mere existance of the page is a spoiler.
 * 3) - Definitely per YoshiKong. I was going to write a small text explaining the reasonings, but he said it the best.
 * 4) - Per all, and per the proposal that got rid of our original spoiler templates. There are spoilers everywhere, as is to be expected of a Mario encyclopedia; we have a disclaimer about it, but beyond that, it's the reader's responsibility to avoid spoilers, because marking them is way too much trouble and looks like crap.
 * 5) - Per all.
 * 6) It's funny, I had the same thought a couple of days ago. But we shouldn't do that, because the wiki would be full of templates otherwise. If somebody doesn't want to read spoilers, he should not go to the page that will obviously contains spoilers (Luigi's Mansion Dark Moon as in your example)
 * 7) – Per all. As has been said time and time before, complete coverage of the Mario series implies that we will cover spoilers.
 * 8) Per all.
 * 9) Per Walkazo and SMB
 * 10) Per all.
 * 11) Per all.
 * 12) Per all.  Thought it was a regular template though.
 * 13) - Per all.
 * 14) - Per all.
 * 15) I'm pretty sure if people didn't want to give any part of the game away, they wouldn't read the article.

Comments
@MortonBoo99: I don't think you grasped the basic idea of the proposal. -- 20:12, 1 April 2013 (EDT)

Tell non-trolling IPS when their edits are undone
OPPOSE 1-15

I think that when we undo an edit from an anonymous IP that they should be notified, unless they are obviously a troll. This should happen because it means when they find out their edit has been undone they will have reasoning for why and so they'll know not to just add it back in. For example, today on the Yoshi's Island DS page, in the babies section, an IP address replaced the Yoshi Island DS Baby Mario and Baby Bowser sprite with their respective Super Mario World 2: Yoshi's Island sprites, this was undone and then a few minutes later they put it back and it had to undone again, if they told that their edit had been undone and were told why then it is likely that they would not have done it again. If the IP address is obviously just a troll then will not need to be notified about this, but for the honest people who just help out they do need to be notified.

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

Support

 * 1) Per proposal.

Oppose

 * 1) - I personally feel it's unnecessary to force everyone into following this procedure. If you want to, you can always let them now, but enforcing it with a proposal feels too much to me. Plus, if you provide a good edit summary when reverting edits, it's possible they'll see it and know why their edit was reverted.
 * 2) - Per Tucayo.
 * 3) Per Tucayo.
 * 4) - Per Tucayo.
 * 5) - Per Tucayo.
 * 6) If you want to do it, do it. I like the idea. But this shouldn't be a policy, that's taking it too far. Per Tucayo.
 * 7) It has good intentions, but I fear that it's going to be more trouble than it's worth. True, some I.P. addresses are unaware that a recent changes page exists (I didn't know about them prior to my joining the wiki), but I feel what you want to enforce is already practiced as courteous common sense, something we should already do anyway, and it shouldn't need enforcing.
 * 8) Per Tucayo.
 * 9) Per Tucayo.
 * 10) Per Tucayo.
 * 11) Per Tucayo.
 * 12) - Per Tucayo.
 * 13) • per all.
 * 14) I feel like this is unnecessary, so I agree with Tucayo and everyone else.
 * 15) Per Tucayo.

Comments
You could be more specific about what exactly will happen should this proposal pass. I mean, you are saying they should be notified, but how? If it is through normal messages on their talk pages, then I'm fairly sure this doesn't warrant a Proposal, but you could tell exactly what method should be used to notify them. ---
 * Talkpage is my only thought, how else can we tell them? I'd say it does warrant a proposal, because I can't just force everyone into doing this, unless the proposal passes
 * Even if this passes, you can't force people to tell the IP every time they make a mistake.--

You know, if someone doesn't bother to create an account in the first place, chances are their interest in the wiki is already fleeting enough that they won't even care that their edit was undone. There's no need to bother these people with what they will most likely think is spam. -

Notification for when watched pages are edited
DON'T NOTIFY 5-15

You know how there's a banner that is on every page of the wiki whenever your talk page is edited, right? Well, this is basically the same thing, just for when something else is edited; the pages that are on your watchlist. This way, we don't have to keep on checking Recent Changes or our watchlist several times a day. The banner should look something like this;




 * A page on your watchlist has been edited. Click here to see the change(s).

(the Mario article was used as an example)

The "here" part would take you to the comparison window between the most recently-made edit and the edit right before it.

Proposer: Deadline: April 22, 2013, 23:59 GMT

Support

 * 1) Per proposal; this will make it much easier to keep track of watchlists.
 * 2) Per proposal and per Goomba.
 * 3) Per proposal.
 * 4) Per proposal.
 * 5) This allow us to keep track of our watched pages. If people have too many pages or find that distracting, I think there should be a option to disable it.

Oppose

 * 1) I don't see this as being more convenient than just checking the watchlist.
 * 2) A lot of people find those templates that follow you around kind of annoying. Also, what if your watchlist is crammed with a lot of pages? I check my watchlist whenever I'm waiting for someone to reply on a talk page, or tracking changes to articles I often edit, etc.
 * 3) Per all.
 * 4) - That would be incredibly annoying, per all.
 * 5) That would just be annoying as shit. Per all.
 * 6) - Let's say you have many watched pages. And magically they get instantly changed in a range of a minute. It would cram all the page as heck with lots of notices like this one.
 * 7) Per all.
 * 8) I don't think we really need this. You really shouldn't compare this to talk pages since they're two completely different things.
 * 9) Per all.
 * 10) - It's unnecessary, annoying, unattractive and most importantly, impossible (see Comments).
 * 11) Per Walkazo.
 * 12) Per Walkazo.
 * 13) - Per all.
 * 14) That seems a bit unnecessary to me. Per all.
 * 15) Rather unnecessary, kinda annoying (imagine users who watch 100's of pages), someone will have to make the code but they'ren't forced to, and finally just have a habit to check the watchlist.

Comments
What would be displayed if several pages which are on your watchlist have been changed since your last visit, rather than just one? Would it just show the most recent? -- 03:15, 15 April 2013 (EDT)
 * "A page" would turn into "Pages", and it would say "Click here to see the most recent changes on [name of article here], [name of article here], etc." 03:17, 15 April 2013 (EDT)


 * Okay so what if you had a whole list of articles which were edited since your last visit. What would the maximum amount of pages which would be displayed on the notice? Also, it might be best to ask Porplemontage about this idea. -- 03:23, 15 April 2013 (EDT)
 * Yeah, I'll notify him soon. As for the limit, I'd probably say about 10 or so. 03:24, 15 April 2013 (EDT)


 * Porple said that it's not feasible, so I think this should be withdrawn. -- 04:31, 15 April 2013 (EDT)

@NSY I think profanity is not allowed here. Or am I wrong?
 * It is allowed, but discouraged. From the Courtesy Policy: "The occasional use of profanity is allowed as long as it is not directed at another user, but it should generally be avoided.". --

I think it'll become a distraction.

Allow Featuring/Unfeaturing Article Nominations to pass by majority
DO NOT ALLOW FEATURING/UNFEATURING ARTICLE NOMINATION BY MAJORITY 3-14

I'm pretty sure there has been several near-successful featuring or unfeaturing article nominations over the years that are unanimous, but right at the last moment, someone opposes it, and because of just one user, the entire thing fails. I wanted to change that by adding a rule that featuring/unfeaturing articles nominations must pass by 50% of the votes plus one. (i.e. 5 to 2, 7 to 3, etc.) It will be a better system and also show that more articles are in really good quality or that more articles need a dusting.

Proposer: Deadline: April 28, 2013, 23:59 GMT

Support

 * 1) Per proposal.
 * 2) Per Goomba.
 * 3) Per Goomba.

Oppose

 * No, if we allow this then we are basically allowing fan votes to decide. I've seen archives of Mario for being featured and it was tonnes of supports because everyone likes him. If we allow this then it means some articles like Nintendo 3DS can be featured and at its current state we can't allow that due to a rewrite template and bad images. And also lots of people could support the unfeaturing of an article and then someone could come along and fix it up, but not be able to remove all the supports and a so a perfectly good article gets unfeatured.
 * 1) No articles should only be fa's when they are perfect and everybody agrees to that if an article has votes against it it means that the article is flawed and the flaws should be fixes (or that the votes are outdated in which case ask an admin) allowing articles to be fa'd when they have valid oppose votes on them will only lead to bad articles being featured because they are major characters.
 * 2) Per all.
 * 3) I would like to add to Marshal Dan Troop's vote (which I per with) that should an article's flaw is incorrect is fixed, we can always vote to remove it (and chances are, the oppose vote will get removed in time). So I think the current system is as fine as it is.
 * 4) Per all.
 * 5) &mdash; Per all, especially Marshal Dan Troop and Baby Luigi.
 * 6) Per Super Mario Bros.
 * 7) Per King Pikante.
 * 8) - Per all.
 * 9) Per all.
 * 10) Per all.
 * 11) Per all.
 * 12) Per all.
 * 13) - Per Marshal Dan Troop.

Comments
@Yoshi876 Fan votes are automatically removed now, so that isn't a problem anymore. 04:58, 21 April 2013 (EDT)
 * But reasons for supporting when featuring an article aren't allowed, so one person could say 'I think the Mario article is good because it has detail and images' and the all the fans would vote and it'd be impossible to see if they were fan votes because they can't leave a comment saying 'I love Mario'.
 * Yeah, I think that it's still a problem: there are still fan votes. 08:01, 21 April 2013 (EDT)
 * It's not much of a problem when one valid oppose vote just tips the side of the FA nomination.

Promotion/Demotion templates
DO NOT USE TEMPLATES 3-15

I think that we should have templates to alert a user that they have been promoted/demoted; it provides a quick reference on their talk page when they were changed. (Note that this is not changing the criteria for promotion in any way) The templates would look something like this:

Proposer: Deadline: April 29, 2013, 23:59 GMT

Support

 * 1) Per proposal.
 * 2) You should be alerted when you get promoted,
 * 3) Per Electrical Bowser jr.

Oppose

 * 1) This is something that is absolutely unnecessary.
 * 2) this is completely pointless we have a user rights log for this.
 * 3) Per all.
 * 4) - Per all.
 * 5) Superflous and tacky-looking.
 * 6) A normal message on your talk page such as "Greeting (user). Due to the quality and frequency of your contributions, the Mariowiki staff has agreed to promote you to Autopatrolled status. Note that this does not carry any additional powers or responsibilities, and that it mostly serves to make patrolling edits easier on our end." is fine enough.
 * 7) It would be annoying and unnecessary, as per Marshal Dan Troop's comment.
 * 8) Per GreenDisaster and Marshal Dan Troop.
 * 9) Promotion/demotion notices take place on the forums nowadays. And if anyone wants to say a congrats on the user's talk page, they can do it without a tacky template.
 * 10) Per all.
 * 11) Per all.
 * 12) Per all.
 * 13) - Per all, especially YoshiKong.
 * 14) - Per all. Our current way of doing things is fine.
 * 15) Per everyone, especially both YoshiKong and GreenDisaster.

Comments
Even though I supported, I know this will fail.


 * You are alerted when you are promoted in fact before you get promoted an admin asks you if you want the job then they send you a message like this one
 * By "tacky", do people mean how the draft templates look? And also, they have such templates on Userpedia here and here, and they seem to be working fine.


 * I don't like the second one's design especially. The animated GIF is not the best type of image we need for a template.
 * @LeftyGreenMario How about this? Luiginesog.png
 * It's better, but I doubt this proposal will pass (I also think the notification is not needed, but the outcome is obvious). Hypothetically, I'd choose that one.


 * I actually prefer the "we're cracking you over the head with a hammer and sending you packing like discarded rubble" image: it's far more amusing. -
 * I thought it was a random image that didn't really make sense because Jumpman was promoted by a "power-up." :P

I actually wouldn't be opposed to this sort of thing. Then again I am kind of a sucker for tackiness (in moderation). -

Delete Links to Passed Talk Page Proposals ONLY Until Action Has Been Taken
LEAVE THE LINKS UP 10-0

Normally, when a talk page proposal passes, we delete the link to the talk page proposal in this page. The problem is that this may leave settled talk page proposals not done because the settled proposal basically is out of sight for many users. I remember one talk page proposal settled a long time ago and no action has been taken until years later; it may have been forgotten. Just recently, few users have taken action in splitting enemies in the Subspace Army article, and I'm wondering if people don't realize it or if they are too busy doing something else.

My proposal is this: if a talk page proposal has passed, we should leave the link on the main proposal page until action has been taken according to the talk page proposal. And once the action has followed, then we can remove the link. That way, we know if action has been taken on that proposal or not.

This is necessary so we ensure appropriate action has been taken when a talk page proposal has settled.

This can also apply to more major proposals, but talk page proposals are the ones that need more awareness.

Of course, exceptions can apply.

Proposer: Deadline: May 2, 2013, 23:59 GMT

Support

 * 1) We should keep links to the talk page proposal on this page until action has been taken. Then, we should remove them. That way, users know if the actions a talk page proposal requires have been taken.
 * 2) Per LGM.
 * 3) Per LeftyGreenMario.
 * 4) This is a good idea. I also think we should note when they have passed. For example, if a TPP has passed but has not been applied, we should note that it passed and that the edits have to be done.
 * 5) Per all.
 * 6) - Funny, I was just thinking about this the other day. Simply replacing the deadlines with "passed" until the change was made was how TPPs were originally done; I dunno why we stopped doing it that way, but bringing the practice back makes total sense. However, not archiving full proposals would make this page very cluttered, and given their larger scale, many aren't quick fixes to start with, so I think it'd be better to stick to archiving them straight away.
 * 7) Per all.
 * 8) - Per all.
 * 9) &mdash; Per LeftyGreenMario, Banon, and Walkazo.
 * 10) - Per SMB.

Comments
Isn't this what we normally do, anyways? That was the way it was at least a few months ago.
 * I brought this up because the link to the proposal splitting the Subspace Emissary enemies was deleted, and nobody has really taken action to split the sections into articles, so it appears that we have already done that.

For the bigger proposals, perhaps we could have a page where the passed proposals are moved to an archive specifically for proposals that haven't been taken into action yet? After whatever the proposal wanted to do has been done, it can be moved to the standard proposal archive. It would bring attention to proposals that haven't been put into effect, and wouldn't cause much cluttering. It's just a thought.
 * That sounds like a good idea. Usually, though, bigger proposals get more attention, so more users can do something.
 * A while back, I made a proposal about splitting a bunch of Donkey Kong Country Returns enemies that had 20 support votes and 0 oppose votes. It took nearly two years for all the necessary articles to be created, and that was only after I made a thread over on the forum. Even if the majority of them get attention, there's always one that slips through the cracks.
 * That's why I said it was a good idea. I also said, "Usually". We probably do need to make a section for passed proposals that didn't see action yet.

Accurate titles for files
CHANGE TITLES 22-0

I have noticed files with, , and. Not only does this decrease professionalism and violate the image policy, but it also makes it more difficult to search for files (e.g. a search for filenames containing "toad" would leave out results if an undescriptive title was used). Even if these images are "only used once or twice", a descriptive title is still more useful.

I am proposing that we go back and rename files used in mainspace/gallery/etc. ('Shroom and userspace would be exempt from this, basically) articles that are breaking the policy, as well as enforcing a standard based and possibly expanding on what is written in the image policy I linked beforehand. I would not be opposed to going back and helping with the work, assuming this proposal passes.

Proposer: Deadline: May 5, 2013, 23:59 GMT

Support

 * 1) - Per proposal.
 * 2) - Per proposal.
 * 3) - Per proposal.
 * 4) - Per proposal, because names should be more clear and appropriate.
 * 5) - I agree, specifically with the part about searching for files. Having fun is good and nice, but when functionality is compromised, that is when priorities must be set.
 * 6) - Per all.
 * 7) Per all.
 * 8) Per all. I used to like uploading retarded file names, but now, I don't.
 * 9) While I don't agree with the "professionalism" part (it can be both fun and presentable), we need standard and to-the-point file names instead of creative ones. I stopped making up my own file names a while ago. Also, per Walkazo's comment.
 * 10) Per all.
 * 11) Per all.
 * 12) Per proposal.
 * 13) Per proposal.
 * 14) &mdash; Per proposal, and Turboo and Kibago specifically.
 * 15) Per proposal.
 * 16) - Per SMB.
 * 17) - Per all.
 * 18) Per all. "Happy Fatty"? That's some serious BJAODN right there!
 * 19) Oh god, "Babypeachyushee'seyelandeees". I cringe at the thought of doing that. I'm  glad to god I decided to stop that while I had the chance. Per all.
 * 20) Per all. I think to move 530.jpg to Koopa Bros Bowser Castle.jpg.
 * 21) Per all.
 * 22) Heck yes. Per all.

Comments
At PidgiWiki, we have a standard which works well. What we do is put the subject of the image first, followed by a hyphen, and then the game/event is comes from.

For example: "Bowser Artwork - Super Mario Bros." If there is an alternative image, we use "Bowser Artwork (alt) - Super Mario Bros.", "Bowser Artwork (alt 2) - Super Mario Bros.", etc. This could be a good way to go.-- 05:17, 28 April 2013 (EDT)
 * I don't really like an idea of a naming standard, since that means we have to rename every single file in this wiki to match the standard. I think the best way to go is to at least make sure the image is descriptive, professional, and follows the image use policy. We don't need a single standard for this.
 * If this proposal passes, we're going to be renaming all of the files anyways. I wouldn't be opposed to a standard naming convention, as long as it isn't too convoluted.
 * I don't think we should rename all the images, just the ones that seem to be in violation of policy. While YK's suggestion could work as a guideline placed on the image policy page (even then, like Walkazo said, we should focus on keeping names straightforward), I don't think we need to enforce it, especially since a lot of filenames work even if they're simply the name of the character or the location. - Turboo (talk) 18:46, 28 April 2013 (EDT)

If we were the impose the standard, we should eliminate the "having fun part" since there is a degree where you may have fun uploading images, and it all depends on the user's personal idea what "fun" is. I know I might sound a wee bit sarcastic here since I did this crap in the past, but if we were to have more functional image files, we need to be as serious as writing articles on this.
 * Removing the "fun" clause has actually come up in admin discussions before, but we never went back and actually got rid of it, but yeah, I'd agree that it'd be better without such a subjective point. As for the overall standard, I think making a rigid formula we have to follow or else would be a bad idea: as long as we can tell what the images are of, if there's some variety, it's not the end of the world. We could add more specific requests to the current "meaningful name" parameter, such as having the name of the game (or an abbreviation), what kind of image it is (profile art, screenshot, boxart, whatever), and what the image is of (name of the character in the profile, name of the level a screenshot it of and maybe some info about the shot, etc.). However, there should also be emphasis on making the names straightforward: I'd argue that "Bowser art SMB" and "Bowser art 2 SMB" would be preferable to the ones YoshiKong suggested, since they're shorter and don't mess around with punctuation (brackets, dashes) and extra words ("alt"). Similarly, even if a screenshot contains Bowser, Mario and a Podoboo, something like "SMB screenshot end of 1-4" would be easier to use than "SMB screenshot 1-4 Bowser, Mario and a Podoboo"; or if a screenshot is of Mario and a Whacka, "PM screenshot Whacka" would be fine, since the Whacka's the important part. But again, most image names are fine even if they don't follow this sort of "what/kind/game" standard, and renaming them would be excessive and annoying, so even requesting those three things should be more of a guideline than a hard rule. -

At the My Little Pony: Friendship is Magic, they also don't use names like File:HappyFatty 9.png. At that wiki, they use descriptive names for photos like
 * We don't follow wikias. Nevertheless, I think putting the description IN the file name is a bit unwieldly. I prefer the description to be reserved for the aboutfile.
 * Yeah. Otherwise, the filename is too much of a mouthful. :P.

Add to Help:Link
WITHDRAWN BY PROPOSER, DISCUSSED ON FORUM

I think we should include Plainlinks here. I mean, there's every other kind of link, so why not include that?

Proposer: Deadline: May 13, 2013, 23:59

Support

 * 1) Per proposal.
 * 2) Per proposal.

Comments
I don't think this warrants a proposal (here, at least).
 * Yeah, you should post it here instead
 * @Baby Luigi Isn't that thread only for small edits that the admins can just go and make? For this I'd have to make a draft.