Please remember that WiKirby contains spoilers, which you read at your own risk! See our general disclaimer for details.

WiKirby:Proposals

From WiKirby, your independent source of Kirby knowledge.
Jump to navigationJump to search
Your opinions matter!

Welcome to the Proposals page. Here, WiKirby's editors may propose changes to the way the wiki operates, including how to handle certain categories of content, quality standards, or even just making aesthetic suggestions. Any user who has Autopatrol status or above may make a proposal or vote on one, and after two weeks of voting, if it passes, it will be incorporated into policy. Please see below for the specifics on how to make and/or vote on a proposal.

How to make a proposal

Please use one of the following templates to make a new proposal:

Single vote: This is for proposals which only propose a single change to the wiki. 

==(insert proposal here) (insert date here)==
(insert details of proposal here and sign with ~~~~)
{{Support}}
{{Oppose}}
{{Neutral}}

===Discussion===

{{clear}}

Multi-option vote: This is for proposals which include many possible changes to a particular element of policy. One option should always be to keep things as they were. It is recommended that no more than 8 options are given in a single proposal, including the "no change" option. 

==(insert proposal here) (insert date here)==
(insert details of proposal here and sign with ~~~~)
{{Option|1|(option title 1)}}
{{Option|2|(option title 2)}}
{{Option|3|(option title 3)}}
{{Option|etc.|(option title etc.)}}
{{Neutral}}

===Discussion===

{{clear}}

Multi-facet vote: This is for proposals which want to make several smaller changes to a single element of policy (for instance, making several changes to how the main page looks). Each change needs to be voted up or down individually. There should not be more than 5 parts to a proposal like this. This type of proposal should not be made without approval from wiki administration. 

==(insert proposal here) (insert date here)==
(insert summary of proposal here and sign with ~~~~)
===Change 1===
(insert details here)
{{Support}}
{{Oppose}}
{{Neutral}}
====Change 1 discussion====

===Change 2===
(insert details here)
{{Support}}
{{Oppose}}
{{Neutral}}
====Change 2 discussion====

===Change 3===
(insert details here)
{{Support}}
{{Oppose}}
{{Neutral}}
====Change 3 discussion====

etc.

{{clear}}

Once a proposal is made, the voting period begins (see voting regulations below). Voting period for a proposal ends two weeks after it starts, at 23:59:59 UTC on the 14th full day of voting. An administrator can veto a proposal at any time, although such action should always be justifiable and agreed upon by multiple admins. Administrators should not use this right to add more weight to their own opinions.

Restrictions

Users may propose many different changes or additions to the wiki. The following things, however, may not be voted on:

  1. Proposals which target specific users (such as bestowing or removing ranks or rights).
  2. Proposals which violate the law, as specified in the general content policy.
  3. Proposals which seek to overturn a recently (within the last 8 weeks (or 56 days)) approved proposal.
  4. Re-submitted proposals which were recently (within the last 8 weeks (or 56 days)) rejected, and which have not been significantly altered.
Voting regulations
  1. Proposal adding and voting is open only to registered users who have attained Autopatrol status and above. Users who do not have Autopatrol+ may still participate in discussions.
  2. Users who are currently blocked will not be allowed to vote, and any outstanding votes they have on proposals will be removed. Any proposal made by a user who is blocked during the consideration period will also be removed.
  3. All votes must be signed with signatures (type four tildes (~~~~.)) Unsigned votes are automatically negated, regardless of any points made.
  4. After two (2) weeks of voting, a proposal will be immediately enacted if the number of supportive votes is greater than the number of opposing votes, or, in the case of multi-option votes, any option receives a plurality consisting of three or more votes. In the event of a tie, the proposal may be re-voted upon with a one week duration, or annulled by the administrators.
  5. In the event a proposal has seven (7) unanimous support votes OR ten (10) support votes and no more than two neutral votes, as well as the support of a bureaucrat, a proposal may pass in only one (1) week instead of two.
  6. If a supported proposal is vetoed by the administrators, it is considered failed and should not be started again for at least 8 weeks (56 days).
  7. If a proposal fails to garner three (3) supporting votes (or 3 votes on any one option in multi-option proposals), it will not be considered.
  8. The original proposal maker may not vote on their own proposal if it only contains two options (i.e., "yes" or "no" proposals). However, proposers may vote on their own proposals if they have three or more options.
  9. All votes must be supported by a substantial reason from the voter. Simple and/or unproductive comments like "I agree" or "No that's stupid" will result in the vote being removed.
  10. The original proposer may cancel the proposal for any reason during the first three (3) days of its run, and it will not be considered failed. Admins may veto subsequent proposals if this is abused.
  11. Voting users may change their vote at any time before a proposal's deadline passes, but should update their timestamp if doing so.
  12. Discussion must remain civil at all times! Any uncivil discussion will result in the offending users' votes being negated, and possibly lead to strikes or a block.
  13. Excessive campaigning for any proposals will result in the campaigner's vote(s) being negated, or proposal being removed if applicable.
  14. Proposals about minor article manipulation (such as splits, merges, renames, or deletions) should not be created, unless the scope of the discussion is particularly large; otherwise, these should be handled on a case-by-case basis, through discussions or polls on the talk page of the article in question.
  15. It is recommended that a single user make only one (1) proposal at a time. Though simultaneous proposals from the same user are allowed, they are discouraged; this should ideally only be done if multiple issues are in question, and not many proposals are already active.
  16. For multi-option votes, voters are encouraged (but not required) to indicate a first, second, third, etc. vote. The exception to this is neutral votes, which must be the only vote if chosen.

