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

WiKirby:Proposals/Archive-2023

From WiKirby, your independent source of Kirby knowledge.
Jump to navigationJump to search
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
  1. 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)
  2. Standardization is good, especially when it matches Kirby media. ---PinkYoshiFan 21:33, 17 December 2023 (UTC)
  3. 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)
  4. I agree. Consistency is cool. --Paistrie (talk) 00:06, 18 December 2023 (UTC)
  5. 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)
  6. Consistency is important, so support. -- KatFL language C.svgKatFL language Y.svgKatFL language O.svgKatFL language N.svg (profile ::: talk) 13:54, 18 December 2023 (UTC)
  7. Consistency is always appreciated, support. Infinite Possibilities (talk) 19:52, 19 December 2023 (UTC)
  8. 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)
  9. 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. ~☆Starvoid⁠☆ (t · c) 23:15, 19 December 2023 (UTC)
  10. 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
  1. 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)
  2. 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)
  3. 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)
  4. 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
  1. 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. ---PinkYoshiFan 18:33, 16 November 2023 (UTC)
  2. 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)
  3. 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)
  4. 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)
  5. 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
  1. Agreed, I can definitely see how it can get confusing. ---PinkYoshiFan 15:31, 16 November 2023 (UTC)
  2. 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)
  3. 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)
  4. Agreed. It'll be much less confusing like this, and we can just put the necessary links in the page's main text. --DeepFriedCabbage 07:22, 19 November 2023 (UTC)
  5. 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)
  6. 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)
  7. 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)
  8. 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
  1. 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
  1. 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)
  2. 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.) ~☆Starvoid⁠☆ (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. ---PinkYoshiFan 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
  1. 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)
  2. 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. ---PinkYoshiFan 13:46, 16 November 2023 (UTC)
Option 2: Narrow scope of rule to two-option proposals only
  1. Per reasons for voting for option 1 before this one was added, the main concern is multiple-option votes. ---PinkYoshiFan 21:58, 16 November 2023 (UTC)
  2. 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)
  3. 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)

  1. 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
  1. 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)
  2. If I'm understanding this correctly then it does seem like the best option. ---PinkYoshiFan 13:46, 16 November 2023 (UTC)
  3. 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)
  4. Using a system that discourages strategic voting seems like a good idea. I support it. Typman (talk) 18:17, 16 November 2023 (UTC)
  5. 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)
  6. 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)
  7. 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. ~☆Starvoid⁠☆ (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. ---PinkYoshiFan 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
  1. 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)
  2. 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)
  3. This is a great idea! We've got some clickable navboxes like this on lots of other pages, and this would work perfectly too. --DeepFriedCabbage 05:59, 24 August 2023 (UTC)
  4. 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)
  5. While I think either design could be good, I do prefer the new design that was brought up after the proposal. ---PinkYoshiFan 11:52, 6 September 2023 (UTC)
Oppose
  1. 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  
