MarioWiki:Proposals/Archive/55

All past proposals are archived here. This page is protected to preserve the discussions as they were.

OK Boomer (Move Boomer (Super Paper Mario) to Boomer (Pixl)?)

withdrawn by the proprietor (see comment)
Interestingly, there are two different identifiers for these two Super Paper Mario pixls: Boomer (Super Paper Mario) and Slim (Pixl). Since there is an inconsistency, it would make sense for both pixls to share the same identifier. Since Slim (Flopside) prevents the use of using (Super Paper Mario), it would make sense to move Boomer (Super Paper Mario) to Boomer (Pixl). This further makes more sense as naming policy suggests using a "Thing" identifier (pixl) over a game identifier. Such a page move would be fairly innocuous.

However, this would create a minor secondary discrepancy with the other two Boomer pages, both of which are using game identifiers. Should both of these pages be moved to be more specific to their pages, such as Boomer (boss) and Boomer (bear), as well as Boomer (Pixl)?

Proposer: Trig Jegman (talk)
Deadline: Jan 6, 2020; 23:59 GMT
Date withdrawn: December 31, 2019, 01:56 GMT

Move Boomer (Super Paper Mario) to Boomer (Pixl) only

1. Trig Jegman (talk) - Well I made it, but I don't necessarily think it would be a big deal if the other two variants remained the same. - 23:01, December 29, 2019 (EST)

Move all three Boomer pages to be more specific

While I suggest Boomer (boss) and Boomer (bear), these could be discussed further

Do nothing

1. Toadette the Achiever (talk) See here, here, and here for a full explanation.

Comments

This further makes more sense as naming policy suggests using a "Thing" identifier (pixl) over a game identifier.

The "thing" in this case is character. If character can't be used, then you move to #2, which is game. Slim is forced to go to #4 since game can't be used, while Boomer can safely stay at #2 and use game. That the two Pixls end up in different places is simply a result of them needing to differentiate from different things (Slim (Flopside) forces it). I understand it can be considered annoying, but whether or not they match is really neither here nor there - they are each a different case with different needs. As you said, if you do the move then these three links are inconsistent since one wouldn't use game (and there is no reason for it not to use game since they are all from different games). So basically you want to open up the character identifier to get more specific before moving to game (as it used to be). This gets into its own weird problems of what should be used, and having some awkward identifiers. I think going to the game name sooner avoids that awkwardness in the most objective way possible. If you tally up the amount of "problems" with each system, I'll take the current Pixl "mismatch" and a bunch of objective game identifiers versus a ton of human/flower/whatever identifiers. The Slim (Pixl) case is a direct result of Nintendo using the same character name twice within one game and rightfully should be the one awkward situation because that is a confusing thing to do. Opening up custom character identifiers before moving to game creates awkward cases which are completely the wiki's doing, and we should try keep our hands clean and minimize any impact. No matter what system we land on there will be weird cases to deal with. I think the current system minimizes the damage and is the "least bad" option, and I don't want to keep changing things around. So I'll veto --Steve (talk) 20:56, December 30, 2019 (EST)

Compile Play Nintendo puzzle activities in a single page

MERGE PUZZLES 7-0
I don't think the Play Nintendo jigsaw puzzles, such as this one, this one and this one, deserve their own pages as much as the other Play Nintendo activities do. The reason skill quizzes and personality quizzes need their own pages is to neatly list all the correct answers for each, in a similar fashion to how we handle the quizzes from the Paper Mario games. However, those jigsaw puzzles all have the exact same "gameplay" where you choose a difficulty of 8, 18 or 50 pieces and then use them to build the base picture; the only difference is the picture you have to build, but this isn't a strong enough reason to keep these puzzles on separate pages. This can be easily managed in a table that contains the preview and description used on the website, what the completed puzzle looks like, and a link to the actual puzzle.

I therefore propose that we make a list of Play Nintendo puzzles where we compile every single one of them, with the following layout for the table:

Preview	Completed puzzle	Play Nintendo description	Web page name	Link
	[pic]	A (puzzle) piece of art Put together the puzzle pieces to get a closer look at the Mushroom Kingdom. You can choose between Easy (8 pieces), Medium (18 pieces), or Hard (50 pieces!). Good luck!	Nintendo Online Jigsaw Puzzle Game	[1]

A few notes:

1. The website description takes priority over the tab title of the puzzle because the words used in it also serve as search keys on Play Nintendo, whereas the tab title seems more like a simple placeholder typed out by the publisher (and cannot be used to search the puzzle). We'll offer a direct link anyways, so the reader won't have to personally go type it out in the search bar, but this decision is taken to more or less highlight the importance of the description on the website.
2. That one Mario jigsaw puzzle on the Nintendo Kids Club website (Play Nintendo's European counterpart) won't be affected by the proposal, as it is considered in relation to other games on the website (Luigi's Word Jumble, Captain Toad's Dungeon Dash! etc.)

If the proposal passes, any puzzles that already have their own pages will be merged in a List of Play Nintendo puzzles. I was planning on organizing the other activities similarly, since the current list on the Play Nintendo page doesn't have much of a rhyme or reason. If the proposal is unsuccessful, then the jigsaw puzzles will continue to have their own pages like the rest of the Play Nintendo activities.

Proposer: Bye Guy (talk)
Deadline: January 16, 2020, 05:27 GMT

Support

1. Bye Guy (talk) per proposal
2. Obsessive Mario Fan (talk) - Since all the puzzles are the same but with different pictures and text, this works best. Also, each puzzle has a unique message when completed, so that should be included too.
3. Power Flotzo (talk) Per Obsessive Mario Fan.
4. TheDarkStar (talk) - Per all.
5. Waluigi Time (talk) Per all.
6. Mister Wu (talk) Agreed - I support the idea of using less space and simplifying navigation without losing the actually relevant information
7. Jazama (talk) Per all.

Remove tense

DELETE TEMPLATE 17-0
The Template:Tense has been around for almost 10 years, and despite this, it is almost never used. Tense is so infrequently used that while discussing it with long time wiki editors, they didn't believe it was a thing. Tense serves virtually no purpose anymore, as changing word tense is generally very easy to do, especially with tools like Find/Find Next being commonplace. If a situation is truly dire, it doesn't make sense to not simply use {{Rewrite}} over Tense, since a majority of people don't either know it exists and cannot find the section in which it is documented, or people don't suspect a tense issue because they are so infrequent. Because of this, I propose that the tense template is deleted.

Proposer: Trig Jegman (talk)

Deadline: Feb 18, 2020, 23:59 GMT

Support (Delete the template)

1. Trig Jegman (talk) per proposal.
2. Doc von Schmeltwick (talk) Ye I had no idea it was a thing, but it's pretty much pointless. Per proposal.
3. Alex95 (talk) - Yeah, that makes sense to me.
4. TheDarkStar (talk) - It's only used on one page, and it doesn't even have a dedicated subcategory, so I'm for deleting this.
5. 7feetunder (talk) We don't need sub-templates for every specific way an article can be badly written. Just use the "reason" parameter.
6. Scrooge200 (talk) Per all.
7. Mario jc (talk) Per proposal.
8. Sdman213 (talk) Per all.
9. Obsessive Mario Fan (talk) This template is redundant. Per all.
10. Niiue (talk) Per all.
11. Toadette the Achiever (talk) Practically useless. It's an issue that's extremely easy to fix.
12. TheFlameChomp (talk) Per all.
13. Yoshi the SSM (talk) Per all.
14. Mister Wu (talk) If it’s redundant and almost unused, we can get rid of it.
15. FanOfYoshi (talk) As another proposal by Super Radio (or is it Results May Vary), this is redundant.
16. Supermariofan67 (talk) Per all.
17. White Lightning (talk) If it is hardly used, it must be removed.

Comments

Actually, it's on Mario & Sonic at the Olympic Games Tokyo 2020, too. But I still don't see a use for it. Scrooge200 (talk) 00:31, February 12, 2020 (EST)

New Template:Gamma Image

create template 6-0
An interesting oddity that I and few other users have noticed while dealing with images is a very interesting type of metadata called Gamma Brightening. In short, what gamma brightening does is change the way the colors of an image are displayed. This is generally very rare, but it is important as the differences between images is severely drastic. After some internal discussion, most notably with Steve, the unspoken policy course of action is to not optimize images with gamma brightening, and leave that metadata on the image if it is the way the source image provides the picture.

The purpose of the proposal is to make this unspoken policy a spoken policy. People should know when an image has a special property and should be treated differently.

The following template, {{Gamma-Brightening}}, would be placed on the documented images with gamma brightening:

This image contains gamma brightening, and should not be optimized.

<div class="notice-template" style="display:flex;text-align:center;background:#BF5FFF;margin:0.675em 2% 1.75em;padding:0 1em;border:2px solid black;color:black"> '''This image contains ''[[User:Trig Jegman#What's Gamma Brightening?|gamma brightening]]'', and should not be optimized.''' </div><includeonly>[[Category:Gamma Image]]</includeonly><noinclude>

Such images seen thus far is:

• Hammer Bro-NSMBU.png
• File:MP8 Hammer Bro Artwork.png
• File:NSMBDS Goomba Artwork.png
• File:BulletBillWii.png
• File:NSMBDS Buzzy Beetle Artwork.png
• File:NSMBW Mario Holding Green Shell Artwork.png
• File:NSMBW Mario Jumping Artwork.png
• File:Blueboostblock.png

It would also be suggested, but not required, to create a MarioWiki page discussing gamma brightening over using a section on my user page.

Comparison image:

Proposer: Trig Jegman (talk)

Deadline: Feb 19, 2020, 23:59 GMT

Support (Create template)

1. Trig Jegman (talk) Per proposal
2. Bye Guy (talk) per proposal
3. TheDarkStar (talk) - Per proposal.
4. Results May Vary (talk) - It might be odd seeing this on many image pages, but otherwise it is a reasonable decision. We want to preserve the original nature of the image as much we can. Although personally I prefer the Gamma brightness removed for the Hammer Bro pic but just in this case, and it's only my opinion.
5. mister Wu (talk) I’m still wondering if removing metadata doesn’t create more problems than it solves (it’s often a few bytes of data where the IDAT chunk is orders of magnitude bigger), but since current optimization software removes them and since the gAMA chunk definitely must not be removed, it’s better to add this template.
6. FanOfYoshi (talk) Per all.

Comments

I mentioned you could simply say this information in the aboutfile template. Because of that, I don't see a need for this template, as it would only really apply to a handfull of images. But I'll remain neutral, as I'm not directly opposed to it, either. 11:21, February 12, 2020 (EST)

Not sure what to think of this yet, but I think the purple should be a lighter color to make the text more readable. --DeepFriedCabbage 14:46, February 13, 2020 (EST)

I can easily change the color to be more reader-friendly. I will hunt for a similar purple that's easier to read. Trig - 16:42, February 13, 2020 (EST)

Thanks! --DeepFriedCabbage 20:07, February 13, 2020 (EST)

is #cb7eff or #debffb more appropriate?

demonstration; original

demonstration; option 1

demonstration; option 2

I personally enjoy the original or lean towards the darker side of purple but it's up to the community. (I've never been great with color) Trig - 17:21, February 14, 2020 (EST)

