MarioWiki:Proposals

List of Talk Page Proposals

 * Merge Harisenbon with Spiny Cheep Cheep. (Discuss) Passed
 * Split from Bramble Scramble (Donkey Kong Country 2: Diddy's Kong Quest). (Discuss) Deadline: August 16, 2016, 23:59 GMT
 * Merge Pokey (Mario vs. Donkey Kong: Minis March Again!) with Pokey, or change the title. (Discuss) Deadline: August 25, 2016, 23:59 GMT

Writing Guidelines
None at the moment.

New features
None at the moment.

Deleting shadow or shadowless versions of artworks
Occasionally (but often enough to have happened repeatedly), users including myself have uploaded both shadow and no shadow versions of the same artwork, and treated them as separate pictures in galleries. Several times, I've seen users questioning the necessity of having both versions stored on this website. Therefore I feel we are obliged to establish a decision through a proposal as to which version we should keep.

An example of the difference may be seen on revisions of File:Dixie Kong - Donkey Kong Country Tropical Freeze.png. Most of the other artworks concerned by this proposal are versions of Super Smash Bros. for Nintendo 3DS / Wii U character artworks.

Proposer: Deadline: August 18, 2016, 23:59 GMT

Replace shadowless with shadows

 * – I would like to see us keep the artworks with shadows, as they would aesthetically be the most true and complete version of the artwork. Onwards, users should be more careful when cropping artworks with shadows. Sometimes it is difficult to be sure when a shadow ends, due to the pixels fading as they move away from the character. We would not want users cropping out parts of a shadow accidentally. – See my most recent comment.


 * 1) - Per proposer.

Replace shadows with shadowless

 * Although this is not my preference, I will explain the advantages nevertheless. Artworks without a shadow are able to be cropped tighter (there will be less space around the image). This means that the artworks will be displayed more clearly when placed in galleries and other small thumbnails.


 * 1) - I'm OK with the other option as well.
 * 2) - Shadows waste too much space, typically unnecessarily. Voting both other options to oppose "Replace shadowless with shadows"

Keep both versions available on the wiki

 * This would set a precedent to upload and document every minor variation of an existing artwork, which I believe is quite excessive.


 * 1) This is an incorrect premise. Supporting to keep both versions do not necessarily open invitations to keep every minor variation in the wiki. As Mister Wu pointed out, shadow and shadowless versions are both used in official media, which can bring up the question of which one is the "real" one. It's less complicated, I think, to just use our own discretion on what variation to use and which variation not to use. It's not much of a huge deal to keep both shadow and shadowless versions in the big picture either, so I don't see the harm in keeping both versions.
 * 2) - Shadows waste too much space, typically unnecessarily. Voting both other options to oppose "Replace shadowless with shadows"
 * 3) Both are necessary.
 * 4) I agree so, let's keep it!
 * 5) Per all.
 * 6) Per all.
 * 7) Per all.

Comments
Frankly, I have good use for both versions on the wiki. I like having official shadows on some areas where I need to use artwork, like scene-building with artworks, and sometimes, when building a wallpaper, I prefer using the version without shadows as it's far more convenient that way than cropping out shadows. Though I don't believe in documenting every single minor variation of artwork, I'd keep having shadows and no shadows. 17:59, 11 August 2016 (EDT)


 * I understand that there are advantages in having both versions. But I have seen users bringing up time and time again whether we really should be storing all these versions. Websites like PidgiWiki are dedicated to documenting and archiving every artwork variation. I just felt that it wasn't within our goal. Of course we want to archive all the different artwork across all games and media, but I feel that the "different artwork" scope we are going by is becoming too narrow when it comes to shadows/non-shadows. Although they're nice resources to have (for user purposes, like you said), it's not necessary for our article/gallery commentary. – 18:25, 11 August 2016 (EDT)


 * I was one person that questioned needing shadow and shadowless where we should only require only one of the two but I never got a response. Gallery talk:Super Smash Bros. for Nintendo 3DS / Wii U -- 18:34, 11 August 2016 (EDT)
 * To be honest, I just stumbled upon the case of the arcade version of Mario & Sonic at the Rio 2016 Olympic Games that uses a shadowless versions of an artwork as main artwork of the character in the official site, while other versions use the same artwork with shadow in other contexts. So, there can be situations in which both of them are useful - if most artwork used in the page is shadowless, an artwork with shadow feels out of place to me.--Mister Wu (talk) 19:14, 11 August 2016 (EDT)