K64 Base Burn.png K64 Base Stone.png K64 Base Ice.png K64 Base Needle.png K64 Base Bomb.png K64 Base Spark.png K64 Base Cutter.png
K64 Base Burn.png K64 PC DoubleBurn.png K64 PC BurnStone.png K64 PC BurnIce.png K64 PC BurnNeedle.png K64 PC BurnBomb.png K64 PC BurnSpark.png K64 PC BurnCutter.png
K64 Base Stone.png K64 PC BurnStone.png K64 PC DoubleStone.png K64 PC StoneIce.png K64 PC StoneNeedle.png K64 PC StoneBomb.png K64 PC StoneSpark.png K64 PC StoneCutter.png
K64 Base Ice.png K64 PC BurnIce.png K64 PC StoneIce.png K64 PC DoubleIce.png K64 PC IceNeedle.png K64 PC IceBomb.png K64 PC IceSpark.png K64 PC IceCutter.png
K64 Base Needle.png K64 PC BurnNeedle.png K64 PC StoneNeedle.png K64 PC IceNeedle.png K64 PC DoubleNeedle.png K64 PC NeedleBomb.png K64 PC NeedleSpark.png K64 PC NeedleCutter.png
K64 Base Bomb.png K64 PC BurnBomb.png K64 PC StoneBomb.png K64 PC IceBomb.png K64 PC NeedleBomb.png K64 PC DoubleBomb.png K64 PC BombSpark.png K64 PC BombCutter.png
K64 Base Spark.png K64 PC BurnSpark.png K64 PC StoneSpark.png K64 PC IceSpark.png K64 PC NeedleSpark.png K64 PC BombSpark.png K64 PC DoubleSpark.png K64 PC SparkCutter.png
K64 Base Cutter.png K64 PC BurnCutter.png K64 PC StoneCutter.png K64 PC IceCutter.png K64 PC NeedleCutter.png K64 PC BombCutter.png K64 PC SparkCutter.png K64 PC DoubleCutter.png

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). ---PinkYoshiFan 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  
K64 Base Burn.png
Burning		 K64 Base Stone.png K64 Base Ice.png K64 Base Needle.png K64 Base Bomb.png K64 Base Spark.png K64 Base Cutter.png
K64 Base Burn.png
Burning 		K64 A DoubleBurn.png
Burn-Burn		 K64 PC BurnStone.png K64 PC BurnIce.png K64 PC BurnNeedle.png K64 PC BurnBomb.png K64 PC BurnSpark.png K64 PC BurnCutter.png
K64 Base Stone.png K64 PC BurnStone.png K64 PC DoubleStone.png K64 PC StoneIce.png K64 PC StoneNeedle.png K64 PC StoneBomb.png K64 PC StoneSpark.png K64 PC StoneCutter.png
K64 Base Ice.png K64 PC BurnIce.png K64 PC StoneIce.png K64 PC DoubleIce.png K64 PC IceNeedle.png K64 PC IceBomb.png K64 PC IceSpark.png K64 PC IceCutter.png
K64 Base Needle.png K64 PC BurnNeedle.png K64 PC StoneNeedle.png K64 PC IceNeedle.png K64 PC DoubleNeedle.png K64 PC NeedleBomb.png K64 PC NeedleSpark.png K64 PC NeedleCutter.png
K64 Base Bomb.png K64 PC BurnBomb.png K64 PC StoneBomb.png K64 PC IceBomb.png K64 PC NeedleBomb.png K64 PC DoubleBomb.png K64 PC BombSpark.png K64 PC BombCutter.png
K64 Base Spark.png K64 PC BurnSpark.png K64 PC StoneSpark.png K64 PC IceSpark.png K64 PC NeedleSpark.png K64 PC BombSpark.png K64 PC DoubleSpark.png K64 PC SparkCutter.png
K64 Base Cutter.png K64 PC BurnCutter.png K64 PC StoneCutter.png K64 PC IceCutter.png K64 PC NeedleCutter.png K64 PC BombCutter.png K64 PC SparkCutter.png K64 PC DoubleCutter.png

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.

  1. 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.
  2. 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.
  3. 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
  1. 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)
  2. 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. ---PinkYoshiFan 20:33, 14 July 2023 (UTC)
  3. 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):

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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
  1. 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)
  2. 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. ---PinkYoshiFan 13:22, 4 July 2023 (UTC)
  3. 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)
  4. 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)
  5. 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
  1. 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. ---PinkYoshiFan 12:23, 20 May 2023 (UTC)
  2. 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)
  3. 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)
  4. 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)
  5. 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)
  6. Heavily agree with this. Preservation is important, especially if we want to check something later. GoldenDragonLeaf (talk · edits) 20:30, 26 May 2023 (UTC)
  7. 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
  1. 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)
  2. 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. ---PinkYoshiFan 15:06, 9 May 2023 (UTC)
  3. 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)
  4. 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)
  5. 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)
  6. 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)
  7. 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)
  8. 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
  1. 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)
  2. 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)
  3. 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)
  4. 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)
  5. 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
  1. 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
  1. 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)
  2. 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. ---PinkYoshiFan 20:53, 26 March 2023 (UTC)
  3. 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
  1. 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)
  2. 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)
  3. 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. ---PinkYoshiFan 21:29, 13 March 2023 (UTC)
  4. 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)
  5. 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)
  6. 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)
  7. 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
  1. 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)
  2. 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
  1. 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)
  2. 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)
  3. 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. ---PinkYoshiFan 12:54, 7 March 2023 (UTC)
Option 3: Revert to how it was before the 2021 proposal
  1. "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
  1. 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)
  2. 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)
  3. 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)
  4. 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)
  5. 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)
  6. 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)
  7. 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
  1. Unnecessary pages should be deleted.--kirb 01:42, 10 February 2023 (UTC)
  2. 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)
  3. Sounds good to me. Would we unregister the users themselves, too? Because I think that would be a good way to free up usernames. --DeepFriedCabbage 06:00, 10 February 2023 (UTC)
  4. 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)
  5. 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
  1. 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. ---PinkYoshiFan 12:27, 9 February 2023 (UTC)
  2. 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. ~☆Starvoid⁠☆ (t · c) 01:24, 10 February 2023 (UTC)
  3. 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)
  4. 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
  1. 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)
  2. 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)
  3. Agreed. The devs being inconsistient doesn't mean that we need to be inconsistient. ---PinkYoshiFan 16:00, 30 January 2023 (UTC)
  4. 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)
  5. 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)
  6. I prefer to keep things consistent. Yoshi's Island 11:18, 8 February 2023 (UTC)
Oppose
Neutral
  1. 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)
  2. 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)
  3. 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
  1. 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)
  2. 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)
  3. Agreed. The infobox is meant for the character as a whole, not for the character in one game specifically. ---PinkYoshiFan 16:05, 30 January 2023 (UTC)
  4. Kind of surprised we weren't doing this already, to be honest. Trig - 16:15, 30 January 2023 (UTC)
  5. 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)
  6. 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)
  7. Not a lot for me to say here outside of consistency. Yoshi's Island 11:18, 8 February 2023 (UTC)
  8. Basically turning unwritten into written. Support. Superbound (talk) 21:29, 11 February 2023 (UTC)
  9. 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
  1. 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
  1. 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. ~☆Starvoid⁠☆ (t · c) 14:55, 29 January 2023 (UTC)
  2. 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)
  3. 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)
  4. 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)
  5. 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)
  6. Agreed. Same as with the gender thing, the devs being inconsistient doesn't mean that we need to be inconsistient. ---PinkYoshiFan 16:01, 30 January 2023 (UTC)
  7. Above has said enough. Sounds good to me. Trig - 16:15, 30 January 2023 (UTC)
  8. 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)
  9. 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)
  10. 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)
  11. 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)
Retrieved from "https://wikirby.com/w/index.php?title=WiKirby:Proposals/Archive-2023&oldid=457065"