MarioWiki:Proposals

Proposals can be new features (such as an extension), removals of previously added features that have tired out, or new policies that must be approved via consensus before any action is taken. 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 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 {{User|User name}}.

This page observes the No-Signature Policy.

How To

Rules

1. 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 Writing Guideline proposals must include a link to the draft page.
2. 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.)
   • 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.
3. Every vote should have a reason accompanying it. Agreeing with 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. 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 administrators.
5. 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 "(banned)" 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.
6. No proposal can overturn the decision of a previous proposal that is less than 4 weeks (28 days) old.
7. 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.
8. All proposals that end up in a tie will be extended for another week.
9. 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.
10. 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.
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 an administrator, the proposer can ask for that help.
12. 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 administrator at any time, provided they have a valid reason for it. Please note that cancelled proposals must also be archived.
13. 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.
14. 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 PipeProject.
15. Proposals cannot be made about promotions and demotions. Users can only be promoted and demoted by the will of the administration.
16. No joke proposals. Proposals are serious wiki matters and should be handled professionally. Joke proposals will be deleted on sight.

Basic Proposal and Support/Oppose Format

This is an example of what your proposal must 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]". Proposals presenting multiple alternative courses of action can have more than two voting options, but what each voting section is supporting must be clearly defined.

---

===[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|[enter your username here]}}<br>
'''Deadline''': [insert a deadline here, 7 days after the proposal was created, at 23:59 GMT.]

====Support====
#{{User|[enter your username here]}} [make a statement indicating that you support your proposal]

====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 "#{{User|[add 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 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.

For a list of all settled Talk Page Proposals, see here.

Rules