I'd go with option 1. --DeepFriedCabbage 15:05, February 19, 2020 (EST)

It seems that "original" does not necessarily equal "accurate" in all cases. Take File:NSMBU Luigi Jumping Artwork.png for example. Note that the optimized version contains a darker green and the gamma ("original") version contains a lighter green. Then look at File:NSMBU FourCharacters.png from the same game, where the opposite is true. Therefore, it seems that there are some images where gamma correction produces an accurate image, and other images where gamma correction produces an inaccurate image. Given this, I think we can't say that gamma should always or never be removed, since it depends on the image. How do we determine when the original is accurate, and when the optimized version is accurate? A side note: it is possible to keep certain metadata, such as the gamma chunk or embedded ICC profiles, while still optimizing the image, such as by passing the --keepchunks=iCCP,gAMA,cHRM option to zopflipng or the -kiCCP,gAMA,cHRM option to pngout. See this page for further explanation. I tested it on File:NSMBDS Goomba Artwork.png. Note: preserving only the iCCP chunk has worked for every image I've tested so far, but theoretically there may be older images that rely on the gAMA or cHRM chunks. Since these legacy chunks are very small, it's probably worth preserving them also. Maybe we could include this information in the policy, so that we can optimize the images without removing gamma.--Super Mario Fan ⁶⁷ (T•C•S) 00:01, February 16, 2020 (EST)

We could modify the template/proposed policy to consider this. Maybe something like:

This image contains gamma brightening, and should not be optimized without preserving iCCP metadata.

--Super Mario Fan ⁶⁷ (T•C•S) 14:31, February 16, 2020 (EST)

The image-critical ancillary chunks are tRNS (used on Captain Toad: Treasure Tracker ripped textures by APNG Optimizer to greatly reduce file size), sBIT, pHYs, and the color space chunks, sRGB (when it specifies a different rendering intent than the default one), gAMA, cHRM and iCCP. So far only the tRNS, sRGB and gAMA/iCCP have been spotted, but I’m not sure if the others are featured as well, press release material might be the most at risk, if it was generated using the AdobeRGB color space.

In any case, this specific proposal deals with the gAMA chunk and possibly the iCCP chunk.—Mister Wu (talk) 18:55, February 16, 2020 (EST)

I'm not sure we should mention performing image optimization on the template at all given that it's now heavily discouraged at best by the image use policy. -- Too Bad! Waluigi Time! 19:24, February 16, 2020 (EST)

The Image Use Policy only discourages "Re-uploading existing images solely to optimize file size," not optimizing images you are planning to upload anyway. There could be other reasons (such as cropping) that one may modify an existing image, and many people such as myself optimize all pngs uploaded, including images to reupload. --Super Mario Fan ⁶⁷ (T•C•S) 19:30, February 16, 2020 (EST)

