MarioWiki:Proposals/Archive/29

__NEWSECTIONLINK__

The problem here is that it completely italizes the title, while some articles only need some words to be italized (the Mario (series) and Donkey Kong (series) are good examples), so if the proposal passes, we might need to make a code that could italize certain words, that range from the whole title to a single word.

Proposer: Deadline: December 20, 2011, 23:59 GMT

Create a new template

 * 1) - I kinda like the idea.

Don't create anything

 * 1) Per this.
 * 2) Per that
 * 3) Per Bop1996.
 * 4) Per all.
 * 5) I agree with the rest (essentially per Bob1996). This feature is unneeded on this Wiki.
 * 6) - It's not really needed, since you only need to input two apostrophes to enable italics.  No need to go more advanced than that.
 * 7) Per all.
 * 8) – Per all.
 * 9) Per all.
 * 10) Creating a template for just italicizing is an excuse for laziness.  Per all who agree with me.
 * 11) - Yeah, it would be actually more complicate, when you can just use two apostrophes. Per M&SG.

Decide if the Yellow and Blue Toad in SM3DL are the same ones from NSMBW
DELETED BY PROPOSER There is only one Blue Toad and one Yellow Toad that appear in SM3DL and no other color Toad appears other than the Red Toad apart from Green and Pink Toads in the Title Screen. Proposer: Deadline: January 5, 2012, 23:59 GMT

The Toads are the same from NSMBW

 * 1) Per my Proposal

The Toads are not the same from NSMBW

 * 1) I think it's more likely to be a Toad Brigate
 * 2) Unless and until there is an official source connecting the two games' Toads, any claims that they are one and the same are speculation.
 * 3) Per Mario4Ever.
 * 4) The 2 Toads appear seperate from all other Toads (except the ones that need saving within levels) while the Yellow and Blue Toads in 3D Land appear with 3 other Toads. We have no proof that the ones from NSMBW and SM3DL are the same. In other words, per Mario4Ever.
 * 5) Per all
 * 6) Per all
 * 7) Per all; in my opinion, this is under the "species" case here for this installment.
 * 8) And the proof is... ?

Comments

Bookmarks
OPPOSE 2-19

When a user wants to find an article that they often visit, they would need to type in the searchbar. When an internet user wants to find a website that they often visit, they don't search in a google search bar, they go to Bookmarks in their internet browser and find their favourite websites. It should be the same here on the Super Mario Wiki. For pages and articles that we often visit, there should be a bookmark section for our individual account somewhere on the page, like on the top next to my watchlist or on the side bar under navigation. Here, we should be able to bookmark pages for easy navigation. If you agree, please support me.

Proposer: Deadline:January 11, 2012, 23:59 GMT

Support

 * 1) Per my proposal.
 * 2) I totally agree with Yoshi Kong. I've actually been wanting something like that since I joined the wiki.

Oppose

 * 1) - On this wiki, the articles themselves have internet links to them. If you feel like you visit the page quite often, then bookmark it like you would with any other site. There is no reason to add a feature that you can already do.
 * 2) Per BMB. Also, it's not hard to find an article using the search bar at all, and the watchlist feature helps you keep tabs on important pages, so there's really no need for it.
 * 3) Per both.
 * 4) This proposal is redundant to the watchlist and to the bookmarks that comes with all browsers.
 * 5) Per All
 * 6) This seems a bit pointless. Per all.
 * 7) - Per BMB and Bop1996.
 * 8) - Per all.
 * 9) Per Baby Mario Bloops and Bop1996
 * 10) Assuming everyone who visits the wiki has more than one finger and can use a keyboard easily, searching in the search bar isn't hard at all. It's so easy, 2 stalks of celery and a paper towel could do it. Per all.
 * 11) We have a contents page on are articles. Per All.
 * 12) - Per all.
 * 13) It's simple enough to search.
 * 14) Per all. You can just bookmark it using your browser.
 * 15) – Like others have been saying, this is kinda useless because we can either use the watchlist or bookmark it on our browsers. If we can do those things, I don't see the point in adding this.
 * 16) Creating a JS (.js) file is required for a feature such as this. If creating the JS file wasn't too overly complicated, I would probably support this decision; however making this "bookmark" feature is way too complicated. You could possibly consider trying to make a .js file of your own. Re-propose once it's done so we could consider moving it to MW space. I'm sorry.
 * 17) This additional feature would be unnecessary, especially since the watchlist already does this.
 * 18) Per all.
 * 19) Per all.

