MarioWiki:Proposals/Archive 28

Remove template maps from articles
Before anyone thinks that I'm proposing to remove all maps from the wiki, let me elaborate. On location articles for Paper Mario and the Mario & Luigi series (Toad Town, Hoohoo Mountain, Thwomp Volcano, Cavi Cape, etc.), there is a small map that allows someone to to go from one location to another location in the same game. That is what I'm proposing to remove. Why? One, the map is really small. It's impractical to look for a location since some of the locations are right next to eachother. Two, it's unnecessary. What's wrong with simply searching for the location, or going to the navigation template? Three, it's inconsistent. Paper Mario: The Thousand-Year Door and Super Mario RPG, and possibly others, have in-game maps too, yet they don't have a map for all of their location articles.

I'll offer three choices: Remove these maps from the ones that have it, add these maps to the ones that lack it, or leave everything as it is.

Proposer: Deadline: August 29, 2011, 23:59 GMT

Remove all maps

 * 1) Per proposal.
 * 2) Reverse is right! We don't need it! Per him!

Add maps

 * 1) Maps don't harm teh wiki in any way.
 * 2) The maps are easy to use. They are quicker and you don't have to find the location in a template or category.
 * 3) They're very useful, especially for the Bowser's body article. Besides, we can create template maps for other maps.
 * 4) I don't think entirely removing it will be the best; a template may be a better solution.
 * 5) Per all.
 * 6) Per all. Like what YoshiGo99 said, they are easy to use. Plus I think that they are helpful templates on pages.
 * 7) Per all.

Do nothing

 * 1) I think it's fine the way it is.

Comments
While regular navigation templates should be sufficient for navigating the articles, it might be worth keeping these templates on the game and/or world pages at the very least (like Bowser's body or Beanbean Kingdom), since it is much more efficient to show people which names apply to which spot, rather than having to explain it verbally. Granted, most of the time, the explanation's pretty straightforward and a tagged map isn't essential, but there's at least one map I definitely don't want to see eradicated entirely:. That layout's rather unorthodox and the directions can be quite bad - "large intestine" doesn't direct me to the Trash Pit's location at all, but while "the green circle on the left next to the red elbow circle" does tell me what I want to know, that sort of description doesn't exactly seem like the kind of writing style we want on the articles (imho). If there was an option to remove the template from everywhere but Bowser's body and Mario & Luigi: Bowser's Inside Story (like a "leave maps on hub pages only" option only, or something), I'd totally vote for it. -

Generic Subjects

 * ''Draft: User:Knife/Policy

This is the first Writing Guideline and is based on my previous proposal. I think Generic Subjects articles should be regulated a little better, which is why I want to propose a Writing Guideline for it. As it is now, it is a very short Writing Guideline but it has room to grow over the course of this proposal. Even if it doesn't, there isn't that much to say about it without going overboard on examples.

I just want to clarify that the statement under the "Exceptions" header stating "This does not apply to sports games.". The reason I wrote that was because nearly everything in the sports games can be construed as collecting (such a catching a basketball) or significant to gameplay (like a home run). This criteria still works well in almost every other genre.

Finally, if this proposal passes, we will start deleting all generic subject articles which are not protected under the proposed Writing Guideline. This will be a slow campaign because tracking down the generic subject articles and determining whether they fit the criteria is time consuming, especially considering how subjective the criteria is.

Proposer: Deadline: September 4, 2011, 23:59 GMT

Support

 * 1) – Per my own proposal.
 * 2) - Having a way to regulate these pages is a good idea, and the Guideline still leaves enough room to come at it on a case-by-case basis, meaning we shouldn't end up losing any good articles to technicalities.
 * 3) Per all.
 * 4) You can't argue with a man who has a draft.
 * 5) - Per all.
 * 6) Per all.
 * 7)  I think that this is a good idea, but I think that the restrictions should be somewhat less loose.  For example, items like Home Run and Poop could get past, because they are important to the gameplay of the game.
 * 8) Per Toad85
 * 9) Per everyone! I have an article on the Speedometer and it does appear in three Mario Kart games.
 * 10) Per all.
 * 11) Per all.

Comments
@Toad85: Home Run was already deleted, as per a proposal of which this new policy is an extension. And if that wasn't enough, the policy directly states that sports subjects, like home runs, are given less leeway, so no, it wouldn't "get past". Also, Poop is important to the gameplay of several Wario titles, and so it should stay (as we decided on a TPP a while back); this policy is written in a way that will let that happen, which is a good thing. -

Categorization

 * ''Draft: User:Walkazo/Essays

For years the admins have been talking about creating a proper system for our categories, rather than the unwritten rules and inconsistencies we have now. Well, we've finally come up with a solid idea and a comprehensive (some would say exhaustive) policy page that everyone can follow - should the community at large agree with the admins that this is the way to go, of course.

Basically, the idea is that the articles get the most specific categories possible, which would in turn be categorized under more general categories, leading back to the most basic and fundamental categories - which, altogether, is known as a "Category Tree" (the general category is the root, and the increasingly specific categories are the branches leading to the articles/leaves). For example, Count Bleck would be part of Category:Super Paper Mario Characters, which would be part of Category:Paper Mario Series Characters, which would be part of, which, finally, would be part of Category:Characters. This makes navigation easier on many levels: for one thing, the articles have less categories to sift through (i.e. Bleck's currently got all three of the existing categories I've listed here (SPM Char., PM Series Char., Characters)), but the more general categories can still be reached with a couple clicks of the mouse. But rather than having increasingly big lists to comb through when getting more and more general, you're presented with links to various smaller lists, which are easier to sort through. However, if you still want the big lists, there's always Characters, and other such "List Pages", so dividing up the categories with the tree system doesn't deprive anyone of resources - it just provides new, easier ways to read through the same info. Here's some examples of what some trees would look like.

And that's not all. While categories in a tree are all connected, different trees also connect to other trees, forming extensive "Category Webs". For example, cat:SPM Characters isn't just part of cat:PM Series Characters - it's also a subcategory of Category:Super Paper Mario (which is part of, which is part of Category:Mario Games, which is part of Category:Games). cat:SPM also contains things like Category:Super Paper Mario Enemies and even Category:Super Paper Mario Images, etc., which all link back to their own trees - and together, the SPM branches of all those trees (leading down from the roots to the SPM pages) forms an overall Super Paper Mario category web. Here's an example of what that web would look like (the second web is just part of the first, reorganized a bit for extra clarity.)

Of course, the branches don't just link to each other down at the most specific level (cat:PM Series Enemies/Characters/etc. are all part of cat:PM Series), and not every step needs a category for every subject of every game (some are just too minor for so much effort, among other reasons explained in the actual policy), and sometimes trees have entirely separate trees branching out of them (again, this is explained in the draft). But it's all very logic-based, and while the webs and trees might seem complicated at times, it's still an improvement over what we have now.

Proposer:, with input from , , , , and the other admins. Deadline: September 23, 2011, 23:59 GMT

Support

 * 1) - Per above, per the other advantages of this system outlined in my policy draft.
 * 2) This is a very well written guideline with a ton of work put into it. It will make categories more consistent and also make it much easier to tell whether a category belongs here or not. This is definitely something we need. Per proposal.
 * 3) I have no doubt that this method of category organization will prove to be extremely beneficial, especially when compared with how the categories are organized now. This is long overdue, and should be implemented as soon as possible.
 * 4) Yes, yes, and triple yes! Per all!
 * 5) This is a beautiful thing you have here. You can't deny that all the admins put in so much work to make this possible and they deserve to have this pass - it will be a great change for the wiki!
 * 6) Per all.
 * 7) It'll be much better method for organizing categories. Per all.
 * 8) – Per all.
 * 9) This strategy is one of the most effective strategies of organization I have seen in a long, long time. It is consistent, reliable, and well-organized. Full agreement on this.
 * 10) Per proposal.
 * 11) Giant explanation, but simple to follow, per all.
 * 12) - Per proposal.
 * 13) Per all, especially on the fact that the category system process needs to be better organized.
 * 14) Per all, anything that took all the admins to make must be important.
 * 15) - Per all who support it.
 * 16) Per all
 * 17) Per all.
 * 18) Per all.
 * 19) Per all.
 * 20) – This makes perfect sense. Per all.

Comments
@Walkazo: Ohey, I have an idea. Why don't you make a PipeProject after this wonderous piece of policy goes through? It would greatly reduce the time it takes to get all pages correctly organised. 05:58, 18 September 2011 (EDT)
 * To be honest, I really don't want to go to the trouble of setting up a PipeProject: I don't see any benefit of having an arbitrary list of people who want to enact a policy that's already clearly explained, and which everyone will have to obey and employ anyway. I'd rather just get the updating underway as soon as the Proposal passes, and anyone who wants to help can just drop in. If users are unsure about how to proceed with certain categories, they can always come and ask me, or any other admin, for guidance. Users can even ask questions about what is and isn't a good idea for the trees/webs on the policy's talk page: it will be good to have the situations as examples for future reference, as new games necessitate the creation of new webs and branches. If PipeProjects offered more organizational benefits, then yeah, I'd agree that making one would be a good idea, but right now, I feel that everything it has to offer can be done just as easily without all the official trappings. -
 * OK. I understand your thoughts perfectly. 07:58, 19 September 2011 (EDT)