Current Proposals

Standardizing Discussion of Regional Differences (April 17, 2024 - May 1, 2024)

This is a problem I've had for a while now; I feel like the way we discuss regional differences is really unclear because it's focused on being too precise to the point of pedantic. Other wikis handle this in a more clear manner, so I feel like we should have a clear set of guidelines when discussing regional differences. These can probably go in the WiKirby:Localization policy.

  1. Prioritize American English in any instance where one language is required. Plain and simple; WiKirby is based in the US, so our articles use American English (the same reason why we voted to remove the LangSwitch template, as nobody was actively switching into British English). In this case, this would be related to page quotes and such where there are differences between the American English and British English versions. While we can list both in other sections, in places like page quotes where it's preferable to only have one, it would be best to prioritize the American version (see old versions of Landia for example, where it was cluttered by listing both versions of the quotes even though they only have minor differences).
  2. When discussing regional differences, discuss only the versions that are pertinent. For example, on Parallel Meta Knight, we have this: "The English, French, Italian, German, Spanish and Dutch localizations of Parallel Meta Knight's pause flavor text misinterpret his origin. As the original Japanese and localized Chinese and Korean texts describe:" That just leads to a signal-to-noise trainwreck; the pertinent versions to discuss here are the Japanese version (the original text) and the English version (the language the wiki uses). Mentioning the others is putting undue weight on a minor note. We can note somewhere that the Korean and Chinese versions generally follow the Japanese version while all other languages follow the English version. In cases where certain languages have peculiar differences, it's fine to mention them; for example, that Whispy Woods is localized as female in the Brazilian Portuguese version, or that the Mint Leaf is not a Sweet Potato in the Korean and Chinese versions. But if they follow the Japanese version or the English version identically or near-identically, it isn't worth noting. (Obviously, this wouldn't apply to the "names in other languages" section.)
  3. Using the terms "PAL" or "NTSC" to describe regional versions is fine. Nintendo officially used the term PAL to describe regional versions of their home consoles and games from the NES all the way up to the Wii, as they were designed to be used for PAL televisions. I can understand not wanting to use it for handhelds or for the Wii U or Switch, as this terminology is based on analog signals that are no longer used, but at least for the NES through the Wii, it is not only valid but official and commonly used terminology. Right now it's commonly switched to "British English", which is not accurate, or "European", which is fine but lacks coverage for Oceania. The same can also apply to NTSC being used for the North American and Japanese versions.
  4. Avoid the constructs "in American languages", "in European languages", etc. when referring to regional versions. For example, on Kirby Super Star or Kirby and the Rainbow Curse. In the former case "NTSC" and "PAL" would be fine, while if we want to avoid using "NTSC" and "PAL" in the latter case, then I think it would be better to just say the regions they were designed for and sold in; in the Americas, in Europe and Oceania. It can lead to confusion; for example, French comes from Europe, but Canada is part of America, so is Canadian French a European or an American language? It's not worth dealing with that question when we can just say "in the Americas".

That's my basic thoughts, anyway. I'm sure things can be ironed out more, but I want to standardize this so we avoid conflict and unnecessary confusion. StarPunch (talk) 23:42, 17 April 2024 (UTC)

1. Prioritize American English in any instance where one language is required.

Support
Oppose
Neutral

Discussion

2. When discussing regional differences, discuss only the versions that are pertinent.

Support
Oppose
Neutral

Discussion

3. Using the terms "PAL" or "NTSC" to describe regional versions is fine.

Support
Oppose
Neutral

Discussion

4. Avoid the constructs "in American languages", "in European languages", etc. when referring to regional versions.

Support
Oppose
Neutral

Discussion

Standardized Boss Moves Locations (April 6, 2024 - April 20, 2024)

Hi! We currently have boss moves put somewhat unevenly around the wiki, with some bosses having their moves recorded on their personal pages (King Dedede, Dark Matter Clone, etc.) and at least one boss I can't track down has them on their stage page. I think these should be standardized, and specifically I think they should go to the boss stage pages. This is because:

  1. Wiki-assisted players will have the convenience of the information being on the boss page, instead of having to go somewhere else to find the knowledge they need.
  2. This will put relevant information on boss stage pages, most of which aren't stubs, but still fairly short due to their nature of being mostly just an arena (except such as in Kirby Star Allies but it still won't hurt).
  3. This will mildly slim down several character pages, only having a major impact for the already lengthy pages of King Dedede and Meta Knight, and it doesn't much impact any other boss.

