MarioWiki:Proposals

Writing guidelines
None at the moment.

Create a template for proposer and deadline parameters
Yet another measure intended to improve how proposals are added to pages. You can find the details here. Basically, my proposal is that we change the parameters for the "Proposer:" and "Deadline:" parameters from hardcoding into a template. This will also (quite obviously) mean that previous archives must be temporarily unprotected to enforce these changes. Proposals like these have received near-unanimous support in the past; we have all of these, to name a few, so how does this fare?

Proposer: Deadline: November 14, 2017, 23:59 GMT

Support

 * 1) Per proposal.

Oppose

 * 1) Why? This just seems like it unnecessarily complicates the whole process. It's perfectly readable as-is and doesn't take up a notable amount of space.
 * 2) - Per Time Turner. This seems to be trying to solve a problem that doesn't exist.
 * 3) Templates are annoying to use as-is, and what I saw when I viewed the source of that example didn't make me particularly welcoming of this idea. It's just easier to do it the way we've been doing it.
 * 4) Per all. I don't see how this makes things any easier.

Comments
@MrConcreteDonkey: The problem is that I have seen countless poorly formatted proposer/deadline parameters. 17:30, 7 November 2017 (EST)
 * I haven't noticed anything like that, and even still it's much less hassle to just fix them separately, rather than editing every proposal in every archive. 17:39, 7 November 2017 (EST)
 * Your argument is still flawed; all of these, to name a few. 17:52, 7 November 2017 (EST)
 * But this doesn't make things any more convenient, and it doesn't provide any added insight for future readers. How is this better than manually inputting it? 18:24, 7 November 2017 (EST)
 * It's been fixed. 18:44, 7 November 2017 (EST)
 * It has not. Doc von Schmeltwick (talk) 18:53, 7 November 2017 (EST)
 * You've only added the list from your most recent comment to the proposal, and haven't addressed our concerns. How is introducing more complicated formatting going to combat poor formatting? 19:46, 7 November 2017 (EST)

Removals
None at the moment.

Make "Bestiary" its own namespace
Sure, we have a namespace for galleries, but I don't see why we can't do the same for bestiaries. It's the same kind of "special" article that I would define galleries as as well. Therefore, I propose that we rename every instance of  to.

Proposer: Deadline: October 26, 2017, 23:59 GMT Extended to November 2, 2017, 23:59 GMT Extended to November 9, 2017, 23:59 GMT

Support

 * 1) Per proposal.
 * 2) Per proposal.
 * 3) Per proposal.
 * 4) Per proposal.  Why not?
 * 5) This is (similar to?) one of the things Zeldawiki does that I think we should too.
 * 6) Per all.
 * 7) Per all.
 * 8) Switch sides again, Per Toadette's comment.
 * 9) - Just because we've got fewer bestiaries than galleries doesn't really give much an excuse. This helps keep the wiki more organized than it would be, and that's more than a good enough reason IMO.

Oppose

 * 1) - For galleries it made sense because most major articles had one (there are currently 319); for bestiaries, I don't see the point at all. There are 12 proper bestiaries, I don't think this warrants a namespace by any means.
 * 2) Per Tucayo. I also don't see the benefit of this; it seems like more hassle then it's worth for little payoff when considering the few bestiaries on the page.
 * 3) Per Tucayo.
 * 4) - Originally supported, but considering the number of bestiaries there are, per Tucayo.
 * 5) I don't think we have enough pages of this thing to make it into a separate namespace. Per all.
 * 6) Per my comment below and Tucayo.
 * 7) Per all. I see what's trying to be done here, but it seems overly fiddly considering what is being effected, making this extra work for little reward.
 * 8) Per all.
 * 9) Really?! Per all.
 * 10) - Per all. At least for now I don't see why this is needed.
 * 11) Per all.