Minigame or Mini-game
Right now we have both spellings on the wiki. The unhyphenated version is being used for the Minigame page and the infobox, while the hyphenated version is used in all the categories; both can be found on articles. Inconsistency is bad, so we should use one or the other, and I think minigame is the better choice - it's more straightforward, it's consistent with the spelling of Microgames and it's even in an official game title: WarioWare, Inc.: Minigame Mania. It's not the end of the world is it takes a while to slowly change the articles to use the unhyphenated version, but what would need to be speedily updated are the categories, to set a precedent. However, the entire categorization system is being revamped anyway if the above Writing Guideline passes, which is actually why I'm proposing this now: so I can kill two birds with one stone next week, and also provide a solid example of how the new Tree system should work by implementing it with the new "Minigame" categories right off the bat.

Proposer: Deadline: September 23, 2011, 23:59 GMT

Use "Minigames"

 * 1) - Per proposal. Consistency is good, and the simpler, the better.
 * 2) Per Walkazo.
 * 3) Per proposer
 * 4) Make it Minigames and that is a Finish on that one so... Beep-beep! (Per all! in Minigame Whistle Form)
 * 5) Per the consistency and official names confirming this.
 * 6) Per the everyone.
 * 7) Per all.
 * 8) Per all!
 * 9) Per Walkazo, the simpler, the better
 * 10) - This would stop the problems with seeing "minigame" and "mini-game" in the exact same articles.
 * 11) Per all.
 * 12) - Per all. The official Mario Party 8 website even spells it "minigames", among other sources.
 * 13) Per all.
 * 14) – This has annoyed me a bit in the past. Per all.
 * 15) Per all.

Use "Mini-games"

 * 1)  I think it looks better asthetically.

Do nothing (use both)

 * 1) I don't think its a big deal if we leave out the hyphen or not. So I think we should just leave it.
 * 2) I like the idea of using both.

Comments
Allow me to demonstrate. I have the Mini-Game Whistle in the wiki so, if the proposal passes, it will take away the hyphen. That is what I thought for when it passes. Do you agree? Reddragon19k 20:48, 16 September 2011 (EDT)
 * Yeah, the hyphen would be removed unless it's explicitly called a "Mini-Game Whistle" in-game, in which case, our hands are tied. Similarly, if in-game modes have hyphenated occurrences of "Mini-Game", we have to use that, since it's not just a term we're using, it's a proper name. That's the only real caveat about this proposal - we can only be consistent in our spelling, but not Nintendo's. So in this case (assuming it is an official name), we could make statements like "the Mini-Game Whistle is used in minigames", but we couldn't change the name itself. -

Create
This template would be similar to this, and has one main use; to anchor a section link to a specific part of a page, without adding it into the table of contents or affecting the table's appearance in any way. For example, linking to Badge, would go straight to the badge's table entry, without actually changing the appearance of the article as a result of the template. This would also be used on other pages with large lists of entries in tables, such as Pokémon, and any other articles that might benefit from it.

Proposer: Deadline: October 23, 2011, 23:59 GMT

Support

 * 1) As I stated above, this would allow us to link directly to an entry in a long table, including in redirects. This could be potentially very helpful, and takes very little effort to add to pages.
 * 2) - It would be very effective on pages that link to Badge or Clothing page, and direct it even further than what it is now. This would be very good indeed.
 * 3) I am surprised that we did not have this already! Per all
 * 4) I guess after I read the comments, well, per all...
 * 5) – I think this is a great idea. Per Bop1996.
 * 6) Per proposal.
 * 7) Per all. I can definitely think of a few pages where this could be incorporated to our advantage.
 * 8) - Per proposal.
 * 9) - This might work, if made correctly.
 * 10) - Per all.
 * 11) Perfect. I've always liked how Bulbapedia does that, now I know how and think we should do it too!
 * 12) - Per all. Being able to link directly to table entries will be a great asset to wiki navigation.
 * 13) Per all.
 * 14) Per all. It will be easier to navigate with this.
 * 15) Per all. This is a great idea.

Oppose

 * 1) -This is more of a disimprovement, rather than an improvement. It would probably cause tons of navigation errors,and cause a crash or two. Bop1996, could you leave Mariowiki alone?

Comments
The only problem I see in this is 2 things - a) even though you say it will be easy, how will we incorporate it? and b) what will qualify something to be from Page to Page, as that needs to be stated clearer on what can and cannot be anchored. Also, a more personal question, what you have something that is shown twice in the page (i.e. - Badge as there is one for the PM game and PM: TTYD game)?
 * All you do is go to the subject entry in the table, type in, and the template does the rest. From that point on, any time you link to Badge , it will go to that section, just like it would a normal section on any regular page. For the multiple name thing, I see no problem with using Spike Shield and Spike Shield 2.
 * That is what I thought. And for that first part, I was confused on how it would work as in how we would get anchor set up but I figured it from Bulbapedia. There is still the problem of what qualifies for anchoring.
 * In any instance where there will be a large amount of links to that page, and while we would normally link to a section there, there is no header there to link with. I've only investigated uses on MetroidWiki, where we use it so that pages like this can have their table entry linked with anchor in templates such as this one. However, in tables such as these, there aren't enough links referencing that specific entry, so we didn't put anchor there. See what I mean?
 * Oh, I understand. Partly I'm asking these questions so that we can clearly define how to use these before it take effect.
 * Yeah, it makes sense, I'd do the same thing probably.

@Mario & Luigi: Reread the proposal. What this does is makes a practically invisible section link we can use anywhere in an article. This is useful for long tables such as those on Badge, as all those Badge pages redirect to the closest header in the article, but not the badge's entry itself. You can't link to Badge properly currently, as it's in a table, but you can if you use this template.

For the tables you can use id variable to the row or the cell, there's no point for this template to be made, as adding "id=[txt]" is much shorter than the template. Example here.


 * @SWFlash: This isn't restricted to just tables, and multitasks fairly well (even though I don't have any immediate plans for it), so I think creating it would reveal some other uses.


 * @Wildgoose: Actually, it doesn't cause any troubles at all, unless you mess up when using it.

Bop1996, I know more than you think. One thing I know is that your "improvement" will cause technical glitches, navigation errors, and computer crashes. Can you just stop this silly proposal?
 * I doubt that, by your pompous-yet-only-slightly-impolite behaviour. Please try not to be like that if you want to be taken more seriously. Sorry, I'm probably waffling on now. x_X But Bop, this seems like a great idea. Navigation will become even qucker.
 * I'm sure that we can handle things if it starts causing unnexpected errors, but until then, we don't have any proof it will. We can't stop a possible advancement with "what if"s and "maybe"s.
 * Aside from the non-specificity of the "technical glitches" mentioned, I've used this template myself on Metroid Wiki, as well as seen it in action on Bulbapedia, so I'm fairly certain it doesn't cause any problems at all.
 * Due to the way this wiki is set up, it would cause errors. Bop1996, as I said a million times, STOP THIS SILLY PROPOSAL!
 * Would you be so kind as to specify exactly what, where, and how the errors are or will be?
 * For what I see from Bulbapedia and Bop's explanation of it is all is something we should have done before. If any errors were to pop up, then those test pages that some users have of anchors would be leading to error codes. Instead, it is doing what it should be. This is not a silly proposal, or stupid.
 * @Bop1996: It is because of the way Mariowiki stores its data. If a "virus" (Unknown, different data storage way implanted on a website) like your template is implanted into Mariowiki, it will disrupt data storage. That is why the errors would occur. @Baby Mario Bloops: This is more than a silly proposal, this could ruin Mariowiki.
 * @Wildgoose: Perhaps you should have a little less attitude and a little more understanding. The MarioWiki would not be ruined by something that has already proven to work. It's not a "virus", and it's not something evil. It is something very simple that will fix many things. Please give us reasons to why it is such a bad thing for us to use anchors, and with less attitude.
 * @Wildgoose: A template is not a virus, a template cannot cause things to break beyond repair, and if it did, the template could simply be deleted and the edits reverted. Please don't try to talk about things you clearly know nothing about, it makes you look dumb. To me, a CS Major, it makes you look really really dumb. --Color Printer 22:32, 22 October 2011 (EDT)
 * Stop arguing with a troll.
 * Looks like he's deliberately leading us on a wild goose chase.
 * @Baby Mario Bloops Bulbapedia and Metriod Wiki run differently than Mariowiki. They orriginated from different places and ideas. They have a data storage system that can use the template. Mariowiki's system, however, can't. The template is proven to work on other data systems, but it won't on Mariowiki's system.

