MarioWiki:Proposals

List of Talk Page Proposals

 * Split the sections Attackathlon, Toad Quiz and Lakitu Info Centre into and  (Discuss) Passed
 * Merge Wooden Block with Hard Block (Discuss) Passed

Writing Guidelines
None at the moment.

New Additional -Like Tags
Over the course of me checking the quality of images I have come across and potentially uploading better quality images anyways, there has been some controversy with me and maybe a few other users of using in the best possible way. Some people have claimed that some usage has been too liberal and the image should be left alone while others agree that the tag should be issued, even if the image isn't that bad in quality but could use a better replacement anyways. To be fair, there isn't much of a definition to on when to use it. This leaves too much room for interpretation, which can lead to conflicts. The current state of Category:Quality requested is overflowing with images (at this time, over 1,000 images need to be fixed). Ultimately, I think we can all agree that MarioWiki deserves the best possible imagery. One tag to keep ~70,000 files in check isn't going to cut it anymore. I think I have come up with a solution that can stop these debates.

First part of this proposal is coming up with rules how to use these image quality tags. See User:Wildgoosespeeder/QualityRequestTypes/sandbox. This sandbox user page is based on my observations of how other people interpreted the current and  tags. The color coding is just a way to convey severity very clearly. This may or may not be part of the final product.
 * Part 1

The next part of this proposal is showing you the additional tags and how they would look when transcluded in image pages.
 * Part 2
 * File:Glide64 2.png
 * User:Wildgoosespeeder/PNG/sandbox
 * User:Wildgoosespeeder/Tweak/sandbox

As for why the copied code from looks thin on the PNG and Tweak sandbox pages, I don't have any idea. The only thing that was changed was the display text. I can't figure out why this is happening. So, for now, pretend the thinness doesn't exist. Also notice how my additional image quality sandbox templates don't put File:Glide64 2.png in Category:Quality requested but rather Category:PNG requested or Category:Images that need improvement instead. That way, congestion in Category:Quality requested will be reduced and be more manageable.

The last part of the proposal is hierarchy of categories:
 * Part 3


 * Category:Image requested <--Click this to see current hierarchy of categories.
 * Category:Articles that need more images
 * Category:Quality requested
 * Category:Images that need improvement
 * Category:PNG requested
 * Category:SVG requested
 * Category:SVG requested moved to a subcategory of Category:Quality requested

The category names are not final and is subject to change. Category:PNG requested and Category:Images that need improvement will just be a subcategory of Category:Quality requested. The two subcategory links will appear in Category:Quality requested and nothing more.

If this proposal passes, images currently in Category:Quality requested will be reevaluated and organized accordingly. Category:PNG requested and Category:Images that need improvement will be created with categorization contents of .The  and  tags will have the contents of User:Wildgoosespeeder/QualityRequestTypes/sandbox and have additional rules and guidelines added somewhere in its   coding, just like User:Wildgoosespeeder/PNG/sandbox and User:Wildgoosespeeder/Tweak/sandbox currently do.
 * Conclusion

Proposer: Deadline: April 16, 23:59 GMT

Support

 * 1) I'm very certain this would be appreciated by all. I hope this proposal passes because it will be needed to make User:Wildgoosespeeder/sandbox more acceptable for a future proposal (TBD).

Oppose

 * 1) I like some of the ideas in this proposal namely splitting off the quality requested tag to different categories of maintenance, but some of the new features introduced here are things I really don't like, which includes the idea of having a tag on any image that isn't perfect. Bazooka Mario and Megadardery has basically explained why that feature in particular is bad; as Mega said and as I previously thought before writing this, it's like tagging not perfectly-written articles on MarioWiki with an improvement tag and we'll have those dotted all over the wiki and we'll look particularly bad to readers. However, considering that this proposal is an all or nothing proposal, I have to go with Oppose here because of how much I don't like adding yet another image tag that we would add to 70% of images due to its very vague and unclear guideline to what exactly constitutes as that, not to mention that there are a lot of parameters and variables into determining whether an image is bad enough or not. You should bring this up in discussions and the collab boards in Marioboards for more input. I strongly feel that this proposal isn't ready yet to be inputted, and it should go back to the drawing boards before we consider the option of implementing it.
 * 2) Per all, including myself: But my biggest feeling towards this kind of thing: We provide information, along with nifty images for clarification. Terrible quality images urge to be replaced, because they do not represent the console-quality nor the subject in question, Decent quality is good, of course Perfect quality is preferred, but it's not the main concern. And very very select amount of people bother regularly with the images. It's also why I don't like how Wii/GCN images are oversized, and N64 images are proposed to be undersized.

