MarioWiki:Proposals/Archive/43

Change the way rule number 9 of the proposal system works
DELETED BY PROPOSER

So, another proposal to remove this rule was made that was just now vetoed by an administrator. The idea in this proposal is not to remove the rule but instead change the way it works to make it more fair and less objectionable. So as of now, this rule is in effect:
 * All proposals that end up in a tie will be extended for another week. Proposals with more than two options must also be extended another week if any single option does not have a majority support: i.e. more than half of all votes cast must be for a single option, rather than one option simply having more votes than the other options.

I think that the rule could use a few changes that could keep much of its original intent intact while making it more accurate towards what the majority of users want. So I propose we replace that rule with this new rule:
 * All proposals that end up in a tie will be extended for another week. Proposals with more than two options must also be extended another week if any single option does not have a majority support: i.e. more than half of all votes cast must be for a single option, rather than one option simply having more votes than the other options, with the change option with the lowest amount of votes and all votes put into it removed each time that happens, and the people who made those removed votes given the opportunity to make a new vote for one of the other options until there is only one change option and the do nothing option remaining when the rules for the proposal basically revert to what the rules for one change vs do nothing proposals are.

I think the changed rule would be better than both the original rule and just flat out deleting the rule for the following reasons:
 * There isn't really that much of a difference in the end than if the original proposal was just between the two options that would have been the last two options in this case.
 * This way, there won't be bogus scenarios where nothing is done because two different change options were both preferable than doing nothing to a majority of people but the majority couldn't agree on which one was the better change option.
 * Since there is always a do nothing option left in the final two, there won't be any problems where two changes both with a different direction in mind that both have more support than doing nothing when both change sides would rather just do nothing than support the other change.
 * Therefore, this only really has the potential to do anything when both changes are ideas for a similar direction that the same users would rather have either of the changes over having nothing done.

Proposer: Deadline: June 28, 2015, 23:59 GMT

Support

 * 1) per proposal.

Oppose

 * 1)  Generally, rules function as intended. Proposed change reads like over complicating an already simple system to me. Additionally, per standard proposal rule 7: "No proposal can overturn the decision of a previous proposal that is less than 4 weeks (28 days) old." A proposal about a change to the proposal system was closed as "no" less than two hours ago. Further, as precedent was set, I call for administrative veto.
 * 2) The problem with this proposal is that it operates on the assumption that once failed, a proposal cannot be redone or there cannot be a later, related discussion that may refine and better compromise to address the needs for disputing sides. Finally, the proposed rule is difficult to read and understand. Further comments are also included. See below section.
 * 3) - Aping a ranked ballot system, as is being proposed here, is way to complicated and problematic. Also, it's frankly ridiculous that this proposal even exists in the first place, not only because it's unlawfully trying to overturn the "proposal rule changes can't be forced through by proposals" ruling on the last proposal, as Ghost Jam pointed out, but because it's blatantly ignoring that ruling. It wasn't "an" administrator who vetoed the last proposal: it was a decision made by multiple admins, and it'll happen to this one too, sooner than later. Maybe then the message will sink in. The system is fine: drop it and leave it alone already.
 * 4) – Interestingly enough, the current system we have now is a modification of this proposal. I had actually suggested this exact idea in April 2012 and it failed, but  suggested a refined version of it in September 2012 based on Walkazo's suggestions. The current rule works, and requires those that want to make a change to compromise in order to provide a clear path of action.

Comments
Wait, in proposals with three choices or more, if their deadlines are extended, do you propose removing the option with the least amount of votes? That sounds so convoluted. Even the wording in that is hard to read. The bolded part is one sentence! Anyhow, if there are two change options clashing and rivaling each other in terms of votes, proceeding with one change or the other will displease a sizeable group and that's not democratic. Having the proposal fail after breaking through several extended deadlines definitely means "no consensus has been reached, so no changes will be made". It's a failsafe measure at this point, and it gives the opportunity for further discussion and refining the proposal further. Not to mention, it wears on people's patience to see a proposal get extended, like, three times, so casting it off is good, elaborated previously.

In super drawn-out proposals, it's safer to kill them eventually than to take questionable and controversial action even if the outcome is dead tied. It's the reason FAs have a time limit, too. 14:17, 21 June 2015 (EDT)

@Ghost Jam: I tried my best to remove the objectionable pieces of the other proposal that caused it to be vetoed and take into consideration things said by Walkazo in my discussion with her in the other proposal to make it not fall into any objections that she made there. @Bazooka Mario, I specifically said in the proposal that the do nothing option would stay to the final two no matter what and before then, only options suggesting change could be removed so if there is a case of two change options clashing and rivaling each other in terms of votes, and people voting for one of the changes would rather have nothing done, they will always have the chance to just move their votes towards doing nothing. -

@Walkazo, just veto it now then in this case to get it over with. I tried my best to fix the problems that got the other proposal vetoed but I guess in this case, I didn't do enough so I guess you should just veto this proposal now. I'll talk about it more with you in user talk page if I feel the need to. I'm sorry for my mistake. -


 * No, I didn't mean that. During a hotly contested proposal, there has to be a time limit for how long a proposal runs, and once that time limit is exceeded, it is canceled, period. The proposal is done, but the discussion can continue since the canceling suggests more discussion needs to be made before putting it "to the floor". People that vote for change don't like to have nothing done, but "do nothing" is the least of the evils when two votes are hotly contested and the time limit is reached. 14:51, 21 June 2015 (EDT)


 * @Kart Player 2011: Feel free to cancel it yourself, if you now understand that it was an ill-advised move. Just be sure to archive it properly, rather than deleting it outright. - 15:08, 21 June 2015 (EDT)

Lessen Crossover Coverage
DELETED BY PROPOSER

According to the current Coverage rule, crossover games like Super Smash Bros. and Mario & Sonic have full coverage. However, this means that we have to cover all of the content from Super Smash Bros., which can cause us to compete with our NIWA Affiliate Smash Wiki. Look at all the Smash content. Shouldn't we focus more on Mario? So I have a proposal:


 * Games that are 0%-5% Mario: CAMEO - No coverage except for on a list of references.
 * 5%-20% Mario: GUEST - just a page on the game and mentions on Mario pages.
 * 20%-70% Mario: CROSSOVER - All playable characters, original content and Mario based content get pages. However, content from other franchises other than playable characters will not be covered.
 * 70%-100% Mario: MARIO GAME Everything in the game will be covered, no matter what.

Proposer: Deadline: June 30, 2015, 23:59 GMT

Support

 * 1) As proposer.

