MarioWiki:Proposals/Archive/36

Make "List of Quotes by Character" Pages
MAKE CHARACTER QUOTE PAGES 12-0

I think we should make "List of Quotes by Character" pages (with "Character" being replaced by the name of a specific character). All the information will go onto a Writing Guideline eventually, but in the mantime, I'll just provide the main ideas here for reference...

These pages would only be for recurring characters, as oneshot characters already have complete quote lists on their parent games' pages. Discretion should also be used when determining what recurring characters should get quotes pages. If a character is major in one game, but only has a few lines in another game or two, there is no point giving them a quote page either: just give them a Quotes section with to the major appearance, as well as some choice quotes from that and all the quotes from the minor appearance. Similarly, if a character appears in many games, but they only have a couple lines in each one, just compile them into a small list that fits in a single Quotes section (like how no separate list pages are needed when there's only one or two glitches or beta elements). Character with quotes list pages should also get Quotes sections linking to the lists with, with a small sample of notable or characteristic (oft-repeated) quotes (in accordance with Empty Section Policy).

Each quote page will have a standardized header: " " (this will be added to Subpages Policy). The first section will be "General", and list quotes that appear in more than one appearance; if they only occur a couple times, the appearances can be listed (put these quotes at the bottom), but otherwise, just leave them. Try to put the most stereotypical quotes at the top (i.e. "Mama Mia" for Mario, "Help me, Mario!" for Peach, etc.), and remember that generic quotes are allowed here - just not things like screams ("ahhh"), nonsense and other stuff that sheds absolutely no light on the character ("hi", "okay", etc.); when in doubt, or when there's disagreement, take it to the talk page. After that section, go by genre/media type: Platformers first, since they usually have less quotes, and after that comes Sports, then Spinoffs (including all the random things), then the RPGs (since these are likely to be the big, hefty sections), then the "Non-game appearances", and finally, a Misc. section for commercials ("Mario, Mario, Mario ja nai!" - Peach, NSLU), websites, and other things like that.. Specific series may be given headers, and specific games too, if they produce a large amount of quotes (typically, games sections will be reserved for the RPGs; spinoffs and sports will at least get series headers often, I suspect); otherwise, just put what game each quote is from following the quote All sections should follow the "unsorted" quotes; use chronological order for everything at every level as much as possible. For the non-game appearances, sections can be given for the different shows, movies, publications, etc., or just list them "unsorted" like the games/series with few quotes.

Pretty sure that's everything. But again, the real proposal part's the first paragraph, so if that's all you read, you got the idea.

Proposer: (prompted by  and ) Deadline: August 18, 2013, 23:59 GMT

Support

 * 1) - Per me. I've had this idea for years and have been mulling it over in earnest since this proposal happened...
 * 2) Per Walkazo.
 * 3) Seems like a pretty solid proposal. I'll support it! It's a good idea to have a separate page for that because putting a large list on the parent article clutters the place up and takes up too much space which can be bad for people with low bandwidth.
 * 4) Huh, I always thought why didn't we have a separate page of quotes for characters like Mario. That should've been a standard years ago.
 * 5) It's a pain in the ass to look for specific quotes by a certain character by looking in the games. This proposal solves this problem.
 * 6) I was thinking about this myself and I feel it would be better to find quotes if one wanted to find one for a specific character. Per all.
 * 7) - Per Walkazo.  - Exactly Per Walkazo, I thought about this idea when I saw all those construction templates on all quotes pages for many and many years. But she seems that she organized this idea more than me.
 * 8) 100% agree with this, makes it easier to find certain quotes if you don't remember the game, but remember the character.
 * 9) Per proposal.
 * 10) Per Yoshi876.
 * 11) – Per all, I'm sure a lot of people have had this idea in the past.
 * 12) Perfextly understandable, and advantegeous.

Comments
Excuse me, but what about quotes like those? -
 * They should stay in the article. As for Mario characters, you should add the quotes into their page.
 * Cool, should we make a Collab on the forum? -

Disallow Usage of "Per All"
ALLOW USAGE OF PER ALL 0-14

My proposal is simple. It is the disallow of "Per All" sentence in proposal. Instead The voter will need a few seconds to specify the the users.

Example:

1. Users should atleast have sometime reading the proposal before voting. 2. Per User1 3. Some Users may just want to vote, so they be called a participant in proposals.

Instead of: 4. Per All He would say: 4. Per User1 and User3 He doesn't need to say Per User2, because User2 opinion is the same as User1

Proposer: (banned) Deadline: August 20, 2013, 23:59 GMT

Oppose

 * 1) I don't see a good reason for it to be gotten rid of, and it'd be incredibly annoying if lots of users contribute to a proposal each with their own reasons for (dis)agreeing with something and you having to go, Per: User 1, 2, 3, 4 etc. if you agree with all of them.
 * 2) &mdash; Per all... uh, I mean, this is completely unnecessary. Per the user above.
 * 3) per all.
 * 4) If the per all thing is removed, then people who's reason for agreeing/disagreeing with something is already mentioned, those people either can't vote or need to come up with a whole new reason. Agreeing with someone else just makes it easier.
 * 5) This seems to be a needless hassle to be specific on who you're perring when you per all.
 * 6) This is Ridiculous.
 * 7) - Per all. Having to list individuals is tedious and unnecessary, especially if lots of users make points you agree with. "Per all" isn't a cop-out, it's a perfectly valid vote.
 * 8) – The current system is fine, per all.
 * 9) Per all.
 * 10) - Per all.
 * 11) This is preposterous. And additionally, how are you going to deal with users who will persist using "Per all"? Send a Warning? Possibly ban them?
 * 12) Per all. (ha ha)
 * 13) Per Yoshi876, Iggy Koopa Jr...ahhh! Per all!
 * 14) All I can say is...uh...what was that... Oh! Per all!

