MarioWiki:Proposals

List of Talk Page Proposals

 * Merge Kat and Ana's Swords with Kat and Ana (Discuss) Deadline: July 10, 2014, 23:59 GMT
 * Merge Giant Star with Grand Star (Discuss) Deadline: July 13, 2014, 23:59 GMT
 * Merge Dribble and Spitz's taxi with Dribble and Spitz (Discuss) Deadline: July 15, 2014, 23:59 GMT
 * Delete Super MakerMatic 21 (Discuss) Deadline: July 15, 2014, 23:59 GMT
 * Merge The Goodwill Ambassador to Cackletta (Discuss) Deadline: July 19, 2014, 23:59 GMT
 * Split Red Luma, Green Luma and Blue Luma from Luma (species) (Discuss) Deadline: July 19, 2014, 23:59 GMT

Writing Guidelines
None at the moment.

New features
None at the moment.

Removals
None at the moment.

Rewrite some of the help pages to make them less complicated
I have noticed that some of the help pages aren't too clear about what you're supposed to do and that may misguide a lot of newbies on the Wiki. Help pages on Userbox templates and signatures for example, aren't pretty clear on how to make the color changes and don't contain the color codes and that isn't straightforward for a newbie to do. The rewrite of the pages would make them explained in clear detail and it will tell the newbie on what code should be entered with a table on the commands that they can use including their functionality. They look hard for some newbies to understand correctly and they will be confused so I'd figured the Wiki can have the pages rewritten so that everyone can understand it. That just makes things less complicated

Proposer: Deadline: July 11, 2014, 23:59 GMT

Rewrite

 * 1) Per my proposal.

Keep pages as is

 * 1) Listing all the color codes would be completely impractical, and it's not that hard to just swap out some code.
 * 2) I cann't see the point of it... I know that Help:Template have a expand template (LOL) but the others are OK. And if a new user cann't unterstand something, just ask to someone!
 * 3) - If a Help page (or any other official policy page) is lacking, you can always make a new draft yourself and show it to the admins for approval: you don't even need proposals for that. You could also use the Wiki Collabs board to highlight specific pages that need work and ask admins or other users to help. Either way, a Proposal vaguely calling for Help pages in general to be rewritten is the wrong way to go about this.
 * 4) Per Walkazo.
 * 5) Per all.
 * 6) Per myself in the comments.
 * 7) While what Walkazo has proposed is a bit far from ideal, there's no need to rewrite help pages.

Comments
Just so you know, if you need help, you can contact another user.  At last, the rock fell.
 * Whoops I didn't know that there is no need for a proposal like this but I find it hard to re word the help pages and I want to see if the Wiki community agrees with the idea or not.

Do something about multiple proposals
Of course, some (but, of course, not all) users remember when created a proposal composed of multiple proposals inside of it. Said proposal was ridden of by the Admins because "the formatting is nigh-incomprehensible". To prevent against this misunderstanding in future proposals, I propose we make a guideline about multiple proposals; should we allow them, or should we deny them?

Should the proposal pass either way, then an administator can amend a new rule to Proposals/Header to determine the outcome of the proposal.

Proposer: Deadline: July 16, 2014, 23:59 GMT.

Allow them

 * 1) Unless I misinterpret this, what you're saying is ban proposals with more than one option. This is ridiculous, as certain proposals may need separate options. You seem to be basing this off one example, and yet proposals with multiples options have worked successfully in the past, there is no reason they should no longer be allowed because of one bad one.
 * 2) Per Yoshi876
 * 3) Personally, I see this as a good idea, as it allows multiple things to take place with a similar line of reasoning instead of making another proposal that is essentially the same but with a different line of action.
 * 4) I don't see anything wrong in them, but the one of example is definitely confusing. I agree, but there should be a limit of proposals regarding the same argoument in it.

Deny them

 * 1) I honestly see no point in doing them (whoa, that was bad English); first, they clutter the proposal system at deadline, and second, the mini-proposals inside of them can be separate proposals.
 * 2) It's really confusing and long.
 * 3) - Like I said in the comments, we shouldn't have to spell it out that this sorta wholly-unnecessary, very specific abuse of the proposals system isn't allowed, but I'd rather explicitly vote "no" than risk sitting by while the "allow" option passes.
 * 4) Per all.
 * 5) Per Walkazo

Comments
@Yoshi876: Just so you know, this regards multiple proposals, not proposals with multiple options.  At last, the rock fell.
 * If by that you mean two proposals in one, there has never been a case of that and if a case arises and it's formatted in a comprehensible way there is no reason for why it shouldn't be allowed. Mario7's was formatted badly, but was just one proposal.


 * Yarg, edit conflict twiiiice... Anyway, one proposal is an example, and I really don't see how it could be done in a way that's not pointlessly convoluted: if there's multiple ideas, just make multiple proposals, or make one multi-option proposal, and if it can't be chopped up or boiled down to that, it's probably not a good idea in the first place. -
 * I think the only reason one would need to be done is if there are multiple similar ideas, although I don't see how it couldn't be covered by a multi-option proposal.

I'm generally in favor of this. If you have multiple ideas, present multiple proposals, as Walkazo said. If it can't be reduced to several proposals, then either bring it to the forums for further discussion or drop it as a bad idea. On the other hand, we've only had one instance of someone trying to pull something like that. One instance is generally not enough to suddenly jump on the S.S. Banwagon about something. -- Ghost Jam 19:58, 9 July 2014 (EDT)


 * Technically, we already have grounds to remove random stuff anyway thanks to the "This is an example of what your proposal must look like, if you want it to be acknowledged." line in the "Basic proposal and Support/Oppose format". It's not worded more strongly ("do it this way or we'll remove it, bucko") because we're a nice community and if someone doesn't format a proposal correctly but has at least the basic gist down, someone usually comes along and fixes it for them instead of killing it, but stretching that leniency to the point of nested multi-proposals is unreasonable, and we shouldn't have to single-out this one very specific abuse of the system as something that one should not do. -

Arrgg, this proposal is very misleading and confusing. If this is dealing with multi-option proposal, I oppose because it doesn't hurt and in fact adds to the proposal itself and the way they are handled. If this is dealing with mini-proposals in one, then I kinda support, especially because discussing the matter first can reduce the situation, just start the discussion on the talk page, or the forums, and when things are arranged, propose it. However, I said kinda, because like what Walkazo said, it is just one example. The new rule is not necessary, but it doesn't hurt.-- 14:57, 10 July 2014 (EDT)
 * Don't worry, it's not about multi-option proposals: check the example provided - it's when you have multiple proposals nested under one overall proposer header, instead of being presented as a single multi-option proposal or simply set up as completely separate proposals (like they're supposed to be be). Really, all we're doing here is voting on something that's already not allowed; it's redundant and saddening that's it's coming to this, but yeah, the only real harm that could come of it is if the "allow" side passes. -