Latest revision as of 14:19, 5 January 2024

Successful proposals archives
Proposals passed in 2023
Proposals passed in 2022
Proposals passed in 2021
Proposals passed in 2020

The following proposals have been successfully passed by WiKirby's community. For older proposals, check the box to the right:

Proposals

Standardize wiki text to favor some words without hyphens (December 17th, 2023 - December 24th, 2023)

I honestly don't know what else to name this, nor exactly how to word it as a guideline eventually. But these five words in particular have been brought up by many different editors over the years, and it has caused some confusion of new editors and sometimes even readers.

You are reading an article, and it writes "moveset" for one section. You keep reading and another section calls it "move-set". Does that sound familiar?

Move-set, cut-scene, mid-air, 3-D and 2-D are the five most common words I've seen on WiKirby article text that are sometimes spelled with hyphens, sometimes not. In particular, most of these five words are mostly commonly spelled without hyphens (which I will prove soon), and in official Kirby text, we've only had usages of them without hyphens as far as I know (although for "moveset", I haven't really seen any official use of the word in any form). You are free to correct me if I'm wrong on official usage, but in particular for 3D and 2D, I've fairly sure of that, at least in recent sources. And, I mean, it's the Nintendo 3DS and 2DS, not 3-DS and 2-DS...

Point is, there is no standardization, so some articles use them with hyphens, some without, some mix and match, and it's not uncommon for editors to go and "fix" to one way or the other. But without a rule, anyone could revert these changes and go "actually, I prefer with/without hyphen". Also, as I mentioned, it's clear that the most common forms of these five words are without hyphens, being used in official Kirby media as well.

With all these in mind, my proposal is to standardize the spelling of these words, much how we favor spelling of words in American English, to the following:

Cutscene over cut-scene. "Cutscene" has 33 million results in Google, while "cut-scene" has 3 million. One example of "cutscene" being used in official Kirby media, Miiverse posts: List of HAL Laboratory Miiverse posts - Kirby: Triple Deluxe;
Moveset over move-set. "Moveset" has 15 million results on Google, while "move-set" has 1.5 million (with many actually resulting in finding "move set", and not "move-set"). I don't actually know any examples of official Kirby media using the word in either form;
Midair over mid-air. This one is the only one basically tied on Google: "midair" has 18 million results on Google, while "mid-air" has 22 million. However, officially Kirby has only ever used "midair", in moveset descriptions;
3D over 3-D. "3D" has 3.6 billion results on Google, while "3-D" has 276 million. Many names use "3D" and none use "3-D", such as 3D Classics: Kirby's Adventure, 3D Helmet Cannon, 3D Warp Star etc. Descriptions of Forgotten Land in particular use 3D, such as the one on Nintendo's website;
2D over 2-D. "2D" has 1.2 billion results on Google, while "2-D" has 214 million (should mention though that a good number of the results actually are for the Gorillaz member). For consistency with "3D". I don't know of many sources that use "2D", but at least this interview I translated used it (yes, even in the original Japanese text).

So, what do you all think? I think something like this is long overdue. I accept suggestions on where/how to word it, but I feel this is something we need to officially address in some form. - Gigi (talk • edits) 19:14, 17 December 2023 (UTC)

Support

I definitely agree that it should be standardized. For every example other than move-set, it automatically makes the most sense to spell it without a hyphen, since that's what official Kirby media does. For every example other than mid-air, it's more commonly spelled without a hyphen online. And for all examples, I personally think it just looks better without a hyphen. - RHVGamer (talk · edits) 19:34, 17 December 2023 (UTC)
Standardization is good, especially when it matches Kirby media. ---Pink Yoshi Fan 21:33, 17 December 2023 (UTC)
I'm in favor of consistency, especially considering how most of these terms have spelling variant that is clearly more common than the other. Typman (talk) 22:40, 17 December 2023 (UTC)
I agree. Consistency is cool. --Paistrie (talk) 00:06, 18 December 2023 (UTC)
Support. (And even if moveset isn't confirmed anywhere I prefer that, which isn't what we're going for but still consistent) ShadowKirby (t/c) a.k.a. your new overlord ShadowMagolor 07:14, 18 December 2023 (UTC)
Consistency is important, so support. -- (profile ::: talk) 13:54, 18 December 2023 (UTC)
Consistency is always appreciated, support. Infinite Possibilities (talk) 19:52, 19 December 2023 (UTC)
Though I still prefer “move set”, a more formal spelling used by Smash Bros., all four others are entered in the Merriam-Webster and New Oxford American dictionaries unhyphenated. And in any case, consistency is always a good idea. -YFJ (talk · edits) 22:57, 19 December 2023 (UTC)
I agree. There's not really anything I can say to support it since everyone else had the same idea, but it holds the same weight. ~☆Star void⁠☆ (t · c) 23:15, 19 December 2023 (UTC)
This is on the same level as (for example) having articles written in third person and in present tense by default, and likewise should be part of the style guide. —willidleaway [talk | edits] 00:35, 20 December 2023 (UTC)

Oppose

Neutral

Discussion

I don't think this changes much, but looks like Miiverse also used "cut-scene" once: https://web.archive.org/https://miiverse.nintendo.net/posts/AYMHAAACAADRUqGa3vd22Q However, "cutscene" was used in two posts after, in particular one of these posts had the word used like "cutscene" 10 times this and this. - Gigi (talk • edits) 17:02, 22 December 2023 (UTC)

Adjust/Remove Proposal Rule 15 (16 November 2023 – 30 November 2023)

As can be seen dueing the time of this proposal, technically it's already being bent, but it would be good to get things straight. There is no real reason to have the "1 proposal at a time per user" rule, because, realistically, either a user with good ideas would have to wait to share them, or a productive user just simply wouldn't have a second+ idea to share. Making proposals is limited to Autopatrol+ anyway, so it's not like we have to worry about the quality and good intentions of the user making the proposal. In short, I don't think this rule is necessary. However, when brought up on Discord, there was the thought that it should still be discouraged to have more than 1 up, which would be a warning against funny business. That's where the voting comes in (for logical reasons, a vote for either of the first 2 options is still a vote in favour of changing the rule, the difference is in the extent of the change). ShadowKirby (t/c) a.k.a. your new overlord ShadowMagolor 18:16, 16 November 2023 (UTC)

Option 1: Remove rule

Strongly support its complete and total abolition. It is, for all intents and purposes, useless. It unnecessarily delays proceedings and discredits ideas simply because the same user proposed another one. If it really became a problem, that's what admin vetoes are for. Not that I think that'd ever happen. --YFJ (talk · edits) 18:56, 16 November 2023 (UTC)
I don't really see a point in discouraging to much. I don't think it does much harm to have more than one proposal from the same person, as long as it's not done maliciously or anything. --Basic Person (talk/contribs) 22:03, 16 November 2023 (UTC)
The fact the rule is already being broken without so much as an objection should speak for itself on how good a rule it is, and "discourage" is vague and not very actionable, would we just arbitrarily start deleting proposals for no reason other than there being too many? Better to just either keep the rule or not for clarity's sake. Or if people are really opposed to the idea of one person making too many proposals at once, we could have a limit on how many one user can have (maybe two or three). Hewer (talk · contributions) 18:41, 18 November 2023 (UTC)
I understand the concern about too many proposals too fast, but I think that's something anyone with common sense should understand. If it's really necessary (not really IMO) then it can be left as a reminder/suggestion, but the rule is practically made to be broken. Waddlez3121 (talk) 23:13, 19 November 2023 (UTC)

Option 2: Discourage but not disallow

I feel like most people would try to keep the number of proposals down to a reasonable extent anyways, but I think discouraging it would still be good. ---Pink Yoshi Fan 18:33, 16 November 2023 (UTC)
Agree on making it "discouraged but not disallowed". We don't want to have a ton of proposals at once (right now I already feel like we have a bit too many), but there's no reason for the same user not to make multiple proposals at once aside from that, especially if they're all related changes. StarPunch (talk) 23:12, 16 November 2023 (UTC)
This option seems to be the most reasonable because a large amount of proposals might be too overwhelming for some. There should only be more than the usual amount of these occasionally. --Paistrie (talk) 21:02, 17 November 2023 (UTC)
I feel we don't need to restrict that much but I also think it's good to make editors keep in mind that we don't want someone to suggest many changes that fast. - Gigi (talk • edits) 17:53, 18 November 2023 (UTC)
Pretty much what the others above said. Having a reminder that multiple proposals from the same person are allowed, but discouraging it is the best way to do it imho. Infinite Possibilities (talk) 17:33, 30 November 2023 (UTC)

Option 3: Keep as is (Opposed)

Neutral

Discussion

Disallow links in quotes, flavor text, etc (November 16th, 2023 - November 30th, 2023)

I will admit this is minor all things considered, but this has bothered me for a long time. To give an example, take Magolor's quote from his page:

“

Hi there! My name is Magolor. I'm from another dimension, but I just love Planet Popstar. I can't get enough of it! Things got a bit hectic when I first arrived, but that's all in the past, thanks to Kirby.

”

— Magolor's opening dialogue from New Challenge Stages in Kirby's Dream Collection Special Edition

As you can see, this features colored text. Orange and... wait a second, blue text?

Well, yeah, these are links to other pages. However, from a quick glance, one could confuse them with colored text, since there is colored text from the actual game before (in orange). Keep in mind I am only talking about Magolor's own quote, not the text after that has links to New Challenge Stages and Kirby's Dream Collection Special Edition: those are fine to stay, as they aren't quotes.

Take another example from Magolor's page:

“

Anyway... MUAHAHAHAHAHAHAHA! The time has come for your planet... No! The time has come for the ENTIRE UNIVERSE to bow down to me. And for being such a big help in all of this, your planet gets to go first! Prepare to bow, Popstar! Welcome your new overlord!

”

— Magolor in Kirby's Return to Dream Land

This one actually features no colored text from the game, but the link to Popstar makes that blue, and one could think this is blue in the game, no? I mean, the emphasis on Popstar would make sense. In short, this misleads the reader.

But you may argue that in Kirby games all colored text is orange/red/yellow, so with the links being blue it's not a problem, since they will always be clearly links. Well, that is the problem: there is colored text with blue text.

New Challenge Stages challenge descriptions like Sword Challenge (New Challenge Stages):

“

Can you master the king of weapon-based Copy Abilities?

”

— Sword Challenge Caption

Pause descriptions in Kirby Super Star Ultra like Suplex:

This burns with fighting spirit! Grab foes and throw 'em! Learn all 8 throws to be a champ!

Just to name a few. So, personally, we should just get rid of links in any text like that to prevent confusion. And last but not least, another reason I don't like links in text like this is how they often use piped links. Take this one about Kracko as an example:

“

YOU...! Did you think I'd forget? The time you smashed into me with your Hi-Jump! That time I was betrayed by Helpers! Or when I was replaced by that mechanical cloud! I-I... Sniff... there's something in my eye...

”

— VS Kracko (Very Hard) Pause Screen description in the American English version of Kirby Fighters Deluxe

It feels really unprofessional to add piped links to "YOU...!", "time" and "when", and the one for "mechanical cloud" like spoils what this is about. I dunno, I never liked it for this reason as well.

To conclude all this, basically, to put it another way, my proposal is to disallow links in any text that is not authored by a wiki editor, so quotes (both from characters and developers), flavor text, official descriptions, translations of anything else that applies, and so on. Just how right now the formatting specifics says that links in section headers should be avoided, my proposal is to also write something like that in that page about quotes, flavor text etc. What do you all think? - Gigi (talk • edits) 15:02, 16 November 2023 (UTC)

Support

Agreed, I can definitely see how it can get confusing. ---Pink Yoshi Fan 15:31, 16 November 2023 (UTC)
Yeah unless there would be a way to change the link color this should not be a thing. --Basic Person (talk/contribs) 22:03, 16 November 2023 (UTC)
Support. I agree it makes things confusing. I know some wikis do this (like Mario Wiki), but when we're using colored text it adds ambiguity, so it should really only be one or the other, and I prefer having the colored text. StarPunch (talk) 23:12, 16 November 2023 (UTC)
Agreed. It'll be much less confusing like this, and we can just put the necessary links in the page's main text. --Deep Fried Cabbage 07:22, 19 November 2023 (UTC)
Though I am a bit torn on this one, I think it’s probably a better idea to get rid of them to reduce ambiguity. If context is really necessary, we have footnotes for that, and most of these links are pretty unnecessary. --YFJ (talk · edits) 20:44, 19 November 2023 (UTC)
I was feeling pretty neutral on this but the flavour text examples make the potential for confusion extremely clear. If something needs a contextual clue either footnotes or even {{explain}} might be better suited. —willidleaway [talk | edits] 00:07, 20 November 2023 (UTC)
The examples listed above are pretty self-explanatory as to how confusing things will be if the possibility for linking within such quotes sticks around. I don't think there's much else for me to say that hasn't already been said, so...Per all. – Owencrazyboy17 (talk) 02:13, 24 November 2023 (UTC)
Nothing much to add, I agree that due to blue colored text existing in some games and the possibility that readers think emphasis is placed on the words with links, even if it isn't, are good reasons to disallow them going forward. Infinite Possibilities (talk) 17:44, 30 November 2023 (UTC)

Oppose

First off, we have a policy on spoilers: spoil them. The games are the place for plot twists, not the wiki, which is for the facts. Second, while I do think the colors themselves get confusing, I think the only ways to keep the links (important for context) would be very clunky, and that just won't do. Piped links also literally just boil down to how you feel about them as opposed to whether they're helpful or not, which I think most are. Waddlez3121 (talk) 23:08, 19 November 2023 (UTC)

Neutral

Hm...not too sure about this one. On one hand, it does make the colored text subject less confusing, but on the other hand, the links would help some people understand the context of certain quotes... --Paistrie (talk) 15:59, 16 November 2023 (UTC)
I agree with Paistrie. For a person who doesn't have as much knowledge on the series, the links could help them out. But for us/people with more knowledge on the series, it might feel like a visual nuisance. (Though I use a custom theme for Wikirby, so it shows up as black and not blue, therefore this doesn't affect me.) ~☆Star void⁠☆ (t · c) 18:55, 18 November 2023 (UTC)

Discussion

Just a couple things I noted on Discord that may help clarify why I also suggested this proposal:

Most of the time I see links in descriptions or quotes they are repeat links or subjects linked can be linked in article text. Basically, they are almost never needed
In a way adding links and stuff (basically editing a text you didn't write) always felt to me like we are editing something we didn't make, which for me is wrong. That's why often if someone quotes someone and for example bolds the text, something like "emphasis mine" is added to clarify their edits to the original text

So, basically, I don't see why these links are needed, and they do more harm than good. - Gigi (talk • edits) 17:00, 16 November 2023 (UTC)

I understand what you mean here, but I still think that the links are helpful for context. When I first started reading article pages on this wiki, some of the links did help me understand what some characters meant (the "mechanical" in that Kracko quote for example). However, of course, I can only speak for myself here. Maybe, if possible, the links could be recolored? (If that's impossible, then the links could be deleted.) --Paistrie (talk) 20:25, 16 November 2023 (UTC)

The links can be recolored like this (also most custom signatures do this, including my own), but having black links seems like it would be confusing and any color besides black would cause the same issues being brought up here. ---Pink Yoshi Fan 02:41, 17 November 2023 (UTC)

Abolish Proposal Rule 8 (16 November 2023 – 30 November 2023)

I know, I know. "Isn't that just one free support vote for every single proposal?" Hear me out.

First off, many proposals aren't as simple as yes or no. Sometimes there are multiple options, and the original proposer may not like one but include it anyway as a courtesy. Alternatively, a person may wish to make a proposal to settle a controversy, and he or she may still prefer to do nothing. In any case, I think there are sufficient reasons not to rule the proposer unable to vote at all, especially since, in many cases, the proposer is the one with the strongest opinions on the topic.

Of course, I'll leave that decision up to you all. --YFJ (talk · edits) 07:04, 16 November 2023 (UTC)

EDIT: I have added a new option per the comments in Neutral. Though I still support the complete abolition of the rule, as I feel the proposer's opinion should still count for something (and as said before, there are reasons one might choose to oppose or remain neutral on one's own proposal), it's certainly a preferable option to the status quo. --YFJ (talk · edits) 21:25, 16 November 2023 (UTC)

Option 1: Complete abolition

Even outside of the multiple options scenario, I think the vote of whoever propeses should also count for something outside of presenting the idea, so support. ShadowKirby (t/c) a.k.a. your new overlord ShadowMagolor 07:23, 16 November 2023 (UTC)
I don't really see what the problem is with it being a free support vote - the opinion of the person who happened to be the one to make the proposal should be just as valid as everyone else's. Hewer (talk · contributions) 18:10, 18 November 2023 (UTC)
~~#Agreed, the proposer being barred from voting doesn't really work for multiple-option votes. ---Pink Yoshi Fan 13:46, 16 November 2023 (UTC)~~

Option 2: Narrow scope of rule to two-option proposals only

Per reasons for voting for option 1 before this one was added, the main concern is multiple-option votes. ---Pink Yoshi Fan 21:58, 16 November 2023 (UTC)
Changing my vote to this, for the reasons I wrote in my original vote for neutral. - Gigi (talk • edits) 17:04, 22 November 2023 (UTC)
Voting this based on my inital vote for neutral before this option was added. Infinite Possibilities (talk) 17:49, 30 November 2023 (UTC)

Option 3: Leave as-is

Neutral

#I feel it should be fine but only on multi-choice proposals. For proposals like this one, where it's just support, oppose, neutral, allowing the person who posted the proposal to vote will basically mean a free support vote for it. For multi-choice, I can see the point since the person who wrote the proposal will have one prefence among many others. So, personally, if this passes, I would prefer that it would with that note. - Gigi (talk • edits) 13:59, 16 November 2023 (UTC)
#I pretty much agree with what Gigi wrote above. While the argument of "it's just a free support vote" doesn't apply to multi-choice proposals, I do feel like keeping the rule for yes or no proposals only would make for a better change. Infinite Possibilities (talk) 15:47, 16 November 2023 (UTC)

I also agree on making it "allow the creator to support their preferred choice on multiple-choice proposals" (which I think is standard policy for most other wikis) rather than getting rid of the rule entirely, since we would want to avoid it just being a free vote on "yes or no" proposals. StarPunch (talk) 23:12, 16 November 2023 (UTC)

Discussion

Change voting rules for multi-option votes (16 November 2023 – 23 November 2023)

Our proposal header warns of the infamous spoiler effect. I think we can do better than that.

For the uninformed: the spoiler effect occurs when, in a three-option proposal, Option A and Option B both score 30 % of the vote while Option C scores 40 %. Option C wins a plurality, but if Options A and B are similar, this means that the majority opposed Option C and it still won out. It's a strong weakness of plurality voting and encourages strategic voting (voting for a less-preferred option in order to prevent the least-preferred option from winning). What can we do about it? Here are our options:

Instant runoff voting: The best solution, in my opinion. Sometimes called "ranked choice voting", it essentially allows you to give differently-weighted votes to different options. I'll give you an example right now: this is my first choice, "multi-option voting" is my second choice and "plurality voting" is my third. If "instant runoff voting" has the least first-choice votes, my vote doesn't lose significance; it instead moves to "multi-option voting", my second choice. This single-elimination process continues until one option remains. Note: Neutral voters would not be allowed to vote on any other option, unless they remove their "neutral" votes.

Multi-option voting: Didn't understand the last option? This might be simpler. You can cast a vote on all options minus one, if you so choose. These votes would all be equally weighted. This is the system preferred on some other NIWA wikis, such as the Super Mario Wiki, to give you an idea. Note: Just as in the above option, neutral voters may not vote for any other option.

Plurality voting: Self-explanatory: do nothing and leave the voting system as-is.

So what'll it be? My preferred option is instant runoff voting, but that's for you all to decide. --YFJ (talk · edits) 07:04, 16 November 2023 (UTC)

EDIT: Important clarification: this proposal would only take effect for proposals following its passage. It does not affect proposals currently ongoing. Also, check out Wikipedia's useful flow chart illustrating instant runoff voting, and this example I made of how it would work in practice. --YFJ (talk · edits) 01:41, 18 November 2023 (UTC)

Option 1: Instant runoff (ranked choice) voting

It took a bit to grasp, but it seems right to count a vote towards something else if another one fails. Would note that one should be able to choose to vote for one option and one option only if they so choose. This option seems to prevent proposals from getting stale due to having more popular options unresolved. Not entirely sure how it'd work in practice but in theory I like this. ShadowKirby (t/c) a.k.a. your new overlord ShadowMagolor 07:23, 16 November 2023 (UTC)
If I'm understanding this correctly then it does seem like the best option. ---Pink Yoshi Fan 13:46, 16 November 2023 (UTC)
Certainly agree about the whole thing about multi-choice proposals. I've often come across times where I notice many people don't want a certain choice to win but then split on voting on two or more options, then the option with most rejection wins still. This would be my preferred method to counter that. I just wonder how to format the voting, but I suppose people can just comment on each option and go "this is my first choice", "this is my second choice" etc. - Gigi (talk • edits) 13:59, 16 November 2023 (UTC)
Using a system that discourages strategic voting seems like a good idea. I support it. Typman (talk) 18:17, 16 November 2023 (UTC)
We already do this for referendums so I don't see why not for regular proposals. --Basic Person (talk/contribs) 22:03, 16 November 2023 (UTC)
Yes, I agree on this, since this is close to how referendums work on the wiki already. It would definitely help avoid situations where a less-popular choice wins because the vote is split between two opposing options. StarPunch (talk) 23:12, 16 November 2023 (UTC)
This feels like the better option. If your first choice doesn't work, it goes toward your second, then third, etc. That way your opinions aren't held to strategy, but preferences. ~☆Star void⁠☆ (t · c) 19:10, 18 November 2023 (UTC)

Option 2: Multi-option voting

Option 3: Plurality voting (leave as-is)

Neutral

Discussion

@ShadowKirby: I should clarify that this would not preclude the option to cast only one vote. The effect of this is that, if a user votes for only one option and that option loses, the vote has no bearing on the standing of the other options, which is the same as in the status quo. It's effectively equivalent to a last-choice vote. (Should also note: one would not be able to make two first choices, or the like; ranking should occur linearly or else options not preferred should be excluded.) --YFJ (talk · edits) 07:40, 16 November 2023 (UTC)

Sounds perfect :) ShadowKirby (t/c) a.k.a. your new overlord ShadowMagolor 07:42, 16 November 2023 (UTC)

Regarding Basic Person's comment: This isn't the exact system used by referendums. Referendums so far have used borda count voting, option 1 is instant-runoff voting. ---Pink Yoshi Fan 23:19, 16 November 2023 (UTC)

To add on to this: the fundamental difference between instant-runoff and borda count is the weight of second-choice votes. In borda count, all votes cast are weighted depending on whether it is first, second, third choice and so on. In instant-runoff, second-choice votes have no weight (except for tiebreakers) unless that user's first-choice vote fails. Instant-runoff essentially emulates the proposal having multiple rounds, with one option eliminated each time. The question becomes, "if this option were eliminated, what would I choose next?"; the answer is, naturally, your second-choice vote. --YFJ (talk · edits) 23:42, 16 November 2023 (UTC)

Kirby 64 Element Table (2023-08-23 - 2023-09-06)

So, I think the existing Kirby 64 Copy Ability navigation is really, really... difficult. At least for me, the current set-up is very hard to read and I think it would help to use a more accessible, easy to understand template. Hmm. If only there was a convenient form of template to document every possible combination of something with two variables! Wait...

You'll see on [Google Drive link] (ZIP archive containing PNG, PDN, TXT, and HTML files) that I have made a table template that is very incomplete, but what is there is a much more approachable interface. It is a table with a top row and left column showing each base Copy Ability as an icon (that links to the ability's page, of course) and in the space of the rest of the table are links to each Power Combo. I'm kinda proud of it despite it being a basic HTML thing. Can we implement something like this on the wiki? Waddlez3121 (talk) 03:48, 24 August 2023 (UTC)

Support

Although I'm fine with the way the Power Combos are set up on the main Kirby 64 page, I think this would be useful as a navbox on the Power Combo pages. StarPunch (talk) 04:28, 24 August 2023 (UTC)
This seems pretty easy to implement and I could see it put on the bottom of each Power Combo page. While I don't tend to look at Kirby 64 stuff, easier accessibility is always good. GoldenDragonLeaf (talk · edits) 04:39, 24 August 2023 (UTC)
This is a great idea! We've got some clickable navboxes like this on lots of other pages, and this would work perfectly too. --Deep Fried Cabbage 05:59, 24 August 2023 (UTC)
I think this kind of table would be very helpful as a navbox. It's simple and to the point. Regarding opposing concerns, I prefer a table with repeats over the same exact table without any. If ut looks too simple, the cells of the table could be coloured in. I still prefer a table over a navmap since those don't cope well with mobile. ShadowKirby (t/c) a.k.a. your new overlord ShadowMagolor 11:08, 24 August 2023 (UTC)
While I think either design could be good, I do prefer the new design that was brought up after the proposal. ---Pink Yoshi Fan 11:52, 6 September 2023 (UTC)

Oppose

I'm going to elaborate on the discussion later, but on the current format of the table I will have to oppose. While I like this idea at core, I think we need to discuss this more and even decide first if we want a table in the page, or a navbox, or both, as they are coded differently. In particular, I'm not sure how to format this as a navbox. And for a table, I'm concerned due to the lack of any text, and also due to repeats the most. This currently doesn't look up to the wiki's standards. - Gigi (talk • edits) 10:29, 24 August 2023 (UTC)

Neutral

Discussion

For ease of access, I've also recreated the table in wikicode. StarPunch (talk) 04:28, 24 August 2023 (UTC)

Power Combos in Kirby 64: The Crystal Shards

Is this proposal talking about the table on Kirby 64: The Crystal Shards#Power Combos or something to replace the power combos line on {{Navbox-K64}}? If it's the first one then I think it's better as-is, but if it's about the navbox then I agree that this is better (as long as it's only put on power combo pages). ---Pink Yoshi Fan 12:59, 24 August 2023 (UTC)

Bump on the above. We really need to figure out what this proposal is about. - Gigi (talk • edits) 11:44, 4 September 2023 (UTC)

Okay so I said I would comment better on my concerns with this table, and here it is.

First of all, it's currently unclear if this proposal is about the table in the Kirby 64 page or a navbox or really anything else. It's not focused and is one of the main reasons I opposed and I still am opposed to it. I don't feel confortable supporting something that I'm not even sure what it is about.

Second, this table says it will help with accessibility, but it does the opposite. It really only helps if you want to figure out what two ability combos make, and even then, you will have to click on the link to actually find out. This is due to the fact that it lacks any text and any images of the actual combos. If you are just looking for a specific combination, in particular one that you just remember the appearance or a more specific name (like Curling), you may take a long time to finally realize which place you need to click. As such, here is a solution to that problem (incomplete table, but it should illustrate what I mean):

Power Combos in Kirby 64: The Crystal Shards
	Burning
Burning	Burn-Burn

This actually makes the table more readable, easier to navigate, and more up to the quality standards of the wiki.

However... not much ago many editors seemed to agree that we weren't a fan of navmaps. So making this a navmap feels a bit backwards to me. Or rather, I feel there is a larger discussion to have about navmaps before creating new ones. So, personally, I would hold off on this one.

So, I'm not opposed completely on making this some sort of navmap if we go with the variation I proposed, but even then I'm not a fan per the paragraph above. Otherwise I'm still opposed since we wouldn't be upholding WiKirby's current quality standards. - Gigi (talk • edits) 12:01, 4 September 2023 (UTC)

The Burn-Burn image does make the table more bright (and less repetitive since rows and columns already include the ability combos), and text links work better on mobile, so the new table looks great. As far as navmaps are concerned, my main issue with them is how glitchy if not outright non-functional they are for some users, which this table isn't. ShadowKirby (t/c) a.k.a. your new overlord ShadowMagolor 12:08, 4 September 2023 (UTC)

First of all, I want to say that, yeah, I think the screenshot-of-ability format is even better. That seems much better, and I definitely prefer it over my original draft (Thanks for making that in full, StarPunch!) Now, I'd like to try my best to address everything concisely as per what I said on Discord earlier this morning.

This is intended to be a navbox to replace the one at the bottom of the individual Power Combo pages, like Burn-Burn and Ice-Stone.
The accessibility factor, in my opinion, is that you can look along a column or row corresponding to an ability and immediately go "oh, okay, this does that." I admit, Gigi's did a far better job of that. This is more organized than simply listing out each combination on one line, due to the column/row alignment. The text version is hard to look at for some reason I can't really explain.
I understand the concern for repeats, however I think that's a more than worthy sacrifice for the format. I'd like to call to mind the twenty-something redirects we have for these same abilities - those can be very helpful for accessing the needed Power Combo in case you get it the "wrong" way.

I'm not sure how to approach making the table now. I like the new table, but I think at least some people were voting for the old version, and I don't know if their thoughts still stand. Should I edit in another option this late in the run? Should we just assume one table or the other? Or should we have a second run at this, assuming it gets approved, to decide between the two?Waddlez3121 (talk) 17:34, 4 September 2023 (UTC)

Basic gadgets (July 14th 2023 - July 28th 2023)

If you're a registered editor on WiKirby, you must have traversed your preferences at least once and seen the Special:Preferences#mw-prefsection-gadgets tab. We have two gadgets on entire WiKirby: MediaWiki:Gadgets-definition, one of which enabled by default and hidden (shows a link to refresh RC when new changes were made, no reason to disable it) and the other shows Category:Meta categories which are hidden by default without having the gadget enabled.

I think we ought to buff editor experience with more gadgets available in preferences. I recommend adding HotCat first and foremost (see the info page: wikipedia:Wikipedia:HotCat), then Purge action (in form of a button in the header, after "watch", to refresh cache of pages), Edittop (adds an [edit] button to edit the just the lead section of the article, without having to load the entire article), Reference Tooltips (when you hover over a reference it shows the source without having to click it and go to the bottom of the article and back to read sources) and Cat-a-lot.

Having all of these added as opt-in, nothing will change for anyone not looking forward to using them or having to disable them. I'm sure wiki support knows gadgets better than I do, but adding them is pretty simple and even I can assist if this proposal passes. ⁠–⁠Wiz (talk · edits) 13:21, 14 July 2023 (UTC)

Support

I come down on overall support. Edittop and Reference Tooltips both seem quite handy. Purge is something I typically do just by editing the URL but I can see it being handy for some as a proper link. I don't use categories so much but can see the value in having HotCat and Cat-a-lot available for others. —willidleaway [talk | edits] 14:25, 14 July 2023 (UTC)
Pretty much the same opinion here as WIA, some seem useful to me and although I wouldn't use the others I can see how others would. ---Pink Yoshi Fan 20:33, 14 July 2023 (UTC)
I'm not too knowledgeable on gadgets and stuff but extra tools wouldn't hurt, in fact I could use quicker purging actions so voting in favor. ShadowKirby (t/c) a.k.a. your new overlord ShadowMagolor 12:35, 28 July 2023 (UTC)

Oppose

Neutral

Discussion

Updating Video policy to allow small official videos (July 4th 2023 - July 18th 2023)

Right now, the wiki's Video policy is mostly focused on trailers and gameplay footage recorded by wiki editors. On that scope, it makes perfect sense and covers well those subjects. However, there are some other kinds of videos that are currently not addressed there, and that I believe we need to address and to allow them to be directly uploaded on WiKirby. That policy was originally written quickly after the wiki's first video file was uploaded, and was set to be reviewed with proposals, so here I am. :P

For full context, Twitter has been dying for a couple months now, and its future continues to be uncertain. Very recently, it became impossible to view tweets without being logged in, and there is currently a limit on the number of tweets an account can read. With official Kirby Twitter accounts around, it became even more important to archive and document tweets from said accounts. As of right now, we document pretty well various Kirby Twitter posts, and by doing so we upload images alongside their text. I will use List of Kirby JP Twitter game reports - Kirby Star Allies as an example here. However, we do not upload videos of tweets when those exist, and instead we just upload the default image of the tweet's video. An example of that is File:KSA Twitter - Rick & Kine & Coo.jpg. There is a Twitter link right next to the post to click and see the video, but, in particular with Twitter's current situation, this is far from ideal. People can only watch the video if they are logged in on Twitter, and if they haven't reached their full quota for the day. And while you could say we can just link an archived link of that same link, this is assuming the link was archived before the change, since as of right now if you try to archive a tweet, it will archive the login page. Moreover, this is not future proof, as it will be impossible to archive new tweets with archive.org.

On a less priority note, some recent Kirby games have had tutorial videos which I think would be neat to have on the wiki. If you are on WiKirby's Discord, see here for a message I posted last year about Forgotten Land, and see here and here for a quick mention of videos like that from Return to Dream Land Deluxe. Currently these can only be uploaded if converted to gifs or apngs which... fine. But if the raw files are videos, I don't see the need to convert them when all the video files are super small.

Anyway, the wiki doesn't currently allow these videos to be uploaded, in particular due to these two points of the current policy:

Uploaded videos should only be of unedited gameplay footage, unless there is a very good reason otherwise. Generally, collaging different unedited footage in a single video is okay.
Uploaded videos must be the uploader's own work, or uploaded with explicit permission from the original creator. You may not upload videos by Nintendo or HAL Laboratory, even if they are publicly released. Use an embed for that instead.

The second point in particular the root of what I want to change. The "Use an embed for that instead" seems to imply that that is possible by default for all those kind of videos. For the two kinds I mentioned, there is no way to embed them unless we upload them to some random Youtube account and embed them, which feels very counter productive for me. If we are allowing videos to be uploaded on WiKirby, why are we telling people to embed all official videos? Again, this was probably written with only trailers and Youtube videos in mind, but the spectrum is much bigger than that. And as this stands, which a very restrictive policy, we only have three video clips uploaded on WiKirby, all of which could even just be gifs. Unless we want to take a step back and go back to disallowing videos on the wiki (which I don't think we should do), we need to make the video policy less restrictive.

With all that said, my proposal is to rewrite the Video policy to allow the two kinds of videos I mentioned above, by changing the policy points as follows (with only the first three points being changed):

Uploaded videos should not be excessively large in size (not significantly larger than the largest images, which are around 5 MB). Exceptions can be made for official videos that are a bit larger than that, but should be avoided.
Uploaded videos that are the uploader's own work should only be of unedited gameplay footage, unless there is a very good reason otherwise. Generally, collaging different unedited footage in a single video is okay.
Uploaded videos must be the uploader's own work, or uploaded with explicit permission from the original creator. You may upload videos by Nintendo or HAL Laboratory only if they are short unique videos posted on social media such as Twitter, or present in the game itself such as tutorial videos. Trailers, advertisements, cutscenes, and other long videos should never be uploaded; use an embed for that instead.
Uploaded videos are subject to similar quality standards to images and/or audio, and bad quality videos will be deleted. Generally speaking, gameplay footage should follow the same resolution standards as images.
At least for now, you may not upload personal videos for your userpage. It must have some use for the wiki proper.

Thoughts, suggestions? In particular, is there any copyright issues with anything I mentioned? And as a final note, while most of the videos I mentioned here are not very big (usually at most 10 MB), some are bigger, like this (which is 20 MB), so I can understand concerns with that. But most of the videos are short and small like this. The size of videos to allow is still a bit up in the air, and we could perhaps ask to embed larger videos. Feel free to comment on that. - Gigi (talk • edits) 12:16, 4 July 2023 (UTC)

Support

Just for the mere fact that Twitter is in danger of extinction ~~and being that for most of the year it's unavailable for me anyway~~ I would very much like to see the videos uploaded to WiKirby. I don't see any reasons to oppose and that's all that matters at this point. ShadowKirby (t/c) a.k.a. your new overlord ShadowMagolor 12:47, 4 July 2023 (UTC)
Agreed, there needs to be a way to preserve official videos (and also make them more accessible) and I'm not sure if Wayback Machine was ever capable of saving Twitter videos (and definitely isn't now). Having the tutorial videos on-wiki also seems good. ---Pink Yoshi Fan 13:22, 4 July 2023 (UTC)
Allowing uploads of tutorial videos makes a lot of sense to me—they comprise a small part of the overall game, and they are clearly not replacements for playing the game both due to that and due to the resolution of the videos (no larger than 1000px in either dimension). For Twitter videos, one possibility is to host either downscaled or clipped versions of > 5 MB videos, and link to IA copies of full-resolution versions, but overall I think there is a rationale for many of them (thinking of the video that shows the KF2 HAL easter egg, to give just one example) to be uploaded without infringing on any of HAL's commercial opportunities. —willidleaway [talk | edits] 17:48, 4 July 2023 (UTC)
I don't see any reason to go against this. Having videos from social media would be neat, which it is not so different from what is being done now, and having in-game videos that are not cutscenes uploaded here would be a good resource. -Zolerian (talk | contribs) 02:59, 5 July 2023 (UTC)
This appears to be a highly logical safety measure to preserve content that is at risk of disappearing with no way to see it. Especially with how Twitter seems to be going down the drain it can't hurt to start preserving the relevant stuff on there now instead of taking the gamble. Infinite Possibilities (talk) 11:07, 5 July 2023 (UTC)

Oppose

Neutral

Discussion

I'm coming to this late, but... Why wouldn't we? Even if Twitter wasn't currently (insert "crapping itself like _" here), it seems really silly to not have our own backups of these things in case an existing source does go down for any reason. Now, given, if they ask us to remove the videos that's a different story, but the way I see it, for Twitter-sourced videos we can send them something like this in return:

"Hi, yes, we'll remove them from the archive immediately. Do you have any other source than Twitter for these videos? We're concerned with the longevity of the platform and would like to source these videos on a more accessible platform."

And if they don't have that, then we deal with that from there.Waddlez3121 (talk) 01:18, 6 July 2023 (UTC)

A few things to consider:

Video files are inherently very large. Even if the server host is willing to take on a lot more of these files, it will also have a significant page loading factor for the end user—the more videos you have, the longer it may take a page to load.
There are not a lot of universal standard file formats to use: Do you plan on using MP4? AVI is generally large in size, MKV has rough support, and Vorbis OGV is also not supported on Apple systems. Furthermore, HEVC encoding (H.265) and MOV are proprietary. I think you need to develop clear and explicit guidelines for how exactly these files need to be uploaded and presented if this does move forward. Trig - 04:09, 7 July 2023 (UTC)

Current video policy prefers MP4 (which I suspect will be the format for all accessible Twitter videos), but unlike generic MKV files, WebM files using VP8/VP9 have reasonable browser support at this point without the proprietary problems of HEVC (and is the native format for some of the in-game files being discussed). So MP4 and WebM are what we should encourage—I suspect those will often will end up being what gets uploaded anyhow but it wouldn't hurt to enshrine it in explicit policy. I don't know that we need explicit bitrate/resolution specifications beyond using native resolution where possible and arriving at a sane total file size, but can be persuaded otherwise.

As far as presentation is concerned, I don't know if I'm taking that in the right spirit but I guess one question is whether videos should autoplay or at least be optionally allowed to autoplay. One issue I see potentially happening is for non-16:9 videos when embedded (eg File:KDL dance.mp4 where I have to employ a CSS hack to remove 'letterboxing' of sorts).

(Slightly orthogonal point, but we could also use clearer guidelines for audio files (eg MP3 uploads at 128 kbps joint stereo).) —willidleaway [talk | edits] 14:23, 14 July 2023 (UTC)

Currently on upload we allow png, gif, jpg, svg, flac, mkv, mov, mp3, mp4, oga, ogg, ogv, wav, webm. So I guess for videos we allow mkv, mov, mp4, ogv and webm right now, but indeed, as mentioned, the policy says mp4 is favored, which I agree. I'm not opposed either to disallow certain file types if we believe they should probably not be allowed at all.

Regarding file size, I think as long as we determine a file limit it should be fine. As for what to do about bigger videos, it appears the solution is to either compress them and link to the original version, or maybe even upload to Youtube. Thinking it over, I wouldn't be opposed to having a WiKirby account for for that purpose if we decided we prefer that method. - Gigi (talk • edits) 15:23, 14 July 2023 (UTC)

One more thing about file size: although the video policy claims that the largest files on WiKirby are generally 5 MB, that is certainly not true. So I suppose the file size discussion should be broader than videos. Although I will admit, I know for images thumbnails are generated, which makes page load better, but I'm unsure if a similar system exists for videos, or if they always are fulled loaded once a page is loaded. - Gigi (talk • edits) 15:42, 14 July 2023 (UTC)

Side note, but before I forget: it appears Wayback Machine is really bad in general about archiving Twitter videos. Using this as an example, I looked at every snapshot of it and I couldn't play the video of this tweet in any of them. And getting direct links to a Twitter video is extremely annoying. If we move forward with the idea that certain videos need to be compressed to be uploaded and we link to an archived version for someone to see it at the highest quality, we will likely to figure out how to archive said videos. Personally, I would recommend to use links from my own archive of the Kirby_JP Twitter account, and we can link the video directly like this. - Gigi (talk • edits) 15:04, 14 July 2023 (UTC)

Require archiving external links (May 20th, 2023 - June 3rd, 2023)

== Archiving external links ==

Ideally when using a website, image from the Internet, or especially a post from the social media as a citation, a link to a [https://archive.org Wayback Machine] archive should also be provided. This is a future-proof measure, in case the site (or the account) gets deleted and the source is no longer accessible or verifiable. Finding an archive is simple: just paste the URL of the site you want to add into the Wayback Machine search bar and see if its here. If yes, then its simple, just use the URL provided. If no, then its still simple, as it can be requested for an archive to be done, which should only take few minutes.
 
Note that some sites block Internet Archive (such as Nintendo of Europe). In this case, the rule does not apply.

I propose for the above text to be added to WiKirby:Citing policy. The events that had happened recently, such as Imgur purging their site from many images, Nintendo Online Magazine and Smash Bros. DOJO!! shutting down, as well as prophecies of Twitter's death have raised awareness that stuff on the internet, in particular social media, can easily be deleted. Thus, as a future-proof measure, I believe every possible external link that can be archived should be done so with Web Archive. Superbound (talk) 12:18, 20 May 2023 (UTC)

Support

Agreed. Losing stuff off the internet is going to happen, but making sure it's not gone forever is why the Wayback Machine was made. We already have some sources that may have no archive, and it would be a good thing to keep that from growing. ---Pink Yoshi Fan 12:23, 20 May 2023 (UTC)
Fight link rot. (That could be a useful policy to refer to, by the way.) It'll only be a matter of time before other websites, like CBC's website for the anime and possibly even the original Smash Bros and Melee promo pages (with Kirby questions and answers), also shut down. —willidleaway [talk | edits] 15:35, 20 May 2023 (UTC)
This is something that Wikipedia does, I think. There is no reason as to not do this, and pointing it out in the policy would lead more people into doing that, which indeed would prevent and bad future. If someone adds some link without an archive, thus "breaking the policy", the edit wouldn't be reverted, but instead ideally it would be kept while also adding the corresponding archive, so again, there is not bad in this. -Zolerian (talk | contribs) 20:15, 20 May 2023 (UTC)
If this is what it takes to preserve a source then I'm all for it, I'll just have to learn how to use that... ShadowKirby (t/c) a.k.a. your new overlord ShadowMagolor 07:53, 21 May 2023 (UTC)
Full support. I remember a while ago that Kirby's Rainbow Resort was down for months and we had to go around updating links to their archive.org versions, when they existed, in many images. The site did go back up, but that won't always be the case. There is also time sensitive stuff like Kirby Café dishes that we need to archive occasionally or they will be lost in time. All in all, this ideal to preserve our sources. - Gigi (talk • edits) 21:59, 22 May 2023 (UTC)
Heavily agree with this. Preservation is important, especially if we want to check something later. GoldenDragonLeaf (talk · edits) 20:30, 26 May 2023 (UTC)
After this passes, we should consider recommending Wayback Machine extension/add-on in {{Recommended Downloads}} and adding archive parameters to {{cite}} and {{Twitterlink}} templates. I also recommend improving the proposed wording - 1) it's unclear to me what "if yes" and "if no" are answers to. 2) there are too many "it's simple"s. 3) where can one request an archive to be done? what will take a few minutes? 4) steps should be made into a list. 5) integrate archive.today as proposed in the comments section when it comes to NoE. It wouldn't hurt to also explain why are we recommending archival in the recommended text. ⁠–⁠Wiz (talk · edits) 12:51, 29 May 2023 (UTC)

Oppose

Neutral

Comments

I also suggest that archive.today is an acceptable website or at least doesn't seem to be immediately going away after ten years. Wayback Machine should still be preferred. Per wikipedia:WP:WEBARCHIVES, Mementos will allow searching multiple archiving services at once. —willidleaway [talk | edits] 15:35, 20 May 2023 (UTC)

It's worth noting that although it took a few minutes, archive.today can archive NoE sites for the moment. —willidleaway [talk | edits] 15:39, 20 May 2023 (UTC)

Both should be used. Internet Archive has been lately clashing with lawsuits (i.e. wikipedia:Hachette v. Internet Archive) and its future is uncertain. ⁠–⁠Wiz (talk · edits) 16:21, 20 May 2023 (UTC)

Clarifying the role of neutral votes in proposal voting (2023-05-09 - 2023-05-17)

During a recent proposal about pronouns, some confusion arose about the meaning of neutral votes for proposals. Currently, rule 4 states that "After two (2) weeks of voting, a proposal will be immediately enacted if a simple majority of more than 50% of votes are supportive, [...]". The regulation does not mention neutral votes, but according to its wording, this would for instance mean that a proposal with 5 supporting, 6 neutral and no opposing votes would not pass, as less than 50% of votes are supporting. This means that in most situations, neutral votes have the exact same effect as opposing votes (except for the purpose of passing a proposal early as outlined in regulation 5, where a neutral vote alone does not prevent this.) So far, this situation has not occurred, but I think this ambiguity should be resolved before that happens.

I believe a lot of people would intuitively assume that a neutral vote is equivalent to abstaining and should not prevent a proposal from passing. Therefore, I propose to change regulation 4 as follows: "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."

If this proposal passes, there can be no doubt that neutral votes are not considered for the majority required by supporting votes, and if it fails, this equally clarifies that neutral votes are counted against the majority needed by supporting votes. Thus, this proposal will remove the current ambiguity regardless of its outcome. Typman (talk) 13:53, 9 May 2023 (UTC)

Support

Neutral votes are more like a "fine by me, don't really mind", if someone is opposed to an idea the section is there, so I don't see why a vote saying "do as you wish" would override a "yes". ShadowKirby (t/c) a.k.a. your new overlord ShadowMagolor 15:00, 9 May 2023 (UTC)
~~As much as I want to vote neutral on this,~~ if people want a proposal to not pass, the oppose option exists. If they don't care about it either way, then they'll probably think neutral is the way to do that. Abstains shouldn't count as votes. ---Pink Yoshi Fan 15:06, 9 May 2023 (UTC)
Though admittedly I don't really get the point of neutral votes in the first place, this would at least make them actually neutral instead of basically just opposition. Hewer (talk · contributions) 18:19, 9 May 2023 (UTC)
When deciding if you like a change, I see a Support as an "I want that", an Oppose as an "I don't want that" and a Neutral as an "I don't care", with the reason of you stating that you don't care being letting everyone else know that you are aware of this change proposal, but can't decide on an option, or both are fine with you because you don't mind. So in that case Neutral voting should not bring the proposal down, nor help it to pass. If we have one with 5 Supports, 0 Opposes and 7 Neutrals, really no one is against the change, as the ones that voted Neutral are supposedly doing so because they are fine with the change happening. -Zolerian (talk | contribs) 03:11, 10 May 2023 (UTC)
The way I've used neutral votes is for if I don't mind either outcome of the proposal, so I definitely agree that they shouldn't hinder a proposal from passing and actually be considered a neutral vote. GoldenDragonLeaf (talk · edits) 03:15, 10 May 2023 (UTC)
I am in favor of this clarification. Neutral votes should not be used to "politely oppose" something. Neutral should only be for people with no strong preference either way. --Samwell (talk) 04:19, 10 May 2023 (UTC)
Yes, neutral should mean neutral and not oppose. As such, I'm in favor of the change. Superbound (talk) 15:25, 10 May 2023 (UTC)
Clear and concise. The confusion during the pronouns proposal proved palpable and avoiding such confusion in future will be preferable. I also hope that this clarification may also encourage use of the Discussion section over voting Neutral. —willidleaway [talk | edits] 12:17, 17 May 2023 (UTC)

Oppose

Neutral

Discussion

Deciding upon pronouns for characters with none (March 24th, 2023 - April 7th, 2023)

A common issue that's come up on the wiki is what pronouns to use to refer to minor characters who haven't been officially referred to in third-person. Right now, there's a discussion about this ongoing with Bouncy, and a lot of anonymous users have made small edits in this vein, usually changing characters with no confirmed pronouns to "it". However, there are cases where this approach seems odd; for example, Super Bonkers is referred to as "it" despite regular Bonkers being referred to as "he", and Keke is referred to as "they" (which I already changed from "it") despite being a reference to Kiki from Kiki's Delivery Service, who is referred to as "she".

Since this issue will likely come up a lot if we don't address it soon, I figured I would create a proposal to establish a formal policy about this. Specifically, it would be a general rule to add to WiKirby:Writing style#Subject characteristics — if a character has no confirmed pronouns, go with what the majority of users feel is correct, as long as it's consistent. Just as an example, a lot of users have expressed the idea that referring to Bouncy as "she" feels correct because Bouncy Sis is, even if she hasn't been officially referred to as such. I don't think gathering a majority opinion has to be done in a formal poll, unless opinions are really split; rather, most can be inferred based on context and getting a general idea of what people think.

The reasoning behind this is because it's very unlikely every character will get official pronouns, so going with what feels right would be a lot less awkward than sticking with "it" for everything. I'm also open to other suggestions or improvements to this policy. StarPunch (talk) 23:01, 24 March 2023 (UTC)

Support

We currently have a lot of inconsistency with pronouns, and we have unwritten rules such as "use it/its for enemies when there is no confirmed pronoun, but use they/them for characters". However, with no complete consistency in the series itself, we could, for example, have someone go to Sailor Waddle Dee and change the pronouns to it/its, claiming that we have a character with it/its pronouns, Sillydillo, and we really won't have any other way to say no other than "I don't believe that's right" or "I prefer they/them", since Sailor Dee has no confirmed pronouns. We are already unofficially dealing with lots of conjecture when it comes to pronouns, and since English has two neutral sets of pronouns (it/its and they/them), and you can also argue that he/him is neutral, we really have no way to be 100% neutral without conjecture. On top of all that, the Kirby series is a Japanese series, and the Japanese language deals with pronouns way differently than English, to the point where it's possible to have lots of text about a character but with no specific pronouns to write an article in English about them (such as Gryll), so we can indeed have many cases where there are no official pronouns. Without a proper way to handle them, we will continue with endless debates on what is the right pronoun for a character (such as Bouncy) and we will go in circles. As such, I believe it's very reasonable to just come to an agreement with a simple vote with what kind of "conjecture" we will use for the pronouns of a character; the conjecture exists with or without a set of rules, but without one we will have way less constructive debates. Pronouns aren't something supplementary like a character's gender, they are required for us to write an article about a subject, so if a character has no confirmed pronouns, we will have to choose one for them, there is no way to avoid that. There is no way WiKirby will exist 100% without conjecture in any form, and expecting that is unrealistic. - Gigi (talk • edits) 21:45, 26 March 2023 (UTC)
Given the inconsistency introduced by KatFL in third-person pronouns for some Mid-Bosses like Gigant Edge, it is fair to say that Nintendo of America themselves engage in conjecture much of the time, given the original Japanese text is unlikely to give guidance and given HAL may not necessarily have codified genders in mind for many characters (including Kirby), certainly not in a sense that translates cleanly to English. This leads me to believe that the concern with the wiki's conjecture policy is moot. The alternative to recommending a consistent (if conjectural) pronoun use in these cases would be highly constrained writing to play the pronoun game, and this would put a much more significant burden on editors to rewrite edits that inadvertently assume pronouns compared to a simple pronoun replacement for edits that inadvertently use non-consensus pronouns. —willidleaway [talk | edits] 14:16, 29 March 2023 (UTC)
Since there are many cases where pronouns change or are simply not given in the games, I don't think there's a simple rule we could use to decide on pronouns that are appropriate for all characters, so I think it makes sense to decide on pronouns for unclear cases like these by coming to a consensus through discussion. Consequently, I support the proposal based on this and the arguments brought forth by the previous supporters. Typman (talk) 14:33, 29 March 2023 (UTC)
While not ideal solution (I have my doubts if calling votes would be effective), I think that it is a better option compared to current anarchy, or a very restrictive system (pronoun game) that would only hurt the quality of our pages. In addition, taking into consideration how pronouns and gendering in the Japanese language work, and plethora of characters or species that exist in Japanese popmedia and simply don't have gender (even Kirby being example of such), I doubt that HAL designers themselves think about this matter. So support. Superbound (talk) 18:04, 31 March 2023 (UTC)
I thought about this for a while and decided to vote in favor. Even if "what the majority feels is right" isn't the most objective reason, given the absence of actual pronouns, it will end up being "what the specific editor feels is right", which is still conjectural. I trust that our community is rational enough to not pick pronouns "because they just like it". However, solidifying some nuances can be helpful. For instance, I think that forms of a certain character/foe that has known pronouns (like the aforementioned Super Bonkers) can inherit the main form's pronouns, though that could still be subject to discussion. In short, if this isn't the best solution, what is? ShadowKirby (a.k.a. your new overlord ShadowMagolor) 10:14, 3 April 2023 (UTC)

Oppose

I personally find that there could be better ways of going about this, one of which might be to allow things to stay as they are. We must consider the fact that pronouns shape (and and are shaped by!) the way we look at people and the way we look at things, and even if conjecture is inevitable in the end, I think that for the sake of neutrality we should stick to what we have. Even then, it is true that a Writing Style rule would be very valuable for consistency. -Amari!! :3 14:07, 28 March 2023 (UTC)

Neutral

WiKirby has gained a reputation of being non-speculative so far. We'll be playing a role in establishing pronouns of subjects which may prove completely wrong at some point in the future. Even if we get proven correct in other '99%' of times, the mere fact we do not differentiate between confirmed and conjectured pronouns can only weaken perception of WiKirby's reliability regarding both. I want to see opinions from others, so staying in Neutral for now. ⁠–⁠Wiz (talk · edits) 11:06, 25 March 2023 (UTC)
While I agree that this would be a definite solution to the issue of people trying to change character pronouns, I agree with Vipz that there is the issue of that it is still conjecture. ---Pink Yoshi Fan 20:53, 26 March 2023 (UTC)
I strongly agree on the fact that we should stay non-speculative. However, the issue of referring to these strange cases still remain, and honestly it's really iffy in general. I'm also not to sure how we would vote without it being too bothersome and clunky in deciding what pronouns to use. GoldenDragonLeaf (talk · edits) 22:08, 26 March 2023 (UTC)

Discussion

I overall agree with the proposal, but I just wanted to ask how we would vote on pronouns. I assume it can be in the page's talk page? Also, I suppose that if someone tried to change the pronouns of a page with no clear reasoning other than "I prefer them like this" it would be reverted, right? - Gigi (talk • edits) 23:07, 24 March 2023 (UTC)

Yeah, talk page discussion was my idea; either that or the Discord. Changing the pronouns without consensus would be reverted. StarPunch (talk) 23:22, 24 March 2023 (UTC)

If the proposal does not go through (and it looks quite close at the moment at least) then wouldn't this be a de facto writing standard anyway? It would just be that it would be an unwritten rule to go by consensus on a character-by-character basis, instead of explicitly codifying it in the style document. I suppose someone could put forward a proposal to codify 'pronoun game' writing for characters with no English pronouns in official use (which for the record I would not support). —willidleaway [talk | edits] 14:40, 29 March 2023 (UTC)

To be clear, this thought isn't to dismiss the proposal as unnecessary, but rather to say that barring 'pronoun game' guidance, some form of consensus-based conjecture may end up being the de facto solution in any case, and I only see benefit to codifying it in the style document. —willidleaway [talk | edits] 14:50, 29 March 2023 (UTC)

I think that's my thought, yeah... We don't really have a standard in place and this seems to be a de facto rule, though I'm open to having a different option proposed. I'm definitely considering the idea that it would shift us to a conjecture-based area. StarPunch (talk) 12:07, 2 April 2023 (UTC)

If we wanted to be sure to avoid the appearance of projecting unofficial pronouns as truth, then I imagine something like {{Title}} but for pronouns would be a possible way of making the reader as aware as possible that the pronoun is being supposed rather than officially sourced. —willidleaway [talk | edits] 05:53, 4 April 2023 (UTC)

Better represent how abilities can be gained from entities via categories (March 13th, 2023 - March 20th, 2023)

Recent edits to add sub-categories of the big Creatures by ability yielded main category to basically every single entity that can give the ability in any form (either being inhaled by Kirby for enemies and mid-bosses, or for their attacks giving abilities) have caught my attention because it makes it confusing for readers to know what is going on for an enemy. And if you go to a category like the Bomb one, it has a list of all kinds of entities, from games to even anime, that make it hard to understand. For example, Vividria is there, but you can get Bomb from her projectiles, not from inhaling her, so it could mislead a reader to think that if you swallow Vividria you can get Bomb. While in article text you can very easily add a note that, for example, you can only get Bomb from one of Vividria's attacks, that is not possible with categories. Thus, my proposal is to split the ability-yielding categories into two, like this:

Creatures that yield [Ability] when swallowed -> this creature gives the given ability when swallowed by Kirby
Creatures that yield [Ability] from projectiles -> this creature gives the given ability from one of their attacks or weapons, not by being swallowed by Kirby

These names are of course subject to change (feel free to give suggestions), I would just prefer to give direct names to these categories, because from discussion about this on Discord, I noticed some people interpret "[Ability]-yielding creatures" as being from inhaled enemies already, while some see a more generic meaning to it, as in that Kirby can get the ability from the boss in some form. Now, if this proposal passes, I also think it makes sense to actually make the following category tree changes:

Creatures by ability yielded -> Creatures by ability yielded when swallowed -> Creatures that yield [Ability] when swallowed
Creatures by ability yielded -> Creatures by ability yielded from projectiles -> Creatures that yield [Ability] from projectiles

And...

Creatures by ability yielded -> Creatures that yield [Ability] -> Creatures that yield [Ability] when swallowed
Creatures by ability yielded -> Creatures that yield [Ability] -> Creatures that yield [Ability] from projectiles

So, basically, Category:Creatures by ability yielded would have the sub-categories Category:Creatures by ability yielded when swallowed and Category:Creatures by ability yielded from projectiles, as well as sub-categories Creatures that yield [Ability] for each ability. Then each Creatures that yield [Ability] when swallowed and Creatures that yield [Ability] from projectiles would have either Category:Creatures by ability yielded when swallowed or Category:Creatures by ability yielded from projectiles as a parent category, as well as the Creatures that yield [Ability] for the respective ability.

...If this all sounds confusing, two examples: the Creatures that yield Fire when swallowed category would be a sub-category of both Creatures by ability yielded when swallowed and Creatures that yield Fire, while the Creatures that yield Plasma from projectiles category would be a sub-category of both Creatures by ability yielded from projectiles and Creatures that yield Plasma.

Of course, only the "Creatures by ability yielded when swallowed" category would have an ability-neutral sub-category, as I think it would be pretty weird to note projectiles that do not give abilities with a category. And of course, if there are abilities which have no projectiles that give them (such as Ranger), we don't need to make categories for them. And finally, the "Creatures that yield [Ability] when swallowed" and the "Creatures that yield [Ability] from projectiles" categories would then be allowed to be assigned to articles, not the "Creatures that yield [Ability]" categories.

So, what you do all think? If this passes, I know we will have a lot of work to reorganize the categories, but I am willing to do it. - Gigi (talk • edits) 19:58, 13 March 2023 (UTC)

Support

I personally find this to be quite a good solution. The current category is confusing, and I find that this would be a really good step in a more easily navigable direction. -Amari!! :3 20:34, 13 March 2023 (UTC)
I can't think of any better names for the categories besides attempting to put the "Ability" part first so that the subcategories are innately alphabetized, but I think providing simple clarity to something as essential to Kirby as getting Abilities from swallowing enemies and projectiles is a no-brainer. The proposed distinction between projectile and creature is also currently the only split we have to account for in terms of enemies, but leaves wiggle room to add more subcategories in the future if we ever encounter a third thing that Kirby can swallow that gives an Ability that isn't the enemy or a projectile it spits out. LeoUnlimited (talk) 20:45, 13 March 2023 (UTC)
Agreed, making it easier to tell if you get the ability from eating something or eating the thing it uses to attack you seems like a good idea, especially since Bosses can have ability-yielding projectiles but can't be swallowed at all. ---Pink Yoshi Fan 21:29, 13 March 2023 (UTC)
Same here. I was part of the conversation in the Discord, and more organization is always good. All in all, it definitely feels like a great step in making the wiki easier to understand for everyone. GoldenDragonLeaf (talk · edits) 22:46, 13 March 2023 (UTC)
Obviously, I am in complete support of this. This should hopefully cut down on confusing the readers in the later future if this proposal becomes successful. --DarkMatterMan4500 (talk) (contribs) 19:52, 14 March 2023 (UTC)
I support the proposal as well. Separating the categories like that will reduce confusion and makes it clearer what Kirby can actually get the ability from. Typman (talk) 23:56, 14 March 2023 (UTC)
I think overall this is a fine way to help distinguish things, though it should naturally come with appropriate changes to the infoboxes to help delineate the difference as well, since categories really only tend to get used by wiki regulars. --Samwell (talk) 17:19, 17 March 2023 (UTC)

Oppose

Neutral

Discussion

Just one note that I ended up realizing recently: for cases where neither categories would work, like Scarfy giving Crash only via Copy, we can make specific categories; in this case specifically, Creatures that give Crash exclusively via Copy, and it won't even just have Scarfy, it will also have Mister Anglep. If anyone can think of other specific cases for which the categories I originally proposed wouldn't cover, feel free to post them here. - Gigi (talk • edits) 12:43, 15 March 2023 (UTC)

Dream Friends pages' colored titles, revisited (March 4th, 2023 - March 18th, 2023)

Two years ago, a proposal was made to give featured Dream Friends articles a special treatment by making their page titles colored. The reasoning for that was, that important characters deserve having their pages be unique and that it would be a nice, little detail. However, there are few problems as of currently.

First, the proposal only affected Dream Friends, who at the time were basically synonymous with "major character". But then the next game came along with Elfilin. Under what was established in the proposal, his article can't get a special color, solely because he had the unluck to debut in a game after Kirby Star Allies. And the Kirby series will still continue, and more characters will appear... It was not future-proof.

Second, the inconsistency. I don't believe that featured articles should be divided into better and worse just because they happen to cover a certain topic, and colored titles make that division. In addition, a lot people are confused on why some pages get that treatment and some don't--that's certainly not helpful either.

So, my solutions are:

Option 1: Give every Featured page special color (that would be my preferred)
Option 2: Make every Featured page white (opposite of Option 1)
Option 3: Revert to how it was before the 2021 proposal (Kirby had pink title font, everything else white)
Option 4: Give special color to every major character, not just Dream Friends (if the first issue is a concern but not the second)
Option 5: Do nothing (it's fine as it is)

Superbound (talk) 12:07, 4 March 2023 (UTC)

Option 1: Give every Featured page special color

At this point it just makes sense to give colors to featured articles as we wish. We could perhaps try to find some sort of rules but ultimately I think we can do our own call. And we can keep some others as white anyway when there is no color to represent the article really. - Gigi (talk • edits) 15:24, 4 March 2023 (UTC)
Per the reasons given. My second choice would be Option 4, but I don't really think that exclusively characters should get this treatment. This would most likely leave out Ability pages, like Beam, and having that be orange-colored would be neat. Now, this do would leave out music and game pages, and while I kinda see why one would want that, having them colored would look good. There are games that kinda follow a color motif: Kirby's Return to Dream Land could have its title blue, while Kirby Battle Royale could have its in orange, for example. And as Gigi said, if giving some color to a page ends up being in some mess, we can just choose to keep that one white and that's it, we don't need to set in stone to have absolutely every featured page colored, but also it would be good to have the option to color some non-character page if it seems good. -Zolerian (talk | contribs) 08:26, 6 March 2023 (UTC)

Option 2: Make every Featured page white

Since applying the special font to all Dream Friends without them all being featured is apparently unfeasible, I'm going with this as I'd rather keep things consistent. Giving every featured page colours would inevitably make determining colour hard in some cases and would look arbitrary to anyone not familiar with it, and giving all major characters colours is similarly a bad idea because if we aren't using the objective definition of "Dream Friends + Elfilin" (which I agree isn't future-proof), then there'll be difficulty determining which characters do and don't count as major. I'm also not voting for the third option as if we aren't doing this for any other character then I don't see a reason for Kirby to get special treatment - an all or nothing approach would be better for the sake of consistency. Hewer (talk · contributions) 21:01, 4 March 2023 (UTC)
After thinking it over, I think this will be my choice. I'm not the biggest fan of how the special colors turned out and I don't like the inconsistency. I think it would look cleaner to just keep the title font with no special color for featured pages. StarPunch (talk) 22:13, 5 March 2023 (UTC)
I would be fine with any of the first three options, just because we should be consistent. If consistency means giving everyone special colors or nobody special colors (except possibly for the namesake of the entire series) that would be ok, although I slightly favor no colors since choosing colors for every featured article could get tricky. ---Pink Yoshi Fan 12:54, 7 March 2023 (UTC)

Option 3: Revert to how it was before the 2021 proposal

"I want to emphasize that this creates an even larger inconsistency amongst page design and it's one that I would drastically prefer to not exist"—Jegman 2021. It looked terrible from the moment it was implemented and should never have gone forward to begin with. Revert pre-2021. Trig Jegman - 15:15, 4 March 2023 (UTC)

Option 4: Give special color to every major character, not just Dream Friends

I like this option. The colors truly characterize them, I feel that they make the articles feel more alive. As said above, some characters are too recent to have enough significant appearances, but it would feel fair if all relevant enough protagonists (maybe antagonists) had their own color. Colorless is just a bit bland, and coloring all featured pages would require some thought and become almost entirely subjective in a matter of seconds... ShadowKirby (talk) 20:41, 4 March 2023 (UTC)
I also like this option; it gives the relevant articles a little bit of flair (e.g., having Elfilin have blue text would signify that he is a major character in the series). We may need to define what a "significant character" is, however, so there is some consistency in when this is applied (both now and in the future). As noted above, colouring every featured page would likely be quite burdensome. Buildz17 (talk) 21:40, 4 March 2023 (UTC)
It always confused me with the special titles for certain Dream Friends but not all of them, not to mention that characters from side games don't even get a chance at all. By having major characters with special colors, it helps to differentiate them from other character pages while also keeping in theme. Also, this option would help with consistency, without having to go through every single featured page. All in all, I just think it's an execellent idea without being too much work. GoldenDragonLeaf (talk · edits) 05:51, 5 March 2023 (UTC)
It shouldn't be a big hassle to put together a definitive 'major character' list, games-wise (we still have anime characters), as they come. Giving color to all articles would be an overkill and create an inconsistent mess, while no color would deprive the wiki of its creative and fun character. Focusing just on Dream Friends is KSA-centric. ⁠–⁠Wiz (talk · edits) 11:21, 5 March 2023 (UTC)
I'd really like if this happens, as this would further show the importance of certain characters, especially major antagonists and final bosses like Hyness and Void Termina, although I don't know if this would be applied to EX versions with their own pages too. - RHVGamer (talk · edits) 21:31, 5 March 2023 (UTC)
Since only featured articles get the special title font, this prevents the scope of 'characters sufficiently major enough to get coloured titles' from becoming too insane, and I suspect a process can be navigated much more easily for deciding title colours for character articles compared to articles in greater generality. —willidleaway [talk | edits] 04:12, 10 March 2023 (UTC)
I like this idea a lot!! Kirby will continue to exist through a variety of media and have characters that are noteworthy exist outside of just mainline games, and I believe that giving others a bit more of a chance to be recognized as such while also allowing for future characters to be introduced and given the same treatment is a better option than resorting to reverting everything. Also, I just find nice to have recurring characters use a special font. It's redundant, but it does give them a lot of character.-Amari!! :3 20:27, 13 March 2023 (UTC)

Option 5: Do nothing

Discussion

Personally I like the idea of the title colours for the unique extra flair they provide, but the part that bothers me most is that only featured articles can get this treatment. Given that these colours are based entirely on the subjects of the articles, I don't think featured status should make a difference at all, and yet Marx, Gooey, Ribbon, and all three Mage-Sisters are excluded by this requirement. The title colour isn't even applied consistently among articles that are featured since it's missing from Rick, Kine, and Coo for some reason. So my ideal solution would be to just consistently apply these title colours to all Dream Friends (as well as Elfilin by the logic I explained here) regardless of featured status. Hewer (talk · contributions) 15:10, 4 March 2023 (UTC)

The reason why only featured articles get this treatment is simply because they are the only articles that use the special title font. - Gigi (talk • edits) 15:25, 4 March 2023 (UTC)

I'm suggesting that the Dream Friend articles (and Elfilin) be an exception to that if we continue to use special colours, because I think it's too inconsistent and doesn't make much sense to restrict a distinction with no relation to article quality (or at least one that really should have no relation to article quality since it only concerns the article's subject) to featured articles. Hewer (talk · contributions) 18:16, 4 March 2023 (UTC)

Then that would have to be a separate proposal because, as of right now, the title font is only applied to featured articles, and we cannot just use it for other articles to have colored titles. Plus, the argument that was made in the original proposal is that all Dream Friend pages should eventually be featured, which I don't disagree with. - Gigi (talk • edits) 20:46, 4 March 2023 (UTC)

Delete spam account talk pages 020823—022223

I think we should delete the welcome template-only talk pages of obvious bot/spam accounts. There is no need to have pages for accounts that clearly will not edit the site or be used again, and it may make searching for valuable talk pages difficult in Special:AllPages. Given the current way WiKirby handles new accounts, this number of account talk pages should not increase. My criterion for deletion would be the following:

*User names must follow the following format:
FirstnameLastname
or
FirstnameLastnameNumbers

*There are no contributions for the user.

*There is no main user page

*The talk page consists solely of the welcome message.

*The account is older than Jan 1, 2021.

I'd be happy to make a list and hand it to admin team or temporarily regain my admin role wiki-only and do it myself, whichever is more comfortable for staff. Trig - 19:35, 8 February 2023 (UTC)

Option 1: Support—Continue as listed

Unnecessary pages should be deleted.--kirb 01:42, 10 February 2023 (UTC)
It seems like a waste of space to include those pages, so why not delete them? Seems logical to me. GoldenDragonLeaf (talk) 03:41, 10 February 2023 (UTC)
Sounds good to me. Would we unregister the users themselves, too? Because I think that would be a good way to free up usernames. --Deep Fried Cabbage 06:00, 10 February 2023 (UTC)
A really small, but imho good thing that would have its benefits should it come into action, even if it is not the grandest change ever. Infinite Possibilities (talk) 17:22, 12 February 2023 (UTC)
I was initially hesitant about the idea of having to manually go through all these page deletions, but it seems that we have the means to sort out and then delete them quickly, so I'll throw my support behind this. Shouldn't be too much trouble. --Samwell (talk) 23:32, 19 February 2023 (UTC)

Option 2: Support, but devise stricter criteria for deletion

Option 3: Do Nothing

Neutral

I don't think it would be bad to do it, but I don't see any real benefit when AllPages isn't the way most people look for user talk pages and this doesn't really help clear up anything else as far as I know. ---Pink Yoshi Fan 12:27, 9 February 2023 (UTC)
I agree with the vote above. It's a good idea, but not really necessary as it's only getting rid of one thing and doesn't change much else. ~☆Star void⁠☆ (t · c) 01:24, 10 February 2023 (UTC)
This seems like a good idea, but I don't know, it doesn't convince me. I don't really have any reasons to oppose it though. -Zolerian (talk | contribs) 19:51, 12 February 2023 (UTC)
I guess I don't really see the need for this to be a proposal, as it's not that big of an issue (in the specific case of AllPages, you can just search for user pages rather than user talk). Deleting them isn't going to save any real amount of space, either. Also, I just don't really see how going through the labor of deleting all those talk pages will help the wiki in the long run. If you have a nifty way of automating the process without targeting the pages of legitimate users, then I might consider supporting, but otherwise, it just seems like empty busywork. --Samwell (talk) 19:44, 13 February 2023 (UTC)

Discussion

Solidifying character names and attributes in article writing (January 29th, 2023 - February 12th, 2023)

So, I've noticed recently that there's been some edits made to character and enemy pages in regards to gender pronouns. In particular, there was a push on the Kracko and Dyna Blade pages to refer to them by different genders based on which game was being discussed (since genders are not always consistent in in-game flavor text). I find this to be highly inappropriate for any characters that have been established as individuals (unlike, say, Broom Hatter, which refers more to a class of characters rather than a single entity). This incident has brought up a larger issue with how to treat attributes of characters and other entities which span multiple games and whose names and other characteristics may differ from one to the next. I come to you now offering a new standardized way to handle this, though it needs to be done in multiple facets which can be voted on individually. I will introduce each particular point and describe the proposed change in its own subsection. Cheers. --Samwell (talk) 14:36, 29 January 2023 (UTC)

Change 1: Solidifying character gender

To summarize what was said above, I believe we need a clause in place to prevent established characters from being referred to by different genders in text based on erroneous or inconsistent in-game flavor text. As such, I'd like to add this to the writing standards:

"For characters established as individuals, their gender must be consistent throughout article text and based on the most consistently-used pronouns in games ("he/she/they" generally takes priority over "it"). It is not appropriate to refer to these characters using different pronouns based on the game unless there is a specific special story or lore-based circumstance for doing so. Note that this rule does not apply across different canons (For example, Kracko in the games VS. Kracko in the anime.), only within canons."

Support

Kracko: "While his pause screen flavor from Kirby Fighters Deluxe, implies that he fights Kirby to get a comeback for his previous losses, however, in Kirby: Triple Deluxe, it appears it attacks Kirby because of Taranza's command." <= possible shenanigans that could occur with changing pronouns by appearance. Thus, I support to make it an official rule. Superbound (talk) 15:37, 29 January 2023 (UTC)
I 100% agree with this. I was looking at the idle animation page and noticed that Driblee was referred to with female pronouns, while on the actual Driblee page the enemy is referred to with it as pronouns. And it doesn't help that Driblee is referred to with all types of pronouns as well. GoldenDragonLeaf (talk) 03:42, 30 January 2023 (UTC)
Agreed. The devs being inconsistient doesn't mean that we need to be inconsistient. ---Pink Yoshi Fan 16:00, 30 January 2023 (UTC)
I support consistency and clarity, regardless of minor developer errors. Both the first and second parts of this proposal will prevent readers from becoming confused. --kirb 17:52, 4 February 2023 (UTC)
At first I was worried that in some cases two or more pronouns would be used simultaneously back and forth between games, (Broom Hatter comes to mind), and so we wouldn't be able to decide which one should appropriately be used. The more I thought about it the more I realized that wouldn't happen all that often, but it still could be a concern so I will bring it up in the discussion here. Aside from that, this will definitely be good to help prevent confusion and I'm all for it. -- Jellytost ♡ (talk) 22:47, 4 February 2023 (UTC)
I prefer to keep things consistent. Yoshi's Island 11:18, 8 February 2023 (UTC)

Oppose

Neutral