Oppose

 * 1) Regardless of anyone's opinion on the matter, your method of deciding whether or not a game should be covered is really off. How is it decided which games have "5%" Mario or "25%" Mario and so on and so forth? It's incredibly vague and I'm not comfortable with it.
 * 2) - Even if the proposal was suggesting something that was actually usable, the current coverage policy is fine.
 * 3) Umm what? Do we cover all 719 species of Pokémon? Do we cover all of Pikachu's apparences in the trading card game, anime, and whatnot? Do we cover all of Kirby's copy abilities in his games? No. All we cover are Smash Bros. apparences. I don't really get this proposal.
 * 4) Per Time Turner.
 * 5) Our coverage policy is fine and all the NIWA wikis know about it so it's not a problem.
 * 6) Per Time Turner and Pokémon XD: Gale of Darkness.
 * 7) Per all. Every single time anyone's asked to reduce coverage, it always gets shot down, this would be no exception. For a good reason too. I see no good reason to reduce our coverage and I feel it's counterproductive to our goal. We even link to SmashWiki in the end of Smash pages anyway so....
 * 8) Per all. The current policy was written with the goal of making the process as inclusive as possible while not going overboard or otherwise becoming too fiddly. I'm not in favor of anything outside of a justified tweak here or there, this proposal goes will beyond that.
 * 9) Per all.
 * 10) Per Pokémon XD and Time Turner.
 * 11) Per all.
 * 12) Strong Oppose. As stated in this proposal: "We cover Smash Bros. fully. We should cover all special moves and Final Smashes, especially since all are major aspects of Smash Bros. that are given a name. Hell, Air Dodge, Shield, and Footstool Jump all have articles.[...] Also, for those who think we're becoming SmashWiki 2.0, actually, that's a slippery slope argument. SmashWiki talks about strategies, character viability, move viability, combo potential, DACUS, wave-dashing, SHFFL, famous competitive players, famous tourneys, palette swaps, Sakurai angles, and a ton other Smash Bros. jargon and nitty bitty mechanics we won't even breahte[sic] on.[...]". Finally, the percentage points defined in the proposal is ridiculous, as if there is a hard-defined method to tell whenever a game is a crossover or guest appearances or cameo and each "element" is treated equally (for example, using these percentage points, Mario being a playable character in a 100-character roster in a Dynasty Warriors game would be deemed less significant than a Mario costume in a Marvel vs. Capcom game of 10 characters, each getting one alternate costume).
 * 13) What is this? The way we do it is fine. We're not competing with SmashWiki, and your calculation system makes no sense. Could you please give an example in the comments? What percent is Super Smash Bros Melee?

Comments
So how do you suggest those percentages are calculated..? --Glowsquid (talk) 23:22, 22 June 2015 (EDT)
 * Also Smash Wiki's coverage is far more technical and fandom-heavy (pages on tournaments, tourney players, memes, using the technically unofficial name "Smash 4" as the default way to refer to the latest installment... etc), so the "we're competing with them!" argument doesn't hold much water. --Glowsquid (talk) 23:25, 22 June 2015 (EDT)
 * Just count how much Mario content is in the game. For a Super Smash Bros. game, count the fighters, stages, music, items, etc. marked with mushrooms, eggs, DKs and Ws and count the total content in the game. Make a fraction with the Mario points on top and the total points on the bottom and divide, and convert the decimal into a fraction. SeanWheeler (talk) 23:32, 22 June 2015 (EDT)
 * are you fucking serious --Glowsquid (talk) 23:38, 22 June 2015 (EDT)
 * And just because they have fandom-based articles doesn't justify us having a lot of content they have. Do we really need all the Pokémon? That's something for Bulbapedia. And I think on the codec conversations and Palutena's guidence, we should just do the conversations about the Mario characters. And the list of trophies should only include the Mario, DK, Wario and Yoshi trophies. Well, at least we'll still have the playable Link, Samus and Pikachu. But I don't think we'll need Ridley, Chansey or Tingle.SeanWheeler (talk) 23:47, 22 June 2015 (EDT)
 * Oh yeah, I'm serious. But if you don't want to do calculations, you can just estimate. SeanWheeler (talk) 23:47, 22 June 2015 (EDT)
 * We don't have "all the Pokémon" though, we have a small table that briefly describes each Poké Ball Pokémon in the context of its Smash appearance alone, and short pages for the Pokémon fighters in Smash that give a very brief description of the Pokémon's concept, and then a brief description of its appearance in Smash, nothing more. The article does not describe the concepts of the individual Pokémon in any detail at all as Bulbapedia would (and does), nor does it describe or even mention Pokémon that appear outside of Smash. Pseudo-dino (talk) 03:17, 23 June 2015 (EDT)

@SeanWheeler, SmashWiki also is very technical about the Smash content. They have tier lists, tourneys, professional smash players, project m, advanced techniques, how viable a character is...etc. If like to learn what wave-dashing, star kos, wall of pains, etc. are, then SmashWiki covers it very well. We don't go that far. We cover like only the official thingamabobs. 03:37, 23 June 2015 (EDT)
 * Well, when I said "all the Pokémon" I wasn't talking about all the Pokémon in the National Dex. I mean all the Poké Ball Pokémon like Chansey, Blastoise and Fletchling. Do we seriously need these Pokémon? SeanWheeler (talk) 11:26, 23 June 2015 (EDT)
 * It's better to have individual articles on them rather than keeping them stuffed all into one page and only that page (along with trophy information). Much akin to putting all Yoshi Eggs in one basket and then eating them, balut style . 17:43, 23 June 2015 (EDT)

"Shouldn't we focus more on Mario?" is a moot point. 5 Smash Bros. games and 9 Mario & Sonic games out of the hundreds of other pure Mario games. -- 16:06, 23 June 2015 (EDT)
 * And that's only if you count the games that have both a handheld and console version, which have a lot of the same content anyway. -- 16:07, 23 June 2015 (EDT)
 * Okay, fine. Could we end this early? I actually like our Smash articles anyway. SeanWheeler (talk) 21:20, 23 June 2015 (EDT)
 * Okay, you can archive it and mark it as deleted by proposer. 21:29, 23 June 2015 (EDT)

Change intro standards for mainspace ex-subpages
DON'T CHANGE 1-7

See this proposal for some background.

This proposal seems a bit minor, but as a Mario Wiki, we strive to inform, not point out the obvious. That being said, the intros for the gallery space and other subpages are very unprofessional, as their only purpose, aside from stating the obvious, serves as filler text (seriously, one big reason we have such text is that "blank space is kind of an eyesore"). The most useful thing it does is provide a link to its main article. Now, I recall proposing replacing the intro text and turning gallery space into subspace, but I wasn't aware that it would violate our subpages policy, and I'm not willing to drastically alter an established policy just for the sake of changing the intro text a bit.

One solution is to replace the current intros with a simple. As for related ex-subpages, we can use. Articleabout, however, is less than ideal, but there's nothing in the way of creating a new template that link to related ex-subpages without saying that a page of images of Mario is a page of images of Mario. Not only does it seem more professional, it simplifies our introductions so users don't have to continuously refer to a policy that specifically outlines how each intro should be worded. Besides, our Subpages Policy is outdated, since galleries now include a few media files (see Baby Mario).