Comments
Most votes are 'Pers' after all. - @Tail777 They can say Per someone -
 * True, but agreeing with many people isn't a bad thing.
 * Alright, I got it now. I'll withdraw the proposal by tomorrow. Keeping it wouldn't hurt -

Semi-Protect templates
DON'T SEMI-PROTECT THE TEMPLATES 2-6

Recently I have noticed that anons have done stupid things in the templates. Take [|this, for example]. We don't want anons putting fake things in the templates. Or [|what about that?] We don't want them putting DS games in the Wii template either. It may not happen a lot, but it still happens and we don't want it.

Proposer: Deadline: August 21, 2013, 23:59 GMT

Support

 * 1) Per my proposal. I still feel stupid I didn't do this earlier...
 * 2) Per proposal. It does happen and major templates that appear on many pages (such as templates listing games or Paper Mario templates, which appear on every item and recipe page) will change all those pages if the template gets vandalized.

Oppose

 * 1) - Per Megadardery in the comments. A couple bad edits is no reason for blanket protection of the templates: we're more likely to prevent good edits than bad edits from happening.
 * 2) Per Megadardery's comment.
 * 3) A vandal is not so enormous a problem.
 * 4) Template aren't usually targeted by vandals, so I don't think protection is needed.
 * 5) Most of the time the templates are used on so much pages that the mistakes could be quick noticed and reverted.
 * 6) – Per all.

Comments
I got this idea in my mind before, but it is unbelievable to protect all the templates. If we have to protect some, we would protect high usage/complicated templates, mostly like Formatting Templates, Media Templates and Internal Link Templates. However, Navigation Templates, and Infobox Templates should never be protected, because maybe anonymous user finds a problem and tries to fix it. Beside all that, it is still easy to revert any vandal edit, other than complicated templates, because a vandal may make an edit, and another user fix a code somewhere else in the template. So it become hard -but not impossible- to revert it. This is nothing like the last proposal of semi-protecting the Glitches pages, because a vandal may add unreal glitch, which doesn't become hard but almost impossible because we wouldn't know if it is real or not, that is the reason our admins protected them in the first place. -
 * I agree with Megadardery. The glitch lists were protected because they are often a target for vandalism and false info. It's true that anyone can add false information to templates as well, but it only happens once in a while (much less frequently than glitch pages), and are easy enough to revert. –

Make template
DON'T CREATE LICENCE NOR CATEGORY 7-10

Since there is really many 3D games.. and there is too much models on this wiki that is classed as a sprite. So I porpose we create a template for them. I'm not so good with copyrights, but here is an almost a copy from Proposer: Deadline: August 18, 2013, 23:59 GMT Extended: August 25, 2013, 23:59 GMT, September 1, 2013, 23:59 GMT

Create The License and the category

 * 1) They aren't sprites so a separate template for models seems like a good idea to me. Per proposal.
 * 2) If they're different, have different templates. Per proposal.
 * 3) Per all.
 * 4) Models aren't used very often, but it never hurts to have this template. I also disagree with YoshiKong. Creating this template will NOT be redundant and a waste of effort because these licensing templates also create a category for these images to go in. Lumping sprites and models in one category is messy, so this template can solve that problem too.
 * 5) I strongly agree with this. BTW, there is a clear-cut difference between pre-rendered sprites and 3d models.
 * 6) Per LGM
 * 7) Per proposal

Do not create the License nor the category

 * 1) – I have regarded this idea with distaste in the past, where it was first brought up as an idea on a wiki collaboration forum thread. The idea of acknowledging the two kinds within image galleries, I'm completely fine with, mainly because it's a notion which is only needing to be changed once per gallery page, to comply with our policy. However, the fact that y'all are hoping to introduce a copyright license which is already legally covered by, the only difference is a slight nameswap makes this template seem completely redundant, and a waste of effort to incorporate. And I don't agree that every user should be expected to correctly license every sprite/model which gets uploaded, and telling them off/continually correcting them would get excessively pedantic. It would be a lot more logical and save us all this unneeded hassle if we just modified our current sprite template to mention these fancy fashion models. And legally, we'd still be safe (which remember, is the whole point of driving licenses), not exactly keeping up with the latest rad words.
 * 2) Per YoshiKong, he has a valid point. The obvious differences between sprites and models are regardless if they can both be legally classified under the same license. Creating another license to acknowledge these differences is highly superfluous and modifying the existing licence to accompany both sprites and models is the more logical thing to do.
 * 3) - Per YoshiKong, the purpose of licenses is simply to be legally correct.
 * 4) Per all.
 * 5) Per all
 * 6) - I agree with YoshiKong and Tucayo.
 * 7) - Per all.
 * 8) Per all.
 * 9) Per YoshiKong.
 * 10) Per the above :P

Comments
What changes would you suggest to -
 * @YoshiKong: It's not the legal part I'm concerned about. Creating game-model also creates and automatically places a category that neatly places all game models into one page. We could manually add a game model category, but we still have this licensing thing that will lump models with sprites.
 * Or we could call the category "Sprites and Models" but that still requires a ton of work.
 * Yeah, Lot of unneeded work plus it would be still mess. A separate category plus a separate license is the best way to go (in my opinion) -