Thoughts? ~ by Waddlez! 23:02, 6 April 2024 (UTC)

Option 1: move to stage page

  1. My only preferred choice. ~ by Waddlez! 23:02, 6 April 2024 (UTC)
  2. Second choice. I can see the merit in having the info on the stage page, although ultimately we're not a strategy guide. Also any standardization is better than none. ---PinkYoshiFan 23:44, 6 April 2024 (UTC)

Option 2: move to boss's character/other page

  1. First choice. It's the moveset for the character, so it should go on their page. ---PinkYoshiFan 23:44, 6 April 2024 (UTC)
  2. Primary (and only) choice. Not just because the attack tables would be better off for the character but also because of a potential problem regarding bosses exclusive to circumstances like The Ultimate Choice. More details in the Discussion section. – Owencrazyboy17 (talk) 23:55, 6 April 2024 (UTC)
  3. Single choice here. As stated, this is the boss character we're talking about, so it wouldn't make as much sense to put the move-set where the boss appears when the boss has its own page.--Paistrie (talk) 16:00, 10 April 2024 (UTC)
  4. It makes far more sense to me to list all the moves on one page given that boss moves tend to evolve over time. We could easily use an {{main}} on stage pages to link to the move listing page wherever that is. --Basic Person (talk/contribs) 19:36, 11 April 2024 (UTC)
  5. I think having boss moves on their own makes the most sense for bosses and I think it'd be best to have these instead of putting them on location pages, mostly because it would be awkward for bosses that only appear in Arena modes. NVS Pixel (talk) 13:14, 12 April 2024 (UTC)
  6. First option, and this is already what we do. Stage pages don't make sense when Kirby has many bosses exclusive to game modes like arenas, and putting boss details there would make giant pages. A boss page should cover info about a boss, and a stage page info about the stage. - Gigi (talk • edits) 13:36, 12 April 2024 (UTC)

Option 3: make no changes

  1. Second option, although this is essentially the same as option 2, as we already only put boss moves in boss/character pages. For reasoning, same as option 2. - Gigi (talk • edits) 13:36, 12 April 2024 (UTC)

Discussion

I thought of a bit of a major issue when it comes to option 1. Say, for example, a boss was fought exclusively in The True Arena or another location or mode with no defined stage count. If option 1 passed with the majority of votes...then how on earth would an attack table for a boss like Chaos Elfilis even work?! Wonder if there's some sort of solution that I'm not seeing... – Owencrazyboy17 (talk) 23:55, 6 April 2024 (UTC)

I'd just put it on the Colosseum page under an exclusive boss heading, myself. They wouldn't be the only exclusive boss there... I get why that might not be appealing to some if the page is just intended to describe the mode but I think that's a good solution should option 1 be passed. Alternatively, special cases could be made for them, but that'd ruin the whole standardization idea.
I'm not fond of putting it under character pages because seeing what a boss uses in each fight over a vast number of games really isn't as useful as having info about the boss in the page about where you fight it, in my opinion. ~ by Waddlez! 00:04, 7 April 2024 (UTC)

Like I mentioned on Discord, I am a bit confused on this proposal's existence. As far as I know, where to put boss attacks is already standardized, and that is to say to put it in the character/boss page, which would make option 2 and 3 the same. - Gigi (talk • edits) 12:44, 10 April 2024 (UTC)

I can see the merit of moving it to the stage pages, as this would help somewhat with clogged character pages or pages for characters with multiple boss appearances where the moveset just gets listed over and over again (for example, King Dedede, Meta Knight, Kracko). I find those inconvenient. But I'm not sure if that's the proper solution to the problem, when it's probably a deeper underlying problem we can find a better way to handle. StarPunch (talk) 16:23, 10 April 2024 (UTC)
On Discord I proposed for recurring characters that are also bosses (mostly Dedede and Meta Knight) we should have separate boss pages for them, so that's another idea. That in general appears to be a problem for characters that appear in more than one game and aren't always bosses. - Gigi (talk • edits) 13:39, 12 April 2024 (UTC)

Add a guideline to discourage edits that don't correct or add any new information (April 10, 2024 - April 24, 2024)

Mentioned this a couple times in the past week or so about this, and finally it's time to make it a proper proposal.

