MarioWiki:Proposals

Expand Featured Articles writing guidelines
Currently our writing standards regarding what constitutes as a Featured Article at MarioWiki: Featured Articles is a vague list of short phrases and one-liners, which makes it far too loose to interpretation to my liking, especially for a process where quality control is key and enforcing these guidelines is a pivotal step to picking out only the best articles in MarioWiki. I propose that we expand these guidelines into small little paragraphs, detailing what exactly we want out of a Featured Article. This will follow the model similar to how we write out our good writing policy, where key points are organized under a header as a list first, and a paragraph detailing what we want under the header will be elaborated on.

If you want the specifics on how exactly I want the writing guidelines to look like, I have worked on it in the following sandbox page, where most of my proposed points is detailed out and worked on


 * User:Baby Luigi/Featured Articles guidelines

If you suggest any improvements to the writing or any further clarity, please comment on the proposal!

Proposer: Deadline: February 15, 2018, 23:59 GMT

Support

 * 1) Everything looks nicely policy-oriented, clear-cut, and not too confusing for the average reader. Per Baby Luigi.
 * 2) Strong support. While I'm not usually very worried about the whole featured article thing, I have seen cases where a nomination does not pass simply because the list of prerequisites was not clear, either because the nominator believed the article was ready when it was not or because the opposition believed the article wasn't ready, even though it may have been. There it is. That phrase. May have been. The current policy is so vague that it doesn't answer users' question about what an article should look like and leaves them thinking "Well, I guess it could be ready. Maybe, maybe not." You shouldn't have to actually nominate an article to find out if it's ready, the policy should tell you all that. Frankly, I'm surprised it's stayed as long it has. No question, that whole section needs a rethink. Per all.
 * 3) Per all.
 * 4) Per all.
 * 5) Per all.
 * 6) Per all, though I feel the first sentence of the "Be sourced with all available Mario-related appearances." section should say "All appearances of the subject need to be present in the article."
 * 1) Per all, though I feel the first sentence of the "Be sourced with all available Mario-related appearances." section should say "All appearances of the subject need to be present in the article."

Comments
Shouldn't there be a draft of this beforehand? Rule #11 especially comes to mind: "An article must be of reasonable length and not be marked as a stub." At first glance, it's hard to know where to start. Only if we put a little more thought into the actual content (such as adding information on how certain sections should be formatted, and not to mention between certain types of subjects) would this proposal actually be clear-cut and easier to implement. (Not that this will cause me to cast a conditional oppose vote, just making sure .) 15:41, 1 February 2018 (EST)
 * Never mind, didn't see the subpage. I'm apparently a little hasty. 15:42, 1 February 2018 (EST)

For the sake of proper grammar, can you change "An article must be..." to "An article must..."? It just bugs me to see "be...be" or "be...not be". - 21:49, 1 February 2018 (EST)
 * Noted. 17:15, 2 February 2018 (EST)

New features
None at the moment.

Removals
None at the moment.

Manually manage Featured Article nominations
For some years, I personally had a problem with how Featured Articles nominations, both active and archived nominations are handled, especially at Featured Articles. We currently just link to an archive via categories when I think it's a very messy, cumbersome, and frankly lazy way to do this. No other processes in the wiki let categories organize and link to their pages; the equivalent is letting categories organize implemented proposals and nothing else. What's especially bad for the category system is that unregistered users mostly cannot even see the active nominations in the category page, as it often requires a manual refreshment of the browser cache to see the active links. I propose to organize the following processes:

I would like to implement a sortable wikitable in the Nominated articles/lists and FAs proposed for unfeaturing header. This table is something we would manually have to update ourselves, which shouldn't be a problem with our active editor community and some effort for some oversight. The table would list a link to the active Featured Article/Unfeature nomination, piped with the article name, the time it was nominated, the deadline, and the time it was passed in. If there exist no parameters, the table would be left blank, filled with a ---. We add cells as nominations go up, and delete cells when nominations pass/fail, and the minimum amount of cells is one row with dashes if there are no active nominations at the time.
 * Active Featured Article nominations

The headers regarding the archives at Featured Articles would be reorganized under a big header, Archives, with two smaller headers: Feature nominations and Unfeature nominations. Both failed and successful archives would therefore be merged together. These archives would also be handled through a sortable table format that we have to manually update, but again, this isn't any skin off our nose, as we can easily archive and document past proposals. The table format cells would use a color system similar to how we archive MarioWiki:Proposals, with a color denoting how the process goes: passed, failed, passed at the time but unfeatured today, and failed at the time but passed today. The cells would link to the archive of the Featured Article with a piped name for the name of the article, which user nominated the article, the time it was nominated, what number of nominations it has (N1, N2, etc.), and the time the nomination passed/failed.
 * Featured Articles archives

If you want a more visual picture of how I want things to be organized at Featured Articles, you can check out my sandbox below. Any refinements, suggestions for improvements, or any correction of possible errors are encouraged and should be noted in the comments section.
 * References


 * User:Baby Luigi/Featured Articles