Comments

 * I might just be a bit dumb, but I don't fully understand what this means or what the difference is. Could you give an example?-- 12:15, 20 October 2017 (EDT)
 * For example, Mario & Luigi: Superstar Saga bestiary would become if this were to pass. -- 12:18, 20 October 2017 (EDT)
 * I can only see one problem with this. On every enemy page where the enemy template is placed, transcluding its info from the bestiary page, they look like this:
 * The bolded part is where we're going to get into some issues. It'll be a simple fix, but we'd have to change the link for EVERY page with an enemy template.-- 12:54, 20 October 2017 (EDT)
 * Sounds like bot work. 12:56, 20 October 2017 (EDT)
 * The bolded part is where we're going to get into some issues. It'll be a simple fix, but we'd have to change the link for EVERY page with an enemy template.-- 12:54, 20 October 2017 (EDT)
 * Sounds like bot work. 12:56, 20 October 2017 (EDT)


 * Could we keep the current names as redirects until all of the transclusions are fixed?
 * 14:05, 20 October 2017 (EDT)
 * @Ultimate Mr. L: Isn't that a standard measure? @Alex95: That was my exact plan for fixing those pages. 17:37, 20 October 2017 (EDT)

@Tucayo: "There's too little" is not an argument in and of itself. It's so that normal readers don't get confused into thinking it's an actual article. 18:00, 23 October 2017 (EDT)
 * They are articles, though?? What makes them any different from quote pages, lists of badges, recipes, assist trophies, etc.? Bold + italics doesn't make it true. -- 22:01, 23 October 2017 (EDT)
 * Those are actual list articles. Bestiaries are not technically list articles; they are rather pages that are there to have individual sections be transcluded onto actual articles. 22:07, 23 October 2017 (EDT)
 * But they are still articles by themselves. I truly fail to see the point here. -- 22:09, 23 October 2017 (EDT)
 * Again, why do you think that they're actual articles? They are not meant to be. 08:25, 24 October 2017 (EDT)

If we gonna have them as separate namespaces I honestly think the category should expand to all list articles since they are the very similar to bestiaries. I honestly think having a separate namespace for just 12 pages for something very specific is inconsistent and unprofessional.
 * @NSY: Again, bestiaries ARE NOT technically list articles; they are relevant sections of a page transcluded onto other articles, and having too few does not make too much of a difference. Also, could you please elaborate on the "inconsistency" argument? I understand it less so than Tucayo's arguments. 15:10, 24 October 2017 (EDT)
 * Well according to dictionary.com a list is defined as "a series of names or other items written or printed together in a meaningful grouping or sequence so as to constitute a record". Pretty certain an article that has a record of every enemy and their stats falls under that. It's inconsistent because these would the only list articles that got their own namespace, what about the articles listing all the mini games in a Mario Party game, would they also get their own namespace.
 * No, because that's an actual list:
 * Balloon Burst
 * Bombs Away
 * Crazy Cutter
 * Where as the bestiaries are tables:
 * {| class="wikitable"

! Name !! Location !! HP !! Items
 * Bowser || Castle || 100 || Key
 * Goomba || Plains || 3 || Mushroom
 * Koopa Troopa || Mountains || 12 ||N/A
 * }
 * We don't list out the enemies on a bestiary like we do for every single list on this site. The lists are spilt up into categories, like the Species list, and they only have a name that links to it's main article, ONLY. Nothing else about that link exists on the page.-- 17:32, 26 October 2017 (EDT)
 * However, there are some "list" articles such as List of enemy formations in Paper Mario that are tables, so the lists are not always simply just a name that links to its main article. I agree that bestiaries are like list articles. -- 17:36, 26 October 2017 (EDT)
 * Didn't know that existed. Is that article necessary? If so, seems like that should be integrated into the Paper Mario bestiary.-- 17:40, 26 October 2017 (EDT)
 * I feel that there is enough information for it to remain separate (a proposal to merge it could be created though). Even if that and the Thousand-Year Door version were merged with their bestiaries, there are still other list articles that are more than just simply names (see Category:Lists for more examples). -- 17:55, 26 October 2017 (EDT)
 * There is also List of Sammer Guys. The only reason why it is kept separate from Super Paper Mario bestiary is that it is a list of Sammer Guys fought in an optional thing (though the first 20 are required) and they are too similar to each other. As for another this bestiaries are, they are compendiums which is "a collection of concise but detailed information about a particular subject, especially in a book or other publication (not really relevant to these bestiaries, but I am quoting this word for word)" -- definition found by searching compendiums on Bing. The list of enemy formations and others listed here may be the only exceptions, though.
 * Didn't know that existed. Is that article necessary? If so, seems like that should be integrated into the Paper Mario bestiary.-- 17:40, 26 October 2017 (EDT)
 * I feel that there is enough information for it to remain separate (a proposal to merge it could be created though). Even if that and the Thousand-Year Door version were merged with their bestiaries, there are still other list articles that are more than just simply names (see Category:Lists for more examples). -- 17:55, 26 October 2017 (EDT)
 * There is also List of Sammer Guys. The only reason why it is kept separate from Super Paper Mario bestiary is that it is a list of Sammer Guys fought in an optional thing (though the first 20 are required) and they are too similar to each other. As for another this bestiaries are, they are compendiums which is "a collection of concise but detailed information about a particular subject, especially in a book or other publication (not really relevant to these bestiaries, but I am quoting this word for word)" -- definition found by searching compendiums on Bing. The list of enemy formations and others listed here may be the only exceptions, though.