This may be a dumb question, but aren't the shadowless versions technically unofficial, as they have been edited out after the fact by a fan? 19:27, 11 August 2016 (EDT)
 * I wouldn't really say so, because some files are kept in a .pdf format that separates shadows and nonshadows with different layers. You might argue that disabling the shadow layer makes it a "fan" edit, but that they separate layers in the first place is an official move. It's kind of like separating the characters in File:MLPSSXTour.png, but of course, the characters are more important than shadows, so it's not a perfect analogy. 20:37, 11 August 2016 (EDT)

I would not support losing shadowless altogether. Look at Dixie Kong's infobox. Forcing the shadowed image would have the character on the left half of the image and nothing but empty space and a shadow on the right. I agree that galleries shouldn't show both. Shadowless has the advantage that it will always show more of the character. I could support 1) only shadowless or 2) status quo with a new rule that galleries should include one or the other and not both. -- 07:19, 12 August 2016 (EDT)


 * Mister Wu, and Bazooka Mario's vote has brought up some points which I hadn't considered. Seeing as this is generating some discussion, I will leave the proposal to continue until the deadline. And then I'll plan a follow-up proposal to cover Porple's point. – 10:30, 12 August 2016 (EDT)
 * I don't think that the proposal's aim is to only settle on one kind of image and force editing images that have shadows when we don't have an official shadowless image. The priority should be first come, first serve. Easiest maintenance that way. Whatever is unedited and available. -- 20:35, 12 August 2016 (EDT)

Remove critic ratings from the wiki entirely
So in a recent proposal, it was decided that series pages such as Mario (franchise) should have critic ratings removed. My proposal here is to go beyond the scope of that proposal, and expand the decision to every article on the wiki.

Proposer: Deadline: August 18, 2016, 23:59 GMT

Eradicate critic ratings on the wiki

 * 1) Critic ratings have bias to them based on the opinion of the critic, and biases are not desirable on the wiki.

Keep critic ratings on the wiki

 * 1) Reviews are important for gauging the public's reaction to a game. They're also supposed to be professional, meaning that the reviewer's biases shouldn't make themselves apparent in the review.
 * 2) - Very strong oppose; ratings are an important part of how the game was received and we don't feature just any review that pops up, only the more reputable ones.
 * 3) The reasons for removing critic ratings in the (series) pages, for a good reason, do not extend to here. The previous proposal was dealing specifically with the formatting of the ratings content in the (series) pages rather than having ratings information in of itself. This proposal also runs directly against an established MarioWiki policy: Reception and Sales, so this proposal may not even be allowed, especially without any sort of lengthy discussion. As the policy puts it, "illustrating its real-world impact and popularity is just as important [as] detailing the fictional minutiae of the Mario franchise" and if this proposal passes, it will leave a major gap in our coverage of everything Mario, which runs against encyclopedia philosophy.
 * 4) Keep it! Take Mario Kart 8 for example. Metacritic scored that game 88 out of 100. That is why I'm keeping it!
 * 5) Per all. It's an important part of the reception a game has received. IGN and GameSpot (the ones we usually feature) are very reputable sources, so there's no reason to remove them.
 * 6) As I mentioned in that said proposal, having critical reception on these pages does serve a purpose, unlike on the series' pages. It shows the game's general reception, showcases why the sales might be the way that they are and can help the reader decide on whether or not to buy the game.
 * 7) per all.
 * 8) Definitely per all.
 * 9) Per Tucky and the lady with the bazooka.

Comments
@AfternoonLight: no offense, but either I'm completely missing the point, but your argument seems a little weak. I know I'm supporting the same choice as you, but could you still explain how Metacritic's score of 88 on Mario Kart justifies that reviews should be kept on pages? --Andymii (talk) 23:44, 11 August 2016 (EDT)

Create a template for the TTYD badge drop rates
On most of the pages created for the badges that appear in TTYD, there's a handy infobox that shows the rates of badges being held or dropped by enemies during a battle. An example is shown below.

It looks pretty clean and professional. Its code, however, is a much different story.