Comments

Dealing with new stub articles - a better and friendlier way
SUPPORT 19-4

Many new short articles are requested for deletion as new stubs instantly after they are created, which is in my opinion, not called for. I propose this should be changed.

After a new stub is created, a template explaining that it is a new stub and that it will be deleted in seven days after the template is put on the page is put on the page. Within that one-week period, articles have some time to expand to acceptable article length. If they reach acceptable article length within a one-week period, the article stays, however if they are still stubs after one week, the article is deleted.

This process prevents scaring newcomers away (when I was a newcomer, I created an article, it was immediately tagged as a new stub, it was deleted and I was beyond frustrated, as I haven't added all content within that creation), and given the main goal is to expand stubs, not to get rid of them!

Addendum: I have created this, which is similar to what should be used to tag new stubs.

Addendum (00:49, 10 January 2012 (EST)): This has nothing to do with the already existent construction template. This is "proposing deletion" of new stubs, instead of deleting them without delay. At least a week is given before they are deleted (unless they are expanded to stub length). Thanks for your !votes.

Proposer: Deadline: January 16, 2012, 23:59 GMT

Support

 * 1) Per proposal. I hope I will be more respectful with the users who !vote 'oppose' this time.
 * 2) - Great ideia. I agree with your words: We should expand stubs, not just simply get rid of them because they are stubs. I always wondered why are new stubs requested for deletion, if we can simply expand them. Per B.wilson
 * 3) As long as you have enough rubies we can tell the difference between a stub and a short article. Per B.Wilson.
 * 4) This does seem to be a more efficient way of dealing with the stub articles. Additionally, this would also raise awareness of the stub articles as they can be fixed before immediate deletion. Per B.Wilson.
 * 5) I agree with most of but i feel that one line articles that can be expanded should be deleted because I think its unfair to let somebody who didn't  do any work get credit for making an article
 * 6) Per all. It gives newly created stub articles a chance to be improved.
 * 7) This is a much better way of having less stubs rather than just deleting them.
 * 8) Although there is a construction template, I'm skeptical that new users even know a construction template exists. For the more experienced users, they can implement the construction template easily, but based on the aforementioned  situation, they don't do it. I think this proposal can help this problem. If not, at least the wiki isn't harmed.
 * 9) - Per all.
 * 10) Per all
 * 11) – Per all
 * 12) - Per all.
 * 13) Per all
 * 14) - Stubbed articles do need a chance to be improved before being subject to deletion.  Per all.
 * 15) - Exactly the same as M&SG.
 * 16) Makes sense. Per all.
 * 17) Per all.
 * 18) Per all.
 * 1) Per all.

Oppose

 * 1) I don't disagree with the premise, but the situation is easily rectifiable with a construction template (though ideally, one would, when creating an article, make sure it is of sufficient length before stopping his or her work for a given period of time).
 * 2) Per Mario4Ever. Also, there's a certain amount of admin discretion involved in whether the articles are deleted. For example, if an article is on a subject like a racecourse in an upcoming Mario Kart installment, chances are the article won't be expanded for a while, especially if it's just one user adding some details and leaving it. However, if a game was just released, and the article is being worked on by many people, the article is not deleted.
 * 3) I find unnecessary. That's what basically a construction template is for. It's a red flag saying, "DO NOT DELETE, IT NEEDS SOME WORK!!"
 * 4) - Construction templates tell the user that work needs done. As a person that has spent many edits unstubifying, I know it is very tedious and hard. However, deleting the page will just create more red links, and from basic experience, will cause even more trouble to create that page later on than to unstubify it later on.

Comments
Zero777: I must apologize for saying this, but your !vote is not opposing anything clearly explained in the proposal. This is basically "proposing deletion" of new stubs, instead of "pending speedy deletion". It has nothing to do with the construction template. I apologize if I misunderstood your !vote, but I don't really think it's relevant to the proposal's intention. --
 * Now I really don't understand what you are saying here. The quotation marks are confusing me.
 * Your !vote is basically thinking that this idea is like the construction template, in which it is not. --
 * I see it basically like the same and I don't think it's too much of a hassle to just slap on the construction template next time.