I would suggest writing a specific new page about Gamma Brightening, and having two sections to the page. One, very general in description, explaining what it is as simply as possible (metadata is a thing and while usually ok is not here and therefore needs to be kept, here's why we keep it), and the second half getting into the really technical stuff involved. While I like the detail that SMF67 and Wu are providing, I have absolutely no idea what just about any of that means. On the second point, I usually optimize uploads that are new nowadays, but I am duplicating them to compare them, just in case. Also, input on the color would be nice. Trig - 20:50, February 16, 2020 (EST)

I like color option 2 the most. --Super Mario Fan ⁶⁷ (T•C•S) 17:58, February 17, 2020 (EST)

@Trig Jegman, @Mister Wu, I made a quick (still incomplete) draft of a page that could describe the technical parts of color-correction metadata and how to safely optimize these images in my sandbox. There are still a few missing details I haven't figured out yet, and anyone is encouraged to add to it or take details from it to make something else (we don't have to use it of course, I don't know if all of the information is relevant/important to include). Additionally, while it might be nitpicky, I think it might be a good idea to refer to the metadata as "color-correction metadata" rather than "gamma brightening," since technically gamma is only one type of color-correction metadata and iCCP seems to be the most common from the images I've tested. --Super Mario Fan ⁶⁷ (T•C•S) 18:24, February 19, 2020 (EST)

Perhaps it would be more appropriate then to use {{color-corrected}}, with the following? The link would be a new page that explains color correction in a much more broad sense with a section on how to properly optimize the images. Trig - 19:00, February 19, 2020 (EST)

This image has color changing metadata and should not be optimized.

Delete Template:No license

DELETE 7-0
Images should have licenses. That's how copyright law works! It's critically important that if we have an image on the site, then we use some form of copyright with it.

Sometimes, the uploader doesn't know how to tag it. If they don't they can use {{don't know}} and Category:Uploader unsure of copyright status (which has a fairly large number of items in it, by the way) and request another user that knows how to categorize the image to indicate it.

This template, however, does not make sense to have. Simply put, if we the collective don't know the copyright status of an image, we do not keep that image. Its so rare that one cannot be categorized anyway, but should an image be so uncertain that multiple people cannot determine its status, it will err towards safety and not use said image.

In short, delete this template and its category because the image that would be tagged with this would be deleted anyway.

Proposer: Trig Jegman (talk)

Deadline: March 1, 2020, 23:59 GMT

Support (delete it)

1. Trig Jegman (talk) Per proposal
2. TheDarkStar (talk) - Per proposal.
3. Supermariofan67 (talk) - Per proposal.
4. FanOfYoshi (talk) Per proposal.
5. Toadette the Achiever (talk) Agreed.
6. Obsessive Mario Fan (talk) Per all.
7. Niiue (talk) Per all.

Delete Category:User eo

DELETE 5-0
The language of Esperanto is not a real language. The auxiliary language was initially created by some linguists to attempt to be universal in application, but nobody really picked it up. As a result, it is not even a secondary language for any country in the world, and has fewer than 10000 'native' speakers (about 5000). Henceforth, it's application in the real world is virtually non-existant. As I like to joke, since we keep this around, why not add Klingon?

Nobody speaks this language. Nobody utilizes the category to speak this language. Nintendo does not even sponsor or support it as a language. It's unnecessary and (frankly somewhat appalling) that we continue to support a language that does not exist, and therefore this category should be removed.

Proposer: Trig Jegman (talk)

Deadline: March 5, 2020, 23:59 GMT

Support (delete category and esperanto support)

1. Trig Jegman (talk) Per proposal
2. Doc von Schmeltwick (talk) Laŭ propono
3. TheDarkStar (talk) - Per proposal.
4. Alex95 (talk) - Per proposal (I'm all for a Klingon template, though).
5. Waluigi Time (talk) Per proposal.

Add categories to the MarioWiki babel for Bengali, Urdu, and Hindi-speaking users

cancelled by the administrators
A proposal is not necessary for creating categories for languages, especially such common ones as these. As MarioWiki:Babel already says, if you speak the language, you're free to just create one.

I look at the MarioWiki babel and see three languages missing: Bengali (also known as Bangla in Bangladesh), Urdu, and Hindi. As a user of Bangladeshi descent, I'm quite surprised to see that Bengali isn't included in the babel; I'm also surprised that Urdu and Hindi haven't made it into the babel yet, either. It's proven that 425 MILLION people worldwide speak Hindi, another 300 mil speak Bengali, and another 100,000,000 speak Urdu. We're talking close to 850M speakers of these 3 languages; that's a rather large portion of the world's population! Don't ya guys think it's time we update the babel?

Proposer: MarioManiac1981 (talk)
Deadline: March 23, 2020, 23:29 GMT

Support

1. MarioManiac1981 (talk) Per proposal.
2. FanOfYoshi (talk) Per proposal.

Delete Category:User ka

keep 1-10

The Georgian language is esoteric to say the least. With just under four million native speakers, it's not a common language to come across. Simply put, it does not have a common application. Nintendo does not support Kartuli Ena (the language) on it's consoles or releases either. It is unlikely that there is ever a need for this language to be spoken, but should it be desired later that someone wants to show they speak the language, it could just be represented by the direct code. It does not make sense to support something that has been unused (and is unlikely to be used).

Proposer: Trig Jegman (talk) (Blocked)

Deadline: March 22, 2020, 23:59 GMT

Support

1. TheDarkStar (talk) - Per proposal.

Oppose

1. MarioManiac1981 (talk) The thing is, this wiki should be a place pertaining to everyone. So what if Georgian is a less commonly spoken language? Does that mean we're gonna exclude the Georgian-speaking minority by removing their language?
2. FanOfYoshi (talk) Per MarioManiac1981.
3. Lord Grammaticus (talk) Per all. I understood the Esperanto one somewhat, but I personally feel trying to prune every single instance of an "unpopular" language is a bit above and beyond the call. I feel like the "not an officially supported language" reasoning is flawed, since that shouldn't and doesn't necessarily stop a fandom developing among those speakers - fan translation communities do exist for the "bigger" languages after all, and the Babel doesn't exactly have any entry barriers to those wishing to utilize it, as JC indicated.
4. Alex95 (talk) - Per all.
5. Waluigi Time (talk) Per all, Lord Grammaticus in particular. Also, you say this could be represented through code if needed in the future, but if the category's deleted there's no substitute for it. Whether or not a language is supported by Nintendo is a moot point as you can speak that language while still enjoying their games (i.e. fan translations, knowing a secondary language that is supported, or just ignoring text entirely if you want to go about it that way). Trimming language support here down to what's "official" because Nintendo supports it is going a little off the deep end in my opinion.
6. Supermariofan67 (talk) - I don't really see the disadvantage of keeping it around, considering that it actually has native speakers (unlike Esperanto).
7. JoeRunner (talk) Per all. The fact that it's not on Nintendo systems doesn't disclude it from here, and "because it isn't spoken much" isn't a great reason either.
8. RickTommy (talk) Per all.
9. Niiue (talk) Per all.
10. PowerKamek (talk) Per all.

Create a "character/species" infobox

create 11-0
So as time has gone on, we've gotten to where entities can be interchangeably considered characters and species. Some of these, like Yoshi, Toad, and Kamek/Magikoopa, have enough respective information they can stay split relatively soundly. Others, like Draggadon, Dorrie, Koopa Kid, and Wiggler (to an extent) are not split, and doing so would be inconvenient both to read and to write and would more than likely require fancrufting to decide where the distinction lays. Others, like Birdo, Boom Boom, Krusha, and Klump probably should be merged due to how their creators treat them wholly interchangeably as a character or species, but are still split nonetheless. The main reason I see preventing that (as well as making the already-merged ones a bit awkward) is having to decide which infobox to use: character or species?

My proposed solution is simple: just have a combined infobox for wider-interpreted entities. This way, we can say other members of a species and their relatives while still acknowledging the "character" aspect exists to whatever extent it does in that particular case. I have code below, view page source to see. It includes all the main important facets (including the "relatives" parameter I didn't realize we'd implemented...) without any redundant parameters like "species."

Proposals/Archive/55

Proposer: Doc von Schmeltwick (talk)
Deadline: April 16, 2020, 23:59 (GMT)

Support

1. Doc von Schmeltwick (talk) Per proposal
2. Results May Vary (talk) Per Doc's reasons, he's already done something similar on a wiki we've been working on. This isn't completely related, but one reason I'd support is because the current species infobox have parameters like parent_species which displays "Variant of"--this makes the source name inconsistent with the displayed name. It would be great if we could change these parameters, which I've been wanting for a while.
3. Mister Wu (talk) Well, I think having a unified template can help as an initial step in trying to approach this character/species oddity, even though at the beginning it might be used just for a few cases like Draggadon and Dorrie
4. Baby Luigi (talk) Sounds like a good idea, and honestly, Boom Boom should have just been merged a long time ago as the two separate articles are pretty much duped: we can easily make a general Boom Boom article and note discrepancies in their general information section surrounding the inconsistency.
5. JoeRunner (talk) Per proposal.
6. Waluigi Time (talk) I don't really want to go down the "merging characters and species" rabbit hole, but admittedly that's just me clinging to nostalgia and this would probably be better for organization.
7. MarioManiac1981 (talk) Per all.
8. FanOfYoshi (talk) Per all.
9. Lord Grammaticus (talk) Doc's got the right idea, it's a small step at the moment but it'll be something.
10. Duckfan77 (talk) Per all.
11. Toadette the Achiever (talk) As they say, "why can't we do both"?

Comments

Not sure how I feel about this right now, but this got me thinking - why don't species infoboxes already have a section for portrayals? Shy Guy and Wiggler come to mind as enemies that could benefit from it, and it's a lot neater than just throwing it in the opening somewhere, or worse, neglecting to mention it at all. -- Too Bad! Waluigi Time! 12:03, April 9, 2020 (EDT)

Create a template for citations

Do not create template 5-9
BEFORE YOU READ, KEEP IN MIND THAT I'M NOT PUSHING ANY POLICY. I AM ONLY PROPOSING AN ADDITION THAT WOULD ENCOURAGE CERTAIN FORMATTING CONVENTIONS, BUT IT WOULD BE UP TO EDITORS TO UTILISE.

Go to the list of Yoshi's Island glitches page and scroll down to the bottom. See those huge blue stacks of undefined links? They make me a little uneasy to be honest. Not a great issue, but they certainly would look better if they were formatted more like this, tidy and comprehensive.

When citing a source, some users are careful to note the author, website of origin, and date of retrieval, while others are content with just putting a link forefront. The way citations are currently formatted on the wiki is, therefore, quite arbitrary and unprofessional. Wikipedia has a template specially created to make citing sources tidy and consistent, and I think we should follow their model for the mere sake of professionalism. This also has the advantage of not having to type in every single character and risk omitting a period or a bracket, at least for me, as they would already be a part of the template.

The template can be used to cite virtually anything, from books, magazines and guides to websites, and have their publication date, publisher and other details mentioned as well, provided their corresponding parameters in the code are filled in. If the proposal passes, the following code, which is similar to what Wikipedia has, will be used:

{{ref
| name       =
| date       =
| url        =
| title      =
| page       =
| source     =
| accessdate =
}}

which, when incorporated, should produce the following line:

Name (Date). [URL Title]. Page. Source. Retrieved Accessdate.

Previously proposed code, modified to the above for brevity:

{{Citation
| last       =
| first      =
| year       =
| url        =
| title      =
| page       =
| publisher  =
| accessdate =
}}

which, when incorporated, should produce the following line:

last, first (Year). [url Title]. Page. Publisher. Retrieved Accessdate.

where the last and first parameters correspond to the author's last and first name respectively. If the author uses a username instead of their real name, then only the first parameter should be filled in; if neither of those parameters are filled in, the brackets around the publication date are removed.

Proposer: Bye Guy (talk)
Deadline: May 1, 2020, 14:54 GMT

Support

1. Bye Guy (talk) per proposal.
2. Waluigi Time (talk) This would make references look a lot more professional and consistent, I see no reason not to do this.
3. Duckfan77 (talk)Per all.
4. FanOfYoshi (talk) Per all.
5. Supermariofan67 (talk) Per all.

Oppose

1. Lord Grammaticus (talk) - I understand and agree that reference formatting is something of an issue, but the use of a template to solve the problem strikes me as dubious, especially when numerous resources that show and teach how to use MLA-style citations already exist. It's still on editors to put those resources and knowledge to use, and I feel like this is misguided in that specific sense of providing yet another something that might not be paid attention to.
2. Doc von Schmeltwick (talk) - First off, the "last" and "first" are automatically flawed since a grand majority of YT videos and the like run on screen names. Furthermore, many of these could be misinterpreted regardless, and this is far less user-friendly than say, our aboutfile template. Furthermore, between MLA and APA, there is no "right" way, and a shocking amount of the resources for those are becoming subscription-only for some bizarre reason. On another note, just having "year" is additionally flawed for video-type sources, and "publisher" is extremely esoteric for a subject like this. We aren't writing scientific journals here.
3. LinkTheLefty (talk) - We haven't even fully sorted through the wiki's former use of contractions, and that was years ago. It would be a waste of time to expect us to go back to each and every citation and ensure they're all updated to a template standard. As noted, Wikipedia's reference style is more academic, while this is decidedly not, and thus not all of those are going to be applicable and many are going to have incomplete information. If you don't like informal citations, you're free to update them yourself on your own time, but please don't force other users to stop what they're doing and implement a rigid system that'll be more trouble than it's worth.
4. TheDarkStar (talk) - per all
5. Yoshi the SSM (talk) - per all especially LinkTheLefty.
6. Goombuigi (talk) - Per all.
7. Niiue (talk) Per all.
8. JoeRunner (talk) Per all.
9. PinkYoshiFan (talk) Per all.

Comments

@Lord Grammaticus: The same argument can be made against the analogous template used on Wikipedia, as well as all the formatting templates currently in use on this wiki ({{sic}}, {{wp}} etc.) The fact that someone may not be aware of such template doesn't make it less practical. -- KOOPA CON CARNE 14:10, April 24, 2020 (EDT)

Mm, fair enough. I'll mull over the vote later today when I have obligations out of the way. -- Lord G. matters. 14:16, April 24, 2020 (EDT)

@Doc von Schmeltwick: I already addressed the potential issue with run-on names in the proposal:

If the author uses a username instead of their real name, then only the first parameter should be filled in

But I agree that using "last" and "first" parameters is not very user-friendly; however, it can be simplified with ease to something like "name". The "year" parameter can be changed to "date" very easily also, and "publisher" can be changed likewise to something more general like "source" (since YouTube can't be cited as a publisher). A large part of your argument seems to be fixated on easily modifiable details that I didn't bother to adapt here, which I admit is a mistake on my part. The rest, regarding "we're not writing scientific journals"--I'm sorry but it doesn't make sense to me. Does that mean that we shouldn't establish some professional conventions? While we're at it, let's scrap the entirety of our writing guidelines and disregard any past proposals. -- KOOPA CON CARNE 15:13, April 24, 2020 (EDT)

When I said that I meant, like, why cite things like we're citing a textbook? Additionally, your "Wikipedia uses it" argument is also flawed in that manner, as they have lengthy articles over nuclear physics and paleobiology that actually would warrant a citation in that manner. On another note, if a video is taken down and needs replaced, it'd be much easier to change the url and leave the "video showing glich" text alone rather than alter every bloody parameter. The convention you are attempting to establish is honestly little more than a burden considering the limited scope of what we cover. Doc von Schmeltwick (talk) 15:21, April 24, 2020 (EDT)

On another note, if a video is taken down and needs replaced, it'd be much easier to change the url and leave the "video showing glitch" text alone rather than alter every bloody parameter.

Doesn't that mean basically changing the entire source? That kinda has to be done regardless if a template is used or not. And the fact that Wikipedia has a different / much larger scope than us has no relevance to the matter. -- KOOPA CON CARNE 15:34, April 24, 2020 (EDT)

How? Changing a link is much simpler than changing the entire specific and quite frankly irrelevant extra information about a hobbyist posting a video. And again, the fact that what we cover isn't going to be sourced from things like scientific journals or textbooks has entirely to do with how this is unnecessary. Posting a quick link to Youtube or TCRF with a quick descriptor rather than filling out information that 70% of the time won't even exist offhand is much more efficient. Doc von Schmeltwick (talk) 15:46, April 24, 2020 (EDT)

Wait, sorry, now I understand what you are saying. You are against writing citations as per MLA conventions as a whole, and support something simpler instead, like just putting a link. I'm afraid I cannot agree with that; we should strive to look as professional as possible. -- KOOPA CON CARNE 15:42, April 24, 2020 (EDT)

...No? I'm against unnecessary fluff, which this is. Doc von Schmeltwick (talk) 15:46, April 24, 2020 (EDT)

YouTube and Twitter hobbyists have the same weight as an officially-endorsed/published author in this case if the source is relevant to our interests. They all produce or reveal information, and I have a feeling that this is what Wikipedia uses as a basis for citing all of their sources in the way they do. -- KOOPA CON CARNE 15:52, April 24, 2020 (EDT)

I think "source for official terminology" is a different thing than "verification that something that's not supposed to happen can happen." Attempting to force a style for majority incompatible sources isn't professional and it isn't proficient. What it is is profoundly prolonging profuse peripherals. Doc von Schmeltwick (talk) 16:07, April 24, 2020 (EDT)

If a convention is set in a particular area, then everything in there should follow it, even if it sacrifices "efficiency" in some cases. Context is key: it's not efficient to use academic lingo when you communicate with your peers, but it is going to be needed when you write a research paper, with no exceptions. Same here: if particular sources are cited in a way, the others should be cited in the same manner as well with no exceptions. -- KOOPA CON CARNE 16:19, April 24, 2020 (EDT)

"If a convention is set in a particular area, then everything in there should follow it, even if it sacrifices "efficiency" in some cases." ....you realize that's inherently a bad thing, right? Being inefficient at the "boon" of considering yourself professional in a needless manner is not a good trade-off. I don't intend to be rude, but I can't see this as anything but that. Doc von Schmeltwick (talk) 16:24, April 24, 2020 (EDT)

You certainly could have worded that remark a little differently but I digress. Let's agree to disagree. Either way this goes, I'll still format YouTube links like how I proposed. -- KOOPA CON CARNE 16:30, April 24, 2020 (EDT)

...you literally said that you want to encourage the creation of inefficient incompatible rules, while admitting they are as such. Doc von Schmeltwick (talk) 16:33, April 24, 2020 (EDT)

Yes, I understood that. My issue was with your tone, but what you said now is perfectly fine. -- KOOPA CON CARNE 16:40, April 24, 2020 (EDT)

I'm wondering what your motivation for this is? What benefit does it have? "Looking professional" is entirely subjective. ZeldaWiki's source template makes me want to dry heave. A needless obfuscation of a task we want to encourage people to do discourages sourcing or even editing in general. Also, given current social circumstances, my mere bluntness is really acting as nice as feasible. Doc von Schmeltwick (talk) 16:46, April 24, 2020 (EDT)

At its core, it's mere preference, backed up by the fact that it's a practice a very regulated place like Wikipedia carries out. What makes me "dry-heave" is the opposite: lack of organisation, just seeing a url slapped under a headline. This template would not be "discouraging other people or forcing it onto them". If someone includes only a link as a source, someone else can format it later in the right way, which is--and excuse my use of italics, but I feel it's warranted here--a thing that is happening currently. A template would make that easier for people like me who want citations to look a certain way, but then I suppose this does not motivate an entire template be put in place as it's subjective. That is why I tried to look up to a website like Wikipedia and try to model my preference after certain criteria. The reason they made this formatting decision is precisely because it looks more organised, which is a sign of professionalism. -- KOOPA CON CARNE 17:01, April 24, 2020 (EDT)

What that ergo entails is that like aboutfile, it's merely a suggestion. Therefore, the only people who will use/fix them anyways are the ones who specifically like it in spite of its user-unfriendliness (as unlike aboutfile, which shows up every time an image upload is prepared, people would have to go out of their way to remember the specific names for each parameter, itself already a major pain for less-used templates like multiframe and multiple-images). If you want to change how they looks, that's fine, but trying to force it (a template regarding this implies it is intended to be used in a policy-driven manner, and you yourself advocated it should be rigidly followed in a preceding comment) the when so many cases are incompatible isn't "professional." I was gonna append a contextually appropriate snarky comment relating to one of the only good remaining newspaper comments, but decided against it Doc von Schmeltwick (talk) 17:09, April 24, 2020 (EDT)

I would like to back-paddle to the comment you mentioned and withdraw that argument, as the existence of the "aboutfile" example (and to a lesser extent, {{ref quote}}) actually makes my point stronger now. If the template is optional, but some people want to use it, then let it be. Like Waluigi Time said in a comment below, the template wouldn't be forced on anyone. People who won't use it are free to not use it. I'm merely stating arguments to support my proposal, not pushing an addition down people's gastrointestinal tract from the entrance down. -- KOOPA CON CARNE 17:25, April 24, 2020 (EDT)

But it's unnecessary. If you want to follow MLA, a confusing template does not encourage the use of it, and it would probably be easier to go to whatever MLA generator site is still not subscription-based and use that. Doc von Schmeltwick (talk) 17:30, April 24, 2020 (EDT)

I'm inclined to agree with you now, but that makes me wonder why Wikipedia even has a template then. Like, what you said now would practically demolish their reasoning. It's probably for more complex citing that requires a lot of things like a book's ISBN and such, but then again they have an individual template for web citation and even for Twitter in particular as far as I know. There must be a reason for the things being the way they are, and if there is, I don't see why we shouldn't follow it as well. -- KOOPA CON CARNE 17:39, April 24, 2020 (EDT)

Because things like study-based textbooks that otherwise are not mentioned in the wording could lead to plagiarism-based legal problems. Manuals based off some dudes playing a game and having a license to write whatever fanfic they concoct over it and be published as official are not the same as careful scientific observation and investigation, and since this is regarding a fictional series anyways, whoever discovers something means jack diddly squat. Doc von Schmeltwick (talk) 17:55, April 24, 2020 (EDT)

Stop being so aggressive. I already said I'm agreeing with you, I just posed a question, in the calmest manner at that. -- KOOPA CON CARNE 18:02, April 24, 2020 (EDT)

I was not being aggressive, that is literally how licensed game guides work, especially back in the day. You asked why wikipedia would use it when we wouldn't need it, I gave respective accurate examples. Doc von Schmeltwick (talk) 18:09, April 24, 2020 (EDT)

Before I stop relying, or start saying things that will guarantee me a warning for that matter, I have to say that "some dudes playing a game and having a license to write whatever fanfic they concoct over it" certainly comes across in a manner that denotes a special kind of attitude that frustrated condescending people have. Most of it is channeled in the irony of the phrase "whatever fanfic", "fanfic" implying something that lacks dignity and taste as the term has become known for. "People officially employed to write manuals" sounds a lot more pristine already without all that, uuh, fluff. It's a cheesy way to explain it but your statements certainly rub me the wrong way most of the time considering the fact that the tone I use in my comments is in now way intended to be flammatory in the slightest. Likewise, since I know that other people have, quote, "expressed displeasure" with this particular tone of yours, I am certain that it is not me who is sensitive. Keep this attitude in other places, on forums, on The Spriters Resource--snarkiness has its place--just not here. Subtly displaying that you think everyone but you is a pushover is, err, not very commendable. Rant over, for this long, probably unecessary piece of text doesn't regard the subject at hand but an older issue. -- KOOPA CON CARNE 18:31, April 24, 2020 (EDT)

Talk pages are in general relatively laid-back in my experience. What never belongs anywhere is this "holier-than-thou" (or be it "more-professional-than-thou") attitude. Regardless, it is clear we have reached a standstill in this. However, I will not be moved on the fact that licensed guide writing relies heavily on the guide writer's own interpretation of others' creations, which is not the same as (and indeed, is in no way comparable to) someone writing about their discoveries in a scientific field, which would require heavy citation if writing about. Doc von Schmeltwick (talk) 18:36, April 24, 2020 (EDT)

I'm going to remain neutral on this, but I'll voice some things anyway. Other wikis use a citation template (Zelda, Fire Emblem, etc.) and it does help make things a little nicer. But they are also kind of big and clunky, and they aren't automatically added or easily accessible like {{aboutfile}}, so users could very easily miss it. Yes, the links should have an identifier to them, but that is an easy fix and we don't really need a template for them. I don't really like using the template, but I also acknowledge its usefulness. 16:24, April 24, 2020 (EDT)

When it comes to preference, I must affirm that I don't like it when I see just a link with nothing else. I like seeing where precisely it will lead me to before I hover my cursor over it. The issue of clunkiness can be resolved, I think, by simply orienting the template's code horizontally rather than vertically. Citations are already clunky as they are, taking a lot of space in the middle of text. -- KOOPA CON CARNE 16:30, April 24, 2020 (EDT)

By clunky, I meant like, it doesn't really do much. It just organizes the text better. It's not like an infobox where a lot of code is necessary, or a citation needed call that points out something is missing. Organization is great and it's nice to have some idea of what to use, don't get me wrong, it just doesn't seem necessary to use to me. 17:07, April 24, 2020 (EDT)

@LinkTheLefty: How is this "forcing" anyone to do anything? Like you said, we haven't even cleaned up all the usage of contractions yet - obviously that proposal didn't "force" us to go around fixing every single contraction and neglecting everything else on the wiki. It would be the same here, as a standard going forward and something to clean up as you come across if you want to. -- Too Bad! Waluigi Time! 17:03, April 24, 2020 (EDT)

Methinks that's the rub - beyond adding a somewhat complex template that results in slightly better organized text, it doesn't directly address the "core" issue of users not actively citing things properly to begin with. It doesn't worsen anything at all, far from it, but in practice it seems unlikely to actually provide enough of an incentive or change anything else with regard to user habit, either. -- Lord G. matters. 17:17, April 24, 2020 (EDT)

That "core" issue does not exist and the proposal doesn't aim to address it in the first place. People are free to format a reference however they want. And I want my citations to follow a template, for reasons I've already stated in the proposal. -- KOOPA CON CARNE 17:29, April 24, 2020 (EDT)

Then that sounds more like a personal convenience, that's being extended into policy because... question mark? -- Lord G. matters. 17:51, April 24, 2020 (EDT)

Because "aboutfile" exists for convenience as well. -- KOOPA CON CARNE 18:02, April 24, 2020 (EDT)

"Aboutfile" is actually conveniently set up, the source code appears whenever one uploads an image, and it arranges it into a table that would otherwise require knowledge of HTML to recreate. This wouldn't do that and merely arranges the words in a specific way with punctuation. Doc von Schmeltwick (talk) 18:12, April 24, 2020 (EDT)

If "people are free to format a reference however they want," doesn't that defeat the purpose of making a template in the name of professionalism? You can't have it both ways. LinkTheLefty (talk) 19:41, April 24, 2020 (EDT)

Oh, you absolutely can. Some people may use that format and some may not, and that's fine. But then again, some people are more professional than others and may want to use a template. Like Bazooka Mario states below, this practice would accustom other editors to more professional formatting.-- KOOPA CON CARNE 19:52, April 24, 2020 (EDT)

And I can empathize with that, but the "proper" way to do so due to the variety of style manuals is so variant that a template loses all meaning. Doc von Schmeltwick (talk) 19:59, April 24, 2020 (EDT)

The template can be adapted to the situation at hand by completing only specific parameters. -- KOOPA CON CARNE 20:18, April 24, 2020 (EDT)

But by saying stuff like "some people are more professional than others," you're inherently suggesting that this will be the new standard; if that isn't your intention, then I feel like this approach will, ironically, look less professional. LinkTheLefty (talk) 20:01, April 24, 2020 (EDT)

That isn't a standard, it's a truth. The site looks unprofessional in some areas because it was handled unprofessionally in those areas. There is no irony/discrepancy involved. -- KOOPA CON CARNE 20:18, April 24, 2020 (EDT)

You are acting as though professionalism is an objectively quantifiable thing, though, and it isn't. People have different standards as to what constitutes that. Doc von Schmeltwick (talk) 20:34, April 24, 2020 (EDT)

I find it professional to barf in a bag and smack people in the face with it. However, a professional act is something that respects certain conventions to work efficiently for the benefit of others. You could argue that for this reason the code used in this template would not be very professional; however, what matters in the end is the presentation output by the template, a far cry from the raw url's we sometimes see. Professional formatting is different from professional writing; as I told LinkTheLefty below, how well people format their edits doesn't (necessarily) reflect the quality of their writing. -- KOOPA CON CARNE 03:58, April 25, 2020 (EDT)

I'm afraid I still don't completely understand - either you want a template in the hopes that its style supersedes the current implementation (which is the distinct impression I'm getting when the point is to follow the Wikipedia model and you emphasize "professionalism"), or you don't. If it becomes mandatory, then it would be a silly thing to warn a would-be or worthwhile contributor over in addition to the update having a long and messy interim on the wiki, and if it remains optional, then readers would be confused as to why the implementation is sloppy. Also, if someone happens to not want to use the template, then their edits should certainly not be viewed as less professional even if the output is exactly the same as if they had used it. I'll also mention that wikis that use a citation template tend to use in-game citation as well, which is something we already don't do in general. I hope you see where I'm coming from. Either way, there's nothing stopping you right now from taking the examples of bad citation and making them resemble better citation. LinkTheLefty (talk) 20:59, April 24, 2020 (EDT)

It's simple. Like the use of contractions, writing citations without regard to any standard is less desireable when someone raises "professionalism" as an argument, but it's not something worth warning people over. My proposal or any of my arguments here don't mention anything about the template being mandatory; what I said was that if we set a convention, it's better to follow it, but we won't force anyone to. A template such as the one proposed here would be useful to let editors know that there is a standard to follow and encourage them to follow it, and whether they use the professional model or not is not a reflection of the quality of their edits writing. Also, I would find references easier to note with a template, so if it's useful to me then certainly others will find it useful as well. -- KOOPA CON CARNE 03:25, April 25, 2020 (EDT)

The template may look better than raw url code, but what you propose to do would make it look nearly (if not exactly) the same as what we currently have. And what we currently have is already professional. It's just that people use it to put raw url in it. Would the template stop people from putting raw url code for references? See TheFlameChomp's comment below. And without removing what we currently have (which would really be too much work that it wouldn't be worth it), people would want to use both. Simply put, we don't need to create a template that would be easier to note over something that looks just as professional. And unlike contractions, this isn't just one word change, it is converting <> to {{}}, changing ref to citation, adding |s (and maybe even the words like name and =), and adding enters at the end of the lines. And why I am not including changing bad references into good references? Well, we can do that already without the template. And unlike contractions, this template is trying to improve something that is already good looking when done right, whether or not it fully replaces it. Yoshi the SSM (talk) 11:34, April 25, 2020 (EDT)

The template would obviously be put between tags, not replace them. I just changed "citation" to "ref" in my code mock-up so it is more in line with {{ref needed}} and {{ref quote}}. Any template code can be arranged in a single row; switching to a new line between parameters is usually done to keep things more visible. And what is "|s"?
I'll say it again: editors would NOT be forced to use the template in any way. My proposal does not promote policy changes, just a mere convenience for people who want adhere to certain conventions for citing sources. For policy matters, see the discussion initiated by Bazooka Mario below. -- KOOPA CON CARNE 11:53, April 25, 2020 (EDT)

If I am understanding this correctly, the code will become from top to bottom.

<ref>name. (date). [url title] ''source''. retrieved date2.</ref>

<ref>{{ref|name|date|url|title|source|date2}}</ref>

To use as an example, I copied the 20th reference of List of Mario & Luigi: Bowser's Inside Story + Bowser Jr.'s Journey glitches at time of writing.

<ref>AAWW1010. (February 10, 2019). [https://youtu.be/Jzj7XJx9yvU Mario and Luigi inside bowser story + bowser jr. journey : music glitch] ''YouTube''. Retrieved February 11, 2019.</ref>

<ref>{{ref|AAWW1010|February 10, 2019|https://youtu.be/Jzj7XJx9yvU|Mario and Luigi inside bowser story + bowser jr. journey : music glitch|YouTube|February 11, 2019}}</ref>

Am I understanding this correctly? If so, then it wouldn't solve the issue of people putting raw url in. Yoshi the SSM (talk) 12:55, April 25, 2020 (EDT)

That's right, it doesn't solve the issue of people putting in only URL's. The proposal, I'm saying it yet again, doesn't concern that at all. But you got the hang of how the code would be laid out and, as you can see, it's efficient, harmless and, most importantly, comprehensive--it has everything you need to know about a particular source. And best of all, you wouldn't be forced to use it, unless the policy gets more serious on how we format citations like Bazooka Mario suggests below. Until then, the template would be completely optional and useful for the ones who want references to be written in a certain way. -- KOOPA CON CARNE 13:18, April 25, 2020 (EDT)

It took a little bit of work to convert just that one. And there are 20 on that page alone. There are several several more references. You can see why it could take a lot of work. And, using the template gives the same appearance to what we currently have when you aren't looking at the code. This isn't (is not) like contractions in this sense, as you can even see the difference of contractions in this sentence. Anyways. A template for references that would look efficient and comprehensive in code, but produces the same result. Is it really necessary? To me, it is a no. Whether or not it is optional, it is a no. And I say no because the current system is not at all broken or bad. And I am not even talking about policy at all here in this paragraph. Yoshi the SSM (talk) 13:52, April 25, 2020 (EDT)

I just did a test in notepad to see how quickly I can turn a manually-formatted citation into template form, and it took me less than 30 seconds, with the mention that I am quite slow usually. 30*20=600 seconds=10 minutes to change all references on that page not counting interim time of copying and pasting the template (about 5 seconds), which would raise it to about 12 minutes. That page has a lot of references, but imagine how quickly you'd be done with a one-two reference page. People would take note of that template over time and start using it for new citations, therefore encouraging a more professional approach. If we ever tighten our rules on formatting, then the template would have even more reason to exist since it's efficient and certainly takes just as much, if not less time to set up than manually formatting a citation with its every period, bracket and apostrophe (for italics). -- KOOPA CON CARNE 14:30, April 25, 2020 (EDT)

And yet, it will still give the same appearance (when not looking at the code). Yoshi the SSM (talk) 14:47, April 25, 2020 (EDT)

Yes, I believe that's the purpose of a template.

For further calculations, I searched "<ref>" on the wiki and got 497 pages that use this tag. I rounded it up to 500 and supposed each one of these pages has 20 references. If we were to redo every citation on the wiki at the rate I calculated above, then in this case it would take 500*20*30= 300,000 seconds = approximately 83 hours of work. If you ration this amount to 2 hours a day, you'd work 41-42 days, a little over a month of daily gnome work. Again, the 20 reference per page was just an exaggeration; things would take much less than that, interim time included. Someone had to go through every page and remove the bold marks around main subjects under image captions. I went and added filenames to every Play Nintendo picture I uploaded (hundreds). This is certainly doable if you set your mind to it, but again, nobody is forced to. I can take care of most if not all. -- KOOPA CON CARNE 14:52, April 25, 2020 (EDT)

Bold marks are noticeable to those not looking at the code. Filenames are noticeable to those that want to see the images. Even contractions are noticeable by those not looking at the code. The aboutfile in images can be seen by those not looking at the code. This template, on the other hand, would not make any difference to those who do not look at the code. When looking at an article, you are usually not going to look at the code, but instead will look at the result of the code. When I say looking at the code, I mean when one edits the page. When I say not looking at the code, I mean the actual page itself. And why do we need a template for something that already is working just fine? Yoshi the SSM (talk) 15:42, April 25, 2020 (EDT)

@Yoshi the SSM: My preoccupation is to maintain everything formatted in a particular way down to punctuation. I am ridiculously petty with stuff like this. I find it jarring when I see the name and date in a citation separated by a period; it's redundant because the date is already bracketed out. In other cases, commas are used instead of periods altogether. A template would set a format in stone and would rid us of these little differences. However, at the same time, I realise that such differences are too minor to create a template for and don't matter as long as all the needed information is conveyed already, by hand or otherwise. In the end, I agree with you. -- KOOPA CON CARNE 18:15, April 25, 2020 (EDT)

I understand this. Also, I went to page in Wikipedia, and found that though there are refs with cites in them, there are also refs without cites in them, but act as like what we currently do. Granted, this is one page that I found it in. Just saying this. Anyways. Let's go down and discuss policy now. Yoshi the SSM (talk) 10:14, April 28, 2020 (EDT)

It's probably best to get policy running on proper citations

If we haven't already. Contractions are a matter of prose, but if we're going to be serious on having good and up-to-date sources, it's better we start having people format their sources now so fact-checking in the future is much easier. A template might be used at a later date, but it's better if people just get accustomed to "Name. (Date). "Title". Publisher. Access date" format rather than dropping bare links with raw URLs or worse putting references as a [1] in the section. I don't get the "we're not academic" and "we shouldn't put unnecessary fluff" claims when at the same time we try to get our best information (e.g. Super Mario Bros. Encyclopedia debacle). Formatting isn't "fluff", it's a basic part of citation, checking dates, credibility of sources, medium of source, etc. Mario^-HOHO! (Talk / Stalk) 18:45, April 24, 2020 (EDT)

I completely agree. Frankly, I don't necessarily care whether or not a template gets created, I just want more professional and consistent sourcing and I feel giving users a template to easily format them consistently is a good way to do that. Unfortunately the opposition, at least to me, feels like it's based entirely on "too much work" and, even worse, "I don't care", so even getting a policy going for this might be controversial. Just because we aren't "writing scientific journals" there's no reason not to be clear, consistent, and informative. -- Too Bad! Waluigi Time! 18:53, April 24, 2020 (EDT)

When half of the most basic parameters don't exist anyway in a majority of relevant examples, you can't reasonably expect ability to consistently use said formatting, and therefore pushing policy of it is nothing but self-destructive. Doc von Schmeltwick (talk) 18:56, April 24, 2020 (EDT)

Thing is, formatting citations properly is, per MarioWiki:Citations, already policy. Anyways, if a parameter doesn't exist (like the author name) for certain citations then it doesn't need to be added, per the policy. This policy has yet to be self-destructive, albeit this policy is often forgotten (not referring to this discussion, it's just that formatting of citations on articles don't often follow this policy, which I am guilty of too). Doomhiker (talk) 19:00, April 24, 2020 (EDT)

A template should be versatile and cover all possible scenarios. Optional parameters exist for a reason. -- Too Bad! Waluigi Time! 19:02, April 24, 2020 (EDT)

Yes, but this template is still very book-centric. Really the only web-based thing on there is url; there is nothing for, say, "platform" (ie YouTube, Twitter, which is in no way the same as a publisher and not really compatible with the "source" one AFAICT) showing just one example of flaws by limitation. Doc von Schmeltwick (talk) 19:08, April 24, 2020 (EDT)

(ec) Most paramters are covered in the proposal, not "half" as you claim. Only parameter I don't see will have much use as the rest is "page" but the rest you can find in most citations. Referencing Twitter posts? Handle (Date) "Link to post" Twitter Access date. YouTube videos? User name (Date) "[Title of video and link]". YouTube. Access date.. Game guides? Author (Date) Title of book. Publisher. Page numbers. Date accessed.. "Self-destructive"? That's hyperbole. Mario's article: 40+ citations, most properly formatted but even those that are not formatted are doable. Bowser: 30+ citations, most formatted, those aren't formatted can and should be. Mario Sports Superstars: 9 citations, most formatted appropriately (YouTube video should have date name). Even the website links should be changed from a bare link to [Link of title "Title of website"] (last edited if applicable) and be given an access date. If parameters aren't used, they won't be used and won't show up in the template, as with normal.

No, the template is not "book-centric". YouTube and Twitter certainly are publishers; not as curated as a traditional book publisher but they are. Whatever argument you have is just splitting hairs between what a "publisher" is and I think focuses too much on semantics. Mario^-HOHO! (Talk / Stalk) 19:13, April 24, 2020 (EDT)

It's great that policy exists but that has to be more closely vetted. Probably featured articles need to have a provision that sources should be properly formatted. I'm iffy on a new improvement template just for source formatting however. It's good to try to notify users if they aren't formatting sources though. Mario^-HOHO! (Talk / Stalk) 19:16, April 24, 2020 (EDT)

While I too try to use formatting as best as I can, there have been many, many cases when all I have to go off is "off-center (and as such, page-number unknown) scan/photo of a page of an official Japanese guidebook with unknown title, publisher, author, or even scanner." Doc von Schmeltwick (talk) 19:29, April 24, 2020 (EDT)

You can proceed without some information but it'll make fact-checking really hard if you don't know what the title of the guidebook is. I guess in those cases you can go with [Japanese guidebook, title unknown, page number unknown, etc.) just so you know the information is incomplete. Mario^-HOHO! (Talk / Stalk) 20:05, April 24, 2020 (EDT)

Side note: we do have a {{page needed}} template that could probably be used more often. LinkTheLefty (talk) 22:03, April 24, 2020 (EDT)

I would agree that setting a policy is better. Especially since what we currently have is similar but different to Wikipedia. A policy would help the issue more than a template. Yoshi the SSM (talk) 01:12, April 25, 2020 (EDT)

Hard agree, a policy amendment would go much further towards actually solving the problem than a template that sets an unrealistic goalpost of "one size fits all reference maker". -- Lord G. matters. 02:24, April 25, 2020 (EDT)

By definition, something versatile like a template is different from one size fits all. -- KOOPA CON CARNE 03:39, April 25, 2020 (EDT)

While it may very well be that a template will help with whatever policy we do come up, it would work just fine with what we currently have, given that the policy would want to encourage the same end result (when not looking at code) instead of raw urls. That is how I see it, anyways. Yoshi the SSM (talk) 10:14, April 28, 2020 (EDT)

I personally am neutral on creating a template for this, as I can see how it could potentially be useful, but I could also see users miss it if it isn’t as accessible as the {{aboutfile}}, and I also agree with some of the issues brought up by LinkTheLefty (talk). However, I do strongly agree with better enforcement of MarioWiki:Citations, as I still see many cases where users continue to simply use a url when sourcing, and I feel the policy isn’t made as visible as it should be. --TheFlameChomp (talk) 11:15, April 25, 2020 (EDT)

Decide how to organise the coloured Toad characters

Restrict Blue Toad (character) and Yellow Toad (New Super Mario Bros. series) information 3-1-5
For context, this was originally a TPP to restrict Blue Toad (character) and Yellow Toad (New Super Mario Bros. series) to information about the NSMB character and moving the leftovers to Toad (species); however, an idea was brought up suggesting that we create single "[colour] Toad" articles for each coloured Toad character concept that list every named instance of a coloured Toad character while also not treating them as the same one (in a similar vein to Yoshi listing every Yoshi character even though they're all not necessarily the same as each other, and Donkey Kong covering the named "Donkey Kong" appearances), hence this broader proposal.

• Create single "[colour] Toad" articles: (See Doc's vote/comments.) Specifically Blue Toad, Yellow Toad, Green Toad, Purple Toad and Red Toad. This would mean merging Blue Toad (character), Yellow Toad (New Super Mario Bros. series) and the Toad Brigade members to these coloured Toad articles (not counting Captain Toad to Red Toad), but also having a way to prominently cover the Mario Maker 2 Story Mode Toads and prevent the need for creating several articles for each individual appearance. As mentioned before, these should focus on named appearances, as I think including information about, say, the Mario Party 9 and Luigi's Mansion 3 Toads (where they are treated as generic Toads) would lead to users including every instance of any coloured Toad with some kind of role to the article. Unnamed Toads that appear alongside otherwise named ones in one game (e.g. the purple Crazy Cap shop owner alongside Hint Toad in Odyssey) are an exception, however, as it'd be odd to exclude them.
• Restrict Blue Toad (character) and Yellow Toad (New Super Mario Bros. series) information: My original proposal to limit the information to the NSMB character and its cameos, and move everything else (the Luigi's Mansion 3, Mario Kart Arcade GP DX and Mario Maker 2 info) to Toad (species). There were points raised about the SMM2 Toads receiving separate articles instead, so I've included that alternative as an option.

Proposer: Mario jc (talk)
Deadline: June 18, 2020, 23:59 GMT

Create single "[colour] Toad" articles

1. Mario jc (talk) I'm in favour of any kind of reorganisation, and this seems like a good way to do it. I'm actually leaning a bit more towards this option.
2. Alex95 (talk) - While there aren't that many named Toads aside from the standard, Blue, and Yellow, this seems like the best way to cover more information. Restricting usage to just NSMB seems odd, especially since there is a playable Blue Toad in Super Mario 3D World and Super Mario Maker 2. I'm not sure about the Toad Brigade, but I'd rather this option over the others.
3. Doc von Schmeltwick (talk) Per my previous comments. While not necessarily the same characters per se, you can say the same about the "Toad" character, as well as the "Yoshi" character and the "Birdo" character and all of that recurring "species name" type. Also, it's preferable compared to splitting in awkward, ultimately speculative ways. Also, the Toad Brigade names are clearly role-based nicknames, though Captain Toad has branched out enough to be considered his own thing.

Create articles but leave all Toad Brigade members split

1. TheFlameChomp (talk) I feel I can support this as my second choice, as I can see the use in creating articles and grouping these Toads together, and I agree that creating a page for each individual Toad is unnecessary. However, per Mister Wu's and my own comment, I do not support merging the Toad Brigade Toads as well.

Do as originally planned (restrict Blue Toad (character) and Yellow Toad (New Super Mario Bros. series) information)

1. Mario jc (talk) Per my original proposal.
2. TheFlameChomp (talk) Per the original proposal, and my reasoning for supporting it.
3. Toadette the Achiever (talk) Per original proposal.
4. Waluigi Time (talk) Per original proposal. I personally think the other option is a bit excessive, not every colored Toad necessarily needs coverage, and passing them all off as the same "character concept" in one article just because they happen to share a color palette feels weird.
5. MinecraftFan (talk) Per original proposal…

Comments

I’m not sure about moving the Toad Brigade members in the colored Toads’ pages, most of these seem to have a name other than [color] Toad.—Mister Wu (talk) 09:00, June 11, 2020 (EDT)

Those names (Mailtoad etc.) would still be used in these proposed articles, only the more general "[colour] Toad" would be used as the titles to reflect the purpose of the articles. Mario JC 09:24, June 11, 2020 (EDT)

I’ll be honest, as simple as these names are (it’s basically their role), the different appearance (no longer just the one common to the Toads of the respective colors since Captain Toad: Treasure Tracker) together with the peculiar names rings alarm bells to me. I would support the first choice if it wasn’t for the Toad Brigade being forced in. Maybe you could add a further option leaving the Toad Brigade out?—Mister Wu (talk) 19:06, June 11, 2020 (EDT)

I agree with adding an option leaving the Toad Brigade out. The recent games differentiate them from other Toads with their explorer outfits, and Hint Toad was already differentiated from other Blue Toads due to his glasses. I feel that this, along with the fact that all of them except Yellow Toad have had unique names, even if they only reflect certain situations, suggests that they are separate enough from the other Toads to be their own characters. The only issue I could really see is the fact that Yellow Toad in Super Mario Maker 2 has a similar personality to the Yellow Toad from the Toad Brigade, though it still does not convince me enough to vote for that option currently. --TheFlameChomp (talk) 19:42, June 11, 2020 (EDT)

"Mailtoad" and "Banktoad" aren't really their names going by some lines of in-game dialog, however - they're just cute titles they had to fulfill roles in certain games, ala "Chief" and "Taskmaster". It's obviously not applicable to all their appearances as members of the Toad Brigade. And if we strictly leave Super Mario Maker 2 out of it, then Yellow Toad is technically unnamed within the context of the Toad Brigade. That's on top of his characteristic narcolepsy being gone in Super Mario Odyssey. LinkTheLefty (talk) 20:25, June 11, 2020 (EDT)

Have Mailtoad, Banktoad, or Hint Toad ever been officially referred to as Purple Toad, Green Toad, or Blue Toad, respectively? --TheFlameChomp (talk) 22:03, June 11, 2020 (EDT)

So if "originally planned" succeeds, would the remaining three SMM2 ones get new articles anyway? Since, as I said, "Purple Toad" is explicitly the actual, birth-given name of that one. Doc von Schmeltwick (talk) 15:25, June 11, 2020 (EDT)

I don't think there would be anything stopping it, so it's whatever the community decides. I figure if they did get articles, passing a second proposal to get new ones for the blue and yellow Toads for consistency probably wouldn't be that hard (though the yellow one having the Brigade member's personality might be an issue there). I don't really have an opinion on it since I don't have the game and haven't seen how relevant they actually are, but at the very least Purple Toad probably qualifies for an article by MarioWiki:Naming alone. -- Too Bad! Waluigi Time! 19:13, June 11, 2020 (EDT)

Abolish the No-Signature Policy

keep in effect 2-5
The no-signature policy is a policy that has pretty much become pointless nowadays yet it stil exists. Back when it was first established it used to be effective and one used for on various different things including this proposals and the long extinct Pipe Projects and Featured Images. Over the years the amount of pages this policy is used for has decreased massively but now as far as I’m aware this policy is only used in two areas: featured articles nominations and in both cases its useage does not match what the policy states.

In the case of featured articles nominations, there is no enforcement of it whatsoever. Here users just decide to put their regular sig in when they comment and they are not corrected or told off for doing so.

With appeals, it doesn’t even follow the guidelines the no-signature policy lists. No-signature policy recommends people to use {{User|User Name Here}} and forces users to link their user page or talk page when writing a comment. Neither of theses are present when writing appeals.

Therefore because of the reasons I listed above I believe the best thing to do here is to abolish policy altogether. Should this proposal pass these changes will be implemented

1. The deletion of Mariowiki: No-signature policy
2. Mariowiki: Featured Articles and Mariowiki: appeals will no longer mention the no-signature policy.
3. Signatures will now officially be allowed on the comments of featured articles nominations (even though they have be used for awhile anyway)
4. A message will be written on the appeals page asking people not to sign their comments.

If anyone has any amendments they would like to make to this proposal, feel free to suggest in the comments.
Proposer: NSY (talk)
Deadline: July 4, 2020, 23:59 GMT

Support

1. NSY (talk) Per Proposal
2. PinkYoshiFan (talk) Per proposal.

Oppose

1. Alex95 (talk) - I don't see a good enough reason to outright remove this. I believe the reason why it was made in the first place was so signatures do not take up too much space. You can see examples of this in older proposals from the first few years of the wiki. For proposals, feature/unfeature nominations, and appeals, I'd rather use the {{user}} template. Signatures are mainly meant for signing talk comments, but can feel like they are in the way in the case of larger signatures (like mine) if used for anything else. EDIT: Additionally, sometimes they are irrelevant, like (using an example from earlier today) Scrooge200 signed his proposal in the proposal text, which isn't necessary when we also say to list the proposer directly after the proposed changes. I realize that's probably a mistake on Scrooge's part, but you usually sign your comments on pages, so the no-signature policy exists to say that you don't need to sign your comments/votes in specific areas.
2. HEROWALUIGI (talk) Same as Alex95.
3. FanOfYoshi (talk) Per all.
4. DarkNight (talk) Per Alex95.
5. TheFlameChomp (talk) Per Alex95.

Comments

By the "deletion" of the policy, you mean that there should be an {{abandoned}} template at the top of the page? ^(T|C) 10:12, June 27, 2020 (EDT)

correct me if i'm wrong but i'm pretty sure that the no-sig policy is unnecessary for proposals at least. if a sig is too big, it leads to a sigfix template. and even the largest of legal sigs wouldn't take up that much space. also, if a signature is coded in such a way that it messes up a good portion of the page it will probably be fixed rather quickly. but appeals makes sense
i'm going to be staying neutral for now. TheDarkStar 10:25, June 28, 2020 (EDT)

Yeah, we keep signatures within a size limit, but by "size", I meant more like unnecessary space usage. If you vote with {{user}}, you don't need the signature, because your name is already there, so the signature is just irrelevant. 22:59, June 28, 2020 (EDT)

Split the Paper Mario: Sticker Star and Paper Mario: Color Splash attacks

split 19-0
This is something that has been bugging me for a long time.

Currently, each attack in Paper Mario: Sticker Star and Paper Mario: Color Splash is merged into a giant list: Sticker (Paper Mario: Sticker Star) and Battle Card (Paper Mario: Color Splash). There are many problems with this current arrangement.

• They're all different. Some have different action commands, they all do different amounts of damage, have different strengths and weaknesses, different buy and sell values, different descriptions, different sprites, different animations...
• Each attack from the first two games are split: see Hold Fast, Dizzy Shell, and Fiery Jinx.
• Linking to Worn-Out Jump is easier than Battle Card (Paper Mario: Color Splash)#Worn-Out Jump.
• Things are special attacks that have different locations, different prices, different descriptions, designs, and animations, hints as to where each one is... A majority of them are required to beat Color Splash.
• Some attacks, like the Hopslipper, appear in both Sticker Star and Color Splash. Thus, the Hopslipper page has links to the two attack lists. It'd be much easier and more efficient to keep them on one page.
• The Hurlhammer is going to return in Paper Mario: The Origami King. What will that page's attack list be? I don't want to end up with an article called "Weapon (Paper Mario: The Origami King)" or "list of attacks in Paper Mario: The Origami King." It'd be flat-out incorrect to treat it as exclusive to The Origami King, too.

If this proposal is passed, the following changes will be made:

• Sticker (Paper Mario: Sticker Star) and Battle Card (Paper Mario: Color Splash) will still exist. We'll just give the attacks present their own pages: each The Thousand-Year Door badge has an article and List of badges in Paper Mario: The Thousand-Year Door exists.
• Every Sticker and Battle Card will receive their own article. If they're the same, like Blazehammer, we cover both the SS and CS info on the same page. In cases like POW Block, we'll include the information on the object's main article and not make a "POW Block (Paper Mario series)" article or anything.
• Every Thing will get its own article.
• Enemy Cards from Color Splash will remain as a list and not get their own articles.

Proposer: Scrooge200 (talk)
Deadline: July 4, 2020, 23:59 GMT

Support

1. Scrooge200 (talk) Per nomination.
2. Waluigi Time (talk) Per proposal.
3. HEROWALUIGI (talk) Per Propsal
4. Magolor04726 (talk) I think I was the one who started this thing by asking if there was a list of where to find things. Definitely will help if this passes. (Also, if this isn't how I should post this, I apologize. I'm a super noob at things like this)
5. Mister Wu (talk) sounds good to me, if anything I think it’s time to cover the recurring attacks in the new Paper Mario games, especially those that are going to be featured in The Origami King.
6. Toadette the Achiever (talk) Yeah, sure. Per all.
7. TheFlameChomp (talk) Per all.
8. TheDarkStar (talk) - per all
9. Doc von Schmeltwick (talk) Recurring items, so obvious yes. This has bugged me for a while, along with the SMRPG lists.
10. Niiue (talk) Per all.
11. Alex95 (talk) - Per all.
12. BBQ Turtle (talk) Per all.
13. FanOfYoshi (talk) Per all.
14. Duckfan77 (talk) Per all.
15. Yoshi the SSM (talk) Per all.
16. DarkNight (talk) Per all.
17. PinkYoshiFan (talk) Per all.
18. AwdryFan1997 (talk) Per all, but also because anything differentiating Color Splash and Suck Star is something I'll support. But mostly per all.
19. LinkTheLefty (talk) Pe rall.

Comments

Would attacks such as Worn-Out Jump ×3 and Worn-Out Hammer ×3 be made into their own articles, or would they just be mentioned on the Worn-Out Jump and Worn-Out Hammer pages, respectively? I am not necessarily against it either way, I am just wondering. --TheFlameChomp (talk) 22:38, June 27, 2020 (EDT)

I was wondering about this, and I think now that we'll give them separate pages. They're still unique cards with separate museum slots, plus it'd be easier to say their buy/sell prices and locations. Scrooge200 (talk) 23:42, June 27, 2020 (EDT)

We have separate pages for triple Mario Kart items now, so it makes sense. Doc von Schmeltwick (talk) 01:23, June 28, 2020 (EDT)

Merge Game Boy Donkey Kong enemy variations / Split Wario World enemy variations

split the Wario World enemies 0-9-0
Donkey Kong for the Game Boy and Wario World have one thing in common: both games often change an enemy's design and name to reflect the environment, while keeping its behaviour intact. However, for each game's case, we apply a different type of coverage. The Donkey Kong enemy variations are currently split from each other, such as in the case of Aqua Man, Miira, Golem and Robo NO.1 having their own pages despite being the same concept, while Wario World enemy derivatives such as Magon, Clowns, Snowmen, Wolves etc. all share the same page. This proposal seeks to find a consistent treatment for enemies that only differ by appearance and name.

Proposer: Bye Guy (talk)
Deadline: July 11, 2020, 15:20 GMT

Split Wario World enemy variations

1. Bye Guy (talk). I am in favour of this option, as there is precedent of this type of coverage with enemies such as Klomp/Neek, Sour Dodo/Cheesy Chester etc.
2. Waluigi Time (talk) They're obviously different enemies that just use the same behavior and attack patterns, it's not like the same enemies in Odyssey wearing different hats to be more thematically appropriate. Not to mention I'm concerned that leaving the Wario World enemies merged would lead down an extremely slippery slope of "different enemy + same behavior = merge".
3. Toadette the Achiever (talk) We've split out far similar subjects, so this makes sense. Plus, despite the minor behavioral changes, their aesthetic changes are so sporadic that it's hard to consider them the same thing (you know, unlike the case with red/green Koopa Troopas).
4. FanOfYoshi (talk) Per all.
5. Duckfan77 (talk) Per all.
6. DarkNight (talk) Per all.
7. Doc von Schmeltwick (talk) Per proposal, since most WW variations have official names now. I will note, however, that GBDK's Metroid-esque enemy reskins do sometimes have subtle differences (notably Bowbow freaking out when Mario gets the hammer compared to its later counterparts) and are all listed separately in the Perfect Daijiten anyways.
8. TheFlameChomp (talk) This option makes the most sense, since the variants have their own official names, and it is consistent with the other similar subjects that have been split in the past. Per all.
9. LinkTheLefty (talk) All per.

Split the Super Mario RPG item lists

split all 7-0
So all the "normal" items in SMRPG are split, but them we have weird giant lists mixed in that do not at all mesh with how we handle other RPGs (aside from M&L gear, which doesn't have any visual distinction associated with them). Now, this is clearly a relic of the early days, but it's still a decently major change. As I said I would do if the sticker/scrap proposal for the PMSS/PMCS games succeeded, I hereby propose to split the following list pages:

• Accessory (Super Mario RPG: Legend of the Seven Stars) - Vaguely comparable to gear, but generally look nothing alike in their artwork.
• Armor - This one is the most comparable to the M&L gear, but note the different artwork as opposed to those just having identical sprites.
• List of weapons in Super Mario RPG: Legend of the Seven Stars - This one is especially notable in that some pages, like hammer, Chomp, and frying pan, already are split due to repeat appearances. Additionally, "Noknok Shell" is just a mistranslation of "Koopa Troopa shell," adding more tinder to the idea of changing how we organize shells, but I digress.
• Special Items (Super Mario RPG: Legend of the Seven Stars) - Various things that happen to share a menu. Some are keys, some are cards, but there's a lot of variation.

(On the off chance there's a list of the same type I missed, then those too.)

Proposer: Doc von Schmeltwick (talk)
Deadline: July 12, 2020, 23:59 (GMT)

Support

1. Doc von Schmeltwick (talk) Per proposal.
2. Waluigi Time (talk) Per proposal.
3. TheDarkStar (talk) - per proposal
4. Duckfan77 (talk) Per proposal
5. DarkNight (talk) Per preposal.
6. Toadette the Achiever (talk) We'll no doubt have to consider splitting out clothing items from the Mario & Luigi series, but this is at least a start. Per proposal.
7. TheFlameChomp (talk) Per proposal.

Cover fan-made Super Mario Maker courses highlighted by Nintendo

allow coverage 5-0
Sometimes, Nintendo would highlight select Super Mario Maker courses by e-mailing them to their newsletter subscribers or publishing them on a platform like Play Nintendo. While these courses would be considered fan-made content, I think they deserve some type of coverage here on grounds that they have been acknowledged by Nintendo directly. They should be listed on a page along with their preview pictures, makers, Nintendo-given descriptions, and IDs.

Proposer: Bye Guy (talk)
Deadline: July 28, 2020, 22:54 GMT

Support

1. Bye Guy (talk) this is a similar situation to the coverage we offer to certain memes and knockoffs.
2. DarkNight (talk) Per Bye Guy.
3. Waluigi Time (talk) Per all.
4. Toadette the Achiever (talk) Yeah, sure.
5. Duckfan77 (talk) Per all.

Comments

Three questions:

• Will this proposal include levels mentioned on Nintendo's social media accounts? Does this change if the levels are not given a description from Nintendo?
• Will there be one article for levels from both Maker games or will there be an article for each game?
• Would a statement of an Nintendo employee, rather than the company, be enough to get a level onto this list? (As an example, would the levels featured in this article be included because an Nintendo employee was talking about them?) Salmancer (talk) 00:03, July 23, 2020 (EDT)

1. I did not state it in the proposal, but I aim to cover those levels that Nintendo has at least given a description. It doesn't matter where Nintendo gave them exposure, what's important is to have a place to store their own assessments on these courses. For instance, just because "Mecha Bowzilla" was featured in a trailer for SMM for 3DS doesn't mean it's elligible for coverage, neither do Special Collections courses on the Super Mario Maker Bookmark website.
2. It would make most sense to have an article for each game.
3. Good question, but I am not sure how to proceed here exactly. There is precedent on this wiki of covering an employee's personal assessment and opinions, as it is the case with Michael Vaughn. Also, in this article's trivia section, you can see that I added the designer's headcanon about the subject. I think it would be fair to follow in the same steps and summarize the employee's feelings about those SMM courses.

---- KOOPA CON CARNE 14:00, July 23, 2020 (EDT)

Remove the PipeProject and PipeProject Talk Namespace descriptor tags from the recent changes

canceled by proposer
Since the PipeProject is abandoned and the Recent Changes can only show changes for up to 90 days, the Namespace: PipeProject and Namespace: PipeProject Talk are practically useless.

Proposer: DarkNight (talk)
Deadline: August 9, at 23:59 GMT
Date Withdrawn: August 3, at 19:19 GMT

Support

1. DarkNight (talk) Per my proposal.

Oppose

1. Alex95 (talk) - Just because they don't show up in Recent Changes anymore doesn't mean we should remove it. There really isn't much of a point to remove it, either, it's not hurting anything. Removing it might actually damage things, I don't know the full extent of what will happen if you remove an entire namespace when it is in use. For one, the pages "PipeProject:X" will show in mainspace categories and page searches, when they shouldn't.
2. TheDarkStar (talk) - per alex
3. Bazooka Mario (talk) You don't really see other namespaces like Gadget and Module showing up either. Perhaps they aren't actively dead like Pipeproject, but I see little reason to remove namespace all together only because they are unused.
4. Waluigi Time (talk) I don't think this is even possible without deleting the entire namespace. There's no reason to do that for what is in my opinion a minor nitpick.
5. TheFlameChomp (talk) Per all.
6. Toadette the Achiever (talk) To bring up another comparison, there is only one entry in the merge log. One. And yet it needs to stay because it documents a particularly exceptional case that can't go undocumented.
7. Keyblade Master (talk) This doesn't really seem like a big deal.

Comments

I'm confused at what this proposal is trying to accomplish. Do you want to remove PipeProject and PipeProject talk from the namespace selector in the recent changes? If so I don't think that's even possible without deleting the namespace. -- Too Bad! Waluigi Time! 18:10, August 2, 2020 (EDT)

Yes, what you just said. I'm pretty sure Porplemontage can do it. --DarkNight 18:12, August 2, 2020 (EDT)

definitions of undead and deceased

redefine the categories' scopes 10-0
As there is no clear definition so far, despite trying on Category:Deceased Characters from when someone will be listed under the categories Deceased Characters or Undead if he dies during or at the end of the game

That is why I suggest that the rules in the table on Talk:Bob-omb (Paper Mario: The Origami King)#Undead apply the rules

Alive	Deceased	Undead	Deceased & Undead
Alive Unknown just "exploding" and/or "defeated" bosses	died have been heavily implied to be dead (like crying or mention him in past-form) undead entity (not ghost!) but (maybe) not "alive"	ghosts and other undead entities	clearly lived once and died AND returned as ghost or other undead entity

Proposer: Pokemon (talk)
Deadline: August 6, 2020, 23:59 GMT

Support

1. Pokemon (talk) Per proposal
2. Waluigi Time (talk) Per proposal and my comments on Bobby's talk page. The handling of these categories is a mess right now and I think this is the best way to handle them.
3. Toadette the Achiever (talk) Yeah, I'm on board with this change.
4. Keyblade Master (talk) I suppose it will make handling these categories a little bit easier.
5. Duckfan77 (talk) Per all.
6. DarkNight (talk) Per proposal.
7. Bazooka Mario (talk) I think we should restrict it to characters that have died or their identity is tied to more to being dead than alive (so we include Wrinkly Kong, who is alive in on egame but turned into a ghost and remained that way for the rest of the games).
8. TheFlameChomp (talk) Per proposal, it feels like giving these an actual definition will make handling the categories easier and help prevent confusion.
9. Jazama (talk) Per all.
10. MarcycinTheViceKingBoo (talk) Per all

Comments

• Clarification; I would be the final state as a time of definition (ie post credits) otherwise, for example, all residents of Sammer's Kingdom would have to be declared "dead" Pokemon (talk) 11:17, July 30, 2020 (EDT)

Yeah, obviously characters that are eventually brought back to life shouldn't be classified as dead. -- Too Bad! Waluigi Time! 12:02, July 30, 2020 (EDT)

For this reason Olly and Olivia should be listed under died Pokemon (talk) 12:16, July 30, 2020 (EDT)

I'm still a bit iffy, but I guess I'm just stuck on what I already know the category to be used for. I believe it was meant to be applied to characters that were never shown to be alive to begin with (King Croacus I) or were already dead by the time the game started (Wrinkly Kong in some cases). Characters that died partway through the game does make this category confusing, as the category does not apply to them for the entire time they are on screen. Bobby is obviously alive at the start of Origami King, for example, so to mark him as "deceased" would not be 100% accurate. 14:37, July 30, 2020 (EDT)

By that logic he's not alive the entire time he's on screen either so not marking him as deceased wouldn't be 100% accurate. Taking that to a logical extreme, the Paper Mario partners aren't instantly in your party the moment they appear, and in the original game all of them leave your party in the epilogue. Should we not categorize them as partners just because they aren't constantly in your party throughout the entire game? Personally, if I'm looking at a category of deceased characters I want to see all the dead characters in the franchise, not what's essentially a list of only characters who died offscreen, and I would think that's what most readers would be looking for. Besides, you have to have been alive to be dead, why should only ever being alive offscreen make a character more eligible for the category? The current usage of the "Deceased Characters" category is incredibly confusing as the whole situation regarding Bobby has shown, and it doesn't help that this supposed "rule" has never actually been on the category page, making me wonder where it even came from in the first place - has it ever been what the category is supposed to be for or is it just the personal preference of some users (and if it's the latter, why was it ever enforced in the first place)? -- Too Bad! Waluigi Time! 15:26, July 30, 2020 (EDT)

While this is certainly a step in the right direction, I take a bit of issue with considering "ghosts in general" to be undead. The generic enemy ghosts in LM, for example, were created as such by van Gore, and as such were never "alive" nor "dead" prior, and as such cannot have "un-died." This is an example of "paranormal" being a more accurate term, though of course there are cases like Wrinkly, Krow, Dry Bones, Dry Bowser, Bonetail, and Bobby where they actually are undead. Doc von Schmeltwick (talk) 15:34, July 30, 2020 (EDT)

That could probably be easily solved by splitting all the ghosts into their own Undead subcategory, which technically still classifies them as undead but it's better than the current setup in that regard. There's certainly enough of them in the franchise to make it worth it, especially considering we've already given Skeletons, Mummies and Vampires their own categories with the latter two having only 16 and 8 entries, respectively. -- Too Bad! Waluigi Time! 15:53, July 30, 2020 (EDT)

I'd be in favor of just scrapping the category entirely. LinkTheLefty (talk) 18:10, July 30, 2020 (EDT)

Honestly, I thought of that earlier today too. Nightwicked Bowser

I don't really think the fact that Nintendo can resurrect any character they want on a whim (which any fictional series can do) makes a deceased characters category less useful. By definition it's supposed to contain all characters that are dead according to the current story. Besides, it happens so rarely anyway (I don't even know of any other examples besides the Fawful one, aside from maybe the overly dramatic SMW flavor text for some of the Koopalings) and it's not like it's that hard to remove a single category from a single page if it does happen. -- Too Bad! Waluigi Time! 19:13, July 30, 2020 (EDT)

Delete the Paper Mario: Sticker Star sticker variation articles

delete 9-0
I was going to do this already, though I suppose maybe a proposal is the right way to go in this case.

Now that a proposal to split the attacks in Sticker Star and Color Splash was successful, I fail to see how the articles Shiny, Flashy, Big Shiny, and Megaflash will have any foreseeable use in the near future. In the event that said four articles remain after the articles dictated by the aforementioned proposal are all accounted for, the former group will essentially just parrot every bit of information from the latter group. If you want a better analogy, you might as well look at how various proposals concerning hypothetical parent species have fared. After all, it's no different here; these are essentially hypothetical "parent" variations.

Basically, I propose we delete the aforementioned articles for being hypothetical and redundant.

Proposer: Toadette the Achiever (talk)
Deadline: September 13, 2020, 23:59 GMT

Support

1. Toadette the Achiever (talk) We simply can't let these four articles outshine the importance of the aforementioned proposal.
2. Shokora (talk) – Per proposal and the precedent set by the examples provided.
3. Waluigi Time (talk) This can easily be covered on the main sticker article or the articles for the individual stickers.
4. Bye Guy (talk) Per proposal.
5. TheFlameChomp (talk) Per proposal.
6. Scrooge200 (talk) Maybe they'd be better as a list or a category. Either way, I think the articles can be deleted now that we're improving our SS and CS coverage.
7. DarkNight (talk) Per proposal and Scrooge200.
8. Niiue (talk) Per all. These are categories in page form.
9. Keyblade Master (talk) Per all, but maybe after more of these individual articles get created.

Allow blank votes as an implied "per all"

forbid 4-8
This is something that's been bothering me ever since Baby Luigi and Bazooka Mario first mentioned it around a year ago. Currently, every vote is required to have some reason attached to it, even if it's a simple "per all" vote. Going back to what they said...

“honestly i say we're far better off getting rid of the reason required rule to begin with: a reasonless vote is pretty much just a stealth "per all". a vote is a vote. i still have the same power regardless if i write two words due to bandwagoning or type a 1000 word essay.”

—Baby Luigi

“I do think that rule of "Every vote should have a strong, sensible reason accompanying it" is not necessary. Per all and blank votes are simply just reiterating the other positions. To assume the worst from blank votes kinda runs against the whole "assume good faith" sort of thing.”

—Bazooka Mario

I agree with them, I really don't think "per all" votes are necessary, and I certainly don't think the requirement that you have to per yourself to support your own proposal is necessary. If this proposal passes, blank votes will be allowed as an implied "per all" vote. A blank vote still cannot be made if there isn't anyone to per in the first place. Having to per yourself on your own proposal would also no longer be necessary, since your arguments should have already been made when proposing it.

Also, just to clarify, "per all" votes will still be allowed if users want to make them, just not required.

Proposer: Waluigi Time (talk)
Deadline: September 14, 2020, 23:59 GMT

Support

1. Waluigi Time (talk) Apparently my vote is invalid unless I specifically say that I agree with myself. (See why I made this proposal?)
2. TheDarkStar (talk) per proposal
3. Bye Guy (talk) Per all.
4. Niiue (talk) Per all.

Oppose

1. Shokora (talk) – I don't think a minimum of two words is too much trouble, considering how formal other aspects of the proposals system are meant to be. Users often add further reasoning to reinforce their "per all" vote, which is good to have on record and probably wouldn't happen so often if we default to not writing anything at all. Less isn't more in this case.
2. Scrooge200 (talk) Proposals are both a vote and a discussion. What good is your vote if you don't have any reasoning? A small "I agree with everyone else and don't anything much to add" is better than just voting and not saying anything about why.
3. DarkNight (talk) Per all = only two words. We shouldn't be lazy, it's only seven letters.
4. TheFlameChomp (talk) Per Shokora.
5. Plumber (talk) Per Scrooge200. (That wasn’t so hard, was it?)
6. Mario jc (talk) Per all; I feel like this would also open the floodgates even more of users voting just to jump on the bandwagon without actually meaning their vote.
7. Toadette the Achiever (talk) Okay, yeah. Per Mario jc.
8. Keyblade Master (talk) I don't think blank votes would be fully clear.

Comments

Additionally, all voters must still provide a reason until this proposal passes. Shokora (talk · edits) 21:40, September 7, 2020 (EDT)

While allowing blank votes in place of “per all” is not a big deal, I’m not comfortable with the premise. Votes based on statements proved to be wrong don’t have the same power as validly motivated votes, if anything I wouldn’t allow decisions in clear contrasts with the games or what Nintendo says as it would go against the basic aim of the wiki. I think this is one of the reasons why a motivation for the vote was asked to begin with.—Mister Wu (talk) 21:52, September 7, 2020 (EDT)

@Shokora: Sure, it's not too much trouble, but that's not the point of this proposal. The point is is it even necessary? If this passes there's nothing stopping users from making elaborate votes if they want to, they can even continue making "per all" votes if they feel so inclined, but if you don't have anything to add to the conversation, why should you have to? I also question how "formal" proposals really are since I've seen humor sprinkled into otherwise serious proposals many times.

@Scrooge200: I think you misunderstood the point of this proposal. It's not to allow votes with no reason whatsoever, but instead to allow blank votes to function identically to a "per all" vote. I'd even argue that blank votes might actually be beneficial to the proposal system by drawing more attention to the people who do give reasoning. -- Too Bad! Waluigi Time! 11:28, September 8, 2020 (EDT)