A writing guideline for Image Maps
WITHDRAWN BY PROPOSER


 * See here for the draft.

This writing guideline is meant to clear everything about Image Maps, when to create them, and basic rules. Everything of what are written in the draft are rules which are already known. A help page will be probably drafted, proposed and created as soon as possible. It will be created under the name Image Maps. Use the comments section below for comments and suggestions.

Proposer:  (lots of help from  appreciated) Deadline: September 13, 2013 23:59 GMT

Comments
"Image Maps are images where different parts of the image link to different pages[...]" Just rewrite that part to something like "Image Maps are images that include points that link to different pages" or something. Just remove the "where" part. It's better written like that. ^^'
 * While I don't like the part 'where', I don't think 'that include points that link to' is the best replacement
 * I don't think so either. I have trouble finding the precise term for things.
 * Would it also be a good idea to show a step-by-step process of creating the thing?
 * As I said: "A help page will be probably drafted, proposed and created as soon as possible." Once I have enough time, I will draft a help page

No APNG Files
REPLACE APNG FILES 12-1

My proposal is simple, getting rid of APNG files (animated PNG files) and replace them with GIF files.

Reasons:
 * The APNG does not show on all browsers (at least without a specific plugin).
 * The APNG editing is harder and request a special program to edit.
 * The APNGs takes more time loading than GIFs
 * Thumbnails of APNGs are not animated.
 * Replacing them with GIFs is easy, and won't loss quality.

Stuff that will get changed/deleted by the passing of this proposal: Proposer: Deadline: September 6, 2013 23:59 GMT

Support

 * 1) Per proposal
 * 2) Per proposal
 * 3) Per proposal.
 * 4) Well if it doesn't work for all browsers... obviously yeah.
 * 5) Per proposal.
 * 6) Per all.
 * 7) Until we get the technology available to make non-indexed animated pictures without some sort of special plugin or program, I vote per proposal.
 * 8) Most of the time, they're unnecessary because the different colors required to make it an animated GIF is usually more than enough to make a good, animated sprite. I don't even know why we have these in the first place when a good old-fashioned GIF image would do.
 * 9) Per voter number 8 (LGM)
 * 10) - Per all.
 * 11) - Per all.
 * 12) Per all

Oppose

 * 1) I don't see anything wrong with them, i think they are helpful sometimes.

Comments
@Randombob-omb4761 Like what?

The Template Shuffle
REVISE THE COLOURS AND GROUPINGS 10-0

Last year I drafted the colour-coding system for the templates, and now that we've had time to see it in action, I have some revisions, which can be seen in this chart here. Red shows which templates are changing, and I have a list of all the specific changes and the reasons why below the chart, but I'll try to summarize it here:


 * 1) Make spinoffs yellow, sports light green, and Wario purple. Right now, the major character pages have massive blocks of purple and aqua with a few reds, blues and teals, making it look more like a bowl of Skittles than a Mario-themed navigation nexus. I blame myself for somehow forgetting that spinoffs are so numerous, but making them yellow (and the sports green) will make the template blocks a lot more Marioish in colour, plus it'll brighten them up. And purple still works for Wario, so no problem on that end of the swap.
 * 2) Combine SSB with the crossovers. With split up into the separate games, the unique colouration's not necessary anymore, and the suitably similar aqua colour's freed up by the sports recolour, so it works out great.
 * 3) Simplify the Alternate Media and G&W stuff. In hindsight, there's no need to grandfather in the old G&W design: better to just update the template and give it the regular console colours. Similarly, differentiating between the two umbrella media types is unnecessary, and the darker of the two shades is too similar to the Mario games to effectively stand apart anyway.
 * 4) Combine SML with the overall Mario series. Again, this was an unnecessary split, although letting it keep its subseries designation is a good idea, and the old, orange Alt Media header colour fits the bill.

The new chart also has a couple extra subheader colours and a couple tweaked background colours, but that's all pretty minor. What isn't minor is the other half of the proposal, which is the establishment of a colour scheme for all the ex-subpage templates. Quick drafts can be seen here (or just scroll up from the colour chart): as you can see, I'm using the fancy SMB sprite setup that was originally made for the SMB template, and which was too cool to just throw away when the colour-coding system was brought in. I meant to make the subpage template use this design all along, but ran out of time for the first draft of MW:NAV, and only got back around to it now. Anyway, the templates all have the same header and background colours, but I gave different templates different banner colours to jazz things up (all of the colours are based on the backgrounds of SMB: the sky blue default, the underground/castle black, and the underwater blue, plus the one glitchy red background).

I really think these colour changes are an improvement over the first draft, and I think the subpages will look good with these template designs. And I hope you guys agree!

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

Support

 * 1) - Per me. Plus, since the backgrounds are all preset in MediaWiki:Common.css, it'll make the transition easier, and either way, I'll be happy to make all the colour changes myself: I love this kinda template work!
 * 2) - I fully agree. The Super Mario Bros theme is unique and fitting, and it sets us apart from other wikis that don't have cool nav template designs. The color palette is well thought out and makes perfect sense. Awesome work, Per Walkazo.
 * 3) – Per all.
 * 4) - I agree with the proposal (a.k.a Per proposal) I love the new ex-subpage design.
 * 5) Per all.
 * 6) – Well thought out! Per all. (In my opinion, the header color of the exsubpage one don't combine with the banner and background, but, as I said before, it's just my opinion.)
 * 7) Per all
 * 8) Per the above... again...
 * 9) Per proposal, great idea.
 * 10) Per proposal.