Anyway, another solution is to create an entirely new template which focuses on ex-subpages and links to related ex-subpages only when the related parameters are used. This would make it a combination of and, but altering it to make it more presentable. The new template would be something like this:

Main article:  For information about, see .

Further suggestions and alterations to this template would be appreciated, as it's only a prototype and I suppose more seasoned template makers can have a hand on this, provided they support, of course.

So, to sum it up, the advantages of using a template would be replacing filler text with a more useful and simple link, and it would simplify our Subpages Policy, the intro aspect.

Finally, this applies to mainly the mainspace ex-subpages, which is what this whole Subspaces Policy is about in the first place. Of course, exceptions apply, but if they're rare and not intrusive, the proposed changes wouldn't undermine the wiki.

Proposer: Deadline: July 1, 2015, 23:59 GMT

Support

 * 1) It's simpler than memorizing a bunch of one-liner intros that point out the obvious, thus making it look more professional. If there are any major flaws I've overlooked, please state so and we'll see what we can do about those. Any refinements is highly encouraged as I do feel there are some ruffles than can be easily worked here and there. After all, these are just prototypes, but I hope you get the basic premise of the idea.

Oppose

 * 1) - In all honesty, I don't have a problem with the one-liners: unlike articles, there's nothing really to say besides what it is (with maybe an extra link to a port/remake or whatever), and yeah, something is better than nothing or a bare  or an equivalent, so whatever. It's not like readers will notice or care either way anyway. Plus, no one needs to memorize what to put since the policy page is set up for copypasta ease. I'd rather just update the policy page than worry about having to fix this non-issue in all the subpages. Don't fix what isn't broken.
 * 2) - I don't really get why we need to do this. Per Walkazo.
 * 3) Per Walkazo.
 * 4) Per Walkazo.
 * 5) Per Walkazo.
 * 6) Per Walkazo.
 * 7) Per Walkazo.

Comments
Huh, I'd expect someone to say "there's no problem with it, so no change". I think a little change goes some way, though, and my proposal is changing just for the sake of concision and trimming out filler text. As for the copy-paste thing, it's still more of a hassle to access these pages to copy-paste them than inputting a template that generates automated text anyhow. I really don't find those intro texts necessary other than providing a link to the main page, hence this proposal. It's not "fixing what isn't broken", it's improving/refining what we have right now, even if "readers won't care anyway". 22:02, 23 June 2015 (EDT)

Make a page for Rhythm Tengoku: The Best +
CREATE 12-0

Coverage states that pages for "Guest Appearance" games need to be voted on before being created. That rule was broken for the Punch-Out!! page, but revisiting that is kind of a waste so w/e.

Anyway, Rhythm Tengoku: The Best+, the latest game in the Rhythm Heaven series, has two hidden levels that feature all the main characters from the warioware series. I think the game deserves a page for the following reasons.


 * 1) It's a small but significant part of the game. It's the only challenge set which has new graphics and it is advertised on Nintendo's official Japanese website.
 * 2) It's not simply cameos. It's a lot of content that's being rejiged (not just one or two games) and the WW characters are playable (in the sense you press buttons and they react to your input, kinda weird to say this about this about a rhythm gaem, but whatever).
 * 3) The ww characters cannot be handwaved as being similar but different persons, random references, etc. It's a literal "guest appearance".

Proposer: Deadline: August 3, 2015, 23:59 GMT

Support

 * 1) - It's pretty much the definition of a "Guest Appearance".
 * 2) Per all.
 * 3) Per all.
 * 4) Per Glowsquid.
 * 5) Go on.
 * 6) Yeah, this should get a page.
 * 7) Per Glowsquid.
 * 8) – Per Glowsquid.
 * 9) - Per Glowsquid.
 * 10) – Per Glowsquid.
 * 11) Per all.
 * 1) Per all.

Add direct links on star icons for 64/Galaxy/Galaxy 2
DELETED BY PROPOSER

I random'd to a SMG galaxy page earlier today, and rolled over the star icon; clicking would have led me to the file page. So, I got an idea: add direct links to their respective stars. This idea came from the map that exists on pages like this which provide a direct page link to that location. What I mean is that clicking on a star icon in the "summary box," as I call it, would take the reader to the section they are looking for, making the need for excessive scrolling nonexistent.

Proposer: Deadline: August 30, 2015, 23:59 GMT

Support

 * 1) As proposer, I support my proposal.

Oppose

 * 1) - You mean the stars in the infobox? Making them section links seems like too much trouble when the table of contents listing the levels is literally right beside them. Plus, a row of stars is not the same thing as a full map, and wouldn't really help folks that are bad at names but good at visuals anyway (not that I even like that the maps are plastered onto every place article to begin with, tbh: it'd make sense for the game pages and maybe a couple other places, but we should just use the regular nav template link lists on the separate articles, imo).
 * 2) – There's already links to them directly above, even directly above in the case of Super Mario 64 and Super Mario 64 DS, the list of stars. This applies to all Super Mario 64, Super Mario 64 DS, Super Mario Galaxy and Super Mario Galaxy 2 level articles. I also don't understand why adding more links to something which is easily accessible by just eyeing a little bit above the list of stars is ultimately going to add to articles.
 * 3) Per all, and I'd even agree with Walkazo about the map links being unnecessary.
 * 4) I don't think it's necessary as stated above, but adding links would be an inconsequential change, which means we probably wouldn't have noticed if you added it without our "permission" or not. Considering that if this proposal passes, though, we need to add the links. I oppose just on those grounds. On a different topic, yeah, I agree with Walkazo about those maps (navmaps, I believe?) since they seem disjointed from the rest of the article.
 * 5) I really see no benefit to doing this. Per all.

Comments
I'm withdrawing; please archive. Thanks!

Add 'Edit' Button To Navigation Templates
PASSED 19-0

Yes, I know, we've already had a proposal about this, but my views on the subject have changed. Sometimes, when I want to improve on a navigation template, like adding a link or fixing a redirect link, I first need to hit edit of the page I find the navigation template at, find the name of the template, then find the name of that template in the list of templates listed when you're editing the page, and that's just plain tedious. The reason it failed was because "you should have multiple steps away from editing a Navitagion Template", and wording which generally reflected on assuming bad faith in edits.

"But if we add this, then there will be too much vandalism to fight." –You, after reading this.

This line of reasoning is nonsensical on so many layers it's not even funny. If we assume there is going to be vandalism just because we make something easier to access, then are we really assuming edits are made in good faith? It's downright disgusting that this is even something that's being thought of. Yes, this is something that other Wikis do. It's something other Wikis do better than the Super Mario Wiki does at this moment. Therefore, we need to step our game up, and upgrade past this "if we make things easier to access then everyone will edit stuff and this is bad"-kind of think that ultimately assumes editing in bad faith. Besides, if someone vandalises a navigation template, and there is an 'edit' button when you view the template as part of a page, it's going to be slightly easier to access the template and revert any vandalism done to the template, even without going to the recent changes. I think that's kind of neat.