All three wikis run on the same mediawiki engine. Unless there's some specific hosting or extension here that isn't present on Metroid Wiki or Bulbapedia that would mess up the wiki so badly as to cause it to cease to function, this will work exactly the same way. I'm pretty sure that if there's an issue with the wiki structure itself that would stop this from working, an admin, bureaucrat, or Steve himself would say something about this.
 * @Color Printer You don't seem to get it. Once the template is implanted, even if it is removed, it will still cause damage beyond repair. Also, don't call me dumb.
 * @SWFlash I didn't know trolls could type.
 * @Bop1996 Didn't you know administrators never look at proposals until the voting ends?
 * I certainly hope that isn't the case, given that six or seven of them have supported this proposal.

Wildgoose, I hope you realize that, yes, administrators do look at proposals, and that your "explanation" for how the template would damage the wiki is fantastically bogus in every way possible, shows a total ignorance of how data storage actually works and features nothing that could be possibly grounded in rational facts. I do not think you are a troll but I reccomend that you cease commenting on this proposal as you clearly have no idea of what you are talking about. --Glowsquid 14:35, 23 October 2011 (EDT)

Glowsquid, I would like to go over a few points. 1.Administrators do not look at proposals until voting ends. Look it up. 2. All the stuff I was commonting about is true. 3. Mariowiki's data storage system is different from Bulbapedia's, as Bulbapedia's is different from Metriod Wiki's. They originated in different places, at different times, and by different people. Thus, their data storage systems are different. 4. I am saving, err... trying to save Mariowiki from the template. That is why I am commenting here.
 * As Glowsquid is an admin, I'd say he's more qualified than you are to say whether admins read proposals.
 * @Wildgoose: Please save your critism for something reasonable. This wiki doesn't obey those type of rules that other Wiki's may use. If that was true, then so many proposals that were bad ideas would pass. Bulbapedia has a different format, yes, but the anchor has been tested and been proven effective and efficent. And there is no saving the MarioWiki. Right now, you are offending many users with the attitude that you came on with into these proposals. Perhaps you should look at it from both sides rather than yelling "it will ruin the wiki!" before commenting.
 * @Wildgoose: I hate to break it to you, but I just created the template on a user subpage, and tested it on another page, as seen here, here, and here. The wiki has not crashed in any way and functions normally.

Animation errors and cartoon episodes pages
The pages for the individual episodes of the three DIC cartoons and the CGI Donkey Kong Country series often lists the animation goofs (stuff like "Luigi has three eyes in one shot") and minor continuity errors, and due to the shoddy animation of all four shows, the listings can get quite big. However, the way they are organised isn't consistent, with most pages listing the errors in the Trivia section and an handful other putting them in their own separate sections. Either way, it needs to be more consistent.

Proposer: Deadline: October 29, 2011, 23:59 GMT

Have a "Animation and Continuity error" section and move the relevant info there

 * 1) - I find this preferable because the animation errors are numerous and recurring enough to be distinct from the one-off anecdotes that the trivia sections are for.
 * 2) - Per Glowsquid.
 * 3) - A section would be good, Per all.
 * 4) It makes the trivia section too big. I think these goofs deserve their own section.
 * 5) Overdone trivia looks really bad, so this would help with fixing a lot of this. Per all.
 * 6) - This would help clean up the Trivia sections a lot.
 * 7) - They really are cluttered.
 * 8) - Per all on this cases; consistency would definitely help in a situation like this.
 * 9) Per all
 * 10) Per all.
 * 11) It's much more consistent.
 * 12) - Per.
 * 13) Finally! A proposal that is not ridiculous or silly!!! Per all!
 * 14) Per Glowsquid.
 * 15) - Per LeftyGreenMario.
 * 16) Defiantly. A separate error page would cut way down on the articles (there are many errors, after all. In fact, I think DIC just didn't care). Per Neon Cephalopod.
 * 17) Per all
 * 18) Per all
 * 19) Per all
 * 20) - Per Glowsquid.
 * 21) Per all.

Comments
@Wildgoose: Your comment seems a tad offensive for how other users explain their proposals in this wiki. Please be more prudent next time.

Remove customizable infoboxes
Yeah, I've noticed a big problem in the past years and I want to stop in this way. Why stop? Because, in general, it's not appropiate. As an student of graphic design and experienced user, I've noticed that customizing some infoboxes like the, the or the , by changing their preset colors for others is annoying because, most of the time users like to add acid or strong colors like red , bright green , purple , blue , etc. The problem of these colors is that hinder the user to read the info contained in the infoboxes and those colors take away totally the template's function and aesthetics. I suggest to remove all those options from the infoboxes to change their colors and customize them in less-useful tools that make the article less formal and consistent visually.

Proposer: Deadline: October 29, 2011, 23:59 GMT.

Support

 * 1) - I agree, this feature doesn't serve any purpose (AFAIK) and in some cases, as shown, even goes as far as to hinder the articles. Definitely support.
 * 2) Per MG1.
 * 3) Per proposal.
 * 4) Per Coincollector. This will help the aesthetics of our infoboxes greatly.
 * 5) - Agreed, but there is one dilemma to keep in mind; see my comment below.
 * 6) Another non-silly proposal! Per proposal and support.
 * 7) - Sounds reasonable.
 * 8) Per all. I did this already on Punpun.
 * 9) I knew those color-changing-variable's exist, but not their reason. Per all.
 * 10) - Per Coincollector. Colour-coding makes sense (like the SSB infoboxes discussed in the comments), but slapping on random, gaudy colours just for fun makes the wiki look bad.
 * 11) Per all and the comments.
 * 12) Per Coincollector, we don't need anyone yelling "My Eyes!" :)

Comments
The template that's used for the Super Smash Bros. characters uses a color code that determines which installment the character first appears in; green for N64; blue for Melee; red for Brawl. The colors aren't too bright, so they shouldn't be a major issue to readers.

@Coincollector: You can add your own support.
 * @Wildgoose: Please try to avoid telling how sysops/administrators what to do, it's very disrespectful.
 * Not only sysop, bureaucrat too.


 * @ M&SG: That's a good point. However, as you can see, the infobox has restricted preset values to change the color scheme, counting with three options only, and preventing the inclusion of other hues. Therefore that template is safe from this proposal.
 * Thanks for clearing that up for me.

I would love to vote on this, but I read through the proposal and I don't really understand it all. I understand that we are using different info box styles for different things such as items and characters, but I don't understand what is wrong with them. Can someone explain that?


 * @ Tail2777: Basically, the problem is that those templates have an option where you can change their colors in infinite ways, but It seems that such property has been abused or badly used. Have you seen those multi-colored infoboxes in some articles that use them? Have you read the info with those bright, almost-blinding colors that usually users like to add just because they think they look nice? Have you managed to read the words on my proposals that are tagged with that kind of colors? If you have but it's hard to see, you've found the problem.
 * Basically, certain colors make it harder to read the text, unless the text is recolored as well.
 * Now I see and yes I agree, so I support.

Allowance of a legitimate alternate account to contribute
As there may be a few editors who edit sparingly from public places, and that some of these places may have password-stealing keyloggers or trojans installed, it would be wise to use one alternate account to prevent the main account, which may have Patroller or Administrator rights, from being harmed. The alternate account should not: Wikipedia and other sites allows such, and my alternate account there is B.wilson-alt. Is there appropriate consensus to agree with the decision?
 * 1) Hold any user rights
 * 2) Be used at all other than at public places
 * 3) Have a username much different than the main account

Proposer: Proposed Deadline: November 6, 2011 23:59 GMT Date Withdrawn: October 30, 2011, 02:51 GMT

Support

 * 1) Per proposal.

Oppose

 * 1) My "real" answer: NOOOOOOOOOOOOOOOOOOOOOOOOOOOOO!!!!!!!!!! Meaning: That is sockpuppeting.
 * 2) What...that' s all that I can say. Just a bad idea. Accounts here are rarely, if ever harmed or used in public places, and an alt account may suffer the same fate.
 * 3) - If you're concerned about security, just don't edit. What Wikipedia does is irrelevant: we're not Wikipedia, and a couple extra edits here and there is not worth bending over backwards to accommodate. One account per user, no exceptions.
 * 4) Per Walkazo.
 * 5) I'm sorry, B.wilson, but I'm going to have to oppose as well. As Walkazo pointed out, we may be a Wiki site, but we're trying NOT to imitate Wikipedia (although some procedures we do somewhat emulate what Wikipedia does). In short, no.