Comments
What if we need a sub-header, and we didn't find a color in this table? as the smallest example: Dr. Mario template
 * Then try making one up yourself (save the template and everything)and ask me or another admin to approve it and add it to the chart. Just like with footer colours (which is explained in the last paragraph of this section of MW:NAV). Worst-case scenario is that we might use a slightly different colour instead, but either way, the subheader will get made. -

While going trough some templates, I found, I think it should be merged with game templates, but what about & ?
 * That question's rather tangential to the goals of this proposal... But yeah, Morphs should be merged with the YI/YIDS templates. But as I keep saying on the forums, the Galaxy templates are fine the way they are, with their unique names and designs and whatnot, and I still think we should leave them be. -


 * As you may see, Ultra Koopa changed the color to Mario series' color. Is this design what you meant with 'unique designs'?
 * I meant the old designs (which I've since restored, since there should be discussion before stripping them of their unique and perfectly functional design - which was purposefully left unchanged when the original colour-coding proposal took effect last year). -

Links to YouTube Videos in Articles
DON'T HAVE LINKS TO YOUTUBE VIDEOS 1-14

I propose that we include links to YouTube videos within certain Super Mario Wiki articles, such as:


 * cheats on how to beat certain enemies
 * articles on how to get to secret places
 * how to get certain stars.

Any articles that fall into the categories listed above will include links to any videos that are related to the topic of that article.

I believe that this new feature should be added to Mario Wiki because it will make it easier for people to complete certain levels that they were not able to complete before due to confusion when reading written instructions.

Proposer: Deadline: September 13, 2013, 23:59 GMT

Support

 * 1) I support my proposal to add links to YouTube videos in articles concerning cheats and secrets in Mario Games.

Oppose

 * 1) This is a Mario Wiki, why should we put on Youtube videos to cheat? and we have refrences, no need for videos.
 * 2) This is a Mario Wiki, not a game walkthrough website.
 * 3) Per all
 * 4) - YouTube videos can already be linked to in References or External Links when appropriate. Embedding them would cause issues for certain readers, and scattering links in the articles would look sloppy.
 * 5) Per Icemario and Walkazo.
 * 6) Per Icemario and Walkazo
 * 7) Per Randombob-omb4761 & Icemario11, StrategyWiki is the best place for this idea to go in.
 * 8) Per all.
 * 9) Per all.
 * 10) references are enough. Besides, I think we can explain enough with words.
 * 11) As if people couldn't go to YouTube and look for the videos themselves.
 * 12) Per all.
 * 13) Per voters 1, 2, 4, 7, 10, and 11. So really, per all.
 * 14) – Per Walkazo.

Comments
@Walkazo, as best as I can understand from Gamerboy768, I don't think he meant to embedding them. He simply said "include links to YouTube videos.
 * Yeah, hence my "scattering links in the articles" bit, and the bit about how they're already included in the footnote area anyway. Vague "link to YouTube" ideas might be interpreted different ways (especially considering that we do link to YouTube already), so I deliberately covered all the bases in my vote. -

Having a spelling standard
DELETED BY PROPOSER

Currently, this wiki allows both American and British spellings, and whilst this is alright it lacks consistency. As seen here, the majority of the site's visitors are American or from American speaking countries. The spelling should reflect that, just like Naming does. American spelling is also predominantly used here so therefore it'd be easier to use American spelling over British spelling as there will be less of it to replace. Should this proposal pass, 'Changing British spellings and grammar conventions to American standards, and vice-versa (like changing "colour" to "color")' would need to be taken off the Warning Policy.

Use the comments section below for comments and suggestions.

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

Use only American spellings

 * 1) Per proposal.

Keep it how it is

 * 1) Why allow only one of them? I think it's perfectly okay to allow both. Words that differ are things like colour/color, realize/realise, etc. They're both easily recognizable by both American and English people alike. For this reason I don't see how "lacking consistency" is relevant.
 * 2) While advantaging the majority, the American users, British users (like me) will have trouble adapting to a spelling method they are not familiar with. Like a typical English Teacher from my school, we should accept both. And as a final point, have you noticed how many pages there is on this wiki? 13769 at the moment, and no doubt nearly all of them comtain a mix of British/American style. Although "less to replace", you still have a lot of work to do.
 * 3) –Although this would add consistency, people who are used to the British style would have trouble switching over, and it would be a hassle to go and replace everything. Plus, it would make people feel that the wiki is American-centered (although it is true that the majority of traffic here is American), and defeat the purpose of the "fist come first serve" rule.
 * 4) - It's easier for users to be able to use the spelling, grammar and punctuation their familiar with: why force a large chunk of us to have to stop and try to remember every little thing we're supposedly not supposed to do according to rules we were never taught, when everyone can have just as easy a time adding content to the wiki? It's way more fair this way, it reflects that there is no right or wrong way when it comes to different dialects, and it's not like we can't understand each others' writing conventions, so it doesn't harm the wiki. In fact, it's quite the opposite: having the occasional British/Canadian/Australian/etc. spellings/etc. mixed in with the American majority adds a nice international feel - why take that away? The article naming policy is mainly based on maximizing Google search traffic so we have less leeway, but nitty-gritty details like spelling? Just let it be.