I have to say, this isn't a bad idea. During that 1 week waiting period, the user who created the article can also make his case that the article is not a stub if they feel it isn't one. However, I'll support this if you can make a better sample template than that.


 * 1) The same template you gave is too similar to (perhaps by intention, but I don't want this proposal to bind us to that design). Make it a little more unique, we don't want a clone of the same template.
 * 2) There's no need to mention that middle sentence, "New stubs are not allowed by Super Mario Wiki policy." It's just a waste of space to explain policy in templates.
 * 3) You need to offer a link to the talk page (like ) in case users want to argue that the article not a stub or want feedback on how to expand the article.
 * 4) Allow a variable which users can input the expected date of deletion. You could replace the small text line with "The article may be deleted if it cannot be expanded beyond stub length by [sample date].", sample date being 7 days after the date of stub creation (it doesn't have to get more specific than the date, hours just make things complicated).

-- 15:55, 10 January 2012 (EST)
 * I like the idea too. A construction template can be used instead, but some new users may not know they can use it and have their articles deleted for being too short. Also, it sometimes occurs that an article is put under construction, and then ignored for months or even years. Having a separate sort of construction template that says that the article must be expanded in a week would prevent someone from making a small article, sticking a construction template on it, and then never coming back to the article again.
 * Hi Knife and Fawfulfury, I've tweaked User:B.wilson/Testing facility/Stub to reduce resemblance to the delete template, and I've also addressed all of Knife's concerns. I've given two examples of articles in which template is used: User:B.wilson/Testing facility/Stub/Article (pending deletion on 18 January) and User:B.wilson/Testing facility/Stub/Article2 (tagged on 3 January and currently pending deletion) - both examples are meant to be humorous. I'd appreciate !votes if you think I've addressed your concerns! -- 21:17, 10 January 2012 (EST)
 * I suggest that you change the color of the template to avoid resemblance to the delete template.

I think the difference between construction templates and this new template would be that this template would be placed by an enforcing party (which would be the user claiming that the article is a new stub) as opposed to the article creator. Both could also be used together. For example, a user creates an article with with no defined completion time, but it's a stub, another user could place the proposed template alongside the construction template to remind the user not to forget about the page otherwise his work will be deleted. Also, stub=/=articles under construction. One week should be enough time to expand an article beyond a stub, regardless of whether it's under construction or not.

@B.Wilson: The template is a little better, but the gif is a little wacky. I personally prefer a still image for things as serious as deletion templates. Perhaps a Bullet Bill would fit in better since it goes along with our theme of exploding creatures in deletion templates. Also, there's no need for an additional comments section in the template. There's really nothing to comment on if it's a new stub and if it really needs to be said, the user could use the talk page for that purpose. As for what to do after the deadline has been passed ansd the article is still a stub, there's no need to use the same template to notify sysops of it deletion. It should just be replaced with with the reason being something like "The article is a seven day new stub". There's also something funny about the wording, but I can't put my finger around it. I suppose we can still change that after the proposal.-- 23:20, 10 January 2012 (EST)

Speaking of the GIF, why does the construction template get one? I wanted to change the picture to one of those Mario sprites from Wrecking Crew '98, but you know I can't. Sorry if a little off-topic, but the Donkey Kong Mario GIF in the construction template is a little distracting. We can also use a Wrecking Crew '98 sprite for the stub expansion template instead.

I'm going to make this suggestion again: could you change the color of the template so it won't resemble the delete template at a glance?
 * Done. 01:40, 11 January 2012 (EST)

It is a bit messy to see in your template, that needs some improvement. Like the template changes appearance at "deadline".

I'm pretty happy with the changes made to the template, so I'll go ahead and support. There's no way to change the template's appearance automatically at deadline as far as I know and if we manually change it, we might as well replace it with the delete template since that will attract more attention from sysops. I agree though, there no need to include inside the proposed template, just replace the proposed template with  and be done with it.-- 11:05, 11 January 2012 (EST)
 * I also think it'd look better with just the delete template, rather than nesting it inside the other template. If it has to be changed manually anyway, as Knife said, just replace it, and if it's done automatically, maybe make it so that the entire template is changed (i.e. if it's not expired, it looks like the Bullet Bill template, and if it's expired, it switches to the Bob-omb design mirroring the normal Deletion template). Also, if we're worried about stubs falling through the cracks even with this template, perhaps the articles marked with this pending-deletion template could be put into the Requested for Deletion category. Things in that category aren't deleted outright, and using it for this as well as its original template might help bring attention to the new stubs before their time is up and they join the real deletion queue. @LeftyGreenMario I forget why we added the gif in the first place - it's maybe because it's ugly and distracting and should therefore motivate people to want to fix the article just to get rid of it. Personally, I think we'd be better off just getting rid of the gif... -
 * Hi folks. I've tweaked the template a little to address the template concern. After seven days, the template will automatically be replaced with the  template. See User:B.wilson/Testing facility/Stub/Article2. Best,  00:02, 12 January 2012 (EST)
 * I've also written a documentation (which will have to be significantly altered if moved to template space). Please remember that this template must be substituted or it will not work. -- 06:02, 12 January 2012 (EST)
 * @Knife: "There's also something funny about the wording, but I can't put my finger around it." Maybe the part that says: "This newly created article appears to be stub length."? Perhaps if it were to be changed to something like: "The current length of this newly created article appears to indicate that it is a stub."... 10:44, 12 January 2012 (EST)
 * Or just "This newly-created article is a stub. If it cannot be expanded within seven days, this article will be deleted." The fine print could also lose the "beyond stub length" bit too, since there isn't really a length below which an article is a stub anyway: it's more about how much info is lacking. Maybe the fine print could be more like "This article may be deleted if a sufficient amount of information cannot be added by [Date]", which is more useful than only using jargon like "stub" and "expanded". -

I agree with Walkazo's suggestion for the categorization and the template wording.-- 18:31, 12 January 2012 (EST)
 * Done. -- 01:08, 13 January 2012 (EST)

Enable AutoWikiBrowser for
WITHDRAWN BY PROPOSER

Given that 's users are doing tasks that would be easier and quicker to do with AutoWikiBrowser, I propose that we enable AWB for the wiki.

What can AWB do? Lots of things that are done manually here! It can remove categories from pages more quickly, it can add templates to articles very quickly (and remove templates from articles), and do lots of other tasks that would be extremely tedious to do manually - that many users are wasting time doing manually!

Proposer: Deadline: January 24, 2012, 23:59 GMT

Support

 * 1) Per proposal
 * 2) Per all. If i've read correctly i would love to mulitasking on a single tab.

