MarioWiki:Proposals

http://i143.photobucket.com/albums/r149/Deadringerforlove/dessert1.jpg 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.

This page observes the No-Signature Policy.

How To
 * 1) Actions that users feel are appropriate to have community approval first can be added by anyone, but they must have a strong argument.
 * 2) Users then start to discuss on the issue. 24 hours after posting the proposal (rounding up or down to the next or previous full hour, respectively, is allowed), the voting period begins. (The proposer is allowed to support their proposal right after posting.) Each proposal ends at the end of the day one week after voting start. (All times GMT).
 * 3) Every vote should have a reason accompanying it. Agreeing or seconding a previously mentioned reason given by another user is accepted.
 * 4) 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. The voter can remove or rewrite their own vote at any time, but the final decision to remove another User's vote lies solely with the Administrators.
 * 5) " # " should be added under the last vote of each support/oppose section to show another blank line.
 * 6) All proposals that end up in a tie will be extended for another week.
 * 7) 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.
 * 8) Any proposal that has three votes or less at deadline will automatically be listed as "NO QUORUM." The original proposer then has the option to relist said proposal to generate more discussion.
 * 9) No proposal can overturn the decision of a previous proposal that is less than 4 weeks (28 days) old.
 * 10) Proposals can only be rewritten or deleted by their proposer within the first three days of their creation. However, the proposer can request that their proposal be deleted by a Sysop at any time, provided they have a valid reason for it.
 * 11) 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 a Sysop, the proposer can ask for that help.
 * 12) There shouldn't be proposals about creating articles on a 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 PipeProject.
 * 13) Proposals cannot be made about System Operator promotions and demotions. Sysops can only be promoted and demoted by the will of Bureaucrats.
 * 14) If the Sysops 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.
 * 15) No joke proposals. Proposals are serious wiki matters, and should be handled professionally. Joke proposals will be deleted on sight.

The times are in GMT, and are set so that the user is more likely to be online at those times (after work/school, weekend nights). If a proposal is added on Monday night at 23:59 GMT, the deadline is the night of the Tuesday of the next week at 23:59 PM. If it is posted a minute later, the deadline is 23:59 PM of the Wednesday of the next week, since midnight is considered to be part of the next day, as 00:00 AM.

Basic Proposal and Support/Oppose Format
This is an example how 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 replace the whole variable including the squared brackets, so "[insert info here]" becomes "This is the inserted information", not "[This is the inserted information]". - ===[insert a title for your Proposal here]=== [describe what you want this Proposal to be like, what changes you would suggest and what this is about]

Proposer: Voting start: [insert a voting start time here, f.e. "2 January, 2010, 14:00". Voting start times are 24 hours after the time at which the proposal was posted, as described in Rule 2 above.] Deadline: [insert a deadline here, 7 days after the voting start, at 23:59 GMT.]

====Support====

====Oppose====

====Comments==== - 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 " # 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 anoother user's Proposal. If you are voting on your own Proposal, you can just say "Per my Proposal".

Talk Page Proposals
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.

How To

 * 1) All active talk page proposals must be listed below in chronological order (new proposals go at the bottom). All pages effected must be mentioned in the brief description, with the talk page housing the discussion linked to directly via "". If the proposal involved a page that is not yet made, use 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  under the heading.
 * 2) 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:
 * 3) Voting in talk page proposals will be open for two weeks, not one. There is no 24 hour delay between the posting of a talk page proposal and the commencement of voting.
 * 4) Talk page proposals may closed by the proposer if both the support and the oppose sides each have fewer than five votes.
 * 5) The talk page proposal must pertain to the article it is posted on.