I don't think enough guidelines are set for me to warrant voting on this. There may be cases where use is too inconsistent to officially suggest one path or another. Trig - 16:15, 30 January 2023 (UTC)
For what it's worth, I don't feel like this particular issue "deserves" a strict guideline. As Trig said, cases of great inconsitency, which I consider to be fairly likely, could arise. Infinite Possibilities (talk) 20:16, 4 February 2023 (UTC)
I don't really have any preference on this. First, its seems that this would only apply to established characters, not common enemies, so it seems that this won't apply to Driblee nor Broom Hatter, and thus this will have a pretty small scope. For the ones that it does apply, like Kracko, I also have those concerns that us choosing specifically one pronoun over the rest would probably be a mess, and I don't know if one is definitively more prominent than the other. For example, for Kracko, I don't know what would make us decide which one to choose between "him" and "it" over the other. Still, I do like consistency, and I really resonate with the reasons to do this. I just don't punch hardly either way. -Zolerian (talk | contribs) 19:36, 12 February 2023 (UTC)

Change 1 discussion

the most consistently-used pronouns in games

So just to clarify, if we were making Kracko's page in 2014, even though Triple Deluxe refers to Kracko by "it" and it's the most recent Kirby game, considering Kracko had been consistently been referred to as "he" before, we would still use "he", and if the next games started to use "it" for Kracko we would change the whole page to refer to Kracko as "it", but if it didn't, we would just keep using "he"? - Gigi (talk • edits) 16:28, 30 January 2023 (UTC)

I think if we got to the point where so many subsequent games started using "it" consistently, then we'd have to conclude that "it" is what they intend, so yes, in that case we would change the whole article to "it". That would be an extreme outlier case, though, as far as I am concerned. --Samwell (talk) 16:31, 30 January 2023 (UTC)

So for the point I brought up in my support comment (the same one Trig and Infinite are likely worried about), how would we handle having a character who switches pronouns very regularly and one doesn't seem to take priority over the other?
"this rule does not apply across different canons"
I figured that this meant that pronouns used in the main-series games would overall take priority (and so maybe that would resolve this issue). I would still like to ask about it though. -- Jellytost ♡ (talk) 22:47, 4 February 2023 (UTC)

Change 2: Solidifying entity names

This part of the proposal has already passed. See below for details.

Change 3: Infobox representation

Admittedly, this one's not really an issue right now, but I still think it's important to have a firm decision on this point. For the main infobox of the page, the image used of a character or other entity should be the most representative/consistent image, not necessarily the most recent one. This rule has largely been followed in practice, but a formal clause should be put in place so nobody thinks to put whatever temporary makeover King Dedede gets in the next game up as his main infobox image like what was attempted when Kirby and the Forgotten Land was the upcoming game. :P

Support

Not much to add here other than I completely agree. It's been an unwritten rule for a while so I fully support making it an official one. - Gigi (talk • edits) 15:03, 29 January 2023 (UTC)
Agree as well, provided that accompanying the policy is a document with a few different example entities showing examples of representative and un-representative images for each. —willidleaway [talk | edits] 15:26, 29 January 2023 (UTC)
Agreed. The infobox is meant for the character as a whole, not for the character in one game specifically. ---Pink Yoshi Fan 16:05, 30 January 2023 (UTC)
Kind of surprised we weren't doing this already, to be honest. Trig - 16:15, 30 January 2023 (UTC)
As long as we the editors can come to a consensus on what is the most "representative" image of a character, I support this. Epic Yarn is a good example of why using the latest official artwork of a character is not always the best action. --kirb 17:58, 4 February 2023 (UTC)
Not a lot for me to say here. This sounds good to me. There will be some discussions on what the "most representative image" is sometimes, but that's natural. -- Jellytost ♡ (talk) 22:47, 4 February 2023 (UTC)
Not a lot for me to say here outside of consistency. Yoshi's Island 11:18, 8 February 2023 (UTC)
Basically turning unwritten into written. Support. Superbound (talk) 21:29, 11 February 2023 (UTC)
I support this, but not under the notion of "choosing the most representative/consistent image", but instead both under the notion of "not choosing necessarily the most recent image" and under the notion of "treating it in a case-by-case basis". What image to choose depends on the character/article. -Zolerian (talk | contribs) 19:46, 12 February 2023 (UTC)

Oppose

Neutral

Similar to change one, there may come up some things where a "most representative" image would need proper deciding between editors first. So while I'm not exactly opposed to the idea to make it a real guideline, I can't say I'm really convinced either. Infinite Possibilities (talk) 20:16, 4 February 2023 (UTC)

Change 3 discussion