Oppose

 * 1) Per my comment below.

Comments
Could is create slot of mess in articles because we would have to do alot of cleanup which will take forever. If i've read correctly i would love to mulitasking on a single tab with AWB.
 * I can't think of anything that users do that is so tedious that this is required.

Preventing sockpuppets of existing accounts
WITHDRAWN BY PROPOSER

We all know that Mario Wiki is being flooded with vandals, trolls and spammers with consecutive sockpuppets. But, a website called Hatena has a special system that doesn't allow users to create a second account: in fact, when users try to make a new account, all options are all disabled, so they cannot create a second account. This happens due to an IP address check that checks the user's IP and then allows or not the user to create an account. We should adopt this system so spammers, trolls and vandals cannot create sockpuppets.

Proposer: Deadline: January 27, 2012, 23:59 GMT.

Support

 * 1) We should adopt this as said. Per proposal.

Oppose

 * 1) Per Raven Effect and myself in the comments section.
 * 2) Per me and Bop
 * 3) As much as I want this to stop. It won't work. Per all.
 * 4) I see this proposal causing more inconvenience as opposed to help. The works of various vandals can easily be stopped and reversed; so I don't see the need for the system (especially since it can also affect other regular users sharing the same IP adresses). Essentially, per all.

Comments
Couldn't this prevent people with dynamic ip addresses from signing up
 * If it's solely based off the IP alone, no, it cannot. Sometimes, users will sockpuppet after the 24-hour autoblock on their IP lifts, and sometimes they'll use a proxy or dynamic IP to sock again since hardcore sockpuppeters get their IPs blocked for a limited amount of time. Also, this would make it impossible for a user that forgets their password to make a new account to edit from.
 * Also much another proposal that dealt with preventing sockpuppets I think this is something that's up to the admins. Also wouldn't this ruin users like Uniju and Snack who are brothers and have the same IP address
 * Never thought that. There should be also a "Forgot your password?" option which asks the user's email (if nobody other knows the email) so he or she can recover the password and login again.
 * But what about a situation like Uniju's and Snacks where the brother live at the same house and each want separate accounts
 * Yes, this will also negatively affect users that are siblings or share an IP address for legitimate reasons. Also, Danimario, it's very easy for admins to spot when a user is using the same IP address to sockpuppet; the real trouble is when there's a dynamic IP or proxy involved.
 * We pretty much do things on a case-by-case basis, and no sockpuppet does anything that can't be fixed, so I don't see why this is necessary.