I hope this proposal would smoothen and refine the process of Featured Article nominations and make it easier for the end user to access past featured article nominations as well as guide them around links easier as they explore our Featured Article pages.

Proposer:, giving huge special thanks to for a lot of effort helping me develop my sandbox page. Deadline: February 8, 2018, 23:59 GMT

Support

 * 1) Per proposal.
 * 2) Per proposal. This is something I wanted to see implemented for a long time, so I specially logged in to vote. Please, be sure to add the first nomination of DKCTF to the list ;)
 * 3) Per proposal. This is a much nicer and well organised method than before.
 * 4) Aside from still needing to create templates specifically for the sake of archiving, it's a workable system that helps organize any FA nomination of any kind. Plus, we use the same colors for the proposal archives, which makes it even easier to find articles specifically for that purpose. I simply cannot agree enough with the proposed action, and would like to give my thanks to Baby Luigi for allowing me to co-contribute to and expand upon her proposed system. All in all, per proposal.
 * 5) Per all.
 * 6) Per all.
 * 7) Per all.
 * 1) Per all.

Comments
@Super Radio: Yeah, blah, I knew I probably left something out. Thanks for the correction! 15:05, 1 February 2018 (EST)

This likely isn't practical, but for the sortable tables, would it be possible to have the status column sort by colour or by day, rather than the time at the front? 17:22, 1 February 2018 (EST)
 * If you were to sort by color, what would you choose? 17:16, 2 February 2018 (EST)
 * I meant more the colors that were already present, i.e. all the the green ones would be stacked next to each other and so on. 17:29, 2 February 2018 (EST)
 * I think it's a good idea, but I don't know how it would be implemented. 21:47, 2 February 2018 (EST)

How to order navigation templates
Following the proprietor's veto of the previous proposal, this proposal will determine how our articles' navigation templates should be ordered using the plan that he laid out. Steve's option involves ordering the templates alphabetically, except series are compiled together and ordered chronologically; see this (the one labeled option 5) for a visual example of this. You're free to look at the previous proposal for exactly why the templates' order should be changed, but to put it simply, the current purely-chronological ordering helps nobody. With this in mind, this proposal only has two choices, per the proprietor's request: either Steve's option (i.e. supporting the proposal), or do nothing (i.e. opposing it).

I'm still adamant about some change being necessary, but the choice is up to you.

Proposer: Deadline: February 18, 2018, 23:59 GMT

Support

 * 1) Per proposal.

Oppose

 * 1) While Porplemontage's option seems like a workable solution, there are still many, many things that need to be fixed before it can be properly implemented. First of all, series ambiguity still has not technically been resolved. (And how do we even consensually order miscellaneous games that don't necessarily fit into one series? Some readers might consider Super Mario Maker to be grouped with Mario Paint, since the two are similar in theme.) Second, how can we be certain that all readers will understand an alphabetical setup of templates in the exact same way? (Some may consider Mario's Early Years! to come before Mario Clash, for example.) Lastly, even if series is the most recognizable format, structuring it like this leads to unnecessary  and in turn may lead to needless conflicts between users, whereas the current format is clear-cut and well-defined, and as described here, the coloration does much of the real work. In short: while it's a good idea in theory, the proposed system needs lots of work before it can be put into practice.
 * 2) Don't get me wrong, it's a great idea.  But it has problems too.  Per Toadette, in addition to the fact that the proposed option groups colors.  If we group colors, why have them at all?

Comments
I'm not sure how "series ambiguity" is an issue when we already have series pages that clearly document what goes where. We can't be expected to reasonably account for every potential assumption from the readers. I'd also say that it's much more of an assumption on our part that our readers are so familiar with the chronology of every game that they can easily navigate such a list. 01:16, 4 February 2018 (EST)

Removing bolded text from image captions
The names of articles are bolded in their intros to draw attention to the beginning of the text; everything starts here, to put it simply. With that in mind, why are page names also bolded within image captions at the beginning of the article? It's certainly not an official rule: the Manual of Style just mentions bolding the name in the intro and not including a period in image captions if they don't form a complete sentence. Even if it's just a piece of tradition that's become widely used, there's no reason we should do it. The readers' eyes shouldn't be drawn to the image caption as if it's the same as the intro text: after all, one signifies the beginning of the actual information, whereas the other is a short description of what's literally happening in the image. It's redundant, to say the least, especially if the page has an infobox that already repeats the article's name at least a couple of times. It's redundant, to say the least. It's not as if any actual information is gained by bolding the text, it only serves to distract readers with nothing gained in return. So, why do we do this?

There's no practical reason that page names in image captions should be bolded; therefore, I propose that they should be removed.

Proposer: Deadline: February 18, 2018, 23:59 GMT

Support

 * 1) Per proposal.
 * 2) Doesn't seem particularly useful, per proposal.
 * 3) Per proposal.
 * 4) Per proposal.
 * 5) } Per proposal.