Okay, this just doesn't make any sense at all. How and why in the world would we make this thing its own namespace if there are only twelve of it on the market right now? I don't get it. 17:49, 27 October 2017 (EDT)
 * Because it's not really an article. Its main purpose is infoboxes to transclude onto articles. Because it is more than just an article, I feel it warrants its own namespace. It doesn't matter how few of them there are.
 * 19:48, 28 October 2017 (EDT)
 * But why does it need a separate namespace to exemplify that fact? 20:00, 28 October 2017 (EDT)
 * Are you suggesting that the Template namspace might be the ideal home for them? (Yeah, it just now occurred to me.) 13:25, 29 October 2017 (EDT)
 * ...No? 00:11, 30 October 2017 (EDT)

Use Lists for the Power Moons instead of Galleries
Porplemontage has indicated that for the Power Moons on the Kingdoms pages, we should use a GALLERY of images relating to the position of the moon, along with the name that links to either a TABLE, or to individual articles, which another proposal will be dealing with. I firmly believe we should use a LIST instead of these galleries, and here's why:
 * Easier to scroll through on mobile devices and desktop.
 * Far less vertical space take up on the page, especially with kingdoms with 50-100 moons.
 * On mobile the entire gallery is one column.
 * The human eye only needs to move up and down the list
 * The galleries require looking all over the screen and can disorient.
 * Many readers will come for help with finding power moons. The list tells them the name and a short description, and if they need more they click the link for the full thing.
 * The galleries have no way of giving a short description about the moon, and can lead readers to jumping all over the site if they are obtaining info moon by moon.
 * Having a single page open and being able to look back at it when needed is a huge help and time saver.

Proposer: Deadline: November 10, 2017, 23:59 GMT

Support

 * 1) per my proposal

Oppose

 * 1) See my comments.
 * 2) Having a redundant list on the main body article of, say, Cascade Kingdom is pointless (when things are more easily summed up with Header+Main template+Small paragraph explaining the moon count and other criteria) and unnecessary padding to the article when the information users are looking for is best explained in the list pages itself. The reason we even resorted to using tables in the first place is because some of the moons objectives are short enough to fit in there; we don't need a summary of a summary. Keep the listicle in the actual list article itself, and leave the worse, less useful, less informative list out of the main one. Another point I like to add is that the list also adds a ridiculous amount of redundant links that ALL lead to the main article: we need only one link and that's where the Main template comes in handy. If people REALLY wanted to search for a specific moon, that's why we have Ctrl + F in the first place. My position is to delete the small listings altogether and leave only a header + main template + small paragraph.
 * 3) Switch sides again, per Baby Luigi's comment.