Allow talk page messages on one's talk page, excluding reminders/warnings, to be removed at the user's discretion
WITHDRAWN BY PROPOSER

At times, I've been uncomfortable with some of the messages I receive, not because I don't like them, but as if I felt they immediately needed to an archive.

On many other wikis, it's okay to remove messages if you feel you don't want them to stay on your talk page. I don't like the fact that we can't remove messages from others on our own talk page. Sometimes you may remove them as acknowledgement that you read them. Of course, if this proposal passes, this will not include official warnings.

Proposer: Deadline: February 2, 2012, 23:59 GMT

Support

 * 1) I've always been wanting something like this since I came here

Oppose

 * 1) - Removing messages removes official records, and that is a very bad thing. In fact, instantaneous archiving itself muddles up page histories, and should be avoided. User histories should be clear as a bell, not encrypted by any means. (See comment below, as well.)
 * 2) Per Walkazo.
 * 3) - Per Walkazo.
 * 4) Per all.
 * 5) Per all.
 * 6) Per Walkazo.
 * 7) Per Walkazo

Comments
A lot of the time, informal messages are given instead of official warning templates, and removing those would make it seem like a user wasn't spoken to when they actually have. Collaboration on projects should also remain because removing messages hides the other user's contributions. Even idle chit-chat should remain because removing it is rude (i.e. their removal could be interpreted as "your messages aren't good enough for my talk page"). Even speedy archiving isn't a welcome practice around here, and the admins have actually been discussing making an official policy against it for weeks before it catches on. A couple sections is not cluttered enough to need to be moved (and certainly not removed altogether), and doing so actually clutters up the page's history with unnecessary userspace edits, making it harder to find anything. Removing messages outright makes it nearly impossible because then you wouldn't even be able to see the end product: if you didn't know it was there, you wouldn't know to look for it, and even if you knew it'd still be way harder to dig up the edit than if the message was just left alone. Plus, immediate archiving is often used as a way to bury unsightly messages as a way to avoid looking bad. Of course, even archiving in chunks like one's supposed to do can be used to hide Warnings and informal wrist-slaps (if they just so happened to archive right after receiving a message), but archiving section-by-section is the epitome of that sort of slate-clearing. Removing stuff would be even worse: as I said before, a lot of stuff is said informally, and pretending like it didn't happen would be just as bad as removing a template. -


 * While I don't particularly mind archiving that's done to reduce clutter on the talk page, I do agree somewhat when it comes to informal messages and warnings. Archives end up making keeping track of warnings difficult by design; I imagine an alternate page(s) dedicated to keeping track of user warnings would be a viable compromise, though I doubt such a motion would receive much support.

Change Special:WhosOnline
DON'T CHANGE 11-2

So I've had this idea in mind about doing major renovations to Who's Online. First things first, I think it should be much similar to the Who's Online of our forums, just without viewing guests. It's quite a hassle to inform someone you replied to their comment on a certain discussion in a talkpage/proposal without having known that he/she has currently been typing up a reply on the talkpage/proposal that you previously mentioned. With a Who's Online like the forums', you could actually know what page he/she is viewing, replying to a comment on a talkpage/proposal, or just generally editing an article without having to have wasted your time of the latter. Also, if you're viewing Who's Online via Recent Changes, there could be a show/hide button for you to click that shows extensive details on what they're viewing or commenting on so you can change it to fit your own preferences. Also, there could be a button like this, just replacing Members with Autoconfirmed Users (I'm not sure if there's a term for users who don't have special ranks like Sysops, Bureaucrats, and Patrollers other than Autconfirmed Users), removing Guests, and adding sections for Sysops, Bureaucrats, and Patrollers.

