MarioWiki:Proposals: Difference between revisions

From the Super Mario Wiki, the Mario encyclopedia
Jump to navigationJump to search
m (→‎Support: Fucking shit.)
 
Line 1: Line 1:
<center>[[File:Proposals.png]]</center>
{{/Header}}
<br clear=all>
{| align="center" style="width: 85%; background-color: #f1f1de; border: 2px solid #996; padding: 5px; color:black"
|'''Proposals''' can be new features (such as an extension), removal of a previously added feature that has tired out, or new policies that must be approved via [[Wikipedia:Wikipedia:Consensus|consensus]] before any action(s) are done.
*Any user can support or oppose, but must have a strong reason for doing so, not, e.g., "I like this idea!"
*"Vote" periods last for one week.
*All past proposals are [[/Archive|archived]].
|}
A proposal section works like a discussion page: comments are brought up and replied to using indents (colons, such as : or ::::) and all edits are signed using the code <nowiki>{{User|</nowiki>''User name''<nowiki>}}</nowiki>.


This page observes the [[MarioWiki:No-Signature Policy|No-Signature Policy]].
==Writing guidelines==
''None at the moment.''


<h2 style="color:black">How To</h2>
==New features==
#If users have an idea about improving the wiki or managing its community, but feel that they need community approval before acting upon that idea, they may make a proposal about it. They must have a strong argument supporting their idea and be willing to discuss it in detail with the other users, who will then vote about whether or not they think the idea should be used. Proposals should include links to all relevant pages and [[MarioWiki:Writing Guideline|Writing Guideline]] proposals ''must'' include a link to the draft page.
===Create a template to direct the user to a game section on the corresponding List of profiles and statistics page===
#Proposals end at the end of the day (23:59) one week after voting starts, except for Writing Guidelines and Talk Page Proposals, which run for two weeks. ('''All times GMT.''')
This proposal aims to create a template that directs people to a game section on a Profiles and statistics list page, saving the user the step of having to scroll for it themselves. The reason why I'm proposing this is because as more ''Super Mario'' games are released, it becomes harder to comfortably find what you're searching for in the corresponding List of profiles and statistics page, especially for [[Mario]], [[Bowser]], and many other recurring subjects.
#*For example, if a proposal is added at any time on Monday, August 1, 2011, the voting starts immediately and the deadline is one week later on Monday, August 8, at 23:59 GMT.
#Every vote should have a reason accompanying it. Agreeing with or seconding a previously mentioned reason given by another user is accepted.
#Users who feel that certain votes were cast in bad faith or which truly have no merit can address the votes in the Comments section. Users can ask a voter to clarify their position, point out mistakes or flaws in their arguments, or call for the outright removal of the vote if it lacks sufficient reasoning. Users may '''not''' remove or alter the content of anyone else's votes. Voters can remove or rewrite their own vote at any time, but the final decision to remove another user's vote lies solely with the [[MarioWiki:Administrators|administrators]].
#If a user makes a vote and is subsequently blocked for any amount of time, their vote is removed. However, if the block ends before the proposal ends, then the user in question holds the right to re-cast their vote.
#No proposal can overturn the decision of a previous proposal that is less than '''4 weeks''' ('''28 days''') old.
#Any proposal that has three votes or less at deadline will automatically be listed as "[[Wikipedia:Quorum|NO QUORUM]]." The original proposer then has the option to relist said proposal to generate more discussion.
#All proposals that end up in a tie will be extended for another week.
#If a proposal has more than ten votes, it can only pass or fail by a margin of '''three''' votes. If a proposal reaches the deadline and the total number of votes for each option differ by two or less votes, the deadline will be extended for another week.
#Proposals can only be extended up to three times. If a consensus has not been reached by the fourth deadline, the proposal fails and can only be re-proposed after four weeks, at the earliest.
#All proposals are archived. The original proposer must '''''take action''''' accordingly if the outcome of the proposal dictates it. If it requires the help of an administrator, the proposer can ask for that help.
#Proposals can only be rewritten or deleted by their proposer within the first three days of their creation. However, proposers can request that their proposal be deleted by an [[MarioWiki:Administrators|administrator]] at any time, provided they have a valid reason for it. Please note that cancelled proposals must also be archived.
#If the administrators deem a proposal unnecessary or potentially detrimental to the upkeep of the Super Mario Wiki, they have the right to remove it at any time.
#There should not be proposals about creating articles on an underrepresented or completely absent subject, unless there is major disagreement about whether the content should be included. To organize efforts about completing articles on missing subjects, try creating a [[MarioWiki:PipeProject|PipeProject]].
#Proposals cannot be made about promotions and demotions. Users can only be promoted and demoted by the will of the [[MarioWiki:Administrators|administration]].
#No joke proposals. Proposals are serious wiki matters and should be handled professionally. Joke proposals will be deleted on sight.


<h3 style="color:black">Basic Proposal and Support/Oppose Format</h3>
Another reason I think this would be valid is because of the fact that listing statistics in prose (e.g. 2/10 or 2 out of 10) looks off, especially if that can already be seen in the corresponding statistics box; in that case, the prose could change from "2/10" to something more vague like "very low stat", which isn't typically worded as such in the statistics box.
This is an example of what your proposal should look like, if you want it to be acknowledged. If you are inexperienced or unsure how to set up this format, simply copy the following and paste it into the fitting section. Then replace the [subject] - variables with information to customize your proposal, so it says what you wish. If you insert the information, be sure to <u>replace the whole variable including the squared brackets</u>, so "[insert info here]" becomes "This is the inserted information", not "[This is the inserted information]".
-----
<nowiki>===[insert a title for your Proposal here]===</nowiki><br>
<nowiki>[describe what issue this Proposal is about and what changes you think should be made to improve how the Wiki handles that issue]</nowiki>


<nowiki>'''Proposer''': {{User|[enter your username here]}}<br></nowiki><br>
For example, let's say for [[Luigi]] in his appearance in ''[[Mario Sports Superstars]]'', there could be a disclaimer either below the section heading or in a box to the side (we can decide the specifics when the proposal passes) that informs the reader that there's corresponding section that shows his profiles/statistics corresponding. Like such:
<nowiki>'''Deadline''': [insert a deadline here, 7 days after the proposal was created, at 23:59 GMT.]</nowiki>