Comments
The purpose of this is to determine which way is better for displaying the moons on the kingdom page. Whether they link to a table or article, there will be far more information on the linked page, including the images AND an in-depth description/walkthrough type thing for the power moon. The list will just take up far less space and provide an easy overview for readers.-- 15:33, 3 November 2017 (EDT)

I was going through your arguments, and decided to put my thoughts to them. Overall, I am not for having them as lists due reasons above. 15:49, 3 November 2017 (EDT)
 * Easier to scroll through on mobile devices and desktop.
 * Not by very much. And if you think about the about of time a section loads (at least on a 3DS (I having the 2DS)), not going to be much difference anyway. Galleries on mobile devices like Nintendo 3DS family in general take long to load, but they usually remain black if there is too many.
 * Far less vertical space take up on the page, especially with kingdoms with 50-100 moons.
 * I compared your mockup on Metro Kingdom layout (81 moons), and your talking about a whole length of the scroll bar on those pages, which is not a lot.
 * On mobile the entire gallery is one column.
 * On which mobile? I use a 2DS, and I don't remember seeing only 1. But that may be due to me using desktop on my 2DS. But, I checked on a desktop mobile view and I only saw one less image per column than in desktop.
 * The human eye only needs to move up and down the list
 * I hear that humans like looking at better looking things. But, it is also something to not overdue.
 * The galleries require looking all over the screen and can disorient.
 * There is still order in galleries. One can easily look at the system and find the one they are looking for.
 * Many readers will come for help with finding power moons. The list tells them the name and a short description, and if they need more they click the link for the full thing.
 * Actually, it's a little quicker finding the moon with a gallery than a list. With a list, readers are going to go to the general area and find it. With galleries, they do the exact same thing. The only difference is that it is found quicker due to there being length. Even in a 1 per column, there are less of the others when this option is done per screen.
 * The galleries have no way of giving a short description about the moon, and can lead readers to jumping all over the site if they are obtaining info moon by moon.
 * Just the moon names may be all they are looking for. I don't know how Talkatoo works exactly due to not having the game. Even still, we should provide the info. But, if they're not looking for the name, they will most likely not go to the kingdom page, no matter if the moons stay in another article or if they all become separated, but instead use the search bar to do it.
 * Having a single page open and being able to look back at it when needed is a huge help and time saver.
 * We already have another page for that. It can even be convinced to keep it even if all are given articles.
 * When I refer to mobile, I am talking about phones. If you're playing the game, it's less likely you have a computer/laptop open next to you looking at the wiki, and more likely you are on a phone. Talkatoo works by only revealing the name of the power moon, not the location, and he only gives you three at a time. If you only want the names to figure it out for yourself, you're fresh out of look with the galleries because you can't avoid seeing the picture. With list it's easier to not read the description. The list is also better suited as it's the exact same way the game itself displays the power moons, as a big numbered list with the names and a minimap to the side with icons indicating the positon on the map of each moon.-- 15:58, 3 November 2017 (EDT)
 * Oh, a phone. But, not everyone has a phone with the ability to look up stuff. You mention that it is hard not to see the image if it is galleries. There are times when galleries don't actually show the picture, but this seems to only happen if there's either low-broadband or takes a long time to load in general. And even if there is a picture, that picture can help them find the moon, but only if the person looking at the picture can tell where it is. They say a picture is worth a thousand words. Compared to descriptions, I have no idea. As for the last point, I don't know how to say something against it and still be in legal grounds. What I do know is that in-game, it shows a picture of the location if you found it. Is there a way to replicate that on the wiki? Or would that be too much? (both questions are only relevant if this passes.) (Scratch that point. I don't think there is especially for long lists. And it would be too much if we found a way to do it.) As of right now, the gallery seem to do the same thing, except in a different way. 16:20, 3 November 2017 (EDT)
 * I mentioned the use of a map to Steve but I didn't really understand his response so I didn't pursue it. Now, be reasonable, you're not looking up the power moons for Super Mario Odyssey if you don't have a switch or plan to get one, that information is useless, and if you have that kind of money, you have a smart phone, even if it's low end. A smart phone is a necessity for life at this point, not because of addiction or obsession, but because of work and family, especially work! Anyways, you would want to avoid the picture because the moment you see it, you'd recognize where that is, and you lose all the fun of working out where it is based on the name. I know we don't worry about spoiler's here, but it makes for a better presentation for people who need some help but don't want to be outright told where it is, and for those that do, we have that information too. Also keep in mind that there are 103 moons for Mushroom Kingdom, a page that has existed on the wiki since 2011 and serves a purpose for multiple games in the franchise. It would be completely overrun if the gallery were applied to it.-- 16:35, 3 November 2017 (EDT)
 * Galleries have visual aspects. This means that people generally find them more attracted. Lists usually have things pretty close to each other. The rest Porplemontage said for me. As for the last point, Mushroom Kingdom doesn't have either. But, it doesn't have a gallery either. But, if you're still not convinced, Porplemontage also mentions that have lists for longer articles. With this proposal, it removes the possibilities of galleries instead of list no matter what, even on shorter articles. 17:00, 3 November 2017 (EDT)
 * That's not how this works. This proposal is only for the power moon lists/galleries on the kingdom pages. The ruling wouldn't effect other situations.-- 17:02, 3 November 2017 (EDT)
 * That's your argument against what I put? Something I already know? If this passes, is guarantees lists for those articles. Since it is support or oppose, the oppose option doesn't necessary mean that we will stick with galleries for all of the articles that are going to be affected. It means that we won't stick with the lists for all of the articles that are going to be affected.
 * As for the point that I didn't cover in my previous comment, you explained it almost exactly as it is, but sometimes standards aren't always what some people do. But, it's hard to know due to preferences of others. So, generally speaking suits well. 17:21, 3 November 2017 (EDT)
 * I misunderstood what you meant. It sounded like you were suggesting that every article would have galleries replaced with lists, not just the kingdoms. My mistake.-- 17:27, 3 November 2017 (EDT)

