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.

Stricter Image Quality Tag Policy, Additional Image Quality Sub-templates, and Dividing Images in Category:Quality requested Into Subcategories
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)

On your points.

Pre-release screenshots are another issue. There should be much more leeway given their limited means of getting them. I wouldn't worry too much about them nor would I be tagging them with image-quality unless they're really bad.

If naming and defining categories are a work in progress, you should discuss it first before firing a proposal. That way, there won't be any confusion and questions on them, and it would free time and energy to discuss the actual proposal. And that's another issue: I agree with Baby Luigi that the proposal is premature. These big changes aren't established yet. I also agree with Megadardery on elaborating "almost perfect" category's issues. I also share concerns on his proposed "images that need improvement"; due to the heavy overlap with the current template, the name might as well be the current tag in another name.

Also repeating Megadardery: .svg requests should be removed. We have had this issue with Smash Bros. emblems. Although they are in .png, the problem remains: vector programs such as Adobe Illustrator are far from perfect. To create .svgs from .pngs, you need to trace them with those programs, but the result leaves much to be desired and, worse, is misleading. If you have .svg images straight from the press such as this Mario image, however, you can replace the existing .png. The .svg here is far superior here and is closer to the vector-nature of original artwork, thus retaining the main advantage of vector graphics: scaling them.

File:Koloradocamp.png is not in an appropriate format (a bloated .png), but .jpg is acceptable for screenshots. The advantages of .png, transparency and color preservation, are less important in screenshots, and the .jpg format saves significant file space, .jpg should be the recommended format for screenshots rather than .png. As for oversized resolutions, we're not as stringent as Bulbapedia or SmashWiki in retaining native resolutions. While retaking screenshots at native resolutions helps and we really don't need screenshots at multi-K pixel resolution, it is also not worth the effort to go backward and reupload them all just because resolution is incorrect (but the aspect ratio is good). We're concerned mostly about aspect ratio and the sheer quality of the screenshot. So, some of these images shouldn't be tagged, and that includes the screenshot I linked.

I've suggested personal lists in the past because image management is mostly a small-scale job i.e. it's done by a few users. If you'd like to have users make great use from your list, then organize a project in our Wiki Collaborations forum and link to the appropriate userspaces as resources. You can also link to RAP's page as well as, again, a resource. We all appreciate it. It has worked in the past; on enemy stats, Megadardery let us use his sandbox as a neat spot for data collecting and I also believe as a template, and it's a tremendous help.

I'll help clarify on improvement tag hierarchy. Actually, there really isn't a hierarchy except construction and stub are reserved for lacking and barren articles. The rest are also meant to be serious, but not as much as construction and stub.


 * generally very lacking article or the article is currently undergoing major changes. The tables are visibly incomplete, sections are clearly missing information, big changes are currently being made in the article, most information are in a mere list, and other big problems that would be considered an "informal appearance".
 * the article has serious problems, be grammar, writing style, organization, image clutter, formatting, and other reasons the user can specify.
 * the article is seriously missing information. This generally includes entire games that should be there, but are absent. Or, if it's a level article, there isn't enough information on its layout.
 * a minor issue. Could overlap with rewrite.
 * the article could use serious expansion. Unlike rewrite-expand, this is reserved for tiny articles that lack sufficient information. This is not to be confused with short, but complete articles, which provide all possible information without having to pad. For instance, if
 * the section is seriously lacking information and is often a one-liner. The Wario article, for instance, has this template in its Mario & Sonic at the Olympic Games sections. It is one sentence stating the obvious, yet there is a whole story mode in that game, and Wario even has his own dialogue and role.