Proposer: Deadline: February 13, 2012, 23:59 GMT

Support

 * 1) Read above.
 * 2) It would be a good feature.

Oppose

 * 1) I don't see any reason to make this change (nor do i know if it's possible.
 * 2) Per Raven Effect. It's good enough the way it is.
 * 3) Per all. It's fine the way it is.
 * 4) Per my comment below.
 * 5) Per Bop1996.
 * 6) . Per All.
 * 7) Per all
 * 8) - Per all.
 * 9) Same as above. The one of nowadays is better.
 * 10) Per all
 * 11) I just don't think it's really necessary...

Comments
"That'd have to be done via extension, and there isn't a feature similar to WhosOnline that I know of that could do that. The WhosOnline only shows users viewing pages on the wiki while logged in, and there's not a feature in there to do what you suggest."


 * Aside from the arguments I have against actually using this feature at all, this probably isn't possible, unless you have some method planned of doing so. The forum version is run by SMF, and this is run by MediaWiki, so it's not like it's some built-in feature we've just been neglecting.

I like the idea, but I doubt if such MediaWiki extension exists, if we can make one, or if Steve agrees.

The forum system and the wiki system AREN'T (notice the caps) good if merged each other. Besides that, I don't like the idea: it makes me feel I'm in a forum with different layout.
 * They aren't going to be merged if this passes. The wiki Who's Online would only be changed to be more like the forum version if this passes.
 * Oh fine. If this passes, then I would get disappointed.

Removal of all non-punctuation redirects
DON'T REMOVE 12-3

While lurking throughout certain articles, I've noticed redirects for article titles that have a punctuation in them that don't include the punctuation, which really bugs me. For example, Super Mario Bros being a redirect of Super Mario Bros. and 9 Volt being a redirect of 9-Volt. It just seems rather unprofessional in my opinion.

Proposer: Deadline: February 13, 2012, 23:59 GMT

Support

 * 1) Read above. (Note: I'm not very good at deadlines, so correct me if I'm wrong.)
 * 2) Per UltraMario3000.
 * 3) I agree with UM3000. All article titles should be 100% accurate.

Oppose

 * 1) I don't see any reason to remove these redirects after all it's really easy to forget the . in Super Mario Bros.
 * 2) Actaully over 50% of people who use our wiki type in Super Mario Bros not Super Mario Bros. and we need to have them tacked straight to the page they wanted just like you typed in Mario which will take you strIight to the page he/she wanted to see. It would be unfair to see people type in Super Mario Bros and get taken straight to the search page for no reason.
 * 3) Per my comment below.
 * 4) Per New Super Yoshi and Raven Effect. Some people don't bother to remember the punctuation.
 * 5) Per all
 * 6) - We should stick with our current policy (see Redirect): it recognizes that punctuation is often omitted or mixed up, and a few redirects to help searchers out is a small price to pay for making the wiki easy to use.
 * 7) Per all.
 * 8) Per all, MarioWiki:Redirect explains why these types of redirects are necessary.
 * 9) Can't argue policy. Per all.
 * 10) We can't be always accurate, and non-accurate users can fall into dead-end pages. Per all.
 * 11)  Do we apparently have an uber-professional image we have to uphold in everything including our redirects?
 * 12) Per Raven Effect and NSY.

Comments
@Opposers: Is it the actual name of the game though? No, it isn't. Abbreviation redirects are an exception though.--
 * So it's more professional to type in SMB than Super Mario Bros
 * Really. So we become more professional typing SMB instead of Super Mario Bros., GCN instead of Nintendo GameCube, GBP instead of Game Boy Pocket. Stop it honestly UM3K. We need complete and non abbreviated titles for the articles.