Comments
@Iggy. And? It may contain a lot of English words, but I'd be up for it.
 * I do not think anyone would have the time, or even bother to change every single "s" into a "z" a hundread times, in every single article. Like Drift said, this wiki is not American centered, although having quite a few American users.
 * You underestimate me, and this isn't about making it American centred, it's about having consistency throughout the wiki.
 * This Wiki would remain consistent, even with different spelling styles. And: "You underestimate me", Yoshi876, well, I don't. You overestimate yourself. If ever this proposal passes, I don't think you would start with A, and go down to Z finding there little details that are in such subtle camouflage in the article.
 * No it wouldn't be consistent, as they would be no clear spelling convention and it'd be simple input the article into Microsoft Word use Find and it'd be simple to find the words that need to be changed.
 * Well, technically, it's not a spelling mistake. This is an international English wiki, not only American.
 * That's why I said find, rather than using Spellcheck.

Stop Considering Amps as Chain Chomps
AMPS ARE NOT CHAIN CHOMPS 12-0

I have done a fair amount of research on this, I've discussed this with a handful of users, and I've come to the conclusion that there's really no reason for Amps to be considered Chain Chomps. I believe everything started when it was stated that Amps were mistakenly placed in the "Chain Chomp" category of enemies in the strategy guide of New Super Mario Bros.. After that, a user named RedStar wrote that Amps were called Electro-Chomps in the New Super Mario Bros. Wii guide. As far as I can tell, this has been the entire basis for considered Amps as Chain Chomps, since, after this name was added, everyone accepted that Amps are Chain Chomps as if it was fact. If you noticed, though, there was no source for it, and he eliminated the mention of Amp being wrongly placed in the NSMB guide. What's even more interesting, though, is that Redstar fully admitted to that being nothing more than a joke, meaning that "Electro-Chomp" is 100% false.

Heck, "Electro-Chomp" is only mentioned on that very article: outside of the Amp article, no other article even mentions that, and outside of this wiki, there is no mention of "Electro-Chomp" outside of a YouTube video for an unrelated matter and a litter of usernames. There's really no other sources that point to them being connected. Thus, the only real connection Amps and Chain Chomps have are their appearance. However, the very vague description "black sphere" isn't enough to say that the two are part of the same species. So, now that I've essentially proven that Amps and Chain Chomps have very few points in common, should we really keep considering Amps as a sub-species of Chain Chomps?

Proposer: Deadline: September 24, 2013, 23:59 GMT

Amps are not Chain Chomps

 * 1) I support my proposal.
 * 2) I blinked when I first saw that Bowser amps are listed under "chomps" and "chain chomps". They bear little to no relation to each other, too, and I decided to talk about it in Bowser Amp's talk page. Then, I discovered that since Bowser amp is an amp, and amps are supposedly "chomps", then Bowser amps are chomps and thus, Chain Chomps. That's what made me blink. Again, the only thing that calls these amps "chomps" is Prima, which also has a knack for misnaming enemies. That being said, it's easier to say what it's not than what it is, too, so if we're unsure about the status of the Amp, we assume that it's not a chomp, chain chomp, or whatever. My sister Baby Luigi insists that I'm missing the point, that I keep confusing "Chain Chomp" with "Chomp", but she misses my broader point that amps aren't chomps at all and, therefore, should not be categorized as "chain chomps". I might sound all over the place, but my point in the talk page is that the placement of amps in "chomps"/"chain chomps" is incorrect mainly because of a lack of ingame description and frank official sources. Adding to that the whole thing is joke only reinforces my point.
 * 3)  Per all.
 * 4) Per LGM
 * 5) I agreed with it on the forums, I agree with it here.
 * 6) Per all. Amps = Chain Chomps? really? ._.
 * 7) Per all.
 * 8) Yeah, per all.
 * 9) Per all.
 * 10) Ditto. Lol though.
 * 11) Per all.
 * 12) Amps have almost no similarities to Chain Chomps. Per all.

Comments
I think this is small enough to be a TPP
 * It's a change that's gonna require editing many articles. Doesn't that make it worthy of a full-fledged proposal?
 * Updating links and lists and whatnot isn't the same thing as making major changes to a swathe of articles. This is a pretty specific topic, but it does affect a couple kinds of Amps, I suppose, so while a TPP would have been okay, a full Proposal isn't exactly wrong, either. -

Make a template encouraging non-users that have made 20 or more edits to make an account
DO NOT CREATE THE TEMPLATE 4-15

The Idea was very good. It was thrown away and forgotten just because the automatic process won't work. But we can issue the template manually. Thankfully, User:NewSMBU created a draft, with minor changes, I created another draft. While this proposal is going, changes can be done to the draft.

Proposer: Deadline: September 25, 2013 23:59 GMT

Support

 * 1) Per old proposal
 * 2) Will help get more contributive members, per proposal.
 * 3) Great idea, per all.
 * 4) Per all.