Proposer: Deadline: August 26, 2015, 23:59 GMT.

Support

 * 1) – Per proposal.
 * 2) &ndash The reasoning provided in the previous proposal is bad, and it'd save everyone a lot of tedium. If vandalism is somehow more of a concern with this set of wiki features, just autoconfirm them
 * 3) Yeah I don't know what I was smoking when I said "no one uses it". These things get updated like all the time, whenever a new game gets released or so. I've always disagreed with that reasoning in the first place though, so there goes my only oppose I had.
 * 4) The opposition's reasoning in the previous proposal is ridiculous and basically a variation of "if it ain't broke, then don't fix it", which is a really annoying thought-terminating argument. Their argument: it's too much like Wikipedia and it's ugly and distracting and it worked without it before. Rule of thumb: websites should be designed for the convenience of its readers, so "it's ugly and distracting anyway" isn't a strong argument (I don't agree that it's "ugly"). My sister is the most reasonable, but it would be nice to have something so inconsequential as easy template editing.
 * 5) I've always found it a pain to try and figure out what the name of those templates were. Straight forward links leading straight to editing them make things a whole lot easier. Per proposal.
 * 6) Per all; this would be a time-saver like you wouldn't believe.
 * 7) Per all.
 * 8) - I'd still say a full navbar (like last proposal) would be ugly and unnecessary (most pages don't have talk pages at all and histories rarely need immediate consulting), but just an "[edit]" link seems reasonable and straightforward (no need for code letters and hover-over text), plus it'd balance out the "[show]", so sure.
 * 9) Per Time Turner
 * 10) - Per all.
 * 11) Per all.
 * 12) Per all.
 * 13) Per all.
 * 14) Yes! I hate this current system. Per everyone.
 * 15) Per everyone!
 * 16) I haven't edited for quite a while, but I really don't want to look through bazillions of long lists of templates just to get another list. Also, per all.
 * 17) Per all! And because this is essential
 * 18) Per all after thinking about it for a while.
 * 19) Per everyone.

Comments
@Bazooka Mario: Don't you mean "websites should be designed for their readers rather than their editors"? You've got that mixed up. Anyway, adding an "edit" template there benefits readers, as it could help point them to the template that needs to be fixed/updated at a convenient time. 23:23, 18 August 2015 (EDT)
 * I got it mixed up, yeah. *blush* 23:30, 18 August 2015 (EDT)

I'm mixed on this. On one hand, I think that we should add something on these templates. On the other hand, I'd rather it be a view link button rather than an edit button. 20:21, 19 August 2015 (EDT)
 * But if you just wanna look at the template, you can do so on the article it's on: most people will only go to the template if they want to edit it, so it makes more sense to have a link to the editing interface, and then from there the few others can just make one more click to view the template. And if you mean you just want the template name, you can already get that from the editing interface - or simply by hovering your mouse over the edit link without clicking it at all, for that matter... - 20:32, 19 August 2015 (EDT)
 * Finally, just another method, you can just pinpoint the template name at the search bar by typing "template:". I don't see the need for a view-only button. 21:12, 19 August 2015 (EDT)
 * As a final addition to this conversation, when you hit 'edit', you'll be immediately taken to a place where the 'view' and 'talk' functions are available by a single click, just by viewing the tabs at the top of the page. It's very convenient that way. 20:33, 22 August 2015 (EDT)

Replace "NTSC/PAL version" with "American/European/Australian/Japanese version"
DELETED It has come to my attention that the current terminology we use for regional differences in Mario games (NTSC/PAL) is obsolete. NTSC and PAL are outdated TV standards. It puzzles me even more when people call, say, the European version of a handheld game the "PAL version", because that doesn't even make sense since it's not on a TV. Also, there could be differences between the American and Japanese "NTSC versions" beyond language, and our current terms would be non-indicative. Same with European and Australian "PAL versions". The Australian version isn't always a direct import of the European "PAL version" anyways. Sometimes it's the US version. Sometimes it's different from both of them. I know this might be confusing, but using more region-specific terminology will curb all this confusion. Proposer: Deadline: September 9, 2015, 23:59 GMT

Support

 * 1) Per above.
 * 2) It would make more sense. Per YoshiCookie.
 * 3) I agree that we must be more specific about this.
 * 4) Per YoshiCookie.

Oppose

 * 1) I have never heard of those terms being obsolete, otherwise we would have changed it before. Prove that the terms are obsolete and I'll support.
 * 2) NTSC and PAL refer to specific groups of countries that share a common region lock (and plenty of other details, but that's not relevant at the moment). "NTSC" is a simpler way of saying "North America, South America (but not this country, this country, this country, etc.), and also this country, this country, this country, etc.", for example. If we want to refer to differences between American and Japanese releases, we already specify it, but NTSC, PAL, and so on are all terms that are appropriate and very relevant to us. There are likely cases when the terms are used inappropriately, but otherwise, it serves a purpose and should not be excluded.
 * 3) The labels "NTSC" and "PAL" refer to the CDs of the games, in which is the terminology that video games are still using and therefore are actually not obsolete. The TVs may have stopped using it, but the CDs haven't. And it's not puzzling to call them "NTSC" or "PAL", since it has become a regular use in our language to refer to regional differences of various CDs, and if you don't understand what they mean, then it's about time you understand some technical words. We could replace that terminology if there are further regional differences with, say, Australia or whatever, but to completely replace those words is something I'm against. Oh, and Time Turner ninja'd me. Fantastic.
 * 4) Per all.
 * 5) Per Time Turner and Baby Luigi. I think that this change wiki just makes things harder.
 * 6) - Per all, especially Time Turner.
 * 7) Per all. Such terms should also be defined in our glossary (which it isn't at the moment).
 * 8) Per TT and BL.

Comments
I think however it is important to note when that term refers to actual 50/59.94 Hz versions of the games, which can be relevant in games such as the Mario Kart series games.--Mister Wu (talk) 13:27, 2 September 2015 (EDT)


 * Agreed. Also, ZonkMario64, look at this.


 * Don't see US, do you mean UK? SM64 Mario Sidekick.png Don't Get Zonked!  Question Block 3D.png (blabbing &middot; what i do) 15:42, 2 September 2015 (EDT)

But what about handheld games? YoshiCookie (talk) 17:33, 2 September 2015 (EDT)
 * Essentially the same deal. 19:04, 2 September 2015 (EDT)

Delete Meaningless Quotes
DELETED BY PROPOSER

Yeah I know we went through this before but it was different because it was going to delete entire pages. I'm tweaking that to say keep the pages, but delete meaningless quotes. For example:


 * Useful quotes: "Oh, did I win?" "Let's go already!"


 * Meaningless quotes: "Yes!" "Woohoo!"