Comments
Mario & Luigi: That is NOT sockpuppeting. This proposal is use of a LEGITIMATE account for use at PUBLIC places where trojans are installed, maybe. If you don't UNDERSTAND my proposal then DON'T VOTE at all. Thank you. --

@B.wilson: It IS sockpuppeting.
 * But in a LEGITIMATE way. Still a lack of understanding the proposal, your rude failure to understand the point of using a legitimate secondary account. --
 * Yeah... I'll forget the password of my secondary account anyways, even if I wanted to create one. I NEVER use a computer in public places.
 * So I'm guessing your vote was basically because you don't use a computer in public places... ??? --
 * No... IT'S SOCKPUPPETING!!!!!!
 * I'm tired of having to respond to your lack of understanding, and even your lack of respect. Sockpuppeting and using an alternate account in a legitimate way are NOT synonymous. Using it in a legitimate way includes using it in public environments where it is not 安全 to use your main account, and using it abusively is to create another one specifically used for vandalism; I will not be responding to any further of your rants on this proposal. I think I have had enough. --

Please, Mario & Luigi, stop with the nonsense. The way you're writing your comments and replies imply you're attempting to be disrepectful with the other user. Consider to valorate other user's comments and find their advantages and disavantages in a more constructive way.

OK. I will change my vote.

Nintendo64Fan: in what way, is it a bad idea ... ??? Thanks. --

Aside from what I think of the proposal, I'm not certain if a community proposal was the right move. If anything like this were to happen, the admins would likely have to approve it first, so I don't think it's up to the community really.
 * Nintendo64Fan, When the alternate account is harmed, it is actually better than to get the main account, most importantly if it holds user rights, harmed, (disaster). --
 * Is there a way to prematurely shut down this proposal? --

@Walkazo:What about when one forgets a password (like Stooben Rooben)? Is he a sockpuppet?
 * No, he's not. If a user forgets their password, they can make a new account: it's a replacement, not a sockpuppet (and it's for a legitimate reason, unlike users trying to erase a record of misbehaviour by starting over with a new account). In these cases, the user still only has one usable account, so it's not an exception to the rule. B.wilson: you can delete your own proposals within the first three days of their creation if you no longer support the idea. However, please be advised that it has to be properly archived, using a grey "DELETED BY PROPOSER" outcome (like how this TPP used grey). -

Starting Planet Stop
In Super Mario Galaxy and Super Mario Galaxy 2, people call the first planet you go into the "Starting Planet". Not surprisingly, people at Mariowiki do the same. But this needs to stop because each planet is different from every other planet in its game. The first planet in a galaxy should be named the same way the others are named. For example, the "starting planet" in Good Egg Galaxy could be called the Dark\Light Planet.

Proposer: Deadline: October 30, 2011 23:59 GMT

Support

 * 1) Per Proposal.

Oppose

 * 1) This has been proposed twice and failed both times for various solid reasons, of which I will name two: Starting Planet describes the first planet perfectly, without ambiguity or room for misunderstanding, except in the cases of the Space Junk and Dreadnought Galaxies. Naming after numbers don't work afterwards as the sequence of planets changes between missions. Per every reason we had for not implementing this last time.
 * 2) As contrary as it is to my opinions concerning this subject, I must oppose. There is not enough here to differentiate the idea from the previous proposals to an extent that would make the subject worth more consideration than it has been given already.
 * 3) - It is better to do research and look at past proposals before creating a proposal, as this exact proposal has been dealt with multiple times. Unless people provide reasonable proof that we should call it otherwise, than this will just be like the other few, and end like them as well.
 * 4) Per all
 * 5) - Per my arguments against the "No Starting Planet Left Behind" proposal in archive 26.
 * 6) I'd rather have the Prima names (Planet A, Planet B, etc.) than this. Per all.
 * 7) – Despite the fact that I supported the "No Starting Planet Left Behind!" proposal in the twenty-sixth archive, this matter has been decided twice: both times in favor of keeping the status quo. I myself support the "third option" of merging the planets into the mission articles in the least redundant manner possible, but there is no need to go through all of this discussion again when this proposal will likely be defeated a third time.
 * 8) — Per all. Though if we were to rename the starting planets, or any other planet really, differently, we would use the in-game filename for them.
 * 9) - A lot of the planet names are conjectural, so it would be no good if we change the starting planet names, unless we have official sources.
 * 10) Really? Is this actually happening? Why would we do this when, as others have mentioned, there were two or three proposals about the Starting Planet conjecture. Two or three proposals that got shot down. Per all.
 * 11) I've done it once, I've done it twice and now I'll do it thrice. Per Bop.
 * 12) Starting Planet is clear, per all.
 * 13) - Per SMB.
 * 14) Serious deja vu here, we have voted against this in the past.
 * 15) I've already tried to float this boat twice, and both times, it sank like the Titanic...per all.
 * 16) I would just number or letter the planets, just because the level is broken up that doesn't mean we need to name every little section.

Comments
Bop1996, why do we always have opposite opinions?


 * @Wildgoose, It's like why your question is not stated clearly.

@RandomYoshi That looks like a good ide- Nevermind…


 * @Wildgoose: If you check the archives for the last two proposals on this topic, then you'll see that I opposed it those two times because of the proposal itself, and this is independent of proposer.

@SWFlash: Not really, I can see the names clearly with "Ctrl +". We would have a problem with figuring out which galaxy each planet filename belongs to, however. -
 * That's what he meant.

@SWFlash:If I wanted to, I could look through every single one of those. It wouldn't take that much time anyway(I'm serious). However, there is a hunch to this... My computer doesn't run Dolphin, which means that I really have no way of opening the files... Though if I could solve that problem, expect to see some changes... Though I have found a wiki about unused items/text/characters etc. which has an article about Super Mario Galaxy. With that we at least have a start. This page also, coincedentally, gets rid of one planet being named "starting planet".
 * Even though someone may have found the data that contains the level files, these are often named something not designed for the player to see and use as a name. For example, we could name a ref "shiofhsdoihisdhooewuor", and as long as it was done properly, it wouldn't affect the quality of our information (aside from annoying other editors, which is a separate issue). In light of that, I wouldn't support the idea of changing all the planet names to the names from the game data itself unless they all made perfect sense and there was one for every single planet in the two games.
 * OK. This means that it really can't be done: the maze-like planet in Gusty Garden Galaxy is called "LavaMazeCubePlanet", a name which doesn't make a whole lot of sense.

How about the "Planet A", "Planet B", "Planet C", etc. as those names are official?
 * Those names give absolutely no description of the planet itself, though.
 * But they are official. Mario &amp; Luigi
 * Official? Nintendo actually called them that? How lazy of them. Magikrazy51
 * Yes... By Prima Guides...
 * @Phoenix: It wasn't that bad; remember, your second proposal ended with both sides tied. As for this little discussion right here, official or not, if the names don't aid in reader comprehension of the planets, there's no point in using them.

Countdowns for upcoming games
Personally i think this would be a great feature,basically theres a countdown to the release of the game(depending on where it launches first)and when the first one is up re-do it to the countdown of the next launch date example: Mario Kart 7 launches in japan in [countdown] and after its released re-do it depending on wheres next. Main page or actual game article state whatever you think is better,and either support or oppose on whichever.

Proposer: Deadline: November 1, 2011, 23:59 GMT

Oppose

 * 1) - The proposal's a bit vague... Anyway, as mentioned in the Comments, this shouldn't go on the articles. However, at any given time, we have multiple games coming up, plus different localization release dates, and having to count down to them all would make a mess of the Main Page. On the other hand, choosing only one would seem like rather shoddy coverage of upcoming Mario events. Either way, it's not a good idea.
 * 2) - Per Walkazo. I wanted to get the right words to oppose to this. Thanks to Walkazo, her words are what I was looking for.
 * 3)  - Per Coincollector and Walkazo.
 * 4) - Per Walkazo's reasons.
 * 5) - I think we could easily have this added onto the main page, however if you insist on putting it into the articles, I will oppose.
 * 6) Per Walkazo.
 * 7) Per Marioguy1.
 * 8) Per all who oppose this. This would cause errors to the wiki if put on pages other than the Userspace and the Main Page.
 * 9) It's not rare for there to be several upcoming Mario games at once, so the main page could get a bit cluttered with it, and it would take even longer to load.
 * 10) Not necessary. Having the actual release date on the article is good enough.

Comments
I think this could be a good idea, but put moreover on the front page or somewhere like that than on the actual articles. If we have space for it on the front page, maybe. So where are you proposing we put it?
 * WiKirby had this for Kirby's Return to Dream Land. I don't know if it would work on Super Mario Wiki though...
 * And Bulbapedia with Black and White.
 * I agree with Marioguy1 that it should be put in the main page.