Oppose

 * 1) – This proposal would require somebody or several people to keep track of the changes that all anonymous editors make, which is not feasible. It is too likely to overwhelm one person that even attempts it or lead to coordination problems with multiple people that attempt it. If the process were able to be automated and could be decently implemented by having a bot add the template, that would be good to consider, but I don't think this idea is sustainable in the long-term as suggested by this proposal.
 * 2) - I wasn't keen on the idea last time, but I didn't vote because it was impossible either way. Anyway, if someone wants to register, they'd register - I highly doubt a boilerplate message would change their mind either way. If anything, they might find it irritating to be pestered like that when they just want to be anonymous for one reason or another. Plus, while automation could create a one-time message like the current Welcome setup (afaik), manually making talk pages will result in stuff lying around dormant long after the anon's joined or moved on, which is simply a waste of space.
 * 3)  - Generic nag messages, automated or not, are horripilating and a waste of time for everyone involved.
 * 4) - If a user is going to create an account, they'll do so, and a useless template won't stop them from it. Per all.
 * 5) Per all.
 * 6) - I think a little incentive to encourage anons to create an account is good, and what we have now is probably enough. Per Walkazo on the "waste of space" part.
 * 7) I've hated this idea the first time it came up and my opinions haven't changed on the matter since. Anons should be able to edit as they please with out being pestered into creating an account.
 * 8) Per Glowsquid
 * 9) Per all.
 * 10) Per Walkazo.
 * 11) I think this template will actually discourage users. If there are anons that are being super active and helpful, then it's better to thank them formally to encourage their signing up than to give a less caring, automated template.
 * 12) Per SMB and Walkazo.
 * 13) Per all.
 * 14) Per SMB and Glowsquid.
 * 15) Like said on the old proposal, it is not feasible. Besides, I find it a bad idea, with an attempt of making publivity to the wiki. If a user is editing a wiki anonymously, he can decide on his own if he wants to really join this place, or not to.

Correct use of the term "Beta"
RENAME ALL BETA ELEMENTS PAGES TO PRE-RELEASE ELEMENTS 17-1

One thing has been irking me a lot and that is the use of "Beta Elements" as the name of the page that has info about stuff not seen in the game. The term "beta" is used as (usually) the last release in the software release life cycle and that is where things start to get difficult.

It's wrong to call something from alpha or after beta stage as being something from the beta development stage. The problem being that it's impossible to know what stage it is from. Sometimes it can be stuff that was planned but not put in, for example the SSBB page has info about Sakurai saying that Villager was planned to be in the game. There's no evidence about this anywhere in the games files or magazine screenshots.

My suggestion is changing the "Beta Elements" name to something like "Pre-release concepts" I'm aware that many other wiki(a)s and sites use the term "beta", but I think it should be stopped ASAP in order to prevent people from spreading misinformation.

Proposer: Deadline: September 29, 2013, 23:59 GMT.

Support

 * 1) Per proposal.
 * 2) Fully agree, the term "beta" has been used incorrectly for the longest, and someone needs to put their foot down to stop this. Per proposal.
 * 3) I too agree. It's lead many users to incorrectly use "beta". Per proposal.
 * 4) per all
 * 5) Per proposal, though I'd call it Pre-Release Elements.
 * 6) "Alpha" and "beta" are two different stages, and they're not all the stages when a game is developed. People are accustomed to use "beta" to stand for "pre-release" just as how some are accustomed to use "aggravate" to stand for "irritate", so this can be irritating to those that aggravate the situation by having more and more wikis say the wrong thing. Alpha is an unstable stage where the software is first tested, while beta is feature complete and closer to the final stage, except with many bugs and issues. It is difficult to determine which is alpha and which is beta just from screenshots and words alone, so muddling both alpha and beta together isn't a good idea. We need a wider term. I think "pre-release elements" works just fine.
 * 7) Per all.
 * 8) This is actually something that was on he back on my mind, but which I never went around proposing due to being unable to find a decently short replacement. Seeing "beta" used to refer to any stage of development is rather irritating.
 * 9) Per all
 * 10) – Per all.
 * 11) Per all.
 * 12) Per all
 * 13) Per all.
 * 14) Per all. I would go with "Pre-release elements".
 * 15) Pre-release elements seems goofy to me, and I would like something different. Per proposal and SYB.
 * 16) I think "unused elements" would be better, if we do this.
 * 1) I think "unused elements" would be better, if we do this.

Oppose

 * 1) "Beta Elements" seems pretty helpful to me, I wouldn't call it "Alpha Elements" and i don't really understand ""Pre-release concepts".

Comments
@Randombob-omb4761 Calling them "Alpha elements" is just as bad as saying "Beta elements". "Pre-release concepts" are simply what a game was earlier in its development.
 * "Pre-release concept" is a self-explanatory name. "Pre-release" is "before release" and "concept" is "idea". Not hard to grasp. I wouldn't call it "concept" though, because the word implies that they were simply ideas that got scrapped. I think we need something more concrete than "concept".
 * The new name is something to defnitely talk about, I'm fine with "Pre-release elements" myself. Also, Lefty was able to sum up my thoughts way better in her support comment, I suck at writing stuff :p PPLToast (talk)


 * "Pre-release elements", as in "List of Super Mario World pre-release elements" sounds good to me. 18:27, 23 September 2013 (EDT)


 * I wouldn't be a help in choosing a name, but is unused information on the disc counts as "pre-release elements"?
 * I'd say yes. Since it's something conceived and made, but not ultimately not used, then it's most likely a scrapped element.


 * Lefty is Right. 17:11, 24 September 2013 (EDT)

I think "Unused elements" would be better, it's a lot more simple. -- 18:19, 26 September 2013 (EDT)


 * Not all are unused, some just are old, which were planned but got cancelled.-- 16:55, 28 September 2013 (EDT)
 * I think that fits the definition of "Unused".