Comments
As for the proposal, I'm not sure how feasible this would be. No one likes bad quality images on the wiki, but even moderate quality images would have to be tagged with maintenance categories, and I'm not on board with that. Although we have some more organization, the majority the images could just be recategorized under "Category:Images that are almost perfect", which may also be a place for acceptable images, not categorized prior to this proposal, to be newly lumped in a new, vague maintenance category. This is goes against the proposal's idea, to help sort through the stuffy "quality requested" category. In other words, if this proposal passes, this (lack of transparency), this (.jpg and lack of transparency), this (.jpg), this (watermark), this (low resolution), this (low resolution), and who knows how many more will qualify under the "almost perfect" category because they all have some flaws, in parentheses. This might free up the original quality-requested maintenance category to leave just the potatoes behind, but the problem of a bloated category would be transferred to your proposed one.

I think the "images to be in PNG format" is a step in the right direction since the category is specific, but its function itself, I don't agree. This invites users to replace .jpgs for .pngs for the sake of it despite no benefit other than nice-looking thumbnail images, but loss of bandwidth and bloated file size. We have some strange stigma against .jpg quality images when there shouldn't be. People don't appreciate how much compression a .jpg can have. Some images simply cannot be uploaded as .png due to the sheer file size (this Mario Tennis Ultra Smash artwork cannot be uploaded as a .png without serious scaling). I imagine that the category would work if static sprites were in the inferior .gif format, but that's already covered by policy, so the static .gif sprites should be replaced. Furthermore, given that static .gifs are usually old and confined, it's not worth creating another maintenance category.

On the other hand, I think we can definitely add more subcategories under quality-requested. Off the top of my head, we could organize it by screenshot, artwork, sprite, render rather than the subjective "almost perfect images". We could add more specific reasons for reupload requests such as resolution, poor color quality, but I also think those in general is already covered by organizing by type of image (e.g. there would be little reason to request higher resolution for sprites so resolution requests would logically apply to screenshots and artworks only). This is an idea, though, not a very developed one. It's feasible to add additional categories by type of image, but it's going to take a lot of effort. Still, I think it might work to organize all low-quality sprites in one spot and all low-quality screenshots in another spot and then we can more easily examine at a glance what needs tweaks and what doesn't.

In the end is intended to be for images that seriously need uploading. I think users are taking it too far by scrutinizing every flaw a screenshot or artwork has and then slapping this template there. However, I acknowledge that there is indeed a problem of trying to communicate these flaws due to the lack of options. For instance, you end up lumping decent images like this into the same category as actual potatoes like this by using your image request template as a means of explaining the flaws. Creating a maintenance category of "almost perfect images" is a good attempt, but I think it has unintended issues such as decent images that are at a modest resolution or has a ugly white background going into a category intended for images with slight, but bothersome glitches. This stems from the vague and subjective definition of what an "almost-perfect" image is, which is the core of the problem of this proposal. 22:37, 9 April 2016 (EDT)
 * The categories are not final. Naming, definitions, and amount of additional categories need work.
 * Keep in mind, I am coming from a place of dealing with in-game content, such as screenshots, sprites, and 3D renders, and not so much the artwork accompanying it. We can add a clause to the PNG template that discretion should be advised for images tagged with or  for examples. Images tagged with, , or  that are not in the appropriate format, there is no doubt to tag with the PNG category. For PNG, GIF, and JPEG, I think that a lot of people are misinformed on when to use those formats so they end up using those formats interchangeably, resulting in haphazard uploads. Also we should implement a policy relating to not converting between formats before upload as that process has unwanted byproducts, such as color loss (to GIF), artifacting (to JPEG), and file size bloating (specific to JPEG to PNG literal conversion). As for static GIF replacement with PNG, who's going to go searching? A tag just makes already known things be put into a log of sorts and increases its chances of getting a suitable replacement. When we mean convert, we mean a resampling of the image and save in a more appropriate format.
 * I am very on-board the idea of removing as much of the subjectivity surrounding the use of and any other new tag that may have unintended consequence of excess subjectivity as possible. How do we do that?
 * The tag with Category:Images that are almost perfect Category:Images that need improvement as the category name was an attempt for already existing PNGs tagged as, , or  to need a certain quality upload, free of unwanted artifacts suitable for Wikis. The  tag with Category:Images to be in PNG format Category:PNG requested as the category name is to get images tagged with , , or  to be in a more appropriate format, but resampled first and not literally converted to the format. -- 23:54, 9 April 2016 (EDT)