<nowiki>====Support====</nowiki><br>
:''For profiles and statistics of Luigi in Mario Sports Superstars, see [[List of Luigi profiles and statistics#Mario Sports Superstars|here]].''
<nowiki>#{{User|[enter your username here]}} [make a statement indicating that you support your proposal]</nowiki>


<nowiki>====Oppose====</nowiki>
The above message is not necessarily the final result (just a given example), but the disclaimer would definitely point the user to the appropriate game section on the profiles and statistics list page, should this pass.


<nowiki>====Comments====</nowiki>
'''Proposer''': {{User|Super Mario RPG}}<br>
-----
'''Deadline''': January 1, 2025, 23:59 GMT
Users will now be able to vote on your Proposal, until the set deadline is reached. Remember, you are a user as well, so you can vote on your own Proposal just like the others.


To support, or oppose, just insert "<nowiki>#{{User|[add your username here]}}</nowiki> at the bottom of the section of your choice. Just don't forget to add a valid reason for your vote behind that tag if you are voting on another user's Proposal. If you are voting on your own Proposal, you can just say "Per my Proposal".
====Support====
 
#{{User|Super Mario RPG}} Per.
__TOC__<!--
#{{User|Hewer}} I don't really see a need to deliberately make prose less specific, but otherwise I like this idea, per proposal.
 
<center><span style="font-size:200%">CURRENTLY: '''{{#time: H:i, d M Y}} (GMT)'''</span></center>


<br>
-->
<h2 style="color:black">Talk Page Proposals</h2>
All proposals dealing with a single article or a specific group of articles are held on the talk page of one of the articles in question. Proposals dealing with massive amounts of splits, merges or deletions across the Wiki should still be held on this page.
:''For a list of all settled Talk Page Proposals, see [[:Category:Settled Talk Page Proposals|here]].''
<h3 style="color:black">How To</h3>
#All active talk page proposals must be listed below in chronological order (new proposals go at the bottom). All pages affected must be mentioned in the ''brief'' description, with the talk page housing the discussion linked to directly via "({{fakelink|Discuss}})". If the proposal involved a page that is not yet made, use {{tem|fakelink}} to communicate its title. The '''Deadline''' must also be included in the entry. Linking to pages not directly involved in the talk page proposal is not recommended, as it clutters the list with unnecessary links. Place {{tem|TPP}} under the heading.
#All rules for talk page proposals are the same as mainspace proposals (see the "How To" section above), with the exceptions made by Rules 3 and 4 as follows:
#Voting in talk page proposals will be open for two weeks, not one. ('''All times GMT.''')
#*For example, if a proposal is added at any time on Monday, August 1, 2011, it ends two weeks later on Monday, August 15, 2011, at 23:59 GMT.
#Talk page proposals may be closed by the proposer at any time if both the support ''and'' the oppose sides each have fewer than five votes.
#The talk page proposal '''must''' pertain to the article it is posted on.
===List of Talk Page Proposals===
*Split Flying Question Block from [[Question Block]] ([[Talk:Question Block|Discuss]]) '''Deadline''': July 15, 2011, 23:59 GMT
*Move [[Waluigi Pinball]] to {{fakelink|Waluigi Pinball (Course)}} ([[Talk:Waluigi Pinball|Discuss]])  '''Deadline''': July 16, 2011, 23:59 GMT
*Split [[Giant Banana]] from [[Banana]] ([[Talk:Banana|Discuss]]) '''Deadline''': <s>July 3, 2011, 23:59 GMT</s> <s>July 10, 2011, 23:59 GMT</s> July 17, 2011, 23:59 GMT
*Merge [[Dry Dry Desert (course)]] with [[Dry Dry Desert]] ([[Talk:Dry Dry Desert|Discuss]]) '''Deadline''': July 18, 2011, 23:59 GMT
*Split the Spike Pillar section of [[Pillar]] from it. ([[Talk:Pillar|Discuss]]) '''Deadline''': July 19, 2011, 23:59 GMT
*Mention unofficial [[SMA4]] level names in articles to help minimise confusion ([[Talk:Super_Mario_Advance_4_e-Cards|Discuss]]) '''Deadline''': 22 July 2011, 23:59 GMT
*Move [[Expresso II]] to {{fakelink|Expresso the Ostrich (Donkey Kong Country 2)}} ([[Talk:Expresso II|Discuss]]) '''Deadline''': July 25, 2011, 23:59 GMT
*Merge [[Power Gauge]] with [[Health Meter]] ([[Talk:Power Gauge#Merge Power Gauge with Health Meter|Discuss]]) '''Deadline:''' July 25, 2011, 23:59 GMT
==Writing Guidelines==
===MLA Format===
All articles should be written with the most updated version of MLA Format. This will help in the eternal preservation of ''always citing your sources.''
'''Proposer:'''{{User|Plumber}} <br>
'''Deadline:''' July 23, 2011, 23:59 GMT
====Support====
#{{User|Plumber}}For clarity
#{{User|Super Mario Bros.}} &ndash; From the sounds of this, what Plumber is doing is suggesting we change our quotations and citations to a well-known, credible standard. I don't know why we shouldn't upgrade to a more credible standard, so I'll offer my support to this proposal.
#{{User|Superfiremario}} Per proposal.
====Oppose====
====Oppose====
#{{User|Walkazo}} - Regulating our reference formatting is a good idea, but I feel like it would be better to go about this by drafting a policy page with our own structure (based on MLA, but tailored to our specific needs) and ''then'' making a proposal. A vague, one-sentence statement (with a one-sentence justification) is far to little to go on, especially when hundreds of pages will be effected by the unspecified changes.
#{{User|Zero777}} Per Walkazo
#{{User|Mariomario64}} &ndash; MLA format shouldn't be directly used on a website like this, in my opinion. Also, per Walkazo.
#{{User|Mario4Ever}} Per Walkazo.
#{{User|Rise Up Above It}} Walkazo has a good idea.


====Debate====
====Comments====
What is MLA? {{User|Xzelion}}
{{@|Hewer}} I don't think this would necessarily eliminate cases in which statistics are in prose, but it may be redundant if there's the link to conveniently access the statistics or profiles. [[User:Super Mario RPG|Super Mario RPG]] ([[User talk:Super Mario RPG|talk]]) 15:15, December 18, 2024 (EST)
 
:Modern Language Association. {{User|Phoenix}}
::See [http://owl.english.purdue.edu/owl/resource/747/01/ here], Xzelion. {{User|Mario4Ever}}
 
:::Okay, that is seriously freaky, I was just gonna link to that... :O {{User|Phoenix}}


Won't this be a massive overhaul of practically every single article on the wiki? {{User|Dr Javelin}}
===Split image categories into separate ones for assets, screenshots, and artwork===
::::<s>I CAN READ YOUR MIND, PHOENIX!</s> I've never found a better source on MLA, so I figured that if I didn't link to it, someone inevitably would. @Dr Javelin: That depends on what exactly needs changing. On that note, Plumber, would you mind clarifying exactly what you propose to do? {{User|Mario4Ever}}
This proposal will address the bloat some image categories have and make them easier to navigate.


:@Mario4Ever - Yeah, my last two college English teachers practically forced us to use that when typing our assignments, so, needless to say, that was the first thing that popped into my head... {{User|Phoenix}}
Why is this useful? It makes adding to galleries or finding images to replace much easier. If you want to retake screenshots from a game, you can go to the screenshots category to find them. If you have sprite rips to replace, there's a category for that. The same goes for finding images from a game that aren't on the gallery already and being able to sort them more efficiently. This is also how we divide up character galleries already, such as [[Gallery:Mario (2010-2019)]].


It won't be a massive overhaul of the article on the wiki besides making source clarifications more useful. Wikis adhere to a rough version of MLA anyhow. The effects of this proposal are to be minor. {{User|Plumber}}
Now, I can see a few edge cases, like when games have screenshots of themselves for credits images (i.e. ''[[Paper Mario: The Thousand-Year Door (Nintendo Switch)]]''). I would still classify these as assets, since they are ripped from the game. Artwork that is used in smaller forms in-game, such as in ''[[Super Mario Maker 2]]'', would be classified as artwork if externally released or an asset if it was ripped from the game files. Edge cases shouldn't be too common and they're easy to work out: it's not too different from how we license images or put them in character or subject galleries.
:How minor? {{User|Xzelion}}
::Basically this only changes citations and ''maybe'' quotations (like where the periods go and stuff, not the actual templates). Also standardizes the English to American English, but that's already done on the wiki as a whole. {{User|Plumber}} 01:29, 9 July 2011 (EDT)
:::Standardizing the English doesn't make sense if the article is already written in British English (or vice-versa). As this is an international wiki, both variations are allowed, and changing one to the other is actually a warnable offense. It sort of operates on a first-come, first-served basis. {{User|Mario4Ever}}


I agree with Mario4Ever. We made a proposal to stablish that British English can be used here. {{user|Coincollector}}
I think the name "assets" would be more useful in shorthand than "sprites and models," in addition to covering textures, so I propose for the category to be called that, but I can change it if there's opposition. The global images category can still exist in the case there's scans, merchandise, video screenshots, or such images that cannot be further categorized.


Well MLA includes Canada, so I suppose we could grandfather Britain into it. But that's distracting from the main point, which is primarily that of quotation and citation, which so desperately need essential reforms. {{User|Plumber}}
'''Proposer''': {{User|Scrooge200}}<br>
 
'''Deadline''': January 5, 2025, 23:59 GMT
May you please elaborate on that, because I'm still not sure what you trying to do. {{User|Zero777}}
::I don't really understand what is going to happen. Could you show us some examples? {{User|LeftyGreenMario}}
:::Hello Plumber, are you there? May you please answer our questions? {{User|Zero777}}
Just Google MLA Standards sonny ;) {{User|Plumber}} 01:25, 11 July 2011 (EDT)
::::All that does is inform people what MLA is; it does nothing to explain exactly what you plan to do according to its standards (there's quite a lot of info, as you can see when clicking on the above link of mine). {{User|Mario4Ever}}
 
==New Features==
''None at the moment.''
 
==Removals==
===Reform MarioWiki:Proposals===
As two old users, we jointly feel that the decision-making system pre-MarioWiki:Proposals was superior to the current system. The current system of MarioWiki:Proposals is based upon popularity contests. The previous system involved discussion on the Community Portal and Talk:Main page. This new proposal would restore any potential problems to be discussed on Talk:Main page, not with "support" and "oppose" columns, but genuine ”bona fide” arguments and discussion. When consensus has been reached, the fate of the "proposal" will be decided. This was the way the system worked before the infamous and perfidious troll {{User|A Link to the Past}} tricked {{User|Porplemontage}} and {{User|Wayoshi}} into creating the proposals (only after his disastrous MarioWiki:Peer Review scheme had failed; Proposals were made largely as a concession to his whining). If this measure passes, it shall go into force July 17, 2011, although any Proposals that still need to expire will be left to expire at their natural time.
 
EDIT: MarioWiki:Proposals will still serve as the main place for talk page proposals. Many thanks to {{User|Goomba's Shoe15}} for bringing that up.
 
'''Proposers:''' {{User|Xzelion}}, {{User|Plumber}}, and {{User|Master Crash}}<br>
'''Deadline:''' July 16, 2011, 23:59 GMT  


====Support====
====Support====
#{{User|Xzelion}} &mdash; Per Plumber.
#{{User|Scrooge200}} Per proposal.
#{{User|Plumber}} &mdash; Per Xzelion ;) See how that's all one needs to get a vote? I think this case is justified since we wrote the proposal, but you know what I mean.
#{{User|Waluigi Time}} I support this in principle, as long as there's room for discretion on what gets split and what gets left alone. A game with only ten or so pieces of artwork doesn't need a separate category for them, they can just stay in the main images category for that game. Otherwise, this seems useful, I just don't want users to go overboard by purely following the letter of this proposal.
#{{User|Master Crash}} &mdash; Per all
#{{User|Salmancer}} I've tried to see if an image I wanted to use was already uploaded via the category, which would encourage me to make the text and get the article up. Due to the sheer number of images, this is a bad idea. This proposal will make that less of a bad idea for cases where an asset or artwork is being searched for.
#{{user|SWFlash}} I have to agree with this proposal. Supporting the proposal without describing why does one thinks it should be so is just bumps it and, sometimes, the wiki may end up to be in even worser situation than it was before the proposal. The good proposals may be unresolved just because one have said the good option to sage the proposal and everyone're just agreeing with him/her. But, of course, some users may be not creative enough to think about their options and they just want the proposal to be settled, but, I think, it's their problems.
#{{User|EvieMaybe}} hell yea
#{{User|Reddragon19k}} I love this proposal! This is my favorite time to per all for this one! Seriously, that is my favorite kind! So... PER EVERYONE!!!
#{{User|Power Flotzo}} Per all.
#{{User|DKPetey99}} Per all does seem to be used a lot. Mostly it's used for friendship. I was actually goanna make this proposal myself, but I didn't think people would approve of my idea. Per all
#{{User|FanOfYoshi}} Per all.
#{{User|ThirdMarioBro}} Per DKPetey99. I am getting tired of people just "going with the flow" and labeling their vote as "per all".
#{{User|BoygeyDude}} Per all, especially Dr Javelin & SWFlash. :)
#{{User|Super Mario Bros.}} &ndash; Making decisions through intelligent discussion, rather by a simple vote count restricted by time limits, seems much more understandable. Per the proposers.
#{{User|LeftyGreenMario}} This makes sense. I think some people put "per all" in their votes, but they don't really understand what they are voting for.
#{{User|Mariomario64}} &ndash; Per proposal and everyone else's comments. In my opinion, this is a much better way to decide on proposals.


====Oppose====
====Oppose====
#{{User|Walkazo}} - What worked in the old days doesn't necessarily translate to how things work now: the community and its dynamics have changed a lot over the years. There are a lot more users now, meaning discussions could potentially be dragged on forever: that's the advantage of deadlines (and the Clear Majority rule makes sure things that aren't settled by the deadline don't just pass). Popularity-based voting is bad, but it's not necessarily the driving force between "per"s, and if someone says everything that needs to be said, it is completely fine for others to per them. Even if all the people on the one side have something to add to the argument, ultimately, if more people agree with one person's idea (which they "per"), that idea should be used. To quote ''Star Trek'', the needs of the many outweigh the needs of the few. Besides, debates already happen in proposals, and proposals can be changed and replaced if better courses of action are identified. While free-flowing discussion might make this a ''little'' more natural-feeling, the lack of rules and structure could easily backfire, and will certainly be harder to archive. And who's to say popularity won't still be a factor in discussions: paraphrasing is just as easy as "per"ing.
#{{User|Zero777}} Oh the reform proposal is to debate until a decision is reached whenever (not by a deadline). Walkazo is right, that will drag on longer then the Starting Planet Proposal, per. And since were proposals popularity contests?
#{{User|Edofenrir}} - I pretty much agree with Walkazo on this one, but I'd like to go into something in conjunction with what she said towards the end of her comment. A lot of the supporters here seem to support solely to get rid of "Per" votes. However, those who do should stop and think about this for a moment. Specifically: How is this proposed system going to do anything about that? Counting arguments instead of heads? Is that going to fix it? Not at all. It is very, ''very'' easy to take an argument and rephrase it in a way that makes it appear like an entirely new argument. This older system will be just as exploitable than the one we are currently using. "Per" votes will not be eliminated by this change; they will just resurface in a different form. And then we will have to deal with those.
#{{User|Yoshiwaker}} - I'm changing my vote. There is nothing wrong with the current system. It's more like a democracy, which it should be when making decisions like this. Also I agree with Zero that if we had to have full consensus then it would take forever to make a decision. Also, per Edofenrir.
#{{User|twentytwofiftyseven}} Hahaha. Ironically, one guy like NARCE could filibuster the proposed system forever. Per all.
#{{User|Supremo78}} - Simply, the argument can still continue in the proposal still having the phrase "Per all". All it is is agreeing, which is what commonly people use. While I realize some people may just put it there just to vote with their friends, is this proposal really going to change that? A continuing argument is like court, which is not what we do here. Making decisions should be simpler than "court". However, some people who want to agree aren't just voting with their friends, may not have something to say, but: I agree (what Per is). People will never know which one the user is trying to do, so just leave it alone all together. Also, like Walkazo said, proposals may go so long, it may be over 2 times of that that the proposal {{User|Phoenix}} did (No Starting Planet Left Behind!) will last over 2 months. That's just not a good way to reach consensus.
#{{User|Glowsquid}} I'm not convinced an argument-only system would be that preferrable. One thing endemic to e-arguments is that they are frequently "won" not by the actual merits of the position presented, but rather by sheer repetition, as one or more participants repeat their stances ad-nauseum up until the other side gets bored or tired (and I was going to use the example of our friend ALinkToThePast/NARCE, but 2257 beat me to it). Of course the matters can be ultimately decided by the administrators - but then that kind of defeat the point of changing the system. I won't deny the current system is sometimes victim of the Popularity Contest/Sheep mentality phenomenom, but strong arguments ''can'' and often ''do'' change the tides of adebate, and I think the proposal as they are now have worked reasonably well. Also, per everything Walkazo said.
#{{User|Phoenix}} There is nothing whatsoever drastically wrong with the system we use currently, and I very highly doubt that the proposed system will make anything any better than it is now, even if it happened to work out well in the past. If I could see it improving the overall decision making process, I would support, but I honestly cannot see it turning into anything less than a travesty. As it is, I seriously doubt that the majority of users are so lazy or shortsighted that they would ignore the important issues at hand and only per the arguments of their friends or per arguments without fully realizing what it is that they are doing. Does that have the potential to happen? Possibly. Does that mean that the entire system is ineffective and detrimental? I don't think so.
#{{User|Hypnotoad}} As much as I'd like to avoid a simple "per" reasoning, pretty much everything I can think about has been said, so per all.
#{{User|Goomba's Shoe15}} per Walkazo after reading her comments i find the proposal system to be just as good if not better than the old system.
#{{User|Gamefreak75}} Even though the "per" reasoning can be annoying at times, it is even more annoying and redundant to restate the exact points that have already been said. So in general, per all.
#{{User|Fawfulfury65}} I agree with the opposers. Also, there are too many users to settle proposals in the way they used to be settled. The arguments would become extremely long and last forever. The current way makes everything more organized, and it helps you tell who is on what side more easily. Some people may vote on a side just because their friend is voting there, but they are outnumbered by the number of users who vote on the side they are sure is best.
#{{User|Bop1996}} Even though I'm still on hiatus, I think that this is such an important issue that I needed to vote anyway. I don't want to argue about what may or may not have happened in the past with User A or User B. That being said, the current system works quite well as it is imho, and the new system wouldn't work better as per everyone above, so per all.
#{{User|Young Master Luma}} The system currently used is much simpler than the one proposed, which (in my opinion) attracts more people to vote. On a wiki with so many users, it would be mildly chaotic to let all the users argue about something just to often come to a quite ambiguous conclusion.
#{{User|MrConcreteDonkey}} - The "”bona fide” arguments and discussion" is the "comments" section of the proposals. Support and oppose columns are much more organised and simple than just cluttered argument. It's easier to find out the end result, too. If we reform this page, how will we know when a proposal has passed? Who will check, and when? And would there be debate even after the end result? If most of the supporters are voting to get rid of the "Per" system, it's quite ironic they're doing it themselves. Per all, especially Walkazo and Edofenrir.
#{{User|UltraMario3000}} "Per" all (Horrible pun).
#{{User|Rise Up Above It}} Although I joined in 2007, I assume that that event you mentioned took place before I jooined, for in the two weeks I was active after joining, I voted in some proposals that seem to have the same basic formula as the ones today (One of my main memories of late 2007 MW is Stumpers' tirades on the Proposals page). I have no idea then of the changes you propose, so I shall agree with all these good arguments.


====Debate====
====Comments====
This proposal include removing the TPP proposal system and if it does are all the TPP proposals that expire after the deadline of this proposal cancelled {{User|Goomba's Shoe15}}
This is already being done (e.g. [[:Category:Mario Kart Tour item icons]]). [[User:Super Mario RPG|Super Mario RPG]] ([[User talk:Super Mario RPG|talk]]) 11:02, December 23, 2024 (EST)
:The Talk Page Proposals are not affected by the system, so they'll still be here. No worries.{{User|Plumber}} 01:56, 9 July 2011 (EDT)
:::What about any proposals proposed before this proposal ends but that expire after the dead line are they cancelled to {{User|Goomba's Shoe15}}
Wait what do the peer reviews have to do with proposals i though those were for the FA process {{User|Goomba's Shoe15}}


What happens if it's a huge proposal with plenty of people with good arguments on both sides? So far, it seems to me that this will create stalemates that eventually stop the wiki from making decisions because of red tape. See the "No starting planet left behind" proposal in the Archives. I do agree that many proposals end up as popularity contests, but at least things happen. {{User|Dr Javelin}}
==Removals==
:Well i think what would happen is they would debate until one side wins cause even now a proposal can only be extended so many times until it fails. And i'm sorry if this doesn't answer your question or is wrong cause i wasn't around during the day and age when they used the talk main page {{User|Goomba's Shoe15}}
''None at the moment.''


Huge proposals actually become smaller because less people are willing to actually write a detailed opinion compared to doing "Per X." Back in the day, ''things got done and stayed done.'' If the arguments are good on both sides, generally the sysops step in to referee, which is not the ideal situation, but it's the general solution. They already referee the Proposals enough as it is. {{User|Plumber}}
==Changes==
:It still seems like it might take longer than the current proposal system. And what happens if the sysops have differing opinions? I am in no way supporting the current proposal system, but as far as I can tell, things still happen. Articles get merged, split, edited, and changed, all according to the proposals. I agree that people should be required to give detailed arguments for or against proposals, but people shouldn't have to wait for a consensus. A time limit might still be needed to make sure that things still happen. {{User|Dr Javelin}}
===Broaden the scope of the <nowiki>{{rewrite}}</nowiki> template and its variations===
In the past, consensus was always able to occur, moreso today with the Sysop Boards.
With the [[Template talk:Unreferenced#Delete or be more specific|previous proposal]] having passed with being more specific as the most voted, I've come up with a proposal about the possibility to make the {{tem|rewrite}}, {{tem|rewrite-expand}}, and {{tem|rewrite-remove}} templates more specific. As you can see, these templates are missing some smaller text. As such, I am just wondering if there is a possibility to have the smaller text added to the <nowiki>{{rewrite}}</nowiki>, <nowiki>{{rewrite-expand}}</nowiki>, and <nowiki>{{rewrite-remove}}</nowiki> templates.
CC: Basically, that's how it was done before. However such things would be done at [[Talk:Main Page]] like they were  because we have agreed the Proposals is too formulaic to be conductive. Strict deadlines are often too short or too long to be effective as well. If anyone needs more information, Xzelion will be happy to oblige, although I know you, CC, of all people are familiar with the old system :) {{User|Plumber}}
 
I'm not exactly familiar with the old proposal system, mostly because I never attended many proposals during my earlier wiki days. {{User|M&SG}}
 
'''@DKPetey99 and ThirdMarioBro''': Well, if that is truly the case, then pretty much nothing we can do will be able to stop that because by this system, they could just "agree" with their friend. {{User|Yoshiwaker}}
 
I have a question for the proposers: will this effect the proposals box on the Main Page? If so, how do you plan to adapt the Main Page for this change? {{User|Super Mario Bros.}}
 
So how will the old system work? You didn't necessarily elaborate on that. {{User|Zero777}}


Hmm. I'm switching back to neutral because of the good opposition arguments, and I'll stay that way unless someone can clearly define the pros and cons of each system in an unbiased manner. {{User|Dr Javelin}}
First of all, the <nowiki>{{rewrite}}</nowiki> template currently reads as follows:
----
<pre>
<div class="notice-template maintenance" style="background:#9CF;border:1px solid #000">
It has been requested that this {{#if:{{{section|}}}|section|article}} be '''rewritten'''. {{#if:{{{reason|{{{1|}}}}}}|'''Reason:''' {{{reason|{{{1}}}}}}|<includeonly>{{#switch:{{NAMESPACE}}||Gallery=[[Category:Articles with incomplete maintenance tags]]}}</includeonly>}}{{#if:{{{date|{{{2|}}}}}}|<nowiki/> (tagged on {{{date|{{{2}}}}}})}}
</div>
</pre>


2257: NARCE could filibuster the proposed system because at that time executive power was concentrated in Wayoshi and (the aloof) Steve. He just needed to wear down one person. Now this is not the case. Also, the "per alls" are not the central issue here, but the voting patterns themselves. Already a few people have defected from my side to the other side. This just proves my point that the Proposals system leads to "vote trends" where the influence of well-known people convinces unsures to go to that side. This proposal was going to pass for sure until Walkazo made things more exciting. If Walkazo had remained silent, then there is a greater likelihood someone such as Zero or Yoshiwaker would not have their votes / voted for my side. The fact that Xzelion and I and Crash (all-well known people, and all in favor of this measure) backed it was to illustrate the flaws of this system as well. Did I already mention how Son of Suns eloquently confused everyone into destroying something they had just backed in a previous Proposal days earlier? Ever since then, I have been at odds with our current system of Proposals; people who liked Son of Suns voted for him because he was popular or because he wrote all fancy-like and whatever it was, it sounded smart or something. I would go on, but I haven't slept in two days, so I'm a bit worn out. The old version in action can be seen in older Talk:Main page archives, where problems were discussed and solved. {{User|Plumber}} 00:02, 10 July 2011 (EDT)
<div class="notice-template maintenance" style="background:#9CF;border:1px solid #000">
:The funny part is that Son of Suns got ''just'' as peeved whenever I threw spanners in ''his'' proposals. But on a serious note, demonizing a retired user who did much more good than harm to the wiki isn't a very fair argument, especially when half of his battles were waged in the ''comments'' sections of the proposals anyway: cutting out the voting part wouldn't have stopped him. Straightforward issues are votes, but anything more in-depth already turns into a debate; the voting part is just so we can keep track of who's winning the argument. Fan votes happen, but it's unreasonable to act like every person's change of heart here is because of a reputation showdown - you can't know that for sure, and assumptions do not make for good arguments. The origins of the system is also a moot point: it has worked just fine for four years (during which the community has changed its face multiple times over); since we've added the Clear Majority and emergency Admin Veto rules, I can't recall any cases where I felt a proposal passed that shouldn't have, and before those rules were made, I can think of only one. Even if you can dredge up a few other mistakes, there will still be hundreds more that came to a just outcome. And really, had this been a discussion, it would have become just as "exciting" before long: an idea is <s>proposed</s> suggested, people like it, but then someone points out some flaws and more people join in (maybe because the first person is well-known, maybe because simply having someone else cast the first stone makes it easier to speak up, or maybe because they simply happened to get there after the first person). The only difference is that maybe we would have less people involved in between the major point-makers, but I don't think that's actually a desirable thing at all: the few people who actually get involved with intimidating, time-consuming discussions aren't necessarily representative of the community as a whole. - {{User|Walkazo}}
It has been requested that this article be '''rewritten'''.
::Demonizing? Harsh words. That particular proposal was a very lengthy description with little comments at all IIRC. The only people who I think would be less involved would be people who don't care at all and are just voting for their friend or the cool kid or something. Most of the community doesn't care about every little single issue, or else everyone would always vote on every proposal unless they were unable to due to RL concerns. {{User|Plumber}} 01:24, 11 July 2011 (EDT)
</div>
----
However, once the proposal passes, the <nowiki>{{rewrite}}</nowiki> template will read as follows:
----
<pre>
<div class="notice-template maintenance" style="background:#9CF;border:1px solid #000">
It has been requested that this {{#if:{{{section|}}}|section|article}} be '''rewritten'''{{#if:{{{reason|{{{1|}}}}}}|<nowiki/> for the following reason(s): {{{reason|{{{1}}}}}}|.<includeonly>{{#switch:{{NAMESPACE}}||Gallery=[[Category:Articles with incomplete maintenance tags]]}}</includeonly>}}{{#if:{{{date|{{{2|}}}}}}|<nowiki/> (tagged on {{{date|{{{2}}}}}})}}<br><small>Please review the [[MarioWiki:Manual of Style|Manual of Style]] and [[MarioWiki:Good writing|good writing standards]] and help {{plain link|{{fullurl:{{FULLPAGENAME}}|action=edit}}|improve this {{#if:{{{section|}}}|section|article}}}}.</small>
</div>
</pre>


I had to dismiss my vote since I rushed in my decision to retrieve the old proposal's way without looking the drawbacks clearly. I'll stay neutral but I'll go with any absolute conclusion. By the way, would Proplemontage agree to change this proposal for another regarding to these decisions if succeeded? I guess he might have the last word. {{user|Coincollector}}
<div class="notice-template maintenance" style="background:#9CF;border:1px solid #000">
:What do you mean? That seems unclear. {{User|Plumber}} 01:24, 11 July 2011 (EDT)
It has been requested that this article be '''rewritten''' for the following reason(s): <reason(s)>.<br><small>Please review the [[MarioWiki:Manual of Style|Manual of Style]] and [[MarioWiki:Good writing|good writing standards]] and help {{plain link|{{fullurl:{{FULLPAGENAME}}|action=edit}}|improve this article}}.</small>
</div>
----
And another thing—the <nowiki>{{rewrite-expand}}</nowiki> template currently reads as follows:
----
<pre>
<div class="notice-template maintenance" style="background:#9CF;border:1px solid #000">
It has been requested that this {{#if:{{{section|}}}|section|article}} be '''rewritten''' and '''expanded''' to include more information. {{#if:{{{reason|{{{1|}}}}}}|'''Reason:''' {{{reason|{{{1}}}}}}|<includeonly>{{#switch:{{NAMESPACE}}||Gallery=[[Category:Articles with incomplete maintenance tags]]}}</includeonly>}}{{#if:{{{date|{{{2|}}}}}}|<nowiki/> (tagged on {{{date|{{{2}}}}}})}}
</div>
</pre>


'''@Plumber''': The "vote trends" you are talking about could very well occur in the proposed system anyways. Somebody could make a good enough argument to convince somebody to change their mind about something. Also, it doesn't matter ''who'' makes an argument that could convince others to take their side. If I had made the exact same argument as Walkazo before she did, I doubt that any less people would have opposed this. Also, that argument is similar to the one in [[MarioWiki:Proposals/Archive#Make_a_Rule_for_Changing_Votes|this proposal]], I find the logic flawed in that it is based off of something that cannot be proven. {{User|Yoshiwaker}}
<div class="notice-template maintenance" style="background:#9CF;border:1px solid #000">
:Cannot be proven? Have you looked at the archives of Talk:Main page? There's old evidence there. Reasonable debate unfettered by random votes by people who don't care. {{User|Plumber}} 01:24, 11 July 2011 (EDT)
It has been requested that this article be '''rewritten''' and '''expanded''' to include more information.
</div>
----
However, once this proposal passes, the <nowiki>{{rewrite-expand}}</nowiki> will read as follows:
----
<pre>
<div class="notice-template maintenance" style="background:#9CF;border:1px solid #000">
It has been requested that this {{#if:{{{section|}}}|section|article}} be '''rewritten''' and '''expanded''' to include more information.{{#if:{{{reason|{{{1|}}}}}}|<nowiki/> for the following reason(s): {{{reason|{{{1}}}}}}|.<includeonly>{{#switch:{{NAMESPACE}}||Gallery=[[Category:Articles with incomplete maintenance tags]]}}</includeonly>}}{{#if:{{{date|{{{2|}}}}}}|<nowiki/> (tagged on {{{date|{{{2}}}}}})}}<br><small>Please review the [[MarioWiki:Manual of Style|Manual of Style]] and [[MarioWiki:Good writing|good writing standards]] and help {{plain link|{{fullurl:{{FULLPAGENAME}}|action=edit}}|improve this {{#if:{{{section|}}}|section|article}}}} by filling in the missing details.</small>
</div>
</pre>


I wasn't a user back when the old system was going on. In fact, I wasn't even active until March but I joined on Jan 9 2011. So, i'm not voting.
<div class="notice-template maintenance" style="background:#9CF;border:1px solid #000">
{{User|Superfiremario}}
It has been requested that this article be '''rewritten''' and '''expanded''' to include more information for the following reason(s): <reason(s)>.<br><small>Please review the [[MarioWiki:Manual of Style|Manual of Style]] and [[MarioWiki:Good writing|good writing standards]] and help {{plain link|{{fullurl:{{FULLPAGENAME}}|action=edit}}|improve this article}} by filling in the missing details.</small>
</div>
----
Lastly, the <nowiki>{{rewrite-remove}}</nowiki> currently reads as follows:
----
<pre>
<div class="notice-template maintenance" style="background:#9CF;border:1px solid #000">
It has been requested that this {{#if:{{{section|}}}|section|article}} be '''rewritten''' to have <u>{{{content|{{{1|content<includeonly>{{#switch:{{NAMESPACE}}||Gallery=[[Category:Articles with incomplete maintenance tags]]}}</includeonly>}}}}}}</u> '''removed''' for the following reason(s): {{{reason|{{{2|???<includeonly>{{#switch:{{NAMESPACE}}||Gallery=[[Category:Articles with incomplete maintenance tags]]}}</includeonly>}}}}}}{{#if:{{{date|{{{3|}}}}}}|<nowiki/> (tagged on {{{date|{{{3}}}}}})}}
</div>
</pre>


I would also like to point out that the "per" problems were "solved" by an old Proposal to abolish "per X" as a reason. IIRC, another Proposal brought it back. That's just a good example of the fickleness of the Proposals system. {{User|Plumber}} 01:29, 11 July 2011 (EDT)
<div class="notice-template maintenance" style="background:#9CF;border:1px solid #000">
:New comments are actually supposed to go on the bottom, not imbedded between other comments, since that can really muddle things up. Specific comments can be addressed using "@X:" or "'''X:'''", or something like that. Anyway, '''in response to your response to my comment''', I stand by my choice of words, and I wasn't actually talking about any of Son of Suns' proposals in particular. (Although, having gone through the archives, I found that six of his proposals were straightforward votes (half of those were straightforward yes/no decisions, however, so there was nothing that ''could'' be debated), whereas two passed proposals involved lengthy discussions and three others failed after lengthy discussions.) Yes, everybody doesn't care about everything, but it's not reasonable to say that everyone who will vote but not discuss something doesn't care ''at all''. Someone could easily care about an issue to some extent, but not want to get involved in a free-for-all debate on behalf of it, or they might feel that all their points have already been added to the discussion and worry that people won't appreciate them cutting in just to say "I agree with X". On the other hand, perhaps people ''would'' do that, en masse, in which case we're back to a vote, only it'll be a lot messier than proposals and their running tallies. Plus, people could always flock to their friends' aid in discussions just as easily as in proposals, in which case, again, we'd have gained nothing from the change. '''In response to your comment to Yoshiwaker''', just because it worked back then doesn't mean it'll work now, when the community has grown and changed so much over the years. Besides, while there ''were'' lots of good discussions back then, users still resorted to votes on three occasions ([[MarioWiki:Main_Page_Talk_Archive_5#Locking_the_Move_Feature_OR_Adding_More_Sysops|1]], [[MarioWiki:Main_Page_Talk_Archive_7#Un-_or_Fan-_MarioWiki|2]], [[MarioWiki:Main_Page_Talk_Archive_8#Humans|3]]) before the proposal system was brought into existence (first spoken of [[MarioWiki:Main_Page_Talk_Archive_10#.22Sudden.22_Change_--_Oligarchy.3F_Rash_movement.3F_I_feel_I_am_to_blame.|on Archive 10]], although obviously you can't get the full story from that section alone), which is rather interesting. And finally, '''regarding your last comment''', I checked the archives and all I found was a ''failed'' attempt to remove "per" votes ([[MarioWiki:Proposals/Archive_2#Pers.2C_I_agrees...|here]]), and similarly, both times they were were brought up on the talk pages ([[MarioWiki_talk:Proposals#.22Per.22|here]] and [[MarioWiki_talk:Proposals#Per_votes|here]]), they were left alone. - {{User|Walkazo}}
It has been requested that this article be '''rewritten''' to have <u>content</u> '''removed''' for the following reason(s): ???
</div>
----
However, once this proposal passes, the <nowiki>{{rewrite-remove}}</nowiki> will read as follows:
----
<pre>
<div class="notice-template maintenance" style="background:#9CF;border:1px solid #000">
It has been requested that this {{#if:{{{section|}}}|section|article}} be '''rewritten''' to have {{#if:{{{content|{{{1|}}}}}}|<u>{{{content|{{{1}}}}}}</u>|content}} '''removed'''{{#if:{{{reason|{{{2|}}}}}}|<nowiki/> for the following reason(s):{{{reason|{{{2}}}}}}|.<includeonly>{{#switch:{{NAMESPACE}}||Gallery=[[Category:Articles with incomplete maintenance tags]]}}</includeonly>}}{{#if:{{{date|{{{3|}}}}}}|<nowiki/> (tagged on {{{date|{{{3}}}}}})}}<br><small>Please review the [[MarioWiki:Manual of Style|Manual of Style]] and [[MarioWiki:Good writing|good writing standards]] and help {{plain link|{{fullurl:{{FULLPAGENAME}}|action=edit}}|improve this {{#if:{{{section|}}}|section|article}}}} by removing the unnecessary details.</small>
</div>
</pre>


===Remove Logos from Infobox Titles===
<div class="notice-template maintenance" style="background:#9CF;border:1px solid #000">
Quite a few games have logos instead of plain text for their infobox titles, but seeing as the game boxart also contains the logo and is located directly beneath the title, all this really does is show us the exact same graphic twice. This is redundant, and it looks sloppy, especially when the logos are transparent and the background colour interferes with the words. It's also inconsistent, since most games just use good ol' fashioned text. Compare [[Mario Kart DS]] with [[Mario Kart: Double Dash!!]] - there's no question as to which one looks more professional, and by extension, which style we should use. Other games using the superfluous title-logos include [[Super Mario Sunshine]], [[Super Mario Galaxy]], all three [[Mario & Sonic at the Olympic Games]] titles, [[Mario Party 8]], [[Mario Kart Wii]] and both [[Super Smash Bros. Melee]] and [[Super Smash Bros. Brawl|Brawl]], among others. Then you have the occasional ''character'' page with a title-logo, which is completely unnecessary. The only time it makes sense to have logos is for series pages, since a single boxart isn't adequately representative of ''all'' the games involved. Some example of this logo usage are [[Super Smash Bros. (series)]], [[Mario Party (series)]], and [[Mario Kart (series)]] (compare with [[Mario Kart DS]]), but even then, the logos are being used as the infobox ''images'', not the titles. And, while the consoles don't really the logos in their images, the transparency issue is still a problem, and the inconsistency with other types of pages is also undesirable, so it'd be better of the logos were simply used elsewhere.
It has been requested that this article be '''rewritten''' to have content '''removed''' for the following reason(s): <reason(s)>.<br><small>Please review the [[MarioWiki:Manual of Style|Manual of Style]] and [[MarioWiki:Good writing|good writing standards]] and help {{plain link|{{fullurl:{{FULLPAGENAME}}|action=edit}}|improve this article}} by removing the unnecessary details.</small>
</div>
----
That will be a perfect idea to make the <nowiki>{{rewrite}}</nowiki> template and its variations as more specific as the {{tem|media missing}} and {{tem|unreferenced}} templates. That way, we'll be able to add smaller text to the remaining [[:Category:Notice templates|notice templates]] in the future.


In short, I propose we remove all instances where the logos are being used for the infobox titles. The logos can be put into the galleries (or incorporated into the body text, as is the case with the character and console pages), so nothing is being lost. Series pages with logos being used as their images will not be affected.
'''Proposer''': {{User|GuntherBayBeee}}<br>
 
'''Deadline''': <s>December 23, 2024, 23:59 GMT</s> Extended to December 30, 2024, 23:59 GMT
'''Proposer:''' {{User|Walkazo}}<br>
'''Deadline:''' July 12, 2011, 23:59 GMT


====Support====
====Support====
#{{User|Walkazo}} - Using text instead of logos is neater, simpler, clearer, more concise and less redundant, and it will make all the game pages consistent.
#{{User|GuntherBayBeee}} Per proposal
#{{User|Phoenix}} Couldn't have said it better myself. I support this 100%.
#{{User|Lindsay151}} Per proposal.
#{{User|Goomba's Shoe15}} Per Proposal
#{{User|Xzelion}} &ndash; Per Walkazo.
#{{User|Zero777}} I found those incredibly hideous, per Walkazo.
#{{user|Coincollector}} - I always wondered where it came the tendency to put the game logo in the game infoboxes. Per proposer.
#{{User|Reddragon19k}} I'm going to agree with Walkazo on this one. We don't need logos on infoboxes, we already have some in the gallery section. Take ''[[Mario Kart Wii]]'' for example. The logo is on the article and the gallery for the game. If we lose it, then it can only be seen in the gallery page for that game. So, per Walkazo!
#{{User|Tails777}} Per proposal.
#{{User|MeritC}} Per all on this case.
#{{User|Supremo78}} That's why I removed the SM64DS logo from its page. Per proposal.
#{{User|Mario4Ever}} Per all.
#{{User|Baconator}} They looked clunky and unprofessional. Per all.
#{{User|Super Mario Bros.}} &ndash; Per Walkazo.
#{{User|Super Luigi! Number one!}} Per.
#{{User|Fawfulfury65}} The logos are already shown on the boxart. Plus, it's inconsistent on how some infoboxes have logos in their titles, while others don't.
#{{User|DKPetey99}} Per FF65. Also, it looks sloppy to have pages with logos and pages without logos. Especially the [[Mii]] logo.


====Oppose====
====Oppose====
#{{User|BoygeyDude}} I don't see anything wrong with keeping the logo.
#{{User|Altendo}} As far as I can tell, the proposal that was linked added parameters that allowed what was supposed to be referenced to be referenced. This one simply adds a subtitle to the bottom of each template. "Be more specific" does not mean saying general information and helpful links, but rather exactly what needs to be done; in terms of that, the existing templates not only all already have parameters, but [[MarioWiki:Proposals/Archive/61#Discourage drive-by templating|filling them out is enforced]]. As [[User:Nightwicked Bowser|Nightwicked Bowser]] said, "Be more specific - Similar to [[MarioWiki:Proposals/Archive/61#Discourage drive-by templating|this proposal]], what exactly needs references must be specified in the template when putting it in the article. A parameter for this will still need to be added." This only adds a subtitle and does not make this "more specific". As for the changes, this is actually harmful in some way, as the <nowiki>(tagged on {{{date|{{{3}}}}}})</nowiki> tag will be added to the subtitle, rather than the main body, which could make it more confusing in my opinion. Feel free to update this and add in what "more specific" actually means, or just change this to "add subtitles" and change the location of <nowiki>(tagged on {{{date|{{{3}}}}}})</nowiki> to the main body, but until then, my vote is staying here.
#{{User|Superfiremario}} Transparent ones are fine, but I'm afraid to agree for untransparent logos.
#{{User|Mario}} Best to keep things simple with these improvement templates.
#{{User|Mariomario64}} &ndash; Per the two above.
#{{User|Technetium}} Per Mario.
#{{User|Plumber}} Why must art be destroyed in the name of conformity?


====Comments====
====Comments====
@ Walkazo: Could you include the removal of Logos of the consoles? Just as you said that color interferes with the design of the logos, this problem can also be seen in the [[Wii U]]'s page and the [[Wii]]. The [[GameCube]] takes a step further: How do you read a symbol of a game console in the infobox? {{user|Coincollector}}
:Well, this proposal is already about removing ''all'' logo-titles, but I agree that adding consoles to the explicit list of what shouldn't have them is a good idea; thanks for pointing it out! - {{User|Walkazo}}
Actually, removing the logos are okay, but maybe they should be moved to the subject's gallery. There may be some chance that we want these plain logos. - {{User|Akfamilyhome}}
:I think you missed a couple lines of the proposal: I ''am'' suggesting that they be moved to the galleries (and they can even be incorporated into the body text, in some cases). They're not being removed from the articles, just from the infoboxes. - {{User|Walkazo}}
@Coincollector: Sorry. {{user|SWFlash}}


If this proposal passes, are we going to remove the logos on games that haven't been released? {{User|Tails777}}
Here's how I would fix some things:
:I don't see why we wouldn't. {{User|Yoshiwaker}}
::Yes, we'd remove the logos from the infobox titles, but if there's no other artwork available, the logo would be used as the infobox ''image'', like the series pages. So, pages like [[Super Mario 3D]], [[Paper Mario (Nintendo 3DS)]] and [[Luigi's Mansion 2]] would be unaffected, while [[Mario Kart 3D]]'s title-logo would be converted into the image, and [[Mario & Sonic at the London 2012 Olympic Games]]'s logo would be removed from the infobox altogether (it's already on the gallery page). - {{User|Walkazo}}


'''@Plumber:''' We are not getting rid of them, one, the artwork of the title is already in the boxart, and two, they are most likely already located at the gallery. {{User|Zero777}}
First of all, the <nowiki>{{rewrite}}</nowiki> template currently reads as follows:
----
<pre>
<div class="notice-template maintenance" style="background:#9CF;border:1px solid #000">
It has been requested that this {{#if:{{{section|}}}|section|article}} be '''rewritten'''. {{#if:{{{reason|{{{1|}}}}}}|'''Reason:''' {{{reason|{{{1}}}}}}|<includeonly>{{#switch:{{NAMESPACE}}||Gallery=[[Category:Articles with incomplete maintenance tags]]}}</includeonly>}}{{#if:{{{date|{{{2|}}}}}}|<nowiki/> (tagged on {{{date|{{{2}}}}}})}}
</div>
</pre>


Since some articles don't have logo's in the infobox titles and some do, I wouldn't mind if we remove the logo's from the info box titles. It looks more professional that way. However, we should realize a game logo is one important image of the game. Logo's are used for commercials on TV or advertisements in newspaper. Websites of the game also show the logo big. The logo is also on the box and even in the game itself. I think we should find a more efficient place for the game logo on the article. A game logo is MAYBE even more important then the boxart. {{User|Arend}}
<div class="notice-template maintenance" style="background:#9CF;border:1px solid #000">
:Fortunately, the logo is ''in'' the boxart, so it's not ''really'' being removed from the article. If there was a logical place to put the stand-alone logo further down the page (rather than just putting it on the gallery), that'd be great, but very few articles have sections where it would make sense (i.e. Development or Reception sections). I'm planning on putting a few logos in the introductions of pages where the image itself doesn't have the logo (i.e. the consoles and the Mii), but for the most part, the logos are gallery-bound, I'm afraid. - {{User|Walkazo}}
It has been requested that this article be '''rewritten'''.
</div>
----
However, once the proposal passes, the <nowiki>{{rewrite}}</nowiki> template will read as follows:
----
<pre>
<div class="notice-template maintenance" style="background:#9CF;border:1px solid #000">
It has been requested that this {{#if:{{{section|}}}|section|article}} be '''rewritten'''{{#if:{{{reason|{{{1|}}}}}}|<nowiki/> for the following reason(s): {{{reason|{{{1}}}}}}|.<includeonly>{{#switch:{{NAMESPACE}}||Gallery=[[Category:Articles with incomplete maintenance tags]]}}</includeonly>}}{{#if:{{{date|{{{2|}}}}}}|<nowiki/> (tagged on {{{date|{{{2}}}}}})}}<br><small>Please review the [[MarioWiki:Manual of Style|Manual of Style]] and [[MarioWiki:Good writing|good writing standards]] and help {{plain link|{{fullurl:{{FULLPAGENAME}}|action=edit}}|improve this {{#if:{{{section|}}}|section|article}}}}.</small>
</div>
</pre>


==Changes==
<div class="notice-template maintenance" style="background:#9CF;border:1px solid #000">
It has been requested that this article be '''rewritten''' for the following reasons:<br><small>Please review the [[MarioWiki:Manual of Style|Manual of Style]] and [[MarioWiki:Good writing|good writing standards]] and help {{plain link|{{fullurl:{{FULLPAGENAME}}|action=edit}}|improve this article}}.</small>
</div>
----
And another thing—the <nowiki>{{rewrite-expand}}</nowiki> template currently reads as follows:
----
<pre>
<div class="notice-template maintenance" style="background:#9CF;border:1px solid #000">
It has been requested that this {{#if:{{{section|}}}|section|article}} be '''rewritten''' and '''expanded''' to include more information. {{#if:{{{reason|{{{1|}}}}}}|'''Reason:''' {{{reason|{{{1}}}}}}|<includeonly>{{#switch:{{NAMESPACE}}||Gallery=[[Category:Articles with incomplete maintenance tags]]}}</includeonly>}}{{#if:{{{date|{{{2|}}}}}}|<nowiki/> (tagged on {{{date|{{{2}}}}}})}}
</div>
</pre>


===Artwork Transparency Issues===
<div class="notice-template maintenance" style="background:#9CF;border:1px solid #000">
During the past set of months, I've been noticing that a good number of JPEG artworks were being replaced by PNG artworks with transparent backgrounds. However, a lot of those images look quite ugly when they're viewed in backgrounds that aren't colored white.  I've mentioned this dilemma at the admins boards, and some of the Sysops there do agree with my statement.  I propose that any artworks with ugly-looking transparency has to lose the transparency. After all, we shouldn't be modifying the artworks by any means; if the artworks are JPEGs, upload them as JPEGs; if the PNG artworks don't have anything transparent, upload them that way.
It has been requested that this article be '''rewritten''' and '''expanded''' to include more information.
</div>
----
However, once this proposal passes, the <nowiki>{{rewrite-expand}}</nowiki> will read as follows:
----
<pre>
<div class="notice-template maintenance" style="background:#9CF;border:1px solid #000">
It has been requested that this {{#if:{{{section|}}}|section|article}} be '''rewritten''' and '''expanded''' to include more information{{#if:{{{reason|{{{1|}}}}}}|<nowiki/> for the following reason(s): {{{reason|{{{1}}}}}}|.<includeonly>{{#switch:{{NAMESPACE}}||Gallery=[[Category:Articles with incomplete maintenance tags]]}}</includeonly>}}{{#if:{{{date|{{{2|}}}}}}|<nowiki/> (tagged on {{{date|{{{2}}}}}})}}<br><small>Please review the [[MarioWiki:Manual of Style|Manual of Style]] and [[MarioWiki:Good writing|good writing standards]] and help {{plain link|{{fullurl:{{FULLPAGENAME}}|action=edit}}|improve this {{#if:{{{section|}}}|section|article}}}} by filling in the missing details.</small>
</div>
</pre>


Update: To understand what's going on, please look [[User:M&SG/proposal|here]] for examples of good transparency and bad transparency.
<div class="notice-template maintenance" style="background:#9CF;border:1px solid #000">
It has been requested that this article be '''rewritten''' and '''expanded''' to include more information for the following reasons:<br><small>Please review the [[MarioWiki:Manual of Style|Manual of Style]] and [[MarioWiki:Good writing|good writing standards]] and help {{plain link|{{fullurl:{{FULLPAGENAME}}|action=edit}}|improve this article}} by filling in the missing details.</small>
</div>
----
Lastly, the <nowiki>{{rewrite-remove}}</nowiki> currently reads as follows:
----
<pre>
<div class="notice-template maintenance" style="background:#9CF;border:1px solid #000">
It has been requested that this {{#if:{{{section|}}}|section|article}} be '''rewritten''' to have <u>{{{content|{{{1|content<includeonly>{{#switch:{{NAMESPACE}}||Gallery=[[Category:Articles with incomplete maintenance tags]]}}</includeonly>}}}}}}</u> '''removed''' for the following reason(s): {{{reason|{{{2|???<includeonly>{{#switch:{{NAMESPACE}}||Gallery=[[Category:Articles with incomplete maintenance tags]]}}</includeonly>}}}}}}{{#if:{{{date|{{{3|}}}}}}|<nowiki/> (tagged on {{{date|{{{3}}}}}})}}
</div>
</pre>


'''Proposer''': {{User|M&SG}}<br>
<div class="notice-template maintenance" style="background:#9CF;border:1px solid #000">
'''Deadline''': <s>June 30, 2011 23:59 GMT</s> <s>July 7, 2011, 23:59 GMT</s> July 14, 2011, 23:59 GMT
It has been requested that this article be '''rewritten''' to have <u>content</u> '''removed''' for the following reason(s): ???
</div>
----
However, once this proposal passes, the <nowiki>{{rewrite-remove}}</nowiki> will read as follows:
----
<pre>
<div class="notice-template maintenance" style="background:#9CF;border:1px solid #000">
It has been requested that this {{#if:{{{section|}}}|section|article}} be '''rewritten''' to have {{#if:{{{content|{{{1|}}}}}}|<u>{{{content|{{{1}}}}}}</u>|content}} '''removed''' {{#if:{{{reason|{{{2|}}}}}}|<nowiki/> for the following reasons:{{{reason|{{{2}}}}}}|.<includeonly>{{#switch:{{NAMESPACE}}||Gallery=[[Category:Articles with incomplete maintenance tags]]}}</includeonly>}}{{#if:{{{date|{{{3|}}}}}}|<nowiki/> (tagged on {{{date|{{{3}}}}}})}}<br><small>Please review the [[MarioWiki:Manual of Style|Manual of Style]] and [[MarioWiki:Good writing|good writing standards]] and help {{plain link|{{fullurl:{{FULLPAGENAME}}|action=edit}}|improve this {{#if:{{{section|}}}|section|article}}}} by removing the unnecessary details.</small>
</div>
</pre>


====Support====
<div class="notice-template maintenance" style="background:#9CF;border:1px solid #000">
#{{User|M&SG}} - Per my proposal.
It has been requested that this article be '''rewritten''' to have content '''removed''' for the following reason(s):<br><small>Please review the [[MarioWiki:Manual of Style|Manual of Style]] and [[MarioWiki:Good writing|good writing standards]] and help {{plain link|{{fullurl:{{FULLPAGENAME}}|action=edit}}|improve this article}} by removing the unnecessary details.</small>
#{{User|Supremo78}} - As I hear a lot, we strive to make this wiki better and better, and if images that don't make the wiki look well, it brings down the wiki's quality. Sometimes it's just better to leave small things alone to make bigger things better.
</div>
#{{User|Mario4Ever}} Per proposal.
#{{User|Reddragon19k}} Per all!
#{{User|Yoshiwaker}} - I recall some images, such as the Black Mage artwork, looking better without transparency. Per all.
#{{User|Fawfulfury65}} Adding transparency ruins the image. Per proposal.
#{{user|SWFlash}} ''"If the artworks are JPEGs, upload them as JPEGs."'' PNG. Even if not transparent, always upload PNG.
#{{user|Coincollector}} - Per proposer. Actually I don't see the necessity to converse JPEG files into PNG: there is no real difference in a picture when converting a JPEG into PNG, and the transparency thing is more of an excuse to say that the PNG is better than JPEG, never noticing the size of the picture wich is a lot heavier in PNG files. This is one of the various causes that retouching official artworks really bothers me. That and the user's less knowledge about a in-game model and a (very bad) cropped screenshot.
#{{User|Rise Up Above It}} Per all.
#{{User|Goomba's Shoe15}} Per all i don't like the way transparent images look anyways
#{{User|Dr Javelin}} As far as I can tell, transparency doesn't need to be added and makes many images look terrible. Per all.
#{{User|Magikrazy51}} Per UhHuhAlrightDaisy who tried to rid the Black Mage artwork of transparency (sorry Ultramario, but <s>our princess is in another castle</s> transparency isn't always better). Also per everyone else who supports this proposal.
#{{User|Superfiremario}} Okay, I get this now. Your saying you want ''bad'' transparency removed, right? I support now. If you didn't see [[User:M&SG/proposal|this]] you should.
#{{User|Gigaremo}} Per all. If transparency makes some images look bad, then it should be removed on those images.
#{{User|Xzelion}} &ndash; Per all.
#{{User|MarioMaster15}} Per all.
#{{User|Goomblob}} The wiki needs of good and striking images.
#{{User|Boowhoplaysgames}} Per all, and, who the hayfidget thought of making transparency for the Mario Sports Mix anyway? the shadows of them make one '''''know''''' that they shouldn't make transparency. leaving white in for thee shadows to be shown is just goofy, and puts this wiki [to me] to shame.[“why, why must this wiki have good info with bad quality?”]
#{{User|Shadow34}} &ndash; Per all!
#{{User|BabyLuigiOnFire}} What we're proposing is that we delete images of bad quality, not remove it all together! Most of the opposers misunderstood this proposal. And I completely agree with this proposal. If it looks crappy, it's better if it's not transparent.
#{{User|Petergriffin555}}Per all.
#{{User|Plumber}} &mdash; The artwork should be uploaded in the way it originally was uploaded.
#{{User|Baby Mario Bloops}} &ndash; Gonna say what I can pretty much sum up to be the case here for many opposers. "It is not about making all PNG's into JPG's, but actually have good PNG's!!!!"
#{{User|Super Mario Bros.}} &ndash; We should not alter official artwork in any way. Per proposal.
#{{User|Cleanup Guy}} - Per all..


====Oppose====
This should fix some things, and I also recommend you change the title or at least context of this proposal. If so, then I might change my vote. [[User:Altendo|Al]][[User talk:Altendo|ten]][[Special:Contributions/Altendo|do]] 19:58, December 9, 2024 (EST)
#{{User|UltraMario3000}} I disagree with this proposal as PNGs are usually better then JPGs and the conversion from JPG to PNG is rather good because the images that I did in that way always looked more clear quality-wise.
:I {{plain link|https://www.mariowiki.com/index.php?title=MarioWiki:Proposals&diff=prev&oldid=4457576|fixed this problem}} for you. How does it look? {{User:GuntherBayBeee/sig}} 09:40, December 10, 2024 (EST)
#{{User|Zero777}} Per UM3000 and comment below. Just let users have the freedom to do whatever they want with the image as long it will look good on and make the article better in quality.
#{{User|SKmarioman}} Per UltraMario3000.
#{{User|YoshiGo99}} Per all.
#{{User|BoygeyDude}} Per all. JPGs (JPEGs) are a little crappy compared to PNGs.
#{{User|Mario Bros.!}} Per UltrMario3000,
#{{User|DKPetey99}} Per UM3000.
#{{User|Mariomario64}} &ndash; Per all.
#{{User|Smasher 101}} Per UltraMario
#{{User|New Super Mario}} Per UM
#{{User|Hypnotoad}} Per all, and as someone who works with these images, I find PNG images easier to use, and maintain a better quality post-process.
#{{User|Koopa K}} Per all.<br><s>#{{User|Arend}} What the heck, you want to get rid of all the transparent PNGs because they ''get a checkered background when you're viewing them in their file page''? That's ridiculous. Per all.</s>
#{{User|Mario Fan 123}} Per all and Arend. This community is sort of annoying sometimes, when they make dumb proposals 'because transparent images look ugly'. Come on, transparent PNGs are way better than plain white background JPGs! And some of the JPG images come with a background, so that's annoying too.
#{{User|MrConcreteDonkey}} - Per all, especially Arend.
#{{User|Not Bugsy}} Per all, and also, PNGs are good for saving space and keeping quality. You can compress them fine without losing quality, but if you compress JPGs, you get artifacts which lower image clarity.
#{{User|Yoshidude99}} Per all.
#{{User|Kingbowser99}} Per all.
#{{User|Bowser Jr And Tom The Atum}} I'm neutral. JPG is horrendous, while PNG is amazing. JPG does not work with transparency, so... I'm just doing it here to make it tied on votes.
#{{User|Super Luigi! Number one!}} JPEGs are for photographs and realistic images. PNGs are for line art, text-heavy images, and images with few colors.Btw, We can "correct" the bad images, making it completly tranparent.
#{{User|EctoBiologist}} I was joking. and yes I oppose this. >>


====Comments====
===Decide what to do with Template:Move infobox===
Recently I've been working with PNG sprite images with white backgrounds that are unnecessary and removing them and reuploading it. I haven't done anything with JPEGs. That's ok, right? {{User|Bowser's luma}}
A while ago (November 4th, specifically), I created [[Template:Move infobox]]. After all, we had templates for essentially all the Browse tabs on the wiki sidebar, except for moves. There WERE templates about specific types of moves, such as [[Template:M&L attack infobox]], but no general template in the same vein as items, characters, species, games, locations, etc.  
:I think the proposal is saying that we should stop making non-transparent images transparent because if you put them behind a background that is a color other than white, you can still see some of the white around the picture. {{User|Fawfulfury65}}
::I don't understand the difference between a JPEG a PNG or transparency all i ever see are pictures {{User|Goomba's Shoe15}}
:::JPEG and PNG are popular image file formats. PNGs are more easily modifiable than JPEGs in a software such as Fireworks or Photoshop. Most images have backgrounds (generally white), and people can use software to remove them (an image without a background is considered transparent). It can be useful at times, but it is not always done perfectly. Usually, the software will remove most of a background using a tool, leaving the user to remove the rest manually, sometimes pixel-by-pixel depending on the quality wanted. The problem is that it can be a tedious process depending on the size of the image and the quantity of background to be removed, so some of it is likely to remain either unnoticed or unattended. On a white background (or one colored identically to the image background), there's no problem, but other backgrounds reveal these unnoticed or unattended portions and make the image, and by extension, the wiki, look unprofessional. {{User|Mario4Ever}}
:::::I'm really confused on this still. Can you give a few examples to really clear this up? {{User|Baby Mario Bloops}}
::::::This image [[File:TrSuper mushroom.jpg|100px]] has a background (all of the space surrounding the trophy), while this image [[File:MarioNSMBWii.PNG|100px]] is transparent (all transparent images have that checkered "background" you see when clicking on it). {{User|Mario4Ever}}
UM: No, the proposer is talking about the bad quality transparent images, not all of the transparent images. {{User|BabyLuigiOnFire}}


I can see where some people are going by replacing JPEG artworks with PNG artworks.  However, if the PNG artworks do not have a transparent background, you should upload them just like that.  If a PNG artwork has transparency already when you download it, odds are, it'll probably look good on any kind of background.  If that truly is the case, that kind of artwork image can be uploaded; Ex.: [[File:MASATLOG_Tails.png|100x100px]]; when I found that image, it already had an Alpha Layer, and it looked good on a black background.  Basically, by normal standards, quality > transparency, and transparency should only be implemented if it looks good. - {{User|M&SG}}
I discussed it on the Discord briefly, nobody said no, and a bit of feedback later about how it should look and what it should have, I created it. It has since been applied to exactly four pages at the time of writing, half of which I was the one to apply it to. In hindsight, this could've used with a proposal instead of me just making it, so here's a belated one.
:I have noticed that some users don't know how to keep the quality when changing it to a transparent image. When they upload the image it is smaller than the JPEG file was and so some users who know how to keep the quality and have it transparent have to fix the image. Also JPEG files has little dots that are hard to see that surround the image and they blend in with the white. We don't want to see that because it makes the image look like it has bad quality and that is probably why we make images transparent. - {{User|YoshiGo99}}
::Regardless, if the original artwork doesn't have transparency, do not alter it.  At times, adding transparency to artwork will make it look much worse, due to the pixelated edges that can be seen.  I learned that the hard way when I modified some ''Mario Super Sluggers'' artworks. - {{User|M&SG}}


'''@UltraMario3000:''' He's not saying that we shouldn't convert from JPG to PNG, but that if someone does that, they shouldn't make it transparent. {{User|Yoshiwaker}}
Should we keep '''Template:Move infobox''' around? If we do keep it, is it good as is, or does it need changes?


'''@Yoshiwaker:''' I don't see what's wrong with making it transparent though.:/--{{User|UltraMario3000}}
'''Proposer''': {{User|EvieMaybe}}<br>
:Take an image and put it behind a black background. You'll see. {{User|Xzelion}}
'''Deadline''': January 1st, 2025, 23:59 GMT
::I don't get what you're trying to say Xze.--{{User|UltraMario3000}}
:::Look [[User:Xzelion/test|here]]. {{User|Xzelion}}


We should upload all artworks as PNG, because when JPG pictures are rescaled (&#91;[File:Example.jpg|''200px'']]), the they become very artifacted. {{user|SWFlash}}
====Keep Move infobox, as is====
:Most artworks that can be found on gaming websites are JPEGs however.  Besides, you shouldn't replace an HQ JPEG image with a low quality PNG image. {{User|M&SG}}
#{{User|Sparks}} I can see this template working really well for moves that aren't in every ''Mario'' game, like [[Spin]]. This has lots of potential!
#{{User|Nintendo101}} Per proposal.
#{{User|Camwoodstock}} We don't see why not--having a dedicated Moves infobox could come in handy, especially if we get any more Mario RPGs in the wake of the weird little renaissance period we've been getting with the back-to-back-to-back SMRPG remake, TTYD remake, and release of Brothership. Per proposal.
#{{User|Pseudo}} Per proposal.
#{{User|Technetium}} Per proposal.
#{{User|Salmancer}} It would bring more attention to our move pages. I'm down for that.


@Goomba's Shoe15: This proposal only applies to bad quality transparency artworks.  Artworks such as the one that Xzelion showed would not be affected, since those artworks already had transparency implemented before being uploaded; artworks that already have transparency usually tend to look good on any background color.  {{User|M&SG}}
====Keep Move infobox, but with changes====
:I know that {{User|Goomba's Shoe15}}


@M&SG Did I say anything about quantity? Also, PNG is lossless, if you didn't notice it. {{user|SWFlash}}
====Delete Move infobox====
:I didn't say quantity.  Also, I didn't say that you shouldn't replace JPEG artworks with PNG artworks.  You can still do that, but if the PNG artworks have no transparency, don't make them transparent. {{User|M&SG}}


Just in case the proposal deadline has to be extended, please refer to [[User:M&SG/proposal|here]] for some examples of acceptable transparency and unacceptable transparency. {{User|M&SG}}
====Move infobox Comments====
Considering the nature of the attack infoboxes, wouldn't it be weird to have moves all in purple but a Mario & Luigi attack use yellow and green and a Paper Mario attack use white and green? Should there be variants of the Move infobox to match the color schemes of existing templates? If an article is covering multiple related moves, how will the infobox work? (ex. [[Handstand]], [[Cap Throw]], [[Roll]], [[Slide Kick]]... there's more of these than I thought). What happens when a move is referenced in somewhat less "move-y" ways? Okay, that last one is kinda strange, but basically I mean "dashing" in Super Mario Run is just a fancy animation, Mario & Luigi Dream Team has an animation where Giant Luigi crouches (with posing and skidding clearly meant to be a platformer callback), to slide under an attack. Do these instances get incorporated into the infobox? Continuing the train of thought, what about sports games? Yoshi can Flutter Jump as his special action on Mario & Sonic games. Does that count as a method of input for a Flutter Jump? [[User:Salmancer|Salmancer]] ([[User talk:Salmancer|talk]]) 21:35, December 19, 2024 (EST)
:that's a lot of very interesting questions!
:*i went with purple to set it apart from the already taken light red (game), green and white (character), blue (level), pink (location), grey (item) and navy/grey (species) infoboxes. changing the color could be a good idea.
:*as for sorting which moves "count" or not, we have to decide these things for other types of subject too, after all, and they get infoboxes. it's a valid concern, though! {{User:EvieMaybe/sig}} 15:09, December 20, 2024 (EST)


@Arend: You're missing the point.  This proposal only applies to artworks that have bad transparency.  Please look at my examples, and you'll clearly get the picture. {{User|M&SG}}


@Mario Fan 123: Well it's one thing when you have a white background, but when you put the image on a black background, that's when you'll notice how poorly done the transparency is. {{User|M&SG}}


<s>Okay, basically  you want to remove transparency?</s> Guys, they're saying they want bad transpaprensy removed.
{{User|Superfiremario}}
'''@Mario Bros.! I'm supporting now.''' {{User|Superfiremario}}


@Zero's vote: Most of these "transparent" images ''don't'' look good on articles{{User|Superfiremario}}
===Allow blank votes and reclassify them as "per all"===
There are times when users have nothing else to add and agree with the rest of the points. Sure, they can type "per all", but wouldn't it be easier to not to have to do this?


I'd like to point out a png image with awful transparency which should be used as an example for this proposal. Alas, I don't know the file name, but I know the image. It's the Galaxy Airship artwork that was ripped from the boss poster. The image looks fine on a white background, but put against a black background or save it to your computer and open it in MSPaint and it reveals how horrendous the transparency is. {{User|Rise Up Above It}}
Yeah sure, if the first oppose vote is just blank for no reason, that'll be strange, but again, it wouldn't be any more strange with the same vote's having "per all" as a reasoning. I've never seen users cast these kinds of votes in bad faith, as we already have rules in place to zap obviously bad faith votes.


IDK, but I'll show directly some examples from MS&G's page to coroborate the problems. Maybe many of you misunderstood this proposal. This is not to kill PNG as many of you think, it's to get rid '''badly edited or cropped pictures''' that they turned out be of worse quality than their originals (regardless they were JPEG or PNG or whatever). In a few words, pictures, like artworks '''Shouldn't be edited'''.
This proposal wouldn't really change how people vote, only that they shouldn't have to be compelled to type the worthless "per all" on their votes.


The chart shows the bad-edited pictures set in a black background, this problem can be seen in any colored bg but white or some white-based color.
'''Proposer''': {{User|Mario}}<br>
'''Deadline''': January 1, 2025, 23:59 GMT


{| style="background:#000000;"
====Blank support====
|[[File:MSMart5.png|260px|center]]
#{{User|Mario}} Per all.
|[[File:BowserKartWii.png|260px|center]]
#{{User|Ray Trace}} Casting a vote in a side is literally an action of endorsement of a side. We don't need to add verbal confirmation to this either.
|[[File:Bowsersmg2.png|260px|center]]
#{{User|PopitTart}} <small>(This vote is left blank to note that I support this option but any commentary I could add would be redundant.)</small>
|[[File:BlackMagesportsmix.png|center]]
#{{User|Altendo}} <small>(Look at the code for my reasoning)</small><!---It might not seem annoying, but over time, or answering multiple proposals at once, it can start putting stress. Copy-pasting can be done, but it is just much easier to not type anything at all.---->
|}
#{{User|FanOfYoshi}}
#{{User|OmegaRuby}} While on the outset it may seem strange to see a large number of votes where people say "per all" and leave, it's important to understand that the decision was made because the user either outright agrees with the entire premise of the proposal, or has read discussion and points on both sides and agrees more with the points made by the side they choose. And if they really ''are'' just mindlessly voting "per all" on proposals with no second thought, we can't police that at ''all.'' <small>(Doing so would border on FBI-agent-tech-magic silliness and would also be extremely invading...)</small> <!---Silent per all.---->
#{{User|Shy Guy on Wheels}} I've always thought of not allowing blank votes to be a bit of a silly rule, when it can so easily be circumvented by typing two words. I think it's better to assume good faith with voting and just let people not write if they don't have anything to add, it's not as if random IPs are able to vote on this page.
#{{user|TheDarkStar}} - Dunno why I have to say something if I agree with an idea but someone's already said what I'm thinking. A vote is a vote, imo.
#{{user|Ninja Squid}} Per proposal.
#{{User|Tails777}} It's not like we're outright telling people not to say "Per all", it's just a means of saying you don't have to. If the proposal in question is so straight forward that nothing else can be said other than "Per proposal/Per all", it's basically the same as saying nothing at all. It's just a silent agreement. Even so, if people DO support a specific person's vote, they can still just "Per [Insert user's name here]". I see no problem with letting people have blank votes, especially if it's optional to do so in the first place.


It's possible to converse JPEGs into PNG but '''never edit them''' unless it needs so and in this case must be '''well-crafted''', not like this. This is becoming in a trend by many user and shouldn't be atually in the Mariowiki, so think twice before taking a decent decision.  
====Blank Oppose====
#{{user|Doc von Schmeltwick}} - Honestly? I'd prefer to get rid of "per all" votes since they're primarily used for the "I don't/like this idea" type of thing that has historically been discouraged. If you don't care enough to explain, you don't care enough to cast IMO.
#{{User|Technetium}} I don't think typing "per all" is that much of an annoyance (it's only two words), and I like clearly seeing why people are voting (for instance, I do see a difference between "per proposal" and "per all" - "per all" implies agreeing with the comments, too). I just don't think this is something that needs changing, not to mention the potential confusion blank votes could cause.
#{{User|Camwoodstock}} Maybe we're a little petty, but we prefer a "per all" vote to a blank one, even if "per all" is effectively used as a non-answer, because it still requires that someone ''does'' provide an answer, even if it's just to effectively say "ditto". You know what to expect with a "per all" vote--you don't really get that information with a fully blank vote.
#{{User|Ahemtoday}} {{color|white|Forgive me for the gimmicky formatting, but I want to make a point here — when you see a blank oppositional vote, it's disheartening, isn't it? Of course, it's always going to be that way when someone's voting against you, but when it doesn't come with any other thoughts, then you can't at all address it, debate it, take it into account — nothing. This also applies to supporting votes, if it's for a proposal you oppose. Of course, this is an issue with "per all" votes as well. I don't know if I'd go as far as Doc would on that, but if there's going to be these kinds of non-discussion-generating votes, they can at least be bothered to type ''two words''.}}
#{{User|Jdtendo}} Per all <small>(is it too much to ask to type just two words to explicitely express that you agree with the above votes?)</small>
#{{User|Axii}} Requiring people to state their reason for agreeing or disagreeing with a proposal leads to unnecessary repetition (in response to Doc). Letting people type nothing doesn't help us understand which arguments they agreed with when deciding what to vote for. The proposer? Other people who voted? Someone in particular, maybe? Maybe everyone except the proposer? It's crucial to know which arguments were the most convincing to people.
#{{User|Pseudo}} Per Technetium, Camwoodstock, and Axii.
#{{User|Hooded Pitohui}} I admit this vote is based on personal preference as any defensible reasoning. To build on Camwoodstock and Ahemtoday's points, though, the way I see it, "per all" at least provides ''some'' insight into what has persuaded a voter, if only the bare minimum. "Per all" is distinct at least from "per proposal", suggesting another voter has persuaded them where the original proposal did not by itself. A blank vote would not provide even that distinction.
#{{User|Mister Wu}} Asking for even a minimal input from the user as to why they are voting is fundamental, it tells us what were the compelling points that led to a choice or the other. It can also aid the voters in clarifying to themselves what they're agreeing with. Also worth noting that the new editors simply can't know that blank means "per all", even if we put it at the beginning of this page, because new editors simply don't know the internal organization of the wiki. Blank votes would inevitably be used inappropriately, and not in bad faith.
#{{user|DesaMatt}} Per all and per everyone and per everything. Per.


{{User|Coincollector}}
====Blank Comments====
I don't think banning "per all" or "per proposal" is feasible nor recommended. People literally sometimes have nothing else to add; they agree with the points being made, so they cast a vote. They don't need to waste keystrokes reiterating points. My proposal is aiming to just streamline that thought process and also save them some keystrokes. {{User:Mario/sig}} 20:34, December 17, 2024 (EST)
:I think every sort of vote (on every level, on every medium) should be written-in regardless of whether something has been said already or not; it demonstrates the level of understanding and investment for the issue at hand, which in my opinion should be prerequisite to voting on any issue. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 20:53, December 17, 2024 (EST)
::There is no way to actually determine this: we are not going to test voters or commenters their understanding of the subject. Someone can read all of the arguments and still just vote for a side because there's no need to reiterate a position that they already agree with. {{User:Ray Trace/sig}} 20:55, December 17, 2024 (EST)
:::My personal belief is that "test[ing] voters or commenters their understanding of the subject" is exactly what should be done to avoid votes cast in misunderstanding or outright bandwagoning. [[User:Doc von Schmeltwick|Doc von Schmeltwick]] ([[User talk:Doc von Schmeltwick|talk]]) 23:06, December 17, 2024 (EST)
::::My personal view is that a change like the one you are suggesting potentially increases the  odds of inexperienced or new users feeling too intimidated to participate because they feel like they do not have well articulated stances, which would be terrible. I think concerns about "bandwagoning" are overstated. However, more pressingly, this proposal is not even about this concept and it is not even one of the voting options, so I recommend saving this idea for another day. - [[User:Nintendo101|Nintendo101]] ([[User talk:Nintendo101|talk]]) 23:32, December 17, 2024 (EST)
:{{@|Mario}} I agree. Banning people from saying that in proposals is restricting others from exercising their right to cast a vote in a system that was designed for user input of any time. I'd strongly oppose any measure to ban "per" statements in proposals. [[User:Super Mario RPG|Super Mario RPG]] ([[User talk:Super Mario RPG|talk]]) 00:11, December 18, 2024 (EST)


'''@All Opposers''' What M&SG is trying to say is that we need to remove the transparency from the images that look bad on a different color background than white. Jusy look at the pictures above. The look crappy in a black background.
Technetium: I understand, but blank votes are a fairly common practice in other wikis, and it's clearly understood that the user is supporting the proposal in general. {{User:Mario/sig}} 20:36, December 17, 2024 (EST)
{{User|Supremo78}}
:Fair point, I didn't know that. Not changing my vote just yet, but I'll keep this in mind as the proposal continues. [[User:Technetium|Technetium]] ([[User talk:Technetium|talk]]) 20:48, December 17, 2024 (EST)
:Well, just like Supremo above, I don't think it means ALL jpg to png images are really going to be undone, as I know many of them that are amazing that had that happened. I think that the proposal is just to have some quality better. I really don't understand why a jpg image is just tossed out there like it is trash when many amazing images have been uploaded by jpg. Png's might be really good as well, but if you try to put a jpg into a png and it doesn't work out, then you might as well just leave it as in instead of trying to continue with what you are doing. But...I still am trying to decide which side I should support, because I can see it - through the opposers' eyes - as to why this shouldn't pass as well, and what the outcome of all this change could lead to. {{User|Baby Mario Bloops}}
:There's a lot of variation in how other wikis do it. WiKirby, for example, doesn't even allow "per" votes last I checked. {{User:Hewer/sig}} 04:13, December 18, 2024 (EST)


@ Bowser Jr And Tom The Atum: You don't get the point. This proposal, again, '''this is not to remove PNG images, nor saying that JPEG is better than PNG nor something''', this proposal is to stop users that believe they can edit or make certain pictures transparent without noticing important details like the chart shown above. Don't think you're becoming experts on this... {{user|Coincollector}}
I'm not really much of a voter, but I'm of the opinion "it's the principle of the matter". Requiring ''a'' written opinion, of any kind, at least encourages a consideration of the topic. [[User:Salmancer|Salmancer]] ([[User talk:Salmancer|talk]]) 21:35, December 19, 2024 (EST)


===Set Vector-2010 to the default wiki skin===
This proposal is about setting the 2010 [[mw:Skin:Vector|Vector]] as the default wiki skin ([https://web.archive.org/web/20160207064154/https://upload.wikimedia.org/wikipedia/foundation/4/44/Logo_new-vector_screenshot.png screenshot here]) for desktop users, with the focus being on people who are new to wikis in particular, while obviously keeping the existing MonoBook skin as an option. What made me think to create this proposal is when I made a [[Talk:Main Page]] proposal about the to-do list tasks and how they are more accessible than clicking the "Wiki maintenance" on the sidebar, I had to uncomfortably squint to find "Wiki maintenance" on the wiki sidebar. But Vector-2010 has the sidebar links slightly larger and a bit more spaced out. With the existing interface, there could be some who may struggle to find options listed on the sidebar.


Okay, I see now what the whole purpose is. You want to delete the PNG's with bad quality of transparency. That is kinda okay, but here comes my opinion. You see, it is kinda good when we're talking about the ones that have some effects that have less to no hardness (like shadows of some people, or fur standing upright, or even fire). However, I think it doesn't make sense at all to delete those of bad quality with 100% hardness (so, for example, no shadows & stuff, no fur standing upright, no fire). An experienced converter or transparency maker could easily take the original file and make the file better transparent. If you don't get what I mean, take a look at these blue dots (the upper ones have no hardness, and the lower ones have a hardness of 100%):<br>
While we're clearly different from Wikipedia (that's why I'm not Vector-2022, since it'd be too much of a departure and likely uncomfortable for several), I do want to refer to [http://web.archive.org/web/20180213165624/https://blog.wikimedia.org/2010/05/13/a-new-look-for-wikipedia/ this page], which summarizes why Wikipedia transitioned to it. Though it is vague, they cite accessibility as the reason, which I think this wiki has been taking steps toward doing.
{| style="background:#000000;"
|http://img834.imageshack.us/img834/4282/examplefd.png
|}<br>
See what I mean? The blue dot with 100% hardness has it's background completely removed, and there's almost no sign of white pixels left around, while there is a whole bunch of white left at the blue dot with no hardness. As with the middle two in the earlier example, it's transparency ''could'' be better. Seeing the Black Mage at the right, that one could also be done better (seriously, there are pixels left behind that ''don't even belong'' to the artwork), but it has a shadow, so we therefor have to wait for an official release of the artwork with no background (though I, unfortunately, think it will never come).<br>So, what I want is that most artwork that has no background nor hardness-less things, such as shadows, should have another re-upload, with original file, with the background removed, making it looking more polished than it first was.<br>{{User|Arend}} - I see, btw, that ''all the examples above'', have at least been upoaded by UltraMario3000 as the latest revision. I suggest for him that he needs a (better) program that removes the background easily, and/or that, if he uses a Magic Wand tool, that he should increase its tolerance, but not too much. Testing the tolerance is always good, too.


:@ Arend: There is no problem to upload high quality transparent images, specially those that are 2D artwork that have plain effects and the tolerance is reliable. The problem comes when you ''try'' to make the artwork transparent. If you find  a picture with no transparency, keep the image unaltered. If you find a transparent image of quality (of tolerable size, not too smaller than the original and the alpha is smooth) keep the image unaltered. If you find or '''make''' a transparent image and has bad quality in transparency and the alpha is not smooth, then undo it. By the way, just a 2D artwork is transparent doesn't mean will be 100% good: [http://www.mariowiki.com/File:Wmage.PNG For example, look at the history here] {{User|Coincollector}}
I'll cite my reasons for preferring Vector and applying this to possible people who are visiting a wiki for the first time. The text is larger, which is especially important for larger screen monitors, some of the lesser used tabs are collapsible on the sidebar, summarizing the most commonly used options, and the user links at the top right are also more noticeable and less close to the body of the article where the content is read.
::@Coincollector: I actually meant ''all'' art, not just 2D. I thought anyone would get it, then someone thinks I only talked about 2D, though I never said it was about 2D. I only used a simple example.<br>Anyways, people who make things transparent can ''try'' to make things transparent, but should <u>not</u> ''save'' directly. They first need to ''test'' the transparency, by adding, for example, a black background as a new layer, if possible. If the art's transparency's not good (enough), they have to ''undo'' the action of making it transparent, ''change'' the tolerance, ''select'' the unwanted things, and try it again. Then they have to test it again, and, if needed, repeat the whole thing, until it is finally good enough.<br>About the 2D art you showed me, it is because the uploader (who seems to be the same person who uploaded the LQ transparency pics above), did not care about the tolerance. Eventually, he should resize the picture a little to make the black lines smoother. To keep a higher quality, shrinking is suggested.<br>I think you skimmed my whole lecture-thing (or whatever it could be described the best) and thought I talked about that transparent 2D art is always good quality, but I never said that. {{User|Arend}}
:::@ Arend: I see your point and is right. In fact you've expandend one of my statements in bold of the comment with the pictures. I have other things to support this. As you said, making a transparent image requires much more time than somebody can think. You may get a whole day dealing with a single image to make it ransparent, testing how will look and undoing it over 100 times if there is a noticeable mistake. The thing gets more complicated when you're playing with the alpha where the colors blend with the background (if you don't what alpha is, is the opacity's bearing of every pixel in a picture, for example the diffuse blue in black bg). Some of the pics above have alpha that the user overlooked and left them in white patches, which makes these pictures unsettling when you look over a background of another color... even more, the white's presence and that dithering ruin the pictures' aesthetics. As I said, the pictures should remain unaltered if they don't need. Making oneself a picture transparent is not easy actually and, these are the mistakes that one can get if they don't this work in a professional way: if you'll do it, do it well and if you didn't well, undo it. Consider my last comment but one as a consequence of this explanation. Also, there are more tools to use than a "magic wand" {{user|Coincollector}}


@Super Luigi! Number One!: Do you know how in the simplest way? It's not an easy task as you think. Requires trial and error to get the best quality.
Though it could take time getting used to the Edit button being on the right (not to mention the search button), the button is at least larger, making it more usable on even lower quality screen monitors, and I like how it's separate from the Page and discussion options, meaning that options that involve viewing articles are on the left while options that involve editing or changing the page in some form are on the right.


==Miscellaneous==
If this proposal passes and others don't like the change, they can always return to the MonoBook option in their [[Special:Preferences#mw-prefsection-rendering|preferences]].
===Merge the non-game lists on the side bar with the video game lists===
I find it very weird that this wiki considers the non-game elements canon but still keeps them separate on the side bar so i think we should merge the two lists together because if everything is official/canon than they should be on the same list. Because right now the two lists separates the game and non-game elements on these lists and i don't think we should do that. Plus we already merged all of the non-game categories so i think it only makes sense to merge the lists two


'''Proposer''': {{User|Goomba's Shoe15}}<br>
'''Proposer''': {{User|Super Mario RPG}}<br>
'''Deadline''': July 14, 2011, 23:59
'''Deadline''': January 1, 2025, 23:59 GMT


====Support====
====Support====
#{{User|Goomba's Shoe15}} per my proposal and consistency also i am sorry if you can't understand what i'm proposing due to my grammar.
#{{User|Super Mario RPG}} Per.
#{{User|Reddragon19k}} Per GS15!
#{{User|Koopa K}} Per GS15
#{{User|BoygeyDude}} Per all.
#{{User|Supremo78}} Ah now I understand. Per proposal.
#{{User|Superfiremario}} I get it.
#{{User|Super Mario Bros.}} &ndash; Yes. Our wiki establishes games and other media as being equal in how we should cover it and not being in separate canons. So it would make sense for us to merge these lists. Per proposal.
#{{User|Walkazo}} - See my comment on the series proposal above. Having one list is best since you can find everything in one place and it's all equal and whatnot, but I also think we should use symbols to differentiate the various series and the alternate media within that unified list. The more organization, the better.


====Oppose====
====Oppose====
#{{User|Camwoodstock}} Admittedly, this vote is largely a matter of preference--we just don't like Vector that much--but we can't think of any real reason to switch to Vector 2010 as the default over the current Monobook beyond the mentioned text spacing; while that is a nice boon, we personally find the weird gradient buttons for the various tabs up top a little grating looking, and we're a fan of the more compact design that Monobook provides--though, this is likely a byproduct of our personal preference for more neatly packed web design. And uh, the less said about the other two options (Vector 2022, and. Timeless. <s>Which is the most dated theme possible, namely to mid-2010s mobile web design.</s>), the better. If you like Vector 2010, that's great, and we're fine with that! Heck, if anyone likes Vector 2022 or Timeless, that's cool too, and more power to them! Variety is the spice of life, after all. But switching it to the default is something that should not be taken lightly, and the reasons for a switch in this proposal feel a little too loosey-goosey for us, we're sorry.
#{{User|DryBonesBandit}} Per Camwoodstock.
#{{User|Nintendo101}} I like how MonoBook looks a little more than Vector. It is what I am comfortable with. If it ain't broke, don't fix it.
#{{User|Drago}} Per Nintendo101. I actually prefer the smaller text of Monobook since you can see more of the page at once. I also want to point out that although logged-in users like us can change the skin in preferences, we'd still be forcing the change on logged-out users.
#{{User|Ahemtoday}} Per Drago.
#{{User|Technetium}} Per Nintendo101 and Drago. I just don't see any reason to make this change.
#{{User|Altendo}} I'm saying this as a Vector-2010 skin user, and I'll say that people have their preferences. I live Vector-2010 because that is how Wikipedia at least used to look before they switched to Vector (2022); On Wikipedia, Vector was renamed to Vector legacy (2010), while Vector 2022 is named Vector (2022). Although I do prefer Vector-2010, I know a lot of people that prefer Monobook, and even if not, this can be changed in the preferences. No need to change the default skin. I get that IPs can't change their appearance, but aside from that, users can, and what they see doesn't have to be default on the wiki. Everyone can change what they specifically see.


====Comments====
====Comments====
Sorry, but I don't get what you are saying. {{User|Zero777}}
{{@|Camwoodstock}} That is true that it's a major change. It's based mainly upon impression from newcomers from them seeing a more prominent edit tab, slightly larger text size, and other minor details like tab names that are easier to read (including a collapsible feature for the lesser used tab). The skin change was based on old Wikipedia research at the time (like how WikiLove was a result of their research). I have no strong feelings whether this passes or not. Although it's vague, since there's no way to tell the statistics (and the wiki's already successful at the moment), I still have a feeling it could help some, but to each their own. [[User:Super Mario RPG|Super Mario RPG]] ([[User talk:Super Mario RPG|talk]]) 18:32, December 18, 2024 (EST)
:We feel like if anybody would be capable of providing any statistics on skin usage, it'd be Porple, but even then, we don't actually know if that's one of the things he tracks, and it feels a little silly to pester him over this of all things... ;p {{User:Camwoodstock/sig}} 18:55, December 18, 2024 (EST)


:Yeah I don't either. {{User|Supremo78}}
I'm okay with opposition, but in case of misunderstanding, this proposal isn't about personal preferences so much as what I believe to be a more ergonomic interface to a wider audience. I know we're not Wikipedia, but there's also the consideration that they've used the Vector skin longer than they had for MonoBook. [[User:Super Mario RPG|Super Mario RPG]] ([[User talk:Super Mario RPG|talk]]) 13:45, December 19, 2024 (EST)
::You see those lists on the side bar well currently there separated into game and non-game i'm proposing we merge them together like we did with the categories {{User|Goomba's Shoe15}}
:If it's what "you believe", then it ultimately (and probably unavoidably) is about personal preferences. Anyway, another consideration is the fact that people often prefer what they're used to. I feel like how long this wiki has used its skin is more relevant than how long Wikipedia has. {{User:Hewer/sig}} 16:39, December 19, 2024 (EST)
:::By "non-game" do you mean beta? Can you please clarify what the non-game stuff is? I don't know what it is. {{User|Supremo78}}
::{{@|Hewer}} I suppose I'm overthinking the ergonomic interface. [[User:Super Mario RPG|Super Mario RPG]] ([[User talk:Super Mario RPG|talk]]) 15:19, December 20, 2024 (EST)
::::Non-game stuff is things from the cartoons and the comics and according to the mario wiki canon policy they are supposed to be on considered on the same level of canon as the games. However, for some reason they are split on the big lists on the side bar and i'm proposing that they be merged together like how the non-game categories and game categories were merged together {{User|Goomba's Shoe15}}
 
==Miscellaneous==
''None at the moment.''

Latest revision as of 17:24, December 28, 2024

Image used as a banner for the Proposals page
Current time:
Sunday, December 29th, 23:42 GMT
Proposals can be new features, the removal of previously-added features that have tired out, or new policies that must be approved via consensus before any action is taken.
  • Voting periods last for two weeks, but can close early or be extended (see below).
  • Any autoconfirmed user can support or oppose, but must have a strong reason for doing so.
  • All proposals must be approved by a majority of voters, including proposals with more than two options.
  • For past proposals, see the proposal archive and the talk page proposal archive.

If you would like to get feedback on an idea before formally proposing it here, you may do so on the proposals talk. For talk page proposals, you can discuss the changes on the talk page itself before creating the TPP there.

How to

If someone has an idea about improving the wiki or managing its community, but feel that they need community approval before acting upon that idea, they may make a proposal about it. They must have a strong argument supporting their idea and be willing to discuss it in detail with other users, who will then vote on whether or not they think the idea should be implemented. Proposals should include links to all relevant pages and writing guidelines. Proposals must include a link to the draft page. Any pages that would be largely affected by the proposal should be marked with {{proposal notice}}.

Rules

  1. Only autoconfirmed users may create or vote on proposals. Anyone is free to comment on proposals (provided that the page's protection level allows them to edit).
  2. Proposals conclude at the end of the day (23:59) two weeks after voting starts (all times GMT).
    • For example, if a proposal is added at any time on Monday, August 1, 2011, the voting starts immediately and the deadline is two weeks later on Monday, August 15, at 23:59 GMT.
  3. Users may vote for more than one option, but they may not vote for every option available.
  4. Every vote should have a strong, sensible reason accompanying it. Agreeing with a previously mentioned reason given by another user is acceptable (including "per" votes), but tangential comments, heavy sarcasm, and other misleading or irrelevant quips are just as invalid as providing no reason at all.
  5. Users who feel that certain votes were cast in bad faith or which truly have no merit can address the votes in the comments section. Users can ask a voter to clarify their position, point out mistakes or flaws in their arguments, or call for the outright removal of the vote if it lacks sufficient reasoning. Users may not remove or alter the content of anyone else's votes. Voters can remove or rewrite their own vote(s) at any time, but the final decision to remove another user's vote lies solely with the wiki staff.
    • Users can also use the comments section to bring up any concerns or mistakes in regards to the proposal itself. In such cases, it's important the proposer addresses any concerns raised as soon as possible. Even if the supporting side might be winning by a wide margin, that should be no reason for such questions to be left unanswered. They may point out any missing details that might have been overlooked by the proposer, so it's a good idea as the proposer to check them frequently to achieve the most accurate outcome possible.
  6. If a user makes a vote and is subsequently blocked for any amount of time, their vote is removed. However, if the block ends before the proposal ends, then the user in question holds the right to re-cast their vote. If a proposer is blocked, their vote is removed and "(blocked)" is added next to their name in the "Proposer:" line of the proposal, which runs until its deadline as normal. If the proposal passes, it falls to the supporters of the idea to enact any changes in a timely manner.
  7. Proposals cannot contradict an already ongoing proposal or overturn the decision of a previous proposal that concluded less than four weeks (28 days) ago.
  8. If one week before a proposal's initial deadline, the first place option is ahead of the second place option by eight or more votes and the first place option has at least 80% approval, then the proposal concludes early. Wiki staff may tag a proposal with "Do not close early" at any time to prevent an early close, if needed.
    • Tag the proposal with {{early notice}} if it is on track for an early close. Use {{proposal check|early=yes}} to perform the check.
  9. Any proposal where none of the options have at least four votes will be extended for another week. If after three extensions, no options have at least four votes, the proposal will be listed as "NO QUORUM." The original proposer then has the option to relist said proposal to generate more discussion.
  10. If a proposal reaches its deadline and there is a tie for first place, then the proposal is extended for another week.
  11. If a proposal reaches its deadline and the first place option is ahead of the second place option by three or more votes, then the first place option must have over 50% approval to win. If the margin is only one or two votes, then the first place option must have at least 60% approval to win. If the required approval threshold is not met, then the proposal is extended for another week.
    • Use {{proposal check}} to automate this calculation; see the template page for usage instructions and examples.
  12. Proposals can be extended a maximum of three times. If a consensus has not been reached by the fourth deadline, then the proposal fails and cannot be re-proposed until at least four weeks after the last deadline.
  13. All proposals are archived. The original proposer must take action accordingly if the outcome of the proposal dictates it. If it requires the help of an administrator, the proposer can ask for that help.
  14. After a proposal passes, it is added to the appropriate list of "unimplemented proposals" below and is removed once it has been sufficiently implemented.
  15. If the wiki staff deem a proposal unnecessary or potentially detrimental to the upkeep of the Super Mario Wiki, they have the right to cancel it at any time.
  16. Proposals can only be rewritten or canceled by their proposer within the first four days of their creation. However, proposers can request that their proposal be canceled by a staff member at any time, provided they have a valid reason for it. Please note that canceled proposals must also be archived.
  17. Unless there is major disagreement about whether certain content should be included, there should not be proposals about creating, expanding, rewriting, or otherwise fixing up pages. To organize efforts about improving articles on neglected or completely missing subjects, try setting up a collaboration thread on the forums.
  18. Proposals cannot be made about promotions and demotions. Staff changes are discussed internally and handled by the bureaucrats.
  19. No joke proposals. Proposals are serious wiki matters and should be handled professionally. Joke proposals will be deleted on sight.
  20. Proposals must have a status quo option (e.g. Oppose, Do nothing) unless the status quo itself violates policy.

Basic proposal formatting

Below is an example of what your proposal must look like. If you are unsure how to set up this format, simply copy the following and paste it into the fitting section. When updating the bracketed variables with actual information, be sure to replace the whole variable including the square brackets, so "[insert info here]" becomes "This is the inserted information" and not "[This is the inserted information]". Proposals presenting multiple alternative courses of action can have more than two voting options, but the objective(s) of each voting option must be clearly defined. Such options should also be kept to a minimum, and if something comes up in the comments, the proposal can be amended as necessary. 

===[insert a title for your proposal here]===
[describe what issue this proposal is about and what changes you think should be made to improve how the wiki handles that issue]

'''Proposer''': {{User|{{subst:REVISIONUSER}}}}<br>
'''Deadline''': {{subst:#time:F j, Y|+2 weeks}}, 23:59 GMT

====[option title (e.g. Support, Option 1)]: [brief summary of option]====
#{{User|{{subst:REVISIONUSER}}}} [make a statement indicating that you support your proposal]

====[option title (e.g. Oppose, Option 2)]: [brief summary of option]====

====Comments ([brief proposal title])====

Autoconfirmed users will now be able to vote on your proposal. Remember that you can vote on your own proposal just like the others.

To vote for an option, just insert #{{User|[your username here]}} at the bottom of the section of your choice. Just don't forget to add a valid reason for your vote behind that tag if you are voting on another user's proposal. If you are voting on your own proposal, you can simply say "Per proposal".

Talk page proposals

Proposals concerning a single page or a limited group of pages are held on the most relevant talk page regarding the matter. All of the above proposal rules also apply to talk page proposals. Place {{TPP}} under the section's header, and once the proposal is over, replace the template with {{settled TPP}}. Proposals dealing with a large amount of splits, merges, or deletions across the wiki should still be held on this page.

All active talk page proposals must be listed below in chronological order (new proposals go at the bottom) using {{TPP discuss}}. Include a brief description of the proposal while also mentioning any pages affected by it, a link to the talk page housing the discussion, and the deadline. If the proposal involves a page that is not yet made, use {{fake link}} to communicate its title in the description. Linking to pages not directly involved in the talk page proposal is not recommended, as it clutters the list with unnecessary links.

List of ongoing talk page proposals

Unimplemented proposals

Proposals

Break alphabetical order in enemy lists to list enemy variants below their base form, EvieMaybe (ended May 21, 2024)
Standardize sectioning for Super Mario series game articles, Nintendo101 (ended July 3, 2024)
^ NOTE: Not yet integrated for the Super Mario Maker titles, Super Mario Run, and Super Mario Bros. Wonder.
Create new sections for gallery pages to cover "unused/pre-release/prototype/etc." graphics separate from the ones that appear in the finalized games, Doc von Schmeltwick (ended September 2, 2024)
Add film and television ratings to Template:Ratings, TheUndescribableGhost (ended October 1, 2024)
Use the classic and classic-link templates when discussing classic courses in Mario Kart Tour, YoYo (ended October 2, 2024)
Clarify coverage of the Super Smash Bros. series, Doc von Schmeltwick (ended October 17, 2024)
Remove all subpage and redirect links from all navigational templates, JanMisali (ended October 31, 2024)
Prioritize MESEN/NEStopia palette for NES sprites and screenshots, Doc von Schmeltwick (ended November 3, 2024)
Stop considering reused voice clips as references (usually), Waluigi Time (ended November 8, 2024)
Allow English names from closed captions, Koopa con Carne (ended November 12, 2024)
^ NOTE: A number of names coming from closed captions are listed here.
Split off the Mario Kart Tour template(s), MightyMario (ended November 24, 2024)
Split major RPG appearances of recurring locations, EvieMaybe (ended December 16, 2024)
Stop integrating templates under the names of planets and areas in the Super Mario Galaxy games, Nintendo101 (ended December 25, 2024)

Talk page proposals

Split all the clothing, Doc von Schmeltwick (ended September 12, 2021)
Split machine parts, Robo-Rabbit, and flag from Super Duel Mode, Doc von Schmeltwick (ended September 30, 2022)
Make bestiary list pages for the Minion Quest and Bowser Jr.'s Journey modes, Doc von Schmeltwick (ended January 11, 2024)
Allow separate articles for Diddy Kong Pilot (2003)'s subjects, Doc von Schmeltwick (ended August 3, 2024)
Create articles for specified special buildings in Super Mario Run, Salmancer (ended November 15, 2024)
Expand and rename List of characters by game to List of characters by first appearance, Hewer (ended November 20, 2024)
Merge False Character and Fighting Polygon/Wireframe/Alloy/Mii Teams into List of Super Smash Bros. series bosses, Doc von Schmeltwick (ended December 2, 2024)
Make changes to List of Smash Taunt characters, Hewer (ended December 27, 2024)

Writing guidelines

None at the moment.

New features

Create a template to direct the user to a game section on the corresponding List of profiles and statistics page

This proposal aims to create a template that directs people to a game section on a Profiles and statistics list page, saving the user the step of having to scroll for it themselves. The reason why I'm proposing this is because as more Super Mario games are released, it becomes harder to comfortably find what you're searching for in the corresponding List of profiles and statistics page, especially for Mario, Bowser, and many other recurring subjects.

Another reason I think this would be valid is because of the fact that listing statistics in prose (e.g. 2/10 or 2 out of 10) looks off, especially if that can already be seen in the corresponding statistics box; in that case, the prose could change from "2/10" to something more vague like "very low stat", which isn't typically worded as such in the statistics box.

For example, let's say for Luigi in his appearance in Mario Sports Superstars, there could be a disclaimer either below the section heading or in a box to the side (we can decide the specifics when the proposal passes) that informs the reader that there's corresponding section that shows his profiles/statistics corresponding. Like such:

For profiles and statistics of Luigi in Mario Sports Superstars, see here.

The above message is not necessarily the final result (just a given example), but the disclaimer would definitely point the user to the appropriate game section on the profiles and statistics list page, should this pass.

Proposer: Super Mario RPG (talk)
Deadline: January 1, 2025, 23:59 GMT

Support

  1. Super Mario RPG (talk) Per.
  2. Hewer (talk) I don't really see a need to deliberately make prose less specific, but otherwise I like this idea, per proposal.

Oppose

Comments

@Hewer I don't think this would necessarily eliminate cases in which statistics are in prose, but it may be redundant if there's the link to conveniently access the statistics or profiles. Super Mario RPG (talk) 15:15, December 18, 2024 (EST)

Split image categories into separate ones for assets, screenshots, and artwork

This proposal will address the bloat some image categories have and make them easier to navigate.

Why is this useful? It makes adding to galleries or finding images to replace much easier. If you want to retake screenshots from a game, you can go to the screenshots category to find them. If you have sprite rips to replace, there's a category for that. The same goes for finding images from a game that aren't on the gallery already and being able to sort them more efficiently. This is also how we divide up character galleries already, such as Gallery:Mario (2010-2019).

Now, I can see a few edge cases, like when games have screenshots of themselves for credits images (i.e. Paper Mario: The Thousand-Year Door (Nintendo Switch)). I would still classify these as assets, since they are ripped from the game. Artwork that is used in smaller forms in-game, such as in Super Mario Maker 2, would be classified as artwork if externally released or an asset if it was ripped from the game files. Edge cases shouldn't be too common and they're easy to work out: it's not too different from how we license images or put them in character or subject galleries.

I think the name "assets" would be more useful in shorthand than "sprites and models," in addition to covering textures, so I propose for the category to be called that, but I can change it if there's opposition. The global images category can still exist in the case there's scans, merchandise, video screenshots, or such images that cannot be further categorized.

Proposer: Scrooge200 (talk)
Deadline: January 5, 2025, 23:59 GMT

Support

  1. Scrooge200 (talk) Per proposal.
  2. Waluigi Time (talk) I support this in principle, as long as there's room for discretion on what gets split and what gets left alone. A game with only ten or so pieces of artwork doesn't need a separate category for them, they can just stay in the main images category for that game. Otherwise, this seems useful, I just don't want users to go overboard by purely following the letter of this proposal.
  3. Salmancer (talk) I've tried to see if an image I wanted to use was already uploaded via the category, which would encourage me to make the text and get the article up. Due to the sheer number of images, this is a bad idea. This proposal will make that less of a bad idea for cases where an asset or artwork is being searched for.
  4. EvieMaybe (talk) hell yea
  5. Power Flotzo (talk) Per all.
  6. FanOfYoshi (talk) Per all.

Oppose

Comments

This is already being done (e.g. Category:Mario Kart Tour item icons). Super Mario RPG (talk) 11:02, December 23, 2024 (EST)

Removals

None at the moment.

Changes

Broaden the scope of the {{rewrite}} template and its variations

With the previous proposal having passed with being more specific as the most voted, I've come up with a proposal about the possibility to make the {{rewrite}}, {{rewrite-expand}}, and {{rewrite-remove}} templates more specific. As you can see, these templates are missing some smaller text. As such, I am just wondering if there is a possibility to have the smaller text added to the {{rewrite}}, {{rewrite-expand}}, and {{rewrite-remove}} templates.

First of all, the {{rewrite}} template currently reads as follows: 

<div class="notice-template maintenance" style="background:#9CF;border:1px solid #000">
It has been requested that this {{#if:{{{section|}}}|section|article}} be '''rewritten'''. {{#if:{{{reason|{{{1|}}}}}}|'''Reason:''' {{{reason|{{{1}}}}}}|<includeonly>{{#switch:{{NAMESPACE}}||Gallery=[[Category:Articles with incomplete maintenance tags]]}}</includeonly>}}{{#if:{{{date|{{{2|}}}}}}|<nowiki/> (tagged on {{{date|{{{2}}}}}})}}
</div>

It has been requested that this article be rewritten.

However, once the proposal passes, the {{rewrite}} template will read as follows: 

<div class="notice-template maintenance" style="background:#9CF;border:1px solid #000">
It has been requested that this {{#if:{{{section|}}}|section|article}} be '''rewritten'''{{#if:{{{reason|{{{1|}}}}}}|<nowiki/> for the following reason(s): {{{reason|{{{1}}}}}}|.<includeonly>{{#switch:{{NAMESPACE}}||Gallery=[[Category:Articles with incomplete maintenance tags]]}}</includeonly>}}{{#if:{{{date|{{{2|}}}}}}|<nowiki/> (tagged on {{{date|{{{2}}}}}})}}<br><small>Please review the [[MarioWiki:Manual of Style|Manual of Style]] and [[MarioWiki:Good writing|good writing standards]] and help {{plain link|{{fullurl:{{FULLPAGENAME}}|action=edit}}|improve this {{#if:{{{section|}}}|section|article}}}}.</small>
</div>

It has been requested that this article be rewritten for the following reason(s): <reason(s)>.
Please review the Manual of Style and good writing standards and help improve this article.

And another thing—the {{rewrite-expand}} template currently reads as follows: 

<div class="notice-template maintenance" style="background:#9CF;border:1px solid #000">
It has been requested that this {{#if:{{{section|}}}|section|article}} be '''rewritten''' and '''expanded''' to include more information. {{#if:{{{reason|{{{1|}}}}}}|'''Reason:''' {{{reason|{{{1}}}}}}|<includeonly>{{#switch:{{NAMESPACE}}||Gallery=[[Category:Articles with incomplete maintenance tags]]}}</includeonly>}}{{#if:{{{date|{{{2|}}}}}}|<nowiki/> (tagged on {{{date|{{{2}}}}}})}}
</div>

It has been requested that this article be rewritten and expanded to include more information.

However, once this proposal passes, the {{rewrite-expand}} will read as follows: 

<div class="notice-template maintenance" style="background:#9CF;border:1px solid #000">
It has been requested that this {{#if:{{{section|}}}|section|article}} be '''rewritten''' and '''expanded''' to include more information.{{#if:{{{reason|{{{1|}}}}}}|<nowiki/> for the following reason(s): {{{reason|{{{1}}}}}}|.<includeonly>{{#switch:{{NAMESPACE}}||Gallery=[[Category:Articles with incomplete maintenance tags]]}}</includeonly>}}{{#if:{{{date|{{{2|}}}}}}|<nowiki/> (tagged on {{{date|{{{2}}}}}})}}<br><small>Please review the [[MarioWiki:Manual of Style|Manual of Style]] and [[MarioWiki:Good writing|good writing standards]] and help {{plain link|{{fullurl:{{FULLPAGENAME}}|action=edit}}|improve this {{#if:{{{section|}}}|section|article}}}} by filling in the missing details.</small>
</div>

It has been requested that this article be rewritten and expanded to include more information for the following reason(s): <reason(s)>.
Please review the Manual of Style and good writing standards and help improve this article by filling in the missing details.

Lastly, the {{rewrite-remove}} currently reads as follows: 

<div class="notice-template maintenance" style="background:#9CF;border:1px solid #000">
It has been requested that this {{#if:{{{section|}}}|section|article}} be '''rewritten''' to have <u>{{{content|{{{1|content<includeonly>{{#switch:{{NAMESPACE}}||Gallery=[[Category:Articles with incomplete maintenance tags]]}}</includeonly>}}}}}}</u> '''removed''' for the following reason(s): {{{reason|{{{2|???<includeonly>{{#switch:{{NAMESPACE}}||Gallery=[[Category:Articles with incomplete maintenance tags]]}}</includeonly>}}}}}}{{#if:{{{date|{{{3|}}}}}}|<nowiki/> (tagged on {{{date|{{{3}}}}}})}}
</div>

It has been requested that this article be rewritten to have content removed for the following reason(s): ???

However, once this proposal passes, the {{rewrite-remove}} will read as follows: 

<div class="notice-template maintenance" style="background:#9CF;border:1px solid #000">
It has been requested that this {{#if:{{{section|}}}|section|article}} be '''rewritten''' to have {{#if:{{{content|{{{1|}}}}}}|<u>{{{content|{{{1}}}}}}</u>|content}} '''removed'''{{#if:{{{reason|{{{2|}}}}}}|<nowiki/> for the following reason(s):{{{reason|{{{2}}}}}}|.<includeonly>{{#switch:{{NAMESPACE}}||Gallery=[[Category:Articles with incomplete maintenance tags]]}}</includeonly>}}{{#if:{{{date|{{{3|}}}}}}|<nowiki/> (tagged on {{{date|{{{3}}}}}})}}<br><small>Please review the [[MarioWiki:Manual of Style|Manual of Style]] and [[MarioWiki:Good writing|good writing standards]] and help {{plain link|{{fullurl:{{FULLPAGENAME}}|action=edit}}|improve this {{#if:{{{section|}}}|section|article}}}} by removing the unnecessary details.</small>
</div>

It has been requested that this article be rewritten to have content removed for the following reason(s): <reason(s)>.
Please review the Manual of Style and good writing standards and help improve this article by removing the unnecessary details.

That will be a perfect idea to make the {{rewrite}} template and its variations as more specific as the {{media missing}} and {{unreferenced}} templates. That way, we'll be able to add smaller text to the remaining notice templates in the future.

Proposer: GuntherBayBeee (talk)
Deadline: December 23, 2024, 23:59 GMT Extended to December 30, 2024, 23:59 GMT

Support

  1. GuntherBayBeee (talk) Per proposal

Oppose

  1. Altendo (talk) As far as I can tell, the proposal that was linked added parameters that allowed what was supposed to be referenced to be referenced. This one simply adds a subtitle to the bottom of each template. "Be more specific" does not mean saying general information and helpful links, but rather exactly what needs to be done; in terms of that, the existing templates not only all already have parameters, but filling them out is enforced. As Nightwicked Bowser said, "Be more specific - Similar to this proposal, what exactly needs references must be specified in the template when putting it in the article. A parameter for this will still need to be added." This only adds a subtitle and does not make this "more specific". As for the changes, this is actually harmful in some way, as the (tagged on {{{date|{{{3}}}}}}) tag will be added to the subtitle, rather than the main body, which could make it more confusing in my opinion. Feel free to update this and add in what "more specific" actually means, or just change this to "add subtitles" and change the location of (tagged on {{{date|{{{3}}}}}}) to the main body, but until then, my vote is staying here.
  2. Mario (talk) Best to keep things simple with these improvement templates.
  3. Technetium (talk) Per Mario.

Comments

Here's how I would fix some things:

First of all, the {{rewrite}} template currently reads as follows: 

<div class="notice-template maintenance" style="background:#9CF;border:1px solid #000">
It has been requested that this {{#if:{{{section|}}}|section|article}} be '''rewritten'''. {{#if:{{{reason|{{{1|}}}}}}|'''Reason:''' {{{reason|{{{1}}}}}}|<includeonly>{{#switch:{{NAMESPACE}}||Gallery=[[Category:Articles with incomplete maintenance tags]]}}</includeonly>}}{{#if:{{{date|{{{2|}}}}}}|<nowiki/> (tagged on {{{date|{{{2}}}}}})}}
</div>

It has been requested that this article be rewritten.

However, once the proposal passes, the {{rewrite}} template will read as follows: 

<div class="notice-template maintenance" style="background:#9CF;border:1px solid #000">
It has been requested that this {{#if:{{{section|}}}|section|article}} be '''rewritten'''{{#if:{{{reason|{{{1|}}}}}}|<nowiki/> for the following reason(s): {{{reason|{{{1}}}}}}|.<includeonly>{{#switch:{{NAMESPACE}}||Gallery=[[Category:Articles with incomplete maintenance tags]]}}</includeonly>}}{{#if:{{{date|{{{2|}}}}}}|<nowiki/> (tagged on {{{date|{{{2}}}}}})}}<br><small>Please review the [[MarioWiki:Manual of Style|Manual of Style]] and [[MarioWiki:Good writing|good writing standards]] and help {{plain link|{{fullurl:{{FULLPAGENAME}}|action=edit}}|improve this {{#if:{{{section|}}}|section|article}}}}.</small>
</div>

It has been requested that this article be rewritten for the following reasons:
Please review the Manual of Style and good writing standards and help improve this article.

And another thing—the {{rewrite-expand}} template currently reads as follows: 

<div class="notice-template maintenance" style="background:#9CF;border:1px solid #000">
It has been requested that this {{#if:{{{section|}}}|section|article}} be '''rewritten''' and '''expanded''' to include more information. {{#if:{{{reason|{{{1|}}}}}}|'''Reason:''' {{{reason|{{{1}}}}}}|<includeonly>{{#switch:{{NAMESPACE}}||Gallery=[[Category:Articles with incomplete maintenance tags]]}}</includeonly>}}{{#if:{{{date|{{{2|}}}}}}|<nowiki/> (tagged on {{{date|{{{2}}}}}})}}
</div>

It has been requested that this article be rewritten and expanded to include more information.

However, once this proposal passes, the {{rewrite-expand}} will read as follows: 

<div class="notice-template maintenance" style="background:#9CF;border:1px solid #000">
It has been requested that this {{#if:{{{section|}}}|section|article}} be '''rewritten''' and '''expanded''' to include more information{{#if:{{{reason|{{{1|}}}}}}|<nowiki/> for the following reason(s): {{{reason|{{{1}}}}}}|.<includeonly>{{#switch:{{NAMESPACE}}||Gallery=[[Category:Articles with incomplete maintenance tags]]}}</includeonly>}}{{#if:{{{date|{{{2|}}}}}}|<nowiki/> (tagged on {{{date|{{{2}}}}}})}}<br><small>Please review the [[MarioWiki:Manual of Style|Manual of Style]] and [[MarioWiki:Good writing|good writing standards]] and help {{plain link|{{fullurl:{{FULLPAGENAME}}|action=edit}}|improve this {{#if:{{{section|}}}|section|article}}}} by filling in the missing details.</small>
</div>

It has been requested that this article be rewritten and expanded to include more information for the following reasons:
Please review the Manual of Style and good writing standards and help improve this article by filling in the missing details.

Lastly, the {{rewrite-remove}} currently reads as follows: 

<div class="notice-template maintenance" style="background:#9CF;border:1px solid #000">
It has been requested that this {{#if:{{{section|}}}|section|article}} be '''rewritten''' to have <u>{{{content|{{{1|content<includeonly>{{#switch:{{NAMESPACE}}||Gallery=[[Category:Articles with incomplete maintenance tags]]}}</includeonly>}}}}}}</u> '''removed''' for the following reason(s): {{{reason|{{{2|???<includeonly>{{#switch:{{NAMESPACE}}||Gallery=[[Category:Articles with incomplete maintenance tags]]}}</includeonly>}}}}}}{{#if:{{{date|{{{3|}}}}}}|<nowiki/> (tagged on {{{date|{{{3}}}}}})}}
</div>

It has been requested that this article be rewritten to have content removed for the following reason(s): ???

However, once this proposal passes, the {{rewrite-remove}} will read as follows: 

<div class="notice-template maintenance" style="background:#9CF;border:1px solid #000">
It has been requested that this {{#if:{{{section|}}}|section|article}} be '''rewritten''' to have {{#if:{{{content|{{{1|}}}}}}|<u>{{{content|{{{1}}}}}}</u>|content}} '''removed''' {{#if:{{{reason|{{{2|}}}}}}|<nowiki/> for the following reasons:{{{reason|{{{2}}}}}}|.<includeonly>{{#switch:{{NAMESPACE}}||Gallery=[[Category:Articles with incomplete maintenance tags]]}}</includeonly>}}{{#if:{{{date|{{{3|}}}}}}|<nowiki/> (tagged on {{{date|{{{3}}}}}})}}<br><small>Please review the [[MarioWiki:Manual of Style|Manual of Style]] and [[MarioWiki:Good writing|good writing standards]] and help {{plain link|{{fullurl:{{FULLPAGENAME}}|action=edit}}|improve this {{#if:{{{section|}}}|section|article}}}} by removing the unnecessary details.</small>
</div>

It has been requested that this article be rewritten to have content removed for the following reason(s):
Please review the Manual of Style and good writing standards and help improve this article by removing the unnecessary details.

This should fix some things, and I also recommend you change the title or at least context of this proposal. If so, then I might change my vote. Altendo 19:58, December 9, 2024 (EST)

I fixed this problem for you. How does it look? GuntherBayBeee.jpgGuntherBayBeeeGravity Rush Kat.png 09:40, December 10, 2024 (EST)

Decide what to do with Template:Move infobox

A while ago (November 4th, specifically), I created Template:Move infobox. After all, we had templates for essentially all the Browse tabs on the wiki sidebar, except for moves. There WERE templates about specific types of moves, such as Template:M&L attack infobox, but no general template in the same vein as items, characters, species, games, locations, etc.

I discussed it on the Discord briefly, nobody said no, and a bit of feedback later about how it should look and what it should have, I created it. It has since been applied to exactly four pages at the time of writing, half of which I was the one to apply it to. In hindsight, this could've used with a proposal instead of me just making it, so here's a belated one.

Should we keep Template:Move infobox around? If we do keep it, is it good as is, or does it need changes?

Proposer: EvieMaybe (talk)
Deadline: January 1st, 2025, 23:59 GMT

Keep Move infobox, as is

  1. Sparks (talk) I can see this template working really well for moves that aren't in every Mario game, like Spin. This has lots of potential!
  2. Nintendo101 (talk) Per proposal.
  3. Camwoodstock (talk) We don't see why not--having a dedicated Moves infobox could come in handy, especially if we get any more Mario RPGs in the wake of the weird little renaissance period we've been getting with the back-to-back-to-back SMRPG remake, TTYD remake, and release of Brothership. Per proposal.
  4. Pseudo (talk) Per proposal.
  5. Technetium (talk) Per proposal.
  6. Salmancer (talk) It would bring more attention to our move pages. I'm down for that.

Keep Move infobox, but with changes

Delete Move infobox

Move infobox Comments

Considering the nature of the attack infoboxes, wouldn't it be weird to have moves all in purple but a Mario & Luigi attack use yellow and green and a Paper Mario attack use white and green? Should there be variants of the Move infobox to match the color schemes of existing templates? If an article is covering multiple related moves, how will the infobox work? (ex. Handstand, Cap Throw, Roll, Slide Kick... there's more of these than I thought). What happens when a move is referenced in somewhat less "move-y" ways? Okay, that last one is kinda strange, but basically I mean "dashing" in Super Mario Run is just a fancy animation, Mario & Luigi Dream Team has an animation where Giant Luigi crouches (with posing and skidding clearly meant to be a platformer callback), to slide under an attack. Do these instances get incorporated into the infobox? Continuing the train of thought, what about sports games? Yoshi can Flutter Jump as his special action on Mario & Sonic games. Does that count as a method of input for a Flutter Jump? Salmancer (talk) 21:35, December 19, 2024 (EST)

that's a lot of very interesting questions!
  • i went with purple to set it apart from the already taken light red (game), green and white (character), blue (level), pink (location), grey (item) and navy/grey (species) infoboxes. changing the color could be a good idea.
  • as for sorting which moves "count" or not, we have to decide these things for other types of subject too, after all, and they get infoboxes. it's a valid concern, though! eviemaybe (talk / contributions) 15:09, December 20, 2024 (EST)



Allow blank votes and reclassify them as "per all"

There are times when users have nothing else to add and agree with the rest of the points. Sure, they can type "per all", but wouldn't it be easier to not to have to do this?

Yeah sure, if the first oppose vote is just blank for no reason, that'll be strange, but again, it wouldn't be any more strange with the same vote's having "per all" as a reasoning. I've never seen users cast these kinds of votes in bad faith, as we already have rules in place to zap obviously bad faith votes.

This proposal wouldn't really change how people vote, only that they shouldn't have to be compelled to type the worthless "per all" on their votes.

Proposer: Mario (talk)
Deadline: January 1, 2025, 23:59 GMT

Blank support

  1. Mario (talk) Per all.
  2. Ray Trace (talk) Casting a vote in a side is literally an action of endorsement of a side. We don't need to add verbal confirmation to this either.
  3. PopitTart (talk) (This vote is left blank to note that I support this option but any commentary I could add would be redundant.)
  4. Altendo (talk) (Look at the code for my reasoning)
  5. FanOfYoshi (talk)
  6. OmegaRuby (talk) While on the outset it may seem strange to see a large number of votes where people say "per all" and leave, it's important to understand that the decision was made because the user either outright agrees with the entire premise of the proposal, or has read discussion and points on both sides and agrees more with the points made by the side they choose. And if they really are just mindlessly voting "per all" on proposals with no second thought, we can't police that at all. (Doing so would border on FBI-agent-tech-magic silliness and would also be extremely invading...)
  7. Shy Guy on Wheels (talk) I've always thought of not allowing blank votes to be a bit of a silly rule, when it can so easily be circumvented by typing two words. I think it's better to assume good faith with voting and just let people not write if they don't have anything to add, it's not as if random IPs are able to vote on this page.
  8. TheDarkStar (talk) - Dunno why I have to say something if I agree with an idea but someone's already said what I'm thinking. A vote is a vote, imo.
  9. Ninja Squid (talk) Per proposal.
  10. Tails777 (talk) It's not like we're outright telling people not to say "Per all", it's just a means of saying you don't have to. If the proposal in question is so straight forward that nothing else can be said other than "Per proposal/Per all", it's basically the same as saying nothing at all. It's just a silent agreement. Even so, if people DO support a specific person's vote, they can still just "Per [Insert user's name here]". I see no problem with letting people have blank votes, especially if it's optional to do so in the first place.

Blank Oppose

  1. Doc von Schmeltwick (talk) - Honestly? I'd prefer to get rid of "per all" votes since they're primarily used for the "I don't/like this idea" type of thing that has historically been discouraged. If you don't care enough to explain, you don't care enough to cast IMO.
  2. Technetium (talk) I don't think typing "per all" is that much of an annoyance (it's only two words), and I like clearly seeing why people are voting (for instance, I do see a difference between "per proposal" and "per all" - "per all" implies agreeing with the comments, too). I just don't think this is something that needs changing, not to mention the potential confusion blank votes could cause.
  3. Camwoodstock (talk) Maybe we're a little petty, but we prefer a "per all" vote to a blank one, even if "per all" is effectively used as a non-answer, because it still requires that someone does provide an answer, even if it's just to effectively say "ditto". You know what to expect with a "per all" vote--you don't really get that information with a fully blank vote.
  4. Ahemtoday (talk) Forgive me for the gimmicky formatting, but I want to make a point here — when you see a blank oppositional vote, it's disheartening, isn't it? Of course, it's always going to be that way when someone's voting against you, but when it doesn't come with any other thoughts, then you can't at all address it, debate it, take it into account — nothing. This also applies to supporting votes, if it's for a proposal you oppose. Of course, this is an issue with "per all" votes as well. I don't know if I'd go as far as Doc would on that, but if there's going to be these kinds of non-discussion-generating votes, they can at least be bothered to type two words.
  5. Jdtendo (talk) Per all (is it too much to ask to type just two words to explicitely express that you agree with the above votes?)
  6. Axii (talk) Requiring people to state their reason for agreeing or disagreeing with a proposal leads to unnecessary repetition (in response to Doc). Letting people type nothing doesn't help us understand which arguments they agreed with when deciding what to vote for. The proposer? Other people who voted? Someone in particular, maybe? Maybe everyone except the proposer? It's crucial to know which arguments were the most convincing to people.
  7. Pseudo (talk) Per Technetium, Camwoodstock, and Axii.
  8. Hooded Pitohui (talk) I admit this vote is based on personal preference as any defensible reasoning. To build on Camwoodstock and Ahemtoday's points, though, the way I see it, "per all" at least provides some insight into what has persuaded a voter, if only the bare minimum. "Per all" is distinct at least from "per proposal", suggesting another voter has persuaded them where the original proposal did not by itself. A blank vote would not provide even that distinction.
  9. Mister Wu (talk) Asking for even a minimal input from the user as to why they are voting is fundamental, it tells us what were the compelling points that led to a choice or the other. It can also aid the voters in clarifying to themselves what they're agreeing with. Also worth noting that the new editors simply can't know that blank means "per all", even if we put it at the beginning of this page, because new editors simply don't know the internal organization of the wiki. Blank votes would inevitably be used inappropriately, and not in bad faith.
  10. DesaMatt (talk) Per all and per everyone and per everything. Per.

Blank Comments

I don't think banning "per all" or "per proposal" is feasible nor recommended. People literally sometimes have nothing else to add; they agree with the points being made, so they cast a vote. They don't need to waste keystrokes reiterating points. My proposal is aiming to just streamline that thought process and also save them some keystrokes. Mario (Santa)'s map icon from Mario Kart Tour Mario-HOHO! (Talk / Stalk) 20:34, December 17, 2024 (EST)

I think every sort of vote (on every level, on every medium) should be written-in regardless of whether something has been said already or not; it demonstrates the level of understanding and investment for the issue at hand, which in my opinion should be prerequisite to voting on any issue. Doc von Schmeltwick (talk) 20:53, December 17, 2024 (EST)
There is no way to actually determine this: we are not going to test voters or commenters their understanding of the subject. Someone can read all of the arguments and still just vote for a side because there's no need to reiterate a position that they already agree with. BabyLuigiFire.pngRay Trace(T|C) 20:55, December 17, 2024 (EST)
My personal belief is that "test[ing] voters or commenters their understanding of the subject" is exactly what should be done to avoid votes cast in misunderstanding or outright bandwagoning. Doc von Schmeltwick (talk) 23:06, December 17, 2024 (EST)
My personal view is that a change like the one you are suggesting potentially increases the odds of inexperienced or new users feeling too intimidated to participate because they feel like they do not have well articulated stances, which would be terrible. I think concerns about "bandwagoning" are overstated. However, more pressingly, this proposal is not even about this concept and it is not even one of the voting options, so I recommend saving this idea for another day. - Nintendo101 (talk) 23:32, December 17, 2024 (EST)
@Mario I agree. Banning people from saying that in proposals is restricting others from exercising their right to cast a vote in a system that was designed for user input of any time. I'd strongly oppose any measure to ban "per" statements in proposals. Super Mario RPG (talk) 00:11, December 18, 2024 (EST)

Technetium: I understand, but blank votes are a fairly common practice in other wikis, and it's clearly understood that the user is supporting the proposal in general. Mario (Santa)'s map icon from Mario Kart Tour Mario-HOHO! (Talk / Stalk) 20:36, December 17, 2024 (EST)

Fair point, I didn't know that. Not changing my vote just yet, but I'll keep this in mind as the proposal continues. Technetium (talk) 20:48, December 17, 2024 (EST)
There's a lot of variation in how other wikis do it. WiKirby, for example, doesn't even allow "per" votes last I checked. Hewer A Hamburger in Super Smash Bros. Brawl. (talk · contributions · edit count) 04:13, December 18, 2024 (EST)

I'm not really much of a voter, but I'm of the opinion "it's the principle of the matter". Requiring a written opinion, of any kind, at least encourages a consideration of the topic. Salmancer (talk) 21:35, December 19, 2024 (EST)

Set Vector-2010 to the default wiki skin

This proposal is about setting the 2010 Vector as the default wiki skin (screenshot here) for desktop users, with the focus being on people who are new to wikis in particular, while obviously keeping the existing MonoBook skin as an option. What made me think to create this proposal is when I made a Talk:Main Page proposal about the to-do list tasks and how they are more accessible than clicking the "Wiki maintenance" on the sidebar, I had to uncomfortably squint to find "Wiki maintenance" on the wiki sidebar. But Vector-2010 has the sidebar links slightly larger and a bit more spaced out. With the existing interface, there could be some who may struggle to find options listed on the sidebar.

While we're clearly different from Wikipedia (that's why I'm not Vector-2022, since it'd be too much of a departure and likely uncomfortable for several), I do want to refer to this page, which summarizes why Wikipedia transitioned to it. Though it is vague, they cite accessibility as the reason, which I think this wiki has been taking steps toward doing.

I'll cite my reasons for preferring Vector and applying this to possible people who are visiting a wiki for the first time. The text is larger, which is especially important for larger screen monitors, some of the lesser used tabs are collapsible on the sidebar, summarizing the most commonly used options, and the user links at the top right are also more noticeable and less close to the body of the article where the content is read.

Though it could take time getting used to the Edit button being on the right (not to mention the search button), the button is at least larger, making it more usable on even lower quality screen monitors, and I like how it's separate from the Page and discussion options, meaning that options that involve viewing articles are on the left while options that involve editing or changing the page in some form are on the right.

If this proposal passes and others don't like the change, they can always return to the MonoBook option in their preferences.

Proposer: Super Mario RPG (talk)
Deadline: January 1, 2025, 23:59 GMT

Support

  1. Super Mario RPG (talk) Per.

Oppose

  1. Camwoodstock (talk) Admittedly, this vote is largely a matter of preference--we just don't like Vector that much--but we can't think of any real reason to switch to Vector 2010 as the default over the current Monobook beyond the mentioned text spacing; while that is a nice boon, we personally find the weird gradient buttons for the various tabs up top a little grating looking, and we're a fan of the more compact design that Monobook provides--though, this is likely a byproduct of our personal preference for more neatly packed web design. And uh, the less said about the other two options (Vector 2022, and. Timeless. Which is the most dated theme possible, namely to mid-2010s mobile web design.), the better. If you like Vector 2010, that's great, and we're fine with that! Heck, if anyone likes Vector 2022 or Timeless, that's cool too, and more power to them! Variety is the spice of life, after all. But switching it to the default is something that should not be taken lightly, and the reasons for a switch in this proposal feel a little too loosey-goosey for us, we're sorry.
  2. DryBonesBandit (talk) Per Camwoodstock.
  3. Nintendo101 (talk) I like how MonoBook looks a little more than Vector. It is what I am comfortable with. If it ain't broke, don't fix it.
  4. Drago (talk) Per Nintendo101. I actually prefer the smaller text of Monobook since you can see more of the page at once. I also want to point out that although logged-in users like us can change the skin in preferences, we'd still be forcing the change on logged-out users.
  5. Ahemtoday (talk) Per Drago.
  6. Technetium (talk) Per Nintendo101 and Drago. I just don't see any reason to make this change.
  7. Altendo (talk) I'm saying this as a Vector-2010 skin user, and I'll say that people have their preferences. I live Vector-2010 because that is how Wikipedia at least used to look before they switched to Vector (2022); On Wikipedia, Vector was renamed to Vector legacy (2010), while Vector 2022 is named Vector (2022). Although I do prefer Vector-2010, I know a lot of people that prefer Monobook, and even if not, this can be changed in the preferences. No need to change the default skin. I get that IPs can't change their appearance, but aside from that, users can, and what they see doesn't have to be default on the wiki. Everyone can change what they specifically see.

Comments

@Camwoodstock That is true that it's a major change. It's based mainly upon impression from newcomers from them seeing a more prominent edit tab, slightly larger text size, and other minor details like tab names that are easier to read (including a collapsible feature for the lesser used tab). The skin change was based on old Wikipedia research at the time (like how WikiLove was a result of their research). I have no strong feelings whether this passes or not. Although it's vague, since there's no way to tell the statistics (and the wiki's already successful at the moment), I still have a feeling it could help some, but to each their own. Super Mario RPG (talk) 18:32, December 18, 2024 (EST)

We feel like if anybody would be capable of providing any statistics on skin usage, it'd be Porple, but even then, we don't actually know if that's one of the things he tracks, and it feels a little silly to pester him over this of all things... ;p Camwoodstock-sigicon.png~Camwoodstock (talk) 18:55, December 18, 2024 (EST)

I'm okay with opposition, but in case of misunderstanding, this proposal isn't about personal preferences so much as what I believe to be a more ergonomic interface to a wider audience. I know we're not Wikipedia, but there's also the consideration that they've used the Vector skin longer than they had for MonoBook. Super Mario RPG (talk) 13:45, December 19, 2024 (EST)

If it's what "you believe", then it ultimately (and probably unavoidably) is about personal preferences. Anyway, another consideration is the fact that people often prefer what they're used to. I feel like how long this wiki has used its skin is more relevant than how long Wikipedia has. Hewer A Hamburger in Super Smash Bros. Brawl. (talk · contributions · edit count) 16:39, December 19, 2024 (EST)
@Hewer I suppose I'm overthinking the ergonomic interface. Super Mario RPG (talk) 15:19, December 20, 2024 (EST)

Miscellaneous

None at the moment.

Retrieved from "https://www.mariowiki.com/index.php?title=MarioWiki:Proposals&oldid=4476928"