Keep in mind, these aren't set-in-stone rules, but based on my observations and experience with the wiki. Either way, I hope I gave you a clearer image for these templates. Finally, don't worry if there isn't a written rule, just use your common sense and keep Don't Shoot Your Foot Off in mind. 18:05, 11 April 2016 (EDT)


 * Images such as File:SMG2 dark mario.jpg I can definitely agree with you do not need but an image such as File:3DMARIO.png does need.
 * Honestly, I didn't expect more work was to be done to my proposal. Seeing the response so far, I may just as an admin for approval to cancel the proposal and postpone it to a later date.
 * OK, I guess removal of is in order but I am not 100% sure it should be removed.
 * I'm 50:50 with PNG vs. JPEG use for screenshots. JPEG would definitely not be acceptable for screenshots of sprite-based games (such as NES, SNES, GB, GBC, and GBA games as well as some games that don't utilize true 3D of N64, GCN, Wii, Wii U, DS, and 3DS games). Compression for those screenshots would almost always be lower in the PNG format than the JPEG format. PNG is great for solid colors while JPEG is great for images with shading. I just default to PNG almost always because it is a very easy format to work with. My experiences with JPEG, I have to fiddle around with compression settings to not be too high in file size while the image doesn't look like it suffers from JPEG artifacting. It's usually a pain for me to work with JPEGs.
 * I feel that personal lists risk being exclusionary and obscure to regular users. 's project failed mostly from what I heard (only up to 1/10th of the images were replaced over the course of a few years and there are still images in poor quality). Tagging an image that could be better is more up-front about it, increases replacement request exposure, and invites people who don't know about the personal lists to contribute better images to the Wiki because that is how the tag functions by design and implementation. I think I was able to replace more images by the tagging method than the personal list method.
 * Wow. I wished those details were included in each of the template's code. I remember  proposing something about  being used incorrectly (something about articles truly being informal). I could never really fully understand what the proposal was asking because the tag itself had a lot of subjectivity surrounding its use. If the tag's description had what you described to me is its proper use, I'm sure his proposal wouldn't need to have been proposed.

Thanks for all your helpful feedback. You and have been the most helpful. -- 19:17, 11 April 2016 (EDT)


 * Not sure why you are prematuarly jumping to conclusions, I believe you are incorrect. First, My oppose was based on my comment and the reasoning I put in the vote. So I was not just picking random things to make a vote. Second, I brang the issue of N64 and Wii resolutions because, as your current proposal implies, these would not be of a perfect quality, and that could make them have this tag as well. And no, I'm not confusing IR and the actual resolution, I said clearly, and multiple times that images should match how the game looks.. nativally on a console, as if emulators never existed, if you take an N64 shot using a capture card it will be 640x480. You also can take Wii/GCN screenshots in a close-to-native resolution easily, but it is not a major issue, that's why I didn't make a serious action against oversized screenshots.

"[...] .jpg format saves significant file space, .jpg should be the recommended format for screenshots rather than .png.", Porple said before that disk space is not a concern, and if that's the case, quality over bandwidth in my opinion.

I stay by my point that should be reserved for images in urge for replacement, and not further, less-serious, templates should be created.-- 19:12, 11 April 2016 (EDT)
 * OK, some misunderstandings occurred. We both misunderstood each other. I hope I can be clearer. First, I have since dropped the original name I gave the categories as provided a less subjective name and I have adopted it. The category will no longer look for "perfect images" but rather something that is clean. Technically, yes, the screenshots I have uploaded of GCN and Wii games would qualify for one of my new proposed tags or go against my own guidelines because they aren't in the right resolution but where those images came from and the faults of the program that produced them is a different story that I have no real control over so it isn't as easy as you make it out to be. If the program wasn't faulty at native resolution when taking screenshots, I'm sure we wouldn't be having this conversation. As for what qualifies as a good N64 screenshot, the capture card method looks at the composite video signal, which is analog, which analog signals are known to degrade over a distance. Longer distances means the degradations get more noticeable. The internal resolution is digital. Digital has no degradation. Screenshots should be taken from this source instead. If that source happens to be 320x240, this is considered the highest quality possible screenshot that is the closest to actual hardware. A few exceptions exist, but it will most likely be 320x240. I see a lot of N64 screenshots forced into 640x480. If I went to the exact spot one of those screenshots are referencing, the pixel-perfect plug-ins I use would be saying the screenshot I selected is 2x in width and height and any HUD elements would see terrible anti-aliasing or pixilation. That means that the emulator image is processing graphics far beyond what the N64 is capable of. In the case of a capture card, it is just taking a screenshot of an upscaled 320x240 image with some level of analog degradation. That is poor quality.
 * I also get the need for JPEG, but it should be used with caution, just like PNG. JPEG, I have such a hard time figuring out the right level to set the lossy compression at. If I didn't have such a love for PNG and I wasn't stupid with JPEG, I would say upload the version of the image that is space-efficient (after PNG Monster compression). I will admit that it is hard to tell the difference between a high-quality JPEG with a properly captured PNG of the same subject, especially 3DS game screenshots. It's easier to point out JPEG quality loss if solid colors are involved. PNG is better for solid colors, getting even smaller than JPEG sometimes.

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.

Comments
It may be an issue if all enemies have a patch form, but it seems to me that we have only Bullet Bill Patch, Monty Mole Patch, Nipper Spore Patch, and Ruffin' Tumble Patch that exist. Maybe it's not so bad that we leave it as it is? 19:14, 11 April 2016 (EDT)

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.
 * 8) This is useful indeed! Per everyone!

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)