In essence, quotes that are only used by one character (Peach and Waluigi, respectively) will stay. Generic quotes (So many Mario characters say "Yes!" in Mario Party and Mario Kart) will be deleted.

Proposer: Deadline: September 9, 2015, 23:59 GMT

Support

 * 1) I'm ZonkMario64, and I approve this proposal.
 * 2) YES PLEASE! It's so annoying having a "quotes" page full of stuff like "yay" "woohoo" and "yeah" to name a few. Per proposal.

Comments
I'm pretty sure there already was a proposal enacted to curb these things? Or I swear there already is a guideline that specifically advocates removal of "YES WHOOOOHOOOO" quotes. 16:15, 2 September 2015 (EDT)


 * Yes, but it was vetoed by admins because it would "strip the wiki of valuable information." SM64 Mario Sidekick.png Don't Get Zonked!  Question Block 3D.png (blabbing &middot; what i do) 16:16, 2 September 2015 (EDT)
 * what. 16:19, 2 September 2015 (EDT)


 * here it is SM64 Mario Sidekick.png Don't Get Zonked!  Question Block 3D.png (blabbing &middot; what i do) 16:19, 2 September 2015 (EDT)
 * That proposal said to delete whole articles of quotes. The one I linked was to specifically delete these. 16:20, 2 September 2015 (EDT)
 * But the proposal from '07 was about gibberish and the like. "Yes" is not gibberish. SM64 Mario Sidekick.png Don't Get Zonked!  Question Block 3D.png (blabbing &middot; what i do) 16:35, 2 September 2015 (EDT)
 * It's not talking about literally gibberish, it's just talking about quotes that are mostly meaningless onomatopoeia. 16:39, 2 September 2015 (EDT)
 * Which doesn't apply to "Yes" either, I don't believe. SM64 Mario Sidekick.png Don't Get Zonked!  Question Block 3D.png (blabbing &middot; what i do) 16:40, 2 September 2015 (EDT)


 * The admin veto summary explicitly says "trim out the unnecessary quotes". The proposal was vetoed because it was using a sledge hammer where a pick-axe would be better, but ultimately, both it and this one were/are unnecessary, since useless quotes that show us nothing about a character's personality can already be removed via common sense and good taste. -

This proposal is not needed whatsoever since it should, on paper, be enforced already as cited by previous proposals above. We can go ahead and delete those "all rights" and "yes" crap but I can imagine people going back and readding those quotes because they're actual words, I guess. If you want to hear character interjections, go to other sites, such as The Sounds Resource, a far better resource than MarioWiki. 20:59, 2 September 2015 (EDT)
 * So are we gonna delete this or what?


 * We need admins to do that, IIRC. 12:28, 4 September 2015 (EDT)
 * They probably will. 15:50, 4 September 2015 (EDT)
 * The hope is that the proposer will ask us to scrap it, since vetoing things is less than ideal, but at this point, it looks like it might just be a NO QUORUM instead. - 12:09, 6 September 2015 (EDT)

@Walkazo: Since I predict that this won't get 2 more votes by tomorrow, I've decided to delete it. Don't Get Zonked!  (blabbing &middot; what i do) 09:40, 8 September 2015 (EDT)
 * Actually, "it's not gonna pass anyway" isn't a valid reason to have a proposal deleted. People try to ragequit proposals periodically, so I'd rather not make any exceptions by granting such a request, even in this case, where the proposal's unnecessary to begin with. But if you'd rather it get yanked now so that you can start on removing the quotes before tomorrow, having learned from the comments that it's already allowed, just say so. - 10:10, 8 September 2015 (EDT)
 * Sold! I am starting school on Thursday so I'd like to delete as many meaningless quotes as possible before then. Thx SM64 Mario Sidekick.png Don't Get Zonked!  Question Block 3D.png (blabbing &middot; what i do) 10:31, 8 September 2015 (EDT)

Restrict (if not remove) ImageMaps
RESTRICT USAGE AND REWRITE THE POLICY PAGE 8-1


 * Draft: User:Bazooka Mario/sandbox (check this revision for any future reference if you ever need it).

ImageMap templates are images you find on articles such as in World 1 (New Super Mario Bros.) that are filled with links, where you click on a specific part of the image to go to a particular article. They're intended to help visual readers navigate the wiki and relevant games more easily, but I find their usage and implementation less than ideal. They qualify as mystery meat navigation, flashy, but user-hostile forms of linking. While the imagemaps in MarioWiki aren't as cryptic as the moon image example in the Wikipedia page, their designs are still confusing for the average reader for several reasons: they are awkwardly placed in articles and look identical to thumbnail images and their low-resolution quality (needed to fit inside the page) and lack of labels or clear borders make distinguishing between places difficult. As Wikipedia put it, "it may not be readily apparent that the image is a clickable map instead of a simple picture". They are even more difficult to use for mobile users since image maps heavily rely on hovering for labeling locations, which mobile users cannot do.

The World 1 example I listed is, unfortunately, typical of most imagemap templates: gaudy, gimmicky, and ultimately useless.

This proposal aims to address the following problems of each individual imagemaps. Deletion is usually preferred, but if you disagree for a particular ImageMap and have reasons to keep them, please state so.