So, at the risk of opening a can of caterpillars but just to have a point of reference ... with the example of Dedede, what would be considered the most representative/consistent image? (It's definitely not the KatFL design, true.)

And for enemies that only appeared in sprite-based games, would we consider official out-of-game artwork to be more representative than the in-game sprite where appropriate, or vice versa? It seems like Twizzy (my beloved) is a good case study in that (in my eye) the official KDL artwork is clearly inconsistent but the KNiDL artwork (which is the current infobox image) is reasonably consistent with all of the in-game sprites and much higher-resolution (and thus should stay the infobox image). —willidleaway [talk | edits] 15:02, 29 January 2023 (UTC)

We can probably formalize some finer details, but basically right now an image like that would be any artwork when available, from the most recent game that accurately represents the character. Sure the specifics of that is hard to put into words, but using Dedede again as an example, he is using File:KRtDLD King Dedede.png which accurate represents him. We didn't use File:KatFL King Dedede artwork.png when FL was his latest appearence because that's his appearance as a boss only, which for an article about Dedede as a whole would be innacurate as he's more often an ally than foe lately. Another examples of images that wouldn't fit his main infobox would be File:King Dedede SSBU.png (as it's from Smash), File:Buff King Dedede KSA artwork.png (again, boss form), and File:K30AMF King Dedede artwork.png (using a design from a real world event and not a game). - Gigi (talk • edits) 15:10, 29 January 2023 (UTC)

I actually like this way of framing it—in ambiguous situations like this, counterexamples are often the best way to suggest what is acceptable. (Tangential example: one might show an example of an acceptable photo for a passport or ID card, followed by several mildly amusing examples of clearly unacceptable photos, suggesting regions of acceptable and unacceptable images without actually having to draw the border.) To that list of Dedede counterexamples I would also add File:King Dedede ball KCC artwork.png, potentially also to argue that designs should be from mainline Kirby games as opposed to spin-off games wherever possible, and File:KDB_Character_Treat_Kirby_riding_King_Dedede_artwork.png, since it's low-res and an indirect appearance (even if the most recent one out of all the released games—this would also preclude a Keychain somehow ending up as the infobox image). —willidleaway [talk | edits] 15:26, 29 January 2023 (UTC)

Agreed with this, since it has long been an unwritten rule, but I have one small question, what if the design stays same, but the artstyle is different (both minor, like everything having thick outlines as it is seen in KRtDLD, but also more major, like Kirby: Canvas Curse or Kirby and the Rainbow Curse)? Superbound (talk) 15:40, 29 January 2023 (UTC)

IMO we should probably treat it case-by-cases, but minor artstyle changes I would say should be fine to use, drastic ones probably not, but for example I'm not sure if I consider Rainbow Curse a major one, but Canvas Curse and Epic Yarn I would. - Gigi (talk • edits) 16:25, 30 January 2023 (UTC)

I see. Superbound (talk) 21:29, 11 February 2023 (UTC)

Solidifying character names and attributes in article writing - Change 2: Solidifying entity names (January 29th, 2023 - February 5th, 2023)

On WiKirby, it has been customary to refer to the names of entities differently based on which game or other media they are in. For example, in the original Kirby's Dream Land, Maxim Tomatoes are referred to as "Bag of Magic Food" in the manual, so they are called that on the wiki whenever talking about them in article text specific to Kirby's Dream Land. Another example is referring to Tiff by her Japanese name "Fumu" whenever talking about the Japanese version of the anime specifically. However, it has been brought up that this convention can be confusing to readers, even if strictly speaking more accurate. If this sub-proposal passes, WiKirby will stop referring to entities by different names based on circumstance and only use the most consistent names, mentioning different names only as an aside, unless that different name is prominent in the game/scenario (such as the name "Aeon Hero" for Galacta Knight in Super Kirby Clash).

Support

I very much agree with this. I have had a decent amount of confusion reading some articles due to the names not being consistent. As for the anime, I feel like this would especially help those (like me) who have never watched the Japanese sub and would save time so they do not need to look up whatever it is that they are confused about. ~☆Star void⁠☆ (t · c) 14:55, 29 January 2023 (UTC)
This seems reasonable—as an extreme supporting example, you wouldn't leave an entity un-named when discussing it in the context of a specific game if that entity got a consistent name in later games. Any context short of literally quoting from the instruction manual or strategy guide should simply have a parenthetical aside or footnote about the original name, and move on using whatever name is (or would be) used for the article for that entity based on the wiki naming policy. —willidleaway [talk | edits] 15:11, 29 January 2023 (UTC)
We also stick to this unwritten rule even if it's a clear typo or mistranslation, Mr. Flosty being most infamous example. I don't really see why we need to stick to developers' mistakes in writing everywhere, especially if they later correct themselves. Superbound (talk) 15:55, 29 January 2023 (UTC)
It is pretty confusing in the most egregious of cases (articles related to the anime especially), so standardizing things in this manner would make it easier for readers that aren't invested in the Kirby series as a whole to not get lost. In other words, per all. – Owencrazyboy17 (talk) 17:06, 29 January 2023 (UTC)
Personally, I feel like consistency is key. By making everything uniform, it will make things less confusing for everyone. I've also gotten a bit confused myself at times when reading articles, so standardizing everything would greatly help. Would definitely have to add a note at the start of all the pages saying that in game they're referred differently however. GoldenDragonLeaf (talk) 03:49, 30 January 2023 (UTC)
Agreed. Same as with the gender thing, the devs being inconsistient doesn't mean that we need to be inconsistient. ---Pink Yoshi Fan 16:01, 30 January 2023 (UTC)
Above has said enough. Sounds good to me. Trig - 16:15, 30 January 2023 (UTC)
As long as the exception in the last sentence of this proposal means we don't just start systemically changing all "Smash" or "Fireball" appearances to "Smash Bros." and "Burning" disregarding the context reader is put into. If there's say a glitch in Kirby & The Amazing Mirror or Kirby's Adventure that requires prominently named Smash or Fireball abilities in respective games, telling the reader/player to aquire "Smash Bros." or "Burning", non-existent as such in respective games, would be more confusing than vice-versa. Whereas examples brought up in this proposal are an obscure prototypical name of Maxim Tomato in an instruction manual and a romanization of Tiff's name in a different language/localization. ⁠–⁠Wiz (talk · edits) 23:41, 30 January 2023 (UTC)
I support consistency and clarity, regardless of minor developer errors. Both the first and second parts of this proposal will prevent readers from becoming confused. --kirb 18:09, 4 February 2023 (UTC)
Consistency provides clarity, so I think this is a valid thing to happen. Additionally, here it would be much clearer what the "prominent name" is. Infinite Possibilities (talk) 20:16, 4 February 2023 (UTC)
This sounds all good to me for the above reasons, though I agree with Vipz that we should consider context in certain instances. Clarifying in those areas will be handy and will make sure readers aren't confuzzled. -- Jellytost ♡ (talk) 22:47, 4 February 2023 (UTC)

Oppose

Neutral

Change 2 discussion

Here's a theoretical question: what if the next Kirby game were to call Waddle Doo "Cyclops Dee"? Would we have to move the enemy's page, change all mentions of and links to it, and move all files related to it? --kirb 17:56, 4 February 2023 (UTC)

Okay, let's say for the sake of argument that that happens. If the name was prominent in the game (used repeatedly in dialogue, given a formal nameplate, etc.) then we'd be forced to use that name when referring to Waddle Doo in that specific context. If it's just a weird outlier (like the name of a keychain or character treat), then it can be mentioned as an aside and otherwise ignored. --Samwell (talk) 18:02, 4 February 2023 (UTC)

That makes sense, but if "Cyclops Dee" were to be used exclusively, would we be forced to use "Cyclops Dee" retroactively? Would it depend on if said game was a mainline or spin-off game, or if the name began to appear in all official media? --kirb 18:06, 4 February 2023 (UTC)

I think it would take several games and a concerted push from HAL to make that happen, so it wouldn't be a sudden decision on our part. --Samwell (talk) 18:07, 4 February 2023 (UTC)

Alright, that makes sense to me. --kirb 18:09, 4 February 2023 (UTC)

@@ Line 3: / Line 3: @@
 =Proposals=
-==Files with Template:Link needed should be ineligible for Good status (112821–121221)==
+==Standardize wiki text to favor some words without hyphens (December 17th, 2023 - December 24th, 2023)==
-'''''NOTE:'''This proposal has been deemed redundant, since what it proposed is already de-facto policy. It has been placed here for reference purposes.''
+I honestly don't know what else to name this, nor exactly how to word it as a guideline eventually. But these five words in particular have been brought up by many different editors over the years, and it has caused some confusion of new editors and sometimes even readers.
-Currently as set in the [[WiKirby:Featured content policy]], the parameters for a Good image are the following conditions:
+You are reading an article, and it writes "moveset" for one section. You keep reading and another section calls it "move-set". Does that sound familiar?
-*a high quality image with no significant aberrations OR a high-quality audio file with no significant distortion.
-*sound of format (no improvement notice templates are present).
-*has complete documentation with source (where applicable).
-*properly licensed.
-*properly categorized.
-*used in at least one article.
-While <nowiki>{{Link needed}}</nowiki> primarily focuses on files that do not have links to listed source files. This proposal sets to claim that any file that uses Link needed is ineligible for Good status, and any files currently utilizing sourced but unlinked files immediately enter into the revoke good process. The reason is primarily in the following terms:
-*sound of format (no improvement notice templates are present).
-*has complete documentation with source (where applicable).
-*properly licensed.
-Licensing is the least likely, but there is a very rare chance a linked file may NOT be used without permission or that it is released under an alternate license that is incorrectly registered on this site. The larger two issues revolve around sound of format; That the file has no notice templates whereas Link needed qualifies as a notice template, and Complete documentation with source. Because there is not a link to the source so that readers may track to the original source, it would stand to say that this does not qualify as complete documentation, and should therefore fail Good qualifications.
-<br>
-An alternate way to describe this scenario is that an ordinary "Good" file has no more reasonable edits to make on it while on-site. This is not the case for Link needed files, as they should feature links to the sources which would require an edit to correct.
-Thank you for your time. <small>[[User:Trig Jegman|Trig]] - 05:41, 28 November 2021 (UTC)</small>
+Move-set, cut-scene, mid-air, 3-D and 2-D are the five most common words I've seen on WiKirby article text that are sometimes spelled with hyphens, sometimes not. In particular, most of these five words are mostly commonly spelled without hyphens (which I will prove soon), and in official Kirby text, we've only had usages of them without hyphens as far as I know (although for "moveset", I haven't really seen any official use of the word in any form). You are free to correct me if I'm wrong on official usage, but in particular for 3D and 2D, I've fairly sure of that, at least in recent sources. And, I mean, it's the Nintendo 3DS and 2DS, not 3-DS and 2-DS...
-{{Support}}
-{{Oppose}}
+Point is, there is no standardization, so some articles use them with hyphens, some without, some mix and match, and it's not uncommon for editors to go and "fix" to one way or the other. But without a rule, anyone could revert these changes and go "actually, I prefer with/without hyphen". Also, as I mentioned, it's clear that the most common forms of these five words are without hyphens, being used in official Kirby media as well.
-{{Neutral}}
-===Discussion===
+With all these in mind, my proposal is to standardize the spelling of these words, much how we favor spelling of words in American English, to the following:
-Just out of curiosity, how would this proposal affect images whose sources cannot be directly linked to, such as a press kit release? --[[User:Samwell|Samwell]] ([[User talk:Samwell|talk]]) 11:51, 28 November 2021 (UTC)
-:I am not 100% clear how those are formatted. If there aren't direct links available or they aren't say legal to share elsewhere, then press kit should just be listed as the source and Link needed template should just be removed. [[User:Trig Jegman|Trig]] - 17:34, 28 November 2021 (UTC)
-::In that case, I'm not entirely sure what the key change you want to make is, aside from using the link needed template in place of the file source template. As far as I was concerned, both templates cover the same ground. Only reason any file with the file source template on it might still be listed as Good would be because we hadn't gotten around to revoking it yet. --[[User:Samwell|Samwell]] ([[User talk:Samwell|talk]]) 21:24, 28 November 2021 (UTC)
-:::Well, the difference is that while something that would have used File source has ''no'' listed source, a Link needed file ''has'' a listed source--just not with a link to it. Some may justify that with a listed source but no link, that a source is complete. I serve to argue that it is not. [[User:Trig Jegman|Trig]] - 21:31, 28 November 2021 (UTC)
-::::Yeah, file source is meant to cover situations like that. Might reword existing policy to make that clearer, but it sounds like a proposal isn't needed for this. --[[User:Samwell|Samwell]] ([[User talk:Samwell|talk]]) 22:28, 28 November 2021 (UTC)
-::For clarity's sake, files without listed sources, those that would use File source or with empty source parameters in Aboutfile 2 are already ineligible for good. The fork from File source template into no listed source in Aboufile or link needed template complicated this however, because instead of a general "Help needed" template, I split them into two specific categories of no link and link needed did not fully specify how the conditions of Good would work. This sets to resolve that. [[User:Trig Jegman|Trig]] - 14:38, 29 November 2021 (UTC)
-:::Do files have to go through {{t|Revoke Good}}, because neither policies nor the template mentions files? I agree with Samwell here, this is ''de-facto'' already in practice but should be clarified on the policy page, including exceptions (e.g. [[:File:Nintendo Power V68 Super Power Club.png|non-own book scans]] from an unimportant imageboard I don't want to link). {{User:Vipz/sig}} 22:33, 1 December 2021 (UTC)
-(Separate from current discussion) Wouldn't link needed already cause files to be not good due to the no improvement notice templates condition? {{User:Pinkyoshifan/sig}} 14:44, 29 November 2021 (UTC)
+*'''Cutscene''' over '''cut-scene'''. "Cutscene" has 33 million results in Google, while "cut-scene" has 3 million. One example of "cutscene" being used in official Kirby media, Miiverse posts: [[List of HAL Laboratory Miiverse posts - Kirby: Triple Deluxe]];
-::Yes, it does. This redundancy is further reason I would like to make it absolutely clear this qualifies. [[User:Trig Jegman|Trig]] - 17:28, 29 November 2021 (UTC)
+*'''Moveset''' over '''move-set'''. "Moveset" has 15 million results on Google, while "move-set" has 1.5 million (with many actually resulting in finding "move set", and not "move-set"). I don't actually know any examples of official Kirby media using the word in either form;
-:::So what's the point of making link needed make files ineligible for good if it already effectively does that? {{User:Pinkyoshifan/sig}} 22:12, 29 November 2021 (UTC)
+*'''Midair''' over '''mid-air'''. This one is the only one basically tied on Google: "midair" has 18 million results on Google, while "mid-air" has 22 million. However, officially Kirby has only ever used "midair", in moveset descriptions;
-{{clear}}
+*'''3D''' over '''3-D'''. "3D" has 3.6 billion results on Google, while "3-D" has 276 million. Many names use "3D" and none use "3-D", such as [[3D Classics: Kirby's Adventure]], [[3D Helmet Cannon]], [[3D Warp Star]] etc. Descriptions of ''Forgotten Land'' in particular use 3D, such as [https://www.nintendo.com/us/store/products/kirby-and-the-forgotten-land-switch/ the one on Nintendo's website];
+*'''2D''' over '''2-D'''. "2D" has 1.2 billion results on Google, while "2-D" has 214 million (should mention though that a good number of the results actually are for the Gorillaz member). For consistency with "3D". I don't know of many sources that use "2D", but at least [https://gigi9714.wordpress.com/2023/04/07/translation-of-the-kirbys-return-to-dream-land-deluxe-interview-from-the-may-2023-edition-of-nintendo-dream/ this interview I translated] used it (yes, even in the original Japanese text).
-==Coverage of non-Kirby content in NES Remix 2 & Ultimate NES Remix (November 16th 2021 - November 30th 2021)==
+So, what do you all think? I think something like this is long overdue. I accept suggestions on where/how to word it, but I feel this is something we need to officially address in some form. {{User:Gigi/sig}} 19:14, 17 December 2023 (UTC)
-Inspired by the recent debate around Smash Bros. coverage since that is a similar topic I'm comming forth with a few options regarding the non-Kirby games featured in NES Remix 2 and Ultimate NES Remix. Here's a little layout for a better understanding:
-*Kirby's Adventure is the only Kirby game featured in these titles
-*The non-Kirby regular stages don't feature anything related to the series
-*In Remix and Bonus stages the challenges sometimes run through multiple games
-*Remix and Bonus stages also feature other characters in the Kirby's Adventure environment while Kirby is sometimes put into another gane himself.
-As far as I'm concerned there are three options.
-====1. Mention which games are featured and include stage parts from other games in the tables given a Kirby challenge also is in the pack====
-Basically, the games get a mention with respective links to their respective wikis and are featured in stage tables if a Kirby challenge is in the same stage. This would make all stage tables complete for their respective stages, at the cost of talking about a game unrelated to the ''Kirby'' series.
-====2. Only mention the games featured====
-The games are all listed with respective links while the stage tables exclusively go over those that have a direct Kirby connection. For example, in Ultimate NES Remix's 25th Bonus stage the table would only feature 25-2 and 25-7. This option is also the closest to what the Super Mario Wiki does.
-====3. Don't mention them at all outside of when they're remixed with Kirby's Adventure====
-The only mention the games would get is in Remix/Bonus stages where Kirby's Adventure elements collide with them. For example in Ultimate NES Remix's 10th Bonus stage Super Mario Bros. The Lost Levels would be mentioned as Bullet Bills from that game appear in a Kirby challenge.
-I'm sorry if something confuses you. Writing stuff like this isn't my strong suit. If any of you have other suggestions, please post them in the "Discussion" section.   [[User:Infinite Possibilities|Infinite Possibilities]] ([[User talk:Infinite Possibilities|talk]]) 19:40, 16 November 2021 (UTC)
-===Voting===
 {{Support}}
-#I would prefer to see option 3; Only cover external elements when absolutely necessary and focus on covering Kirby content. [[User:Trig Jegman|Trig]] - 20:05, 16 November 2021 (UTC)
+#I definitely agree that it should be standardized. For every example other than move-set, it automatically makes the most sense to spell it without a hyphen, since that's what official Kirby media does. For every example other than mid-air, it's more commonly spelled without a hyphen online. And for all examples, I personally think it just looks better without a hyphen. {{User:RHVGamer/sig}} 19:34, 17 December 2023 (UTC)
-#Listing the non-Kirby stages with interwikis and going more in-depth on Kirby content sounds good, so I support option 2. {{User:Pinkyoshifan/sig}} 23:05, 16 November 2021 (UTC)
+#Standardization is good, especially when it matches Kirby media. {{User:Pinkyoshifan/sig}} 21:33, 17 December 2023 (UTC)
-#Seeing more in depth everything, I vote for option '''2'''. With option 1, every stage would be covered fully even if it does not have any Kirby thing in it. But this is WiKirby, not [[nwiki:Main Page|NintendoWiki]], covering the ''NES Remixes'' completely is up to them, so just listing the other games suffices.<br> With option 3, every game that doesn't have something with ''Kirby's Adventure'' would be deleted from the matrix, not even mentioned, and I think that at least mentioning each game featured in the ''NES Remixes'' would be good. So option '''2''' seems to be the more balanced to me. -[[User:Kirbeat|Kirbeat]] ([[User talk:Kirbeat|talk]]) 05:27, 18 November 2021 (UTC)
+#I'm in favor of consistency, especially considering how most of these terms have spelling variant that is clearly more common than the other. [[User:Typman|Typman]] ([[User talk:Typman|talk]]) 22:40, 17 December 2023 (UTC)
-#I am precisely in agreement with the above message. I'll go with option '''2''' due it its reasonable balance. -- {{User:MetaDragon/sig}} 03:02, 22 November 2021 (UTC)
+#I agree. Consistency is cool. --[[User:Paistrie|Paistrie]] ([[User talk:Paistrie|talk]]) 00:06, 18 December 2023 (UTC)
-<s>#I vote on option '''1''', if I understood correctly the options. If there is a ''Kirby'' related thing, it should be covered here. Like, If Kirby, the character, appears in a stage of another game, it should be covered here.<br> I don't vote on 2 because I understand that with that option, if Kirby appears on ''Super Mario Bros.'', it wouldn't be covered. But I think that that case should be covered, so 2 is out for me.<br> And with 3 it would be the same thing, as I get that in a non-remix stage ''Kirby'' and ''Mario'' content clash, it wouldn't be covered, but to me that, well, ''should be covered here''. So in short, I want that every thing in which a ''Kirby'' related thing appears is covered here.<br> I'm in disagreement if something like, a stage where there is just Bomberman gameplay with the Bomberman characters, without Kirby at all, is covered. Though I think none of the options support that anyways.<br> (If I didn't understood something correctly, an clarification at the Discussion section would be appreciated to formulate my vote better, but for now I will go with '''1'''.) -[[User:Kirbeat|Kirbeat]] ([[User talk:Kirbeat|talk]]) 22:21, 16 November 2021 (UTC)</s>
+#Support. (And even if moveset isn't confirmed anywhere I prefer that, which isn't what we're going for but still consistent) {{User:ShadowKirby/sig}} 07:14, 18 December 2023 (UTC)
+#Consistency is important, so support. --{{User:EleCyon/sig}} 13:54, 18 December 2023 (UTC)
+#Consistency is always appreciated, support. [[User:Infinite Possibilities|Infinite Possibilities]] ([[User talk:Infinite Possibilities|talk]]) 19:52, 19 December 2023 (UTC)
+#Though I still prefer “move set”, a more formal spelling used by ''Smash Bros.'', all four others are entered in the Merriam-Webster and New Oxford American dictionaries unhyphenated. And in any case, consistency is always a good idea. {{User:YoshiFlutterJump/sig}} 22:57, 19 December 2023 (UTC)
+#I agree. There's not really anything I can say to support it since everyone else had the same idea, but it holds the same weight. {{User:Starvoid/sig}} 23:15, 19 December 2023 (UTC)
+#This is on the same level as (for example) having articles written in third person and in present tense by default, and likewise should be part of the [[WiKirby:Writing style|style guide]]. {{User:WillIdleAway/sig}} 00:35, 20 December 2023 (UTC)
 {{Oppose}}
 {{Neutral}}
 ===Discussion===
-*Here are two helpful links, one to the Sandbox where the current NES Remix stuff is located, the other to the Super Mario Wikis version of NES Remix 2.
+I don't think this changes much, but looks like Miiverse also used "cut-scene" once: https://web.archive.org/https://miiverse.nintendo.net/posts/AYMHAAACAADRUqGa3vd22Q However, "cutscene" was used in two posts after, in particular one of these posts had the word used like "cutscene" 10 times [https://web.archive.org/https://miiverse.nintendo.net/posts/AYMHAAACAAADVHh_BVD3fg this] and [https://web.archive.org/https://miiverse.nintendo.net/posts/AYMHAAACAAADVHj_P9zo9Q this]. {{User:Gigi/sig}} 17:02, 22 December 2023 (UTC)
-**[[User:Infinite Possibilities/Sandbox#NES Remix 2 + Ultimate NES Remix: Kirby's Adventure|NES Remix 2 + Ultimate NES Remix: Kirby's Adventure]]
+{{clear}}
-**[[mariowiki:NES Remix 2]]
-[[User:Infinite Possibilities|Infinite Possibilities]] ([[User talk:Infinite Possibilities|talk]]) 19:40, 16 November 2021 (UTC)
-Since it seems like clarification is needed, here are hopefully clearer explanations:
+==Adjust/Remove Proposal Rule 15 (16 November 2023 – 30 November 2023)==
-*Option 1. Coverage would include non-Kirby content if it appears in the same stage as Kirby content. All games would be listed fairly early in the page.
+As can be seen dueing the time of this proposal, technically it's already being bent, but it would be good to get things straight. There is no real reason to have the "1 proposal at a time per user" rule, because, realistically, either a user with good ideas would have to wait to share them, or a productive user just simply wouldn't have a second+ idea to share. Making proposals is limited to Autopatrol+ anyway, so it's not like we have to worry about the quality and good intentions of the user making the proposal. In short, I don't think this rule is necessary. However, when brought up on Discord, there was the thought that it should still be discouraged to have more than 1 up, which would be a warning against funny business. That's where the voting comes in (for logical reasons, a vote for either of the first 2 options is still a vote in favour of changing the rule, the difference is in the extent of the change). {{User:ShadowKirby/sig}} 18:16, 16 November 2023 (UTC)
-*Option 2. Coverage would be limited to stages where Kirby content makes direct appearances. The games would be listed.
-*Option 3. Coverage would be limited to where Kirby is the main focus of the challenge. Other games are only mentioned if their elements appear in Kirby stages.
-[[User:Infinite Possibilities|Infinite Possibilities]] ([[User talk:Infinite Possibilities|talk]]) 08:58, 17 November 2021 (UTC)
-=== Result ===
+{{Option|1|Remove rule}}
-Option 2 is the winner, with three votes.
+#Strongly support its complete and total abolition. It is, for all intents and purposes, useless. It unnecessarily delays proceedings and discredits ideas simply because the same user proposed another one. If it ''really'' became a problem, that's what admin vetoes are for. Not that I think that'd ever happen. -{{User:YoshiFlutterJump/sig}} 18:56, 16 November 2023 (UTC)
+#I don't really see a point in  discouraging to much. I don't think it does much harm to have more than one proposal from the same person, as long as it's not done maliciously or anything. {{User:Basic Person/sig}} 22:03, 16 November 2023 (UTC)
+#The fact the rule is already being broken without so much as an objection should speak for itself on how good a rule it is, and "discourage" is vague and not very actionable, would we just arbitrarily start deleting proposals for no reason other than there being too many? Better to just either keep the rule or not for clarity's sake. Or if people are really opposed to the idea of one person making too many proposals at once, we could have a limit on how many one user can have (maybe two or three). [[User:Hewer|Hewer]] ([[User talk:Hewer|talk]] &middot; [[Special:Contributions/Hewer|contributions]]) 18:41, 18 November 2023 (UTC)
+#I understand the concern about too many proposals too fast, but I think that's something anyone with common sense should understand. If it's really necessary (not really IMO) then it can be left as a reminder/suggestion, but the rule is practically made to be broken. [[User:Waddlez3121|Waddlez3121]] ([[User talk:Waddlez3121|talk]]) 23:13, 19 November 2023 (UTC)
+{{Option|2|Discourage but not disallow}}
+#I feel like most people would try to keep the number of proposals down to a reasonable extent anyways, but I think discouraging it would still be good. {{User:Pinkyoshifan/sig}} 18:33, 16 November 2023 (UTC)
+#Agree on making it "discouraged but not disallowed". We don't want to have a ton of proposals at once (right now I already feel like we have a bit too many), but there's no reason for the same user not to make multiple proposals at once aside from that, especially if they're all related changes. [[User:StarPunch|StarPunch]] ([[User talk:StarPunch|talk]]) 23:12, 16 November 2023 (UTC)
+#This option seems to be the most reasonable because a large amount of proposals might be too overwhelming for some. There should only be more than the usual amount of these occasionally. --[[User:Paistrie|Paistrie]] ([[User talk:Paistrie|talk]]) 21:02, 17 November 2023 (UTC)
+#I feel we don't need to restrict that much but I also think it's good to make editors keep in mind that we don't want someone to suggest many changes that fast. {{User:Gigi/sig}} 17:53, 18 November 2023 (UTC)
+#Pretty much what the others above said. Having a reminder that multiple proposals from the same person are allowed, but discouraging it is the best way to do it imho. [[User:Infinite Possibilities|Infinite Possibilities]] ([[User talk:Infinite Possibilities|talk]]) 17:33, 30 November 2023 (UTC)
+{{Option|3|Keep as is (Opposed)}}
-{{clear}}
-==Change the way featured content queue works (November 14, 2021 - November 28, 2021)==
-Right now, whenever an article or a picture gets featured, it appears on the front page as soon as the nomination passes, overtaking whatever is in there at the moment. While I'm not opposed to favoring the newest articles or pictures, I don't like how it happens at the cost of other featured content. Hence, I'm proposing for <u>most recently featured articles/pictures to appear the next Sunday after their nomination passes</u>,. Note that this has been the case for a really long time unofficially ([https://wikirby.com/w/index.php?title=Template:FA/doc&diff=193930&oldid=193812]
-[https://wikirby.com/w/index.php?title=Template:FA/doc&diff=190241&oldid=188946]
-[https://wikirby.com/w/index.php?title=Template:FA/doc&diff=224489&oldid=223743]
-[https://wikirby.com/w/index.php?title=Template:FA/doc&diff=222897&oldid=222206]
-[https://wikirby.com/w/index.php?title=Template:FA/doc&diff=218712&oldid=216059]
-[https://wikirby.com/w/index.php?title=Template:FA/doc&diff=243869&oldid=230206]
-[https://wikirby.com/w/index.php?title=Template:FA/doc&diff=248729&oldid=247736]), however, there was no formal discussion or decision about it according to Gigi. Thoughts on this? {{User:Superbound/sig}} 14:29, 14 November 2021 (UTC)
-{{Support}}
-#Completely agree, it is way cleaner that way. In the actual state of things, if a page/picture gets featured a day before the next rotation begins, it will either be featured by 1 day, or by 8 days, which messes up the things quite a bit. And if a page/picture is featured a day after the rotation begins, it will be featured by 6 days, but the previous one will be there just 1 day, which isn't fair. So in this way everything gets a pair and fair time on display, and if it has been like that before, it is for something. (Unrelated note and recommendation, there is a cleaner way to link to differences. See this [[Special:Diff/193930|[1]]] for example.) -[[User:Kirbeat|Kirbeat]] ([[User talk:Kirbeat|talk]]) 15:26, 16 November 2021 (UTC)
-#I prefer consistency here. Changing between articles randomly could confuse some people. This will be much more simple and fair--as long as we remember to update the articles in the first place when the time comes, of course. :P -- {{User:MetaDragon/sig}} 03:02, 22 November 2021 (UTC)
-#Consistiency is good, and it's not really that important to put something on the main page ''immediately''. {{User:Pinkyoshifan/sig}} 13:16, 28 November 2021 (UTC)
-{{Oppose}}
 {{Neutral}}
-#I really do not think the length of Featured Content matters. If something passes, then it can change. At worst, more variety the better. This isn't to necessarily say I want no minimum time, as though we could switch it every 8 hours or something ridiculous like that, but I don't think worrying about the difference between 1 to 8 days matters significantly enough in order to warrant this policy being instilled. [[User:Trig Jegman|Trig]] - 20:05, 16 November 2021 (UTC)
-#Maybe it's just me but I do believe that the current way doesn't need to be changed. I'm not paticulary against this suggestion, just don't think it's necessary. [[User:Infinite Possibilities|Infinite Possibilities]] ([[User talk:Infinite Possibilities|talk]]) 20:45, 27 November 2021 (UTC)
 ===Discussion===
-{{clear}}
+==Disallow links in quotes, flavor text, etc (November 16th, 2023 - November 30th, 2023)==
+I will admit this is minor all things considered, but this has bothered me for a long time. To give an example, take [[Magolor]]'s quote from his page:
-==Archive all significant discussion pages for deleted articles and files (11/12/2021 - 11/26/2021)==
+{{quote|Hi there! My name is {{color|orange|Magolor}}. I'm from {{color|orange|another dimension}}, but I just love [[Popstar|Planet Popstar]]. I can't get enough of it! Things got a bit hectic [[Kirby's Return to Dream Land|when I first arrived]], but that's all in the past, thanks to [[Kirby]].|Magolor's opening dialogue from [[New Challenge Stages]] in ''[[Kirby's Dream Collection Special Edition]]''}}
-So, looking at the long discussion that has ballooned in [[Talk:List of composers]], and seeing what the likely fate of its parent article will be, I think it would be a shame for such a talk page to be deleted just as a matter or course. My proposal is simply that if there is any significant content (especially if there are debates regarding the wiki and its mission) in a discussion page of an article or file that gets deleted, that discussion page should be archived rather than deleted. Vote now with your phones. --[[User:Samwell|Samwell]] ([[User talk:Samwell|talk]]) 14:24, 12 November 2021 (UTC)
+As you can see, this features colored text. Orange and... wait a second, blue text?
-{{Support}}
+Well, yeah, these are links to other pages. However, from a quick glance, one could confuse them with colored text, since there is colored text from the actual game before (in orange). Keep in mind I am only talking about Magolor's own quote, not the text after that has links to [[New Challenge Stages]] and ''[[Kirby's Dream Collection Special Edition]]'': those are fine to stay, as they aren't quotes.
-#History shouldn't be deleted, especially if that history is why something else was deleted. {{User:Pinkyoshifan/sig}} 14:31, 12 November 2021 (UTC)
-#^What he said. Without the conversation leading to the deletion, we might forget why we deleted it in the first place. :P {{User:Kirb/sig}} 15:36, 12 November 2021 (UTC)
-#^^What they said + if we don't know why something got deleted it'll likely come to a repeat discussion. It could also help with deciding the fates of other pages where similar arguments could accour. [[User:Infinite Possibilities|Infinite Possibilities]] ([[User talk:Infinite Possibilities|talk]]) 15:51, 12 November 2021 (UTC)
-#I was under the impression that those were always meant to be archived rather than straight up deleted. So you have my support for archiving, as talk pages should be preserved in case the discussion needs to be checked again after it's over for any reason. {{User:Gigi/sig}} 15:54, 12 November 2021 (UTC)
-#Huge fan of preserving, so support. I don't see a reason why it's a bad thing that a talk page exist without its core page; moving discussion to a single page would also probably be more work in exchange for minimal benefit. Perhaps a special, separate category or a navigation page could compromise. {{User:Superbound/sig}} 14:29, 14 November 2021 (UTC)
-#What everyone said :P If a discussion is significant, it should be preserved somehow. I agree that it is better having just one "Talk/Disussion Page archive" (because in this wiki it isn't so clear which of the two names is the "correct" one) instead of putting each archive on several pages. For example, if the list of composers is deleted, and a "Music" page borns, the archive of that long discussion should be on the "Talk/Disussion Page archive" instead on somewhere on the Music page. -[[User:Kirbeat|Kirbeat]] ([[User talk:Kirbeat|talk]]) 14:59, 16 November 2021 (UTC)
-#I am of the firm belief that history should be preserved whenever possible, and doing this in addition would save us a lot of trouble in the future I believe. Deleting it feels like a hurtful waste, but keeping it around seems only to result in positives, so why not? -- {{User:MetaDragon/sig}} 03:02, 22 November 2021 (UTC)
-{{Oppose}}
-#I am of the belief that if the page does not exist, the talk page does not need to either. If it is too significant an issue that it needs to remain in conversation, at '''''worst''''' it should be moved to one single page of talk page archives similar to the passed/failed proposals page. It is extraordinarily unlikely people will be finding talk pages for archives unless specific people remember the conversation and can route the reasoning. If a page is deleted, a reason in the deletion page description ''should be sufficient'' for the reason a page was deleted. Firm oppose, but suggest a single page for archives if absolutely needed. [[User:Trig Jegman|Trig]] - 16:01, 12 November 2021 (UTC)
-{{Neutral}}
-#I agree about archiving them, but in a single page archive like Trig suggests. In such case, to easily traverse through long discussions, I would also make their sections auto-collapsed (like you see with tables). {{User:Vipz/sig}} 01:27, 14 November 2021 (UTC)
-===Discussion===
+Take another example from Magolor's page:
-{{clear}}
+{{quote|Anyway... MUAHAHAHAHAHAHAHA! The time has come for your planet... No! The time has come for the ENTIRE UNIVERSE to bow down to me. And for being such a big help in all of this, your planet gets to go first! Prepare to bow, [[Popstar]]! Welcome your new overlord!|Magolor in ''Kirby's Return to Dream Land''}}
+This one actually features no colored text from the game, but the link to Popstar makes that blue, and one could think this is blue in the game, no? I mean, the emphasis on Popstar would make sense. In short, this misleads the reader.
-==Smash Bros. Coverage 110221–111621 EXT: 112521==
+But you may argue that in Kirby games all colored text is orange/red/yellow, so with the links being blue it's not a problem, since they will always be clearly links. Well, that is the problem: there is colored text with blue text.
-This is a proposal relating to several conversations on Discord about how WiKirby should be moving forward in Smash Bros. content moving forward. Currently, most pages are set up in the following structure:
-*About the game
-*'''All''' Characters in a list
-*Kirby's moveset
-*King Dedede's moveset
-*Meta Knight's moveset
-*'''All''' stages in the game
-*Specifically only Kirby Stages
-*"Story Mode" or main non-Smash game mode
-*Items
-*Trophies
-*Gallery
-*Trivia/References/Footers
-There have been several vocalized concerns about the types of content being covered on these pages, as they are generally long in vertical length and not always being directly related to Kirby. The following are some suggested paths to move forward on covering content, listed in a form of most change to least change:
-====1-Completely redirect all Smash Bros. Content to SmashWiki, the Smash NIWA affiliate====
-The most extreme choice. If game pages remain, they mostly serve to just send people to SmashWiki after a short explanation of the game.
-====2-Reduce covered content to explicitly only cover Kirby content====
-Remove information about various game modes, non-kirby characters, and non-kirby stages.
-====3-Only remove character images on Brawl, 4, and Ultimate pages====
-One of the chief complaints is that having character images lengthens pages too much and therefore should be deleted, and move character lists back to single line text. This option would only seek to delete character pictures and no other change
-====4-No Changes====
-Current coverage is just fine the way that it is. No changes are necessary.
-====5-Increase Smash Bros. Coverage====
-This option is for arguing that Wikirby does not cover enough Smash content, and should work on developing ''more'', even if it isn't directly Kirby related.
-<br>
-Please discuss heavily! As for myself, I would prefer options 3 and 2 in order. [[User:Trig Jegman|Trig]] - 14:30, 2 November 2021 (UTC)
-===Voting===
-{{Support}}
-#3 sounds like the best option. {{User:Pinkyoshifan/sig}} 23:49, 3 November 2021 (UTC)
-#The ''Super Smash Bros.'' game pages are a bit anomalous at this point when it comes to pages that cover ''Smash Bros.'' content on WiKirby, since all other pages that deal with ''Smash Bros.'' content tend to only focus on the stuff that directly links to the ''Kirby'' series. At this point, I'm almost convinced that the pages on ''Super Smash Bros.'' games themselves should be removed entirely from WiKirby in favor of links to SmashWiki, and any relevant information on those pages be dispersed to the most appropriate pages (for instance, moving details on Kirby as a Smash Bros. fighter to the main [[Kirby]] page). For now though, just to make sure nothing moves too fast, I will vote for option '''2'''. --[[User:Samwell|Samwell]] ([[User talk:Samwell|talk]]) 20:48, 7 November 2021 (UTC)
-#I vote for option '''2'''.<br> Although there is a "joke" of Kirby sites covering Smash, because both were created by the same [[Masahiro Sakurai|person]] and [[HAL Laboratory|company]], I doubt that there is any reason to cover non-Kirby content here with the existence of  [[smashwiki:|Smash Wiki]]. [[pikipedia:Super Smash Bros. Ultimate|Pikipedia]]'s and [[inkipedia:Super Smash Bros. Ultimate|Inkipedia]]'s articles of Ultimate jumps directly to the content of their respective franchises evading any external content, and I think that WiKirby should do the same in every Smash page; not cover non-Kirby scenarios, nor the game modes if they don't have relation to Kirby. Having a list of all the characters is useful because, as Gigi said [[Talk:Super Smash Bros. Ultimate|here]], Kirby copies them, so they are relevant in the Kirby side. But having images of them is not necessary, a text listing like the ones in 64 and Melee pages suffices.<br> In short: 64, Melee, Brawl and For lists non-Kirby stages. Brawl, For and Ultimate have images of non-Kirby characters. Ultimate lists the game modes even if they have nothing to do with Kirby. I think that those things shouldn't be in WiKirby, and option '''2''' aims to do delete them, so there I go. -[[User:Kirbeat|Kirbeat]] ([[User talk:Kirbeat|talk]]) 02:46, 8 November 2021 (UTC)
-#Covering the content that specifically has nothing to do with the Kirby series doesn't really serve a purpose as there already is a NIWA wiki for that. Though I personally disagree with getting rid of all game modes since Ultimate's Classic Mode specifically makes use of the Kirby characters in other routes which reference stuff, so I vote for option '''3''' as it gets rid of the stuff most unneeded while keeping what I consider to be relevant enough. [[User:Infinite Possibilities|Infinite Possibilities]] ([[User talk:Infinite Possibilities|talk]]) 17:44, 11 November 2021 (UTC)
-#'''3''' It seems to me that covering Smash elements that don't relate to Kirby isn't very useful when SmashWiki is so extensive. I think we should keep around the pages, since the Smash series is technically a game in which Kirby appears as a playable character. We don't really need images of other fighters. {{User:Kirb/sig}} 15:34, 12 November 2021 (UTC)
-#Voting for '''3''' because 2 looks very extreme and 3 would solve the biggest problem we have right now. I would base them the other pages around ''[[Super Smash Bros. Ultimate]]'' minus the character images, as I believe it strikes a good balance of content about these games. {{User:Gigi/sig}} 16:00, 12 November 2021 (UTC)
-#This was certainly a tough decision... Both parties have good points. For a while now, I've been iffy about having the Smash Bros. pages on WiKirby ''at all'', but their existence doesn't hurt much as-is, especially since Kirby characters are playable. There's a chance they'll be wiped from the wiki eventually though, which is something I'm half-and-half on.<br>As for the content on the pages, I really don't see the need to cover non-Kirby content, though a very basic summary of some stuff is fine. We need a bit of general context here and there for the Kirby content itself, but not much at all. I don't believe that it will be misleading, since we can, for instance, title the Game Modes section as something like "Game Modes involving Kirby content". Stripping content away won't be a totally strict process. There's always room for suggestions in the future if things are going downhill or if anyone changes their mind.<br>With all of that said, I was originally going to play it safe with option 3, but after thinking about it for a few days, I'll be going with option '''2'''. -- {{User:MetaDragon/sig}} 03:02, 22 November 2021 (UTC)
-{{Oppose}}
-{{Neutral}}
-===Discussion===
+New Challenge Stages challenge descriptions like [[Sword Challenge (New Challenge Stages)]]:
-*I will post here every link relating to this proposal, just if someone wants to check those pages fast. Feel free to add any one that I missed.
-**[[Super Smash Bros.]]
-**[[Super Smash Bros. Melee]]
-**[[Super Smash Bros. Brawl]] ([[:Category:Super Smash Bros. Brawl images|images]])
-**[[Super Smash Bros. for Nintendo 3DS / Wii U]] ('''gallery''') ([[:Category:Super Smash Bros. for Nintendo 3DS / Wii U images|images]])
-**[[Super Smash Bros. Ultimate]] ([[Talk:Super Smash Bros. Ultimate|talk]]) ([[:Category:Super Smash Bros. Ultimate images|images]])
-*In the Ultimate talk page is a discussion about the removal of the images of other characters, so it's worth checking. -[[User:Kirbeat|Kirbeat]] ([[User talk:Kirbeat|talk]]) 15:52, 2 November 2021 (UTC)
-*Here is my proposed outline of what should be covered in each ''Smash'' page, taking inspiration of the current state of ''[[Super Smash Bros. Ultimate]]'':
+{{quote|Can you {{color|orange|master}} the {{color|blue|king}} of weapon-based Copy Abilities?|Sword Challenge Caption}}
-**'''Fighters''' - fighters *should* be listed because Kirby copies them, but without images, and in a collapsible table. ''Kirby'' series fighters get explanation of their movesets in separate sections;
+Pause descriptions in ''[[Kirby Super Star Ultra]]'' like [[Suplex]]:
-**'''Stages''' - much like the page right now, an overview of the number of available stages, and any relevant info that relates to the ''Kirby'' in general (such as the stage forms). Then a list of ''Kirby'' stages, and their music;
-**'''Items''' - similarly to the Stages, an overview, any relevant info, all ''Kirby'' items with info about them;
-**'''Game Modes''' - at least general information about them. Cutting some of them would make no sense for me as some modes such as Classic Mode have their variations per character, and they would they get listed while others would not? It would be misleading to the reader. So just listing all modes is fine, while detailing ''Kirby'' content of modes as needed;
-**'''Trivia/Gallery''' - as long as these are only about ''Kirby'' content it should be fine.
-*Again, just my two cents. I think a format like this strikes a good balance between the two worlds. {{User:Gigi/sig}} 16:09, 12 November 2021 (UTC)
-=== Result ===
+''This {{Color|red|burns}} with {{Color|blue|fighting spirit}}! Grab {{color|red|foes}} and {{color|blue|throw}} 'em! Learn all 8 {{color|blue|throws}} to be a {{color|red|champ}}!''
-Option '''3''' is the winner, with four votes. Option 2 comes in second, with three votes.
-{{clear}}
+Just to name a few. So, personally, we should just get rid of links in any text like that to prevent confusion. And last but not least, another reason I don't like links in text like this is how they often use piped links. Take this one about Kracko as an example:
-==Overhaul Template:Aboutfile 101621-103021==
+{{Quote|[[Kirby|YOU...!]] Did you think I'd forget? The [[Kirby's Adventure|time]] you smashed into me with your [[Hi-Jump]]! That [[Kirby Super Star|time]] I was betrayed by [[Helper]]s! Or [[Kirby: Squeak Squad|when]] I was replaced by that [[Mecha-Kracko|mechanical cloud]]! I-I... Sniff... there's something in my eye...|'''VS Kracko''' (Very Hard) Pause Screen description in the American English version of ''[[Kirby Fighters Deluxe]]''}}
-I've come to make an announcement in regards to the project that I am leading regarding adding Template:Aboutfile to every image that lacks it currently. In short, I want to make changes to the currently existing template to be more like the Template:File on Wars Wiki and StrategyWiki ([https://warswiki.org/wiki/Template:File see here]).
-Simply put, I think that this template is not only objectively better but also extremely easy to implement. Here is a list of reasons in a relative order of importance:
+It feels really unprofessional to add piped links to "YOU...!", "time" and "when", and the one for "mechanical cloud" like spoils what this is about. I dunno, I never liked it for this reason as well.
-*This would be a non-destructive change. This is only changing the components of Aboutfile, which means that that the old styling and the suggested new changes can be together without conflict. This is simply just trying to add to the existing template, not make a new one.
+To conclude all this, basically, to put it another way, my proposal is to disallow links in any text that is not authored by a wiki editor, so quotes (both from characters and developers), flavor text, official descriptions, translations of anything else that applies, and so on. Just how right now the [[WiKirby:Formatting specifics|formatting specifics]] says that links in section headers should be avoided, my proposal is to also write something like that in that page about quotes, flavor text etc. What do you all think? {{User:Gigi/sig}} 15:02, 16 November 2023 (UTC)
-*It's drastically easier for new users to use. People that don't have much experience uploading files will find exactly everything they need to enter directly where it needs to be, most likely without having to open up other pages or categories to see exactly what needs written for that file, and don't need to memorize certain aspects of uploading.
+{{Support}}
+#Agreed, I can definitely see how it can get confusing. {{User:Pinkyoshifan/sig}} 15:31, 16 November 2023 (UTC)
+#Yeah unless there would be a way to change the link color this should not be a thing. {{User:Basic Person/sig}} 22:03, 16 November 2023 (UTC)
+#Support. I agree it makes things confusing. I know some wikis do this (like Mario Wiki), but when we're using colored text it adds ambiguity, so it should really only be one or the other, and I prefer having the colored text. [[User:StarPunch|StarPunch]] ([[User talk:StarPunch|talk]]) 23:12, 16 November 2023 (UTC)
+#Agreed. It'll be much less confusing like this, and we can just put the necessary links in the page's main text. {{User:DeepFriedCabbage/sig}} 07:22, 19 November 2023 (UTC)
+#Though I am a bit torn on this one, I think it’s probably a better idea to get rid of them to reduce ambiguity. If context is really necessary, we have footnotes for that, and most of these links are pretty unnecessary. -{{User:YoshiFlutterJump/sig}} 20:44, 19 November 2023 (UTC)
+#I was feeling pretty neutral on this but the flavour text examples make the potential for confusion extremely clear. If something needs a contextual clue either footnotes or even {{explain|a template that adds hover text and less intrusive formatting|{{T|explain}}}} might be better suited. {{User:WillIdleAway/sig}} 00:07, 20 November 2023 (UTC)
+#The examples listed above are pretty self-explanatory as to how confusing things will be if the possibility for linking within such quotes sticks around. I don't think there's much else for me to say that hasn't already been said, so...Per all. &ndash; [[User:Owencrazyboy17|Owencrazyboy17]] ([[User talk:Owencrazyboy17|talk]]) 02:13, 24 November 2023 (UTC)
+#Nothing much to add, I agree that due to blue colored text existing in some games and the possibility that readers think emphasis is placed on the words with links, even if it isn't, are good reasons to disallow them going forward. [[User:Infinite Possibilities|Infinite Possibilities]] ([[User talk:Infinite Possibilities|talk]]) 17:44, 30 November 2023 (UTC)
+{{Oppose}}
+#First off, we have a policy on spoilers: spoil them. The games are the place for plot twists, not the wiki, which is for the facts. Second, while I do think the colors themselves get confusing, I think the only ways to keep the links (important for context) would be very clunky, and that just won't do. Piped links also literally just boil down to how you feel about them as opposed to whether they're helpful or not, which I think most are. [[User:Waddlez3121|Waddlez3121]] ([[User talk:Waddlez3121|talk]]) 23:08, 19 November 2023 (UTC)
-*It's drastically easier for you, yes YOU to use. The primary benefit to Wars' Template:File is that a lot of components don't need to be manually written. If a game is entered into the |game= slot, the game not only has a link to it, but is automatically categorized for that game. Wars' |type= section not only categorizes the file to the "type" conditional's category (like Category:Screenshots) but also automatically generates the file license which means...
+{{Neutral}}
+#Hm...not too sure about this one. On one hand, it does make the colored text subject less confusing, but on the other hand, the links ''would'' help some people understand the context of certain quotes... --[[User:Paistrie|Paistrie]] ([[User talk:Paistrie|talk]]) 15:59, 16 November 2023 (UTC)
+#I agree with Paistrie. For a person who doesn't have as much knowledge on the series, the links could help them out. But for us/people with more knowledge on the series, it might feel like a visual nuisance. (Though I use a custom theme for Wikirby, so it shows up as black and not blue, therefore this doesn't affect me.) {{User:Starvoid/sig}} 18:55, 18 November 2023 (UTC)
+===Discussion===
+Just a couple things I noted on Discord that may help clarify why I also suggested this proposal:
-*No more licensing templates needed. Everything will automatically be fed through the template and generate exactly what is needed! No need to write out categories or licenses. This is a fantastic way to reduce potential errors, as typos can always exist on the categorization meaning people looking for images cannot find them as easily.
+*Most of the time I see links in descriptions or quotes they are repeat links or subjects linked can be linked in article text. Basically, they are almost never needed
+*In a way adding links and stuff (basically editing a text you didn't write) always felt to me like we are editing something we didn't make, which for me is wrong. That's why often if someone quotes someone and for example bolds the text, something like "emphasis mine" is added to clarify their edits to the original text
-*Sourcing becomes a lot better managed. Currently for Wars, if a section is left blank, the file will automatically be added to a category for unsourced files. What could occur is the current file needs sourcing template is integrated into the new Aboutfile template so that there is a bright, contrasting warning inside the box indicating the file has no source and one needs located. This can be taken a step further by having a second warning specifically for any files sourced through Kirby FANDOM or FANDOM overall.
+So, basically, I don't see why these links are needed, and they do more harm than good. {{User:Gigi/sig}} 17:00, 16 November 2023 (UTC)
+:I understand what you mean here, but I still think that the links are helpful for context. When I first started reading article pages on this wiki, some of the links did help me understand what some characters meant (the "mechanical" in that Kracko quote for example). However, of course, I can only speak for myself here. Maybe, if possible, the links could be recolored? (If that's impossible, then the links could be deleted.) --[[User:Paistrie|Paistrie]] ([[User talk:Paistrie|talk]]) 20:25, 16 November 2023 (UTC)
+::The links can be recolored like [[Kirby|{{Color|#000000|this}}]] (also most custom signatures do this, including my own), but having black links seems like it would be confusing and any color besides black would cause the same issues being brought up here. {{User:Pinkyoshifan/sig}} 02:41, 17 November 2023 (UTC)
-*Finding errors and improvements when changing the template. I have seen a significant as in over 200 files that need image-quality templates, header fixes, or other types of fixes while compiling the list. This is a fantastic way to address these types of problems when making changes to files anyway.
+==Abolish Proposal Rule 8 (16 November 2023 – 30 November 2023)==
+I know, I know. "Isn't that just one free support vote for every single proposal?" Hear me out.
-*Saves space on new uploads. This is pretty minor. But it's cool and notable.
+First off, many proposals aren't as simple as yes or no. Sometimes there are multiple options, and the original proposer may not like one but include it anyway as a courtesy. Alternatively, a person may wish to make a proposal to settle a controversy, and he or she may still prefer to do nothing. In any case, I think there are sufficient reasons not to rule the proposer unable to vote at all, especially since, in many cases, the proposer is the one with the strongest opinions on the topic.
-The only current either downside or hinderances in my way for fully integrating this today right now are the following: Your collective support for the idea, making the template still look as pretty as it does now, and how exactly we would approach other media like the anime or books or something. I would personally suggest just dropping it in |game= but there might be a few lingustic rivals amongst us that disagree with using game for not-games.
+Of course, I'll leave that decision up to you all. -{{User:YoshiFlutterJump/sig}} 07:04, 16 November 2023 (UTC)
-TL;DR:
+EDIT: I have added a new option per the comments in Neutral. Though I still support the complete abolition of the rule, as I feel the proposer's opinion should still count for something (and as said before, there are reasons one might choose to oppose or remain neutral on one's own proposal), it's certainly a preferable option to the status quo. -{{User:YoshiFlutterJump/sig}} 21:25, 16 November 2023 (UTC)
-*Aboutfile is converted to include the automatics involved in Wars Wiki's Template:File through additional parameters.
-*Template:File source is converted to File source link (or something similar) to specifically notate files that have a written source, but no link to it (such as many of RMV's uploads). File source needed and Not-using-FANDOM conditionals are built into Aboutfile.
-*Trig posts his big freaky list and people start chipping away at it.
-:::::--[[User:Trig Jegman|Trig Jegman]] - 03:05, 16 October 2021 (UTC)
+{{Option|1|Complete abolition}}
+#Even outside of the multiple options scenario, I think the vote of whoever propeses should also count for something outside of presenting the idea, so support. {{User:ShadowKirby/sig}} 07:23, 16 November 2023 (UTC)
-For an example of a file change, please click "Expand" on the right.
+#I don't really see what the problem is with it being a free support vote - the opinion of the person who happened to be the one to make the proposal should be just as valid as everyone else's. [[User:Hewer|Hewer]] ([[User talk:Hewer|talk]] &middot; [[Special:Contributions/Hewer|contributions]]) 18:10, 18 November 2023 (UTC)<!--
-<div class="mw-collapsible mw-collapsed" style="width:98%; overflow:auto;">
+--><br><s>#Agreed, the proposer being barred from voting doesn't really work for multiple-option votes. {{User:Pinkyoshifan/sig}} 13:46, 16 November 2023 (UTC)</s>
-Consult [[:File:KMA Tortletummy Thorn sprite.png]]
-<pre><nowiki>
-== Summary ==
-{{aboutfile
-|description=In-game sprite of [[Tortletummy Thorn]] from ''[[Kirby Mass Attack]]''
-|game=''[[Kirby Mass Attack]]''
-|source=[https://www.spriters-resource.com/ds_dsi/kirbymassattack/sheet/8487/ Spriters Resource]
-}}
-== License ==
+{{Option|2|Narrow scope of rule to two-option proposals only}}
-{{Game sprite}}
+#Per reasons for voting for option 1 before this one was added, the main concern is multiple-option votes. {{User:Pinkyoshifan/sig}} 21:58, 16 November 2023 (UTC)
-[[Category:Kirby Mass Attack images]]
+#Changing my vote to this, for the reasons I wrote in my original vote for neutral. {{User:Gigi/sig}} 17:04, 22 November 2023 (UTC)
-[[Category:Sprites]]
+#Voting this based on my inital vote for neutral before this option was added. [[User:Infinite Possibilities|Infinite Possibilities]] ([[User talk:Infinite Possibilities|talk]]) 17:49, 30 November 2023 (UTC)
-</pre>
+{{Option|3|Leave as-is}}
-would move to
-<pre>
-==Summary==
-{{aboutfile
-|description=In-game sprite of [[Tortletummy Thorn]] from ''[[Kirby Mass Attack]]''
-|game=Kirby Mass Attack
-|type=sprite
-|source=[https://www.spriters-resource.com/ds_dsi/kirbymassattack/sheet/8487/ Spriters Resource]
-}}
-</nowiki></pre>
-in order to provide the same exact results.
-</div>
-<br/>
-{{Support}}
-#Sounds good to me. Any changes that make the process of proper file uploading easier for new users in particular gets a thumbs up from me. --[[User:Samwell|Samwell]] ([[User talk:Samwell|talk]]) 03:07, 16 October 2021 (UTC)
-#Complete support. This is very beneficial, and what catches my eye more is both the auto placement of unsourced files and, on top of everything, the auto Categorization in general. -[[User:Kirbeat|Kirbeat]] ([[User talk:Kirbeat|talk]]) 04:35, 16 October 2021 (UTC)
-#Simpler is better, especially for new users. {{User:Pinkyoshifan/sig}} 10:59, 16 October 2021 (UTC)
-#Not having to manually add game categories and license types is a good idea. {{User:Kirb/sig}} 18:12, 25 October 2021 (UTC)
-{{Oppose}}
 {{Neutral}}
+<s>#I feel it should be fine but only on multi-choice proposals. For proposals like this one, where it's just support, oppose, neutral, allowing the person who posted the proposal to vote will basically mean a free support vote for it. For multi-choice, I can see the point since the person who wrote the proposal will have one prefence among many others. So, personally, if this passes, I would prefer that it would with that note. {{User:Gigi/sig}} 13:59, 16 November 2023 (UTC)</s>
+<br><s>#I pretty much agree with what Gigi wrote above. While the argument of "it's just a free support vote" doesn't apply to multi-choice proposals, I do feel like keeping the rule for yes or no proposals only would make for a better change. [[User:Infinite Possibilities|Infinite Possibilities]] ([[User talk:Infinite Possibilities|talk]]) 15:47, 16 November 2023 (UTC)</s>
+#I also agree on making it "allow the creator to support their preferred choice on multiple-choice proposals" (which I think is standard policy for most other wikis) rather than getting rid of the rule entirely, since we would want to avoid it just being a free vote on "yes or no" proposals. [[User:StarPunch|StarPunch]] ([[User talk:StarPunch|talk]]) 23:12, 16 November 2023 (UTC)
 ===Discussion===
-====Vipz====
-A couple of issues I'm foreseeing:
-*Automization with "|game=Kirby's Game" doing <code><nowiki>''[[Kirby's Game]]'' [[Category:Kirby's Game images]]</nowiki></code> will work only for games, so aside from linguistics, this is why I think "|media=" should be a separate field. Not all media will have pages and categories (that work the same way).
-*Pipe links are impossible.
-*When an image comes from multiple games (e.g. KNiDL, KaTAM and KSqS) - although additional categories can be added manually.
-*License parameters (e.g. <nowiki>{{Game screenshot|official}}</nowiki>) and multiple licenses (e.g. {{t|WikimediaImage}} + {{t|PD}}).
-There might be more, so clean automization is hard, unless we introduce more parameters. {{User:Vipz/sig}} 11:58, 16 October 2021 (UTC)
-::Back from my trip. I agree that perhaps having a secondary |media= that does not cause an automatic link may be useful, but would suggest we emphasize using |game= when most possible. Secondarily, I cannot necessarily think of an appropriate reason to have a piped link for a game title. Anything that is a deviation from a full game name seems like it would qualify as an inaccuracy. At the absolute worst, |media= would solve that. If an image comes from multiple games, I would suggest simply using |description= to list other included games and writing in more categories. I think that multi-game files would be exceedingly rare. Licensing parameters would be able to be changed to be their own separate variable switch. The way the template works is by using a different, all-encompassing switch template to change the file license instead of having several dozen templates so one parameter could just become |type=Screenshotofficial or something similar. As for multiple licenses, I do not forsee {{t|WikimediaImage}} being necessary if we are specifically listing the source out, though once again another parameter could be added for a Wikimedia+PD parameter if absolutely needed. [[User:Trig Jegman|Trig]] - 00:29, 18 October 2021 (UTC)
-====Template WIP====
-While not fully complete, [[User talk:Trig Jegman/Sandbox]] here is a rough draft of how the template will function including the requests made above/on Shiver Star. [[User:Trig Jegman|Trig]] - 21:07, 19 October 2021 (UTC)
-<br/>
-====Gigi====
-About licenses, are you proposing that [[:Category:Image templates|these]] [[:Category:Audio templates|templates]] are to be removed from all current files currently using it if this change rolls out in favor of a more general one for just "files" as shown in your sandbox? Because as of right now, there is a dropbox in the upload form for choose a template, and I'm wondering if that is supposed to eventually be gone too. I would just like to understand more and what kinda of backwards work would need to be done if this rolls out. {{User:Gigi/sig}} 01:12, 26 October 2021 (UTC)
-::Long story short, yes, the drop box would go. As [https://cdn.discordapp.com/attachments/821498111045271562/902366903211794432/file.png we have on StrategyWiki], the list of possible file types is up front and center first thing on the upload screen (although it could be prettier). These templates all roughly contain the same message only inter-changable by the type, which is being designated its own parameter as opposed to a template name. It is unlikely that a different license will need to be used for an overwhelming majority of images, and although yes ''technically'' possible to continue generating different licenses for different types, it does not do much except waste space. I would intend to look at fixing every file anyway, due to the amount of sourcing and quality flagging that can be addressed (hundreds to thousand files probably need some form of extra management). [[User:Trig Jegman|Trig]] - 01:48, 26 October 2021 (UTC)
-==Favor adapted Japanese names and terms over literal translations whenever possible (July 28th - August 11th)==
-Currently, the [[WiKirby:Naming policy|naming policy]] says the following when it comes to Japanese names:
-*Any non-English official name, following the three above priorities as with English names. '''Translated Japanese names take priority here'''.
+==Change voting rules for multi-option votes (16 November 2023 – 23 November 2023)==
+Our proposal header warns of the infamous spoiler effect. I think we can do better than that.
-The part I bolded is what I want to specify better. My proposal is to change that point to the following:
+For the uninformed: the spoiler effect occurs when, in a three-option proposal, Option A and Option B both score 30 % of the vote while Option C scores 40 %. Option C wins a plurality, but if Options A and B are similar, this means that the majority opposed Option C and it still won out. It's a strong weakness of plurality voting and encourages strategic voting (voting for a less-preferred option in order to prevent the least-preferred option from winning). What can we do about it? Here are our options:
-*Any non-English official name, following the three above priorities as with English names. '''Translated Japanese names take priority here, using adapted names and terms whenever possible'''.
+'''Instant runoff voting''': The best solution, in my opinion. Sometimes called "ranked choice voting", it essentially allows you to give differently-weighted votes to different options. I'll give you an example right now: this is my first choice, "multi-option voting" is my second choice and "plurality voting" is my third. If "instant runoff voting" has the least first-choice votes, my vote doesn't lose significance; it instead moves to "multi-option voting", my second choice. This single-elimination process continues until one option remains. ''Note'': Neutral voters would not be allowed to vote on any other option, unless they remove their "neutral" votes.
-In short, when we use Japanese names, we should try to use officially localized names and terms whenever possible, to make the names as close to English as possible, and to avoid inconsistencies. Here are some examples to illustrate:
+'''Multi-option voting''': Didn't understand the last option? This might be simpler. You can cast a vote on all options minus one, if you so choose. These votes would all be equally weighted. This is the system preferred on some other NIWA wikis, such as the Super Mario Wiki, to give you an idea. ''Note'': Just as in the above option, neutral voters may not vote for any other option.
-*[[Four-Headed Guardian Angel: Landia]]: the Japanese title '''4つ首の守り神：ランディア''' directly translates to ''Four-Headed Guardian Deity: Landia''. However, '''守り神''' has been localized in the games as "Guardian Angel", so we instead use that term for the page.
+'''Plurality voting''': Self-explanatory: do nothing and leave the voting system as-is.
-*[[Air Ride: Sky Sands]]: the Japanese title '''エアライド:サンドーラ''' directly translates to ''Air Ride: Sandoola''. However, "Sandoola" is the Japanese name for "Sky Sands", so instead we use that name for the page.
-*[[True Arena Showdown]]: the Japanese title '''真 コロシアムの戦い''' directly translates to ''True Colosseum Battle''. '''コロシアムの戦い''' is the Japanese name of [[Arena Showdown]], that has an official English name. '''真 コロシアムの戦い''' is basically "真" plus '''コロシアムの戦い''', and "真" is the prefix added to "The Arena" to make it "The True Arena" in Japanese. So, it's safe to do something similar in English. "True" plus "Arena Showdown", resulting in "True Arena Showdown".
-Of course, by allowing this, these names aren't translated names anymore, but instead derived, so marking them with the [[Template:ForeignTitle]] makes it misleading. So I also propose the creation of a "Derived from Japanese" template, to mark articles with names that aren't direct translations, but rather use the Japanese name as a guide of sorts for the article's title. These would still put pages in the [[:Category:Articles with titles from non-English languages]] regardless, as the source of the name is Japanese. Finally, while it could be argued that these titles could end up being speculative, I believe that as long as there are basis to go with (such as in the examples I gave), adapting names like that should be fine. And, of course, if there is ever diverging opinions about what to name a page, that could be discussed on its talk page.
+So what'll it be? My preferred option is instant runoff voting, but that's for you all to decide. -{{User:YoshiFlutterJump/sig}} 07:04, 16 November 2023 (UTC)
-Thoughts? {{User:Gigi/sig}} 00:55, 28 July 2021 (UTC)
+EDIT: Important clarification: this proposal would only take effect for proposals following its passage. It does not affect proposals currently ongoing. Also, check out Wikipedia's [https://commons.m.wikimedia.org/wiki/File:IRV_counting_flowchart.svg#mw-jump-to-license useful flow chart] illustrating instant runoff voting, and [[User:YoshiFlutterJump/Instant Runoff Voting Example|this example]] I made of how it would work in practice. -{{User:YoshiFlutterJump/sig}} 01:41, 18 November 2023 (UTC)
-{{Support}}
-#I'm in support of this: I realize we don't have a consistent solution for this, so it'd be best to stick with the direction we're already going and make it formal. I think that'd also mean articles like ''[[Hoshi no Kirby Yume no Izumi no Monogatari (soundtrack)]]'' and ''[[Hoshi no Kirby 64 Original Soundtrack]]'' would have to be moved, but I'm fine with that. (I assume ''[[Kirby Wii Music Selection]]'' would stay the same since it's already in English? I suppose we can discuss that later...) [[User:StrawberryChan|StrawberryChan]] ([[User talk:StrawberryChan|talk]]) 01:07, 28 July 2021 (UTC)
-#Gigi and I spent a lot of ASCII hammering out the finer details of this idea, and I am pleased with the result, so I support. --[[User:Samwell|Samwell]] ([[User talk:Samwell|talk]]) 01:08, 28 July 2021 (UTC)
-#Direct translations, while technically more true to the source material, can be flawed, misleading, or contradicting localization sometimes and can require interpretation, which is what this proposal aims to allow (if I'm understanding it correctly). Support. {{User:Pinkyoshifan/sig}} 16:13, 28 July 2021 (UTC)
-#Another example I can thing of is [[Big Metalun]], and since we had an IP user got confused by this recently, it should definitely be clarified. {{User:Superbound/sig}} 21:46, 2 August 2021 (UTC)
-#Definitely seems like a good idea. This should lessen confusion and having a solid solution for going about Japanese names will be good, as said by the other supporters. -- {{User:MetaDragon/sig}} 02:26, 3 August 2021 (UTC)
-{{Oppose}}
-{{Neutral}}
-===Discussion===
+{{Option|1|Instant runoff (ranked choice) voting}}
-To answer StrawberryChan, this would only apply to names written in Japanese, so ''[[Kirby Wii Music Selection]]'' wouldn't need to be moved since it's written in English. As for ''[[Hoshi no Kirby Yume no Izumi no Monogatari (soundtrack)|Hoshi no Kirby Yume no Izumi no Monogatari]]'' and ''[[Hoshi no Kirby 64 Original Soundtrack]]'' we could discuss them further later. I wouldn't be against making an exception for album titles since they aren't often translated and aren't many articles anyway. {{User:Gigi/sig}} 01:22, 28 July 2021 (UTC)
+#It took a bit to grasp, but it seems right to count a vote towards something else if another one fails. Would note that one should be able to choose to vote for one option and one option only if they so choose. This option seems to prevent proposals from getting stale due to having more popular options unresolved. Not entirely sure how it'd work in practice but in theory I like this. {{User:ShadowKirby/sig}} 07:23, 16 November 2023 (UTC)
+#If I'm understanding this correctly then it does seem like the best option. {{User:Pinkyoshifan/sig}} 13:46, 16 November 2023 (UTC)
+#Certainly agree about the whole thing about multi-choice proposals. I've often come across times where I notice many people don't want a certain choice to win but then split on voting on two or more options, then the option with most rejection wins still. This would be my preferred method to counter that. I just wonder how to format the voting, but I suppose people can just comment on each option and go "this is my first choice", "this is my second choice" etc. {{User:Gigi/sig}} 13:59, 16 November 2023 (UTC)
+#Using a system that discourages strategic voting seems like a good idea. I support it. [[User:Typman|Typman]] ([[User talk:Typman|talk]]) 18:17, 16 November 2023 (UTC)
+#We already do this for referendums so I don't see why not for regular proposals. {{User:Basic Person/sig}} 22:03, 16 November 2023 (UTC)
+#Yes, I agree on this, since this is close to how referendums work on the wiki already. It would definitely help avoid situations where a less-popular choice wins because the vote is split between two opposing options. [[User:StarPunch|StarPunch]] ([[User talk:StarPunch|talk]]) 23:12, 16 November 2023 (UTC)
+#This feels like the better option. If your first choice doesn't work, it goes toward your second, then third, etc. That way your opinions aren't held to strategy, but preferences. {{User:Starvoid/sig}} 19:10, 18 November 2023 (UTC)
-{{clear}}
+{{Option|2|Multi-option voting}}
-==Overhaul to writing standards regarding humor (July 5th, 2021 - July 19th, 2021)==
+{{Option|3|Plurality voting (leave as-is)}}
-Hey, everyone. It's come to attention recently that the [[WiKirby:Writing style|writing standards]] may be a bit too lenient in allowing for non-encyclopedic jokes in articles. While it's important that WiKirby doesn't take itself too seriously, it's also important that it doesn't become overridden with writers focusing on comedy over quality. The important bits from the previously linked article and the [[WiKirby:Writing specifics|writing specifics]] are outlined below:
-*''WiKirby serves to display a certain sense of whimsy and humor when describing subjects. However, WiKirby does not intend to have subjective opinions on these subjects which may color the reader's judgments, especially if those opinions are comparison-based.''
-*''WiKirby likes a bit of joviality, especially when it comes to clever use of wording and creative ways to spell out summaries. However, humor should not take precedence over the essential information of the article. Generally speaking, jokes should be confined to captions for images that do not require an explanation, if they appear in article text at all.''
-It should be emphasized that WiKirby focuses on information first, and this is outlined in both of these statements. They are otherwise rather vague, however, which can lead to some misunderstanding regarding what kind of humor is appropriate and inappropriate for each article. The general idea is that overt jokes should not be allowed in articles—the comedy generally comes from a sense of tongue-in-cheek humor, describing a fanciful series in a serious and practical manner. In other words, a more casual manner of describing information than most wikis is fine for our tastes, but not to a point where it becomes unprofessional. The above statements could be rewritten as such to reflect this:
-*''WiKirby has a casual style of writing that suits the whimsical nature of the ''Kirby'' series. However, WiKirby does not intend to have subjective opinions on these subjects which may color the reader's judgments, especially if those opinions are comparison-based.''
-*''WiKirby aims to be informative, but also to avoid being dry and authoritative. A matter-of-fact tone is encouraged; a sense of wit is also welcome, but should not take precedence over the essential information of an article. This includes things that are otherwise self-evident, such as image captions. We're not looking to make the reader laugh.''
-This has been discussed on the Discord server already, but further discussion can take place here, as well. What are your thoughts? [[User:StrawberryChan|StrawberryChan]] ([[User talk:StrawberryChan|talk]]) 00:26, 5 July 2021 (UTC)
-{{Support}}
-#I support this clarification. Should hopefully cut down on any confusion about what is and is not allowed in article text. --[[User:Samwell|Samwell]] ([[User talk:Samwell|talk]]) 00:32, 5 July 2021 (UTC)
-#Support because I agree that clarification is needed, and we shouldn't be making image captions with humor as the main goal. {{User:Gigi/sig}} 00:44, 5 July 2021 (UTC)
-#Humor is a good side effect, but yeah, this should be clarified to note that the main intent shouldn't be jokes. {{User:Pinkyoshifan/sig}} 01:08, 5 July 2021 (UTC)
-#Sounds like a good idea to me. Clarification on this would be nice and would make things less confusing. -- {{User:MetaDragon/sig}} 05:30, 5 July 2021 (UTC)
-#These two guidelines have confused me since I joined, so making them less confusing would be nice. [[User:Hewer|Hewer]] ([[User talk:Hewer|talk]] &middot; [[Special:Contributions/Hewer|contributions]]) 14:22, 6 July 2021 (UTC)
-#Being more clear is always nice. {{User:Superbound/sig}} 14:47, 6 July 2021 (UTC)
-{{Oppose}}
 {{Neutral}}
-#Personally I wouldn't mind non-encyclopedic jokes on image captions but I guess it would be better not to have them.{{User:Kirb/sig}} 14:40, 6 July 2021 (UTC)
 ===Discussion===
+@ShadowKirby: I should clarify that this would not preclude the option to cast only one vote. The effect of this is that, if a user votes for only one option and that option loses, the vote has no bearing on the standing of the other options, which is the same as in the status quo. It's effectively equivalent to a last-choice vote. (Should also note: one would not be able to make two first choices, or the like; ranking should occur linearly or else options not preferred should be excluded.) -{{User:YoshiFlutterJump/sig}} 07:40, 16 November 2023 (UTC)
+:Sounds perfect :) {{User:ShadowKirby/sig}} 07:42, 16 November 2023 (UTC)
+Regarding Basic Person's comment: This isn't the exact system used by referendums. Referendums so far have used [[wikipedia:borda count|borda count]] voting, option 1 is [[wikipedia:instant-runoff voting|instant-runoff voting]]. {{User:Pinkyoshifan/sig}} 23:19, 16 November 2023 (UTC)
+:To add on to this: the fundamental difference between instant-runoff and borda count is the weight of second-choice votes. In borda count, all votes cast are weighted depending on whether it is first, second, third choice and so on. In instant-runoff, second-choice votes have no weight (except for tiebreakers) unless that user's first-choice vote fails. Instant-runoff essentially emulates the proposal having multiple rounds, with one option eliminated each time. The question becomes, "if this option were eliminated, what would I choose next?"; the answer is, naturally, your second-choice vote. -{{User:YoshiFlutterJump/sig}} 23:42, 16 November 2023 (UTC)
-{{clear}}
+==Kirby 64 Element Table (2023-08-23 - 2023-09-06)==
+So, I think the existing Kirby 64 Copy Ability navigation is really, really... difficult. At least for me, the current set-up is very hard to read and I think it would help to use a more accessible, easy to understand template. Hmm. If only there was a convenient form of template to document every possible combination of something with two variables! <small>Wait...</small>
-==Allow Autopatrol users to mark files as Good (July 1st, 2021 - July 15th, 2021)==
+You'll see on [[https://drive.google.com/file/d/1dv4M1qVVCPilgEEw79xCmehabnp3ONa3/view?usp=sharing|this Google Drive link]] (ZIP archive containing PNG, PDN, TXT, and HTML files) that I have made a table template that is very incomplete, but what is there is a much more approachable interface. It is a table with a top row and left column showing each base Copy Ability as an icon (that links to the ability's page, of course) and in the space of the rest of the table are links to each [[Power Combo]]. I'm kinda proud of it despite it being a basic HTML thing. Can we implement something like this on the wiki? [[User:Waddlez3121|Waddlez3121]] ([[User talk:Waddlez3121|talk]]) 03:48, 24 August 2023 (UTC)
-Greetings. It has come to my attention that a lot of file uploading has been undertaken by some of our more active users in Autopatrol rank. Due to the sheer quantity of them, I think it is impractical for Patrollers+ to be chasing all these files and marking them as Good, especially since the users in question uploading the files have already taken care to ensure they meet the qualifications. As such I propose that Autopatrol users be allowed to mark these files Good themselves. Note that this does '''not''' extend to articles, as those are subject to a stricter standard and ideally should still be looked over by a Patroller+. What do you all say? --[[User:Samwell|Samwell]] ([[User talk:Samwell|talk]]) 18:58, 1 July 2021 (UTC)
 {{Support}}
-#I was thinking of proposing the same but also including articles, although now that you point it out, I agree that files in particular are less of an issue, plus there are way more of them. So, since Autopatrol users are trusted and manually selected for the rank, I don't see why not. {{User:Gigi/sig}} 19:07, 1 July 2021 (UTC)
+#Although I'm fine with the way the Power Combos are set up on the main ''Kirby 64'' page, I think this would be useful as a navbox on the Power Combo pages. [[User:StarPunch|StarPunch]] ([[User talk:StarPunch|talk]]) 04:28, 24 August 2023 (UTC)
-#Autopatrol users have already demonstrated that they can be trusted, and trusting them with marking files as Good seems like it makes sense, especially since some users mark things as Good, only to have the edit undone since they aren't wiki staff. {{User:Pinkyoshifan/sig}} 20:19, 1 July 2021 (UTC)
+#This seems pretty easy to implement and I could see it put on the bottom of each Power Combo page. While I don't tend to look at ''Kirby 64'' stuff, easier accessibility is always good. {{User:GoldenDragonLeaf/sig}} 04:39, 24 August 2023 (UTC)
-#I don't see why not. As said by Gigi and PYF, autopatrol users are trusted users who deserve to at least mark files as Good and giving them this permission would make things much easier, but I agree that marking articles as Good be left up to Patrollers+, especially because doing otherwise would leave Patrollers with little to no special permissions in their rank. :P -- {{User:MetaDragon/sig}} 06:07, 4 July 2021 (UTC)
+#This is a great idea! We've got some clickable navboxes like this on lots of other pages, and this would work perfectly too. {{User:DeepFriedCabbage/sig}} 05:59, 24 August 2023 (UTC)
-#Yes, this is a good idea. Uploading images is something that the wiki needs a lot of, and something new users are often willing to do.{{User:Kirb/sig}} 14:37, 6 July 2021 (UTC)
+#I think this kind of table would be very helpful as a navbox. It's simple and to the point. Regarding opposing concerns, I prefer a table with repeats over the same exact table without any. If ut looks too simple, the cells of the table could be coloured in. I still prefer a table over a navmap since those don't cope well with mobile. {{User:ShadowKirby/sig}} 11:08, 24 August 2023 (UTC)
+#While I think either design could be good, I do prefer the new design that was brought up after the proposal. {{User:Pinkyoshifan/sig}} 11:52, 6 September 2023 (UTC)
 {{Oppose}}
+#I'm going to elaborate on the discussion later, but on the current format of the table I will have to oppose. While I like this idea at core, I think we need to discuss this more and even decide first if we want a table in the page, or a navbox, or both, as they are coded differently. In particular, I'm not sure how to format this as a navbox. And for a table, I'm concerned due to the lack of any text, and also due to repeats the most. This currently doesn't look up to the wiki's standards. {{User:Gigi/sig}} 10:29, 24 August 2023 (UTC)
 {{Neutral}}
 ===Discussion===
+For ease of access, I've also recreated the table in wikicode. [[User:StarPunch|StarPunch]] ([[User talk:StarPunch|talk]]) 04:28, 24 August 2023 (UTC)
+{| class="wikitable mw-collapsible mw-collapsed" style="margin: 0 auto;" border=1 cellpadding=2
+!colspan=8|Power Combos in ''Kirby 64: The Crystal Shards'' &nbsp;
+|-
+! !! [[File:K64 Base Burn.png|link=[[Burning]]]] !! [[File:K64 Base Stone.png|link=[[Stone]]]] !! [[File:K64 Base Ice.png|link=[[Ice]]]] !! [[File:K64 Base Needle.png|link=[[Needle]]]] !! [[File:K64 Base Bomb.png|link=[[Bomb]]]] !! [[File:K64 Base Spark.png|link=[[Spark]]]] !! [[File:K64 Base Cutter.png|link=[[Cutter]]]]
+|-
+![[File:K64 Base Burn.png|link=[[Burning]]]]
+|[[File:K64 PC DoubleBurn.png|link=[[Burn-Burn]]]] || [[File:K64 PC BurnStone.png|link=[[Burning Stone]]]] || [[File:K64 PC BurnIce.png|link=[[Burn-Ice]]]] || [[File:K64 PC BurnNeedle.png|link=[[Burn-Needle]]]] || [[File:K64 PC BurnBomb.png|link=[[Burn-Bomb]]]] || [[File:K64 PC BurnSpark.png|link=[[Burn-Spark]]]] || [[File:K64 PC BurnCutter.png|link=[[Burn-Cutter]]]]
+|-
+![[File:K64 Base Stone.png|link=[[Stone]]]]
+|[[File:K64 PC BurnStone.png|link=[[Burn-Stone]]]] || [[File:K64 PC DoubleStone.png|link=[[Stone-Stone]]]] || [[File:K64 PC StoneIce.png|link=[[Stone-Ice]]]] || [[File:K64 PC StoneNeedle.png|link=[[Stone-Needle]]]] || [[File:K64 PC StoneBomb.png|link=[[Stone-Bomb]]]] || [[File:K64 PC StoneSpark.png|link=[[Stone-Spark]]]] || [[File:K64 PC StoneCutter.png|link=[[Stone-Cutter]]]]
+|-
+![[File:K64 Base Ice.png|link=[[Ice]]]]
+|[[File:K64 PC BurnIce.png|link=[[Burn-Ice]]]] || [[File:K64 PC StoneIce.png|link=[[Stone-Ice]]]] || [[File:K64 PC DoubleIce.png|link=[[Ice-Ice]]]] || [[File:K64 PC IceNeedle.png|link=[[Ice-Needle]]]] || [[File:K64 PC IceBomb.png|link=[[Ice-Bomb]]]] || [[File:K64 PC IceSpark.png|link=[[Ice-Spark]]]] || [[File:K64 PC IceCutter.png|link=[[Ice-Cutter]]]]
+|-
+![[File:K64 Base Needle.png|link=[[Needle]]]]
+|[[File:K64 PC BurnNeedle.png|link=[[Burn-Needle]]]] || [[File:K64 PC StoneNeedle.png|link=[[Stone-Needle]]]] || [[File:K64 PC IceNeedle.png|link=[[Ice-Needle]]]] || [[File:K64 PC DoubleNeedle.png|link=[[Needle-Needle]]]] || [[File:K64 PC NeedleBomb.png|link=[[Needle-Bomb]]]] || [[File:K64 PC NeedleSpark.png|link=[[Needle-Spark]]]] || [[File:K64 PC NeedleCutter.png|link=[[Needle-Cutter]]]]
+|-
+![[File:K64 Base Bomb.png|link=[[Bomb]]]]
+|[[File:K64 PC BurnBomb.png|link=[[Burn-Bomb]]]] || [[File:K64 PC StoneBomb.png|link=[[Stone-Bomb]]]] || [[File:K64 PC IceBomb.png|link=[[Ice-Bomb]]]] || [[File:K64 PC NeedleBomb.png|link=[[Needle-Bomb]]]] || [[File:K64 PC DoubleBomb.png|link=[[Bomb-Bomb]]]] || [[File:K64 PC BombSpark.png|link=[[Bomb-Spark]]]] || [[File:K64 PC BombCutter.png|link=[[Bomb-Cutter]]]]
+|-
+![[File:K64 Base Spark.png|link=[[Spark]]]]
+|[[File:K64 PC BurnSpark.png|link=[[Burn-Spark]]]] || [[File:K64 PC StoneSpark.png|link=[[Stone-Spark]]]] || [[File:K64 PC IceSpark.png|link=[[Ice-Spark]]]] || [[File:K64 PC NeedleSpark.png|link=[[Needle-Spark]]]] || [[File:K64 PC BombSpark.png|link=[[Bomb-Spark]]]] || [[File:K64 PC DoubleSpark.png|link=[[Spark-Spark]]]] || [[File:K64 PC SparkCutter.png|link=[[Spark-Cutter]]]]
+|-
+![[File:K64 Base Cutter.png|link=[[Cutter]]]]
+|[[File:K64 PC BurnCutter.png|link=[[Burn-Cutter]]]] || [[File:K64 PC StoneCutter.png|link=[[Stone-Cutter]]]] || [[File:K64 PC IceCutter.png|link=[[Ice-Cutter]]]] || [[File:K64 PC NeedleCutter.png|link=[[Needle-Cutter]]]] || [[File:K64 PC BombCutter.png|link=[[Bomb-Cutter]]]] || [[File:K64 PC SparkCutter.png|link=[[Spark-Cutter]]]] || [[File:K64 PC DoubleCutter.png|link=[[Cutter-Cutter]]]]
+|}
+Is this proposal talking about the table on [[Kirby 64: The Crystal Shards#Power Combos]] or something to replace the power combos line on {{t|Navbox-K64}}? If it's the first one then I think it's better as-is, but if it's about the navbox then I agree that this is better (as long as it's only put on power combo pages). {{User:Pinkyoshifan/sig}} 12:59, 24 August 2023 (UTC)
 {{clear}}
+:Bump on the above. We really need to figure out what this proposal is about. {{User:Gigi/sig}} 11:44, 4 September 2023 (UTC)
-==Tweak various policies regarding files (May 14th, 2021 - May 27th, 2021)==
+Okay so I said I would comment better on my concerns with this table, and here it is.
-Something I've noticed every since I started editing here on WiKirby was how we had no written guidelines about various things about files. We have policies like [[WiKirby:Image standards]], [[WiKirby:Audio standards]], [[WiKirby:File use policy]], which are all great, but they don't cover everything about files. In fact, we have various unwritten rules already been enforced here that aren't written anywhere. I'm going to list all these and propose what to change to make them clearer.
-===No file redirects===
+First of all, it's currently unclear if this proposal is about the table in the ''Kirby 64'' page or a navbox or really anything else. It's not focused and is one of the main reasons I opposed and I still am opposed to it. I don't feel confortable supporting something that I'm not even sure what it is about.
-It is written nowhere in the pages [[Help:Redirects]] and [[WiKirby:Deletion policy]] that file redirects aren't allowed, and should be removed from pages and marked for deletion. It is not mentioned either in [[WiKirby:File use policy]]. [[Help:Moving pages]] is focused on pages, it encourages users to leave redirects, which could lead new users into thinking the same applies to files. In short, it's not mentioned anywhere.
-My idea is to mention in [[Help:Redirects]] that file redirects should not exist under any circumstance. [[WiKirby:Deletion policy]] should list file redirects as candidates for deletion. [[Help:Moving pages]] should have a section explaining that an editor not on Autopatrol+ should, after moving a file, change all uses of the file to the new name and mark the file redirect for deletion. Users on Autopatrol+ should move files without leaving a redirect.
+Second, this table says it will help with accessibility, but it does the opposite. It really only helps if you want to figure out what two ability combos make, and even then, you will have to click on the link to actually find out. This is due to the fact that it lacks any text and any images of the actual combos. If you are just looking for a specific combination, in particular one that you just remember the appearance or a more specific name (like Curling), you may take a long time to finally realize which place you need to click. As such, here is a solution to that problem (incomplete table, but it should illustrate what I mean):
-===Cropping transparent images and optimizing files===
+{| class="wikitable mw-collapsible mw-collapsed" style="margin: 0 auto;" border=1 cellpadding=2
-These two trends, mainly optimizing files, started with [[WiKirby:Project Clean-Up]]. I see them as productive, and I would like to have them listed as recommendations in some policy pages. I don't believe we need to enforce them formally, but saying that it is preferred to do so would be nice.
+!colspan=8|Power Combos in ''Kirby 64: The Crystal Shards'' &nbsp;
+|-
+! !! [[File:K64 Base Burn.png]]<br>[[Burning]] !! [[File:K64 Base Stone.png|link=[[Stone]]]] !! [[File:K64 Base Ice.png|link=[[Ice]]]] !! [[File:K64 Base Needle.png|link=[[Needle]]]] !! [[File:K64 Base Bomb.png|link=[[Bomb]]]] !! [[File:K64 Base Spark.png|link=[[Spark]]]] !! [[File:K64 Base Cutter.png|link=[[Cutter]]]]
+|-
+![[File:K64 Base Burn.png]]<br>[[Burning]]
+|[[File:K64 A DoubleBurn.png|75px]]<br>[[Burn-Burn]] || [[File:K64 PC BurnStone.png|link=[[Burning Stone]]]] || [[File:K64 PC BurnIce.png|link=[[Burn-Ice]]]] || [[File:K64 PC BurnNeedle.png|link=[[Burn-Needle]]]] || [[File:K64 PC BurnBomb.png|link=[[Burn-Bomb]]]] || [[File:K64 PC BurnSpark.png|link=[[Burn-Spark]]]] || [[File:K64 PC BurnCutter.png|link=[[Burn-Cutter]]]]
+|-
+![[File:K64 Base Stone.png|link=[[Stone]]]]
+|[[File:K64 PC BurnStone.png|link=[[Burn-Stone]]]] || [[File:K64 PC DoubleStone.png|link=[[Stone-Stone]]]] || [[File:K64 PC StoneIce.png|link=[[Stone-Ice]]]] || [[File:K64 PC StoneNeedle.png|link=[[Stone-Needle]]]] || [[File:K64 PC StoneBomb.png|link=[[Stone-Bomb]]]] || [[File:K64 PC StoneSpark.png|link=[[Stone-Spark]]]] || [[File:K64 PC StoneCutter.png|link=[[Stone-Cutter]]]]
+|-
+![[File:K64 Base Ice.png|link=[[Ice]]]]
+|[[File:K64 PC BurnIce.png|link=[[Burn-Ice]]]] || [[File:K64 PC StoneIce.png|link=[[Stone-Ice]]]] || [[File:K64 PC DoubleIce.png|link=[[Ice-Ice]]]] || [[File:K64 PC IceNeedle.png|link=[[Ice-Needle]]]] || [[File:K64 PC IceBomb.png|link=[[Ice-Bomb]]]] || [[File:K64 PC IceSpark.png|link=[[Ice-Spark]]]] || [[File:K64 PC IceCutter.png|link=[[Ice-Cutter]]]]
+|-
+![[File:K64 Base Needle.png|link=[[Needle]]]]
+|[[File:K64 PC BurnNeedle.png|link=[[Burn-Needle]]]] || [[File:K64 PC StoneNeedle.png|link=[[Stone-Needle]]]] || [[File:K64 PC IceNeedle.png|link=[[Ice-Needle]]]] || [[File:K64 PC DoubleNeedle.png|link=[[Needle-Needle]]]] || [[File:K64 PC NeedleBomb.png|link=[[Needle-Bomb]]]] || [[File:K64 PC NeedleSpark.png|link=[[Needle-Spark]]]] || [[File:K64 PC NeedleCutter.png|link=[[Needle-Cutter]]]]
+|-
+![[File:K64 Base Bomb.png|link=[[Bomb]]]]
+|[[File:K64 PC BurnBomb.png|link=[[Burn-Bomb]]]] || [[File:K64 PC StoneBomb.png|link=[[Stone-Bomb]]]] || [[File:K64 PC IceBomb.png|link=[[Ice-Bomb]]]] || [[File:K64 PC NeedleBomb.png|link=[[Needle-Bomb]]]] || [[File:K64 PC DoubleBomb.png|link=[[Bomb-Bomb]]]] || [[File:K64 PC BombSpark.png|link=[[Bomb-Spark]]]] || [[File:K64 PC BombCutter.png|link=[[Bomb-Cutter]]]]
+|-
+![[File:K64 Base Spark.png|link=[[Spark]]]]
+|[[File:K64 PC BurnSpark.png|link=[[Burn-Spark]]]] || [[File:K64 PC StoneSpark.png|link=[[Stone-Spark]]]] || [[File:K64 PC IceSpark.png|link=[[Ice-Spark]]]] || [[File:K64 PC NeedleSpark.png|link=[[Needle-Spark]]]] || [[File:K64 PC BombSpark.png|link=[[Bomb-Spark]]]] || [[File:K64 PC DoubleSpark.png|link=[[Spark-Spark]]]] || [[File:K64 PC SparkCutter.png|link=[[Spark-Cutter]]]]
+|-
+![[File:K64 Base Cutter.png|link=[[Cutter]]]]
+|[[File:K64 PC BurnCutter.png|link=[[Burn-Cutter]]]] || [[File:K64 PC StoneCutter.png|link=[[Stone-Cutter]]]] || [[File:K64 PC IceCutter.png|link=[[Ice-Cutter]]]] || [[File:K64 PC NeedleCutter.png|link=[[Needle-Cutter]]]] || [[File:K64 PC BombCutter.png|link=[[Bomb-Cutter]]]] || [[File:K64 PC SparkCutter.png|link=[[Spark-Cutter]]]] || [[File:K64 PC DoubleCutter.png|link=[[Cutter-Cutter]]]]
+|}
-Cropping transparent images basically means removing empty space from them. Many times files from official sites are transparent, but they have lots of empty space. The extra space makes the image appear smaller on the wiki, since it's accounting for all that empty space. My idea is to add a small note on [[WiKirby:Image standards]] to do that with any transparent image.
+This actually makes the table more readable, easier to navigate, and more up to the quality standards of the wiki.
-Optimizing files means running them through some image optimizer program to make them as small in file size as possible without losing quality. I would like to mention it also in [[WiKirby:Image standards]], with a note that it's optional, and an editor looking into optimize images needs to do it loselessly.
+However... [https://discord.com/channels/266426802321227778/927929804722946108/1092896960823971923 not much ago many editors seemed to agree that we weren't a fan of navmaps]. So making this a navmap feels a bit backwards to me. Or rather, I feel there is a larger discussion to have about navmaps before creating new ones. So, personally, I would hold off on this one.
-===File naming guidelines===
+So, I'm not opposed completely on making this some sort of navmap if we go with the variation I proposed, but even then I'm not a fan per the paragraph above. Otherwise I'm still opposed since we wouldn't be upholding WiKirby's current quality standards. {{User:Gigi/sig}} 12:01, 4 September 2023 (UTC)
-[[WiKirby:Naming policy]] right now only lists guidelines for naming pages, which makes sense. [[WiKirby:Image standards#Other image procedures and details]] has a general "give a good name to the file, or it will be moved or deleted". However I believe we need at least some basic rules so that we can consider a name file good enough, without small disagreements on if it could have a better name. Ever since [[WiKirby:Project Clean-Up]] started, different users have inforced different rules for naming. At core they all have the same principles, and so I'm going to list those here. My idea isn't to make very specific guidelines like the regular naming policy, but I believe we still need some small guidance. The basic rules I propose are:
+:The Burn-Burn image does make the table more bright (and less repetitive since rows and columns already include the ability combos), and text links work better on mobile, so the new table looks great. As far as navmaps are concerned, my main issue with them is how glitchy if not outright non-functional they are for some users, which this table isn't. {{User:ShadowKirby/sig}} 12:08, 4 September 2023 (UTC)
-*The file name must have the subject (eg. Kirby), the game or media it's from (eg. KSSU), and if it's an image the type of image (eg. Artwork). Order doesn't matter. So "Kirby KSSU Artwork", "KSSU Kirby Artwork", "KSSU Artwork Kirby" and "Kirby Artwork KSSU" are all acceptable;
+First of all, I want to say that, yeah, I think the screenshot-of-ability format is even better. That seems much better, and I definitely prefer it over my original draft (Thanks for making that in full, StarPunch!) Now, I'd like to try my best to address everything concisely as per what I said on Discord earlier this morning.
-**However, the beginning of the file name should give enough information about the file itself. In other words, the subject must be in the beginning of the file name if it's very long (this is specifically to prevent issues such as [[:Category:Kirby JP Twitter commemorative illustrations|this whole category]] page being impossible to navigate);
-**The game should use the abbreviation from [[WiKirby:Abbreviations]].
-*Proper nouns in the file name should be capitalized, other words are up to the file uploader;
-*No restrictions about using special characters, as long as the file name is readable, with the exception of periods, that should be avoided to not mess up with the definition of the file type. So no file names with Japanese characters, but characters such as ' and & are acceptable for example.
-And as the final guideline:
+# This is intended to be a navbox to replace the one at the bottom of the individual Power Combo pages, like [[Burn-Burn]] and [[Ice-Stone]].
+# The accessibility factor, in my opinion, is that you can look along a column or row corresponding to an ability and immediately go "oh, okay, this does that." I admit, Gigi's did a far better job of that. This is more organized than simply listing out each combination on one line, due to the column/row alignment. The text version is hard to look at for some reason I can't really explain.
+# I understand the concern for repeats, however I think that's a more than worthy sacrifice for the format. I'd like to call to mind the twenty-something redirects we have for these same abilities - those can be very helpful for accessing the needed Power Combo in case you get it the "wrong" way.
-*Files should not be moved unless it's to fix an issue with these guidelines.
+I'm not sure how to approach making the table now. I like the new table, but I think at least some people were voting for the old version, and I don't know if their thoughts still stand. Should I edit in another option this late in the run? Should we just assume one table or the other? Or should we have a second run at this, assuming it gets approved, to decide between the two?[[User:Waddlez3121|Waddlez3121]] ([[User talk:Waddlez3121|talk]]) 17:34, 4 September 2023 (UTC)
-That way we don't have "move wars". With the example I used, if there is a file named "Kirby KSSU Artwork" it's acceptable. It shouldn't be moved to "KSSU Kirby artwork". This is equivalent to editing a page and changing certain words but still keeping the same meaning, which isn't productive at all.
+==Basic gadgets (July 14th 2023 - July 28th 2023)==
+If you're a registered editor on WiKirby, you must have traversed your preferences at least once and seen the [[Special:Preferences#mw-prefsection-gadgets]] tab. We have two gadgets on entire WiKirby: [[MediaWiki:Gadgets-definition]], one of which enabled by default and hidden (shows a link to refresh RC when new changes were made, no reason to disable it) and the other shows [[:Category:Meta categories]] which are hidden by default without having the gadget enabled.
-All that should then be listed in [[WiKirby:Naming policy]], and [[WiKirby:Image standards]] and [[WiKirby:Audio standards]] should list them and link back to the naming policy. [[Help:Moving pages]] should mention files and explain when they should and shouldn't be moved.
+I think we ought to buff editor experience with more gadgets available in preferences. I recommend adding [[:wikipedia:MediaWiki:Gadget-HotCat.js|HotCat]] first and foremost (see the info page: [[:wikipedia:Wikipedia:HotCat]]), then [[:wikipedia:MediaWiki:Gadget-purgetab.js|Purge action]] (in form of a button in the header, after "watch", to refresh cache of pages), [[:wikipedia:MediaWiki:Gadget-edittop.js|Edittop]] (adds an [edit] button to edit the just the lead section of the article, without having to load the entire article), [[:mediawikiwiki:Reference Tooltips|Reference Tooltips]] (when you hover over a reference it shows the source without having to click it and go to the bottom of the article and back to read sources) and [[:commons:Help:Gadget-Cat-a-lot|Cat-a-lot]].
+Having all of these added as opt-in, nothing will change for anyone not looking forward to using them or having to disable them. I'm sure wiki support knows gadgets better than I do, but adding them is pretty simple and even I can assist if this proposal passes. {{User:Vipz/sig}} 13:21, 14 July 2023 (UTC)
-What do you all think? {{User:Gigi/sig}} 20:17, 14 May 2021 (UTC)
 {{Support}}
-#I find no problem with any of these changes, with the no file redirects rule being especially helpful and the rule regarding all filenames having certain parts certainly helping out with being consistent, even if just a small bit. {{User:Pinkyoshifan/sig}} 22:19, 14 May 2021 (UTC)
+# I come down on overall support. Edittop and Reference Tooltips both seem quite handy. Purge is something I typically do just by editing the URL but I can see it being handy for some as a proper link. I don't use categories so much but can see the value in having HotCat and Cat-a-lot available for others. {{User:WillIdleAway/sig}} 14:25, 14 July 2023 (UTC)
-#Per my comment down below. {{User:Superbound/sig}} 06:01, 15 May 2021 (UTC)
+#Pretty much the same opinion here as WIA, some seem useful to me and although I wouldn't use the others I can see how others would. {{User:Pinkyoshifan/sig}} 20:33, 14 July 2023 (UTC)
-#General support for this. See my input down below for details. --[[User:Samwell|Samwell]] ([[User talk:Samwell|talk]]) 16:59, 17 May 2021 (UTC)
+#I'm not too knowledgeable on gadgets and stuff but extra tools wouldn't hurt, in fact I could use quicker purging actions so voting in favor. {{User:ShadowKirby/sig}} 12:35, 28 July 2023 (UTC)
-#I've been thinking and I now agree with almost all of the proposals. The file redirects could be used for something and only should be disabled for most purposes. We should be cropping transparent files to make them look at their best. I realize that having one specific way to name files is too strict and new contributors might break the rules immediately if stricter file naming rules are applied. {{User:GameDoor64/sig}} 22:07, 17 May 2021 (UTC)
-#I haven't really considered before the reasons found below in the discussion panel as to why preventing the creation and existence of file redirects may cause some problems. I'm largely neutral either way regarding this. If we do end up keeping certain file redirects, as long as we diligently keep them off articles, I've nothing against it. As for recommending images to be cropped and optimized on some policy pages, I entirely agree with it. As for file naming guidelines... I really don't think we need any strict guidelines as Gigi said. A lot of moves I've seen have seemed unnecessary. Renaming "KSSU Birdon Artwork.png" to "KSSU Birdon artwork.png" is very unnecessary, for example, so I generally agree that we should only move files if there is a problem in which the file ''needs'' to be moved, not just because of personal preference. Some sort of ordering for the respective subjects in file names could possibly be positive, especially in "sets" of similar files and to avoid a situation where "KSSU Birdon Artwork", "KSSU Birdon artwork", and "Birdon Artwork KSSU" all exist for example, but renaming many if not all files to a set order does largely seem like an unachievable task that's not really worth the effort in all, and I could definitely see said "sets" being defined differently between editors and becoming controversial, as Gigi said. Sorting through these different definitions and picking out one and strictly using it honestly seems like more work than it's worth to me, especially since again, as Gigi said, we're a Kirby wiki, and having extremely strict guidelines just doesn't seem fitting for us. As long as the file tells me simply what I want to know about it, I'm satisfied.
-::To summarize, I generally agree with this proposal and support it. -- {{User:MetaDragon/sig}} 06:31, 27 May 2021 (UTC)
 {{Oppose}}
-#I agree mostly, but disagree on a few minor points such as putting the game abbreviation first and allowing special characters. {{User:Kirb/sig}} 09:37, 27 May 2021 (UTC)
 {{Neutral}}
-#Point 1 and 2 go without a say, but I disagree with third's subpoint 1 and subsequently 4. Policy is supposed to guideline editors into naming new files well in the first place, so 4th doesn't need to happen (and instead say to not capitalize "Artwork / Sprite / Screenshot"). Order doesn't matter because they only affect categories really (they're findable by searching too), so sure there, but I'd prefer type on last place. If someone is willing to make a small set of consistency moves at a time, that's fine. (Again, regardless of actual vote outcome, please regard the discussion made below, so multi-point proposals don't end up 100% yes or 100% no). {{User:Viperision/sig}} 08:29, 15 May 2021 (UTC)
 ===Discussion===
-I fully agree with points one and two.
-Point 1: File redirects are not necessary, and only take up space. As the proposal states, they only exist to help new users not accidentally move a file and break many pages. Adding a note in the policy stating that file redirects are discouraged will not only let new users know, but also remind them to properly change the links on images they moved.
+{{clear}}
-Point 2: Both optimizing and cropping are two helpful tactics to reduce file space and size, especially when loaded on pages. It is a very good idea to encourage these. (It should be noted that it actually increases the total space used up as MediaWiki keeps all versions of a file unless they are specifically deleted, and even then the file exists only visible to admins+.)
+==Updating Video policy to allow small official videos (July 4th 2023 - July 18th 2023)==
+Right now, the wiki's [[WiKirby:Video policy|Video policy]] is mostly focused on trailers and gameplay footage recorded by wiki editors. On that scope, it makes perfect sense and covers well those subjects. However, there are some other kinds of videos that are currently not addressed there, and that I believe we need to address and to allow them to be directly uploaded on WiKirby. That policy was originally written quickly after the wiki's first video file was uploaded, and was set to be reviewed with proposals, so here I am. :P
-Point 3: The third point is one where I partially disagree. I do agree that all filenames should contain the subject, WiKirby game abbreviation, and image type unless not needed. The parts I don't completely agree with are that the order does not matter, non-proper noun capitalization is up to the uploader, and files should not be moved unless necessary.
+For full context, Twitter has been dying for a couple months now, and its future continues to be uncertain. Very recently, it became impossible to view tweets without being logged in, and there is currently a limit on the number of tweets an account can read. With official Kirby Twitter accounts around, it became even more important to archive and document tweets from said accounts. As of right now, we document pretty well various Kirby Twitter posts, and by doing so we upload images alongside their text. I will use [[List of Kirby JP Twitter game reports - Kirby Star Allies]] as an example here. However, we do not upload videos of tweets when those exist, and instead we just upload the default image of the tweet's video. An example of that is [[:File:KSA Twitter - Rick & Kine & Coo.jpg]]. There is a Twitter link right next to the post to click and see the video, but, in particular with Twitter's current situation, this is far from ideal. People can only watch the video if they are logged in on Twitter, and if they haven't reached their full quota for the day. And while you could say we can just link an archived link of that same link, this is assuming the link was archived before the change, since as of right now if you try to archive a tweet, it will archive the login page. Moreover, this is not future proof, as it will be impossible to archive new tweets with archive.org.
-Subpoint 1: I think that the order of the words of the filename can be important in situations where multiple files exist, all with the same name but different order. I have moved many files and seen many situations where "KSSU Kirby Artwork", "KSSU Kirby artwork", and "Kirby Artwork KSSU" all exist as an example. This is why I personally always put the game abbreviation at the beginning, so when I scan through the image category, all of the similar files are grouped together. In regards to the Commemorative Illustration category, it is a very rare occurrence. In it's case the subject should go at the beginning of the name because of how long "Twitter Commemorative Illustration" is. For nearly every other category, the game abbreviation is 2-5 characters long, and does not take up a lot of space (KA, KSS, KRtDL, KPR, KF2), and the image type (sprite, artwork, screenshot) is at the end of the filename usually. Putting the game abbreviation is my personal preference, because if every image starts with the abbreviation, none of them do in regards to alphabetical order.
+On a less priority note, some recent Kirby games have had tutorial videos which I think would be neat to have on the wiki. If you are on WiKirby's Discord, see [https://discord.com/channels/266426802321227778/323530530681520129/968219641300262945 here] for a message I posted last year about ''Forgotten Land'', and see [https://discord.com/channels/266426802321227778/323530530681520129/1083781856450842645 here] and [https://discord.com/channels/266426802321227778/323530530681520129/1083779554256101426 here] for a quick mention of videos like that from ''Return to Dream Land Deluxe''. Currently these can only be uploaded if converted to gifs or apngs which... fine. But if the raw files are videos, I don't see the need to convert them when all the video files are super small.
-Subpoint 2: Proper nouns should always be capitalized in filenames, but other words probably shouldn't. I'm not sure if it should be a rule, but it should be suggested that words such as "concept artwork", "screenshot", "and", and "scene" don't really have to be capitalized. (They nearly always aren't right now.) I would ask that we suggest uploaders to not put any words in FULL CAPS that aren't supposed to be, as this is not useful and kind of annoying.
+Anyway, the wiki doesn't currently allow these videos to be uploaded, in particular due to these two points of the current policy:
-Subpoint 3: Special characters can be allowed in filenames, with the exception of non-readable characters (Japanese, Arabic, Russian) and periods (which can mess with the filetype). We should probably also ban emojis from filenames although nobody has attempted uploading emoji names yet as far as I know. While special characters are allowed, they should only exist if they are part of the name, such as allowing "KSSU Daroach's Airship screenshot.png", but not allow adding extra characters that don't need to be there. In general, there shouldn't be extra words/characters added to filenames. ("KA Kirby sprite.png" vs "Awesome Kirby picture (Adventure) image ~ sprite.png")
+* Uploaded videos should only be of unedited gameplay footage, unless there is a very good reason otherwise. Generally, collaging different unedited footage in a single video is okay.
+* Uploaded videos '''must''' be the uploader's own work, or uploaded with '''explicit permission''' from the original creator. You may not upload videos by Nintendo or HAL Laboratory, even if they are publicly released. Use an embed for that instead.
-Subpoint 4: I think that files should be moved to match with similar files. If there are a lot of files like "KSS Stone artwork.png", than if one file is "Spark Artwork KSS.png" it should be changed to fit in with the rest. It doesn't need to be required or top-priority that filenames be similar to others in their group, but it shouldn't be a bad thing to make one file fit in with the rest. {{User:Kirb/sig}} 20:37, 14 May 2021 (UTC)
+The second point in particular the root of what I want to change. The "Use an embed for that instead" seems to imply that that is possible by default for all those kind of videos. For the two kinds I mentioned, there is no way to embed them unless we upload them to some random Youtube account and embed them, which feels very counter productive for me. If we are allowing videos to be uploaded on WiKirby, why are we telling people to embed '''all''' official videos? Again, this was probably written with only trailers and Youtube videos in mind, but the spectrum is much bigger than that. And as this stands, which a very restrictive policy, [[:Category:Video clips|we only have three video clips uploaded on WiKirby]], all of which could even just be gifs. Unless we want to take a step back and go back to disallowing videos on the wiki (which I don't think we should do), we need to make the video policy less restrictive.
-:For reference, I don't want to make extremely strict rules to naming files. Most of your counterarguments seem to favor that.
+With all that said, my proposal is to rewrite the Video policy to allow the two kinds of videos I mentioned above, by changing the policy points as follows (with only the first three points being changed):
-:Subpoint 1: I will be honest, I fail to see the point you're making here. Can you explain better?
+# Uploaded videos should not be excessively large in size (not significantly larger than the largest images, which are around 5 MB). Exceptions can be made for official videos that are a bit larger than that, but should be avoided.
+# Uploaded videos that are the uploader's own work should only be of unedited gameplay footage, unless there is a very good reason otherwise. Generally, collaging different unedited footage in a single video is okay.
+# Uploaded videos '''must''' be the uploader's own work, or uploaded with '''explicit permission''' from the original creator. You may upload videos by Nintendo or HAL Laboratory '''only''' if they are short unique videos posted on social media such as Twitter, or present in the game itself such as tutorial videos. Trailers, advertisements, cutscenes, and other long videos should never be uploaded; use an embed for that instead.
+#Uploaded videos are subject to similar quality standards to images and/or audio, and bad quality videos will be deleted. Generally speaking, gameplay footage should follow the same [[WiKirby:Image standards|resolution standards]] as images.
+#At least for now, you may not upload personal videos for your userpage. It must have some use for the wiki proper.
-:Subpoint 2: Again, it doesn't really matter if they aren't capitalized or not unless it's proper nouns. Moving a file just to change that isn't necessary. If you think it is, could you please elaborate?
+Thoughts, suggestions? In particular, is there any copyright issues with anything I mentioned? And as a final note, while most of the videos I mentioned here are not very big (usually at most 10 MB), some are bigger, like [https://ia601506.us.archive.org/22/items/kirby_jp-twitter/2019-04-27%20Kirby%20JP/1121972693648064512_MTP8TG84958srUiU.mp4 this] (which is 20 MB), so I can understand concerns with that. But most of the videos are short and small like [https://ia601506.us.archive.org/22/items/kirby_jp-twitter/2019-10-18%20Kirby%20JP/1185027983049809921_YKIx6PLbhK9al0wN.mp4 this]. The size of videos to allow is still a bit up in the air, and we could perhaps ask to embed larger videos. Feel free to comment on that. {{User:Gigi/sig}} 12:16, 4 July 2023 (UTC)
-:Subpoint 3: Fair enough. That is what I was going with that.
+{{Support}}
+#Just for the mere fact that Twitter is in danger of extinction <s>and being that for most of the year it's unavailable for me anyway</s> I would very much like to see the videos uploaded to WiKirby. I don't see any reasons to oppose and that's all that matters at this point. {{User:ShadowKirby/sig}} 12:47, 4 July 2023 (UTC)
+#Agreed, there needs to be a way to preserve official videos (and also make them more accessible) and I'm not sure if Wayback Machine was ever capable of saving Twitter videos (and definitely isn't now). Having the tutorial videos on-wiki also seems good. {{User:Pinkyoshifan/sig}} 13:22, 4 July 2023 (UTC)
+#Allowing uploads of tutorial videos makes a lot of sense to me—they comprise a small part of the overall game, and they are clearly not replacements for playing the game both due to that and due to the resolution of the videos (no larger than 1000px in either dimension). For Twitter videos, one possibility is to host either downscaled or clipped versions of > 5 MB videos, and link to IA copies of full-resolution versions, but overall I think there is a rationale for many of them (thinking of the video that shows the KF2 HAL easter egg, to give just one example) to be uploaded without infringing on any of HAL's commercial opportunities. {{User:WillIdleAway/sig}} 17:48, 4 July 2023 (UTC)
+#I don't see any reason to go against this. Having videos from social media would be neat, which it is not so different from what is being done now, and having in-game videos that are not cutscenes uploaded here would be a good resource. {{User:Zolerian Yuviaflero/sig}} 02:59, 5 July 2023 (UTC)
+#This appears to be a highly logical safety measure to preserve content that is at risk of disappearing with no way to see it. Especially with how Twitter seems to be going down the drain it can't hurt to start preserving the relevant stuff on there now instead of taking the gamble. [[User:Infinite Possibilities|Infinite Possibilities]] ([[User talk:Infinite Possibilities|talk]]) 11:07, 5 July 2023 (UTC)
+{{Oppose}}
+{{Neutral}}
-:Subpoint 4: The issue with this is where you draw the line. What are "similar files"? How do we define that? Do all artwork files need to follow the same pattern? Or just files from a certain game? Or just copy ability files? It starts to become extremely arbitrary.
+===Discussion===
+I'm coming to this late, but... Why wouldn't we? Even if Twitter wasn't currently (insert "crapping itself like _" here), it seems really silly to not have our own backups of these things in case an existing source does go down for any reason. Now, given, if they ask us to remove the videos that's a different story, but the way I see it, for Twitter-sourced videos we can send them something like this in return:
-:Again, I just want a simple set of guidelines just to make sure people aren't naming a file like "poppy bros. jr. kssu.png". I really don't want us to make very specific guidelines to files because they are mostly hidden to editors. And I keep seeing unnecessary edits to files that I would really rather see stop. That is all. {{User:Gigi/sig}} 20:47, 14 May 2021 (UTC)
+"Hi, yes, we'll remove them from the archive immediately. Do you have any other source than Twitter for these videos? We're concerned with the longevity of the platform and would like to source these videos on a more accessible platform."
-::I agree that it can be difficult to determine what makes files "similar", but I mainly didn't want to be prohibited from moving a few files to match with closely-related files. I think all files in a "set" should follow the same format. A "set" being very specific, such as all copy ability sprites from a certain game, or every screenshot from a certain stage. Most images are not like this, but many are. If all of the Super Star Copy Ability sprites follow a format except one, I would want to rename that one. I can however see that many of the moves I have done were not necessary, and I will try not to move files that already have acceptable names. {{User:Kirb/sig}} 21:05, 14 May 2021 (UTC)
+And if they don't have that, then we deal with that from there.[[User:Waddlez3121|Waddlez3121]] ([[User talk:Waddlez3121|talk]]) 01:18, 6 July 2023 (UTC)
+::A few things to consider:
+*Video files are inherently very large. Even if the server host is willing to take on a lot more of these files, it will also have a significant page loading factor for the end user—the more videos you have, the longer it may take a page to load.
+*There are not a lot of universal standard file formats to use: Do you plan on using MP4? AVI is generally large in size, MKV has rough support, and Vorbis OGV is also not supported on Apple systems. Furthermore, HEVC encoding (H.265) and MOV are proprietary. I think you need to develop clear and explicit guidelines for how exactly these files need to be uploaded and presented if this does move forward. [[User:Trig Jegman|Trig]] - 04:09, 7 July 2023 (UTC)
+:::Current video policy prefers MP4 (which I suspect will be the format for all accessible Twitter videos), but unlike generic MKV files, WebM files using VP8/VP9 have reasonable browser support at this point without the proprietary problems of HEVC (and is the native format for some of the in-game files being discussed). So MP4 and WebM are what we should encourage—I suspect those will often will end up being what gets uploaded anyhow but it wouldn't hurt to enshrine it in explicit policy. I don't know that we need explicit bitrate/resolution specifications beyond using native resolution where possible and arriving at a sane total file size, but can be persuaded otherwise.
+:::As far as presentation is concerned, I don't know if I'm taking that in the right spirit but I guess one question is whether videos should autoplay or at least be optionally allowed to autoplay. One issue I see potentially happening is for non-16:9 videos when embedded (eg [[:File:KDL dance.mp4]] where I have to employ a CSS hack to remove 'letterboxing' of sorts).
+:::(Slightly orthogonal point, but we could also use clearer guidelines for audio files (eg MP3 uploads at 128 kbps joint stereo).) {{User:WillIdleAway/sig}} 14:23, 14 July 2023 (UTC)
+::::Currently on upload we allow png, gif, jpg, svg, flac, mkv, mov, mp3, mp4, oga, ogg, ogv, wav, webm. So I guess for videos we allow mkv, mov, mp4, ogv and webm right now, but indeed, as mentioned, the policy says mp4 is favored, which I agree. I'm not opposed either to disallow certain file types if we believe they should probably not be allowed at all.
+::::Regarding file size, I think as long as we determine a file limit it should be fine. As for what to do about bigger videos, it appears the solution is to either compress them and link to the original version, or maybe even upload to Youtube. Thinking it over, I wouldn't be opposed to having a WiKirby account for for that purpose if we decided we prefer that method. {{User:Gigi/sig}} 15:23, 14 July 2023 (UTC)
+::::One more thing about file size: although the video policy claims that the largest files on WiKirby are generally 5 MB, [https://wikirby.com/w/index.php?title=Special:ListFiles&sort=img_size&limit=250&asc=&desc=1 that is certainly not true]. So I suppose the file size discussion should be broader than videos. Although I will admit, I know for images thumbnails are generated, which makes page load better, but I'm unsure if a similar system exists for videos, or if they always are fulled loaded once a page is loaded. {{User:Gigi/sig}} 15:42, 14 July 2023 (UTC)
-:::The issue happens when someone else considers a "set" different from someone else, or really when different "sets" are used on pages of the same subject. An example: ability icons are usually grouped together in galleries, but some copy ability pages don't do that and icons are between various kinds of files. Compare for example [[Beam#Gallery]] and [[Archer#Gallery]], they are very different. Again, it is really arbitrary, and if we made rules for each case we would be here all day making rules and, frankly, we're a wiki about Kirby. We don't need a million rules. Which is again why I think we should have some basic ones and leave the rest for the uploader. {{User:Gigi/sig}} 21:27, 14 May 2021 (UTC)
+Side note, but before I forget: it appears Wayback Machine is really bad in general about archiving Twitter videos. Using [https://web.archive.org/web/1000/twitter.com/Kirby_JP/status/880631044365467648 this] as an example, I looked at every snapshot of it and I couldn't play the video of this tweet in any of them. And getting direct links to a Twitter video is extremely annoying. If we move forward with the idea that certain videos need to be compressed to be uploaded and we link to an archived version for someone to see it at the highest quality, we will likely to figure out how to archive said videos. Personally, I would recommend to use links from [https://archive.org/details/kirby_jp-twitter my own archive of the Kirby_JP Twitter account], and we can link the video directly [https://ia601506.us.archive.org/22/items/kirby_jp-twitter/2017-06-30%20Kirby%20JP/880631044365467648_B5LzEFITgMQ5aQa7.mp4 like this]. {{User:Gigi/sig}} 15:04, 14 July 2023 (UTC)
-::::When you say "special characters", which ones do you mean? I don't think we should allow any characters that aren't on a standard QWERTY keyboard. {{User:Kirb/sig}} 01:07, 18 May 2021 (UTC)
-I do agree on the first proposal that file redirects shouldn't be allowed and that we should optimize images. I however don't agree on the third proposal. I have renamed over 100 files just to name them like this: '''KSSU Plasma Wisp artwork'''. I believe that we should [[User:GameDoor64#A Small Guide to Files Because I Like Doing Things With Files|name files]] like what I mentioned before. {{User:GameDoor64/sig}} 21:00, 14 May 2021 (UTC)
+{{clear}}
-:Your personal guidelines are basically the same as mine. I'm confused as to what you go against my proposed guidelines for files. Care to elaborate? {{User:Gigi/sig}} 21:27, 14 May 2021 (UTC)
+== Require archiving external links (May 20th, 2023 - June 3rd, 2023) ==
+<pre><nowiki>
+== Archiving external links ==
-::I just believe that we should have the files named in a certain way for organization. I can see the reason that you're behind with having the files named in any order of abbreviation, subject, type of image. But it'll make finding images easier provided we don't have file redirects. {{User:GameDoor64/sig}}
+Ideally when using a website, image from the Internet, or especially a post from the social media as a citation, a link to a [https://archive.org Wayback Machine] archive should also be provided. This is a future-proof measure, in case the site (or the account) gets deleted and the source is no longer accessible or verifiable. Finding an archive is simple: just paste the URL of the site you want to add into the Wayback Machine search bar and see if its here. If yes, then its simple, just use the URL provided. If no, then its still simple, as it can be requested for an archive to be done, which should only take few minutes.
+Note that some sites block Internet Archive (such as Nintendo of Europe). In this case, the rule does not apply.
+</nowiki></pre>
-:::I just don't believe we need extremely strict guidelines for file naming when we have categories and galleries and the search function. For me as long as the file name gives me enough information about the file it should be good. Moreover, I would rather to see energy spent on actual bad file names than perfectly fine ones. Not to mention that every user has their personal way to name files, and I fail to see a good reason to move good file names that doesn't have any problems. I personally have my own issues with files starting with the game abbreviations, but I won't go on my way to rename files like that because, honestly, it's not my place, even as the editor-in-chief, to impose my personal opinion on a small thing such as a file name. And frankly, the effort it would be to make all files follow some extremely specific guidelines is too much more work than it's worth. {{User:Gigi/sig}} 21:54, 14 May 2021 (UTC)
+I propose for the above text to be added to [[WiKirby:Citing policy]]. The events that had happened recently, such as [https://web.archive.org/web/20230518125805/https://help.imgur.com/hc/en-us/articles/14415587638029-Imgur-Terms-of-Service-Update Imgur purging their site from many images], Nintendo Online Magazine and Smash Bros. DOJO!! shutting down, as well as prophecies of Twitter's death have raised awareness that stuff on the internet, in particular social media, can easily be deleted. Thus, as a future-proof measure, I believe every possible external link that can be archived should be done so with Web Archive. {{User:Superbound/sig}} 12:18, 20 May 2023 (UTC)
-Why I don't like "strict file name format":
+{{Support}}
-#Causes a lot shenanigans. "KSA Susie Artwork.png" is bad, but "KSA Susie artwork.png" is better? Or "Archer KSSU sprite.png" versus "KSSU Archer Sprite.png"? Like why, they basically the same.
+#Agreed. Losing stuff off the internet is going to happen, but making sure it's not gone forever is why the Wayback Machine was made. We already have [[:Category:Pages with dead links|some sources that may have no archive]], and it would be a good thing to keep that from growing. {{User:Pinkyoshifan/sig}} 12:23, 20 May 2023 (UTC)
-#As Gigi mentioned above, there is no way we ever agree on what format should be used, as any variation has their own pros and cons. Starting with subject helps navigating [[:category:Images by game|game categories]], but starting with abbrevs helps in [[:category:Images by character|character images]]. And there's nothing to stop us from just accepting both, so why bother?
+#Fight [[wikipedia:WP:LINKROT|link rot]]. (That could be a useful policy to refer to, by the way.) It'll only be a matter of time before other websites, like CBC's website for the anime and possibly even the original Smash Bros and Melee promo pages (with Kirby questions and answers), also shut down. {{User:WillIdleAway/sig}} 15:35, 20 May 2023 (UTC)
+#This is something that Wikipedia does, I think. There is no reason as to not do this, and pointing it out in the policy would lead more people into doing that, which indeed would prevent and bad future. If someone adds some link without an archive, thus "breaking the policy", the edit wouldn't be reverted, but instead ideally it would be kept while also adding the corresponding archive, so again, there is not bad in this. {{User:Zolerian Yuviaflero/sig}} 20:15, 20 May 2023 (UTC)
+#If this is what it takes to preserve a source then I'm all for it, I'll just have to learn how to use that... {{User:ShadowKirby/sig}} 07:53, 21 May 2023 (UTC)
+#Full support. I remember a while ago that Kirby's Rainbow Resort was down for months and we had to go around updating links to their archive.org versions, when they existed, in many images. The site did go back up, but that won't always be the case. There is also time sensitive stuff like Kirby Café dishes that we need to archive occasionally or they will be lost in time. All in all, this ideal to preserve our sources. {{User:Gigi/sig}} 21:59, 22 May 2023 (UTC)
+#Heavily agree with this. Preservation is important, especially if we want to check something later. {{User:GoldenDragonLeaf/sig}} 20:30, 26 May 2023 (UTC)
+#After this passes, we should consider recommending Wayback Machine extension/add-on in {{tl|Recommended Downloads}} and adding archive parameters to {{tl|cite}} and {{tl|Twitterlink}} templates. I also recommend improving the proposed wording - 1) it's unclear to me what "if yes" and "if no" are answers to. 2) there are too many "it's simple"s. 3) where can one request an archive to be done? what will take a few minutes? 4) steps should be made into a list. 5) integrate archive.today as proposed in the comments section when it comes to NoE. It wouldn't hurt to also explain why are we recommending archival in the recommended text. {{User:Vipz/sig}} 12:51, 29 May 2023 (UTC)
+{{Oppose}}
+{{Neutral}}
-I mentioned this some time ago (in [[WiKirby talk:Abbreviations|abbreviations proposal]]), and brought it up on Discord few days ago -  the descriptiveness matters the most. I strongly support moving files only if there is an actual problem with them. Pointless moves are pointless, bring little to no improvement (or sometimes do the reverse) and clog recent changes.
+=== Comments ===
+I also suggest that [https://archive.today archive.today] is an acceptable website or at least doesn't seem to be immediately going away after ten years. Wayback Machine should still be preferred. Per [[wikipedia:WP:WEBARCHIVES]], [https://timetravel.mementoweb.org Mementos] will allow searching multiple archiving services at once. {{User:WillIdleAway/sig}} 15:35, 20 May 2023 (UTC)
+:It's worth noting that although it took a few minutes, [https://archive.is/TYYzd archive.today ''can'' archive NoE sites] for the moment. {{User:WillIdleAway/sig}} 15:39, 20 May 2023 (UTC)
+::Both should be used. Internet Archive has been lately clashing with lawsuits (i.e. [[wikipedia:Hachette v. Internet Archive]]) and its future is uncertain. {{User:Vipz/sig}} 16:21, 20 May 2023 (UTC)
-Points 1 and 2 are just writing already widely accepted unwritten rules, so no problem from me there too. {{User:Superbound/sig}} 06:01, 15 May 2021 (UTC)
+==Clarifying the role of neutral votes in proposal voting (2023-05-09 - 2023-05-17)==
-:Update: I'm not opposed to allowing file redirect as panda said below me if we decide to do so. {{User:Superbound/sig}} 10:51, 20 May 2021 (UTC)
+During a recent proposal about pronouns, some confusion arose about the meaning of neutral votes for proposals. Currently, rule 4 states that "After two (2) weeks of voting, a proposal will be immediately enacted if a simple majority of more than 50% of votes are supportive, [...]". The regulation does not mention neutral votes, but according to its wording, this would for instance mean that a proposal with 5 supporting, 6 neutral and no opposing votes would not pass, as less than 50% of votes are supporting. This means that in most situations, neutral votes have the exact same effect as opposing votes (except for the purpose of passing a proposal early as outlined in regulation 5, where a neutral vote alone does not prevent this.) So far, this situation has not occurred, but I think this ambiguity should be resolved before that happens.
-To be honest I disagree that file redirects are unnecessary and shouldn't exist. Those who say that probably don't care about external sites linking to our wiki. By not redirecting old filenames to their new names, you break every single link to that old name. And even worse, we don't know how many times that old name is linked to in other sites we don't control.
+I believe a lot of people would intuitively assume that a neutral vote is equivalent to abstaining and should not prevent a proposal from passing. Therefore, I propose to change regulation 4 as follows: "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."
-See [https://www.w3.org/Provider/Style/URI.html Cool URIs don't change] by the W3C on why old links shouldn't break.
+If this proposal passes, there can be no doubt that neutral votes are not considered for the majority required by supporting votes, and if it fails, this equally clarifies that neutral votes are counted against the majority needed by supporting votes. Thus, this proposal will remove the current ambiguity regardless of its outcome. [[User:Typman|Typman]] ([[User talk:Typman|talk]]) 13:53, 9 May 2023 (UTC)
+{{Support}}
+#Neutral votes are more like a "fine by me, don't really mind", if someone is opposed to an idea the section is there, so I don't see why a vote saying "do as you wish" would override a "yes". {{User:ShadowKirby/sig}} 15:00, 9 May 2023 (UTC)
+#<s>As much as I want to vote neutral on this,</s> if people want a proposal to not pass, the oppose option exists. If they don't care about it either way, then they'll probably think neutral is the way to do that. Abstains shouldn't count as votes. {{User:Pinkyoshifan/sig}} 15:06, 9 May 2023 (UTC)
+#Though admittedly I don't really get the point of neutral votes in the first place, this would at least make them actually neutral instead of basically just opposition. [[User:Hewer|Hewer]] ([[User talk:Hewer|talk]] &middot; [[Special:Contributions/Hewer|contributions]]) 18:19, 9 May 2023 (UTC)
+#When deciding if you like a change, I see a Support as an "I want that", an Oppose as an "I don't want that" and a Neutral as an "I don't care", with the reason of you stating that you don't care being letting everyone else know that you are aware of this change proposal, but can't decide on an option, or both are fine with you because you don't mind. So in that case Neutral voting should not bring the proposal down, nor help it to pass. If we have one with 5 Supports, 0 Opposes and 7 Neutrals, really no one is against the change, as the ones that voted Neutral are supposedly doing so because they are fine with the change happening. {{User:Zolerian Yuviaflero/sig}} 03:11, 10 May 2023 (UTC)
+#The way I've used neutral votes is for if I don't mind either outcome of the proposal, so I definitely agree that they shouldn't hinder a proposal from passing and actually be considered a neutral vote. {{User:GoldenDragonLeaf/sig}} 03:15, 10 May 2023 (UTC)
+#I am in favor of this clarification. Neutral votes should not be used to "politely oppose" something. Neutral should only be for people with no strong preference either way. --[[User:Samwell|Samwell]] ([[User talk:Samwell|talk]]) 04:19, 10 May 2023 (UTC)
+#Yes, neutral should mean neutral and not oppose. As such, I'm in favor of the change. {{User:Superbound/sig}} 15:25, 10 May 2023 (UTC)
+#Clear and concise. The confusion during the pronouns proposal proved palpable and avoiding such confusion in future will be preferable. I also hope that this clarification may also encourage use of the Discussion section over voting Neutral. {{User:WillIdleAway/sig}} 12:17, 17 May 2023 (UTC)
+{{Oppose}}
+{{Neutral}}
-Now I'm not saying we should allow internal linking to redirects. They should be relinked to the new name. Preventing the creation of redirects is still okay, as long as the old name is not more than two days old, or the old name was blatantly inappropriate and offensive.
+===Discussion===
-A common argument by those who want to exterminate ala Dalek the file redirects is that they cost space. But the thing is, the moment you rename a file, you already took up some space. The moment the redirect was created, you can't take that space back by "deleting" it. In fact "deletions" in MediaWiki are more of just archivals and hiding of content from non-admins. They don't free any space, and will only waste even more space because every "deletion" is logged. [[User:pandakekok9|pandakekok9]] ([[User talk:pandakekok9|poyo]]) 13:56, 15 May 2021 (UTC)
+{{clear}}
-:I'll assume this doesn't refer to external sites using up WiKirby's bandwidth with their src attribute, but the ability to find moved files after redirect's deletion. There are 2 ways to delete a file redirect - one is by auto-deleting it when moving it ([https://wikirby.com/w/index.php?title=File:KARKirbyWallpaper.jpg which tells where the file got moved to]), and another is by tagging it for deletion, and the delete tag expects a reason for that. When deleted, all actions with the file or last content when manually deleted is always visible in the reference. {{User:Viperision/sig}} 01:29, 16 May 2021 (UTC)
-::Nope, I'm not referring to those sites who eat up WiKirby's bandwidth via the img src attribute, but rather those who link via the anchor tag.<!--
---><p>Of course you can still find the new name after deleting or preventing the creation of the redirect. It's always logged in the deletion log. But you forgot one thing: the old name can be recreated, thus hiding the new name in obscurity. Of course such thing is very rare, but it can happen. And besides, the average user most likely would be annoyed of not being automatically redirected to the new name.</p><!--
---><p>So with that in mind, what's the point of deleting such file redirects then? None. [[User:pandakekok9|pandakekok9]] ([[User talk:pandakekok9|poyo]]) 02:09, 16 May 2021 (UTC)</p>
-:::Now that you bring this up, I am unsure myself why this wiki has always deleted file redirects. It has been an unwritten rule for as long as I've been in this wiki. We even recently added the permission for any user on Autopatrol+ to move files without a redirect exactly because we deemed them unnecessary.
-:::I am honestly neutral on this subject: as long as pages don't use file redirects I'm okay with that, and I could instead just mention that in the policies and we could start allowing file redirects, and we would need to revert back that permission and only allow Admins+ to move files without redirects.
-:::I do have a question, however: what if a file is, say, named "Kirby KSSU.png" and it is moved to "Kirby KSSU artwork.png". Would a file redirect make sense here? A file named "Kirby KSSU" could be any file of Kirby from KSSU, a sprite, artwork, screenshot etc. In short, generally on WiKirby we move files because of bad or not specific names, would you still argue that these file redirects should exist? {{User:Gigi/sig}} 23:02, 16 May 2021 (UTC)
-::::Good question. I think it depends on the age of the old name, and as well as the knowledge on how many times it was linked to. If the old name is relatively new, maybe preventing the creation of a redirect is okay. If a redirect already exists though, they shouldn't be deleted, even if it was a mistake, or the old name is relatively new. Redirects should only be deleted when its name is obviously inappropriate or offensive. A good rule of thumb would be, "if in doubt, don't delete or prevent the creation of a redirect." [[User:pandakekok9|pandakekok9]] ([[User talk:pandakekok9|poyo]]) 04:23, 17 May 2021 (UTC)
-::::And by the way, I won't go as far as removing the privilege of moving files without a redirect for Autopatrol+. They are trusted, established users of the community, and our community is relatively small, so I trust they will do good judgment on whether to create a redirect or not. [[User:pandakekok9|pandakekok9]] ([[User talk:pandakekok9|poyo]]) 04:25, 17 May 2021 (UTC)
-==== Samwell's input ====
+==Deciding upon pronouns for characters with none (March 24th, 2023 - April 7th, 2023)==
-So, let me try to give my thoughts on all the points made here as succinctly as I can so as to avoid this discussion panel getting too much longer than it already is.
+A common issue that's come up on the wiki is what pronouns to use to refer to minor characters who haven't been officially referred to in third-person. Right now, there's a discussion about this ongoing with [[Bouncy]], and a lot of anonymous users have made small edits in this vein, usually changing characters with no confirmed pronouns to "it". However, there are cases where this approach seems odd; for example, [[Super Bonkers]] is referred to as "it" despite regular [[Bonkers]] being referred to as "he", and [[Keke]] is referred to as "they" (which I already changed from "it") despite being a reference to Kiki from ''Kiki's Delivery Service'', who is referred to as "she".
-*'''File redirects:''' I don't remember when the precedent started to delete all file redirects, but the reasoning that I held for the practice was specifically to prevent situations where redirect links were used in articles and gallery pages. I've personally had to chase after quite a lot of image links that weren't properly changed after a move and were creating viewing issues on pages, and it's easier to find those discrepancies when they are red links via the special pages. However, I don't have anything against file redirects existing so long as we are diligent in keeping such links off articles.
-*I've nothing to add regarding cropping transparent images or optimizing files, since I basically agree with the original proposal.
-*'''File naming guidelines:''' This one's a bit tricky, since a great deal of unwritten precedent was established by Trig Jegman when he started Project Clean-Up. In doing so, he set up what was for him a standardized policy that he personally used across the dozen or so wikis he was working on simultaneously, which paid little regard to whatever file naming policies may have existed beforehand (which admittedly for us was not substantial at the time). Personally, I still think it's a good idea to standardize file names to follow one rule set consistently (such as game abbreviation always appearing at the beginning, or always at the end, whichever one we'd decide on), but at the same time, I understand that there's already been so much file moving based on changing standards over the years. The prospect of having to do it all again feels like a Sisyphean task, and it may not ultimately be worth the effort. Also, for lack of a better term, a lot of Trig's name change fixation was fairly petty, as can still be seen on the Project Clean-Up page, and I've felt like tossing out entire sections of the file renaming columns as not worth the trouble. In short, I generally agree with Gigi's sentiment on this last point, that file moves should only be done when the name is not fit for purpose, not just because the capitalization is slightly off.
-In summary, I support the proposal generally, but remain neutral on the matter of file redirects existing or not. I will leave that one to Gigi and the rest of the community to decide on. --[[User:Samwell|Samwell]] ([[User talk:Samwell|talk]]) 16:59, 17 May 2021 (UTC)
+Since this issue will likely come up a lot if we don't address it soon, I figured I would create a proposal to establish a formal policy about this. Specifically, it would be a general rule to add to [[WiKirby:Writing style#Subject characteristics]] — '''if a character has no confirmed pronouns, go with what the majority of users feel is correct, as long as it's consistent.''' Just as an example, a lot of users have expressed the idea that referring to Bouncy as "she" feels correct because [[Bouncy Sis]] is, even if she hasn't been officially referred to as such. I don't think gathering a majority opinion has to be done in a formal poll, unless opinions are really split; rather, most can be inferred based on context and getting a general idea of what people think.
-{{clear}}
-==Small adjustments to Good page criteria (March 15th, 2021 - March 29th, 2021)==
+The reasoning behind this is because it's very unlikely every character will get official pronouns, so going with what feels right would be a lot less awkward than sticking with "it" for everything. I'm also open to other suggestions or improvements to this policy. [[User:StarPunch|StarPunch]] ([[User talk:StarPunch|talk]]) 23:01, 24 March 2023 (UTC)
-So, it was briefly discussed on the Discord that some adjustments should be made to the criteria for deeming an article Good in order to accommodate pages covering entities that only appear once in the series and/or have little to be said about them. On behalf of those in that discussion channel, I propose the following changes to the Good articles criteria on the [[WiKirby:Featured content policy|Featured content policy]] as follows:
-*Minimum number of bytes for a page to be Good to be reduced from 2,000 to 1,000 (assuming the page is otherwise complete).
-*Status of subpages to no longer be a factor in determining whether the main article is deemed Good or not.
-This will be a relatively minor change to the policy, but it should allow many short but complete pages on our wiki to receive the Good mark, as well as sparing the blushes of many of our larger complete pages that have incomplete gallery sub-pages. What say you all? --[[User:Samwell|Samwell]] ([[User talk:Samwell|talk]]) 01:49, 15 March 2021 (UTC)
 {{Support}}
-#Definite '''support'''. The main thing about a good article is that it should only have to be the best it can ''feasibly'' be. If the article's about a minor subject that can't reach 2,000 bytes, but it's still otherwise a fully fleshed-out article, that shouldn't have to hold it back. We definitely want as much detail as possible, but we don't want to encourage padding, either. [[User:StrawberryChan|StrawberryChan]] ([[User talk:StrawberryChan|talk]]) 01:53, 15 March 2021 (UTC)
+#We currently have a lot of inconsistency with pronouns, and we have unwritten rules such as "use it/its for enemies when there is no confirmed pronoun, but use they/them for characters". However, with no complete consistency in the series itself, we could, for example, have someone go to [[Sailor Waddle Dee]] and change the pronouns to it/its, claiming that we have a character with it/its pronouns, [[Sillydillo]], and we really won't have any other way to say no other than "I don't believe that's right" or "I prefer they/them", since Sailor Dee has no confirmed pronouns. We are already unofficially dealing with lots of conjecture when it comes to pronouns, and since English has two neutral sets of pronouns (it/its and they/them), and you can also argue that he/him is neutral, we really have no way to be 100% neutral without conjecture. On top of all that, the ''Kirby'' series is a Japanese series, and the Japanese language deals with pronouns way differently than English, to the point where it's possible to have lots of text about a character but with no specific pronouns to write an article in English about them (such as [[Gryll]]), so we can indeed have many cases where there are no official pronouns. Without a proper way to handle them, we will continue with endless debates on what is the right pronoun for a character (such as [[Bouncy]]) and we will go in circles. As such, I believe it's very reasonable to just come to an agreement with a simple vote with what kind of "conjecture" we will use for the pronouns of a character; the conjecture exists with or without a set of rules, but without one we will have way less constructive debates. Pronouns aren't something supplementary like a character's gender, they are required for us to write an article about a subject, so if a character has no confirmed pronouns, we will have to choose one for them, there is no way to avoid that. There is no way WiKirby will exist 100% without conjecture in any form, and expecting that is unrealistic. {{User:Gigi/sig}} 21:45, 26 March 2023 (UTC)
-#I agree. Some pages are fully completed but still under 2000 bytes. And a page can be good without it's subpages being so. {{User:Kirb/sig}} 01:56, 15 March 2021 (UTC)
+#Given the inconsistency introduced by KatFL in third-person pronouns for some Mid-Bosses like Gigant Edge, it is fair to say that Nintendo of America themselves engage in conjecture much of the time, given the original Japanese text is unlikely to give guidance and given HAL may not necessarily have codified genders in mind for many characters (including Kirby), certainly not in a sense that translates cleanly to English. This leads me to believe that the concern with the wiki's conjecture policy is moot. The alternative to recommending a consistent (if conjectural) pronoun use in these cases would be highly constrained writing to play the [[wikipedia:pronoun game|pronoun game]], and this would put a much more significant burden on editors to rewrite edits that inadvertently assume pronouns compared to a simple pronoun replacement for edits that inadvertently use non-consensus pronouns. {{User:WillIdleAway/sig}} 14:16, 29 March 2023 (UTC)
-#Agreed, not all short pages are necessarily bad (an example that comes to mind is most of the [[:Category:Kirby & The Amazing Mirror|K&TAM rooms]]). Removing the subpage requirement doesn't hurt either. {{User:Pinkyoshifan/sig}} 11:18, 15 March 2021 (UTC)
+#Since there are many cases where pronouns change or are simply not given in the games, I don't think there's a simple rule we could use to decide on pronouns that are appropriate for all characters, so I think it makes sense to decide on pronouns for unclear cases like these by coming to a consensus through discussion. Consequently, I support the proposal based on this and the arguments brought forth by the previous supporters. [[User:Typman|Typman]] ([[User talk:Typman|talk]]) 14:33, 29 March 2023 (UTC)
-#Actually I think we should remove the bytes requirement, which seems unnecessary IMO and can be an inaccurate metric for completeness (who knows, maybe someone suddenly knew of a way to abstract the content of a 1000-byte good article to a template, shrinking the article down to like 900 bytes. Should we demote the article just because someone knew of a better way to encode an article?), and let the patroller+ judge whether an article is complete enough and of good quality. But this is a good start. As said by others already, there are articles that are short but can't be expanded because it's already complete. --[[User:pandakekok9|pandakekok9]] ([[User talk:pandakekok9|poyo]]) 15:34, 16 March 2021 (UTC)
+#While not ideal solution (I have my doubts if calling votes would be effective), I think that it is a better option compared to current anarchy, or a very restrictive system (pronoun game) that would only hurt the quality of our pages. In addition, taking into consideration how pronouns and gendering in the Japanese language work, and plethora of characters or species that exist in Japanese popmedia and simply don't have gender (even [[Kirby]] being example of such), I doubt that HAL designers themselves think about this matter. So support. {{User:Superbound/sig}} 18:04, 31 March 2023 (UTC)
-#I support. This sounds like a reasonable idea. Pages can be complete and be worthy of being marked as 'Good' and be under 2000 bytes. They can also be 'Good' even if their subpages are not. -- {{User:MetaDragon/sig}} 02:55, 18 March 2021 (UTC)
+#I thought about this for a while and decided to vote in favor. Even if "what the majority feels is right" isn't the most objective reason, given the absence of actual pronouns, it will end up being "what the specific editor feels is right", which is still conjectural. I trust that our community is rational enough to not pick pronouns "because they just like it". However, solidifying some nuances can be helpful. For instance, I think that forms of a certain character/foe that has known pronouns (like the aforementioned Super Bonkers) can inherit the main form's pronouns, though that could still be subject to discussion. In short, if this isn't the best solution, what is? [[User:ShadowKirby|ShadowKirby]] <small>(a.k.a. your new overlord ShadowMagolor)</small> 10:14, 3 April 2023 (UTC)
-#As said by others above, if an article covers all information that can be added without question it deserves to be granted ''good'' status. Unnecesarily bloating pages with half-correct information to reach 2000 bytes only hurts the credibility of the wiki. For subpages, those often are only relatively minor in general and don't need to affect the main pages in a negative way. Support all the way. [[User:Infinite Possibilities|Infinite Possibilities]] ([[User talk:Infinite Possibilities|talk]]) 08:54, 18 March 2021 (UTC)
-#The Good status is just for pages that are complete. The 2,000 byte limit just encouraged padding for small pages. {{User:Obsessive Mario Fan/sig}} 17:54, 29 March 2021 (UTC)
 {{Oppose}}
+#I personally find that there could be better ways of going about this, one of which might be to allow things to stay as they are. We must consider the fact that pronouns ''shape (and and are shaped by!) the way we look at people and the way we look at things'', and even if conjecture is inevitable in the end, I think that for the sake of neutrality we should stick to what we have. Even then, it is true that a Writing Style rule would be very valuable for consistency. {{User:Astigmautism/sig}} 14:07, 28 March 2023 (UTC)
 {{Neutral}}
+# WiKirby has gained a reputation of being [[WiKirby:Conjecture policy|non-speculative]] so far. We'll be playing a role in establishing pronouns of subjects which may prove completely wrong at some point in the future. Even if we get proven correct in other '99%' of times, the mere fact we do not differentiate between confirmed and conjectured pronouns can only weaken perception of WiKirby's reliability regarding both. I want to see opinions from others, so staying in Neutral for now. {{User:Vipz/sig}} 11:06, 25 March 2023 (UTC)
+#While I agree that this would be a definite solution to the issue of people trying to change character pronouns, I agree with Vipz that there is the issue of that it is still conjecture. {{User:Pinkyoshifan/sig}} 20:53, 26 March 2023 (UTC)
+#I strongly agree on the fact that we should stay non-speculative. However, the issue of referring to these strange cases still remain, and honestly it's really iffy in general. I'm also not to sure how we would vote without it being too bothersome and clunky in deciding what pronouns to use. {{User:GoldenDragonLeaf/sig}} 22:08, 26 March 2023 (UTC)
 ===Discussion===
+I overall agree with the proposal, but I just wanted to ask how we would vote on pronouns. I assume it can be in the page's talk page? Also, I suppose that if someone tried to change the pronouns of a page with no clear reasoning other than "I prefer them like this" it would be reverted, right? {{User:Gigi/sig}} 23:07, 24 March 2023 (UTC)
+:Yeah, talk page discussion was my idea; either that or the Discord. Changing the pronouns without consensus would be reverted. [[User:StarPunch|StarPunch]] ([[User talk:StarPunch|talk]]) 23:22, 24 March 2023 (UTC)
+If the proposal does not go through (and it looks quite close at the moment at least) then wouldn't this be a ''de facto'' writing standard ''anyway''? It would just be that it would be an unwritten rule to go by consensus on a character-by-character basis, instead of explicitly codifying it in the style document. I suppose someone could put forward a proposal to codify 'pronoun game' writing for characters with no English pronouns in official use (which for the record I would not support). {{User:WillIdleAway/sig}} 14:40, 29 March 2023 (UTC)
+:To be clear, this thought isn't to dismiss the proposal as unnecessary, but rather to say that barring 'pronoun game' guidance, some form of consensus-based conjecture may end up being the ''de facto'' solution in any case, and I only see benefit to codifying it in the style document. {{User:WillIdleAway/sig}} 14:50, 29 March 2023 (UTC)
+::I think that's my thought, yeah... We don't really have a standard in place and this seems to be a ''de facto'' rule, though I'm open to having a different option proposed. I'm definitely considering the idea that it would shift us to a conjecture-based area. [[User:StarPunch|StarPunch]] ([[User talk:StarPunch|talk]]) 12:07, 2 April 2023 (UTC)
+:If we wanted to be sure to avoid the appearance of projecting unofficial pronouns as truth, then I imagine something like {{T|Title}} but for pronouns would be a possible way of making the reader as aware as possible that the pronoun is being supposed rather than officially sourced. {{User:WillIdleAway/sig}} 05:53, 4 April 2023 (UTC)
+==Better represent how abilities can be gained from entities via categories (March 13th, 2023 - March 20th, 2023)==
+Recent edits to add sub-categories of the big [[:Category:Creatures by ability yielded|Creatures by ability yielded main category]] to basically every single entity that can give the ability in any form (either being inhaled by Kirby for enemies and mid-bosses, or for their attacks giving abilities) have caught my attention because it makes it confusing for readers to know what is going on for an enemy. And if you go to a category like [[:Category:Bomb-yielding creatures|the Bomb one]], it has a list of all kinds of entities, from games to even anime, that make it hard to understand. For example, [[Vividria]] is there, but you can get Bomb from her projectiles, not from inhaling her, so it could mislead a reader to think that if you swallow Vividria you can get Bomb. While in article text you can very easily add a note that, for example, you can only get Bomb from one of Vividria's attacks, that is not possible with categories. Thus, my proposal is to split the ability-yielding categories into two, like this:
+*'''Creatures that yield [Ability] when swallowed''' -> this creature gives the given ability when swallowed by Kirby
+*'''Creatures that yield [Ability] from projectiles''' -> this creature gives the given ability from one of their attacks or weapons, not by being swallowed by Kirby
-{{clear}}
+These names are of course subject to change (feel free to give suggestions), I would just prefer to give direct names to these categories, because from discussion about this on Discord, I noticed some people interpret "[Ability]-yielding creatures" as being from inhaled enemies already, while some see a more generic meaning to it, as in that Kirby can get the ability from the boss in some form. Now, if this proposal passes, I also think it makes sense to actually make the following category tree changes:
-==Revise image standards (sprite-based images, Virtual Console, etc.) (February 25th, 2021 - March 11th, 2021)==
+*'''Creatures by ability yielded''' -> '''Creatures by ability yielded when swallowed''' -> '''Creatures that yield [Ability] when swallowed'''
-Greetings, puffballs and others. In the past, we've had a number of discussions about what constitutes a Good game screenshot on WiKirby, and going by "native resolution" as a default rule has been the de-facto standard for some time now. However, recently, a few hiccups here and there have led me to realize that the current standards are a little too tight in places, and a little too ill-defined in others. As such, I'd like to propose an amendment to [[WiKirby:Image standards|the image standards]] by making the following the new guidelines for what constitutes a Good game screenshot:
+*'''Creatures by ability yielded''' -> '''Creatures by ability yielded from projectiles''' -> '''Creatures that yield [Ability] from projectiles'''
-=== Sprite-based games ===
+And...
-Screenshots of sprite-based games are Good if and ''only'' if they are "pixel perfect"; meaning the pixels are rendered at a 1 to 1 ratio from game to screenshot. It does not matter what is used to capture the screenshot (native console, Virtual Console, emulation, etc.), as long as this is the case. In addition, these screenshots must be clean (no visual distortions and precisely cropped for full screenshots) and ''originally'' rendered in lossless format (PNG in our case).
-Sprite-based games (along with full screenshot resolution in parentheses) consist of the following:
+*'''Creatures by ability yielded''' -> '''Creatures that yield [Ability]''' -> '''Creatures that yield [Ability] when swallowed'''
-*All [[Game Boy]] games (160x144px)
+*'''Creatures by ability yielded''' -> '''Creatures that yield [Ability]''' -> '''Creatures that yield [Ability] from projectiles'''
-*All [[Super Nintendo Entertainment System|SNES]] games (256x224px)
-*All [[Game Boy Advance]] games (240x160px)
-*All [[Nintendo DS]] games (256x192px for single screen, 256x384px for both screens)
-*''[[Kirby's Adventure]]'' (256x224px or 256x240px, depending on the way the image comes out)
-*''[[Kirby's Dream Land 2]]'' (160x144px for Game Boy, 256x224px for Super Game Boy)
-*''[[Kirby Tilt 'n' Tumble]]'' (160x144px)
-=== Non-sprite-based games, native or unofficially emulated ===
+So, basically, '''Category:Creatures by ability yielded''' would have the sub-categories '''Category:Creatures by ability yielded when swallowed''' and '''Category:Creatures by ability yielded from projectiles''', as well as sub-categories '''Creatures that yield [Ability]''' for each ability. Then each '''Creatures that yield [Ability] when swallowed''' and '''Creatures that yield [Ability] from projectiles''' would have either '''Category:Creatures by ability yielded when swallowed''' or '''Category:Creatures by ability yielded from projectiles''' as a parent category, as well as the '''Creatures that yield [Ability]''' for the respective ability.
-Screenshots of non-sprite-based games that are not being played on Virtual Console are Good if they match the native resolution of the console they were ''originally'' made for. In addition, they can be in a file format other than PNG as long as they are clean with no significant distortion.
-Non-sprite-based game screenshots should follow the standard resolution of their home consoles, as follows:
+...If this all sounds confusing, two examples: the '''Creatures that yield Fire when swallowed''' category would be a sub-category of both '''Creatures by ability yielded when swallowed''' and '''Creatures that yield Fire''', while the '''Creatures that yield Plasma from projectiles''' category would be a sub-category of both '''Creatures by ability yielded from projectiles''' and '''Creatures that yield Plasma'''.
-*[[Nintendo 64]] (320x240px or 640x480px)
-*[[Nintendo GameCube]] and [[Wii]] (640x480px or 854x480px for widescreen)
-*[[Nintendo 3DS]] (400x240px for upper screen, 320x240px for lower screen)
-*[[Wii U]] and [[Nintendo Switch]] (1280x720px or 1920x1080px)
-*[[Wii U]] Game Pad (854x480px)
-=== Virtual Console games ===
+Of course, only the "Creatures by ability yielded when swallowed" category would have an ability-neutral sub-category, as I think it would be pretty weird to note projectiles that do not give abilities with a category. And of course, if there are abilities which have no projectiles that give them (such as [[:Category:Ranger-yielding creatures|Ranger]]), we don't need to make categories for them. And finally, the "Creatures that yield [Ability] when swallowed" and the "Creatures that yield [Ability] from projectiles" categories would then be allowed to be assigned to articles, not the "Creatures that yield [Ability]" categories.
-Screenshots of games emulated using [[Virtual Console]] or any other ''official'' Nintendo emulation method can be marked as Good if and ''only'' if they match the native resolution of the console they are being played on, are clean, and are '''not''' sprite-based. They ''must'' also all be marked with the '''<nowiki>{{VC}}</nowiki>''' template (a file template marking an image as coming from Virtual Console that will be made if this proposal passes). For the sake of clarity, games that are being played on backwards-compatible devices with higher resolution (such as Wii games on Wii U) will also be treated as Virtual Console.
-That should about do it. Let me know if there are any concerns with this proposal, and I will seek to make further amendments where applicable. --[[User:Samwell|Samwell]] ([[User talk:Samwell|talk]]) 21:04, 25 February 2021 (UTC)
+So, what you do all think? If this passes, I know we will have a lot of work to reorganize the categories, but I am willing to do it. {{User:Gigi/sig}} 19:58, 13 March 2023 (UTC)
 {{Support}}
-#'''Support'''; the image standards definitely need more consistency, and this seems like a good solution. The Virtual Console template, in particular, feels like it will be incredibly useful in the long run, as we may want to provide VC screenshots later on for comparison (for example, [[Zero]]'s arena in Boss Butch). [[User:StrawberryChan|StrawberryChan]] ([[User talk:StrawberryChan|talk]]) 21:13, 25 February 2021 (UTC)
+#I personally find this to be quite a good solution. The current category ''is'' confusing, and I find that this would be a really good step in a more ''easily navigable'' direction. {{User:Astigmautism/sig}} 20:34, 13 March 2023 (UTC)
-#These changes definitely look like they would help the clarity of our policies, and a VC template is definitely a good idea to differentiate them from native shots while still being allowed on articles. -{{User:YoshiFlutterJump/sig}} 22:20, 25 February 2021 (UTC)
+# I can't think of any better names for the categories besides attempting to put the "Ability" part first so that the subcategories are innately alphabetized, but I think providing simple clarity to something as essential to Kirby as getting Abilities from swallowing enemies and projectiles is a no-brainer. The proposed distinction between projectile and creature is also currently the only split we have to account for in terms of enemies, but leaves wiggle room to add more subcategories in the future if we ever encounter a third thing that Kirby can swallow that gives an Ability that isn't the enemy or a projectile it spits out. [[User:LeoUnlimited|LeoUnlimited]] ([[User talk:LeoUnlimited|talk]]) 20:45, 13 March 2023 (UTC)
-#Clarity is good, especially with how to deal with official upscales. {{User:Pinkyoshifan/sig}} 22:24, 25 February 2021 (UTC)
+#Agreed, making it easier to tell if you get the ability from eating something or eating the thing it uses to attack you seems like a good idea, especially since [[Boss]]es can have ability-yielding projectiles but can't be swallowed at all. {{User:Pinkyoshifan/sig}} 21:29, 13 March 2023 (UTC)
-#This is a good compromise for everything we have available. Keeps things consistent, while still allowing screenshots from every console that can run each game when applicable. {{User:Gigi/sig}} 22:33, 25 February 2021 (UTC)
+#Same here. I was part of the conversation in the Discord, and more organization is always good. All in all, it definitely feels like a great step in making the wiki easier to understand for everyone. {{User:GoldenDragonLeaf/sig}} 22:46, 13 March 2023 (UTC)
-#Not much new to say from me, I agree with all changes made by this proposal, especially VC template. {{User:Superbound/sig}} 11:46, 26 February 2021 (UTC)
+# Obviously, I am in complete support of this. This should hopefully cut down on confusing the readers in the later future if this proposal becomes successful. --[[User:DarkMatterMan4500|DarkMatterMan4500]] ([[User talk:DarkMatterMan4500|talk]]) ([[Special:Contributions/DarkMatterMan4500|contribs]]) 19:52, 14 March 2023 (UTC)
-#I also don't have anything new to point out here. It sounds like a reasonable solution with consistency. This VC template also sounds like a good idea. -- {{User:MetaDragon/sig}} 07:30, 28 February 2021 (UTC)
+#I support the proposal as well. Separating the categories like that will reduce confusion and makes it clearer what Kirby can actually get the ability from. [[User:Typman|Typman]] ([[User talk:Typman|talk]]) 23:56, 14 March 2023 (UTC)
+#I think overall this is a fine way to help distinguish things, though it should naturally come with appropriate changes to the infoboxes to help delineate the difference as well, since categories really only tend to get used by wiki regulars. --[[User:Samwell|Samwell]] ([[User talk:Samwell|talk]]) 17:19, 17 March 2023 (UTC)
 {{Oppose}}
 {{Neutral}}
 ===Discussion===
-:I see that KDL2 has a specific rule about SGB. I think this one needs to be cleared up. Should we include the KDL2-specific border from SGB when making screenshots in SGB? Also note that a real Game Boy would only run KDL2 in monochrome, and without any border, therefore screenshots like [[:File:KDL2 Dark Matter Appears.png|this one]] are inaccurate, since it is colored and doesn't show any SGB border. So my point is, should we still allow SGB screenshots of KDL2 without the border? If so, then I don't see the point of allowing SNES resolution for KDL2. [[User:pandakekok9|pandakekok9]] ([[User talk:pandakekok9|poyo]]) 14:52, 28 February 2021 (UTC)
+Just one note that I ended up realizing recently: for cases where neither categories would work, like [[Scarfy]] giving [[Crash]] only via [[Copy]], we can make specific categories; in this case specifically, '''Creatures that give Crash exclusively via Copy''', and it won't even just have Scarfy, it will also have [[Mister Anglep]]. If anyone can think of other specific cases for which the categories I originally proposed wouldn't cover, feel free to post them here. {{User:Gigi/sig}} 12:43, 15 March 2023 (UTC)
-::Keep in mind that the stated resolution applies only to ''full'' screenshots, and that an image can still be marked as Good if it crops out unnecessary detail (as is often done to highlight specific characters or objects). So, for Super Game Boy screenshots, it is okay to crop out the border if there is no need to show it. --[[User:Samwell|Samwell]] ([[User talk:Samwell|talk]]) 16:01, 28 February 2021 (UTC)
-:::Okay, that cleared that up for me, thanks. [[User:pandakekok9|pandakekok9]] ([[User talk:pandakekok9|poyo]]) 02:36, 1 March 2021 (UTC)
-:Regarding SNES games, screenshots coming from ''[[Kirby's Toy Box]]'' were all 256×239 (which is one of [[wikipedia:Super Nintendo Entertainment System#Video|valid resolutions]], mind the odd number), and all screenshots on the 'net are this resolution too. I followed [[:File:KTB Pinball.png|Pandakekok9's first upload]] and cropped all 8 currently uploaded screenshots to 256×224 manually since I couldn't find a way to emulate at this height. Should this be a valid alternative resolution? —[[User:Viperision|Viperision]] ([[User talk:Viperision|talk]]) 17:30, 2 March 2021 (UTC)
 {{clear}}
-::''Kirby's Toy Box'' is a sprite-based game, so just use whatever resolution you need to keep a full screenshot pixel perfect. --[[User:Samwell|Samwell]] ([[User talk:Samwell|talk]]) 17:46, 2 March 2021 (UTC)
-==What to do with bigger but JPG images and smaller but PNG images (February 22, 2021 - March 8, 2021)==
+==Dream Friends pages' colored titles, revisited (March 4th, 2023 - March 18th, 2023)==
-There are plenty of images on this wiki, which also includes artwork. As many may know, PNG is the best for artwork, however, sometimes it isn't the largest one available, like with ''Kirby 64'' Cilly...
-[[File:Chilly K64 artwork.jpg|500px]]
+Two years ago, [[WiKirby:Proposals/Archive-2021#Add Colored Titles to Dream Friend Pages (January 19th, 2021 - February 2nd, 2021)|a proposal]] was made to give featured [[Dream Friend]]s articles a special treatment by making their page titles colored. The reasoning for that was, that important characters deserve having their pages be unique and that it would be a nice, little detail. However, there are few problems as of currently.
-[[File:K64 Chilly Transparent Artwork.png|500px]]<br>
-(left - JPG, right - PNG)
-...or ''Air Ride'' Warpstar.<br>
+First, the proposal only affected Dream Friends, who at the time were basically synonymous with "major character". But then the next game came along with [[Elfilin]]. Under what was established in the proposal, his article can't get a special color, solely because he had the unluck to debut in a game after ''Kirby Star Allies''. And the ''Kirby'' series will still continue, and more characters will appear... It was not future-proof.
-[[File:WarpstarKAR.jpg|500px]]
-[[File:KAR Warpstar Small.png|500px]]<br>
-(left - JPG, right - PNG)
-Significant drop in resoltiuon. On the other hand, images aren't that often used to be this large, and most of them are in galleries in following size:
+Second, the inconsistency. I don't believe that featured articles should be divided into better and worse just because they happen to cover a certain topic, and colored titles make that division. In addition, a lot people are confused on why some pages get that treatment and some don't--that's certainly not helpful either.
-<gallery>
-Chilly K64 artwork.jpg|OH NO, COULD IT BE&ndash;
-K64 Chilly Transparent Artwork.png|WARPSTARS?!
-WarpstarKAR.jpg|lmao they r scared of us
-KAR Warpstar Small.png|ha ha silly snowguys
-</gallery>
-As you can see, it's hard to note a difference in quality, but transparency works better here.
+So, my solutions are:
+* '''Option 1: Give every Featured page special color''' (that would be my preferred)
+* '''Option 2: Make every Featured page white''' (opposite of Option 1)
+* '''Option 3: Revert to how it was before the 2021 proposal''' (Kirby had pink title font, everything else white)
+* '''Option 4: Give special color to every major character, not just Dream Friends''' (if the first issue is a concern but not the second)
+* '''Option 5: Do nothing''' (it's fine as it is)
-So what do we do?
+{{User:Superbound/sig}} 12:07, 4 March 2023 (UTC)
-*'''List both''' - In case something like this happens, both images will be displayed, with caption like "Smaller but transparent version od a previous artwork"
-*'''PNG > JPG''' - Favor smaller PNG over bigger JPG.
-*'''JPG > PNG''' - Inverted version of above.
-*'''Case-by-case basis (so nothing changes)''' - This is oversimplifaction of something complicated, and each case like that should be reviewed seperatly.
-{{User:Superbound/sig}} 18:56, 22 February 2021 (UTC)
+{{Option|1|Give every Featured page special color}}
-===<u>List both</u>===
+#At this point it just makes sense to give colors to featured articles as we wish. We could perhaps try to find some sort of rules but ultimately I think we can do our own call. And we can keep some others as white anyway when there is no color to represent the article really. {{User:Gigi/sig}} 15:24, 4 March 2023 (UTC)
-#This has been my de-facto way of handling this artwork, so I'll go with this option. --[[User:Samwell|Samwell]] ([[User talk:Samwell|talk]]) 19:45, 22 February 2021 (UTC)
+#Per the reasons given. My second choice would be Option 4, but I don't really think that exclusively characters should get this treatment. This would most likely leave out Ability pages, like [[Beam]], and having that be orange-colored would be neat. Now, this do would leave out music and game pages, and while I kinda see why one would want that, having them colored would look good. There are games that kinda follow a color motif: ''[[Kirby's Return to Dream Land]]'' could have its title blue, while ''[[Kirby Battle Royale]]'' could have its in orange, for example. And as Gigi said, if giving some color to a page ends up being in some mess, we can just choose to keep that one white and that's it, we don't need to set in stone to have absolutely every featured page colored, but also it would be good to have the option to color some non-character page if it seems good. {{User:Zolerian Yuviaflero/sig}} 08:26, 6 March 2023 (UTC)
-#Listing both means keeping both. In the worst-case scenario, convert a JPG to PNG (and upload to same filepage) to preserve both versions. —[[User:Viperision|Viperision]] ([[User talk:Viperision|talk]]) 20:18, 22 February 2021 (UTC)
-#Second choice. {{User:Obsessive Mario Fan/sig}} 19:41, 27 February 2021 (UTC)
-===<u>PNG > JPG</u>===
+{{Option|2|Make every Featured page white}}
+#Since applying the special font to all Dream Friends without them all being featured is apparently unfeasible, I'm going with this as I'd rather keep things consistent. Giving every featured page colours would inevitably make determining colour hard in some cases and would look arbitrary to anyone not familiar with it, and giving all major characters colours is similarly a bad idea because if we aren't using the objective definition of "Dream Friends + Elfilin" (which I agree isn't future-proof), then there'll be difficulty determining which characters do and don't count as major. I'm also not voting for the third option as if we aren't doing this for any other character then I don't see a reason for Kirby to get special treatment - an all or nothing approach would be better for the sake of consistency. [[User:Hewer|Hewer]] ([[User talk:Hewer|talk]] &middot; [[Special:Contributions/Hewer|contributions]]) 21:01, 4 March 2023 (UTC)
+#After thinking it over, I think this will be my choice. I'm not the biggest fan of how the special colors turned out and I don't like the inconsistency. I think it would look cleaner to just keep the title font with no special color for featured pages. [[User:StarPunch|StarPunch]] ([[User talk:StarPunch|talk]]) 22:13, 5 March 2023 (UTC)
+#I would be fine with any of the first three options, just because we should be consistent. If consistency means giving everyone special colors or nobody special colors (except possibly for the namesake of the entire series) that would be ok, although I slightly favor no colors since choosing colors for every featured article could get tricky. {{User:Pinkyoshifan/sig}} 12:54, 7 March 2023 (UTC)
+{{Option|3|Revert to how it was before the 2021 proposal}}
+#"''I want to emphasize that this creates an even larger inconsistency amongst page design and it's one that I would drastically prefer to not exist''"—Jegman 2021. It looked terrible from the moment it was implemented and should never have gone forward to begin with. Revert pre-2021. [[User:Trig Jegman|Trig Jegman]] - 15:15, 4 March 2023 (UTC)
+{{Option|4|Give special color to every major character, not just Dream Friends}}
+#I like this option. The colors truly ''characterize'' them, I feel that they make the articles feel more alive. As said above, some characters are too recent to have enough significant appearances, but it would feel fair if all relevant enough protagonists (maybe antagonists) had their own color. Colorless is just a bit bland, and coloring ''all'' featured pages would require some thought and become almost entirely subjective in a matter of seconds... [[User:ShadowKirby|ShadowKirby]] ([[User talk:ShadowKirby|talk]]) 20:41, 4 March 2023 (UTC)
+#I also like this option; it gives the relevant articles a little bit of ''flair'' (e.g., having [[Elfilin]] have blue text would signify that he is a major character in the series). We may need to define what a "significant character" is, however, so there is some consistency in when this is applied (both now and in the future). As noted above, colouring every featured page would likely be quite burdensome. [[User:Buildz17|Buildz17]] ([[User talk:Buildz17|talk]]) 21:40, 4 March 2023 (UTC)
+#It always confused me with the special titles for certain Dream Friends but not all of them, not to mention that characters from side games don't even get a chance at all. By having major characters with special colors, it helps to differentiate them from other character pages while also keeping in theme. Also, this option would help with consistency, without having to go through every single featured page. All in all, I just think it's an execellent idea without being too much work. {{User:GoldenDragonLeaf/sig}} 05:51, 5 March 2023 (UTC)
+#It shouldn't be a big hassle to put together a definitive 'major character' list, games-wise (we still have anime characters), as they come. Giving color to all articles would be an overkill and create an inconsistent mess, while no color would deprive the wiki of its creative and fun character. Focusing just on Dream Friends is ''KSA''-centric. {{User:Vipz/sig}} 11:21, 5 March 2023 (UTC)
+#I'd really like if this happens, as this would further show the importance of certain characters, especially major antagonists and final bosses like Hyness and Void Termina, although I don't know if this would be applied to EX versions with their own pages too. {{User:RHVGamer/sig}} 21:31, 5 March 2023 (UTC)
+#Since only featured articles get the special title font, this prevents the scope of 'characters sufficiently major enough to get coloured titles' from becoming too insane, and I suspect a process can be navigated much more easily for deciding title colours for character articles compared to articles in greater generality. {{User:WillIdleAway/sig}} 04:12, 10 March 2023 (UTC)
+#I like this idea a lot!! Kirby will continue to exist through a variety of media and have characters that are noteworthy exist outside of just mainline games, and I believe that giving others a bit more of a chance to be recognized as such while also allowing for future characters to be introduced and given the same treatment is a better option than resorting to reverting everything. Also, I just find nice to have recurring characters use a special font. It's redundant, but it ''does give them a lot of character.''{{User:Astigmautism/sig}} 20:27, 13 March 2023 (UTC)
+{{Option|5|Do nothing}}
-===<u>JPG > PNG</u>===
+===Discussion===
+Personally I like the idea of the title colours for the unique extra flair they provide, but the part that bothers me most is that only featured articles can get this treatment. Given that these colours are based entirely on the subjects of the articles, I don't think featured status should make a difference at all, and yet [[Marx]], [[Gooey]], [[Ribbon]], and all three Mage-Sisters are excluded by this requirement. The title colour isn't even applied consistently among articles that ''are'' featured since it's missing from [[Rick]], [[Kine]], and [[Coo]] for some reason. So my ideal solution would be to just consistently apply these title colours to all Dream Friends (as well as Elfilin by the logic I explained [[Talk:Elfilin#Title colour|here]]) regardless of featured status. [[User:Hewer|Hewer]] ([[User talk:Hewer|talk]] &middot; [[Special:Contributions/Hewer|contributions]]) 15:10, 4 March 2023 (UTC)
-===<u>Case-by-case basis (so nothing changes)</u>===
+:The reason why only featured articles get this treatment is simply because they are the only articles that use the special title font. {{User:Gigi/sig}} 15:25, 4 March 2023 (UTC)
-#It is heavily redundant in my opinion to use the same image twice for things, but that said, I think that is truly situational about the image's quality overall. In more instances than not, a JPG is usually larger and cleaner, and despite having a background, is easier to make out. JPGs are also usually better to avoid situations [https://cdn.discordapp.com/attachments/813529368802492416/813529397415247872/Cripes.png Like this] where transparency in images doesn't always look good, especially for dark mode nerds like myself. In other circumstances, the PNG may be a higher quality despite being smaller, and would look better in both galleries AND infoboxes, where JPGs ''generally'' only look good in galleries. I would stress that both have their advantages and disadvantages, and if an editor isn't sure, they can either bring it up on discord or upload both and allow the community to decide. [[User:Trig Jegman|Trig]] - 22:04, 22 February 2021 (UTC)
+::I'm suggesting that the Dream Friend articles (and Elfilin) be an exception to that if we continue to use special colours, because I think it's too inconsistent and doesn't make much sense to restrict a distinction with no relation to article quality (or at least one that really should have no relation to article quality since it only concerns the article's subject) to featured articles. [[User:Hewer|Hewer]] ([[User talk:Hewer|talk]] &middot; [[Special:Contributions/Hewer|contributions]]) 18:16, 4 March 2023 (UTC)
-#PNGs are only different enough than JPG (from a visual standpoint, at least) to where we should only replace JPG with PNG the PNGs have transparent backgrounds or if the JPG is smaller than or equal in size to the PNG. So basically, (in my opinion) if the JPG is bigger and the PNG isn't transparent, then use JPG. Otherwise, use PNG. {{User:Pinkyoshifan/sig}} 22:09, 22 February 2021 (UTC)
+:::Then that would have to be a separate proposal because, as of right now, the title font is only applied to featured articles, and we cannot just use it for other articles to have colored titles. Plus, the argument that was made in the original proposal is that all Dream Friend pages should eventually be featured, which I don't disagree with. {{User:Gigi/sig}} 20:46, 4 March 2023 (UTC)
-#Agreed on case-by-case. PNG isn't always automatically better than JPG and vice-versa; it's ultimately down to the image itself. Generally a PNG with a transparent background is most preferable for an infobox, while a JPG can look fine if a transparent version of the image isn't available. Listing both seems redundant to me. [[User:StrawberryChan|StrawberryChan]] ([[User talk:StrawberryChan|talk]]) 03:40, 24 February 2021 (UTC)
-#I've been thinking and I'm going to go with case-by-case here. These cases seem rare from what I've seen, and generally it's better to have both, but it really depends on the case. Rather than make a very black and white rule for a situation that doesn't happen that often, I would rather keep it case-by-case. {{User:Gigi/sig}} 16:07, 24 February 2021 (UTC)
-#As cases are not unified, neither should our solution. Enough said. {{User:Kirb/sig}} 04:06, 25 February 2021 (UTC)
-#I honestly can't add any more to what's already been said. PNG is not inherently superior to JPG or vice versa, and it really comes down to the individual quality of the images. -{{User:YoshiFlutterJump/sig}} 21:58, 25 February 2021 (UTC)
-#I think PNGs are generally better than JPGs, but if we have a JPG that's tranparent, we should include both. {{User:Obsessive Mario Fan/sig}} 19:41, 27 February 2021 (UTC)
-#JPGs are usually inferior to PNGs, but it all comes down to the quality of the image itself since that isn't always the case. Having a hard rule for PNG over JPG or vice-versa would be a bit too tight and would likely do some damage to the overall quality of our images. Listing both is a better alternative to that, but as stated above, due to redundancy, that probably would not be the best option here. Therefore, in my opinion, this should be done case-by-case. -- {{User:MetaDragon/sig}} 07:30, 28 February 2021 (UTC)
-===Neutral Comments===
-#Superbound your captions are funny :p. {{User:Kirb/sig}} 22:13, 22 February 2021 (UTC)
-===Discussion===
-:To respond to Viperision, I would '''intensely''' affirm that images should ''never ever not ever'' be converted from lossy to lossless or lossless to lossy, as it entirely butchers the quality of the image and is generally entirely ineffective at comparing multiple images. There is no harm to having two images and one being deleted, as mentioned in my vote. [[User:Trig Jegman|Trig]] - 22:04, 22 February 2021 (UTC)
-::JPG to PNG is this "worst-case scenario" in order to (if listing both is not a viable option, which I doubt) attempt to preserve two versions of same artwork. It's still valid to try conversion, investigate whether CMYK to RGB butchered anything, and decide to (not) upload. My "list both" vote regards cases where both (JPG and PNG) versions have valid advantages, in order to ''not'' have a perfectly fine transparent but smaller PNG version be deleted, and vice-versa for larger JPG versions. For wiki's display purposes it may not be all that important and most users will likely not notice another version preserved in file logs, so definitely list both and '''don't bother''' with conversion. —[[User:Viperision|Viperision]] ([[User talk:Viperision|talk]]) 20:17, 28 February 2021 (UTC)
 {{clear}}
-==Reform [[WiKirby: Abbreviations]] (January 23, 2021 - February 6, 2021)==
+==Delete spam account talk pages 020823—022223==
-Alright. You remember the Great Debate we had on [[WiKirby talk:Abbreviations]]? This is where we put that into effect.
+I think we should delete the welcome template-only talk pages of obvious bot/spam accounts. There is no need to have pages for accounts that clearly will not edit the site or be used again, and it may make searching for valuable talk pages difficult in Special:AllPages. Given the current way WiKirby handles new accounts, this number of account talk pages should not increase. My criterion for deletion would be the following:
+<pre>
+*User names must follow the following format:
+FirstnameLastname
+or
+FirstnameLastnameNumbers
-Let me get this out of the way. The purpose of the abbreviation policy page is to standardize naming patterns for filenames. And that's where it miserably fails. More than one abbreviation per game? Abbreviations for consoles and Kirby Super Star subgames? ''Abbreviations for characters that no one will ever use?'' Yeah, let's fix that.
+*There are no contributions for the user.
-I propose we completely rewrite the abbreviations list and only use the following abbreviations:
+*There is no main user page
-Kirby's Dream Land - KDL<br>
+*The talk page consists solely of the welcome message.
-Kirby's Adventure - KA<br>
-Kirby's Pinball Land - KPL<br>
-Kirby's Dream Course - KDC<br>
-Kirby's Dream Land 2 - KDL2<br>
-Kirby's Avalanche - KAv<br>
-Kirby's Block Ball - KBBa<br>
-Kirby's Toy Box - KTB<br>
-Kirby Super Star - KSS (as determined by discussion)<br>
-Kirby's Star Stacker (Game Boy) - KSSGB<br>
-Kirby's Dream Land 3 - KDL3<br>
-Kirby's Star Stacker (SNES) - KSSS<br>
-Kirby 64: The Crystal Shards - K64<br>
-Kirby Tilt 'n' Tumble - KTnT<br>
-Kirby: Nightmare in Dream Land - KNiDL<br>
-Kirby Air Ride - KAR<br>
-Kirby & The Amazing Mirror - KaTAM<br>
-Kirby: Canvas Curse - KCC<br>
-Kirby: Squeak Squad - KSqS<br>
-Kirby Super Star Ultra - KSSU<br>
-Kirby's Epic Yarn - KEY<br>
-Kirby Mass Attack - KMA<br>
-Kirby's Return to Dream Land - KRtDL<br>
-Kirby's Dream Collection Special Edition - KDCSE<br>
-Kirby: Triple Deluxe - KTD<br>
-Kirby Fighters Deluxe - KFD<br>
-Dedede's Drum Dash Deluxe - DDDD<br>
-Kirby and the Rainbow Curse - KatRC<br>
-Kirby: Planet Robobot - KPR<br>
-Team Kirby Clash Deluxe - TKCD<br>
-Kirby's Blowout Blast - KBBl<br>
-Kirby Battle Royale - KBR<br>
-Kirby Star Allies - KSA<br>
-Kirby's Extra Epic Yarn - KEEY<br>
-Super Kirby Clash - SKC<br>
-Kirby Fighters 2 - KF2<br>
-Super Smash Bros. series - SSB<br>
+*The account is older than Jan 1, 2021.
-Super Smash Bros. - SSB64<br>
+</pre>
-Super Smash Bros. Melee - SSBM<br>
-Super Smash Bros. Brawl - SSBB<br>
-Super Smash Bros. for Nintendo 3DS / Wii U - SSB4<br>
-Super Smash Bros. for Nintendo 3DS - SSB4-3DS<br>
-Super Smash Bros. for Wii U - SSB4-WiiU<br>
-Super Smash Bros. Ultimate - SSBU<br>
-Kirby: Right Back at Ya! - KRBaY
-What say you all? Vote below or voice any suggestions you may have. -{{User:YoshiFlutterJump/sig}} 21:59, 23 January 2021 (UTC)
+I'd be happy to make a list and hand it to admin team or temporarily regain my admin role wiki-only and do it myself, whichever is more comfortable for staff. [[User:Trig Jegman|Trig]] - 19:35, 8 February 2023 (UTC)
-{{Support}}
+{{Option|1|Support—Continue as listed}}
-#I say yes, as we need more consistent abbreviations.{{User:Kirb/sig}} 22:01, 23 January 2021 (UTC)
+#Unnecessary pages should be deleted.{{User:Kirb/sig}} 01:42, 10 February 2023 (UTC)
-#I've no issue with this set of abbreviations, as I believe we've done a more than adequate job of ironing them all out. I am looking forward to having a consistent set of abbreviations on the wiki for file naming purposes. --[[User:Samwell|Samwell]] ([[User talk:Samwell|talk]]) 22:02, 23 January 2021 (UTC)
+#It seems like a waste of space to include those pages, so why not delete them? Seems logical to me. [[User:GoldenDragonLeaf|GoldenDragonLeaf]] ([[User talk:GoldenDragonLeaf|talk]]) 03:41, 10 February 2023 (UTC)
-#Abbreviations being inconsistent is a major problem that needs to be fixed. This fixes that, so support. {{User:Pinkyoshifan/sig}} 22:03, 23 January 2021 (UTC)
+#Sounds good to me. Would we unregister the users themselves, too? Because I think that would be a good way to free up usernames. {{User:DeepFriedCabbage/sig}} 06:00, 10 February 2023 (UTC)
-#Support. I'm guilty of adding a lot of the superfluous abbreviations myself, and it's better to be concise and consistent. [[User:StrawberryChan|StrawberryChan]] ([[User talk:StrawberryChan|talk]]) 01:06, 24 January 2021 (UTC)
+#A really small, but imho good thing that would have its benefits should it come into action, even if it is not the grandest change ever. [[User:Infinite Possibilities|Infinite Possibilities]] ([[User talk:Infinite Possibilities|talk]]) 17:22, 12 February 2023 (UTC)
-#The abbreviations chosen above should do well, and having consistency would be a good idea, so I support. -- {{User:MetaDragon/sig}} 21:08, 24 January 2021 (UTC)
+#I was initially hesitant about the idea of having to manually go through all these page deletions, but it seems that we have the means to sort out and then delete them quickly, so I'll throw my support behind this. Shouldn't be too much trouble. --[[User:Samwell|Samwell]] ([[User talk:Samwell|talk]]) 23:32, 19 February 2023 (UTC)
-#Abbreviations are looking really simple and clean for file naming, so I'm on the support side. [[User:Hexelectron|Hexelectron]] ([[User talk:Hexelectron|talk]]) 10:14, 25 January 2021 (UTC)
+<br clear=all>
-#Consitency is good and all that. {{User:Superbound/sig}} 18:34, 25 January 2021 (UTC)
+{{Option|2|Support, but devise stricter criteria for deletion}}
-#Best to have only one abbreviation per game, and the choices are all good. {{User:Gigi/sig}} 18:56, 27 January 2021 (UTC)
+<br clear=all>
-#Only having one abbreviation per game brings more consistency which is a good thing. And the choices are the most common abbreviations for their respective games.[[User:Infinite Possibilities|Infinite Possibilities]] ([[User talk:Infinite Possibilities|talk]]) 14:04, 30 January 2021 (UTC)
+{{Option|3|Do Nothing}}
-{{Oppose}}
+<br clear=all>
 {{Neutral}}
+#I don't think it would be bad to do it, but I don't see any real benefit when AllPages isn't the way most people look for user talk pages and this doesn't really help clear up anything else as far as I know. {{User:Pinkyoshifan/sig}} 12:27, 9 February 2023 (UTC)
+#I agree with the vote above. It's a good idea, but not really necessary as it's only getting rid of one thing and doesn't change much else. {{User:Starvoid/sig}} 01:24, 10 February 2023 (UTC)
+#This seems like a good idea, but I don't know, it doesn't convince me. I don't really have any reasons to oppose it though. {{User:Zolerian Yuviaflero/sig}} 19:51, 12 February 2023 (UTC)
+#<s>I guess I don't really see the need for this to be a proposal, as it's not that big of an issue (in the specific case of AllPages, you can just search for user pages rather than user talk). Deleting them isn't going to save any real amount of space, either. Also, I just don't really see how going through the labor of deleting all those talk pages will help the wiki in the long run. If you have a nifty way of automating the process without targeting the pages of legitimate users, then I might consider supporting, but otherwise, it just seems like empty busywork. --[[User:Samwell|Samwell]] ([[User talk:Samwell|talk]]) 19:44, 13 February 2023 (UTC)</s>
+<br clear=all>
 ===Discussion===
-==Add Colored Titles to Dream Friend Pages (January 19th, 2021 - February 2nd, 2021)==
+{{clear}}
-The title of the Kirby page uses a custom color for the font, pink. As of [[Kirby Star Allies]], each of the delineated [[Dream Friend|Dream Friends]] were given a specific color for their name and two colors for the background of their summon screen. I propose that we add a custom color to the titles of the Dream Friend pages. While there could be some debate for which colors to use, I think the colors used specifically for the character's names makes the most sense. My logic is, we have specific colors associated with each of the Dream Friends, and a method of adding color to individual page titles. It would be a fun visual flair for characters highlighted as important to the series. The only drawback currently is that the special font that [[Kirby|Kirby's]] page uses isn't currently on every Dream Friend's page, as the font is used exclusively for featured pages. That being said, we could vote to add the color once each character's page gets featured, and add color to the ones that are currently using the font. Either way, it would be a nice use of the (at the time of posting this proposal) new font's color feature, and exemplify a little bit of extra trivia from the Kirby series. [[User:LeoUnlimited|LeoUnlimited]] ([[User talk:LeoUnlimited|talk]]) 02:55, 20 January 2021 (UTC)
-{{Support}}
-#I support this; it'd be a cute detail. I could work out the colors for each of them once this passes and they're featured. [[User:StrawberryChan|StrawberryChan]] ([[User talk:StrawberryChan|talk]]) 02:58, 20 January 2021 (UTC)
-#I concur, granted we can get all the Dream Friend articles featured. After all, would be a shame to add the color to a page that was not up to snuff. --[[User:Samwell|Samwell]] ([[User talk:Samwell|talk]]) 03:05, 20 January 2021 (UTC)
-#Colors, colors, everywhere, I want them on the names all around. And that gives me a huge support, for they are super ultra astound! On a serious note, however, that's a nice little detail and I'd like that, especially if Kirby's title color is pink. [[User:Hexelectron|Hexelectron]] ([[User talk:Hexelectron|talk]]) 03:07, 20 January 2021 (UTC)
-#Yes. Color good. Much add.{{User:Kirb/sig}} 03:08, 20 January 2021 (UTC)
-#I feel that, since we do this for Kirby, it's only fair we do it on Dedede, Meta Knight, and Bandana Waddle Dee as well. And I'm certainly not opposed to doing it for the other Dream Friends, too. -{{User:YoshiFlutterJump/sig}} 03:18, 20 January 2021 (UTC)
-#It would be a nice touch to the Dream Friend articles, and it will do no harm, so I support. -- {{User:MetaDragon/sig}} 05:50, 20 January 2021 (UTC)
-#It would be a nice touch, but we should only use the special font if it's already an FA, and instead just colorize the preexisting font if not. {{User:Pinkyoshifan/sig}} 12:59, 20 January 2021 (UTC)
-#I also support this, even if as of right now most Dream Friend articles aren't featured; the ones that are at least deserve some color. {{User:Gigi/sig}} 17:32, 20 January 2021 (UTC)
-#I support this; it would add more variety to the article titles. Hopefully we can get all the Dream Friend articles featured so they can all have colorful titles. {{User:Obsessive Mario Fan/sig}} 18:58, 20 January 2021 (UTC)
-#I don't see anything speaking against it. It would set them apart more from regular articles and is a cute asthetic. [[User:Infinite Possibilities|Infinite Possibilities]] ([[User talk:Infinite Possibilities|talk]]) 16:26, 23 January 2021 (UTC)
-{{Oppose}}
-#I would prefer plain white over other col{{o}}r, but that's not the main reason I'm opposing. I don't like how the proposal affects only Dream Friends. Other featured characters should be treated as equal, as they are (mostly) the same but still high quality. {{User:Superbound/sig}} 18:34, 25 January 2021 (UTC)
-#I doubt that this changes the end impact, but I want to emphasize that this creates an even larger inconsistency amongst page design and its one that I would drastically prefer to not exist. [[User:Trig Jegman|Trig Jegman]] - 14:47, 26 January 2021 (UTC)
-#It works for Kirby since it's pinkish on pink background, however looking at most Dream Friends' main colors I'm can't imagine they would work as text color (except for Meta Knight and blue at some extent). Take King Dedede (blue, yellow, red) and Daroach (grey, red) for example. It would also create inconsistency and some people prefer less (clashing) colors. —[[User:Viperision|Viperision]] ([[User talk:Viperision|talk]]) 10:18, 2 February 2021 (UTC)
-#Thinking about it, I'm more convinced by the opposition here, than the supporters above. Consistency is important. --[[User:pandakekok9|pandakekok9]] ([[User talk:pandakekok9|poyo]]) 10:46, 2 February 2021 (UTC)
-{{Neutral}}
-===Discussion===
+==Solidifying character names and attributes in article writing (January 29th, 2023 - February 12th, 2023)==
-If the proposal passes, why don't we go full aetjic and color other things in the pages, like tables? {{User:Superbound/sig}} 18:34, 25 January 2021 (UTC)
+So, I've noticed recently that there's been some edits made to character and enemy pages in regards to gender pronouns. In particular, there was a push on the [[Kracko]] and [[Dyna Blade]] pages to refer to them by different genders based on which game was being discussed (since genders are not always consistent in in-game flavor text). I find this to be highly inappropriate for any characters that have been established as individuals (unlike, say, [[Broom Hatter]], which refers more to a class of characters rather than a single entity). This incident has brought up a larger issue with how to treat attributes of characters and other entities which span multiple games and whose names and other characteristics may differ from one to the next. I come to you now offering a new standardized way to handle this, though it needs to be done in multiple facets which can be voted on individually. I will introduce each particular point and describe the proposed change in its own subsection. Cheers. --[[User:Samwell|Samwell]] ([[User talk:Samwell|talk]]) 14:36, 29 January 2023 (UTC)
-:Perhaps a few col{{o}}rful touches to the wiki could do nicely, but we mustn't make anything too col{{o}}rful since I know there are plenty of users who wouldn't take very kindly to vivid col{{o}}rs. -- {{User:MetaDragon/sig}} 04:58, 30 January 2021 (UTC)
-::I think it's important that this doesn't open the floodgate to full inconsistency for the sake of playful design. This is about the upper limit, in my opinion. I can definitely see the reasoning against doing so, and keeping it solely to Dream Friends is important with regards to establishing a boundary. [[User:StrawberryChan|StrawberryChan]] ([[User talk:StrawberryChan|talk]]) 12:22, 2 February 2021 (UTC)
-Though the proposal has technically passed, I would like to show some examples of colored title text: [https://wikirby.com/w/index.php?title=King_Dedede&oldid=194842 King Dedede], [https://wikirby.com/w/index.php?title=Meta_Knight&oldid=194844 Meta Knight], and [https://wikirby.com/w/index.php?title=Bandana_Waddle_Dee&oldid=194843 Bandana Waddle Dee]. These are based on the two-tone colors used by their [https://cdn.discordapp.com/attachments/323530530681520129/806645608885649448/unknown.png Dream Friend] icons. Any thoughts before the full go-ahead? [[User:StrawberryChan|StrawberryChan]] ([[User talk:StrawberryChan|talk]]) 22:31, 3 February 2021 (UTC)
+===Change 1: Solidifying character gender===
-{{clear}}
+To summarize what was said above, I believe we need a clause in place to prevent established characters from being referred to by different genders in text based on erroneous or inconsistent in-game flavor text. As such, I'd like to add this to the writing standards:
-==Replacing the image-based title font (January 5th, 2021 - January 19th, 2021)==
+"For characters established as individuals, their gender must be consistent throughout article text and based on the most consistently-used pronouns in games ("he/she/they" generally takes priority over "it"). It is not appropriate to refer to these characters using different pronouns based on the game unless there is a specific special story or lore-based circumstance for doing so. Note that this rule does not apply across different [[canon]]s (For example, [[Kracko]] in the games VS. Kracko in the [[Kirby: Right Back at Ya!|anime]].), only within canons."
-This has been a bit overdue, and I'm not really sure how detailed this needs to be, but I'll go ahead and do my best to explain it. Basically, the "[[Help:Title font (old)|title font]]" (currently used for the titles of featured articles, as well as a few odds and ends like the old home page) is based the font from ''Kirby's Dream Collection'' and works by using individual sprites of each letter, which are then converted from text to images. Aside from being somewhat slow and inefficient, this presents a major problem for those who use screen readers: since the title font is not an actual font, the screen reader will not read the title properly, thus resulting in missing information for people with blindness or visual disabilities. This isn't an insignificant portion of people, so it can't just be ignored.
-The solution was to find a way to convert the title font to an actual font rather than images. While the actual font, Pop Happiness, is free to download for personal usage, using it in commercialized work requires an expensive license, and since the wiki has ads running, this is not feasible. We were able to find a workaround by using a free substitute, Delfino, which is based on the same font (it's traced from the dialogue in ''Super Mario Sunshine'', hence the name). It's not a perfect recreation, but it gets the job done, and solves the above problem as well as looking cleaner in close-up. Delfino has been implemented on the wiki's server and is currently being used on the main page. There is already a template ready to go, so the final step is properly implementing it across the wiki.
+{{Support}}
+#Kracko: "While <u>his</u> pause screen flavor from ''[[Kirby Fighters Deluxe]]'', implies that <u>he</u> fights Kirby to get a comeback for <u>his</u> previous losses, however, in ''[[Kirby: Triple Deluxe]]'', <u>it</u> appears <u>it</u> attacks Kirby because of Taranza's command." <= possible shenanigans that could occur with changing pronouns by appearance. Thus, I support to make it an official rule. {{User:Superbound/sig}} 15:37, 29 January 2023 (UTC)
-'''Image-based title font:'''
+#I 100% agree with this. I was looking at the [[idle animation]] page and noticed that Driblee was referred to with female pronouns, while on the actual [[Driblee]] page the enemy is referred to with it as pronouns. And it doesn't help that Driblee is referred to with all types of pronouns as well. [[User:GoldenDragonLeaf|GoldenDragonLeaf]] ([[User talk:GoldenDragonLeaf|talk]]) 03:42, 30 January 2023 (UTC)
+#Agreed. The devs being inconsistient doesn't mean that we need to be inconsistient. {{User:Pinkyoshifan/sig}} 16:00, 30 January 2023 (UTC)
+#I support consistency and clarity, regardless of minor developer errors. Both the first and second parts of this proposal will prevent readers from becoming confused. {{User:Kirb/sig}} 17:52, 4 February 2023 (UTC)
+#At first I was worried that in some cases two or more pronouns would be used simultaneously back and forth between games, ([[Broom Hatter]] comes to mind), and so we wouldn't be able to decide which one should appropriately be used. The more I thought about it the more I realized that wouldn't happen all that often, but it still could be a concern so I will bring it up in the discussion here. Aside from that, this will definitely be good to help prevent confusion and I'm all for it. -- {{User:Jellytost♡/sig}} 22:47, 4 February 2023 (UTC)
+#I prefer to keep things consistent. {{User:Yoshi's Island/sig}} 11:18, 8 February 2023 (UTC)
+{{Oppose}}
+{{Neutral}}
+#I don't think enough guidelines are set for me to warrant voting on this. There may be cases where use is too inconsistent to officially suggest one path or another. [[User:Trig Jegman|Trig]] - 16:15, 30 January 2023 (UTC)
+#For what it's worth, I don't feel like this particular issue "deserves" a strict guideline. As Trig said, cases of great inconsitency, which I consider to be fairly likely, could arise. [[User:Infinite Possibilities|Infinite Possibilities]] ([[User talk:Infinite Possibilities|talk]]) 20:16, 4 February 2023 (UTC)
+#I don't really have any preference on this. First, its seems that this would only apply to established characters, not common enemies, so it seems that this won't apply to [[Driblee]] nor [[Broom Hatter]], and thus this will have a pretty small scope. For the ones that it does apply, like Kracko, I also have those concerns that us choosing specifically one pronoun over the rest would probably be a mess, and I don't know if one is definitively more prominent than the other. For example, for Kracko, I don't know what would make us decide which one to choose between "him" and "it" over the other. Still, I do like consistency, and I really resonate with the reasons to do this. I just don't punch hardly either way. {{User:Zolerian Yuviaflero/sig}} 19:36, 12 February 2023 (UTC)
+====Change 1 discussion====
+''the most consistently-used pronouns in games''
-{{title font (old)|cH|e|l|l|o}} {{title font (old)|w|o|r|l|d|exclamation}}
+So just to clarify, if we were making Kracko's page in 2014, even though ''Triple Deluxe'' refers to Kracko by "it" and it's the most recent Kirby game, considering Kracko had been consistently been referred to as "he" before, we would still use "he", and if the next games started to use "it" for Kracko we would change the whole page to refer to Kracko as "it", but if it didn't, we would just keep using "he"? {{User:Gigi/sig}} 16:28, 30 January 2023 (UTC)
+:I think if we got to the point where so many subsequent games started using "it" consistently, then we'd have to conclude that "it" is what they intend, so yes, in that case we would change the whole article to "it". That would be an extreme outlier case, though, as far as I am concerned. --[[User:Samwell|Samwell]] ([[User talk:Samwell|talk]]) 16:31, 30 January 2023 (UTC)
-'''Text-based title font:'''
+So for the point I brought up in my support comment (the same one Trig and Infinite are likely worried about), how would we handle having a character who switches pronouns very regularly and one doesn't seem to take priority over the other?<br>''"this rule does not apply across different canons"''<br>I figured that this meant that pronouns used in the main-series games would overall take priority (and so maybe that would resolve this issue). I would still like to ask about it though. -- {{User:Jellytost♡/sig}} 22:47, 4 February 2023 (UTC)
-<span style="font-family: 'Delfino'; font-size:3em; line-height:1.25em; -webkit-text-fill-color: white; text-shadow: -0.04em -0.04em 0 black, -0.04em 0 0 black, -0.04em 0.04em 0 black, 0 0.04em 0 black, 0.04em 0.04em 0 black, 0.04em 0 0 black, 0.04em -0.04em 0 black, 0 -0.04em 0 black">Hello world''!''</span>
+===Change 2: Solidifying entity names===
+This part of the proposal has already passed. See below for details.
-Above is a comparison between the two methods. A major benefit to the image-based title font are that it's more accurate to the games, but the cons are that it's screen-reader incompatible, blurry at higher resolutions, takes longer to load, and inflexible (new characters require new images). By contrast, the text-based title font is less accurate and a bit choppy at extremely high resolutions, but it being an actual font is a major boon; it can scale to any size, it's faster to load, compatible with screen readers, and can be formatted in any way as long as it's CSS compatible. Because of this, I believe it's the best approach to implement and switch to it. [[User:StrawberryChan|StrawberryChan]] ([[User talk:StrawberryChan|talk]]) 02:38, 6 January 2021 (UTC)
+===Change 3: Infobox representation===
+Admittedly, this one's not really an issue right now, but I still think it's important to have a firm decision on this point. For the main infobox of the page, the image used of a character or other entity should be the most representative/consistent image, not necessarily the most recent one. This rule has largely been followed in practice, but a formal clause should be put in place so nobody thinks to put whatever temporary makeover [[King Dedede]] gets in the next game up as his main infobox image like what was attempted when ''[[Kirby and the Forgotten Land]]'' was the upcoming game. :P
 {{Support}}
-#Of course. I think accessibility as well as infinite scalability (which the PNGs didn't have due to being bitmap) is a huge plus IMO. --[[User:pandakekok9|pandakekok9]] ([[User talk:pandakekok9|poyo]]) 02:49, 6 January 2021 (UTC)
+#Not much to add here other than I completely agree. It's been an unwritten rule for a while so I fully support making it an official one. {{User:Gigi/sig}} 15:03, 29 January 2023 (UTC)
-#This would make screen readers (and copy-paste, the thing that started this back in August) work, which is a big plus. Also would help simplify the template further. {{User:Pinkyoshifan/sig}} 23:06, 9 January 2021 (UTC)
+#Agree as well, provided that accompanying the policy is a document with a few different example entities showing examples of representative and un-representative images for each. {{User:WillIdleAway/sig}} 15:26, 29 January 2023 (UTC)
-#While the text-based one's outline is a bit too thin, this improves accessibility and loading times. {{User:Obsessive Mario Fan/sig}} 01:56, 10 January 2021 (UTC)
+#Agreed. The infobox is meant for the character as a whole, not for the character in one game specifically. {{User:Pinkyoshifan/sig}} 16:05, 30 January 2023 (UTC)
-#Also agree! Never thought that added accessibility would be a key component in resorting to text instead of imagery. &ndash; [[User:Owencrazyboy17|Owencrazyboy17]] ([[User talk:Owencrazyboy17|talk]]) 02:34, 10 January 2021 (UTC)
+#Kind of surprised we weren't doing this already, to be honest. [[User:Trig Jegman|Trig]] - 16:15, 30 January 2023 (UTC)
-#It seems things will be more efficient this way, and I see no problems with making the change, so support. -- {{User:MetaDragon/sig}} 06:03, 11 January 2021 (UTC)
+#As long as we the editors can come to a consensus on what is the most "representative" image of a character, I support this. Epic Yarn is a good example of why using the latest official artwork of a character is not always the best action. {{User:Kirb/sig}} 17:58, 4 February 2023 (UTC)
-#Looks like benefits outweigh the take backs by a lot. Supporting. {{User:Superbound/sig}} 12:30, 16 January 2021 (UTC)
+#Not a lot for me to say here. This sounds good to me. There will be some discussions on what the "most representative image" is sometimes, but that's natural. -- {{User:Jellytost♡/sig}} 22:47, 4 February 2023 (UTC)
+#Not a lot for me to say here outside of consistency. {{User:Yoshi's Island/sig}} 11:18, 8 February 2023 (UTC)
+# Basically turning unwritten into written. Support. {{User:Superbound/sig}} 21:29, 11 February 2023 (UTC)
+#I support this, but not under the notion of "choosing the most representative/consistent image", but instead both under the notion of "not choosing necessarily the most recent image" and under the notion of "treating it in a case-by-case basis". What image to choose depends on the character/article. {{User:Zolerian Yuviaflero/sig}} 19:46, 12 February 2023 (UTC)
 {{Oppose}}
 {{Neutral}}
-#I believe this was already going to happen regardless, we just had not gotten around to it yet, so I am not entirely sure a proposal is necessary. --[[User:Samwell|Samwell]] ([[User talk:Samwell|talk]]) 02:40, 6 January 2021 (UTC)
+#Similar to change one, there may come up some things where a "most representative" image would need proper deciding between editors first. So while I'm not exactly opposed to the idea to make it a real guideline, I can't say I'm really convinced either. [[User:Infinite Possibilities|Infinite Possibilities]] ([[User talk:Infinite Possibilities|talk]]) 20:16, 4 February 2023 (UTC)
-:::I thought the last step was to get final approval from the community before we went forward with it? Otherwise, I was just waiting for nothing. Which, I mean, I wouldn't put past myself. :p [[User:StrawberryChan|StrawberryChan]] ([[User talk:StrawberryChan|talk]]) 02:43, 6 January 2021 (UTC)
+====Change 3 discussion====
-===Discussion===
-Just one question, if the proposal passed, is Delfino font going to be implemented by changing {{t|Title font}} directly or totally new template will be created, while the image-based one will remain for archival/other purposes? {{User:Superbound/sig}} 20:00, 9 January 2021 (UTC)
-:{{t|Title font}} will be changed and the image-based one will be moved to {{t|Title font (old)}} or something like that. [[User:StrawberryChan|StrawberryChan]] ([[User talk:StrawberryChan|talk]]) 13:39, 10 January 2021 (UTC)
-::Perhaps <nowiki>{{t|Title font image}}</nowiki> or <nowiki>{{t|Pop Happiness font}}</nowiki> would be a better name? {{User:Superbound/sig}} 12:30, 16 January 2021 (UTC)
-For a preview of what it will look like on a featured article, see this [[User:Pandakekok9/sandbox|page]] ([[Special:PermaLink/187025|permalink]]). There's this annoying empty space though, and I'm not sure what's causing it. [[User:pandakekok9|pandakekok9]] ([[User talk:pandakekok9|poyo]]) 10:57, 11 January 2021 (UTC)
-:I looked at it some and it looks like the empty space is caused by the line breaks between the featured template, title font template, and infobox template. {{User:Pinkyoshifan/sig}} 15:31, 11 January 2021 (UTC)
-{{clear}}
-==Adjust naming policy to prioritize romanized Japanese names over internal data names (December 19th, 2020 - January 2nd, 2021)==
+So, at the risk of opening a can of caterpillars but just to have a point of reference ... with the example of Dedede, what ''would'' be considered the most representative/consistent image? (It's definitely ''not'' the KatFL design, true.)
-Currently, in the [[WiKirby:Naming_policy#Priority_in_naming|Naming policy]], it is stated that internal file names have priority over any non-English official title. The reasoning for this was that these internal names, however temporary they may have been to the developers, were often easier to understand. However, this priority comes with a few notable caveats, which can be summarized as follows:
-*It is hard to argue that internal names are really official, since they were not intended to be seen in-game or shown in promotional material.
-*Internal file names are typically difficult to source, and many of the ones we use here are not sourced properly for that reason.
-*For games like ''[[Kirby Mass Attack]]'', Japanese names tend to be the only ones available, and tend to appear more frequently in-game, making them more legitimate than internal data titles.
-*Recently, it has become a trend for external sources like the [[Kirby JP Twitter]] to provide additional information about otherwise anonymous enemies and other entities that appear in recent ''Kirby'' titles. The policy I think should be changed to better recognize this feed as a legitimate source of information on the series, whether it be in English or not.
-So, what this proposal seeks to do in short is to change the order of the Priority in Naming as follows:
+And for enemies that only appeared in sprite-based games, would we consider official out-of-game artwork to be more representative than the in-game sprite where appropriate, or vice versa? It seems like [[Twizzy]] (my beloved) is a good case study in that (in my eye) the official KDL artwork is clearly inconsistent but the KNiDL artwork (which is the current infobox image) is reasonably consistent with all of the in-game sprites and much higher-resolution (and thus should stay the infobox image). {{User:WillIdleAway/sig}} 15:02, 29 January 2023 (UTC)
+:We can probably formalize some finer details, but basically right now an image like that would be any artwork when available, from the most recent game that accurately represents the character. Sure the specifics of that is hard to put into words, but using Dedede again as an example, he is using [[:File:KRtDLD King Dedede.png]] which accurate represents him. We didn't use [[:File:KatFL King Dedede artwork.png]] when FL was his latest appearence because that's his appearance as a boss only, which for an article about Dedede as a whole would be innacurate as he's more often an ally than foe lately. Another examples of images that wouldn't fit his main infobox would be [[:File:King Dedede SSBU.png]] (as it's from Smash), [[:File:Buff King Dedede KSA artwork.png]] (again, boss form), and [[:File:K30AMF King Dedede artwork.png]] (using a design from a real world event and not a game). {{User:Gigi/sig}} 15:10, 29 January 2023 (UTC)
+::I actually like this way of framing it—in ambiguous situations like this, counterexamples are often the best way to suggest what is acceptable. (Tangential example: one might show an example of an acceptable photo for a passport or ID card, followed by several mildly amusing examples of clearly unacceptable photos, suggesting regions of acceptable and unacceptable images without actually having to draw the border.) To that list of Dedede counterexamples I would also add [[:File:King Dedede ball KCC artwork.png]], potentially also to argue that designs should be from mainline Kirby games as opposed to spin-off games wherever possible, and [[:File:KDB_Character_Treat_Kirby_riding_King_Dedede_artwork.png]], since it's low-res and an indirect appearance (even if the most recent one out of all the released games—this would also preclude a Keychain somehow ending up as the infobox image). {{User:WillIdleAway/sig}} 15:26, 29 January 2023 (UTC)
-#In-game names. Newer names have higher priority in most cases.
+Agreed with this, since it has long been an unwritten rule, but I have one small question, what if the design stays same, but the artstyle is different (both minor, like everything having thick outlines as it is seen in KRtDLD, but also more major, like ''[[Kirby: Canvas Curse]]'' or ''[[Kirby and the Rainbow Curse]]'')? {{User:Superbound/sig}} 15:40, 29 January 2023 (UTC)
-#Nintendo-published promotional material, including instruction manuals, website blurbs, and Nintendo-published strategy guides. If there are multiple names used among these sources, those that are most distinctive and commonly used take priority.
+{{clear}}
-#Any officially licensed non-Nintendo-published strategy guide. If there are multiple names used among these sources, those that are most distinctive and commonly used take priority.
+:IMO we should probably treat it case-by-cases, but minor artstyle changes I would say should be fine to use, drastic ones probably not, but for example I'm not sure if I consider ''Rainbow Curse'' a major one, but ''Canvas Curse'' and ''Epic Yarn'' I would. {{User:Gigi/sig}} 16:25, 30 January 2023 (UTC)
-#'''Any non-English official name, following the three above priorities as with English names. Romanized Japanese names take priority here.'''
+::I see. {{User:Superbound/sig}} 21:29, 11 February 2023 (UTC)
-#'''Internal file names. Use only as a last priority, as these names tend to be either short-hands or early development names. However, these may be used as additional sources to back up names from point 3.'''
-#Conjectural names. Use only if there is no official name of any kind to be found.
-What say you all? --[[User:Samwell|Samwell]] ([[User talk:Samwell|talk]]) 16:47, 19 December 2020 (UTC)
+==Solidifying character names and attributes in article writing - Change 2: Solidifying entity names (January 29th, 2023 - February 5th, 2023)==
+On WiKirby, it has been customary to refer to the names of entities differently based on which game or other media they are in. For example, in the original ''[[Kirby's Dream Land]]'', [[Maxim Tomato]]es are referred to as "Bag of Magic Food" in the manual, so they are called that on the wiki whenever talking about them in article text specific to ''Kirby's Dream Land''. Another example is referring to [[Tiff]] by her Japanese name "Fumu" whenever talking about the Japanese version of the anime specifically. However, it has been brought up that this convention can be confusing to readers, even if strictly speaking more accurate. If this sub-proposal passes, WiKirby will stop referring to entities by different names based on circumstance and only use the most consistent names, mentioning different names only as an aside, unless that different name is prominent in the game/scenario (such as the name "Aeon Hero" for [[Galacta Knight]] in ''[[Super Kirby Clash]]'').
 {{Support}}
-#Yes, in game names were not intended for use. Romanized Japanese names are not English, but still more official than dev names. {{User:Kirb/sig}} 17:04, 19 December 2020 (UTC)
+#I very much agree with this. I have had a decent amount of confusion reading some articles due to the names not being consistent. As for the anime, I feel like this would especially help those (like me) who have never watched the Japanese sub and would save time so they do not need to look up whatever it is that they are confused about.  {{User:Starvoid/sig}} 14:55, 29 January 2023 (UTC)
-#I agree as well. These names were not intended for the public to see, only for those developing the game and those sneaky little people who look in the game files after release. Non-English names that are mentioned in-game or in strategy guides (or even [[Kirby JP Twitter|Twitter]]) should be prioritized instead of internal names, not the other way around. &ndash; [[User:Owencrazyboy17|Owencrazyboy17]] ([[User talk:Owencrazyboy17|talk]]) 17:16, 19 December 2020 (UTC)
+#This seems reasonable—as an extreme supporting example, you wouldn't leave an entity un-named when discussing it in the context of a specific game if that entity got a consistent name in later games. Any context short of literally quoting from the instruction manual or strategy guide should simply have a parenthetical aside or footnote about the original name, and move on using whatever name is (or would be) used for the article for that entity based on the wiki naming policy. {{User:WillIdleAway/sig}} 15:11, 29 January 2023 (UTC)
-#I was looking at the naming policy today and thought the same. Japanese names are usually (at least I think) more well-though, since as mentioned earlier are supposed to be seen as public, unlike data names (example: [[Haltworker]]). Kirby JP Twitter should also be acknowledged as a better source. Support. {{User:Superbound/sig}} 17:22, 19 December 2020 (UTC)
+#We also stick to this unwritten rule even if it's a clear typo or mistranslation, Mr. Flosty being most infamous example. I don't really see why we need to stick to developers' mistakes in writing everywhere, especially if they later correct themselves. {{User:Superbound/sig}} 15:55, 29 January 2023 (UTC)
-#Agreed. Non-publicly released titles used in early development definitely should not have priority over any official non-English title. It makes sense to use non-English titles before internal file titles. -- {{User:MetaDragon/sig}} 18:43, 19 December 2020 (UTC)
+#It ''is'' pretty confusing in the most egregious of cases (articles related to the anime especially), so standardizing things in this manner would make it easier for readers that aren't invested in the ''Kirby'' series as a whole to not get lost. In other words, per all. &ndash; [[User:Owencrazyboy17|Owencrazyboy17]] ([[User talk:Owencrazyboy17|talk]]) 17:06, 29 January 2023 (UTC)
-#Even if an official name is foreign, it's still official, and that's better than a placeholder we aren't supposed to see. {{User:Pinkyoshifan/sig}} 19:31, 19 December 2020 (UTC)
+#Personally, I feel like consistency is key. By making everything uniform, it will make things less confusing for everyone. I've also gotten a bit confused myself at times when reading articles, so standardizing everything would greatly help. Would definitely have to add a note at the start of all the pages saying that in game they're referred differently however. [[User:GoldenDragonLeaf|GoldenDragonLeaf]] ([[User talk:GoldenDragonLeaf|talk]]) 03:49, 30 January 2023 (UTC)
-#Let's be honest, most of the internal file names we use are just nicknames used in development, and oftentimes in Japanese to start with anyway. I think this makes sense--and if we want English names, digging through official strategy guides is still an option. -{{User:YoshiFlutterJump/sig}} 19:11, 21 December 2020 (UTC)
+#Agreed. Same as with the gender thing, the devs being inconsistient doesn't mean that we need to be inconsistient. {{User:Pinkyoshifan/sig}} 16:01, 30 January 2023 (UTC)
-#Agreed here; Japanese names are still official and should be prioritized, even if they need to be translated. That being said, filenames should also be taken into account when it comes to how the Japanese names are romanized; for example, [[Grandy]] comes from the English filename, but matches the writing of the Japanese name. [[User:StrawberryChan|StrawberryChan]] ([[User talk:StrawberryChan|talk]]) 03:17, 22 December 2020 (UTC)
+#Above has said enough. Sounds good to me. [[User:Trig Jegman|Trig]] - 16:15, 30 January 2023 (UTC)
-#I'm agreeing as well.This solution seems more logical. Official none English names are way more reliable than internal file names, as those could be missunderstood more easily. [[User:Infinite Possibilities|Infinite Possibilities]] ([[User talk:Infinite Possibilities|talk]]) 20:35, 25 December 2020 (UTC)
+#As long as the exception in the last sentence of this proposal means we don't just start systemically changing all "[[Smash]]" or "[[Fireball]]" appearances to "[[Smash Bros.]]" and "[[Burning]]" disregarding the context reader is put into. If there's say a [[Glitches in Kirby & The Amazing Mirror|glitch in ''Kirby & The Amazing Mirror'']] or [[Glitches in Kirby's Adventure|''Kirby's Adventure'']] that requires prominently named Smash or Fireball abilities in respective games, telling the reader/player to aquire "Smash Bros." or "Burning", non-existent as such in respective games, would be more confusing than vice-versa. Whereas examples brought up in this proposal are an obscure prototypical name of [[Maxim Tomato]] in an instruction manual and a romanization of [[Tiff]]'s name in a different language/localization. {{User:Vipz/sig}} 23:41, 30 January 2023 (UTC)
-#Internal data names are starting to become really informal for me now that I think about it. I prefer Japanese or English names of various entities as they come from an official source, and internal data names may be a bit misleading, like with the case of [[Iron Ball]], which could be easily confused by me for a wrecking ball. -- [[User:Hexelectron|Hexelectron]] ([[User talk:Hexelectron|talk]]) 01:34, 26 December 2020 (UTC))
+#I support consistency and clarity, regardless of minor developer errors. Both the first and second parts of this proposal will prevent readers from becoming confused. {{User:Kirb/sig}} 18:09, 4 February 2023 (UTC)
+#Consistency provides clarity, so I think this is a valid thing to happen. Additionally, here it would be much clearer what the "prominent name" is. [[User:Infinite Possibilities|Infinite Possibilities]] ([[User talk:Infinite Possibilities|talk]]) 20:16, 4 February 2023 (UTC)
+#This sounds all good to me for the above reasons, though I agree with Vipz that we should consider context in certain instances. Clarifying in those areas will be handy and will make sure readers aren't confuzzled. -- {{User:Jellytost♡/sig}} 22:47, 4 February 2023 (UTC)
 {{Oppose}}
 {{Neutral}}
-===Discussion===
+====Change 2 discussion====
+Here's a theoretical question: what if the next ''[[Keeby|Kirby]]'' game were to call Waddle Doo "Cyclops Dee"? Would we have to move the enemy's page, change all mentions of and links to it, and move all files related to it? {{User:Kirb/sig}} 17:56, 4 February 2023 (UTC)
+:Okay, let's say for the sake of argument that that happens. If the name was prominent in the game (used repeatedly in dialogue, given a formal nameplate, etc.) then we'd be forced to use that name when referring to Waddle Doo in that specific context. If it's just a weird outlier (like the name of a keychain or character treat), then it can be mentioned as an aside and otherwise ignored. --[[User:Samwell|Samwell]] ([[User talk:Samwell|talk]]) 18:02, 4 February 2023 (UTC)
+::That makes sense, but if "Cyclops Dee" were to be used exclusively, would we be forced to use "Cyclops Dee" retroactively? Would it depend on if said game was a mainline or spin-off game, or if the name began to appear in all official media? {{User:Kirb/sig}} 18:06, 4 February 2023 (UTC)
+:::I think it would take several games and a concerted push from HAL to make that happen, so it wouldn't be a sudden decision on our part. --[[User:Samwell|Samwell]] ([[User talk:Samwell|talk]]) 18:07, 4 February 2023 (UTC)
+::::Alright, that makes sense to me. {{User:Kirb/sig}} 18:09, 4 February 2023 (UTC)
 {{clear}}
 [[Category:Archive]]

WiKirby:Proposals/Archive-2023: Difference between revisions

Latest revision as of 14:19, 5 January 2024

Proposals

Standardize wiki text to favor some words without hyphens (December 17th, 2023 - December 24th, 2023)

Discussion

Adjust/Remove Proposal Rule 15 (16 November 2023 – 30 November 2023)

Discussion

Disallow links in quotes, flavor text, etc (November 16th, 2023 - November 30th, 2023)

Discussion

Abolish Proposal Rule 8 (16 November 2023 – 30 November 2023)

Discussion

Change voting rules for multi-option votes (16 November 2023 – 23 November 2023)

Discussion

Kirby 64 Element Table (2023-08-23 - 2023-09-06)

Discussion

Basic gadgets (July 14th 2023 - July 28th 2023)

Discussion

Updating Video policy to allow small official videos (July 4th 2023 - July 18th 2023)

Discussion

Require archiving external links (May 20th, 2023 - June 3rd, 2023)

Comments

Clarifying the role of neutral votes in proposal voting (2023-05-09 - 2023-05-17)

Discussion

Deciding upon pronouns for characters with none (March 24th, 2023 - April 7th, 2023)

Discussion

Better represent how abilities can be gained from entities via categories (March 13th, 2023 - March 20th, 2023)

Discussion

Dream Friends pages' colored titles, revisited (March 4th, 2023 - March 18th, 2023)

Discussion

Delete spam account talk pages 020823—022223

Discussion

Solidifying character names and attributes in article writing (January 29th, 2023 - February 12th, 2023)

Change 1: Solidifying character gender

Change 1 discussion

Change 2: Solidifying entity names

Change 3: Infobox representation

Change 3 discussion

Solidifying character names and attributes in article writing - Change 2: Solidifying entity names (January 29th, 2023 - February 5th, 2023)

Change 2 discussion

Navigation menu

Search