Well we could put it on the main page where the Proposals box was,but i think having it at the very top of the actual games article is better. Donaldthescotishtwin
 * It really depends on whether we could make it aesthetically pleasing on the main page or not in that case. I've seen some pretty awesome countdowns on main pages before, but those were done by expert coders. I would oppose having it on the game articles, as that would likely be distracting and jarring to the content of the articles.
 * I'm with Bop on this. If we can make it work on the main page, great, but if not, oh well.

I am rather skeptical with this idea. Additionally, this would have to be restricted to the main page only.
 * And as Walkazo stated, the main page would become way too messed up if we do count downs for every single upcoming game.

I'm not insisting on putting them on articles,put them on the main page if it would look better. Donaldthescotishtwin

Also if anyone's confused I mean countdowns for games coming for the present year, example:SM3DL and MK7 isn't far away so countdowns for their releases for whichever country first and so fourth. Donaldthescotishtwin

I actually think this is a great idea if it looks good and can be consistently maintained. Could end up creating more hype for the game and possibly raise traffic for the site. However since so many games are being released at the same time, we should probably only do a countdown for the most recent game coming out. We should also set a time minimum, like we cannot start a countdown unless there is less than two weeks for the game to come out. It also has to look good on the main page. If I were you, I'd rework this proposal into something a lot more specific and detailed, possibly including a sample main page to show us how it would look. This is assuming you are serious about the idea. If you don't get this one to work, you can always re-propose 28 days later.-- 13:11, 28 October 2011 (EDT)

This is being done by Nintendo Wiki when I posted this comment for E3 2012. I think it could be good. But It may not work because the dates for the game depend on where you live. So I'm at a loss

@Wildgoose: Actually, it just uses the server clock and a date, and that doesn't crash any wiki in any way AFAIK. Please don't start with the technical glitches again.

@Knife: That still leads to inconsistency. For example, if two games were coming out with only a couple days between them, only the first game gets the full two weeks countdown, while the other one gets only those couple days. And, what if the second game was something highly anticipated while the first game was part of a more minor subseries: people would probably take issue with the fact that we're neglecting the major game. However, ignoring some games in favour of counting down to others leads too all sorts of potential pitfalls. Like, would we count down to a new game being released in Japan, or count down to the first English-language release of an existing game? And what if we have a NA vs. PAL situation? It just seems like way too much of a hassle for such a minor feature. -

@Wildgoose: Why do you always say things will create errors? See here:  days until Super Mario 3D Land in Europe. The italic number you see here is calculated when you entered this page. No errors you see?

A template for references and for articles with too many plain refs
This proposal's purpose is to eliminate plain references, and to discourage others to stop creating them. Very recently, many articles are filled with plain references, as well as them being added from time to time.

The format is best:

but in order to prevent errors in the format (which can be made by many), I created a template, drafted at User:B.wilson/ref. Using the draft template here, placing

produces:

And for articles with too many of these naughty plain references, I also drafted User:B.wilson/Plainrefs.

I think this will make our references filled even more quickly. I doubt that anyone would oppose such a great idea.

Proposer: Proposed Deadline: November 11, 2011, 23:59 GMT Date Withdrawn: November 5, 2011, 01:24 GMT

Support

 * 1) Per proposal.

Oppose

 * 1) - Except for upcoming info, it's almost a miracle when we get people bothering to cite their sources at all, and you want to make it more complicated? There's nothing wrong with plain tags: raising awareness about using them and regulating what needs to go into them (page number and possibly quotes from instruction manuals; link, name, access date for websites; etc.) would be a much more fruitful endeavour than trying to redo it all from scratch (and even then, we can't be too exacting: most of the info is taken straight from the games and is added by kids - not the best circumstances for citations).
 * 2) Per Walkazo's reasoning, even though it seemingly contradicts the Citation Policy. Also, I'd like to say that while I greatly enjoy reading something rife with direct citations from the game on Zelda or Metroid Wiki, I believe our current policy works best for our situation.

Comments
Walkazo - You may say that plain tags have no problems, as I agree with that, but it just doesn't look professional. If there are filled, they will look better, because it will help others. I know I wasted a lot of time doing this yesterday because you are refusing the support the idea. Of course, the KIDS don't have to fill them in, if there are plain links added, then we can fill them in. It would make the wiki look a lot more professional. If you want the wiki to be the best database and reference source about our favorite plumber, why are you against making it more professional?

New Super Mario Bros. Wii Level Split
For levels in New Super Mario Bros. Wii, people keep them all in an article depending on their world.Why? This doesn't give the wiki a chance to give an overview of the levels, like how to get the Star Coins or how to reach the secret exit. The purpose of this proposal is to split all levels in New Super Mario Bros. Wii so each level has its own article.

Proposer: Deadline: November 5, 2011, 23:59 GMT

Support

 * 1) Per proposal. This would be an awesome improvement, and it would give Mariowiki more information.

Oppose

 * 1) We already voted a proposal down that was similar to this here. Per Mario4Ever and Walkazo in that archived proposal.
 * 2) - We don't need to create more articles; that doesn't give us more information, it just moves the information to harder-to-reach pages so that people searching for it will have to click through several more links to get to it.
 * 3) Per Marioguy1.
 * 4) - Per Marioguy1.
 * 5) Per Bop1996 and MG1.
 * 6) I don't know what to say other than "I agree with the users above". :/
 * 7) - I can't really explain this.  Therefore, per Marioguy1.
 * 8) - Per Bop1996. I still think merging levels into worlds across the wiki would be the best option: it'd streamline navigation, save space, and avoid both stubs and attempts to make pages much longer than they need to be (using wordy, walkthrough-like level summaries).
 * 9) Info on "star coin get" should be dealt with our couleagues at the Strategy Wiki (assuming they have an article on such a game). Per all.
 * 10) – I am against the idea of gaming the article count of this site.
 * 11) Per all
 * 12) - IIRC, we had a proposal about this way back when I was active and editing the Wario Land 1 worlds. Whatevs, world articles are way better. They supply way more information for way less clicking. Besides, one can still write in-depth descriptions of the levels (without them becoming walkthroughs) in one article.

Comments
Bop1996, you are trying to prevent my proposals from working! Also, my proposal is nothing like the one you showed me. The articles will be named like "Word 1-1 (New Super Mario Bros. Wii)".
 * That's illogical. If you want me to support your proposals, you might try proposing something I didn't vote against the last times we voted on it. And actually, the proposal in the archives wanted an article on each level in all the 2D games, but the reasoning applies to the NSMBW levels as well, minus the long list of redirects and disambiguation pages that would have been created in the previous proposal.
 * Wildgoose: Please don't confuse users like me by removing all the oppose votes. Just because people have different views from you doesn't mean that they're wrong or silly.

Come on, can't I have just one support comment? No one ever agrees with me.
 * There's no need to complain. The proposal's got some time left, so who knows, you might get some before the deadline.

What's wrong with disambiguation pages anyway? They have always been a part of the wiki, they always will be. This will add more information, the articles would be similar to articles about Donkey Kong Contry levels.
 * Just like MG1 said, making separate pages for each level won't make them any more detailed; it's just how much is put into each section.
 * @Wildgoose: I understand why you want to have another support with you, but you really need to do some research before doing proposals. Your SMG proposal has already been tried multiple times, and this one is similar to when a user wanted to split all Super Mario Bros. levels into separate pages. Bop is not causing you to lose this proposal, nor is it preventing people from supporting it. If you want a proposal to pass, you got to have strong evidence as well as strong reasoning for why it is being done. You also have to look at both sides, especially the side-effects. For example, if this was to pass, then many other things would have to be split to keep consistency on the wiki.

Blacklisting inappropriate titles
Over the past few weeks, I've noticed disproportionately inappropriate usernames being created. Such as "Stop blocking my socks", and other usernames, such as a username insulting another user on the site.

Suppose that someone creates an account called "GGGGGRRRRRRRRRRRRRR B.wilson's A RETARD!!!!" How is the thing prevented from happening the next time?

If we insert the following Regex:

If they create an account again that contains B.wilson (even with alterations, such as B.Wilson or Bwilson) the text in errmsg will be displayed: This username has been identified as harmful, and has bene blacklisted from creation. Please choose a different username.

This can also prevent inappropriate page moves, edits, and page creations. Do you think it's a great idea? This Regex should be stored on MediaWiki:Titleblacklist. I made this proposal due to the fact that the page is empty.

Proposer: Deadline: November 8, 2011, 23:59 GMT

Support

 * 1) What would not make it a good idea?