It is also imperative to see comments below as well before you vote since these are not set in stone, and they can be changed even after the proposal has passed.


 * (this one is especially confusing. Extremely user-hostile for those who are not familiar with Luigi's Mansion, but probably still confusing for those who are. It would work better in an article that lists all locations in Luigi's Mansion, but such article apparently doesn't exist. This, at best, should stay in the drawing board.)
 * (see LM Mansion Map. While LM Mansion Map might be a navigational aid for those in the middle of a game (although the Mansion isn't exactly a maze either), this one makes even less sense since the Lab is a small place)
 * (this one is already covered by navigational template. Implementing this into the navigational template would just take up space)
 * (it might have use, but it's very difficult to implement this template in any other spot in the article, and it looks bad the way it is)
 * (see NSMB-W1map. That ImageTemplates are far from complete is troublesome (for the merits of Image Maps, which are already dubious anyway) but it might be good to restrict usage now before it gets out of hand)
 * (see NSMB-W3map)
 * (see PDSMBE-map)
 * (see PDSMBE-map)
 * (this one is even more confusing, and it has to be ultra-low res for it to look barely presentable, which makes distinguishing between worlds very difficult; very user-hostile image-map that should be removed)
 * (already covered in its respective article. Moreover, its location inside the level infobox makes it impossible to discern it from a normal image without hovering over its specific link points)
 * (not great, especially for those who haven't played the game. It might work for Bowser's body, but ideally, it should have labels, but the low-res nature thanks for AlphaDream makes it not worth it. It's still difficult pinpointing each location; case point, it took me, who hasn't played the game (and for those who are in the midst of playing the game, the game already provides labels to each location, if I'm correct) longer than it should to locate Trash Pit. Otherwise, it should be removed from area-specific articles due to its bad placements in those articles.)
 * (at best, it should stick to only to the game article, Mario & Luigi: Bowser's Inside Story. Even then, it looks inconspicuous and not very useful, and the in-game map probably already has those labels.)
 * (this one is bad. The low resolution makes it difficult to distinguish between each area, so I think we should just nix this one.)
 * (it's not horrible, but I question its usefulness the same way I question M&L BIS Overworld Map's utility. I'm aware that in-game, the map itself already provides pointers to where you are, making it even more useless for those in the midst of playing the game.)
 * (see M&L:PIT Overworld Map. Its in-game map also has labels and makes this one useless when it comes to wiki coverage. This one is particularly difficult to use due to its low-res nature and that certain major areas including Beanbean Castle Town are difficult to locate. Also, Beanbean Outskirts is located in a specific spot when it should surround Beanbean Castle, but I suppose that's impossible with this system. So, remove it.)
 * (Not good. Its low-res nature makes it difficult to use, as with most Image Map templates. It would work if it were bigger and had labels. Its placement in articles is just as miserable as in most Image Map templates.
 * (again, it's very difficult to distinguish between places without squinting)
 * It would probably work for general overhead articles, but only if it actually looks different from other images. It's still difficult to use since some places are bordering microscopic.
 * Utterly pointless (not to mention gaudy in Super Mario World 2: Yoshi's Island, and when you have screenshots that have this stuff in it, like in World 6 (Super Mario World 2: Yoshi's Island), it's also confusing.
 * It might work, but its current implementation is difficult to use and requires a microscope. It still needs to be confined to overview articles rather than area-specific articles.
 * See SMWmap; this one looks identical.
 * It might work, but confine it to general overview articles (Vibe Island in this case) rather than slapping it everywhere. It still needs to be placed in a better spot, but the low-res nature of it makes it difficult for me to think of a method where it doesn't resemble a plain image.
 * Pointless. Names are a good indicator of each place. Actually, this applies to most areas in most games.
 * Utterly pointless.
 * Utterly pointless.

Common issues:
 * Difficult-to-distinguish locations
 * Bad placement, especially within more area-specific articles (placement in overview articles are not great either).
 * Redundant.
 * Aside from a tiny i icon, looks identical to normal images.
 * Due to the over reliance on hover-text, mobile users cannot benefit from Image Maps.

This is a writing guidelines proposal because there is a policy page dedicated to this under the writing guidelines category. Again, some ImageMaps may be worthy of keeping (I have doubts though), but if so, then it must caution users when making ImageMaps and they need to be implemented in a manner that doesn't highly resemble normal images, perhaps a special border around the image with the label "image map", no thumbnail framing, and located in a more conspicuous spot in the article. Either way, all Image Maps have their issues and I can't say I like they way they're implemented here. I prefer if they were deleted and at least placed back in the drawing board so it doesn't look at bad as it is now, but all-out-deletion may be too much, so I'm open for suggestions and objections.

Proposer: Deadline: September 18, 2015, 23:59 GMT

Support

 * 1) All Image Maps, in my opinion, are highly flawed design aspects in our wiki. I used to think they are useful for the visual learners (including me), but they have only disappointed me so far for these above reasons. I think deletion or at least a highly confined usage will work for them. This is "Writing Guidelines" because it's a major change in one of our policies if it passes.
 * 2) Per Bazooka Mario.
 * 3) Per Mario.
 * 4) Per proposal.
 * 5) Per proposal.
 * 6) Per proposal
 * 7) I've changed my mind. Through the comments, Bazooka Mario has made it very clear what the goal of this proposal is. I still think this proposal isn't perfect, but I think we've made some decent progress that warrants my vote.
 * 8) - Image Maps are good for orientation in the directory articles (game and overall world/place pages), but not as alternative navigation templates on the specific location/level pages. See my comments about which ones should be scrapped or saved, but overall, a proposal to rehabilitate their use and fix the policy page is one I can get behind, and the draft is well enough along at this point for me to formally support.

Oppose

 * # Okay, hear me out. I agree with what's been said, and I agree that image maps are a mess. However, I don't think removing some without further thought is a good idea. This is the type of thing that can be changed, improved, and fixed. I'm not the best at coding, but I'm sure there's a way to make image maps appealing to everyone. If we try improving image maps and it doesn't work, ah well, maybe then we can think of removing them. But for now, give it a chance. After all, it's not the idea that is flawed; it's the presentation. Also, see my comments below. They are arguebly just as important.


 * 1) Per all, Andymii in particular.

Comments
Not that I disagree with what's being proposed, but if you're going to make a writing guidelines proposal, don't you need to make a draft?
 * Well, I'm not sure what the draft might look like as of yet, but the policy page implies that the process of writing a draft can be done during proposal process (that "writing guideline proposals are given two weeks as opposed to one so as to allow sufficient time to perfect the document.") Also, my proposal aims to either nix or highly restrict their usage, something I don't feel is worth potentially splitting the vote (I can go with either one), so I'm not 100% sure what's supposed to be in the draft yet, or if there is a call for a draft. It was difficult for me to determine if this proposal is about general change, removal, or a writing guideline, but I stuck with writing guideline since it involves potentially (emphasis on potentially) changing a MarioWiki policy or making it moot. In other words, I'm highly uncertain. 18:48, 4 September 2015 (EDT)
 * Okay, I got the draft down. That might be a start. 19:32, 4 September 2015 (EDT)

These are kind of useful. What will we do if they get removed or restricted? (talk|contribs) Kamek Power! 00:23, 5 September 2015 (EDT)
 * They are not useful as I explained above, and for these reasons, they are a user-hostile design that shouldn't be in this wiki in their current state. 15:35, 5 September 2015 (EDT)

Andymii: This proposal is not wholly about removing Image Maps, it's simply restricting their usage at best if in case there are reasons to keep one or two. As I said, "I prefer if they were deleted and at least placed back in the drawing board so it doesn't look at bad as it is now, but all-out-deletion may be too much, so I'm open for suggestions and objections." I'm saying that even at best, we should send Image Maps back to the drawing board to allow them to get improved so we can readd them when needed. Image Maps as they are are abused and look terrible in most articles they are in, mostly scrunched below the infobox, hidden at the bottom of the article, or being redundantly placed directly next to the list of levels. They're the gaudiest part of our wiki and thus, they don't improve our credibility. 15:35, 5 September 2015 (EDT)
 * And even if Image Maps are highly flawed in design, our Writing Guidelines for Image Maps set them up to be low-res and inconspicuous and I already pointed out those problems in my draft. 15:36, 5 September 2015 (EDT)

Good points, but I don't think we really know what we will do next. You've listes some image maps with comments, but most of them are just "this is useless" (okay, more detailed than that, but, ya know.) I'm always open for change, but I don't think this has been completely thought through. Not that I'm saying all our changes should be black and white, but I'm genuinelly unsure here what's going to happen next. --Andymii (talk) 00:13, 6 September 2015 (EDT)
 * I think the likeliest change would be keeping ImageMaps within generic location articles (like Bowser's Body, BeanBean Kingdom) while removing Image Maps from level/world articles. Remember, they can always be reimplemented, but I just don't like their current state right now. I'm emphasizing on "if not remove" part of the proposal title. See, that's what a draft is for, and that's why "Writing Guidelines" go for two weeks, for me to think and allow people to point out suggestions and other comments. 01:15, 6 September 2015 (EDT)
 * Oh, I'm sorry. I had a misunderstanding. You're thinking of deleting the maps from level/world articles and keeping them on generic location articles. I actually think that's a good idea. I wish I supported.

(talk|contribs) Kamek Power! 10:08, 6 September 2015 (EDT)
 * You can remove your opposition vote and support the proposal instead, you know. - 12:07, 6 September 2015 (EDT)

So I finally got enough time to look at this proposal properly (except for the writing guideline draft: I'll try to get to that tonight or tomorrow) and go through the templates one-by-one, and here's my thoughts, grouped by map type / verdict for clarity:


 * - Keep: it'd be good for Luigi's Mansion (place) and Luigi's Mansion. But I'd suggest redesigning it to that all 5 levels are vertically arranged (rather than two columns), with a bit of blank space between each as buffers so that it's clearer that they're different floors.
 * , - Scrap: too small to be worth-while.
 * }},, , , , - Scrap: the labels are in the images already; just have the regular images on the pages rather than all the trouble of a template.
 * ,, - Keep: since there's branching pathways it's not completely intuitive what the numbers always are, and provided all the worlds get them, they could be used in both those articles in the infoboxes (P&D is fine but the NSMB infobox needs to be wider to be legible) and the game pages (i.e. stacked in the "Worlds" sections next to the descriptions, rather than just single world examples).
 * ,, , , , , , , , - Keep: not all the area names are intuitive, and the maps will fit on the game and location pages well enough (in place of mere images, and at large-enough sizes, not scaled down). The only issue is that larger areas should have more than one tiny clickable area (e.g. add multiple link sites for Beanbean Outskirts, and all the NSMBU areas, etc.).
 * - Keep: it's good for Bowser's body and the M&L3 game article since then you can match up the locations to the nodes (otherwise long windy directions are needed since it's not intuitive at all a lot of the time; that'd be fine for individual location articles, but it'd be too much all in one place).
 * - Scrap: duplicate of

Overall thoughts: The overworld maps are good for game and place articles (Beanbean Kingdom, etc.), and the world-specific maps are good for the world articles and the game articles, as long as all the worlds have them. When a template is used on an article, it should be used in place of a mere image of the map; this will often mean putting the template in the infobox, which should be fine as long as the infoboxes aren't obscenely wide (but most templates are only about 400 px or less wide, which would be fine for an infobox, and should be clear enough to be readable and useable). If the names of the places are right there in the level/world select screens, no template's necessary to tell readers what place is what. - 16:45, 7 September 2015 (EDT)
 * I'll get around to some revisions, but do you think how Image Maps are placed are a problem? That ImageMaps aren't immediately discernible from simple images is an issue. I think the infobox might need some revision to let readers better know that these are Image Maps. 18:19, 7 September 2015 (EDT)
 * Just include a "click the level icons/areas/etc. to go to the relevant articles" note as a caption (no  following the template) for the images in infoboxes, and when images aren't in infoboxes, like in game pages, just mention it in the text or the thumbnail notes (depending on whether it's formatted as a thumbnail or not - anything that goes in infoboxes shouldn't be). -  18:55, 7 September 2015 (EDT)

Wow, I didn't realize how terrible Image Maps is... Anyway, I looked over the draft, but there's so many problems with the source material, I gave up on trying to succinctly comment and just did a whole new draft for the policy parts, based on some of your comments on your draft page, and also things that I said here, and extra bits that occurred to me as I was working. Let me know what you think. - 21:55, 8 September 2015 (EDT)
 * Yeah, I was wondering why it seems so... amateur to me, nothing against Megadardery (he's not a native speaker if I recall correctly). Yeah, my draft probably isn't the best, so I just made comments here and there. Well, is it fine if I incorporate the draft soon? I still have yet to look over it, but at a glance, it seems fine... 00:07, 10 September 2015 (EDT)
 * Yep, if you wanna use my draft, feel free to copypasta it (and then make any fixes or further changes if you see fit, but for clarity, I'd use separate edits than the initial moving of the content). If this passes, I can update the protected policy page for you and ensure the appropriate credit is given to both of us in the summary. - 18:39, 10 September 2015 (EDT)
 * Okay, I've done it, and I've included some (not much!) commentary on some points. It's mostly for clarification or other questions. 15:53, 12 September 2015 (EDT)
 * Cool. I updated my page to better explain the default link stuff), and also made the "no fan images" part of the main point rather than a subpoint unto itself (but I think it should still be explicitly said to make absolutely sure people get the point). As for the size/clarity one, the subpoint gives examples already, so more aren't necessary. EDIT: I also made a few grammar tweaks on top of your changes, shown here. - 17:06, 12 September 2015 (EDT)
 * That's what I thought the extra bullet point was meant to hammer in readers, but I think how you merged it is a better idea. One more statement that isn't made very clear to me is the one that starts with "Locations that are widespread in the map[...]". I'm not sure why I haven't commented on this earlier, but later reading it, I kind of go "huh?". 17:43, 12 September 2015 (EDT)
 * Like how in, all the areas are pretty large, yet once the text disappears after you hover-over part of the area, it doesn't appear again as you waver the mouse around the rest of the large area - so I feel like in these cases, it'd be good to break the areas into smaller chunks so the text can come up more than once and show it's all the same place. Plus, as been mentioned before, places like the Beanbean Outskirts are all around the castle, but only have a link underneath in , so multiple links would be good for those as well. - 18:05, 12 September 2015 (EDT)
 * Beanbean Outskirts is a good example to provide for this then. I couldn't find the link for it myself, so I speak from personal experience. Thanks for the clarification! 18:26, 12 September 2015 (EDT)

Okay, so I went ahead and rewrote the bottom half of MarioWiki:Image Maps too - to the best of my abilities, anyway, but I'm pretty sure all the coding stuff is right. - 20:51, 15 September 2015 (EDT)


 * sigh, all my hard "bad" work. Actually, it was a terrible thing I did with the Image Maps. So yea, the draft Walkazo came up with is 100 times better :) Anyway, regarding the actual proposal, I don't agree with removing all the imagemaps as Bazooka proposed, I prefer to go with Walkazo's suggestion, I wasn't very keen on the NSMB and YIDS style map, but since it was made by one of the admins (or a formal admin), I didn't give it much of a thought, I felt it provided a faster way to move if you know which page you are going to go to, saving you the trouble of writing the link in the search bar or something. But now that I think about it, the images looks ugly the way they are. Anyway, regarding the bigger maps, especially Luigi's Mansion. Not only because that I made them (and I make perfect ImageMap templates, mind you :P) . But because they actually help to navigate faster between rooms, and show users a very good layout of the mansion, better than any lengthy description. I could manually add text to the rooms to make them easier to see (because the game doesn't nativally show names, or at least the name of the rooms you are not in). But it's a gray area editing screenshot, so avoiding it is better. Also, hovering over any part of the mapimage will show the link location in almost all modern browsers in the lower left corner of the screen. If not, waiting like 1 second will show you the target name under the cursor. So whatever the imagemap is, it's not worthless. But if it causes troubles or ugliness, then off with it. If the names of the location is the thing that annoys you, I think going over all the games and getting screenshots of the maps with the labels shouldn't be very impossible.-- 07:52, 18 September 2015 (EDT)
 * Don't be too hard on yourself. I thought about you when I made this proposal and I was pretty guilty, but in the same time, their design bothers me. As stated in the proposal title, the "if not" part is only an option if people really do think they should be removed, but my main point is to amend them, and if they cannot be amended, then they should be removed. I'm aware that you can hover over the area to get their names, but it's fairly time-consuming, and mobile users can't do this. I do think labels might work (and it can; Superstar Saga has ingame labels that we can possible screencap off and upload it on this wiki). The problem with my proposals is that my ideas and thoughts tend to be half-baked, and I'm grateful that we're allocated two weeks to sort out those kinds of things. 18:07, 18 September 2015 (EDT)

Add "bugs and" or "and bugs" to "List of glitches in"
DON'T CHANGE 1-5

First, my reasoning is bugs and glitches are not the same. A bug is a minor glitch (like a short-lived audio glitch, which would be considered a bug according to this proposal), whereas a full-blown glitch is something that is longterm, causes a game to freeze, and so on and so forth. For example: this is what would be considered a bug, but this would be a full-blown glitch.

Proposer: Deadline: September 20, 2015, 23:59 GMT

Change

 * 1) per my own proposal.

Leave as is

 * 1) - Seems too similar and minor to bother changing all these titles, and mouthful "_ and _" names are less than ideal in general. The only reason we're stuck with "pre-release and unused" is because there's no nice umbrella term, but I feel like the broad meaning of "glitch", like how we currently use it, is more widespread and accepted than "beta" was, with a lot of (if not most) folks using it and "bug" interchangeably.
 * 2) Per Walkazo. Better off staying how they are.
 * 3) Per Walkazo, as well as Baby Luigi in the comments.
 * 4) I think it's totally fine to create a page called Bug and redirect it to Glitch, but beyond that, I feel the definitions here are a smidge pedantic, unlike the far more confusing "subspecies" and "beta".
 * 5) Walky said it better, but I don't see the point. Bugs and glitches are already near synonyms and I doubt anyone's getting confused.