For context, while not that common, sometimes there are edits on WiKirby that simply change a part of the text to one thing or another and both the version before and after the edit are correct and not incomplete. Two major examples are adding or removing the Oxford comma, and adding or removing contractions to words (don't to do not, for example, and vice-versa): both are correct in English, so there is little to no point in changing from one way or another. In particular, due to both ways being correct, this can easily create a dispute between editors, and in the end there is no real resolution as there is no one way that is more correct or incorrect. So, in a similar vein to other past proposals (see here and here), my proposal is to add a new mantra to the writing specifics, that is something like:

Don't correct what is correct - Unless something is incorrect, don't correct it.

(The above can be reworded of course, this is just my first idea, feel free to suggest changes)

Also, for clarification, this is not to say that we shouldn't change European English spelling to American English, that is a guideline we have on WiKirby to prefer American English stuff so that is unrelated to this proposal, and any other specific rules we may have about how to write things is also unrelated to this proposal. To put it another way, if there is no specific guideline on WiKirby to say we should say one thing one way or another, an editor shouldn't come to a page to just change it because they prefer it another way. While this mostly applies to spelling, this could be expanded to for example to changing mentions of NTSC and PAL to North American and European: as there's no rule (at least right now) on WiKirby to prefer one way or the other, there shouldn't be edits to "correct" these one way or the other.

What do you all think? - Gigi (talk • edits) 16:13, 10 April 2024 (UTC)

Support
  1. Agreed, there's no real reason to change things that are correct. ---PinkYoshiFan 16:18, 10 April 2024 (UTC)
  2. Right, there's definitely a distinction to be had between fixing up writing to match the writing guidelines and just doing pointless style edits that don't add anything. A lot of wikis have a similar mantra, sometimes phrased as "first come, first served". If it's not incorrect, there's no need to do an edit solely to change it to your preferred style. Whatever is there first should stay there, as long as it's correct and consistent. StarPunch (talk) 16:23, 10 April 2024 (UTC)
  3. I also agree. As was previously stated, if the initial wording was perfectly fine...why bother changing it? The only exception for me is applying that train of thought to using outdated video signal terminology for regional video game releases (especially since modern sources like NSO go with the standard "NA and EU version" route), but I don't think it's that pressing a concern right now. – Owencrazyboy17 (talk) 16:48, 10 April 2024 (UTC)
  4. Supporting. Spelling is definitely something some people have strong opinions and preferences, even when both options are correct, so having a policy like that to prevent arguments is good. Superbound (talk) 19:18, 11 April 2024 (UTC)
  5. I think this is a good thing to clarify. That said, I should warn you now that this likely will not stop certain users from insisting that certain things (like the Oxford comma situation) are correct, so it probably won't stop most edit wars on these grounds. At the very least, it gives the admins firmer ground, so supporting regardless. --Samwell (talk) 19:26, 11 April 2024 (UTC)
  6. I concur with those above about this subject. However, I feel as though the current proposed message could be a bit more descriptive and outright include some along the lines of: "No minor wording changes" just to be more specific and clear. --Basic Person (talk/contribs) 19:36, 11 April 2024 (UTC)
Oppose
Neutral

Discussion

Proposal Archive

Successful proposals
Failed proposals
Withdrawn proposals

Basic help
Getting started • Categories • Colors • Disambiguation • File uploading • Formatting • Formatting file pages • Moving pages • Protected Page • Redirects • References • Tables • Talk pages • Templates • User Navigation Bar • Userboxes
Advanced help
Advanced tables • Creating navmaps • Creating templates • Custom Signatures • HTML • Page history • Special pages • Tabs • Template documentation • Using infoboxes
Policies
Abbreviations • Article creation • Article manipulation • Audio standards • Blocking of users • Categories • Citing • Community polls • Conjecture • Cookies • Copyrights • Deletion of content • Disputes • Featured content • File use • Formatting specifics • General content • General disclaimer • Glitch disclaimer notes • Glitches • Image standards • Infoboxes and Navboxes • Interwiki • Language • Layout • Localization • Long pages • Naming • Non-Kirby content • Personal content • Privacy • Sourcing standards • Stubs • Talk pages • Trivia sections • User accounts • Videos • Writing style • Writing specifics
Useful links
About WiKirby • Affiliates • April Fools • Archive • Current events • Dedication • Discord • Featured Article Nomination • Featured Picture Nomination • Good recommendations • IPA • Maintenance (Project Clean-Up) • Proposals • Ranks (Bots • Check user • Editor-in-Chief • System Admin) • Sandbox • Social media • Special pages
KSA Parasol Waddle Dee Pause Screen Artwork.png
Retrieved from "https://wikirby.com/w/index.php?title=WiKirby:Proposals&oldid=469932"