Oppose

 * 1) - These accounts are all caught and blocked very quickly and if the name's really bad, we can suppress them from view. And even before this new suppression feature, we easily dealt with inappropriate names by renaming the accounts. But most of the time, they're just stupid names and they're just not worth any trouble or concern at all. Our system works perfectly fine: we don't need some fancy new blacklist feature. Don't fix what isn't broken.
 * 2) - Per Walkazo.
 * 3) - Per MeritC and Walkazo.
 * 4) AFAIK, this wouldn't really affect most of the users except admins, so if the admins would prefer to keep things the way they are, I don't see any reason to change it. Per Walkazo.
 * 5) Per Walkazo, though if we didn't have as awesome admins as we do here, I would probably support it.
 * 6) Per Walkazo.
 * 7) Per Walkazo.
 * 8) Per all
 * 9) Per Walky.
 * 10) Per Walkazo. Also it just seem to me (maybe just right now) that anybody will have ownership of their username and cannot be used by another person, even a part of it.
 * 11) Per Walkazo and Marioguy1's comment.

Comments
Oh, okay, it seems that the admins here at are too passionate... ;) --
 * No, given opposals on ALL OF MY proposals, and that only the proposals made by admins pass...I so did not mean that. --
 * I meant, the only problem with a part of the community here is that they simply lack any good taste. I am not attacking anyone for the most part, nor am I saying this place is a bad place - this place has great administrators and a great community. But the only problems are that only proposals made by admins or a group of them pass (any newcomer can see the archive), or made by extremely trusted contributors who have been on the site for some time. I only have been here for a month, but that doesn't increase any chance that this proposal should fail. So the point of the proposal is to blacklist inappropriate usernames, so they cannot be created. So time to hide mentioning of them from edit summaries (which can take a lot of time if lots of edits), blocking them, and cleaning up after them can be replaced by contributions that will benefit from this wiki. I am actually trying to help you guys help benefit the wiki by more mainspace contributions, but it seems like... -- 03:56, 6 November 2011 (EST)
 * In the nearly a year I've spent here, plenty of regular users have made successful proposals, even if they aren't highly experienced or knowledgeable. The reason it looks like your proposals are just an admin bandwagon is because your proposals affect admins the most, and the vast majority of our community defers to what the admins prefer to do in these cases, as it'd be highly counterproductive to take an action changing how the admins do things if the admins would prefer not to change it.
 * That may be correct, but this doesn't affect administrators much. All this is is discouragement of adding plain references, using a simple template for filling them in easier, and tags on pages for experienced users to drop by and fill em in. -- 09:01, 6 November 2011 (EST)
 * In the case you mentioned, Walkazo pointed out that simply raising awareness about a better way to reference would work better, and to be honest, if you spend enough time here with a big release coming up, it's pretty hard not to notice that people sometimes have a hard time referencing just with a link. As for your other two proposals, those would have mostly just affected the admins, so it's no wonder that if the admins voted it down, the rest of the community followed.

The point of the matter is, B.wilson, this proposal will be work for us - every time the trolls find a new user to troll, we will have to add another title to the blacklist. Even then, a troll will either find a way around it or move on to another user. It is a waste of time hankering ourselves to find a way to stop the trolls when the damage they do is extremely minimal as is.

As for your comments that only proposals by administrators pass, I think you are misreading the data. For example, if you looked at data for any country in the world of human activity, you'd find that when the sun goes down, people go inside. When the sun comes back up, people come back outside. So a proper analysis of that would be that the sun causes people to come inside and go back out. And that analysis would be wrong. If you look at the archives for the proposals, you'd find that when a respected user makes a proposal, it passes. When a newer user makes a proposal, it fails. There are several exceptions in each scenario. Your analysis is that only respected users' proposals pass, but that analysis is also wrong. Going on with the sun-example, people find it convenient to go inside when the lights and warmth are gone and then find it convenient to come back outside when they are back. The sun in no way forces them to do this. Similarly, proposals made by respected users are usually well-thought-out and well-proposed - with proper research done beforehand. Proposals done by newer users are usually not well-thought-out and they are formatted badly so that they don't draw people's attention. The fact that the user is "new" or "old" has nothing to do with whether they make good proposals or not.

A final point I'd like to make would be that there is a reason administrators are allowed to vote on proposals - because they usually know what they are doing. If an administrator opposes a proposal, they will usually have a good reason to do it. In saying that your proposal is failing because everyone is following an administrator, you are disregarding the opinion of that administrator; and if everyone is following that administrator, their opinion is probably an intelligent one. The point is, the admins usually know what they're doing, they're not perfect, but we trust them enough to make proper decisions for the betterment of the wiki.
 * You may be right, I was not attacking Walkazo's opinion. But the only thing I find kind of - not what I expected - is that the entries following Walkazo's oppose just basically said nothing but "Per Walkazo" or "per all", which may be... --
 * Ah, so you don't really like the "per" votes. Well, I could have typed out everything Walkazo said as my vote, or just "per'd" her. Either way, I'm basically voting for oppose based off her vote, the only difference is that in the case of the latter, none of the content is lost, but it takes a lot less time to just basically say "I agree with Walkazo" or something like that.
 * I feel it is more polite to give out my real reasons for votes for consensus, even if it's just a rephrase or paraphrase of another's vote - and then give my original reasons. Best,
 * Aside from it being redundant to rephrase or paraphrase another user's vote, more often than not, as a proposal approaches deadline, there are going to be fewer and fewer original reasons, simply because initial votes in either direction require a reason, and the users that follow won't come up with a new reason if they agree with one already present.

Create articles for media with several references
There are some TV shows/Internet stuff/Movies/Anything else with many references. Some with enough to qualify for their own page. This makes the references pages very long. I feel that doing this would cut back on the references pages. I see many other wikis do it. Some prime contenders would be Futurama and Homestar Runner among others.

Proposer: Deadline: November 13, 2011 23:59 GMT

Support

 * 1) Per the words above me.

Oppose

 * 1) I don't really see the point for new pages full of references, and besides, it doesn't belong to the Mario franchise and is not licenced by Nintendo.
 * 2) — Per Lakituthequick.
 * 3) – Weak Oppose. I don't really understand the full meaning of the proposal, but if I'm not mistaken, here's my opinion of what I think about the proposal. Some of the references may not be reliable sources (blogs aren't reliable, while news sources are). Furthermore, if Lakituthequick says it doesn't belong to the Mario series (I will trust their opinion) why do you want to game the article count with articles non-Mario?
 * 4) If it's not official, it shouldn't belong here.  I strongly oppose this.
 * 5) per all
 * 6) - Our wiki is about official Mario appearances; the References are just examples of the cultural impact of the series, and aren't a major focus at all. While some shows/websites/whatever do have a lot of Mario references, creating separate pages for them still seems like an unnecessary step. Futurama doesn't actually seem that bad anyway, and Homestar Runner can easily be streamlined by discussing multiple minor appearances in broad paragraphs, rather than having one-liner sections for every single individual toons.
 * 7) Per all

Comments
Sorry, but I cannot understand your proposal.


 * I think that he means that the Video game references page has some entries that are big enough to be considered to be put into a list - he wants the big entries to have pages created for them. That's what I am getting from his proposal, that is. I might be mistaking.
 * Hmmm....if that's the case, I am neutral. Wish there would be a "neutral section" :P --

So let me get this straight. You want there to be a page like "List of Mario references in *insert other media here*" for certain media with large amounts of Mario references. My main beef with this is the fact that your qualifications for splitting them into a new page are very vague, so I'd rather see a kb limit or something before supporting.

Other wikis I go to have separate pages for a certain TV show or anything else with enough references to qualify for a page. I think the same could be done here. Homestar Runner, for example, has more than enough references. Futurama, possibly. The Mad TV series seems to be getting there as it's only in its second season with many references (although it would be a bit of a stretch right now). I'm defiantly not saying to make pages for everything that referenced Mario, just the specific shows/bands/video game series/etc that have referenced Mario multiple times.
 * Still I'm neutral. Doesn't allow me to vote :P --
 * So you'd want an article named Homestar Runner devoted to the Mario references in that show? If that's the case, you still haven't said what makes the number of references in a media qualified to be split.
 * Per what Bop thinks about what the proposal is about, I weakly Oppose.
 * The article would probably be called "Online references/Homestar Runner".

English vs. Japanese names
I think this needs to be settled once and for all.

Countless pages has been under controversy dealing with their names. Just go to Lava Bubble, Shooting Star Summit, Pale Piranha/Piranha Plant (TTYD), Yo'ster Isle, and many others. When released in English (American and Europe), they use those names stated above. However, from Japanese names, they share the name as Podoboo, Star Hill, Piranha Plant/Pale Piranha (respectively), Yoshi's Island, and other similar things/places. There has been many arguments dealing with it, and it gets more and more annoying to watch.

So, what I'm proposing is just have it set in stone, so that we don't have to be doing multiple TTP's that are really becoming really controversial. We either use English or Japanese in these cases.

Currently, we have been moreover to Japanese since that is where the games usually come out at first. It does make since as that is where Nintendo is. Also, sometimes Nintendo of America/Europe make translation errors when it comes to those situations. However, it might not be the best system. With English names, it makes more since, since this entire site is ENGLISH! Not only that, but we do find English names to make more since at times. Manyt places/enemies do not appear as they do as they are being merged with.