List of Talk Page Proposals

 * Move Super Mushroom information to Super Mushroom. (Discuss) Deadline: May 4, 2010, 24:00
 * Merge Shooting Star Summit into Star Hill. (Discuss) Deadline: April 28 2010, 24:00 May 5 2010, 24:00
 * Split the weekly microgames from NinSoft and contests in WarioWare: D.I.Y. into separate pages. (Discuss) Deadline: May 7 2010, 24:00
 * Move Move Mega Mushroom info, Poison Mushroom info, etc. from the mushroom article to their respective articles. (Discuss) Deadline: May 8 2010, 24:00
 * Split from Sherbet Land. (Discuss) Deadline: May 2nd 2010, 24:00 May 9 2010, 24:00
 * Merge Vs. Wrecking Crew into Wrecking Crew. (Discuss) Deadline: May 9 2010, 24:00
 * Merge Super Mario FX into Super Mario 64/Beta elements. (Discuss) Deadline: May 10 2010, 24:00

New Features
''None at the moment.

Removals
''None at the moment.

Image Standard for "World" Articles
I was breezing through the (lovely) "world"-type articles recently (World 8 (Super Mario Bros.), Mt. Teapot, World 5 (New Super Mario Bros.)), and I noticed two types of images used for levels in the articles. The first, seen to the side, shows the level in its entirety, sprite-mapper and all.

The second shows a simple screenshot of the game, in the level. Two examples can be seen to the side.

I propose that we make a standard to use one or the other in all world/level articles. Please note that this only applies to the images attached to the "level" sections of the "world" articles.

(Side note: this is not an attack on the work of any user; it was simply something I noticed while I browsed the wiki.) Proposer: Voting Start: 00:33, 28 April 2010 Deadline: 23:59, 5 May 2010

Use Image Type 2

 * 1) -- I believe this is more official-looking and less like a strategy guide. We are not a guide, and simply must give information about each level. A screenshot can easily be used to show a specific part of the level mentioned in the description. It also makes for a nicer compliment to the text, as it can easily be viewed without clicking on the image to see the whole of the level. Lastly, many spritemaps are made by non-wiki users who put their name on the map; this looks very unprofessional and is, if copyrighted, illegal.
 * 2) Per BP.
 * 3) Per F65.
 * 4) Per PB, my comment and also they are nicer to look at.
 * 5) The entire map layout looks like a real mess and it's as ugly as Baby Luigi's face. The other one, however, is basically more efficient and it doesn't look like it got screwed up and whatever.
 * 6) - Per BP and because nobody likes having to click on an image (and wait for it to load) and then having to click again to view it in full size just to find out what is going on in it. Readers should be able to see what's in an image while reading the article it is used in, which is simply not possible with giant images with impractical dimensions.

Comments
I don't see how this is going to work out. I think that the first image should be used in the infobox right now and the latter should be used in the level descriptions. Take the worlds of NSMB right now, they look perfectly fine and use both types of images.
 * What the NSMB articles use in the infoboxes are pictures of the map screens of the respective worlds. This is about maps of individual level layouts being used in the world articles rather than unmodified in-game screenshots (like the NSMB articles also use).--
 * D'oh. There goes me misunderstanding a proposal...again. I don't know, as long as the map images aren't stolen, I see no problem.

I think that both images can be used, one in infoboxes and the other one in the article, but as BP said, some of the full-level images may even be copyrighted, we don't want to use copyrighted content without permission, do we?

