merge 12-0
There are several items from Paper Mario: The Thousand-Year Door which are clearly intended to return in Super Paper Mario, but have different pages due to having different English names. Considering that they look identical and usually have the same name in every country except the US, they should probably be merged as per the precedent set by moreproposalsthanIcancount. As for the items having slightly different effects between games, thathappensallthetime.
Magikrazy (talk) I would question whether or not this proposal is necessary, but either way it would be nice to have a single proposal to point towards should the issue ever come up again.
Yoshi the Space Station Manager (talk) I am wondering about whether it should be a proposal. Either way, Spaghetti and Spaghetti Plate are the only ones mentioned that actually have a big noticeable difference. Besides that, Roast Shroom is slightly different texture from Shroom Roast. That said, I am not 100% sure if we should merge Spaghetti and Spaghetti Plate, but I am 100% ok with the others merging.
Alex95 (talk) If they have similar attributes, then a merge is totally acceptable. It's possible name changes can occur over time, after all.
TheFlameChomp (talk) Almost all of them look very similar to each other, and, since multiple proposals that are very similar to this have been made before, I support these merges. The only one that I am not 100% sure about is Spaghetti and Spaghetti Plate, since they have big differences in their appearance.
Allow users to make a user subpage for 'Shroom sections
don't allow 1-8
I made a proposal that would allow users to make a sub page filled with all of their 'Shroom sections. (See the proposal archives) Only I voted so it was 'NO QUORUM'. I am asking for more users to vote, not just me.
In the page, users would copy their section from an issue of The 'Shroom and paste it onto their page (unless if there is a way to translude it). Users can choose what sections to put in it. They can put either all of their sections, their favourite ones, or have one section and replace it each time they write for The 'Shroom. Users can slo choose to link sections if they want to.
This would make it easier to find sections made by a certain user without wasting time looking through the archives. This page will also make it easy to count how many sections a particular user has written.
Lord Bowser (talk) This wouldn't be a good idea in the long run. Many 'Shroom writers, such as myself, have written massive sections in the past, or have simply written a very large amount of sections. Transcluding whole sections into a userpage would lead to said pages easily taking up 100k+ bytes, reducing load times and clogging up the wiki. Userpages simply made for linking to sections seem rather unnecessary as well, as it could just as easily be done on the writer's main userpage.
Luigi 64DD (talk) Per Lord Bowser. Also, the rules say that subpages that serve the wiki can be created in addition to signatures and the like. Having a separate page filled with 'Shroom sections wouldn't really serve the wiki.
You forgot to title your proposal, by the way.LB (talk • edits • forum) 14:26, 30 March 2017 (EDT)
I want to point out, regarding the "make it easy to count how many sections a particular user has written", we do have this. --™The 'Shroom 03:52, 31 March 2017 (EDT)
repurpose 14-1
As highlighted by Magikrazy (talk) in this forum post, the necessity of the {{userspace}} template has come under question. His main concerns are that it seems redundant to hand out when a user overly edits in their userspace, and that the template itself is too wordy and takes too long to get to the point. Baby Luigi (talk) also mentioned that many users with high userspace edits often have it due to experimentation with wiki coding, which is a productive use of editing if it is meant to go onto official articles.
These two reasons is why I propose a restructuring of the userspace template; removing the too many userspace edits reason, and just sending out (in)formal reminders for that instead on a case-by-case basis. I also propose reformatting the template so that it only covers genuine violations of the userspace policy and gets to the point faster. This way, the template won't need to be handed out so liberally, and it will better get the attention of those in violation of the policy.
Proposer: Lord Bowser (talk) Deadline: April 12, 2017, 23:59 GMT
Toadette the Achiever (talk) While it seems detrimental to retire the temple altogether, it also seems pointless to not improve it. Perhaps it should only be issued if A) the user in question makes more than five or six major edits (500 bytes or more) to their userspace, and B) these edits all have little or no relevance to the project (such as, you know, using the wiki as a web host). While the status quo isn't the worst (Bulbapedia, for example, has an even stricter (and maybe an even more "needlessly patronizing") policy on userpages), I'd say it's definitely worthy of improvement.
Magikrazy (talk) Per myself and Baby Luigi in the linked forum thread.
Turboo (talk) - Per all; trimming it down and making it clear when (not) to use it is a needed improvement to the template
Luigi 64DD (talk) Having experienced the overuse of this reminder first hand (although it was overturned by an Admin almost immediately), I agree we need to make more clear what type of situations this reminder should be issued in. Per all.
Wildgoosespeeder (talk) You can say that a userpage is a great place to practice MediaWiki syntax but we should encourage redirecting those people's attention to do that in MarioWiki:Sandbox. Keeps attention off the user namespace. There is a reasonable argument that, in general, Bulbapedia is too strict. In general, I feel that MarioWiki is too relaxed. I think we can find a happy middle ground, but this proposal as it stands right now isn't it.
Comments
@Toadette the Achiever - I don't propose removing it entirely, since it can still serve a legitimate purpose. I just wanted to retool and rewrite it so that it would only be issued in the case of userspace policy violations, and informal reminders being sent out in the case of excess unproductive userspace edits. This would increase to formal reminders and warnings if it persists, similar to the current policy in place. LB (talk • edits • forum) 19:02, 5 April 2017 (EDT)
Something lacking is the link to Special:Editcount. This is clearer than Special:Contributions because one page keeps count of edits while the other lists each edit made by the user. Here's me:
@Wildgoosespeeder - It is important to remember that many users, including yourself and myself, have their own personal sandboxes under userspace, used for things such as template drafts, policy drafts, experimentation, and so on. All of these edits add up on Special:Editcount under the User row. Encouraging people to use the wiki sandbox when you have your own personal one is contradictory and borderline hypocritical. LB (talk • edits • forum) 04:15, 6 April 2017 (EDT)
If anyone was curious, I've created a potential new userspace template on my sandbox. Feel free to comment on anything that should be changed within it. LB (talk • edits • forum) 04:48, 6 April 2017 (EDT)
Damn Wildgoosespeeder, you've got more edits than me :'( @Lord Bowser, that proposed template seems fine. Like Template:Sigfix, the wording around the policy is very general, which leaves it to those who are issuing the reminder to personally advise the user on exactly what they've done wrong (such as excessive userpage edits, creating unnecessary subpages). Shokora (talk · edits) 08:13, 6 April 2017 (EDT)
I think that number of user space edits alone does not determine whether a user is editing their user space too much. For example, a user may use a sandbox to work on a very big project. This would not be in violation of policy because it is helpful to the wiki. What is not allowed is making a very large number of edits on pages that are not helpful to the wiki, such as a main userpage, while making little to no mainspace edits. I think that the template cloud be rewritten to make that clear, as well as adding detail about other types of userspace violation. --Super Mario Fan 67 (T•C•S) 08:56, 6 April 2017 (EDT)
Discourage OGG Extension (Not Format)
Discourage OGG extension (but not OGA and OGV) 10-0
The *.ogg extension is a generic extension to describe the *.ogv and *.oga file formats. To put that into perspective, that would be like clumping all *.jpg, *.png, and *.gif file extensions to be under *.img or something*.html, *.xml, and *.rtf formats to be included with what we expect of the *.txt extension. Yes, those files all contain easily readable text if opened in Notepad, but it would be very hard to tell each file apart if all HTML, XML, and RTF files all had the TXT extension instead. To make things more easily identifiable on MarioWiki, I propose that *.ogg be a discouraged extension for a file of this type when uploading. Sure, MediaWiki can detect the MIME type regardless of extension, but that's not immediately clear when sifting through categories.
Xiph.Org Foundation, the developers of OGG, recommend the extensions I am proposing[1]. VLC Media Player already registers all known extensions of this standard. My guess is back in the day, OGG was just audio (such as DX-Ball 2) but things were getting more complex so they needed to have a better extension to represent the complexities of the standard and discourage the old extension.
To be clear, I am not looking to discourage the format, just the one extension of the format. OGV and OGA are perfectly safe. There are around 1,000 files to check and move. Let's get them changed before we end up with a insurmountable amount of files to make changes to. I think Pywikibot can do this stuff automatically.
{{media table}} - Update it to allow for OGV and OGA as well? Code for row one but apply similar code for each row after it: {{media table/{{#switch:{{{type1|}}}|video=OGV|audio=OGA|#default=row}}|type={{{type1|}}}|name={{{name1|}}}|pipe={{{pipe1|}}}|description={{{description1|}}}|caps={{{caps1|}}}}}
Yoshi the Space Station Manager (talk) My browser (at least the one I use the most as I also have Google Chrome, but I not really going to mess with ogg) doesn't even support OGG, OGA, or OGV. But, OGA and OGV are very different from each other. Banning use of OGG for both audio and video sounds good. But, what about applications if they ever become part of this wiki? What will happen to those? (I am only asking to point out all possibilities.) As for vandels that happen during this, there is a option not to show/hide bots which I have chosen to hide them and this is the only thing I have chosen to hide due to when bots work, it makes a lot of changes reflected on Recent Changes. Overall, I will support this decision.
Baby Luigi (talk) Nothing wrong with encouraging a better extension than a blanket one. The proposal previously supported a complete ban on .ogg which was too extreme for my tastes, but this is something I could get behind.
Toadette the Achiever (talk) I'm now convinced that this proposal will succeed. Per Baby Luigi and my comment below.
Mister Wu (talk) If this simplifies life for the Wiki editors and staff, I support the idea. It is recommended by the Xiph.Org Foundation anyway.
TheDisneyGamer (talk) I'm in the same boat as Yoshi; my Browser (Firefox is what I'm using currently) doesn't even support .OGG files. I definitely support this idea.
Oppose
#Lord Bowser (talk) There is apparently no technical difference between .oga and .ogv, while there are differences between .png, .jpg, .gif, etc, which renders that point in the proposal moot. I can't really imagine a scenario where only having .ogg would hinder the wiki in any aspect, and besides, .ogg files are relatively infrequently uploaded and used here. Banning the .ogg extension in place of .ogv and .oga seems like a lot of hassle for little benefit, as like you said, thousands of files would need to be moved; however, even more articles than that would have to be edited in order to correctly reflect the moved files, which is a pretty big task even with bots. This is a good idea on paper, but the benefits of implementing this seem to be outweighed by the sheer level of editing that needs to be done across every article that uses .ogg files. #Toadette the Achiever (talk) Per Lord Bowser. It indeed sounds rock-solid on paper, but if you think more deeply about it, why would it even be necessary to ban one extension when the two umbrella extensions work very similarly to each other, yet are used differently? If anything, I say we ban OGA and OGV because sometimes having less options can actually benefit and relieve more than harm. Unless you can give some other reason for banning OGG, I'm afraid I'll have to oppose. #Baby Luigi (talk) The idea to split the sound files and video files into their own compartments sounds like a good idea on paper, but I think the creation of another category specifically dealing with .OGV versions of .OGG would be more useful in the long run, as we don't have to bend backward to change this rather common file extension across the wiki. As the above two stated, I think too much energy required is worth the hassle of what amounts simply a name change with very little benefit to it whatsoever. Furthermore, .OGG is the default extension for many programs I use such as VLC and Audacity, and I think it's just too much of a hassle going through the extra step of renaming the extension to meet these proposed standards. If you want to rename extensions from .OGG to .OGA or .OGV, no one is stopping you, since that's technically allowed, but I don't support an official, outright ban on .OGG formats either.
Comments
Sort of related...do we still need {{requirescortado}}? I thought browsers supported this by default. --Super Mario Fan 67 (T•C•S) 17:43, 25 April 2017 (EDT)
And what exactly is the difference between .oga and .ogv? Is it really significant enough to warrant banning the .ogg extension? This should really be further elaborated upon for those less experienced. LB (talk • edits • forum) 03:01, 26 April 2017 (EDT)
Technically, no difference between *.ogg, *.oga, and *.ogv. They are all defined by one standard, as I linked at the very beginning of the proposal. For MarioWiki, it would make maintenance easier by making all files by the standard easily identifiable by file extension rather than by MIME type. We should assign *.oga for audio, assign *.ogv for video, and forbid *.ogg rather than use the extensions interchangeably with audio and video data streams. By posing these restrictions, we can integrate {{media table/OGA}} and {{media table/OGV}} better than what is currently being done with the restrictive {{media table/row}} for *.ogg files only. --Wildgoosespeeder (talk) (Stats - Contribs) 04:33, 26 April 2017 (EDT)
No article editing required because the templates force .ogg, .ogv, and .oga for {{media table/row}}, {{media table/OGV}}, and {{media table/OGA}} respectively. Only one edit will take place, on {{media table}}. The rest is moving. You don't specify the extension if you use the template. Not sure why but OK. All that needs to be done is the move bot work, which I have my credentials hooked to, so this work is all me. I have done thousands of edits before at a time with Category:Beta Images by moving the remaining hundreds of images to Category:Pre-release and unused content images. It got done in two hours or so. If a vandal runs rampant during the transition, I immediately stop the bot so that way Special:RecentChanges doesn't render the vandal unnoticed. --Wildgoosespeeder (talk) (Stats - Contribs) 17:33, 26 April 2017 (EDT)
Yoshi the Space Station Manager (talk), this is just a browser issue. Chrome supports MP4, WebM, and OGG/OGV/OGA. Internet Explorer just MP4 (automatically) and WebM (with a codec installation by Google). For some reason, Internet Explorer forces you out of being able to play OGG/OGV/OGA. Just open up the file in an external application, such as VLC Media Player.
Applications? You mean like *.exe, *.zip, *.rar, *.7z? That's Porplemontage (talk)'s decision and I don't blame him for it.
People have brought up to flag my account as a bot temporarily but I don't use the bot often enough for it to be worth it. --Wildgoosespeeder (talk) (Stats - Contribs) 18:21, 26 April 2017 (EDT)
When I say applications, I am referring to something else the OGG covers which can be viewed on the Wikipedia site provided. Yoshi the SSM (talk) 18:26, 26 April 2017 (EDT)
I'm not entirely sure how MarioWiki can take advantage of those added perks of the OGG standard. Because of how the four media templates are coded, we just create additional templates for each extension and amend the switch.
.ogg
.ogv
.oga
.ogx
.ogm
.spx
.opus
If I really had my way with the four templates, I would delete the subpages and code everything into {{media table}}. --Wildgoosespeeder (talk) (Stats - Contribs) 18:56, 26 April 2017 (EDT)
Again, I'll be doing the work to get things up to standards. It's a one time deal. Title changed so the file extension is acceptable but should be moved to a better extension. --Wildgoosespeeder (talk) (Stats - Contribs) 20:39, 26 April 2017 (EDT)
Yeah...dissuasion is usually better than an outright ban. (T|C) 21:02, 26 April 2017 (EDT)
@Wildgoosespeeder, I've read everything, and I understand what you want to do, but I don't entirely understand why. First, you mention that "it would make maintenance easier by making all files by the standard easily identifiable by file extension rather than by MIME type." From an organizational standpoint, it makes sense, but what do you mean by "maintenance," and how does keeping the .ogg extension currently complicate things? Second, you said that "by posing these restrictions, we can integrate {{media table/OGA}} and {{media table/OGV}} better than what is currently being done with the restrictive {{media table/row}} for *.ogg files only." Is there only an organizational benefit here, or am I missing the bigger picture? Mario4Ever (talk)
Proposal now has a reason to move over each file to the extension based on standards by Xiph. Consider each subcategory of Category:Media files by game. They contain a mixture of audio and video under the extension OGG in most cases (only five uploaded files are up to Xiph's extension standards). I also explain a better example with text files why keeping the OGG extension is a bad idea. Right now, {{media table}} is calling {{media table/row}} only 30 times. With the switch code I can implement very easily, {{media table}} could call {{media table/row}}, {{media table/OGA}}, or {{media table/OGV}} depending on the type specified. The OGA and OGV templates were proposed, passed, and created, just never properly implemented. Also, Media table/OGA and Media table/OGV isn't transcluded very much compared to media table/row. The special thing about templates and categories is that if you edit the template to change its category, it affects all places it is transcluded, autosorting everything in Category:Pages with media files to go into Category:Pages with audio files and Category:Pages with video files. --Wildgoosespeeder (talk) (Stats - Contribs) 21:55, 26 April 2017 (EDT)
Baby Luigi (talk), you don't even need to do it through Audacity. You can just use Windows Explorer (or equivalent file manager) to change the extension or redlink with the OGA/OGV extension and upload the source file that kept OGG. File contents doesn't change. Just the file name extension. This is similar to how you can upload a file with the *.jpg extension onto a file using *.jpeg because File:New Nintendo 3DS and New Nintendo 3DS XL.jpg can exist separately. --Wildgoosespeeder (talk) (Stats - Contribs) 21:09, 27 April 2017 (EDT)
Just as I suspected. So it's just like changing a notepad file to a .bat file, nothing would really change if I edited the extension. Thanks for clearing that up. Ray Trace(T|C) 22:55, 27 April 2017 (EDT)
Exactly. To make it even more clear, MediaWiki would have thrown an error if I were to move an PNG image to a page with a JPEG extension for example. I tested OGV and OGA moves with two OGG files, described in the proposal, and MediaWiki didn't throw any errors. --Wildgoosespeeder (talk) (Stats - Contribs) 02:14, 28 April 2017 (EDT)
Create Template:Pmitem-infobox
create template 12-0
I've noticed that pages for Paper Mario series items don't really have a consistent format, usually having either Template:Item infobox or Template:PM recipe infobox. The problem is, neither template works very well, especially in terms of documenting the items' descriptions between games (the item infobox looks bad with multiple descriptions stacked on each other, and the recipe infobox doesn't even have a description field). Because of that, I propose that we create a new infobox for Paper Mario items, that way it's easier to document series-specific info in a convenient way.
Here's the current draft in my sandbox, which is mostly incomplete at the moment.
Proposer: Niiue (talk) Deadline: May 4, 2017, 23:59 GMT
Yoshi the Space Station Manager (talk) Sure, but we would have to get rid of recipe-info box because it repeats everything already mentioned, while what is proposed will bring new info as well. I also like the proposed name better than the recipe one.
Baby Luigi (talk) Sounds like a good idea to me. Per proposal.
TheFlameChomp (talk) Per all. Would the Template:PM recipe infobox be necessary anymore? All of the pages it is used on are Paper Mario items, and the new infobox would repeat certain information.
Toadette the Achiever (talk) That definitely sounds fine to me. I also agree that Template:PM recipe infobox would no longer be needed should this proposal pass. However, I wonder if we can do the same to the Mario & Luigi series, since the items listed are also in need of an infobox. Nonetheless, it's a good idea, and I see no reason to oppose in the long run.
Alex95 (talk) I don't know why we don't have this already. Per all.
I think it should really be called Template:RPGiteminfobox, since I don't see why this can't include the Mario & Luigi series as well. (T|C) 20:28, 28 April 2017 (EDT)
I plan to make it easier to implement series-specific sections if necessary, though. Niiue (talk) 23:22, 28 April 2017 (EDT)
@Wildgoosespeeder: I wouldn't worry about that too much at the moment, considering that the Stickers/Battle Cards don't currently have their own pages. Niiue (talk) 23:23, 28 April 2017 (EDT)
@Niiue: Perhaps then it would be better to create Template:Mlitem-infobox as well...? Maybe both could be created, but then I think they would have to match the respective color schemes for navigation templates. (T|C) 11:14, 29 April 2017 (EDT)
Sounds good. Niiue (talk) 16:16, 29 April 2017 (EDT)
canceled by proposer
Like many other readers of Super Mario Wiki, I have made the big mistake of reading the "Story" sections of game pages. This section gives spoilers that don't make the game as fun. I propose that we make a {{spoileralert}} template that warns users for spoilers. This template would go directly beneath the "Story" heading in game articles. Also, if this proposal is successful, I would like to know how to make this template, so please post here on my talk page.
Proposer: YoshiFlutterJump (talk) Proposed Deadline: May 12, 2017, 23:59 GMT Date Withdrawn: May 5, 2017, 19:29 GMT
Niiue (talk) Honestly, I don't see the harm in this. Every other game wiki I've been to has some variant of it, after all.
Oppose
Shokora (talk) – Per the arguments in this proposal. Essentially, entire articles could be spoilers. And as an encyclopedia, we should be presenting information as professionally and candidly as we can.
Wildgoosespeeder (talk) Spoilers in general, why are people so picky with plot details being revealed, even to the point of trying to get others to censor their own material? Also, how much time must pass for it to not be considered a spoiler anymore? Oftentimes, reveals are out of context. Reading text isn't as compelling as playing the game itself or watching someone else play. It's much more fun wondering how the conclusion is reached rather than seeing what the conclusion is. With something like the Mario games, we all know how things go. When has there ever been a plot twist? Spoilers are a mess that observers created and is out of control. In the context of a wiki, too much editing with little pay-off.
Supermariofan67 (talk) Almost the whole wiki contains spoilers. This would mean that almost all pages would require the template. Instead of doing this, it would make more sense to put a message on the front page (if we should do anything at all).
TheFlameChomp (talk) Per all. Almost every page would require the template, and MarioWiki:About already warns that the Wiki coverage includes unmarked spoilers.
Mario jc (talk) Per the proposal Shokora mentioned.
Ultimate Mr. L (talk) Per all. I'm not even sure if this proposal should be here, considering it's contradicting a past proposal.
The Koopa Bro. (talk) Per All. This entire wiki is a spoiler. If people want to avoid spoilers, they might as well stay of the internet, spoilers are everywhere.
Alex95 (talk) - Per the About page. It already warns that there can be spoilers. General disclaimer there. If you want this template made, we're going to have to rewrite policy.
Baby Luigi (talk) Per the reasons it got removed in the first place.
Comments
@Niiue: We are not every other wiki, though. Every wiki has their own rules. 12:22, 5 May 2017 (EDT)
Create templates for the Super Smash Bros. head images
canceled by proposer
I've noticed looking though Equipment#Equipment list that all of the head images for the characters in Super Smash Bros. look kind of tedious to type out. So, I thought it'd be easier and more efficient to have templates for the heads instead.
The code would be like {{SSBMMario}} for the Mario image from Super Smash Bros. Melee, which would turn out like this: . Currently, it's all linking to the image itself and, again, is rather tedious to type out: [[File:Mario SSBM.png|link=Mario|Mario]].
Codes would be as follows for each game (and just substitute "Mario" for the character):
{{SSBMario}} would lead to
{{SSBMMario}} would lead to
{{SSBBMario}} would lead to
{{SSB4Mario}} would lead to
In many cases, like the linked Equipment page above, these would be great to have. They're quick, efficient, and consistent. Unlike how the Equipment page is set up, where the coding is everywhere... These can be useful in several charts, either already created or could be created, where we would need to show only the head of the character for easy reference.
Proposer:Alex95 (talk) Proposed Deadline: May 18, 2017, 23:59 GMT Date Withdrawn: May 12, 2017, 19:29 GMT
I don't understand why this would be only for Super Smash Bros. characters. In the wiki, multiple instances of this is already used, like in Mario Kart 8, Mario Kart 7, Superstar Challenge. I personally don't see much benefit for this template. Ray Trace(T|C) 00:03, 12 May 2017 (EDT)
...Oh. I was thinking too single-focused here, it looks like. Completely forgot there were other games that used these types of mugshots. I could repurpose the proposal to cover everything like this, but.. oh, boy, that would be a lot of mugs to work with... Um, yeah, I think this was a good idea, but I'm just going to cancel this. I obviously didn't think this all the way through. Maybe I'll suggest this again in the future when I have all the facts and options straight. 00:18, 12 May 2017 (EDT)
New Notice Template: refrequest
No new template 5-10
Currently, there is only one template dedicated to pages that have unsourced information, which is {{ref needed}}. However, this template is meant for tagging singular, specific instances of uncited facts in a page. My proposal is that we create a new notice template to tag articles that, in general, have multiple instances of unsourced information throughout and need citations added to them. The tag would have the tag date added to it with {{refrequest|April 29, 2017}} and could be added to a specific article section with {{refrequest|section=yes}}, similar to {{rewrite}} and {{rewrite-expand}}, and the tag would also add the article to a category, probably Category:Articles with unsourced statements. For example, the article on Nintendo literally has absolutely no references/citations in the article at all; rather than adding {{ref needed}} after every single individual unsourced piece of information, it would be much easier to add a notice to the top of the page indicating that the page as a whole is in need of citations. It's worth mentioning that Wikipedia itself has 2 notice templatesjust like this, as well as a ref needed template.
I actually attempted to create this template last night, but it was deleted since it was created without permission. You can see what the notice would look like here.
Proposer: TheDisneyGamer (talk) Deadline: May 6, 2017, 23:59 GMT May 13, 2017, 23:59 GMT
Baby Luigi (talk) Eh, I don't see the harm in creating this template. Some articles could fine uses for it, specifically the glitch articles where it could list a very specific problem that rewrite template couldn't. Having a template like this can easily tell editors that the article needs better sources at a glance, and while the usage of this template is rather niche it would still serve a purpose. I'd support, because I don't see the downsides of having an extra template for citations.
YoshiFlutterJump (talk)This is a good idea, and is better than repeatedly using the ref needed template. Plus, if Wikipedia has it, so should we.
Yoshi876 (talk) I'm sure no one else will join me, but I really think this is unnecessary. I do agree that pages like Nintendo should have more sources, although mainly just in the history section, but I don't think a garish template at the top of the page is best for an otherwise fine article. Same with the glitch pages, in all honesty I see no issues with the {{ref needed}} being used in relevant areas. Also, should the proposal pass, I massively oppose the creation of a new category for it. It's asking for the exact same thing as Category:Articles with unsourced statements, just on a more large-scale situation.
Alex95 (talk) Per Yoshi876. I held off on voting for a while, but I really don't see the need for more than one template calling for the same thing. {{ref needed}} asks for a specific source, whereas this would cover the whole page, which I can see getting confusing as it wouldn't be clear exactly what needs to be sourced. And having both templates on the page would just look terrible and be redundant.
Mario4Ever (talk) Per Yoshi876 and Alex95. It's more important to let users know what specifically needs fixed (so they are better able to do it) than it is to let to know that something needs fixing. Doing the latter in this case makes it more difficult to determine whether or not citation issues have been (accurately) addressed down the line without someone poring over and interpreting the citation policy after every potential problem sentence. I would say that if an article requires users to do that, then that article has bigger issues than the source(s) of its information.
The Koopa Bro. (talk) Per all. Just because Wikipedia has it, doesn't mean the wiki should have, and as there won't be many pages that use this, it won't be to helpful.
Comments
Wikipedia has a different policy than us when it comes to creating citations though. We're far more lenient with trusting the userbase on information they have gained from playing video games. The only articles this would be really useful in are articles dealing with real world matters, like reception sections, development, rarely trivia sections, legacy, etc which are very few articles on this wiki. I don't think this template would be as useful as it is in other wikis and having just ref needed actually works (and most of the time when we come across that, we usually just outright delete it if people can't source their claims). Ray Trace(T|C) 14:14, 29 April 2017 (EDT)
For example, Wikipedia does not count YouTube as a reliable source, while we do, as long as the video is relevant to the questioned info. If anything, there could be a "better source needed" tag for sources that don't necessarily prove the into cited. (T|C) 15:04, 29 April 2017 (EDT)
You mean like this? Niiue (talk) 03:50, 1 May 2017 (EDT)
My only concern with an additional template is we already have {{ref needed}} and we could do something more clever with it. Is there any way to put an alert at the top of the page automatically by editing the already existing template? --Wildgoosespeeder (talk) (Stats - Contribs) 18:55, 1 May 2017 (EDT)
@Yoshi876: The point of a "garish" template is to direct editors to the main problem of the article, as being unsourced is clearly not fine. If it is being "garish", it's doing its job exactly as it is intended of informing readers of bad problems. In fact, I think it's even uglier on the flipside to what we're currently doing seeing the {{ref needed}} all over the place in the article (some articles can be mostly devoid of necessary cited sources) instead of all of those issues being congested into one template that does its job of immediately pointing out readers that a good chunk of statements that isn't sourced. It immediately notifies the reader, rather than the less apparent {{ref needed}} template. But this is an argument from an aesthetics point of view, which is, in itself, fallacious; we intentionally designed those templates to be hideous, garish, and ugly in the first place, you can't really fault it when we designed it that way to begin with. Though the new category proposed isn't such a great idea that I pretty much agree with. Ray Trace(T|C) 15:38, 2 May 2017 (EDT)
A lot of our articles are unsourced, as you say we trust editors from what they find in game. Articles like Nintendo and Sega I think should be better sourced, but I don't think a template like that at the top of the page is the correct way to do so, especially since much of the information is likely to come from the same place, so in all honesty I think a {{ref needed}} would suffice rather than a template at the top, especially when not everything is going to need be sourced. I can see the point with glitch pages, but in all honesty I think a better policing system is required, rather than a template. Yoshi876 (talk)
And that's why I said that its purpose is niche, but the niche purpose fills a role that the rewrite template doesn't necessarily cover. A lot of articles on the wiki can benefit from this, and this additionally includes sections where a template like this is necessary, and while it's not a lot of articles and only some sections, it's a purpose that's there (many reception sections, such as Mario Kart 8 Deluxe's, needs references). For the glitch page, some glitches can be really sworn to be true but the glitch just happened at a bad time and bad place where you couldn't capture it (though I think better glitches are those that can be replicated, sometimes glitches are caused by faults in the CD and we don't count those). Also, you're making assumptions about Nintendo's article. You're saying that it's "likely" that the information in Nintendo's article comes from one source, but that is not necessarily true in cases like these. Some details you read and some links in between events can easily come from multiple sources, try reading any article on Wikipedia, you'll understand what I mean. Ray Trace(T|C) 16:10, 2 May 2017 (EDT)
My main thing with the Nintendo article is that, for me at least, not everything in it needs references. Having editing a fair few Wikipedia articles, and using sources, I am well aware that information can come from multiple sources, but in Nintendo's case what we have, is highly likely that there's a History of Nintendo website out there that can give us the needed reference. I can see the uses of the template, but I don't like the form is takes, perhaps something like {{redirect}} would be better. That way it draws attention to the issue, but isn't so in your face about it, because I do trust the majority of our editors, and so I believe the information is valid, but could be improved by being backed up; and it's not necessarily as bad as a poorly written article, or one that lacks images. Yoshi876 (talk)
Nintendo's article is only an example. What about the other company articles, or the people articles? Or development sections? Also, you're also making more assumptions: considering Nintendo is a huge, well-known company, many articles have been written about its history, Wikipedia's take on it dismantles your argument about a single website covering Nintendo's history. In my opinion, having no sources is just as bad as a poorly written article: if the poorly written article is correctly sourced with good information, we can believe it. However, with a well-written article with dubious sources, it's misinformation, and misinformation is arguably worse than no information. I also don't like the template being {{redirect}}, it's far, far too subtle when dealing with a clear, pronounced error with the article. Ray Trace(T|C) 16:35, 2 May 2017 (EDT)
I'm finding it hard to decide. {{ref needed}} tells a user specifically what spot needs a source, but this new template would be bigger and less subtle and more likely to alert users when something really needs attention. Then again, tons of ref neededs all over a page would probably draw attention too. But having this template would be far easier than running around a page placing ref needed. But even if we did have this template, we'd still need to use ref needed to specify what needs sourced, unless literally the entire article is unsourced information, an unlikely event. In the end, the template would only be an extra alert to pages that are heavily unsourced. But experienced users can spot pages like that without a template and more experienced users are also more likely to know where to find sources. So the template is pretty unnecessary.
I'll have to abstain, since I'm really not sure how useful the template will be. (T|C) 18:48, 8 May 2017 (EDT)
Either merge {{Yoshi forms}} into {{Yoshis}}, or remove the transformation section from {{Yoshis}}
remove the transformation section from {{Yoshis}} 0-15-0
These two navigation templates always confused me, and I'm not sure which one is better over the other. Therefore, I propose that we discuss the purpose of these two templates before any action is taken regarding them.
Toadette the Achiever (talk) To be honest, this is my preferred option. It seems that {{Yoshis}} is mainly focused on providing navigation between different-colored Yoshis, not necessarily different Yoshi transformations. {{Yoshi forms}}, on the other hand, is long enough, and navigates between enough Yoshi transformations to warrant its own template. Of couse, we could merge the templates, but that seems pointless, considering {{Yoshi forms}}'s sheer size. Per proposal.
Alex95 (talk) - I don't think "every" power-up should be removed, just the ones that specifically refer to transformations (i.e. get rid of Car, but keep Mega Yoshi, etc.). Never mind. Wasn't thinking clearly last night, but all of the transformations in the Yoshis template are "morphs" of some kind. So per all.
Wildgoosespeeder (talk) Thought this was a two options vote. This option seems to be moving transformations from {{Yoshis}} to {{Yoshi forms}}. I support this if that is the case. Makes way more sense that way.
@Alex95: ...Then why not vote for that option? Niiue (talk) 21:11, 27 May 2017 (EDT)
'Cause I'm a dunce and can't read. But does that work better? Just rename the "Power-up Yoshis" to "Other Yoshis" or something? 21:15, 27 May 2017 (EDT)
@Alex95: I can see your idea working. (T|C) 16:09, 28 May 2017 (EDT)
Actually, never mind. They are all transformations. I was thinking of something slightly different. 18:20, 28 May 2017 (EDT)
@Wildgoosespeeder: I... really don't see how that's similar at all. Niiue (talk) 17:44, 28 May 2017 (EDT)
I think I made a mistake with my vote. Misread this as a two vote proposal. Sorry. --Wildgoosespeeder (talk) (Stats - Contribs) 18:13, 28 May 2017 (EDT)
Remove the eleventh featured article/list standard
keep standard 8-12
"11. [An article must] be of reasonable length and not marked as a stub."
This is the eleventh and final standard that must be followed for featured articles and featured lists, as described on MarioWiki:Featured articles, and it is completely unnecessary. For starters, it is too vague to be of any practical use, and it would be difficult to use our current featured articles for comparison since they have wildly different sizes. Mt. Teapot, Mystic Forest, Mario Kart: Double Dash!!, and Mario Sports Superstars clearly all have different lengths, and yet they're all featured articles. If we tried to be strict and set a minimum character count or word count, then we're only going to promote articles that have been stretched and padded out solely to meet the minimum count. Needless to say, that is bad. With that in mind, why should we look at the length of an article to judge its quality? There are plenty of articles that are long, but they haven't been featured because they're missing information or their writing isn't good or their images are blurry or they have an improvement tag or for a myriad of other reasons based directly on the article's content, all of which are already covered by the other featured article standards. An article's length has next to nothing to do with its content and quality, so why should it be used to judge articles that, and I quote, "represent the best the Super Mario Wiki has to offer"?
Finally, there's already a proposal that discusses lowering the size requirement for featured articles (which was also my original idea apparently although I genuinely don't remember it), and it passed. Since the proposal was four years ago, it's hard to see how much of it is still in effect today, but my proposal clearly hasn't come from nowhere, and this is to say nothing of the recent forum post and the replies therein that inspired me to make this proposal. Simply put, the eleventh standard is too vague to be useful and is redundant with the other standards, and that is why I want it to be removed.
Proposer: Time Turner (talk) Deadline: June 11, 2017, 23:59 GMT Extended to June 18, 2017, 23:59 GMT Extended to June 25, 2017, 23:59 GMT
YoshiFlutterJump (talk) This rule really has no purpose. Featured articles are about quality, not length. If a stub is a good article, it should still be featured. There is absolutely no reason why this rule should not be removed. Additionally, if there is a proposal that passed for this 4 years ago, then this proposal doesn't need to be here. Remove the rule, end of story.
Wildgoosespeeder (talk) To keep this being discussed further, I am going to balance the votes to be 6-6 (as of Sunday, June 11th, 06:21 GMT). I am only going to support if the rule will be "[An article must] not be marked as a stub" because reasonable length is arbitrary and subjective. Stub means missing information, not short article, so a featured article needs to mostly be complete, if not fully complete.
The Koopa Bro. (talk) Per all. My only concern was that the {{stub}} part shouldn't be removed, but that part is already covered by rule 5.
Oppose
Supermariofan67 (talk) The purpose of the Featured Articles system is to be applied to the best articles on the wiki. There are many articles that are very well-written and that meet all the requirements, but shouldn't be featured because they are very short and therefore cannot be the best articles on the wiki. I think an article needs to be long enough to be featured, but there should not be a specific number of bytes because articles vary due to images, tables, etc. and reasonable length can vary between different types of articles. I support Baby Luigi (talk)'s page. I agree that the rule should be changed but not removed.
Baby Luigi (talk) Strong oppose: This entire proposal has its foundation on a logical fallacy. Honestly, I think removing featured article size requirements altogether would be disastrous for Featured Articles in MarioWiki. It's far better to revise the guideline that outright remove it all together. This is really a sledgehammer situation to a problem that can easily be solved through compromise. Also, per my comments below.
Toadette the Achiever (talk) Per Baby Luigi. Her point has motivated me enough to change my vote. Change it, but don't outright remove it. Even if an article was featured as a stub, the very little information on it would be contradictory to the purpose of featured articles.
Ultimate Mr. L (talk) Changing my vote. Per Baby Luigi. The rule should be changed, not removed. (I was a bit confused when I supported. :P)
TheFlameChomp (talk) Per Baby Luigi. I have changed my mind, as I agree that it is better to change the rule than remove it completely.
Shokora (talk) – In what circumstances could a stub qualify as a featured article? Per all.
Magikrazy (talk) After thinking it over, I gotta side with Oppose, per my reasons below.
Lord Bowser (talk) This is a highly divisive issue, and I wasn't sure what side I aligned with better, but I'm going to cast a vote for oppose for the time being. I feel like the best way to go about this is to go with a case-by-case thing, instead of an overarching rule. Length and length alone shouldn't exclude an article from being featured, but the rule shouldn't be removed entirely; otherwise, we could have stuff like Ronald B. Ruben up for nomination (thanks Magikrazy (talk)). Even if someone does lack common sense and we get very short articles nominated, it's extremely unlikely that there will be a unanimous vote to have said very short articles featured. The other ten rules for featured article standards are clearer and less open to interpretatiom, while rule 11 is, as it currently is, very vague. Rewording it or going with a case-by-case standard would be the best approach for this matter.
Alex95 (talk) - I agree this is vague, but it should be reworded, not removed (which can be discussed in full elsewhere). The info about {{stub}} should be removed, as I feel that would fall under rule 5, ultimately be redundant. A case-by-case basis would be better, like Lord Bowser said.
Luigi 64DD (talk) After lots of holding off, I've decided this is the best course of action. Glowsquid and Baby Luigi's comments helped convince me. I think that a well-written article with detailed, comprehensive information that is also lengthy is more impressive to a reader than a short article with the same attributes. To use an analogy, a person is more likely to choose a large bowl of delicious ice cream over a small cup of the same ice cream, despite the two containing ice cream from the same carton.
Comments
So, to confirm, articles of any size would be able to become featured as long as they meet the other ten requirements, right? --™The 'Shroom 21:46, 3 June 2017 (EDT)
From experience writing essays in high school and college, word count and character count is in no way an indication of quality because I could ramble on about something instead of writing something that actually says something accurate and straight forward. As the saying goes, less is more. I mean I really stretched to meet minimum requirements. For a real life example, most politicians don't even read bills before they vote on them because they are ridiculously long! As of right now, I am neutral and not voting. --Wildgoosespeeder (talk) (Stats - Contribs) 23:13, 4 June 2017 (EDT)
Our featured articles guidelines already discourage padding to meet out minimum requirements. Again, if an article was padded out only to give the false impression that it is sophisticated it easily fails. My argument is that writing should definitely be focused on quality, but the quantity of the quality is also something that should be taken into account when it comes to designating articles as the "best" in MarioWiki. Ray Trace(T|C) 23:22, 4 June 2017 (EDT)
In general, I find the whole system biased trying to showcase articles because we the contributors are biased liking Mario games. I don't really consider MarioWiki literature but rather a database of knowledge. Featured articles do nothing to enhance the database. --Wildgoosespeeder (talk) (Stats - Contribs) 23:28, 4 June 2017 (EDT)
To me, I see Featured Articles as an example of how an article should ideally look in MarioWiki, so we have a goal to work towards to when we improve articles and our writing overall. Setting a clear, visual goal helps me and other editors look out at what other articles do that work and what doesn't work. The concept of Featured Articles is how I got inspired to write Mario Party: Star Rush and Mario Sports Superstars anyway. Ray Trace(T|C) 23:36, 4 June 2017 (EDT)
Keep in mind that some articles become unfeatured because something went wrong when trying to follow writing guidelines. I'm not sure how an article can get into such a disheveled state but couldn't it be argued that someone could take wrongful inspiration if the upkeep of featured articles is not kept? --Wildgoosespeeder (talk) (Stats - Contribs) 00:24, 5 June 2017 (EDT)
Some articles are unfeatured mostly because of outdated writing styles that editors have overlooked. Like, in 2015, I've unfeatured Mario Kart 64 because that article looks totally barren today back when it was originally featured, standing up to articles such as Mario Kart 8 or Mario Kart Double Dash. I'm not saying all featured articles are a caliber of quality, but a decent amount of them are and they're enough inspiration to work at my hardest. Ray Trace(T|C) 00:34, 5 June 2017 (EDT)
@YoshiFlutterJump: The proposal linked to is referring to decreasing the the size an article needs to be to become an Featured Article, not about removing the rule, so this proposal still is necessary in order to remove the rule. Also, stubs cannot become featured articles, as a featured article cannot be tagged with any sort of improvement tags, which includes {{stub}}. --TheFlameChomp (talk) 14:35, 4 June 2017 (EDT)
@Supermariofan67: Why can't a short article be the best? If it follows all of the other standards to a T, I frankly don't see why the content should be outright ignored. What about its length says anything about the article itself? Hello, I'm Time Turner. 16:27, 4 June 2017 (EDT)
I'll try to rebuke several things brought up in this proposal.
If we tried to be strict and set a minimum character count or word count, then we're only going to promote articles that have been stretched and padded out solely to meet the minimum count.
If that were the case, the Featured Article nomination would easily fail because it doesn't pass the "well-written" rule that is put up there easily for that reason, and therefore, would not be fit as a Featured Article. This is a strawman of imposing a minimum size guideline, and obviously, we're not going to feature articles that are flowery or padded out just for the sake of meeting just one rule out of the rest of rules that are there to keep things in check. It's like badly formatting images just so the article can meet the image requirement. A minimum size requirement rule assumes that the article is already well-written and covers everything about the subject. My idea is to make it, y'know, a guideline. Have say 2,000 words give or take 100 or 50 or whatever.
With that in mind, why should we look at the length of an article to judge its quality?
I'd argue that length is an element of quality for an article to be featured on MarioWiki, just like how something should be well-written or something should have high quality images to be considered to be featured. We feature articles because they provide meaningful, detailed content, they represent the best MarioWiki has to offer. The best means that all factors have to be taken into account, and for this, we're not looking at just its length as you're implying. Many articles have barriers to prevent them from passing to be featured on the main page, even if they're written the best they could. If they lack images because they're too obscure to be found, they can't be featured. Shorter articles have their length as their barrier of entry, and this barrier prevents us from calling any article the "best" on MarioWiki. There's plenty of fish in the sea for MarioWiki, and having a minimum size limit rule picks out only the best and biggest fish, which is supposed to be the Featured Article's original purpose. There's a huge reason that most Featured Articles are long and detailed, it's because they provide content in both size and quality, and there's a reason shorter articles like Culex are in the vast minority. And finally, this argument fails because it's a false dichotomy. This is not a binary problem, an article can be BOTH large and have quality content, it's what separates the longer FAs from the very, very short ones, and what I think is a huge quality difference between the two.
The proposal Time Turner linked to looks really flimsy to my eyes today, I really wouldn't cite it for serious reasons. Also, in my thread, most responses were against the Good Articles idea, and no one has bothered even refuting my comments on how quantity can be linked to quality if you think about it. I'd also per Glowsquid's comment in that thread, "It's like, if you think there's a minimum length needed for front page exposure, that's fine, and it's a principle nearly every print media operates on, but "featuring" content will always be exclusionary in nature." Removing a minimum word limit is not how print media operates on and we shouldn't ignore why they have a minimum word count, aside from using false dichotomy arguments that quality and quantity have to be separate qualities of an article. Ray Trace(T|C) 16:59, 4 June 2017 (EDT)
I've messaged Steve so that he can participate directly in this discussion. (T|C) 20:18, 4 June 2017 (EDT)
I think the "stub" part could be removed, as that seems to also fall under Rule 5.
"There are plenty of articles that are long, but they haven't been featured because they're missing information or their writing isn't good or their images are blurry or they have an improvement tag or for a myriad of other reasons based directly on the article's content, all of which are already covered by the other featured article standards."
In this case, then they should remain unfeatured. Not because of the length, but because they should be tagged for improvement or the images need to be replaced, etc. I agree padding should be removed when noticed, but if they have other problems, then length isn't the issue. I do think articles should have length to them, for example, nothing like Water Bomb and has headers that describe what the subject is, infoboxes if needed, images, etc. However, length should probably be of the lowest priority when it comes to article content, but still be considered. If there isn't anything more to add, then there's nothing more to add.
Not sure how I'm voting on this, but just putting in what I think. 22:42, 4 June 2017 (EDT)
Really, the issue of prioritizing length all depends on the article itself. When it comes to being detailed about media, a longer length should just come naturally as a result of being comprehensive and detailed. I do agree that good writing and formatting should be stressed over length, but length cannot be ignored outright either, which is what this proposal is proposing to ignore, as people here think quality and quantity are two mutually exclusive aspects of a Featured Article when they're not at all. Ray Trace(T|C) 23:02, 4 June 2017 (EDT)
I am going to bring up the Bible. I know not every one believes it, but it is one of the largest books and it is considered one of the bests. So, this does show quality and quantity to be near equal. But, let me show you two different things. The first is the incomplete Bible. This Bible is a little less than the Bible, but you wouldn't know that unless you compared them. This incomplete Bible drops in quality, too. The second is child Bible. This may sound like an incomplete Bible, but the difference is it is meant for children. It has the quality of the Bible it comes from without the quantity. The only time quality and quantity aren't related. Now to translate this to articles. There will be long articles with good quality, and long articles with no good quality. If we bring in short articles of good quality, they won't make much difference. And, by the way, there would be an indirect length standard. Why? We would not want a whole article or a lot of it on the front page, which would only happen if it is just an intro. Yoshi the SSM (talk) 22:42, 4 June 2017 (EDT)
I really don't understand your point. Can you (or someone) clarify, please? Ray Trace(T|C) 23:24, 4 June 2017 (EDT)
I think he's saying that it doesn't matter the length as long as the quality is good? 23:26, 4 June 2017 (EDT)
I have already argued that length does play a factor in terms of designating what is considered the best. Assuming that your article is well-written and not artificially long, a long length should be considered a positive quality, not a negative one, as typically, long length naturally comes from the article being comprehensive and detailed, which is what we're aiming for with featuring articles on the main page. Also, I think the Bible analogy isn't correct: there's a myriad of reasons children's Bibles would be simplified and abridged, and this doesn't relate to how we feature articles here. Ray Trace(T|C) 23:31, 4 June 2017 (EDT)
Yes, Alex95. Also, the incomplete Bibles also use padding by not removing the number of the verse that was removed altogether. And children's Bible is the closest thing to small articles that relates to the Bible. Sorry if the relation between isn't perfect. Yoshi the SSM (talk) 23:38, 4 June 2017 (EDT)
I see that whole analogy more analogous to regular Wikipedia and Simple Wikipedia than smaller articles and bigger articles here, where Simple Wikipedia is like the children's Bible where content has to be abridged and simplified for a different audience, that's why I think your analogy doesn't work. Ray Trace(T|C) 23:43, 4 June 2017 (EDT)
That may be true, but before now, I never heard of Simple Wikipedia. Also, it is the closest thing of small being a good quality. And by the way, when I say children's Bible, I also include lessons for any age group and messages, which are shorter than reading the entire Bible through, though I may not refer to them directly. Yoshi the SSM (talk) 23:53, 4 June 2017 (EDT)
I mean, I understand your point. I definitely agree that quality should be emphasized over quantity and that longer doesn't necessarily mean better. Padding is a sign of terrible writing. However, this is a standard every single MarioWiki article wants to have; in terms of featuring it in the main page, size of the article definitely should be taken into account, as it's a different standard than the typical fare of how an article should look in MarioWiki. Ray Trace(T|C) 00:03, 5 June 2017 (EDT)
I think I got an idea. Go find 6 articles (requirements below) and make a comment of which articles they are. Don't ask why, just do it. I will explain after you do that. For me, I am going to bed. Oh, and the deadline is June 7 at noon according to the time the Wiki uses. You comment on what you got at that time if you can't find all. Ps. Rules below refer to feature article rules.Yoshi the SSM (talk) 00:20, 5 June 2017 (EDT)
an article you feel meets rule #11 and the rest of the rules
an article you feel meets rule #11 and breaks at least one of the other rules
an article you feel falls short of rule #11 (but not too short), but meets the rest of the rules
an article you feel falls short of rule #11 (but not too short), and breaks at least one of the other rules
an article you feel is very short, but meets the rest of the rules
an article you feel is very short, and breaks at least one of the other rules.
Wow. very good list. *looks at the articles. Notices that they are featured articles.* You know that you can also include non-feature articles as well. Seems kinda bias too, but then I said feel. Yoshi the SSM (talk) 15:47, 5 June 2017 (EDT)
Well if articles aren't featured yet, they probably don't meet all of the rules yet. It's easier to select what is already featured than analyze some articles. Ray Trace(T|C) 16:05, 5 June 2017 (EDT)
I can totally agree with that. (T|C) 16:11, 5 June 2017 (EDT)
Ok, fine. I wonder how many people agree with this list. Yoshi the SSM (talk) 16:23, 5 June 2017 (EDT)
Look, after compiling this list I've realized this: we have 97 Featured Articles. If 3, 4, 5 were to be excluded due to their questionable length and this is going to be excluding the shorter listicles like Miracle Book and Rosalina's Storybook, only like, 12 articles out of 97 would be unfeatured due to the rule. That's only a paltry 12% of all Featured Articles. If we cut it down to just 4 and 5, it'd just be 10 articles. There's a reason articles like those are in the minority. Ray Trace(T|C) 16:55, 5 June 2017 (EDT)
@Wildgoosespeeder: That's what the opposing side is arguing. (T|C) 08:52, 11 June 2017 (EDT)
I am aware. The vote is neither for nor against but because of the two-choice voting, strategic voting took place to maximize discussion, because of how split people are. My best advice for Time Turner (talk) is to ask permission from sysops to cancel the proposal and continue discussion (with {{talk}}) over on MarioWiki talk:Featured articles or something. --Wildgoosespeeder (talk) (Stats - Contribs) 14:17, 11 June 2017 (EDT)
Your vote already complicates things, since this proposal would be extended regardless of your vote, considering the proposal has more than 10 votes and thus, needs a margin of three votes from one side to pass in the first place. Ray Trace(T|C) 14:57, 11 June 2017 (EDT)
Again, aware. Instead of needing two more votes, brought it back to needing three. That's not the point. The point was to keep the discussion going for as long as possible. This is quite a controversial change, and the current proposal isn't sufficient for both sides. Needs to go back to the drawing board. --Wildgoosespeeder (talk) (Stats - Contribs) 15:29, 11 June 2017 (EDT)
I will not vote so as to keep discussion flowing for another week or so, but I don't think outright removing the rule is a good idea. Length isn't a factor in quality of an article, but we shouldn't just throw around the Featured Article status to any Kart article just because it's well written. I don't like the idea of a set in stone "it must be this long or absolutely no feature", but not having a length rule will just oversaturate the Featured Article list with well written but tiny articles about Paper Mario NPCs and Mario Party items. How will that make us look? Really, I think the best thing to do when it comes to article length is use your common sense. If it doesn't look too short to you, go ahead and nominate it. The worst that can happen is it's not featured. Yeah, this rule ends up excluding some well written articles. Oh well. If your goal when writing articles is only to get them featured, then you're wasting your time. Magikrazy (talk) 14:06, 11 June 2017 (EDT)
In my opinion, having well-written articles should already be the default goal of all articles in MarioWiki in the first place. We should already try writing articles to the best of our abilities, that's why we tag pages with improvement templates. Featured Articles is another standard above the standard we try to aim for with regular articles in MarioWiki and in this case, length should definitely matter for that higher standard. Ray Trace(T|C) 14:54, 11 June 2017 (EDT)
People throw around feel-good statements like "Length shouldn't a factor as long as the article is well-written", and to be honest, I think it's kind of, for a lack of a better word, deluded. If you're going to focus all eyeballs on a specific page for a week of time, length *absolutely* does matter. The Featured Article spot is basicallly marketing for the wiki. It exist to retain new readers and fidelize existing ones. People who nominate articles may have a different agenda for doing so (likely vindicating their efforts on writing a page or to publicize their favourite character), but even there's an underlying goal of having an article exposed to as many people as possible because someones want to. You impress people by having up-to-date information on the latest games, with fancy and creative ways of presenting statistics lsited or unlisted, or having an exhaustive and accurate description of every media a 20-years old character has appeared in. You don't impress people with three-paragraph articles about Paper Mario NPCs.
Ultimately I agree with Baby Luigi's statement that articles being well written (... and accurate) should be the baseline expectation, not something to throw a shiny sticker at. A page like Goombob is fine. Indeed it may be "better" that a bloated article that looks superficially "big" and "impressive" at a first skimming, but reveals itself to have clumsy writting and poorly-organized information. But a page like that isn't what you use to show you're the definitive Mario fansite out there. --Glowsquid (talk) 19:31, 11 June 2017 (EDT)
To a degree, length matters (such as making sure statements are detailed enough), but there does come a point where there are too many words and you lose your audience's attentiveness (TMI), which is often why we split articles. Strive for quality over quantity. I think word count falls on a bell curve to determine effectiveness of the article's ability to convey information. The right amount of words varies from article to article. --Wildgoosespeeder (talk) (Stats - Contribs) 20:14, 11 June 2017 (EDT)
"but there does come a point where there are too many words and you lose your audience's attentiveness (TMI), which is often why we split articles." This is blatantly, hilariously wrong and I have no idea how you came to reason this is the reason articles are split. --Glowsquid (talk) 20:33, 11 June 2017 (EDT)
Many galaxy pages are getting split into mission subpages. I figure the reasoning is to separate missions from what is found in the galaxy. Same thing is happening to Super Mario 64 and Super Mario Sunshine places and missions. Other kinds of splits include List of references in video games, which a proposal passed to split them into 1st and 3rd party. We have a policy page how to tell us if an article needs to be split. That just means there are too many words on the article page and needs to be split into digestible chunks. --Wildgoosespeeder (talk) (Stats - Contribs) 20:58, 11 June 2017 (EDT)
The mission pages are split by site owner's edict they should be (for more ad revenues, consistency with level pages for the 2D games , etc etc.). The reference pages and 99% of page splits on the wiki are done because the uncropped page is Too Big to comfortably load on low and mid-range computer rigs. No pages were split "to hold the audience's attention" as you claimed. --Glowsquid (talk) 21:10, 11 June 2017 (EDT)
But there are splits that are occurring on pages that can load on low to mid range computers. Take Skeeter and Skeeter (New Super Mario Bros.). They were split because the attack changed. That would be like creating an article for Ukiki holding a cactus thing and an Ukiki holding a bomb. Ad revenue, well, you kind of got me there, except why not split the long articles so you can make more ad revenue? More page navigation means more ad revenue, which seems to be against the interest of long articles. Do you have hard data to support that readers aren't overwhelmed? From my experiences, people in general often complain about having to read walls of text and would rather have a shorter version of what they are reading. --Wildgoosespeeder (talk) (Stats - Contribs) 21:26, 11 June 2017 (EDT)
For the quick, "shorter version", that sort of info usually goes into infoboxes. The wiki is not meant to hold reader's interests, it is to provide information. Level of interest varies on the person. Also, that's what section headers are for: for readers to easily find the info they are looking for, despite the length of the article. 21:32, 11 June 2017 (EDT)
Attentiveness means to pay attention to details, and if there are too many details, it becomes very hard to keep information straight. I think it was confused for active reading and attention span. --Wildgoosespeeder (talk) (Stats - Contribs) 21:38, 11 June 2017 (EDT)
Wildgoosespeeder, our job isn't to entertain writers. It's to inform them. If they're too lazy to read comprehensive information, they're in the wrong place. Ray Trace(T|C) 21:35, 11 June 2017 (EDT)
I think you misread my statements. I never claimed entertainment. --Wildgoosespeeder (talk) (Stats - Contribs) 21:42, 11 June 2017 (EDT)
Also it seems my commen went over your head because I never implied articles should artificially be padded or that being more lengthy is innherently "better". The opposite even. My point is that a page specifically linked to the front page for its quality should be both "big" and good. --Glowsquid (talk) 20:46, 11 June 2017 (EDT)
I posted all this in Discord, so I'm just gonna copy/paste what I said there (save typos and whatever):
"I think this sort of thing would be decided on a case-by-case basis, like what LB said on his oppose. If it's well written and has enough detail to adequately state what the subject is, then great. But we probably wouldn't nominate articles like Bumble V or whatever. The current issue with Culex is, I think, probably a good representation here. It has solid information, describes what the subject is, and the history around him. It is also of considerable length, imo. Whereas Bumble V is well written (from what I can tell, anyway), but is rather short as it really only appeared in one game (though so did Culex), so there isn't much about it. All in all, the ultimate decision would boil down to the nomination process itself and what other users would have to say about it. I do think the stub thing in rule 11 should be removed, as I think that's covered in rule 5. As for rule 11 itself, I'm not so sure...
"Point I'm trying to make is: Length should be considered, but the size of the article should be taken with some common sense, you know? If it's a well-written article, but only one paragraph long, it probably won't be nominated. Whereas if the article is over 30,000 bytes long, but is a complete mess and info is jumbled, it wouldn't be nominated either. I feel like this proposal is a waste of time, tbh. Everyone has different opinions over what counts as a "long article", that it should be decided on the proposal pages itself."
I would vote to support the removal of the rule, but at the same time, I feel the rule should be rewritten. 00:29, 12 June 2017 (EDT)
Since it looks like we're gonna get another extension, I'd like to re-iterate that Featured Articles are only a showcase of our best articles, not our whole enchilada. Magikrazy (talk) 10:09, 19 June 2017 (EDT)
Standardization of Species Templates' Endings
pluralize all species templates 12-0
This is a simple issue: when it comes to navigation templates based on species, some are pluralized (e.g. {{Boos}} and {{Koopa Troopas}}), and some are singularized (e.g. {{Human}} and {{Koopa Paratroopa}}). A majority of them are already plural, but most of the singular templates are for the well-known species. There's no reason why we shouldn't have consistency, so enough's enough. I personally think that it makes much more sense to pluralize all of them, but considering the number of templates that are singular, I'm including both options for fairness. Obviously, this is not even close to a major issue, but at the same time, for such a minor issue, it has yet to be cleared up, and having a uniform system makes the wiki seem all the more professional.
Proposer: Time Turner (talk) Deadline: August 7, 2017, 23:59 GMT
Alex95 (talk) Per. I assume a bot will take care of this. If not, I'm willing to help.
Doc von Schmeltwick (talk) Having them in singular at all is confusing, and there's only a few singular as it is, instead of the large amount of plurals there is. Less bot work.
Yoshi the SSM (talk) The templates that are singular have plural names on their headers. Also, I should point out that you didn't include an oppose. Which, I would have chosen if I didn't look at the templates.
@Alex: The plan is to have a bot take care of the dirty work. Hello, I'm Time Turner. 00:25, 31 July 2017 (EDT)
Do Something With Game-Specific Species Categories
use species categories for non-hostile, non-item, non-object species 7-0
So, Time Turner noticed a while back that Category:Super Mario Bros. 3 Species (and most games' species categories as a whole) are basically duplicates of their enemy categories, with maybe one or two different pages. Overall, species categories as they currently stand are useless and redundant. I've included a few options on how to fix this:
Use species categories only for non-hostile, non-item, non-object species: This would redefine species categories to only count creatures that aren't enemies, aren't items, and aren't objects. In other words, they'd only be for things like Egg-Plants, Humans, Piantas, and the like.
Use species categories only for non-hostile species: Similar to the previous option, except it would also include things like Fire Flowers and Beanstalks. The problem I see here is that items and objects already have their own categories, so we'd just end up with another set of redundancies.
Delete species categories: One of the simpler options. Just get rid of every game-specific species category on the wiki, and leave articles like Bird (Super Mario Sunshine) in categories like Category:Real World Animals.
Do nothing: The simplest option. As this would involve not changing anything, I feel it'd be the most detrimental option.
Proposer: Niiue (talk) Deadline: August 8, 2017, 23:59 GMT
Use species categories only for non-hostile, non-item, non-object species
Time Turner (talk) I think this is the best option. It gives a home to a small, but well-defined, group of articles that wouldn't otherwise have a place in one of the main categories, while also ensuring that there's little to no overlap.
A lot of these could probably be deleted, since a lot of them (especially platformer ones) have pretty much 100% overlap with their games' respective enemy categories.
use old names in articles 2-8
Currently, it's standard practice to use the old name of a subject while writing about in at a point in time where that old name was in use. For example, Blooper was called "Bloober" in Super Mario Bros., so "Bloober" would be used when talking about Super Mario Bros. instead of the more recent name. If a link is involved, it would be coded as [[Blooper|Bloober]], always maintaining the old name. Though this isn't outlined in the policy pages, as far as I can tell, there wasa proposal that set out to outline this exact issue, and ultimately decided to use old names when relevant (thank you Alex95 (talk). However, I'm not entirely in agreement with the outcome.. To outline the pros and cons of the current situation:
Pros:
It's historically accurate.
Considering that these names were consistently used until they happened to be changed, it naturally follows that our articles reflect that.
It's what people familiar with the old names would look for.
To use the cartoons as an example, they regularly and consistently refer to Princess Peach as "Princess Toadstool". Anyone who is familiar with the cartoons would be looking for the name Toadstool and not Peach. This extends to any of the old names, really: whether it was in the cartoons, the manuals, or the guides, these names were prominent.
Cons:
It's not currently accurate.
Regardless of how consistently the old names were used, these are not the names being used today. For an encyclopedia, using the old names in articles and templates without so much as a note seems misleading.
It's confusing, especially for newcomers.
Not everyone knows that Princess Peach's old name was "Princess Toadstool". The similarities in the names are there, but it's certainly not a given that these two names refer to the same subject. To use the cartoons as an example, someone with little knowledge of the series may read one of its pages and leave without realizing that Princess Toadstool actually refers to Princess Peach.
To me, it makes more sense to keep articles up-to-date rather than potentially mislead readers, though I'm giving each option equal opportunity. (For the record, the MarioWiki:Naming does state that "the newer name will replace the older one" while using Blooper as an example, but as far as I can tell, that hasn't been put into effect beyond the article's name and usage in modern games.)
Niiue (talk) As much as I dislike certain new names (looking at you, Bull's-Eye Bill), standardization is best.
Use old names for articles
Alex95 (talk) - I'm leaning towards to result of the original proposal. While yes, some readers may get confused, the purpose of the wiki is to display and show information as accurately as possible.
Doc von Schmeltwick (talk) - Fire Chomp, Podoboo, Grand Goomba, Venus Fire Trap, and Missile Bill for life!
Mister Wu (talk) Since ultimately the links then reveal what the current name of the subject is, I think that using the modern names can be extremely confusing in the case of games where the old name is showed by the game itself, especially for bestiaries where we are supposed to show the actual name used by the game. As an example, we just discovered in the 30th anniversary books that the bats of Super Mario Galaxy games have the same Japanese name of Enigmas and are thus very likely to be those bats, but there they are known in English as Bats. What would happen if we ended up using the new name also in the pages and tables related to Super Mario RPG: Legend of the Seven Stars ?
Chester Alan Arthur (talk) Gonna have to agree with Alex since those were the names at the time.
Comments
I know I helped you find some of the information, but I'm voting against. Blooper's name in Super Mario Bros. was "Bloober", for example, so it makes sense to call it by that name where relevant. If readers end up trying to correct the name to its modern variant, we can always revert it; posting something in the edit summary or their talk page if needed. 00:25, 1 August 2017 (EDT)
Not every user is an editor who plans on changing the wiki. The average person wouldn't know about the name change, so they'd fully believe that the white squid enemy from Super Mario Bros was a Bloober, and not a Blooper. It seems rather disingenuous to use old names without ever mentioned that they've changed names. Hello, I'm Time Turner. 00:28, 1 August 2017 (EDT)
Why can't we just advise users to say "Bloober, later known as Bloopers, appear in Super Mario Bros.. Bloobers blob around in water levels, etc." Shokora (talk · edits) 01:53, 1 August 2017 (EDT)
Definitely opposing this. While I can kind of see the benefit to enacting this change for franchise mainstays with a "dominant" new name, like Peach and Blooper, for less prominent stuff, it's just confusing and awkward. For example, Goomba King/Goomboss. He only appears in three games. His article uses "Goomboss" because that's his most recent name, but people looking up information on Paper Mario are going to be annoyed/confused if we call him "Goomboss" even on those articles. His name in that game is clearly "Goomba King", so that's what articles relating to PM call him. I see no reason to change this. Or, for another example, the Sluggish/Slow 'Shroom Orb, an item only appearing in two games within the same series. Mario Party 6 calls it a Sluggish 'Shroom, Mario Party 7 calls it a Slow 'Shroom. Neither name is more "correct" than the other, so MP6 articles use "Sluggish" and MP7 articles use "Slow". 01:59, 1 August 2017 (EDT)
On one hand, it's somewhat retroactive to apply the newer names to certain articles; on the other hand, it's more consistent, is already noted just fine in the body of their own articles, and there have been official cases where more recent names were used in re-releases in favor of the older ones (like in remakes and some Virtual Console digital manuals; for example, mushroom retainers are called Toads in the 3DS Virtual Console and Wii Super Mario All-Stars manuals for Super Mario Bros., and "Magic Mushroom" completely fell by the wayside). Then there are others like Blooper and Nipper Plant that were in use in strategy guides, or instances where a given subject was only named in foreign content at times and its newer English name is preferred instead. We're specifically talking about video games, right? It would be iffy to use Peach and Bowser when referring to the DIC cartoons when they were nothing but Toadstool and Koopa during the entire run. It'd also be confusing to do this for the RPG bestiaries and info boxes, if that's considered under this proposal. What about obvious misspellings like Racoon Mario and pirana plant? Are we sticking to those just because they were contemporary? I feel like there should be a middle ground: in-game and manual elements could use whatever name they had at the time (universally preserving the very well-known changes of Peach/Toadstool, Bowser/Koopa, Starman/Super Star, RPG name changes, etc.), but names that only came from old guides are most probably obscure enough to be standardized with the more recent material. Basically, make it into a source hierarchy like the naming policy. LinkTheLefty (talk) 02:40, 1 August 2017 (EDT)
@Mister Wu: This is just an aside, but I very much doubt that Enigma example is intentional because Square/Square Enix most likely holds the copyright for it. LinkTheLefty (talk) 10:46, 1 August 2017 (EDT)
I definitely concede that mass-changing every name would do more harm than good, but at the same time, I agree with LTL in that there should be some sort of hierarchy or a well-defined system for deciding how names should be used in articles. Your point about "pirana plant" is good too: why does Super Mario Bros. uses "Bloober" for Blooper but not "pirana plant" for Piranha Plant? I'm not sure if manuals should take the same precedence as games, though, especially since most games don't require the use of the manual. Hello, I'm Time Turner. 16:27, 2 August 2017 (EDT)
I think the old names should be kept for the games where they were used, while including notes of the names that are currently used. For example, "Princess Toadstool (early name of Princess Peach until Super Mario 64)" or "Flopsy Fish (the name used of Cheep Cheep in this game)". SmokedChili (talk) 05:20, 4 August 2017 (EDT)
What do you mean by "the games where they were used"? Are manuals and official guides also counted under that? Hello, I'm Time Turner. 13:17, 5 August 2017 (EDT)
I was thinking "a game and its manual and possibly a guide", although I could have worded that better like "material where they were used". I wrote that comment rather roughly at the time. SmokedChili (talk) 13:50, 5 August 2017 (EDT)
Create an archive system for talk page proposals
create 13-0 Once more, with feeling. I'm aware of the previous failed proposal, but frankly, I don't agree with the opposition. Yes, talk page proposals don't affect as many pages as regular proposals (usually), but at the same time, they're still affecting pages, and that can easily have repercussions as well as set a precedent for the future. If a user is unsure if there's anything to support something that they want to do, they can look through the archive of proposals and see if any similar proposals have happened as well as their outcomes. That's certainly something I've done with the regular proposals, so I don't think it's unreasonable to do the same for talk page proposals. To use a concrete example, for my proposal on implied subjects, I had to dig through history pages and rely on my terrible memory to find talk page proposals that were relevant to my own; why not make the process simpler? Also, pointing people to the category as a suitable substitute when it gives no details about the content of the proposals, when they happened, what their outcome was, or even if multiple proposals happened on the same page is not satisfactory for me. Banana's talk page has six separate proposals (and it's hardly the only one of its kind), but that fact becomes completely obfuscated if we only use the category. Also, if we relied on categories for everything, we wouldn't have navigation templates. Besides, this only requires a single page.
Like the original proposal, I'm not planning on literally making an archive that houses every talk page proposal: I want to create a page that emulates MarioWiki:Proposals/Archive, but instead of linking to subpages with every proposal, I would be simply linking to the original talk pages. This gives added clarification and convenience, and I really don't see why we shouldn't have it.
Proposer: Time Turner (talk) Deadline: August 11, 2017, 23:59 GMT
Alex95 (talk) - I was thinking about making a proposal like this myself, but I wasn't sure how to go about it. I get lost looking for TPPs, especially if it's one I wasn't aware existed in the first place (and there have been a few occasions where finding a past TPP would've help me, but I just couldn't find it). A condensed page similar to the main proposal archive can work, so I support.
Baby Luigi (talk) I don't like the argument that "it's not hard to find TPPs" which was the primary reason to oppose in the previous proposal. History has shown and some users stated, yes, it IS harder to find the proposals by browsing through an endless assortment of pages listed by categories. And I don't understand why we can't take the time and effort to improve navigation and organization of these things: depending on your perspective, TPPs can be more major than main space proposals, and it has spawned paragraphs and paragraphs of discussion. Plus, I don't see how lesser importance means that we should completely ignore still facets that have an influence in changing around policy, regardless of scale. I say, the correct move is to take effort and organize them better and it'd would benefit pretty much everyone in the long-term.
I think you should have drafted a sandbox page for this before you made a proposal out of it, see what it looks like before we cast a vote on this. Ray Trace(T|C) 22:50, 4 August 2017 (EDT)
I have a very rough draft here: it'll obviously be increased and adjusted as time goes on. Hello, I'm Time Turner. 23:56, 4 August 2017 (EDT)
Now that I'm going through the talk page proposals, I'm noticing that there are a few proposals that are canceled and then immediately put into effect, usually because the proposed change is valid but the whole proposal process is unnecessary. Would anyone object if I added a color for these situations? I'm thinking mauve would look alright (and it's on the mock-up; search for Axem or Gargantua). Hello, I'm Time Turner. 11:02, 5 August 2017 (EDT)
I think white would be better, as mauve might be confusing for color-blind people (like me) with purple. I think blue is what's normally used in this case, though. 11:42, 5 August 2017 (EDT)
Blue is meant for proposals that fail, but whose proposed changes are later implemented anyways. A canceled proposal is different from a failed proposal - that's why we have both red and pink. I can definitely change the color, but since white is also what generically appears if a color hasn't been inputted correctly, I think that might be confusing. EDIT: Actually, if we're concerning ourselves with colorblindness, then the current color system has its own issues. Hello, I'm Time Turner. 11:46, 5 August 2017 (EDT)
Here is a suggestion. If a proposal was cancelled but changes took place after the proposal, than it would be light blue. It's not much of a difference, but a difference nevertheless. Yoshi the SSM (talk) 17:39, 5 August 2017 (EDT)
It'd be hard to distinguish between light blue and regular blue at a glance, especially since our current blue is already fairly light. Hello, I'm Time Turner. 17:41, 5 August 2017 (EDT)
We could use black, but then the text would have to change accordingly. As for blue, apparently the color we're using is lighter than the #0000FF code for standard blue. So with that in mind, maybe dark blue? 17:50, 5 August 2017 (EDT)
If the blue's too dark, then we come to the same issue as using black (and in fact, the standard "DarkBlue" or "Navy" is definitely too dark). The template also isn't currently set up for changing the text color, and in any case, I think that it'd be best to keep the text uniform. For now, I've thrown more colors onto the table at the top for demonstrative purposes. If you have a particular color in mind, this website works well for testing how it would like against black text. Hello, I'm Time Turner. 18:11, 5 August 2017 (EDT)
The problem I think we're having is we've used all the basic colors; any others we chose aside from a very light or a very dark color will end up looking close to ones we're already using. Dark blue doesn't look too bad, imo, though ivory, light yellow, slate, and chartreuse (as ugly as that is) are some other possible options. 18:23, 5 August 2017 (EDT)
It'd be more convenient if you could provide hex color codes that show exactly what you're talking about, if you don't mind. Hello, I'm Time Turner. 18:32, 5 August 2017 (EDT)
Ivory: #FFFFF0, Light yellow: #FFFFE0, Slate: #708090, and Chartreuse: #7FFF00. The dark blue I was thinking of was actually Dark cyan, my mistake there: #008B8B. 18:41, 5 August 2017 (EDT)
Threw all of those colors up there for good measure. Now that they're all up there, I'm partial to dark cyan. Everything else is either illegible or too similar to another (established) color. Hello, I'm Time Turner. 18:47, 5 August 2017 (EDT)
darkcyan looks the best out of them all, imo. Is there a chance this new parameter could be added to main proposals as well, just in case something like that happens here in the future? 18:51, 5 August 2017 (EDT)
I'll start using that for now, then (although I'll call the parameter "teal" for convenience). I'll leave the discussion of implementing it with the main proposals to you administrators. Hello, I'm Time Turner. 19:00, 5 August 2017 (EDT)
Merge Super Mario Sunshine sub-level articles into their missions' articles
merge 10-1
We currently have articles for various sub-levels from Super Mario Sunshine (e.g. Sand Portal, Bottle). These are obviously just artifacts from before the game's missions were split off. Now that we have the mission articles, the sub-level articles themselves are completely obsolete; we now have several pairs of articles covering the exact same thing. Some of them even have conjectural names derived right from the mission names (Hotel Lobby's Secret, Shell's Secret), which not only emphasizes the redundancy but adds confusion. So any relevant content on these articles not already on the mission articles should just be moved to those. It's not like we generally have separate articles for sub-levels anyway; we don't have articles for Shifting Sand Land's pyramid or Lethal Lava Land's volcano.
Here are what the results of this proposal will be if it passes:
Baby Luigi (talk) Some of these names aren't even "names" per se, they're just descriptive locations, like hillside cave. Anyway, most of these are pretty much the equivalent of our planet sections in the Super Mario Galaxy articles, so I think a merge is sufficient.
Alex95 (talk) - The mission articles go into detail about the secret areas anyway. Support.
Mister Wu (talk) If we can indeed cover the sub-levels in the mission pages without losing any amount of relevant detail and without creating pages that are too long and difficult to browse, I definitely support the idea of writing everything in one page.
Toadette the Achiever (talk) So long as mission/episode articles are not affected (which looks like they'll stay), per proposal!
Megadardery (talk) Per proposal, those pages are better fit as redirects to the mission pages.
Oppose
Doc von Schmeltwick (talk) I think the Episode description should describe the entire mission, including getting to the secret, but not getted bogged down with every geographical detail of said secret level's layout, which the article for the secret area should have instead.
Both Category: RPG Items - General and Category:RPG Items - Special are inconsistent with the rest of the wiki. We don't have categories for platformer items or sports items, nor do we have broad RPG categories for characters or enemies or any other subject. At best, we only have categories that encompass a series (for example, Category:Mario & Luigi Series Enemies branches off into the game-specific enemy categories), but nothing that's solely based on genre. Every item in these categories already has a home in another, more specific and more helpful item category. Nothing is gained from having them, and nothing would be lost if they were deleted.
Proposer: Time Turner (talk) Deadline: August 16, 2017, 23:59 GMT
Yoshi the SSM (talk) Why do we have this? I know RPGs are special because they give meaning to items, but a wiki shouldn't just put them all together in one category and call it a day. Even look at this if you want to know why. Per proposal
I find the first part, about articles needing to link to the disambiguation page, to be unnecessary, for the simple fact that the about template is almost always unnecessary in these situations. Let me use Stamp (Mario's Time Machine) as my example:
If a reader ends up there by chance (say, by using Special:Random), they weren't interested in a particular stamp in the first place and there's no need to point them to the disambiguation page.
If a reader ends up there through Stamp (disambiguation), then they were already at the disambiguation page. It's redundant to link to it again.
If a reader ends up there through a link within the body of another article, then the context should be enough to let them know where they're going, and failing that, "Mario's Time Machine" is right in the title. They clicked on the link because they wanted more information about the subject discussed within the article, and even if they had another Stamp in mind, the article quickly shows what it's about.
If a reader searches for "Stamp", they'll first see the most prominent Stamp and then Stamp (disambiguation). Even if they go to "Stamp" first and that's not what they wanted, that page already links to the disambiguation page, which goes back to the second point.
I used the Stamps for my example, but this extends to all similar pages. I simply cannot think of a situation where someone would end up at the page while thinking that they were going to end up somewhere else, and then being confused or disappointed about where they ended up. In these circumstances, the about template is a piece of fluff that doesn't help readers and distracts from the rest of the article. It shouldn't be a requirement to use it on every article when disambiguation pages are involved. It's not as if the about template is useless in all circumstances - for example, Stamp should link to its corresponding disambiguation page, as mentioned above - but it's hardly a necessity for all pages.
I am not proposing to outright remove the about template; I propose to make the following change to the sentence:
When disambiguation pages are used, the articles should only link to them in {{about}} when necessary, but if a disambiguation page is not used, the articles can merely link to the other same-named page.
Yoshi the SSM (talk) Sure. I have never really used those pages when I wrote articles of the Super Mario Maker for Nintendo 3DS's levels. I only started using the about template when it was just either Super Mario Maker or the remake that had this set of numbers. Even then, I use this to send the reader to the other place, not the one that had both. In general, the only times that they need to be link the one to the one with many uses is on the most commonly used the most often. Which means that it is in ()s. And if your wondering why I haven't said the name even once, the reason is I don't know the name well enough to type it out very easily. This doesn't mean I don't know what it does. Per proposal.
Toadette the Achiever (talk) I have my doubts, but I think maybe this should specifically apply in certain cases where there aren't enough disambiguated pages (like cases where there are only two pages to be disambiguated). Per all.
Megadardery (talk) Redundancy when comes to linking is a delicate matter. If it makes sense to link to other pages similar to the current page, the reader might be interested in reading more. It's not like we are linking a completely irrelevant page. This is especially true for the first case, if the reader stumbled upon this page by pure chance, they are willing to read more, and expanding the number of rational links to similar and related topics is helpful. If the reader reached the specific page he wanted, a million links to other articles will never stop them from reading, so regarding that as a distraction is a poor reason. Also my comment
Comments
Let's take the navigation template by the same reasoning:
If a reader ends there by chance, they weren't interested in any particular page, and there is no need to point them to many other articles that just share the same game.
is a moot point
If a reader ends up there through a link within the body of another article, then unless they blindly clicked a link (brings us back to point 1) or they reached the article they wanted to read (sends us to point 4)
If a reader searches for any article, they'll arrive at it. So? Why even direct them at potential reads?--
18:46, 17 August 2017 (EDT)
Pardon, but I'm not sure I understand the relevance to this proposal. Hello, I'm Time Turner. 18:47, 17 August 2017 (EDT)
I was trying to illustrate that redundancy when it comes to linking is not enough reason to remove the link.--
If you mean reoccurring links, that's a different situation, as it is already linked once in the same article. The preceding unsigned comment was added by Megadardery (talk).
I'm going to butt in here and say that one of the reasons why it's not entirely necessary to use {{about}} on pages with identifiers is because the reader might search for the same page title and possibly look for different identifiers. (T|C) 22:43, 19 August 2017 (EDT)
Expand proposal rule 10 to apply to proposals with more than two options
canceled by proposer
Just look at the example here! Although I feel that the move was warranted and compliant with policy, I also feel that the outcome was too close to actually warrant the move. Therefore, I propose that rule 10 of the proposal system apply to proposals with additional options as well.
Proposer:Toadette the Achiever (talk) Proposed Deadline: September 5, 2017, 23:59 GMT Date Withdrawn: August 29, 2017, 19:52 GMT
3D Player 2010 (talk) technically, that proposal only had 9 voters. Also, I feel that rule 10 is very arbitrary and I would personally prefer to simply get rid of that rule instead.
Shokora (talk) – Applying rule 10 to proposals with more than two options isn't easy or practical. For example, if most people kept voting for both the first and second option, it would take a large number of voters to even gain a majority of more than three votes. Hence why for such proposals, we instead count the total number of individual voters, and find which option has gained favour from a majority of voters. In the case of the coin bag proposal, the first option was selected by six of the ten voters, and that's a majority.
@Shokora: Yeah, you bring up a good point. It's more complex than I thought. I guess I'll cancel this proposal then.
Decide if the Mario's Time Machine historical figures are characters and/or people
they are characters and people 1-2-8
(for the purposes of the wiki and as it is used in this proposal, a "character" is someone fictional while a "person" is someone real)
This proposal, stemming from a discussion on Template talk:People, primarily centers around the numerous historical figures that appear in Mario's Time Machine. Note that this proposal currently does not cover the game's developers who inserted themselves into the game while directly using their names, faces, and voices, but that's a can of worms that I'll set aside for the moment. When it comes to the actual historical figures themselves, everyone from the game (who has an article) was a real, breathing person who impacted the course of history. They aren't just satirical or obviously fictionalized versions of the actual people: in the context of the game, Mario is traveling back in time and meeting the real people themselves. We also have a template, {{People}}, that lists the real people that have contributed to the Mario franchise. With that in mind, should these historical figures be listed in this template? There are other ramifications as well, but this is the most obvious example of what will be changed.
To some extent, these characters are similar to some of the guest stars of The Super Mario Bros. Super Show!. Ernie Hudson, for example, is a real, living person (who happens to still be alive!), but at the same time, he's not literally himself in the show, but rather a fictionalized version of himself based on the role he played in the fictional film Ghostbusters. Even with more mundane examples like Nicole Eggert, there's still a quirk or an oddity about them that obviously only exists because they're characters. Due to this, they, along with several others like David Horowitz, Shabba-Doo, Jim Lange, and others, are currently being treated as both characters and people.
However, there's a notable difference: in the show, these real characters are being portrayed by the actual people, whereas the historical figures in Mario's Time Machine are, obviously, not portrayed by their real life counterparts. Ernie Hudson the character is played by Ernie Hudson the actor. Thus, merely being based on a real person isn't necessarily enough to be considered as an actual person. For example, Cher, while being a real person, is not played by the real Cherilyn Sarkisian, so she is only treated as a character. The historical figures are simply blobs of pixels played by a random voice actor, and not a real person portraying a live-action character directly based on themselves while also having the same name as themselves. However, at the same time, the historical figures are literally supposed to be the real people, and they are presented to the player as such (ignoring the odd joke or historical inaccuracy). Even if the literal real-life Marco Polo isn't playing himself in the game, is it still fair to describe the in-game Marco Polo as not being real?
There's perhaps also an argument to be made about including Cher and similar subjects in the People template or not including the guest stars at all, but for now, this is the way things are. In short, there are three options for dealing with this:
Option 1: They are characters.
This is currently how the characters are treated on the wiki. Essentially, this is the "do nothing" option. The historical figures will be treated as purely fictional characters, and no categories or templates will be updated.
Option 2: They are people.
They will be treated as though they are the real historical figures and not as fictional characters. This involves removing them from {{Humans}}, placing them on {{People}}, and adjusting the categories on their page so that they're treated as real people (for example, Category:Deceased People, would be applied to the vast majority of them).
Option 3: They are both.
Following the guest stars from The Super Mario Bros. Super Show!, this involves leaving them in their current templates and categories while also placing them on {{People}}. This also involves making the same adjustments as in the second option, though without any potential removals.
(technically, there's a fourth option in which they're neither characters nor people, but that's silly and won't be taken into account)
After going through all of this, I personally think that the historical figures are too separated from their real life counterparts to be exclusively considered people, but consideration should also be given to the fact that they are, to some extent, their real life counterparts. Still, this is meant to be decided by the users of the wiki. With all of this information having been presented, what do you think?
Proposer: Time Turner (talk) Deadline: September 1, 2017, 23:59 GMT
Yoshi the SSM (talk) They are real people. Since most of them are dead, they wouldn't have their real life counterpart for them to be portrayed. It may seem weird to list them with the video game developers, but this then again, these people are listed in the template, humans, weirdly. I mean, who wants Abraham Lincoln, Henry Ford, and Mozart with Ace, Alex, Mario, Luigi, Peach, Daisy, and the last four's baby counterparts. They should be removed from that section. Preferably by outright removing them.
Yoshi the SSM (talk) Per what I said in the above option, but with some added stuff besides what is mentioned in the proposal. If this option is taken, however, the human template should be updated to have those in Mario's Time Machine separated from Mario franchise, but near it. Although this is just a suggestion, this is what I recommend.
Alex95 (talk) - They appear(ed) in both reality and the games, so it makes sense to me that they would be classified as both.
Baby Luigi (talk) Portrayals of real life characters in fictional narratives undertake a lot of different artistic interpretations to alter them in an environment they are worth suited for, and therefore would be considered fictional in a way, and therefore, called a "character". Unlike our articles here that deal with real people, which has their biographies and their roles down, the characters in the Mario is Missing game and other titles are definitely altered from their nonfictional environment to be considered fictional to an extent, and they are NPCs in a game that have the same level as interaction as all other NPCs in other video games. It is worth noting that these people are still direct inspirations from actual living people and retains a lot of traits that are common knowledge to them, so they should definitely be also classified as people as well, unlike parodies of people like those with slightly different names than the ones they are based off of. I'm also not opposed to a creation of a new category dedicated to this hybrid, "Characters directly based off real people" or something like that, my wording is terrible. Bottom line is, this is the most attractive option for me.
vetoed by the administrators It is not up to the users to decided what the staff can and can't do.
The {{talk}} template is extremely useful, but the issues brought up often remain neglected, or answered when the questioner had already forgotten about it. Receiving a relevant answer, no matter what the answer is ("IDK"s count), might take a week to a month. There is even one issue that has been left unattended to for over a year now! I think it's about time we ask certain users to answer certain questions, even if their answers don't quite help the questioner or are even just a matter of "I don't know". Which brings me here. I propose that patrollers and administrators alike potentially add Category:Talk pages with unresolved issues to their list of administrative categories to check on a regular basis, and set it in stone as official policy.
Proposer:Toadette the Achiever (talk) Proposed Deadline: September 9, 2017, 23:59 GMT Date Withdrawn: September 2, 2017, 17:18 GMT
Support
Toadette the Achiever (talk) Let's bring this neglected category back into the real spotlight! Per proposal.
You really can't force people to answer questions, least of all because they may not even have any answers. Hello, I'm Time Turner. 01:57, 2 September 2017 (EDT)
I'm not really forcing questions to be answered, I just want the category checked periodically for new questions. (T|C) 02:30, 2 September 2017 (EDT)
And what do you want them to do after they see that a new question has appeared? If all they're doing is looking at it, then what's the point? Hello, I'm Time Turner. 02:44, 2 September 2017 (EDT)
It's to see if they can easuly answer it or not. If not, they can try to contact another user who might know or answer that they don't know the answer. Really, I'm not asking for admins to be able to answer questions; rather, I'm asking for admins to make an effort to answer questions. (T|C) 02:52, 2 September 2017 (EDT)
It's not as if admins have an intuitive awareness of who is particularly familiar with certain games, and again, there's no guarantee that they'll know the answer. Even if the admin knows the answer, they may be working on another project already or they're preoccupied with any number of admin tasks or they simply do not have the proper opportunity to give a satisfactory answer to the question. Requiring them to keep up with the category, even if they're not required to answer any questions, is simply an unnecessary burden. In short, let them do it of their own free will on their own free time. Hello, I'm Time Turner. 03:02, 2 September 2017 (EDT)
Let's not forget the fact that I intentionally left out the time frame for that reason. Yes, it's obviously not going to be a daily basis, but I think it might be either weekly or biweekly, and yet this also depends for each individual admin. (T|C) 03:11, 2 September 2017 (EDT)
Changed the proposal to address your concern. (T|C) 03:13, 2 September 2017 (EDT)
I never said it was daily, but the timeframe does not matter, especially if you expand if to the point where it becomes trivial. Why do you want to give admins more busywork that they may not even be able to complete in any satisfactory manner? And if this isn't mandatory, this is simply a request and something for the admins to consider doing every once in a while, why require them to follow it? Hello, I'm Time Turner. 03:14, 2 September 2017 (EDT)
I agree partially. Someunresolvedtalkpagesare just policy issues. One question on the Snapjaw talkpage has already been answered, it just hasn't got the ball rolling. These examples, among many others, should definitely be checked by some administerial figure. Though I also agree that somequestions would require someone to be able to obtain or perform something outside the wiki space or the virtual world of the Internet, which isn't always possible. -- -- KOOPACONCARNE
And what are you going to do about the them? (Just out of curiosity.) Yoshi the SSM (talk) 10:42, 2 September 2017 (EDT)
1. There was a discussion about this on the forums. May want to look more into that. 2. From what I've read about before in the past, proposals that affect how the administrative team works is usually frowned upon. Stuff like this is usually brought up internally, or privately. 12:32, 2 September 2017 (EDT)