Why is there no "use tables" option in this proposal? That's the option I'd want to vote for. 13:29, 6 November 2017 (EST)
 * Because they take up far too much space, even more than the galleries would, and are really not mobile friendly at all. Plus, three pages currently already link to a separate page when a table exists. Another proposal will be made soon to figure out how to handle articles for power moons, and I believe the default option is to link to a table.-- 14:23, 6 November 2017 (EST)
 * After looking through this again and understanding where you're going with this, why do we even need a redundant list in the main body Cascade Kingdom article itself? Just delete the list and let the List of Cascade Kingdom Moon article handle all of the work of describing the details of each Power Moon. 14:42, 6 November 2017 (EST)
 * Because we have to wait for the other proposal to go through first. We don't know if the List of Cascade Kingdom Moon article will stay or not. If the decision is to make an article for every power moon, which I now support, then that page will be deleted. The list on the kingdom page itself will not have an in-depth description of the moons, keeping it simple, because the in-depth part will be on the individual pages.-- 15:03, 6 November 2017 (EST)
 * Shouldn't you wait for the proposal to go through before starting another proposal about this matter first? Also, I still don't think a summary is necessary, considering some moons can be explained in only a few sentences, which is why we're even using the table format in the first place rather than giving them separate articles. 19:55, 6 November 2017 (EST)

One thing that confuses me: the way this proposal is worded doesn't say whether the gallery/list is its own page or part of the main page, but the way you were talking would imply that a gallery would have to be separate while a list would have to be part of the main article, which isn't true at all. Doc von Schmeltwick (talk) 17:12, 7 November 2017 (EST)

Make indenting comments during discussions an official rule
You know, when I was just discussing with my good friend Black Lightning when he reminded me to indent my comments, he told me that indenting comments during discussions was an unwritten rule that the wiki abided by. I started to think, why not make this an official rule? So that's the point of this proposal, why not make indenting comments during talk page discussions an official rule? The rule will state that all participants in a talk-page discussion must indent their comments, but after around five to seven colons have been used to indent comments, the bar will reset to zero, and the cycle goes on and on until the discussion ends. This would be a great rule to increase the efficiency and effectiveness of all talk-page discussions. However, unlike most rules, there will be no punishment for violating this rule, as it's more of an official guideline than an official rule, although very occasional reminders will be given. The official rule part is to make it so that all autoconfirmed users do it regularly and get in the habit of indenting their comments early on in their work on the wiki. Proposer: Deadline: November 11, 2017, 23:59 GMT