So the proposal is saying that we should have either a screenshot or a map for the images in all the world articles? If that's what it means, than I think we should have a map for the first image in all the world articles. Problem is, what if we can't find an image of the map?
 * The proposal is saying that the individual levels in the World articles should either consistently use screenshots from the respective level or complete layout maps of the levels. The first image (used in the world's infobox) could still be an overworld map in either case, if that's what you mean with "map"; as I understand the proposal, this is solely about the images used for the individual levels listed in a world article, as the articles are currently inconsistent on whether they use screenshots or layout maps to go with the level descriptions. If you mean the first level listed should have a complete layout and the rest only screenshots, I don't really understand how that would make sense.--
 * Oh I get it now. Thanks.
 * @Vellidragon: You've got it perfect. I edited the proposal to make it more clear.

So...to put it nice and short...you are proposing the images in the article all be of one type. The other ones can still be located in the gallery section, correct?
 * Well... I don't like the copyrighted level maps on the articles at all. I would propose to delete them entirely. However, this proposal does not discuss what to do with the leftover images, so I suppose that they would, indeed, be put in a gallery at the bottom.

I like how type 2 give you a better idea of how the level looks "in play", but the maps could be useful. Although, we aren't a walkthough site. Is there possible a walkthrough site in need of some nice maps? It would be a shame to remove them and make them inaccessible (and isn't being an encyclopedia all about making information accessible?), but I can see how they don't belong. I guess, perhaps, if the images were "donated" to a separate level maps project we could just get rid of them.
 * Technically, we don't even own the maps. They've mostly been made by other people not even affiliated with this site who made the maps for places like vgatlas.com. We don't have the power to "donate" them, like you say, and they are still accessible on the mapping sites, as far as I know. We're not removing any original information by removing the maps.
 * I didn't think the wiki did really "own" them at all (which is why I didn't bother asking for permission to archive them). I guess there are enough map sites already, and game guides are pretty accessible and often include maps anyway. Although I think there are a few cases where maps might show something better to show an area, this is mostly for larger areas in the RPG games and not the platforming games this proposal seems to be dealing with.

@KS3: Did you even read the whole conversation? This proposal will not change anything about either comment you're referencing. >_>

I am Zero! I'll like one where if it is possible to make both of those types appear on the page; this might prevent stubs. Zero signing out.
 * It won't cause stubs. It would just be replaced by the second type.
 * Uh... how is changing an image supposed to cause stubs?
 * I am Zero! No I'm saying why don't we put both the screenshot of the level and the image of the whole level on articles. I'm not saying changing an image will create stubs I'm saying if there are some level articles that are stubs adding two images of the level may not make them stubs anymore. Zero signing out.
 * Adding images to an article is a very poor way to expand stubs... Besides, look at some of those world articles. There's not enough room on each level to add two images to each section.

The image of the whole level is shrunk drastically, making it nearly impossible to see it clearly without enlarging it. However, I don't like Image 2. Even though we are not a strategy guide, most people are visual learners. Most descriptions of levels are pointless to me if I can't see the picture of it.

Items and enemies order
I noticed a lot of items and enemies in articles like Super Mario Sunshine and Super Mario Galaxy 2 are just ordered randomly, which it a pain in the ass to navigate. We already has a proposal on the list of character relationships, and it won ABC. We pretty much are going to do the same thing with the items and enemies.

ABC is that we order the items and enemies in alphabetical format

Chronological is which appears first. The ones that appear first goes first, and the ones that appear last appears last in the article. If 2 appear at the same time, then it will be organized in alphabetical.

Importance is how important that item/enemy is. The most important item/enemy goes first and the least important one goes last.

Proposer: Voting start: 23:10, May 2 2010 Deadline: 23:59, May 9 2010

ABC

 * 1) most convenient, and few other games' enemies are organized ABC
 * 2) I am Zero! ABC order will be the easiest way to navigate for those who don't know much of the Mario series. Zero signing out.
 * 3) - Per comment below. Really the only way that makes sense, and it's already being done like this in various places.

Comments
As I have stated on the characters proposal, sorting anything by "importance" is extremely subjective. Chronological seems overly complicated and isn't even possible for non-linear games. Alphabetical order is basically the order used for pretty much anything except appearances in a History section (as they can easily be arranged chronologically just by looking at the release dates of individual games/other media). The navigation templates already put these things in alphabetical order in fact, and some articles, like the Super Mario Galaxy article (at least the "Returning Enemies" section of it) attempt an alphabetical order as well (though parts of it apparently got messed up here). I would like to know though, would the outcome of this proposal would affect bosses as well?--
 * It will affect bosses as well.
 * I'm tempted to oppose because of this. Bosses should be listed in the order they appear in the game. There is a very clear boss order in most games, and this order would be far easier to navigate than alphabetical.

Uhm... I don't know why they weren't in alphabetical order... They're supposed to be. They are in almost every other game.

Miscellaneous
None at the moment.