Comments
I'm on the edge with this, but your description is wrong. The term of a bug and glitches is not defined on how damaging of a scale they are (both can cause game-breaking things, it depends on what component of the game experiences that or that), but the processes that caused them. Glitches, I believe, are things that the game developers did not intend/over-looked that are performed by the player, while a bug is a problem in the coding of the software itself. But since we do use "pre-release and unused" for that, I don't see why we can't add "bugs" to the title description. However, most people say those two interchangeably, so I do think it's verging in pedantry. 16:52, 13 September 2015 (EDT)
 * I wasn't talking about the level of damage but the significance of a glitch. And while they are interchangeable, that is only in speaking. On the wiki, however, the two should have different meanings. RoyNSMBU.png Roy Koopa 16:57, 13 September 2015 (EDT)
 * It's still not dependent on the magnitude of the glitch. As I said, the term is defined more of processes that caused the error in the game rather than how significant they are, as both are fully capable of crashing the game or whatever, so it's really hard to define terms that way (like, a minor clip bug could cause the rest of the game to be unplayable, because you cannot advance due to it). And tell why they should? I have said why they should not; because it's for the convenience of searching for these articles and because it's used interchangeably in normal speak. Compared to beta elements, that is. I've also stated why we should, to be consistent with the pre-released and unused content article. 17:01, 13 September 2015 (EDT)
 * About the minor clip bug, that would call for a reset of the system/software. As for the convenience of searching bit, if someone doesn't know we only use the term "glitches" and looked up "List of bugs in," they would get nowhere. As you might be able to see, this proposal is more for the help of readers who have no intention of editing, anons who edit, and new users. RoyNSMBU.png Roy Koopa 17:12, 13 September 2015 (EDT)
 * Exactly, you've proved my point on why we don't define the terms solely because of how big and game-changing they are. There are far too many variables and parameters we have to define; saying the processes that caused this and this error is a better way to define "bug" and "glitch" rather than how significant it is, and "significant" is a pretty loose and relative term. Also, I think we need more redirects in general with the whole lists thing, like List of minigames articles needs more redirects. 17:16, 13 September 2015 (EDT)
 * What if I added an option to say "Redirect 'List of bugs in' to 'List of glitches in'"? RoyNSMBU.png Roy Koopa 17:20, 13 September 2015 (EDT)
 * Maybe? Maybe not. I don't know about this. 14:58, 14 September 2015 (EDT)
 * I don't think anyone would object if you created Bug as a redirect to Glitch although "bug" can mean other things. 15:08, 14 September 2015 (EDT)

I don't think there is a need to split the vote between "bugs and" and "and bugs". Just a simple support would suffice so determining outcomes would be simpler. 17:14, 13 September 2015 (EDT)
 * Do you mean have the voters post their opinion in the vote? RoyNSMBU.png Roy Koopa 17:15, 13 September 2015 (EDT)
 * I mean, you can merge your "bugs and" and "and bugs" choices into one support vote. They're pretty much the same thing, so there's no need to mull over the order of the elements. 17:23, 13 September 2015 (EDT)

@Walkazo Adding two syllables is not a mouthful imo. Six syllables (I counted) is though. Roy Koopa 17:28, 13 September 2015 (EDT)
 * You're not adding just syllables, but extra spaces and characters. It makes the title and links look more clunky. 18:11, 13 September 2015 (EDT)
 * ummmm...how does it make a link clunky? RoyNSMBU.png Roy Koopa 21:12, 13 September 2015 (EDT)
 * In the navigation templates mostly, so you mostly have to resort to piping there. And considering that it's not all that necessary, then I'm not sure if it's worth lengthening the name like that. 14:58, 14 September 2015 (EDT)