Support

 * 1) I'm sticking with my proposal.

Oppose

 * 1) 1) I strongly disagree with the cycle resetting to zero. It would be better if it just stopped and stayed at seven. 2) It wouldn't really increase the efficiency of talk pages since pretty much everybody follows it anyway. You can't solve a problem that isn't there. If it ain't broke, don't fix it. 3) "Good friend" is really stretching it. "Acquaintance" maybe. Nothing personal, but, as my page says, I don't do internet friends.
 * 2) No. This type of rule works best as a guideline rather than something users can get reminders and warnings for, and I think this veers almost on common sense at this point. To be frank, this isn't something major enough to be addressed, and as Ultimate Mr. L said, most people already abide by it anyway, so there's no point in making this a rule.
 * 3) Per all.
 * 4) - Per all. In most instances it's just common sense, and making not following it punishable with a reminder/warning does not sound like a good idea.
 * 5) - Just indent your discussions like people have been telling you. No need to shoot your foot off.

Comments
THANK YOU! It FINALLY did what I wanted it to do, which is show up as a black header and not a bunch of code. Anyway, you don't need to apologize, Black Lightning. We've all got our opinions, and no one can take them away from us, even if their life depended on it. In the end, that's all that matters. And by the way, I meant "good friend" as in quite literally, "good friend". I didn't mean to use the specific Internet term. 22:56, 4 November 2017 (EDT)
 * Not sure what's with that glitch, it seems to happen every other time a new proposal is made. Encountered it at my first proposal and its shown up form time to time ever since. It fixes itself as long as there some code under the section. As for the friend thing, I mean I haven't met you face-to-face and therefore do not consider you a friend. But this really isn't the place for this conversation.
 * 23:00, 4 November 2017 (EDT)

Help:List <- Closest thing to a written "rule" I can find. 22:04, 5 November 2017 (EST)
 * By the way, I should point out that while not indenting comments is not currently a warnable offense, it is equally minor as forgetting italics, which is as it is detailed on this user's talk page. Drawing from that user's example, if not indenting comments were to become a warnable offense at all, it should only get serious after the user in question is reminded about it more than ten or so times. 16:28, 7 November 2017 (EST)
 * The difference is, I think user space dealing with formatting are lot more lenient on formatting than writing formatting stuff on actual articles. For example, we encourage people to not copy paste raw signature coding all over the people's talk pages whenever they sign, but that rule is not enforced all that often...indenting is even more minor than that, I say. 21:26, 7 November 2017 (EST)
 * @Toadette the Achiever Non-italicizing is something that shows up on articles random people read, while indenting is a talk page thing. I'm not sure how I can explain it any better.
 * 21:44, 7 November 2017 (EST)

Oh, come on, can I ever get any proposal I make to get off the ground and start running? I always seem to epically fail with every proposal I make. Anyway, don't mind me here, I'm just being good old me. 21:45, 7 November 2017 (EST)
 * Complaining isn't going to help you, if anything it will make you look bad. Sometimes proposals just don't go in your favor. One of the points of a proposal is to see what others think, and this is what they think. 21:47, 7 November 2017 (EST)
 * Proposals pass if they are well-thought out and have a decent point to make. Most of the ones you proposed are usually neither. 22:42, 7 November 2017 (EST)
 * I admit that it's difficult to come up with good proposals every now and then, and let's be honest, it's ESPECIALLY difficult to come up with flaws and counterarguments that could be presented to the proposer when they already made their proposal. Just take the commentary as advice, and it'll flow smoothly. 23:25, 7 November 2017 (EST)
 * Well, that's why I usually discuss things in forums or in Discord chat before I enact anything major. 23:28, 7 November 2017 (EST)