MarioWiki:Proposals

List of Talk Page Proposals

 * Revamp the images on the Trick page. (Discuss) Deadline: October 2, 2015, 23:59 GMT
 * Overhaul the "Aliases" and the "Occupations" sections in the Mario article. (Discuss) Deadline: October 5, 2015, 23:59 GMT
 * Split Giant Kamek and Kamek. (Discuss) Deadline: October 15, 2015, 23:59 GMT

Writing Guidelines
None at the moment.

Add a 3D render licensing template
We have this proposal for earlier reference. It failed mainly because of legal redundancy. I understand that already covers this issue. Currently, however, 3D renders such as this, this, this, this, this and this are lumped with sprites in this category. This is not good when one of our wiki policies already took pains to distinguish between what's a sprite (including pre-rendered sprites) and a live rendered model. So, the legal argument is not a valid point against creating a template and a category, and it fails to address a more immediate problem, which is an organizational one, in this wiki. This proposal aims to remove this disparity by including a licensing template called and its content will look like this (embedded categories excluded):

Again, the legal issue is not the main point I'm going for; we need this so we can organize such images into a convenient category rather than awkwardly lumping them with our sprites. Our current way of doing this violates the policy I've mentioned earlier, so taking a step to include a separate category (which will have more than enough entries) would benefit our wiki.

One possible alternate option would be to rename the category, but it would be an unnecessary hassle to rename all of those categories, and it wouldn't help with our organization at all. Again, we're supposed to treat sprites and renders as two separate and distinct entities as outlined by MarioWiki:Good Writing. Otherwise, you might as well just lump everything under like it used to be before  was created in 2011. I think just creating a new one to cover the renders is a far better and consistent option.

There is also another option to simply add a new category but that doesn't solve the licensing by itself, so you have to edit the licensing template to accommodate 3D renders, making it more convoluted than what's being proposed.

We can also go with "3D model" rather than "3D render", but "3D render" is much more precise and not too jargon-y. If there is a sudden call to change from "render" to "model", please let me know.

If this proposal passes, it will overturn the previous proposal and will give us one more drop-down option under licensing when you upload an image.

Proposer: Deadline: October 3, 2015 23:59 GMT

Support

 * 1) Per proposal
 * 2) Per all.
 * 3) please for the love of god yes, i keep asking for a licensing template that would differentiate between two clearly-wouldn't-be-more-different things
 * 4) They are two different things. I agreed to making a separate licensing template back in that previous proposal. So heck yeah this is a per proposal.
 * 5) Per all. Even though the trouble that will arise from this is not little, it is clear that sprites are not models. "3D render" also sounds a lot better than plain "model".
 * 6) Per all.
 * 7) Per all.
 * 8) – Per all.
 * 1) – Per all.

Comments
Megadardery: "Even though the trouble that will arise from this is not little[...]". Elaborate? I don't think this will cause any problems other than a little reorganization, but it's not like we haven't done this before. 15:24, 27 September 2015 (EDT)
 * Pretty much the "surfing the wiki and finding all 3D models" is what comes to my mind. Plus the fact that few users would not notice this proposal, and continue marking models as sprites. Plus the fact that some users would still confuse some 3D renders as sprites (NSMBDS comes to mind). It's an inconvenient to say the least.-- 12:00, 28 September 2015 (EDT)
 * Well, that's not stopping us from at least making an effort to reorganize the renders. We've made drastic wiki organizational changes before, such as removing "beta" and "sub-species" terminology. Sure, users will probably categorize renders from sprites, but it's not different from any other type of bad categorization, poor formatting, or even bad grammar. Hell, it's why we have this section in policy. We can't just leave them like that. 20:40, 28 September 2015 (EDT)
 * Which is basically why I'm supporting.-- 12:16, 29 September 2015 (EDT)
 * I don't even know if nsmbds uses sprites or prerendered models. Some enemies are clearly sprites. Even the player models have frames ripped in the spriters resource. 19:22, 29 September 2015 (EDT)
 * Well, they're still technically renders, but I'll give the benefit of doubt and say that Mayro, Loogie, Pitch, Bowz, and Junior are 3D renders. 19:35, 29 September 2015 (EDT)

Removals
None at the moment.

Make location infoboxes more appropriate for buildings as well
I propose us to make location infoboxes more fitting to articles on buildings. That is because the current one uses the terms greater location, ruler and inhabitants, which seem more suitable/common for regions. We could create a switch to a "building" option, that would switch:
 * Greater location to Location;
 * Ruler to Owner;
 * Inhabitants to Residers.

Proposer: Deadline: October 4, 2015, at 23:59 GMT.

Support

 * 1) Per my proposal.
 * 2) Per Mr. Ice Bro. (Though I'd advice changing "Residers" to "Residents").
 * 3) It makes a lot of sense to do so.

Oppose

 * 1) Very vague. Good idea, but too vague.
 * 2) - Simplifying "location" is a good idea, but it would be a mistake to make the other two changes: I'd rather "owner" be added instead of replacing "ruler", and "inhabitants" works perfectly well for both types of places.
 * 3) Per Walkazo.
 * 4) Per Walkazo.
 * 5) Per Walkazo.

Comments
Changing "greater location" to "location" would make sense either way, but "inhabitants" already works for buildings, so I think that one should be left alone. Also, while "ruler" indeed doesn't work for buildings, "owner" would sound awkward for countries and whatnot, so why not just make both variables usable? "Ruler" is already optional, so just add "owner" as a different optional variable, and then both types of situations are covered. -

Roy Koopa: If it's too vague, then what parts of the proposal do you think needs elaboration? Also, I agree with Walkazo, just add more if parameters into the infoboxes. This probably doesn't even need a proposal for such an inconsequential change. We don't need a new infobox, just add it to "location". 15:27, 27 September 2015 (EDT)
 * It's vague because the only reasoning is "this is bad we should change it to this." RoyNSMBU.png Roy Koopa 18:37, 28 September 2015 (EDT)
 * The propositions seem to be fairly specific though, but I do think elaboration is needed for why these propositions are needed, but inferring from the propositions and proposal titles, it seems to be apparent. That "location" as it's currently used also covers "buildings", which is pretty awkward. 20:22, 28 September 2015 (EDT)

I don't know. Some things work in this proposal, others don't. I personally think Walkazo's idea is the best. I'm not voting yet either way as of now.

Miscellaneous
None at the moment.