Super Mario Wiki

MarioWiki:Proposals

Project page Discussion
Revision as of 21:41, January 11, 2012 by Baby Mario Bloops (talk | contribs) (→‎Oppose)
Image used as a banner for the Proposals page


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

Writing Guidelines

None at the moment.

New Features

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.
  9. RandomYoshi (talk) - Per all.
  10. Lakituthequick (talk) Per all
  11. Knife (talk) – Per all
  12. Walkazo (talk) - Per all.
  13. Nintendo64Fan (talk) Per all

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!!"
  4. Baby Mario Bloops (talk) - Construction templates tell the user that work needs done. As a person that has spent many edits unstubifying, I know it is very tedious and hard. However, deleting the page will just create more red links, and from basic experience, will cause even more trouble to create that page later on than to unstubify it later on.

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! --B.wilson (talk) 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. As for what to do after the deadline has been passed ansd the article is still a stub, there's no need to use the same template to notify sysops of it deletion. It should just be replaced with {{Delete}} with the reason being something like "The article is a seven day new stub". 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)

Speaking of the GIF, why does the construction template get one? I wanted to change the picture to one of those Mario sprites from Wrecking Crew '98, but you know I can't. Sorry if a little off-topic, but the Donkey Kong Mario GIF in the construction template is a little distracting. We can also use a Wrecking Crew '98 sprite for the stub expansion template instead.LeftyGreenMario (talk)

I'm going to make this suggestion again: could you change the color of the template so it won't resemble the delete template at a glance? LeftyGreenMario (talk)

Done. B.wilson (talk) 01:40, 11 January 2012 (EST)

It is a bit messy to see {{Delete}} in your template, that needs some improvement. Like the template changes appearance at "deadline". Lakituthequick (talk)

I'm pretty happy with the changes made to the template, so I'll go ahead and support. There's no way to change the template's appearance automatically at deadline as far as I know and if we manually change it, we might as well replace it with the delete template since that will attract more attention from sysops. I agree though, there no need to include {{Delete}} inside the proposed template, just replace the proposed template with {{Delete}} and be done with it.--Knife (talk) 11:05, 11 January 2012 (EST)

I also think it'd look better with just the delete template, rather than nesting it inside the other template. If it has to be changed manually anyway, as Knife said, just replace it, and if it's done automatically, maybe make it so that the entire template is changed (i.e. if it's not expired, it looks like the Bullet Bill template, and if it's expired, it switches to the Bob-omb design mirroring the normal Deletion template). Also, if we're worried about stubs falling through the cracks even with this template, perhaps the articles marked with this pending-deletion template could be put into the Requested for Deletion category. Things in that category aren't deleted outright, and using it for this as well as its original template might help bring attention to the new stubs before their time is up and they join the real deletion queue. @LeftyGreenMario I forget why we added the gif in the first place - it's maybe because it's ugly and distracting and should therefore motivate people to want to fix the article just to get rid of it. Personally, I think we'd be better off just getting rid of the gif... - Walkazo (talk)

Removals

None at the moment.

Changes

None at the moment.

Miscellaneous

None at the moment.

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