MarioWiki:Proposals

Writing guidelines
None at the moment.

New features
None at the moment.

Removals
None at the moment.

Part 2: What should be included in enemies lists?
I think enemy lists should include counts, because that helps define the level: a level with one throwaway enemy is quite different from a level heavily populated by a certain enemy. As a corollary to this point, I have removed my vote from my original main option of the other proposal, since enemy counts as a defining factor in the level means they probably deserve their own section. Obviously, implementing this would be a long-term process, but I think if we're already listing the enemies, it's not too hard to gradually add the counts (and situational specifications, like counts in different versions) as well.

Proposer: Deadline: May 8, 2018, 23:59 GMT

Include enemy link and enemy counts

 * 1) (Proposer)
 * 2) Having enemy counts doesn't really seem like a bad idea, if a bit hard to correctly list in longer stages. It lets a reader know if a level is based around a particular enemy or set of enemies.
 * 3) per all
 * 4) Per proposal.

Create a template for reception tables
According to the reception and sales policy:

''"A review listing template has been created to more efficiently present the information and prevent the summary from being a succession of "so and so said X, while so and so said Y". Here's the code and an explanation of the parameters:

"

However, I don't see why this is actually a template yet. It won't really hurt to add one (and given the many prior proposals to templatize certain repetitive features of the wiki), hence why I am proposing this. There are still many reviewers and aggregators out there, so it may take a while to add them in, but I've added quite a bit in the meantime. The only real problem is figuring out how to configure the URLs (since some links are inconsistent with others on the same site), but it's also something we can fix as we go on.

One big change that supersedes the original is listing the reviews and aggregators in respective alphabetical order. I think that's a good way to go since none of the other possible methods seem doable.

I have an aforementioned draft, which you can view here.

Proposer: Deadline: May 8, 2018, 23:59 GMT

Support

 * 1) Let's get rid of the raw coding in favor of a template; per proposal.
 * 2) Per proposal.

Oppose

 * 1) - I honestly think it's easier to code a table from scratch rather than using templates, but that may be just me. Especially when there's a ready-made code listed as above. Even if it's the same type of table, transclusions for tables/charts can be finicky. And by "template" in the policy, it means there's a ready-made code ready to be used, not necessarily the "templates" we use to transclude information.

Comments
I'm pretty split on this proposal. On one hand, I'm not a huge fan of copying this very specific table with its raw-coding displayed article to article to article but on the other hand, I just don't see too much benefit from creating a template out of this either because of the sheer number of variables this review table has, unlike the proposal outcome template which is far simpler to write out. I don't have particularly strong opinions either way, though I am leaning on support there because I also think displayed the raw coding for this table in our policy page looks really messy from our end. 22:43, 6 May 2018 (EDT)

Miscellaneous
None at the moment.