Right now, our consistency about this is pretty split even. We have many articles being merged, yet, we have pages that have the same name in different games, but are split. How we are apporaching Japanese style, then we might as well merge Special Attack (Mario & Luigi: Bowser's Inside Story) and Special Attack (Mario & Sonic at the Olympic Games). They are completely different in multiple ways, but the same name, much like many of the articles merged listed in the beginning.

My point is, agruing about it in TTP's is not going to help. We simply need to just decide what we are going to choose to decide names about articles that have different English names but same Japanese names. And yes, there are some exceptions to this, but not many.

Proposer: Deadline: Novemeber 17, 2011 23:59 GMT

Use English names

 * 1) Becasue of using the Japanese names, all previously said places or enemies are merged with other places or enemies that are similar, but might be slightly different. (But in some cases, they are the same.) A good and obvious example is Pale Piranha and Piranha Plant. They are different, but are still merged. So I say go by the English names.
 * 2) Well if the Wiki is in English, it's best to have English. Per All.

Leave it as is

 * 1) Per Walkazo's entire line of reasoning in the TPPs alluded to here, including here, here, and many others I forget the exact placement of.
 * 2) per bop
 * 3) - I can't really explain this, so I'm just going with what Bop1996 said.
 * 4) – Per Bob1996/Walkazo
 * 5) - Like Bop1996, I'm gonna per all my old TPP comments/votes. The Boomerang Bro. TPP (the first link in Bop's vote) probably has the most exhaustive arguments, and this has a more succinct statement. Really, it boils down to one simple idea: use whatever official name makes sense based on the context. If two things look, act or are otherwise arguably different things, and at least one region gives them different names to reflect those differences, we can also assert that they are different things by giving them different pages. Conversely, if two things look the same and one of the regions says they are the same thing, we can also say they're the same thing by putting them on the same page. It's not inconsistent if we're using the same reasoning for all the splits and merges, and doing this on a case-by-case basis is certainly better than insisting that one language is always right when that's obviously not the case.
 * 6) Per Walkazo and her referenced line of reasoning.
 * 7) Normally I am the kind of person that says that the original language supersedes all others, but Walkazo's reasoning convinced me otherwise. So, per Walkazo.
 * 8) — Per all.

Comments
@Tails777: While we're splitting the Pale Piranha (or trying to anyway) on the basis of its English name, the logic is coming mostly from behavior; it behaves like it's a different species, and while the Japanese names may be the same, our equally valid English source has confirmed them to be different species, so that's where the split is coming from.
 * Well, behaviour and appearance. Pale Piranhas are pale, unlike normal Piranha Plants, so NOA is right in giving them a unique English name. However, the other TYD species, "Killer Piranhas" are explicitly said to be stronger than "normal" Piranha Plants, even in the English version, and so NOA was wrong to simply call them "Piranha Plants", but since they have unique names in Japan and at least a couple European translations, we're not stuck abiding by this lapse in judgement and are able to split them. The language doesn't matter: it's all coming from Nintendo so it's all official, and so, fair-game for us to use. -

Bringing the "Spoiler" template back
I think we used to have a Spoiler template,I don't see why it was removed/deleted but me thinks we need it again,especially with all the upcoming games,those articles are ALL spoilers, a reader will take an interest but they may not want to know Everything,plus with all the info we look for and add to the articles sometimes i can't see us without one,and if this passes I can wip one up pretty quick if someone gives an appropriate image.

Proposer: Proposed Deadline: November 30, 2011, 23:59 GMT. Date Withdrawn: November 23, 2011, 22:32 GMT

Oppose

 * 1) We voted this down here with a pretty significant margin. Here are some of the reasons why this happened: we had virtually no consistency, which was highly problematic. We also mostly agreed that almost everything is a spoiler, so making off specific portions as "Spoilers" isn't usually necessary. We agreed that mentioning it on About was good enough to warn people that spoilers are unmarked here. All in all, I see no reason to bring it back, since this does nothing to refute the previous arguments.
 * 2) Per Bop.
 * 3) Per Bop

Create articles for Mario Kart Battle Modes and Mario Party Minigame modes
All of these are currently merged with Mario Kart (series) and In the Mario Party full game articles and I think they deseve their own articles. All the Battle Courses have a page and the Mario Party Boards have one. This should also shorten loading times on pages when doing this and putting them into a full Article. There are no redirects to these pages as well.

Proposer: Deadline: November 27, 2011, 23:59 GMT

Support

 * 1) Per my Proposal.
 * 2) They seem big enough to deserve their own article
 * 3) It couldn't hurt.

Oppose

 * 1) Actually, I think the modes are fine the way they are. I don't see why Minigame Modes need their own article when they are fine with their respective Mario Party article, while Battle Mode still fits fine in the Mario Kart series. Also, why disregard other modes such as Time Trials? I'm also opposing this because of lack of consistency.
 * 2) - If I could oppose twice I would. Per BLOF, and to corroborate her arguments, we had former discussions to merge various sorts of modes to their respective articles (ie: Donkey Kong Country's Time Attack article) because splitting the modes from them would reduce considerably the importance of the games'articles and their content.
 * 3) Per BLOF and Coincollector.
 * 4) Per all.
 * 5) Per all
 * 6) Per all
 * 7) Per everybody
 * 8) Per all.
 * 9) - Weak Oppose per Coincollector, nothing's wrong with doing so, but it's best to leave it the way it is currently.
 * 10) — per BLOF.

Comments
@Toad85 Thanks for suporting but you need to have a valid reason for voting.
 * The question is, Mr. 85, could it help?

Music files
I have noticed that certain pages have music files on them, such as Paper Mario:TTYD and Mario Kart Wii. But I ask this: Why do we have those music files on the game's article? Wouldn't it be better to put the music on the article it is from. An example for those who don't understand: Instead of putting the music for Luigi Circuit from Mario Kart Wii on Mario Kart Wii's article, why not put all the Luigi Circuit themes on the Luigi Circuit article? The same for bosses from the RPGs, Mario Party boards. If you don't completely understand, see here

Proposer: Proposed Deadline: December 9, 2011, 23:59 GMT Date Withdrawn: December 4, 2011, 03:46 GMT

Support

 * 1) Per my proposal
 * 2) Putting the music from Luigi Circuit in the article about Luigi Circuit makes more sense than putting it in the article about Mario Kart Wii, definitely.
 * 3) Makes sense to me. Per Mpeng and Tails777.
 * 4) Per Tails777.
 * 5) Per proposal.
 * 6) Per all
 * 7) Per proposal

Comments
This does sound like it would work a little, but wouldn't it also make it harder to search for a collection of music from a certain game? For example, if you want to find music from Mario Kart Wii, you would probably look for it on the Mario Kart Wii article. However, if this proposal were to pass, you wouldn't find a lot of music because most of it would be scattered throughout other articles. Basically, it could potentially make it harder to find the music you want.

I think a good idea would be to have all of the music in the game's article, and then have links in other articles that would lead you to the section in the game's article with the music file in it. So, let's say you want to listen to music from Luigi's Circuit in Mario Kart Wii, and you went on the Luigi's Circuit article to find it. Instead of having all the music files in that article, there would instead be a link to here, where you can find other MKW music too. I'll try to explain more if it doesn't make sense.

@Fawfulfury65 The reason we shouldn't put the music on the game's article is that some articles will have too much music. For example the Paper Mario series. That would be one for each boss and location and character theme when it's easier to put the music on the character's or location's page. If we put all the music on one page, that would make it looked cramped. I understand for the Mario Kart series and your idea there might be better than mine, but I am focusing more on the games with more music than the Mario Kart series such as the Paper Mario series and both Super Mario Galaxies.
 * If the media sections get excessively long, couldn't we just use a scrollbox?
 * Either that or on a separate subpage, like Galleries sometimes are.
 * It hasn't been three days since I created this proposal. Can I change it up a little? Cause Bop1996's idea of creating a sub page for music is way better than my idea.
 * Now you'd have to request a deletion by an admin, then recreate it with the changes you need.
 * Do I have to wait to restart the proposal or can I recreate it right away?
 * After it gets deleted, you can recreate it right away if you wish.
 * Alright, I'm now requesting that this proposal gets deleted please.

MarioWiki:Upcoming content
This writing guideline is meant to establish a consistent guideline for how we handle content from unreleased games. The only aspect of upcoming content that is not covered in this guideline are the project articles themselves. This is because I believe they need a separate guideline page due to their complex nature. Most of what's covered in the guideline is already more or less adhered to, except for one thing. If this proposal passes, all information about upcoming projects will need to have a suitable reference. The main reason for this is because information from upcoming projects are at high risk of being false and references improve our credibility. It really shouldn't be too difficult to enforce on a mass scale, today's games have ton of secondary source coverage and it is easy to find something that backs up the information. The process is detailed a little more in the draft page. Comments and suggestions for improvement are always welcome.