A writing guideline for Image Maps
CREATE THE POLICY PAGE 9-3


 * see here for the draft.

This Writing Guideline is meant to clear thing of when and how an Image Map page should be created. It will be created under the name Image Maps. These rules only apply to real articles.

All information are present in the draft, description is present here:

The Map Images must be a map sprite from the game, screenshot, or an official map artwork because it makes the Image Map looks professional. Fan-made will make the Image Map looks fake, unofficial nor professional

Templates are only for real articles, no templates for Policy pages, Help pages, or Userpages.. However, coding can go in any other page.

Image Maps are meant only for locations, or levels. It is not good to have an Image map for characters, even if the artwork was official, it won't look neat.

Image Maps are meant to help with navigation. If image is less than 8 links, it could be embedded in the page with caption description the links. Example on the right.

The Image Map's any dimension must not exceed 400 pixels, and the other one must not exceed 200 pixels. The Image Map's width in the template must never exceed 300 pixels. I specified the sizes depending on medium sized screens, so it does not look very small, or very big. Reason includes that if maps were larger than that then the page would look very crowded.

If the map isn't going to be put into the Worldbox template, then the map should be classed as a  and aligned to the right. However, If the map is only going to be put in the Worldbox template, it must be classed as  and it must be aligned in the center. Otherwise a variable must be declared; so if it is set to ,it would be aligned in the center and it would be classed as. And if it is not set, it would be classed as a  and it would be aligned to the right.

In other word, templates like are put inside the  and never outside, so it is classed as   and it is aligned in the center, so it looks centered and without borders in the template. Templates like are put outsise the Worldbox template and never inside, so it is classed as   and aligned to the right. However templates like are put both inside and outside, so there is a variable defining if it would be put in the Worldbox template, or would be put outside.

The template must only be put where it links to (i.e If the template only links to and, it must never be put on ). That's because it is unneeded on an unrelated page.

If the article is about a subject that only appeared in the Image Map's game, the template should be put under the info-box. Otherwise the template should be put as the first line in the game's section on the article.

Explaining: links to X-Naut Fortress and The Moon.. Since X-Naut Fortress only appeared in Paper Mario: The Thousand-Year Door, the template is put under the infobox, However The Moon appeared in multiple games, so the template is put in the game's section.

For the Platformer games: in the Worlds pages, the template should be put in the  parameter of the  template (using the code  ). Reason includes it unneeded to crowd the page with a template, which can be put inside the infobox template.

Last three sections describe basics of creating the template.

Use the comments section below for comments and suggestions.

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

Support

 * 1) Per proposal. Should help those new to image maps as well.
 * 2) per proposal... I don't see anything bad about this, and it'd be helpful to a lot of people.
 * 3) Per all
 * 4) ImageMaps will come in the future (until something renders it deprecated), and once more people know how to do it, the better. Knowledge is power.
 * 5) Per all.
 * 6) I think it's a good idea, per all.
 * 7) Per all.
 * 8) Per LeftyGreenMario.
 * 1) Per LeftyGreenMario.

Oppose

 * 1) I personally find it unneeded.
 * 2) I think it is fine the way it is, and we don't need to change anything.
 * 3) Per Mario7.

Comments
@Iggy Koopa Jr Why? Image maps are kinda complicated, they need several rules, so it does not look messy when created.

It is because not many image maps are made on this wiki(because unneeded), and not everyone knows how to make one. I have myself not stumbled on a messy Map, so I think rules for something already done well is unneeded.


 * The reason of not too many ImageMaps are made on wiki mostly because people don't know how to make one, hopefully this writing guideline will put standards for making the Imagemap, that's why I made it in the first place, With many games (specially 3DS games) new today, the ImageMaps will help a lot in navigation. And I can guess that's lot of ImageMaps are coming in near future.

Pokemon, Assist Trophies, and the SSB Templates
DO NOTHING 3-0-9

As of now, we have three templates for the three games in the Super Smash Bros. series: },, and. All of these templates have various sections for their aspects, whether they'd be items, non-playable characters, enemies, etc. However, there's always been one peculiarity that's always bothered me: none of the Poké Ball Pokémon, nor any of the Assist Trophy characters, are listed in any of templates. We've made it a point of (trying to) list all of the stage hazard characters in the templates, but everything from Andross to Weavile has simply been absent, which seems rather inconsistent. Is there really any reason for keeping them out of the templates? Yes, just about all of the Pokémon/Assist Trophies are merged into articles, but that's why we have redirects (which is also aided by the advent of anchors), and most, if not all, of the stage hazards have also been merged. Really, the only question should be whether to give them separate sections in the template or to stick them in the NPC section.

Proposer: Deadline: October 3, 2013, 23:59 GMT

Add a New "Pokémon"/"Assist Trophy" Section to the Appropriate Templates

 * 1) The NPC section would probably get too cramped if we started adding the Pokémon and the Assist Trophies.
 * 2) Seems weird that this information is not figured anywhere.
 * 3) Per proposal and all

Do Nothing

 * 1) - Nav templates are for navigating between pages: tonnes and tonnes of links to the same list page (or two) will just clutter up the templates, making them look bad and hindering navigation to the other, separate pages. Just add one link to the Pokemon list page on the templates that don't have it yet (which is an oversight and doesn't require a proposal in itself), and folks can use the TOC to navigate the lists from there.
 * 2) - Per Walkazo. A template linking to the same page in 90% of its entries is not exactly useful. And, as she said, adding a link to said page wouldn't even require a proposal.
 * 3) Per Tucayo
 * 4) Per my comment.
 * 5) Per Walkazo.
 * 6) - Per Walkazo.
 * 7) - Per Walkazo.
 * 8) Per Walkazo.
 * 9) Per Walkazo