I need some changes/questions answered before supporting. -- 00:00, 10 April 2016 (EDT)
 * 1) Category:Images to be in PNG format should be Category:PNG requested to keep it consistent.
 * 2) Is there going to be a guideline for which images need to be in PNG format or does this pretend to convert every other format into PNG? Because, as Bazooka Mario pointed out, not all files need to be PNG's.
 * 3) Rename Category:Images that are almost perfect to Category:Images that need improvement. It's an important change because almost perfect is way too broad of a concept. Needing improvement, on the other hand, is a tad more specific.
 * I agree with every point you made ! I'll put in those changes. As for guidelines, already started out working that out in a commented directed to . -- 00:11, 10 April 2016 (EDT)

Ok, for starters, this should have been a collab/discussion on the forums, it has too many options and details to be a direct proposal.

I agree with LGM on many points, but here is my semi-detailed take on this: The "Category:Images that are almost perfect" would be good, that is in a perfect world, it is like putting a rewrite-expand on every single page missing a small piece of information, which doesn't only clutter things, but it makes some users, who are willing to help, feel a bit overwhelmed -for my lake of a better word- when they are replacing images. For starters, sometimes a replacement cannot be found at all, especially when it comes to unreleased games and some old artworks, putting a request of improvement in that case would be completely wrong. Making this category will just increase the "to do maintence work", which doesn't get that much attention anyway, at least from most users.

However, renaming the category to "Category:Images that need improvement" would actually kinda solve my issues. But still, I fear that 70% of the wiki images will have this tag, even though they would not deserve it, for example, a Paper Mario image that is 20px off the preferred size should not get this category and should not get any "quality" categories. This and this (if it wasn't oversized) seem almost perfect to me, perfect enough to not have a tag. this is undersized and should get a tag (and a better name, for that matter). It's just, you can't make a rule for this thing.

However, I agree with separating it into multiple categories for the shots, sprites and artworks and whatnot. It would reduce the clutter in quality image category.

Convert to SVG needs to be deleted. First, it encourages fan-made logo SVG, which should not be allowed. Second, afaik, it was briefly used on old small sprites, because on the old mediawiki, resizing those sprites would blur the image, right now, nearest-pixel zoom is enabled on all browsers. So it doesn't currently have a use.

Last thing... why? The images are here to show one thing, the subject that we are talking about, sure it is better to have it bigger, but why bother and make countless improvements to the system, instead of improvements to the images themselves if possible? We already had the sweat guy User:RAP make a mile long list of images that need improvements, it didn't even reach 10% done. More tags are not going to help it, if the image is terrible, than it deserves a tag, otherwise, if the subject is clear, and the image is of a reasonable size, it's good to go, move on to another image. Priorities.

I might continue talking about this later, I just don't have much time right now.-- 17:09, 10 April 2016 (EDT)
 * I haven't directly addressed pre-release images yet but in User:Wildgoosespeeder/sandbox (future proposal), I revised the introduction to narrow down what should require a PNG (unused content) and what can be left alone in its current format (pre-release screenshots). I'm split. I definitely don't agree with 's tagging of some pre-release images, unless there is a BMP source and someone didn't think twice and used JPEG or GIF.
 * File:Koloradocamp.png, that would be tagged on the grounds of a JPEG not resampled but rather directly converted into the PNG format and was not sampled in native resolution, which I'm against. File:PM 64thTriviaQuiz-off.jpg, there is a lot more consistency with screenshot taking in native resolution in an N64 emulator than Dolphin Emulator (different story). I'm not oversizing GameCube and Wii emulator images because it is HD versions of a SD game. I'm doing it because it is just easier than the work-around way that really needs to be recoded. Generally speaking, oversized images cause terrible blurring to HUD elements because most are sprite-based, especially N64 images. I have found two offenders and since corrected the problem (File:Peach's message.png and File:PMBowserBattle1.png).
 * I'll consider splitting into screenshots, sprites, etc., but at a later point in time. First we need to see how the first implementation goes (if it passes).
 * I honestly thought that was used to have scalable logos and not for making graphics more scalable without blur. If that is the case, I merely thought that the tag was repurposed for better things.
 * I find that personal lists don't solve the problem of getting better replacement images. A tag is an easy-to-spot flag that catalogs into a category while a personal list is mostly hidden from direct public view because it is not a page considered maintenance. Who's going to know about it? Only a few users know about it. -- 20:17, 10 April 2016 (EDT)


 * Voting comments