Proposer: Deadline: December 8, 2011, 23:59 GMT Draft: User:Knife/Policy

Support

 * 1) – Per proposal.
 * 2) - Per all. And what per all I mean is Knife.
 * 3) Per proposal.
 * 4) I could actually keep track of new info which I always would want to Per all.
 * 5) Per all
 * 6) Per proposal.
 * 7) — Per Knife. We really need this thing.
 * 8) - Per Knife.
 * 9) - Per proposal.
 * 10) Per all.
 * 11) Per all.
 * 12) I don't know what to say other than Per All, and that's a bad thing. However, this proposal is a good thing.
 * 13) Per Knife! Great idea!
 * 14) Per proposal.
 * ok
 * 1) I thought this was already in effect - a definite Yes.
 * 2) Per proposal

Comments
It's just my opinion, but I think it's not by their complex nature but rather by their unique nature. Regarding to the new subjects (articles that talk about new element of the game like enemies, courses, etc. especially those that are introduced in a game) Is it possible to use the infoboxes and make mention of their appearance? I see a problem with this. Usually we don't include the appearance of something of a an upcoming game in the infobox until it is officially released. However, some articles (for example, the racecourses of Mario Kart 7) include their appearance despite the fact that the game has not been released yet which may be incosistent to the guidelines.
 * That's why those articles have the template on them. The information within the articles, as I understand it, is coming from one or more of the official websites, but that doesn't mean the articles aren't subject to revision once the game comes out.

Yes, but that doesn't explain the necessity to include an infobox with such information in a upcoming subject, that's what bothers me. Include information to the infoboxes respecting the sources or get the rules of not include information to them until the game is released?
 * Correct me if I'm wrong, but I think the issue only arises when people try to add appearances in an unreleased game on preexisting subjects (like if someone tried to say that the latest appearance of Maple Treeway is in MK7). There's nothing that says we can't include appearances in infoboxes for subjects (e.g. Melody Motorway) that have yet to appear in the series provided it comes from a reputable source.

If that were the case, I think it should be needed to make notice of that, because some people may get that the appearance of a new subject should be applied likewise for another previously released and will make an upcoming appearance as well.
 * Maybe the new subject's infoboxes could have "(upcoming)" next to the game's name to set them apart from normal released appearances. I also think it'd be a good idea to have a small section on Infoboxes in the policy page to make the varying use of the "latest appearance" clear. Additionally, I think more emphasis on using references could be made in the "New articles pertaining to upcoming project" and "Previously existing articles in upcoming projects" - nothing major, however, just a short note in each section (leaving the discussion to the section). Like, in the former section one sentence could be expanded to "If an article does have sufficient information backed up by reliable references,", and the latter section could have "as long as the information is not speculation and is accompanied by solid references". Also, "Once information has been rewritten" seems redundant: if the info was well-written from the start, maybe it doesn't need rewriting, just supplementation, and something like "Once the project has been released for a reasonable amount of time and more content has been added" seems like it's giving more bang for the buck (since it's also pointing out that the template can't be removed immediately). -

@ Walkazo: That sounds fine to me.

@Stuff regarding infobox usage: I'm not going to include that into this Writing Guideline since that is a rule that deals with the template specifically. Such rules of usage should be mentioned on the template page itself. The only reason why I mention how to use the Newsubject templates is because those template are specifically for this purpose. @Walkazo's suggestion to the wording: I'll amend all the changes you suggested except for the "Once the project has been released for a reasonable amount of time and more content has been added" suggestion. I don't think either case is necessary to do a rewrite. Sometime the amount of content is fine as it is and asking for more can sometimes prove to be difficult. Using the words "reasonable time" is unnecessarily restrictive. If the article has all the information it needs, then why wait longer to remove the template? Plus what defines a "reasonable" amount of time? I should clarify though; rewrite in cases like this only refers to changing future tense in present tense (will appear>appears in) and removing unneeded references. I will expand on this more when I make the amendments.-- 11:16, 29 November 2011 (EST)

Okay, made some changes. Supporters, please review them. I basically just differentiated vaporware and cancelled games (based on Glowsquid's proposal) and added a section for revision help.-- 23:56, 29 November 2011 (EST)


 * The changes are good, but I disagree with your decision to not include anything about the infoboxes. While the infoboxes do have their own sets of rules on the pages, this particular aspect of their use is directly related to upcoming/new releases. Dealing with infoboxes (or leaving them alone) is part of writing about upcoming games, and since different things are being done regarding the infoboxes, an outline for those specific procedures would be handy on a Writing Guideline. Why hope that users will happen to visit infobox pages and find out what to do when you could easily present them the info in a couple lines of text, laid out nice and simple? There's no rule against only describing writing policies in one page and no where else - on the contrary, many policy pages have overlapping content, and that's a good thing. It's not like it'll be a huge essay about general infobox usage, so what's the harm? -
 * A specific suggestion regarding infoboxes: we would probably benefit from a note somewhere about changing the images on infoboxes after the games release, as I don't believe that's official policy, and it could use some clarification.
 * Again I agree with Walkazo. Abstain from this suggestion means you're leaving this in half-way, Knife. This is also part of the upcoming project, And I'm not talking the infobox itself, it's the information of the infobox that likewise is part of the context. At Bop1996, what do you mean exactly? In my experience, I see that some pictures are changed often when a new game is released. But not always... For example, Princess Daisy's picture has been never changed to this point, similar to Waluigi's. Additionally, I dunno really, but it seems there is a rule about not adding pictures of characters alongside other objects that may distract the prime subject... for example: the picture of Metal Mario of Mario Kart 7 which is new but it cannot be used by these circumstances.
 * Recently, when we've had new high-quality artworks of characters like, Peach, Mario, Toad, etc, people seem to just replace the artwork when they feel like it. MeritC, I believe, has been reverting these changes until the games release, and I started doing the same for the same reasons. However, this isn't in any policy currently, but since we're discussing infoboxes and upcoming content, I figured it would be a good idea to mention that we aren't supposed to change the infobox images until the game they come from has released. We don't have to change it when the game releases if the artwork isn't better, but if we agree to change it, it should wait until after the game releases, basically.
 * Hmmm... MeritC told me the same thing and apparently that discussion came from the forums (Again I'm not sure). Going to your point, I guess it needs to be applied but looking how we are currently with the images, I think we should clarify that a bit more. But, again it can be done - At least if Knife approves this or else we have to do this by ourselves.

Sorry for the late response. If you all really feel it's necessary to mention it here, that's fine. However, I'm not 100% sure what you want me to put in. It would probably be best for someone who is more familiar with the userbox usage to write that section of the guideline. You can either add a section for it on draft or post raw coding into this comments section (for non-sysops). If no one comes up with a draft by then, we can put in later assuming no one opposes adding this information.-- 20:24, 4 December 2011 (EST)

Music Files
I read one of Bop1996's comments in the previous proposal of mine and he had a better idea, to make a sub page for music files. (So credit to him for the idea). So I decided to delete the other proposal and restart it and going with his idea instead.

Proposer: Deadline:December 10, 2011 23:59 GST

Support

 * 1) Per proposal.
 * 2) If you say the music would be located at a subpage named Music, like for the article Mario, Mario/Music, I'd say it's an adequate idea.
 * 3) It would cut down on clutter in the music sections, just like having huge Galleries on separate pages does.
 * 4) Pages would load faster. A yes from this impatient user.
 * 5) Per all
 * 6) Good idea, we can ask Porplemontage to create a namespace for music (like we have a gallery namespace)
 * 7) — Per all.
 * 8) Per all.

Oppose

 * 1) I think just having a list of music is a bad idea. People can look it up on YouTube and people need a player to listen to these and it would be easier to find the song they are looking for on YouTube anyway and it would take a lot of work to upload every Mario song in the series.
 * 2) Per NSY.

Comments
For the record, the previous proposal about Music Files can be found here. -

@ Tails777: Can you specify the title of your proposal? It's about the Sound files, but what's exactly the matter about them?

@Coincollector Nothing is wrong about them, I just find it would be better to put the music on a sub page rather than the game's page. Like what others have said, like gallery pages.

I would only support this if we use YouTube Videos not Music Files because more people like me can listen to the music.-- 11:37, 7 December 2011 (EST)


 * @ New Super Yoshi: The wiki doesn't use Youtube videos for the articles. See Help for the reason.

I don't see a good reason. Anyway music and video flies are taken from YouTube so what is the point. -


 * We had various proposals talking about inserting Youtube videos to articles, which all of them failed, mostly because Youtube videos are very informal and because of that contrast greatly with the articles' essential function.