1. 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 "(Template:Fakelink)". If the proposal involved a page that is not yet made, use {{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 {{TPP}} 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. (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.
4. 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.
5. The talk page proposal must pertain to the article it is posted on.

List of Talk Page Proposals

• Classify Rocky Wrenches as Monty Moles. (Discuss) Deadline: January 2, 2012, 23:59 GMT Extended: January 9, 2012, 23:59 GMT, January 16, 2012, 23:59 GMT
• Give the {{Aboutfile}} template a 3D indicator. (Discuss) Deadline: January 19, 2012, 23:59 GMT

Writing Guidelines

None at the moment.

New Features

Bookmarks

When a user wants to find an article that they often visit, they would need to type in the searchbar. When an internet user wants to find a website that they often visit, they don't search in a google search bar, they go to Bookmarks in their internet browser and find their favourite websites. It should be the same here on the Super Mario Wiki. For pages and articles that we often visit, there should be a bookmark section for our individual account somewhere on the page, like on the top next to my watchlist or on the side bar under navigation. Here, we should be able to bookmark pages for easy navigation. If you agree, please support me.

Proposer:YoshiKong (talk)
Deadline:January 11, 2012, 23:59 GMT

Support

1. YoshiKong (talk) Per my proposal.
2. Pichi-Hime6 (talk) I totally agree with Yoshi Kong. I've actually been wanting something like that since I joined the wiki.

Oppose

1. Baby Mario Bloops (talk) - On this wiki, the articles themselves have internet links to them. If you feel like you visit the page quite often, then bookmark it like you would with any other site. There is no reason to add a feature that you can already do.
2. Bop1996 (talk) Per BMB. Also, it's not hard to find an article using the search bar at all, and the watchlist feature helps you keep tabs on important pages, so there's really no need for it.
3. Mario4Ever (talk) Per both.
4. Jazama (talk) This proposal is redundant to the watchlist and to the bookmarks that comes with all browsers.
5. Raven Effect (talk) Per All
6. Commander Code-8 (talk) This seems a bit pointless. Per all.
7. Walkazo (talk) - Per BMB and Bop1996.
8. M&SG (talk) - Per all.
9. Lakituthequick (talk) Per Baby Mario Bloops and Bop1996
10. Magikrazy51 (talk) Assuming everyone who visits the wiki has more than one finger and can use a keyboard easily, searching in the search bar isn't hard at all. It's so easy, 2 stalks of celery and a paper towel could do it. Per all.
11. Skyward Yoshi (talk) We have a contents page on are articles. Per All.
12. RandomYoshi (talk) - Per all.
13. Hyper Yoshi (talk) It's simple enough to search.
14. Akfamilyhome (talk) Per all. You can just bookmark it using your browser.
15. Mariomario64 (talk) – Like others have been saying, this is kinda useless because we can either use the watchlist or bookmark it on our browsers. If we can do those things, I don't see the point in adding this.
16. B.wilson (talk) Creating a JS (.js) file is required for a feature such as this. If creating the JS file wasn't too overly complicated, I would probably support this decision; however making this "bookmark" feature is way too complicated. You could possibly consider trying to make a .js file of your own. Re-propose once it's done so we could consider moving it to MW space. I'm sorry.
17. ThirdMarioBro (talk) This additional feature would be unnecessary, especially since the watchlist already does this.
18. Phoenix (talk) Per all.
19. Fawfulfury65 (talk) Per all.

Dealing with new stub articles - a better and friendlier way

Many new short articles are requested for deletion as new stubs instantly after they are created, which is in my opinion, not called for. I propose this should be changed.

After a new stub is created, a template explaining that it is a new stub and that it will be deleted in seven days after the template is put on the page is put on the page. Within that one-week period, articles have some time to expand to acceptable article length. If they reach acceptable article length within a one-week period, the article stays, however if they are still stubs after one week, the article is deleted.

This process prevents scaring newcomers away (when I was a newcomer, I created an article, it was immediately tagged as a new stub, it was deleted and I was beyond frustrated, as I haven't added all content within that creation), and given the main goal is to expand stubs, not to get rid of them!

Addendum: I have created this, which is similar to what should be used to tag new stubs.

Addendum (00:49, 10 January 2012 (EST)): This has nothing to do with the already existent construction template. This is "proposing deletion" of new stubs, instead of deleting them without delay. At least a week is given before they are deleted (unless they are expanded to stub length). Thanks for your !votes.

Proposer: B.wilson (talk)
Deadline: 16 January 2012 23:59 GMT

Support

1. B.wilson (talk) Per proposal. I hope I will be more respectful with the users who !vote 'oppose' this time.
2. ThePremiumYoshi (talk) - Great ideia. I agree with your words: We should expand stubs, not just simply get rid of them because they are stubs. I always wondered why are new stubs requested for deletion, if we can simply expand them. Per B.wilson
3. Magikrazy51 (talk) As long as you have enough rubies we can tell the difference between a stub and a short article. Per B.Wilson.
4. Propeller Toad (talk) This does seem to be a more efficient way of dealing with the stub articles. Additionally, this would also raise awareness of the stub articles as they can be fixed before immediate deletion. Per B.Wilson.
5. Raven Effect (talk) I agree with most of but i feel that one line articles that can be expanded should be deleted because I think its unfair to let somebody who didn't do any work get credit for making an article
6. Tails777 (talk) Per all. It gives newly created stub articles a chance to be improved.
7. Commander Code-8 (talk) This is a much better way of having less stubs rather than just deleting them.
8. LeftyGreenMario (talk) Although there is a construction template, I'm skeptical that new users even know a construction template exists. For the more experienced users, they can implement the construction template easily, but based on the aforementioned situation, they don't do it. I think this proposal can help this problem. If not, at least the wiki isn't harmed.

Oppose

1. Mario4Ever (talk) I don't disagree with the premise, but the situation is easily rectifiable with a construction template (though ideally, one would, when creating an article, make sure it is of sufficient length before stopping his or her work for a given period of time).
2. Bop1996 (talk) Per Mario4Ever. Also, there's a certain amount of admin discretion involved in whether the articles are deleted. For example, if an article is on a subject like a racecourse in an upcoming Mario Kart installment, chances are the article won't be expanded for a while, especially if it's just one user adding some details and leaving it. However, if a game was just released, and the article is being worked on by many people, the article is not deleted.
3. Zero777 (talk) I find unnecessary. That's what basically a construction template is for. It's a red flag saying, "DO NOT DELETE, IT NEEDS SOME WORK!!"

Comments

Zero777: I must apologize for saying this, but your !vote is not opposing anything clearly explained in the proposal. This is basically "proposing deletion" of new stubs, instead of "pending speedy deletion". It has nothing to do with the construction template. I apologize if I misunderstood your !vote, but I don't really think it's relevant to the proposal's intention. --B.wilson (talk)

Now I really don't understand what you are saying here. The quotation marks are confusing me. Zero777 (talk)

Your !vote is basically thinking that this idea is like the construction template, in which it is not. --B.wilson (talk)

I see it basically like the same and I don't think it's too much of a hassle to just slap on the construction template next time. Zero777 (talk)

I have to say, this isn't a bad idea. During that 1 week waiting period, the user who created the article can also make his case that the article is not a stub if they feel it isn't one. However, I'll support this if you can make a better sample template than that.

1. The same template you gave is too similar to {{Delete}} (perhaps by intention, but I don't want this proposal to bind us to that design). Make it a little more unique, we don't want a clone of the same template.
2. There's no need to mention that middle sentence, "New stubs are not allowed by Super Mario Wiki policy." It's just a waste of space to explain policy in templates.
3. You need to offer a link to the talk page (like {{Tobedeleted}}) in case users want to argue that the article not a stub or want feedback on how to expand the article.
4. Allow a variable which users can input the expected date of deletion. You could replace the small text line with "The article may be deleted if it cannot be expanded beyond stub length by [sample date].", sample date being 7 days after the date of stub creation (it doesn't have to get more specific than the date, hours just make things complicated).

--Knife (talk) 15:55, 10 January 2012 (EST)

I like the idea too. A construction template can be used instead, but some new users may not know they can use it and have their articles deleted for being too short. Also, it sometimes occurs that an article is put under construction, and then ignored for months or even years. Having a separate sort of construction template that says that the article must be expanded in a week would prevent someone from making a small article, sticking a construction template on it, and then never coming back to the article again. Fawfulfury65 (talk)

Hi Knife and Fawfulfury, I've tweaked User:B.wilson/Testing facility/Stub to reduce resemblance to the delete template, and I've also addressed all of Knife's concerns. I've given two examples of articles in which template is used: User:B.wilson/Testing facility/Stub/Article (pending deletion on 18 January) and User:B.wilson/Testing facility/Stub/Article2 (tagged on 3 January and currently pending deletion) - both examples are meant to be humorous. I'd appreciate !votes if you think I've addressed your concerns! --Bryce talk contributions 21:17, 10 January 2012 (EST)

I suggest that you change the color of the template to avoid resemblance to the delete template. LeftyGreenMario (talk)

I think the difference between construction templates and this new template would be that this template would be placed by an enforcing party (which would be the user claiming that the article is a new stub) as opposed to the article creator. Both could also be used together. For example, a user creates an article with {{Construction}} with no defined completion time, but it's a stub, another user could place the proposed template alongside the construction template to remind the user not to forget about the page otherwise his work will be deleted. Also, stub=/=articles under construction. One week should be enough time to expand an article beyond a stub, regardless of whether it's under construction or not.

@B.Wilson: The template is a little better, but the gif is a little wacky. I personally prefer a still image for things as serious as deletion templates. Perhaps a Bullet Bill would fit in better since it goes along with our theme of exploding creatures in deletion templates. Also, there's no need for an additional comments section in the template. There's really nothing to comment on if it's a new stub and if it really needs to be said, the user could use the talk page for that purpose. There's also something funny about the wording, but I can't put my finger around it. I suppose we can still change that after the proposal.--Knife (talk) 23:20, 10 January 2012 (EST)

Removals

None at the moment.

Changes

None at the moment.

Miscellaneous

None at the moment.