If you wanted to search SMB to get to the article faster, yes, it is. Titles without punctuation aren't exactly faster to type in anyway. Gosh, one character away. It's like making Mari a redirect of Mario. Why? To get to the article faster of course.--
 * The difference is a . and it's very easy to forget a period it's not easy to forget to o in Mario
 * Well, you're missing my first point anyhow. "If you wanted to search SMB to get to the article faster, yes, it is. Titles without punctuation aren't exactly faster to type in anyway. Gosh, one character away.--
 * What's the difference between typing SMB and Super Mario Bros why should you be able to type in SMB to get to an article but not Super Mario Bros
 * Because Super Mario Bros only removes one character from Super Mario Bros.. People shouldn't be that lazy to forget about the. However, punctuation redirects such as 9 Volt are just awful and should at least be removed. It's easier to forget the period in Super Mario Bros. than the dash in 9-Volt. I guess punctuation redirects could be an except any articles that are not about games.--

"The example title includes punctuation marks, which are one the largest stumbling blocks for searchers. In this case, they can forget the colon and/or one or both of the exclamation marks. For that reason, we have the redirects 'Mario Kart Double Dash', 'Mario Kart Double Dash!', 'Mario Kart Double Dash!!', 'Mario Kart: Double Dash', and 'Mario Kart: Double Dash!'."


 * This makes it pretty clear why we allow such redirects, and far outweighs the arguments against.
 * Ok, but using my point from my reply to GS, redirects like 9 Volt should at least be removed. I assume punctuation redirects are ok in game articles though.--

Also, what about removing redirects in game articles that don't use apostrophes?--

@NSY:"over 50% of people who use our wiki type in Super Mario Bros not Super Mario Bros."--
 * @UltraMario3000: Redirects using hyphens such as 9 Volt are necessary if they're used to redirect people from a commonly-used search term to the actual article.
 * @Bop: Didn't know that. I think you ignored this statement though: "what about removing redirects in game articles that don't use apostrophes?" Also, to add to that statement, I think article redirects that don't include the apostrophes or commas like the article they're redirecting to should probably be removed. If not removing the ones without commas, then at least the ones without apostrophes should be removed, as they're grammatically incorrect anyways.--

From the Spelling section of Redirect (which also provided Bop's earlier quotation): "Leaving out apostrophes in contractions or in the possessive case (i.e. 'Marios' instead of 'Mario's') is considered an unacceptable spelling mistake." Policy pages are here for a reason: read them. -
 * Well, I've seen quite a majority of those kinds of redirects, so I assume it's safe to put a delete template on all of them.-
 * Well? Nobody can be ALWAYS precise linking articles, naming or searching them.

Change emblem of series in the SSB infoboxes to the latest SSB icon of character
WITHDRAWN BY PROPOSER

I think we should change the latest icon of the character. It would be more interesting and would make our wiki better in my opinion.

Proposer: Deadline: February 20, 2012, 23:59 GMT

Support

 * 1) Per me

Oppose

 * 1) - Putting the character's icon in the infobox isn't informative, since it just shows what the character looks like, and that's shown in the main picture anyways. The series emblem, on the other hand, is more informative since it shows what series they are classified in.
 * 2) Per Yoshiwaker.
 * 3) Per Yoshiwaker. The icon is great for the gallery, though. That's where it should belong in.
 * 4) Having a disembodied head of the perspective character as an infobox icon is just plain weird.

Comments
Can't decide if opposing or supporting. --Danimario9 ( Talk ) 15:54, 13 February 2012 (EST)

Is the current icon the symbol for the character's series? (like a pokeball for the Pokemon, mushroom for the Mario etc.)
 * No, by "current icon" he meant by the Stock Icon, not the series icon.

List of stats and descriptions in (game title here)
DON'T ADD STATS 9-2

So I had this idea of making stat/description lists for certain games. It'd include all of the website bios, in-game descriptions, and stats from (game title here).

Proposer: Deadline: February 17th, 2012, 23:59 GMT

Support

 * 1) Read above.
 * 2) I agree! It would be handy to have all this info on the Wiki.