I can understand where you are coming from with your concerns surrounding tagging in general because it can be an eyesore to the flow of the article. When you think about it, isn't that part of a tag's design? The tag isn't supposed to be there but it is (if there is a good enough reason for it to be there, even more so if an exact reason is specified by the tag's parameter). It should let anyone know that the article or section needs attention. No tag on articles means the article has less of a chance of getting attention. I can also understand over-tagging things too as meaning can be lost. I always thought that, , , , , and carried, from highest to lowest, a sense of how much an article needs to be improved. I'm not very clear on when to use those tags anyways because even those tags have vague to no description on how they should be used which leaves room for interpretation. I feel like I am running on interpretations, which leads to unwanted debates and confusion. Same goes for and. MarioWiki is striving for professionalism so wouldn't it make sense to have professional-looking images be in higher demand to give the impression the articles show a professionally-taken image? -- 16:05, 11 April 2016 (EDT)

I can't help but feel some of my commentary towards you is being ignored or you are picking out certain things in this discussion that have little to nothing to do with the proposal at hand. I am not suggesting N64 images to be undersized. I think you are confusing internal resolution with output resolution of real hardware with your N64 argument. The internal resolution of an N64 is mostly going to be 320x240, with a few exceptions of having the resolution be 640x480 or some weird resolution (based on angrylion's graphics plug-in found on TCRF), but the analog video signal converter thing that any Nintendo console has before Wii U converts the internal resolution into a signal a SDTV can understand, which is 640x480 composite video. That is why NES and SNES games tend to look pixelated on TVs but an emulator looks sharp because the internal resolution is 256x224 or 256x240 and that resolution is being stretched to fit a 640x480 TV screen. As for oversized GCN and Wii game screenshots, I told you many times I am not advocating oversized imagery. I find it much easier to take screenshots in that manner. I advocate a bare minimum, which is 640x480 for 4:3 and 854x480 for 16:9. A few exceptions to this rule exist because general game hackers are finding true internal resolutions of some of these games being a little bit smaller than those resolutions but my experiences and uploads are based on outdated code that still needs to be fixed that Dolphin Emulator developers haven't fixed yet. -- 16:05, 11 April 2016 (EDT)

Removals
None at the moment.

Merge all YWW [X] Patch Articles with Their Non-Patch Articles
In Yoshi's Woolly World, some enemies, such as the Ruffin Tumble, have a patch form, that is simply a pixelated version of the original enemy; they're the exact same as the originals, except that they look different and that the patch forms are seen in blocks, and are released after the block is eaten. I don't think that one minor difference is enough to warrant separate articles for the original and the patch form. The only thing that might be a problem is their positions in the Scrapbook Theater, but I'm not sure that warrants separate articles either.

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

Support

 * 1) My proposal.

Implement or Delete
I created this template as a draft with the idea of placing it on every wiki page for Mario Party boards. I do not, however, want to put it on before passing this idea to the community. I think this template would allow for easier navigation and support its implementation for that reason.

Proposer: Deadline: April, 12, 2016, 23:59 GMT"

Implement

 * 1) per proposal
 * 2) This definitely works and will benefit navigating the wiki although I must agree with my sister. Next time, create a draft page in your userspace first so you can edit and stuff without having other users possibly notice this template and then start using it, especially if you're just going to end up creating a proposal on its existence.
 * 3) Per Bazooka Mario.
 * 4) - Per Bazooka Mario.
 * 5) Per all.
 * 6) Seems extremely useful, implement it.
 * 7) Per all.

Comments
You should have created a specific draft page for your project before you create an official template. Anyway, your colors are all wrong. Look at how other Mario Party games format their cell colors (an example being Mario Party 5's nav template). Your first style background should be #FAFA00, not #FFFF00, and the second color should be #FFFF33. And if you're going to separate the boards into two categories, you need to specify and create specific cells for each type (split the single player and multiplayer boards into their own cells, not lumped under a single game). The text on the left cells should be centered and bolded. I do support the addition of a navtemplate for the Mario Party boards, as I think it could get one considering Mario Party is a big series, like Mario Kart, that probably should get navtemplates in a similar vein to how it gets racetracks, but please format it correctly when you create new navtemplates. 17:50, 5 April 2016 (EDT)