The code is fairly complex for such a frequently used infobox, and users inexperienced with code can easily ruin the entire infobox by making a typo in the wrong spot. I propose creating a template which streamlines the code found in these infoboxes, making them more accessible and far easier to edit.

Proposer: Deadline: August 17, 2016, 23:59 GMT

Create template

 * 1) Per my proposal.
 * 2) That definitely seems a little complex for a template that's repeated that many times, especially with the alt-text on Hold Rate and Drop Rate.
 * 3) Sounds like fun. We have created many templates including the staff, the games, and the companies so, let's do it!
 * 4) The point of a template is to reduce redundancy by only passing in parameters that need to change how something displays. I agree with this just to make things easier to maintain.

Leave as is

 * 1) Until I see what the proposed template would actually look like, I'm hesitant to support this proposal.
 * 2) The code may look complicated, but if you use copy and paste for the main areas, you will have the thing right. If I see the proposed finish, I might change my vote, but it just needs to be just right. Otherwise, I will say "Leave as is." Reason why? There are a lot of badges. It will be used for all of them. If it doesn't fit like this one fits, I will have a lot of trouble trying to support this.
 * 3) A proposal merely pointing out the flaws in the current template design is no good.

Comments
Of course the coding looks complicated when you paste it without line breaks, that's not what is seen when editing a page. Anyway before I vote, I would like to see your proposed template coding. I think a template would be beneficial to standardize the "drop rate percentage", "hold rate" and "drop rate" messages on the top of the table, and a template would also allow that message coding to not appear on the article page.

However, I have concerns about how an automated template could calculating those percentages. Additionally, you would need to consider how you will allow users to input notes about the unused drop rates, such as those seen at Jumpman (Badge). – 06:08, 10 August 2016 (EDT)

I agree! AfternoonLight (talk) 09:13, 10 August 2016 (EDT)

I received an email from just now. They said that these rates are now outdated. For example, the drop rate of HP Plus for Gloomba is now implied to be 2/249, not 2/200, according to the newer version of the document I cited below. I'm not sure if there is urgent need to update them, but if someone wants, I would suggest displaying the demical form on the page and the fraction form in the mouseover text, since fractions with varying denominators are hard to read.


 * Sounds like a Wikidata for MarioWiki  (By the way, the original data is two-dimensional, meaning they can also be sorted by enemy. Would an update to  be appropriate? There are so much data in that document!)

But the enemy infobox already displays items which could be potentially dropped by an enemy. Unless I misunderstood your suggestion? – 16:51, 10 August 2016 (EDT)

Time Turner: I imagine that the created template would be a generic version of the templates that are currently used on this article (like the one shown above). Pseudo-dino (talk) 03:46, 11 August 2016 (EDT)
 * I'd rather see it put into practice first than simply imagine what it would look like. 15:38, 11 August 2016 (EDT)
 * Here's an example of what I mean:


 * This might be bad template design, I'm not sure, but someone with more experience could do it better, I'm sure. It just matches the current design (but probably uses too many parameters). Pseudo-dino (talk) 18:50, 11 August 2016 (EDT)
 * It's... not exactly user-friendly. This kind of code can get easily tangled up with vague variables, especially when there are a lot of them. I'm also interested in seeing the proposer's rendition of the template. 19:31, 11 August 2016 (EDT)
 * How about two templates where the main template is responsible for the table as a whole and a sub-template that is responsible for each table row? -- 15:29, 12 August 2016 (EDT)
 * Or you know, just have the beginning of the design put in a template, then use it as normal:
 * Or you know, just have the beginning of the design put in a template, then use it as normal:


 * Poison Puff
 * 0/200
 * 2/300
 * Spiny #2 (Glitz Pit, Spike Storm)
 * 0/200
 * 2/300
 * }
 * Other than this option (which is actually preferred, because if a change is needed in the code, it's better to update it in one location), I wouldn't support the proposal, having countless parameters is just silly.-- 06:45, 12 August 2016 (EDT)
 * Other than this option (which is actually preferred, because if a change is needed in the code, it's better to update it in one location), I wouldn't support the proposal, having countless parameters is just silly.-- 06:45, 12 August 2016 (EDT)

Miscellaneous
None at the moment.