Comments
Personally, I prefer no listing Pokémons, or Assist Trophies, I feel it better when it just links to Assist Trophy and Pokémon articles. Instead of many unneeded links, just for listing. The articles has lists. And beside, I feel this does not worth a Proposal, not even a TPP.. I would stick with a, If I were you.
 * The proposal's already up, might as well roll with it. Besides, which talk page would I post it on, the Pokemon or the Assist Trophy? Also, how exactly are they unneeded?
 * You would put that on . Back with the discussing, I said unneeded because they would crowd the template with unnecessary list, while there is already an link for Assist Trophy and Pokémon, and those articles contains those lists already.
 * But my template is covering multiple templates (SSB, SSBM, SSBB). Yes, Assist Trophy isn't relevant for the first two, but the Pokemon are. Why does that even matter? Besides, there's already plenty of entries there. Why not the Assist Trophies and the Pokemon charcters? Let me put it this why: why should all the characters that appeared as obstacles (if even that) for a single stage be placed in a template, but characters that can show up no matter what stage you on and contribute greatly to the fight (Goldeen aside) be simply disregarded?

Make Most Maintenance Categories Hidden
DON'T HIDE CATEGORIES 2-6

An idea which was willing on my mind from long time ago. The Maintenance categories should be hidden from the categories bar on the bottom of each article. The categories bar on each article is only for main categories. Some readers may just want to navigate through the categories without contributing. And for any user that does want to see them, he could just navigate to his Preferences, in Appearance tab, down at Advanced options. Check "Show hidden categories".

List: (marked with * may need some discussion)
 * Category:Articles under construction
 * Category:Articles with conjectural titles
 * Category:Articles with long Trivia sections
 * Category:Pages with broken file links & Category:Articles with broken file links
 * Category:Citation needed
 * Category:Disambiguation -- It looks neater for Disamb pages to appear without categories
 * Category:Image requested
 * Category:Quality requested
 * Category:Merge Requested & Category:Split Requested
 * Category:Pages with media files
 * Category:Protection Change Requested
 * Category:Requested for Deletion* & Category:To be deleted* & Category:Talk to be deleted*
 * Category:Rewrite Requested & Category:Rewrite and Expansion Requested
 * Category:Stubs & Category:Section Stubs & Category:New Stubs

Proposer: Deadline: October, 7 2013 23:59 GMT

Support

 * 1) -- Per Proposal, the categories bar should only contain real-articles related categories.
 * 2) Per Dardery.

Oppose

 * 1) I think that these should be easily visible so that editors can quickly see that changes need to be made and visitors can see what the problem is, so they don't get a bad impression of this wiki
 * 2) And for the ones that are willing to contribute, but does not have an account? What do we do about them?
 * 3) Per Mario7.
 * 4) Per Iggy, I highly doubt IPs are going to look in Wiki Maintenance, so it can make it harder to have some valid contributions.
 * 5) The reason the notice template generates categories is that, y'know, so it's a convenient way to see all the articles that have a similar problem in that category. I don't see any other valid point other than it clutters the category page and it is unrelated. If such article HAS a category that calls for improvement, that actually makes the category related to the article. If we hid the categories, it would make it much more of a hassle to navigate around, making sure we have to always click on Wiki Maintenance instead of going on the bottom of the page and searching if there's any more. There's a reason no other wikis I know don't hide their categories: it's hiding a problem on the article and making them hidden would make it harder for editors to search and correct them. And there's editors who would like to look for random articles to fix. Overall, I don't see any decent advantages of hiding this, and it would cause problems for editors looking for an article for a similar problem.
 * 6) Per Iggy and Baby Luigi.

Comments
So, exactly why do we need to hide these categories? And wouldn't unchecking the hide option show categories that are hidden in the first place, adding more clutter?
 * So the categories bar doesn't get crowded with categories unrelated to the subject itself.. as for the second question, I don't think I quite understand it.
 * My question is that are there already hidden categories in the first place? You know, I'd like to know the amount of categories that are already hidden.
 * Nope! There are no hidden categories yet! any hidden category will automatically go in Category:Hidden categories which I will create as soon this proposal pass.

@Mario7 The problem can be easily seen by looking on the Notice Template which is mostly on the top of any page. And Editor can see them by checking the 'Show hidden Categories' option.

Like I said, there are also anons that are willing to contribute the wiki. Keep the hidden categories visible for them.


 * Most-to-All Maintenance categories can be seen in Maintenance, I purpose hiding them so the categories bar doesn't get crowded with them.. Taking Trick as an example, and you will see that there is 2 categories which aren't helpful in navigation at all. Look at List of Mario references on the Web and you would see that 3/5 categories are not related to the article just Maintenance. Imagine if this article was requested to be protected (which what I would just about to do, before Walkazo done it) and has media files (which what I will do soon), and it need a reference or two. That would mean that 6/8 of categories which will be hidden from normal view.
 * So? Anyone can ignore them. You don't need to hide them, especially when that means anons cannot navigate with the bar, as they don't have a preference page.


 * ِAgain, all Maintenance categories are found in Maintenance and Category:MarioWiki Maintenance