Oppose

 * 1) All of the enemies respective pages have this information for each game. It's like taking that section of an article or the whole article itself and placing it in each games section. Since we already have the information, we don't need it included somewhere else. No for me.
 * 2) Same as above. I wonder if this is strictly needed. Per all.
 * 3) Per SuperPickle.
 * 4) - The proposal's not very clear what exactly would happen should it passes, and it's never a good idea to blindly vote for black boxes like that, especially when they concern such a major topic. If this was just about adding official bios about the game itself, I'd be all over it, but it's not. The comments make it sound like all "official" stats/bios/descriptions/etc. about all the characters/enemies/etc. in a game would go on the game page as well as the character/enemy/etc. articles, but there's confusion about what's official or not, and the stated motivation is flawed: it'll be way more time consuming to go from game to game looking for a character's stats than simply scrolling down their one article. That being said, having info all in one place is helpful a lot of the time, but if done wrong, it could also result in a giant, unwieldy mess. Given the skeletal two-sentence proposal, the complete lack of any sort of draft and the sorry state of the comments section, I fear we'd end up with the giant mess outcome should this ill-thought-out idea be approved.
 * 5) Per Walkazo
 * 6) Per Walkazo.
 * 7) Per all
 * 8) Per Jazama
 * 9) Per all. There should be a more specific description of what this proposal means. But it doesn't seem like a very good idea anyway.

Comments
@SuperPickle: Well, that's kinda the point. It's basically a way to navigate a certain character's stats from whatever game the user searching for without having to scroll through the stats section to look for stats from one specific game.--
 * Well, it would be pointless because some enemies only appeared in one game and the entire article's information would be moved to a bigger article, making the enemies article pointless, so we wouldn't move them, but not moving those enemies would leave us with an incomplete articl. So, it's your choice: follow your plan and lose lots of articles and create an incomplete one to replace them or forget your plan and keep the articles.
 * You know this proposal doesn't have anything to do with enemies, right? By stats and descriptions, I mean official bios, not usermade content from our wiki.--
 * Huh? Bios are the same thing! They show an enemies (or bosses) stats! Where do ya think the usermade stuff came from anyway? They check the bios! Where else would they get the info?
 * Uh, what? They get the info from playing the perspective game or just looking at the character overall. It's not like users learned that Mario has a mustache by reading a bio. They just take a quick look at him to notice the mustache on his face. Almost none of our articles have gotten their info from a bio. And bosses and enemies in main series Mario games don't even have stats. It's basically just copy/pasting official bios onto the page, not removing said bios from the article entirely.--
 * Yeah, they have stats! In the Mario & Luigi series and the Paper Mario series, enemies and bosses have stats like HP, BP/SP/FP, POW/ATTACK and DEF (defence) and t5hose are stats, so there! And they don't get all the info from playing the game. In the Mario & Luigi series, playing the game doesn't tell you the enemies max HP.
 * Uh, there aren't any official stats for the enemies in the M&L series, so players just look through the rom file via hacking and find their stats. "And bosses and enemies in main series Mario games don't even have stats." Besides, none of your arguments are relevant to the reason you oppose...
 * Well, it's too late to take it off... sorry. Next time, please make your proposal a little more clear.
 * You know you could always remove your vote, right?--

Oh yeah, another proposal by you bringing a total of 3. By the way, take for example a Goomba from Super Mario Bros. 3. It doesn't have any stats at all: no HP, no SP nor EXP. If I am correct you pretend to place stats on characters and enemies which don't appear in RPG games. And articles are not restricted to have info from bios.

Sitenotice archives
DELETED BY PROPOSER

I think we should archive our sitenotices just as we do with proposals, talkpages, polls, etc. because they'd be a good reference for anyone who missed out on any of our previous sitenotices. They'd also be a reference for users to be up-to-date with any of our sitenotices so they don't mistakenly do something against a previous sitenotice. With a sitenotice archive, users that have returned from a hiatus and/or inactivity won't need to be given a reminder for making edits based on outdated/obsolete rules.

Proposer: Deadline: February 28, 2012, 23:59 GMT

Support

 * 1) Per my reasons above.
 * 2) It would be helpful to those who didn't read or missed it. Per proposal.

Oppose

 * 1) I find this highly unnecessary since all of the Sitenotices we've used are all in the history of MediaWiki:Sitenotice. Also, the argument about policy notices is poorly reasoned given that users are supposed to stay updated on policies anyway, and not all policy changes necessarily go through the Sitenotice anyway.