WiKirby:Proposals/Archive-2023

The following proposals have been successfully passed by WiKirby's community:

Proposals

Smash Bros. Coverage 110221–111621 EXT: 112521

This is a proposal relating to several conversations on Discord about how WiKirby should be moving forward in Smash Bros. content moving forward. Currently, most pages are set up in the following structure:

• About the game
• All Characters in a list
• Kirby's moveset
• King Dedede's moveset
• Meta Knight's moveset
• All stages in the game
• Specifically only Kirby Stages
• "Story Mode" or main non-Smash game mode
• Items
• Trophies
• Gallery
• Trivia/References/Footers

There have been several vocalized concerns about the types of content being covered on these pages, as they are generally long in vertical length and not always being directly related to Kirby. The following are some suggested paths to move forward on covering content, listed in a form of most change to least change:

1-Completely redirect all Smash Bros. Content to SmashWiki, the Smash NIWA affiliate

The most extreme choice. If game pages remain, they mostly serve to just send people to SmashWiki after a short explanation of the game.

2-Reduce covered content to explicitly only cover Kirby content

Remove information about various game modes, non-kirby characters, and non-kirby stages.

3-Only remove character images on Brawl, 4, and Ultimate pages

One of the chief complaints is that having character images lengthens pages too much and therefore should be deleted, and move character lists back to single line text. This option would only seek to delete character pictures and no other change

4-No Changes

Current coverage is just fine the way that it is. No changes are necessary.

5-Increase Smash Bros. Coverage

This option is for arguing that Wikirby does not cover enough Smash content, and should work on developing more, even if it isn't directly Kirby related.
Please discuss heavily! As for myself, I would prefer options 3 and 2 in order. Trig - 14:30, 2 November 2021 (UTC)

Voting

Support

1. 3 sounds like the best option. ---PinkYoshiFan 23:49, 3 November 2021 (UTC)
2. The Super Smash Bros. game pages are a bit anomalous at this point when it comes to pages that cover Smash Bros. content on WiKirby, since all other pages that deal with Smash Bros. content tend to only focus on the stuff that directly links to the Kirby series. At this point, I'm almost convinced that the pages on Super Smash Bros. games themselves should be removed entirely from WiKirby in favor of links to SmashWiki, and any relevant information on those pages be dispersed to the most appropriate pages (for instance, moving details on Kirby as a Smash Bros. fighter to the main Kirby page). For now though, just to make sure nothing moves too fast, I will vote for option 2. --Samwell (talk) 20:48, 7 November 2021 (UTC)
3. I vote for option 2.
   Although there is a "joke" of Kirby sites covering Smash, because both were created by the same person and company, I doubt that there is any reason to cover non-Kirby content here with the existence of Smash Wiki. Pikipedia's and Inkipedia's articles of Ultimate jumps directly to the content of their respective franchises evading any external content, and I think that WiKirby should do the same in every Smash page; not cover non-Kirby scenarios, nor the game modes if they don't have relation to Kirby. Having a list of all the characters is useful because, as Gigi said here, Kirby copies them, so they are relevant in the Kirby side. But having images of them is not necessary, a text listing like the ones in 64 and Melee pages suffices.
   In short: 64, Melee, Brawl and For lists non-Kirby stages. Brawl, For and Ultimate have images of non-Kirby characters. Ultimate lists the game modes even if they have nothing to do with Kirby. I think that those things shouldn't be in WiKirby, and option 2 aims to do delete them, so there I go. -Kirbeat (talk) 02:46, 8 November 2021 (UTC)
4. Covering the content that specifically has nothing to do with the Kirby series doesn't really serve a purpose as there already is a NIWA wiki for that. Though I personally disagree with getting rid of all game modes since Ultimate's Classic Mode specifically makes use of the Kirby characters in other routes which reference stuff, so I vote for option 3 as it gets rid of the stuff most unneeded while keeping what I consider to be relevant enough. Infinite Possibilities (talk) 17:44, 11 November 2021 (UTC)
5. 3 It seems to me that covering Smash elements that don't relate to Kirby isn't very useful when SmashWiki is so extensive. I think we should keep around the pages, since the Smash series is technically a game in which Kirby appears as a playable character. We don't really need images of other fighters. --kirb 15:34, 12 November 2021 (UTC)
6. Voting for 3 because 2 looks very extreme and 3 would solve the biggest problem we have right now. I would base them the other pages around Super Smash Bros. Ultimate minus the character images, as I believe it strikes a good balance of content about these games. - Gigi (talk • edits) 16:00, 12 November 2021 (UTC)
7. This was certainly a tough decision... Both parties have good points. For a while now, I've been iffy about having the Smash Bros. pages on WiKirby at all, but their existence doesn't hurt much as-is, especially since Kirby characters are playable. There's a chance they'll be wiped from the wiki eventually though, which is something I'm half-and-half on.
   As for the content on the pages, I really don't see the need to cover non-Kirby content, though a very basic summary of some stuff is fine. We need a bit of general context here and there for the Kirby content itself, but not much at all. I don't believe that it will be misleading, since we can, for instance, title the Game Modes section as something like "Game Modes involving Kirby content". Stripping content away won't be a totally strict process. There's always room for suggestions in the future if things are going downhill or if anyone changes their mind.
   With all of that said, I was originally going to play it safe with option 3, but after thinking about it for a few days, I'll be going with option 2. -- Jellytost♡ (talk) 03:02, 22 November 2021 (UTC)

Oppose

Neutral

Discussion

• I will post here every link relating to this proposal, just if someone wants to check those pages fast. Feel free to add any one that I missed.
  • Super Smash Bros.
  • Super Smash Bros. Melee
  • Super Smash Bros. Brawl (images)
  • Super Smash Bros. for Nintendo 3DS / Wii U (gallery) (images)
  • Super Smash Bros. Ultimate (talk) (images)
• In the Ultimate talk page is a discussion about the removal of the images of other characters, so it's worth checking. -Kirbeat (talk) 15:52, 2 November 2021 (UTC)

• Here is my proposed outline of what should be covered in each Smash page, taking inspiration of the current state of Super Smash Bros. Ultimate:
  • Fighters - fighters *should* be listed because Kirby copies them, but without images, and in a collapsible table. Kirby series fighters get explanation of their movesets in separate sections;
  • Stages - much like the page right now, an overview of the number of available stages, and any relevant info that relates to the Kirby in general (such as the stage forms). Then a list of Kirby stages, and their music;
  • Items - similarly to the Stages, an overview, any relevant info, all Kirby items with info about them;
  • Game Modes - at least general information about them. Cutting some of them would make no sense for me as some modes such as Classic Mode have their variations per character, and they would they get listed while others would not? It would be misleading to the reader. So just listing all modes is fine, while detailing Kirby content of modes as needed;
  • Trivia/Gallery - as long as these are only about Kirby content it should be fine.
• Again, just my two cents. I think a format like this strikes a good balance between the two worlds. - Gigi (talk • edits) 16:09, 12 November 2021 (UTC)

Overhaul Template:Aboutfile 101621-103021

I've come to make an announcement in regards to the project that I am leading regarding adding Template:Aboutfile to every image that lacks it currently. In short, I want to make changes to the currently existing template to be more like the Template:File on Wars Wiki and StrategyWiki (see here).

Simply put, I think that this template is not only objectively better but also extremely easy to implement. Here is a list of reasons in a relative order of importance:

• This would be a non-destructive change. This is only changing the components of Aboutfile, which means that that the old styling and the suggested new changes can be together without conflict. This is simply just trying to add to the existing template, not make a new one.

• It's drastically easier for new users to use. People that don't have much experience uploading files will find exactly everything they need to enter directly where it needs to be, most likely without having to open up other pages or categories to see exactly what needs written for that file, and don't need to memorize certain aspects of uploading.

• It's drastically easier for you, yes YOU to use. The primary benefit to Wars' Template:File is that a lot of components don't need to be manually written. If a game is entered into the |game= slot, the game not only has a link to it, but is automatically categorized for that game. Wars' |type= section not only categorizes the file to the "type" conditional's category (like Category:Screenshots) but also automatically generates the file license which means...

• No more licensing templates needed. Everything will automatically be fed through the template and generate exactly what is needed! No need to write out categories or licenses. This is a fantastic way to reduce potential errors, as typos can always exist on the categorization meaning people looking for images cannot find them as easily.

• Sourcing becomes a lot better managed. Currently for Wars, if a section is left blank, the file will automatically be added to a category for unsourced files. What could occur is the current file needs sourcing template is integrated into the new Aboutfile template so that there is a bright, contrasting warning inside the box indicating the file has no source and one needs located. This can be taken a step further by having a second warning specifically for any files sourced through Kirby FANDOM or FANDOM overall.

• Finding errors and improvements when changing the template. I have seen a significant as in over 200 files that need image-quality templates, header fixes, or other types of fixes while compiling the list. This is a fantastic way to address these types of problems when making changes to files anyway.

• Saves space on new uploads. This is pretty minor. But it's cool and notable.

The only current either downside or hinderances in my way for fully integrating this today right now are the following: Your collective support for the idea, making the template still look as pretty as it does now, and how exactly we would approach other media like the anime or books or something. I would personally suggest just dropping it in |game= but there might be a few lingustic rivals amongst us that disagree with using game for not-games.

TL;DR:

• Aboutfile is converted to include the automatics involved in Wars Wiki's Template:File through additional parameters.
• Template:File source is converted to File source link (or something similar) to specifically notate files that have a written source, but no link to it (such as many of RMV's uploads). File source needed and Not-using-FANDOM conditionals are built into Aboutfile.
• Trig posts his big freaky list and people start chipping away at it.

--Trig Jegman - 03:05, 16 October 2021 (UTC)

For an example of a file change, please click "Expand" on the right.

Consult File:KMA Tortletummy Thorn sprite.png

<nowiki>
== Summary ==
{{aboutfile
|description=In-game sprite of [[Tortletummy Thorn]] from ''[[Kirby Mass Attack]]''
|game=''[[Kirby Mass Attack]]''
|source=[https://www.spriters-resource.com/ds_dsi/kirbymassattack/sheet/8487/ Spriters Resource]
}}

== License ==
{{Game sprite}}
[[Category:Kirby Mass Attack images]]
[[Category:Sprites]]

would move to

==Summary==
{{aboutfile
|description=In-game sprite of [[Tortletummy Thorn]] from ''[[Kirby Mass Attack]]''
|game=Kirby Mass Attack
|type=sprite
|source=[https://www.spriters-resource.com/ds_dsi/kirbymassattack/sheet/8487/ Spriters Resource]
}}
</nowiki>

in order to provide the same exact results.

Support

1. Sounds good to me. Any changes that make the process of proper file uploading easier for new users in particular gets a thumbs up from me. --Samwell (talk) 03:07, 16 October 2021 (UTC)
2. Complete support. This is very beneficial, and what catches my eye more is both the auto placement of unsourced files and, on top of everything, the auto Categorization in general. -Kirbeat (talk) 04:35, 16 October 2021 (UTC)
3. Simpler is better, especially for new users. ---PinkYoshiFan 10:59, 16 October 2021 (UTC)
4. Not having to manually add game categories and license types is a good idea. --kirb 18:12, 25 October 2021 (UTC)

Oppose

Neutral

Discussion

Vipz

A couple of issues I'm foreseeing:

• Automization with "|game=Kirby's Game" doing ''[[Kirby's Game]]'' [[Category:Kirby's Game images]] will work only for games, so aside from linguistics, this is why I think "|media=" should be a separate field. Not all media will have pages and categories (that work the same way).
• Pipe links are impossible.
• When an image comes from multiple games (e.g. KNiDL, KaTAM and KSqS) - although additional categories can be added manually.
• License parameters (e.g. {{Game screenshot|official}}) and multiple licenses (e.g. {{WikimediaImage}} + {{PD}}).

There might be more, so clean automization is hard, unless we introduce more parameters. ⁠–⁠Wiz (talk · edits) 11:58, 16 October 2021 (UTC)

Back from my trip. I agree that perhaps having a secondary |media= that does not cause an automatic link may be useful, but would suggest we emphasize using |game= when most possible. Secondarily, I cannot necessarily think of an appropriate reason to have a piped link for a game title. Anything that is a deviation from a full game name seems like it would qualify as an inaccuracy. At the absolute worst, |media= would solve that. If an image comes from multiple games, I would suggest simply using |description= to list other included games and writing in more categories. I think that multi-game files would be exceedingly rare. Licensing parameters would be able to be changed to be their own separate variable switch. The way the template works is by using a different, all-encompassing switch template to change the file license instead of having several dozen templates so one parameter could just become |type=Screenshotofficial or something similar. As for multiple licenses, I do not forsee {{WikimediaImage}} being necessary if we are specifically listing the source out, though once again another parameter could be added for a Wikimedia+PD parameter if absolutely needed. Trig - 00:29, 18 October 2021 (UTC)

Template WIP

While not fully complete, User talk:Trig Jegman/Sandbox here is a rough draft of how the template will function including the requests made above/on Shiver Star. Trig - 21:07, 19 October 2021 (UTC)

Gigi

About licenses, are you proposing that these templates are to be removed from all current files currently using it if this change rolls out in favor of a more general one for just "files" as shown in your sandbox? Because as of right now, there is a dropbox in the upload form for choose a template, and I'm wondering if that is supposed to eventually be gone too. I would just like to understand more and what kinda of backwards work would need to be done if this rolls out. - Gigi (talk • edits) 01:12, 26 October 2021 (UTC)

Long story short, yes, the drop box would go. As we have on StrategyWiki, the list of possible file types is up front and center first thing on the upload screen (although it could be prettier). These templates all roughly contain the same message only inter-changable by the type, which is being designated its own parameter as opposed to a template name. It is unlikely that a different license will need to be used for an overwhelming majority of images, and although yes technically possible to continue generating different licenses for different types, it does not do much except waste space. I would intend to look at fixing every file anyway, due to the amount of sourcing and quality flagging that can be addressed (hundreds to thousand files probably need some form of extra management). Trig - 01:48, 26 October 2021 (UTC)

Favor adapted Japanese names and terms over literal translations whenever possible (July 28th - August 11th)

Currently, the naming policy says the following when it comes to Japanese names:

• Any non-English official name, following the three above priorities as with English names. Translated Japanese names take priority here.

The part I bolded is what I want to specify better. My proposal is to change that point to the following:

• Any non-English official name, following the three above priorities as with English names. Translated Japanese names take priority here, using adapted names and terms whenever possible.

In short, when we use Japanese names, we should try to use officially localized names and terms whenever possible, to make the names as close to English as possible, and to avoid inconsistencies. Here are some examples to illustrate:

• Four-Headed Guardian Angel: Landia: the Japanese title 4つ首の守り神：ランディア directly translates to Four-Headed Guardian Deity: Landia. However, 守り神 has been localized in the games as "Guardian Angel", so we instead use that term for the page.
• Air Ride: Sky Sands: the Japanese title エアライド:サンドーラ directly translates to Air Ride: Sandoola. However, "Sandoola" is the Japanese name for "Sky Sands", so instead we use that name for the page.
• True Arena Showdown: the Japanese title 真 コロシアムの戦い directly translates to True Colosseum Battle. コロシアムの戦い is the Japanese name of Arena Showdown, that has an official English name. 真 コロシアムの戦い is basically "真" plus コロシアムの戦い, and "真" is the prefix added to "The Arena" to make it "The True Arena" in Japanese. So, it's safe to do something similar in English. "True" plus "Arena Showdown", resulting in "True Arena Showdown".

Of course, by allowing this, these names aren't translated names anymore, but instead derived, so marking them with the Template:ForeignTitle makes it misleading. So I also propose the creation of a "Derived from Japanese" template, to mark articles with names that aren't direct translations, but rather use the Japanese name as a guide of sorts for the article's title. These would still put pages in the Category:Articles with titles from non-English languages regardless, as the source of the name is Japanese. Finally, while it could be argued that these titles could end up being speculative, I believe that as long as there are basis to go with (such as in the examples I gave), adapting names like that should be fine. And, of course, if there is ever diverging opinions about what to name a page, that could be discussed on its talk page.

Thoughts? - Gigi (talk • edits) 00:55, 28 July 2021 (UTC)

Support

1. I'm in support of this: I realize we don't have a consistent solution for this, so it'd be best to stick with the direction we're already going and make it formal. I think that'd also mean articles like Hoshi no Kirby Yume no Izumi no Monogatari (soundtrack) and Hoshi no Kirby 64 Original Soundtrack would have to be moved, but I'm fine with that. (I assume Kirby Wii Music Selection would stay the same since it's already in English? I suppose we can discuss that later...) StrawberryChan (talk) 01:07, 28 July 2021 (UTC)
2. Gigi and I spent a lot of ASCII hammering out the finer details of this idea, and I am pleased with the result, so I support. --Samwell (talk) 01:08, 28 July 2021 (UTC)
3. Direct translations, while technically more true to the source material, can be flawed, misleading, or contradicting localization sometimes and can require interpretation, which is what this proposal aims to allow (if I'm understanding it correctly). Support. ---PinkYoshiFan 16:13, 28 July 2021 (UTC)
4. Another example I can thing of is Big Metalun, and since we had an IP user got confused by this recently, it should definitely be clarified. Superbound (talk) 21:46, 2 August 2021 (UTC)
5. Definitely seems like a good idea. This should lessen confusion and having a solid solution for going about Japanese names will be good, as said by the other supporters. -- Jellytost♡ (talk) 02:26, 3 August 2021 (UTC)

Oppose

Neutral

Discussion

To answer StrawberryChan, this would only apply to names written in Japanese, so Kirby Wii Music Selection wouldn't need to be moved since it's written in English. As for Hoshi no Kirby Yume no Izumi no Monogatari and Hoshi no Kirby 64 Original Soundtrack we could discuss them further later. I wouldn't be against making an exception for album titles since they aren't often translated and aren't many articles anyway. - Gigi (talk • edits) 01:22, 28 July 2021 (UTC)

Overhaul to writing standards regarding humor (July 5th, 2021 - July 19th, 2021)

Hey, everyone. It's come to attention recently that the writing standards may be a bit too lenient in allowing for non-encyclopedic jokes in articles. While it's important that WiKirby doesn't take itself too seriously, it's also important that it doesn't become overridden with writers focusing on comedy over quality. The important bits from the previously linked article and the writing specifics are outlined below:

• WiKirby serves to display a certain sense of whimsy and humor when describing subjects. However, WiKirby does not intend to have subjective opinions on these subjects which may color the reader's judgments, especially if those opinions are comparison-based.
• WiKirby likes a bit of joviality, especially when it comes to clever use of wording and creative ways to spell out summaries. However, humor should not take precedence over the essential information of the article. Generally speaking, jokes should be confined to captions for images that do not require an explanation, if they appear in article text at all.

It should be emphasized that WiKirby focuses on information first, and this is outlined in both of these statements. They are otherwise rather vague, however, which can lead to some misunderstanding regarding what kind of humor is appropriate and inappropriate for each article. The general idea is that overt jokes should not be allowed in articles—the comedy generally comes from a sense of tongue-in-cheek humor, describing a fanciful series in a serious and practical manner. In other words, a more casual manner of describing information than most wikis is fine for our tastes, but not to a point where it becomes unprofessional. The above statements could be rewritten as such to reflect this:

• WiKirby has a casual style of writing that suits the whimsical nature of the Kirby series. However, WiKirby does not intend to have subjective opinions on these subjects which may color the reader's judgments, especially if those opinions are comparison-based.
• WiKirby aims to be informative, but also to avoid being dry and authoritative. A matter-of-fact tone is encouraged; a sense of wit is also welcome, but should not take precedence over the essential information of an article. This includes things that are otherwise self-evident, such as image captions. We're not looking to make the reader laugh.

This has been discussed on the Discord server already, but further discussion can take place here, as well. What are your thoughts? StrawberryChan (talk) 00:26, 5 July 2021 (UTC)

Support

1. I support this clarification. Should hopefully cut down on any confusion about what is and is not allowed in article text. --Samwell (talk) 00:32, 5 July 2021 (UTC)
2. Support because I agree that clarification is needed, and we shouldn't be making image captions with humor as the main goal. - Gigi (talk • edits) 00:44, 5 July 2021 (UTC)
3. Humor is a good side effect, but yeah, this should be clarified to note that the main intent shouldn't be jokes. ---PinkYoshiFan 01:08, 5 July 2021 (UTC)
4. Sounds like a good idea to me. Clarification on this would be nice and would make things less confusing. -- Jellytost♡ (talk) 05:30, 5 July 2021 (UTC)
5. These two guidelines have confused me since I joined, so making them less confusing would be nice. Hewer (talk · contributions) 14:22, 6 July 2021 (UTC)
6. Being more clear is always nice. Superbound (talk) 14:47, 6 July 2021 (UTC)

Oppose

Neutral

1. Personally I wouldn't mind non-encyclopedic jokes on image captions but I guess it would be better not to have them.--kirb 14:40, 6 July 2021 (UTC)

Allow Autopatrol users to mark files as Good (July 1st, 2021 - July 15th, 2021)

Greetings. It has come to my attention that a lot of file uploading has been undertaken by some of our more active users in Autopatrol rank. Due to the sheer quantity of them, I think it is impractical for Patrollers+ to be chasing all these files and marking them as Good, especially since the users in question uploading the files have already taken care to ensure they meet the qualifications. As such I propose that Autopatrol users be allowed to mark these files Good themselves. Note that this does not extend to articles, as those are subject to a stricter standard and ideally should still be looked over by a Patroller+. What do you all say? --Samwell (talk) 18:58, 1 July 2021 (UTC)

Support

1. I was thinking of proposing the same but also including articles, although now that you point it out, I agree that files in particular are less of an issue, plus there are way more of them. So, since Autopatrol users are trusted and manually selected for the rank, I don't see why not. - Gigi (talk • edits) 19:07, 1 July 2021 (UTC)
2. Autopatrol users have already demonstrated that they can be trusted, and trusting them with marking files as Good seems like it makes sense, especially since some users mark things as Good, only to have the edit undone since they aren't wiki staff. ---PinkYoshiFan 20:19, 1 July 2021 (UTC)
3. I don't see why not. As said by Gigi and PYF, autopatrol users are trusted users who deserve to at least mark files as Good and giving them this permission would make things much easier, but I agree that marking articles as Good be left up to Patrollers+, especially because doing otherwise would leave Patrollers with little to no special permissions in their rank. :P -- Jellytost♡ (talk) 06:07, 4 July 2021 (UTC)
4. Yes, this is a good idea. Uploading images is something that the wiki needs a lot of, and something new users are often willing to do.--kirb 14:37, 6 July 2021 (UTC)

Oppose

Neutral

Tweak various policies regarding files (May 14th, 2021 - May 27th, 2021)

Something I've noticed every since I started editing here on WiKirby was how we had no written guidelines about various things about files. We have policies like WiKirby:Image standards, WiKirby:Audio standards, WiKirby:File use policy, which are all great, but they don't cover everything about files. In fact, we have various unwritten rules already been enforced here that aren't written anywhere. I'm going to list all these and propose what to change to make them clearer.

No file redirects

It is written nowhere in the pages Help:Redirects and WiKirby:Deletion policy that file redirects aren't allowed, and should be removed from pages and marked for deletion. It is not mentioned either in WiKirby:File use policy. Help:Moving pages is focused on pages, it encourages users to leave redirects, which could lead new users into thinking the same applies to files. In short, it's not mentioned anywhere.

My idea is to mention in Help:Redirects that file redirects should not exist under any circumstance. WiKirby:Deletion policy should list file redirects as candidates for deletion. Help:Moving pages should have a section explaining that an editor not on Autopatrol+ should, after moving a file, change all uses of the file to the new name and mark the file redirect for deletion. Users on Autopatrol+ should move files without leaving a redirect.

Cropping transparent images and optimizing files

These two trends, mainly optimizing files, started with WiKirby:Project Clean-Up. I see them as productive, and I would like to have them listed as recommendations in some policy pages. I don't believe we need to enforce them formally, but saying that it is preferred to do so would be nice.

Cropping transparent images basically means removing empty space from them. Many times files from official sites are transparent, but they have lots of empty space. The extra space makes the image appear smaller on the wiki, since it's accounting for all that empty space. My idea is to add a small note on WiKirby:Image standards to do that with any transparent image.

Optimizing files means running them through some image optimizer program to make them as small in file size as possible without losing quality. I would like to mention it also in WiKirby:Image standards, with a note that it's optional, and an editor looking into optimize images needs to do it loselessly.

File naming guidelines

WiKirby:Naming policy right now only lists guidelines for naming pages, which makes sense. WiKirby:Image standards#Other image procedures and details has a general "give a good name to the file, or it will be moved or deleted". However I believe we need at least some basic rules so that we can consider a name file good enough, without small disagreements on if it could have a better name. Ever since WiKirby:Project Clean-Up started, different users have inforced different rules for naming. At core they all have the same principles, and so I'm going to list those here. My idea isn't to make very specific guidelines like the regular naming policy, but I believe we still need some small guidance. The basic rules I propose are:

• The file name must have the subject (eg. Kirby), the game or media it's from (eg. KSSU), and if it's an image the type of image (eg. Artwork). Order doesn't matter. So "Kirby KSSU Artwork", "KSSU Kirby Artwork", "KSSU Artwork Kirby" and "Kirby Artwork KSSU" are all acceptable;
  • However, the beginning of the file name should give enough information about the file itself. In other words, the subject must be in the beginning of the file name if it's very long (this is specifically to prevent issues such as this whole category page being impossible to navigate);
  • The game should use the abbreviation from WiKirby:Abbreviations.
• Proper nouns in the file name should be capitalized, other words are up to the file uploader;
• No restrictions about using special characters, as long as the file name is readable, with the exception of periods, that should be avoided to not mess up with the definition of the file type. So no file names with Japanese characters, but characters such as ' and & are acceptable for example.

And as the final guideline:

• Files should not be moved unless it's to fix an issue with these guidelines.

That way we don't have "move wars". With the example I used, if there is a file named "Kirby KSSU Artwork" it's acceptable. It shouldn't be moved to "KSSU Kirby artwork". This is equivalent to editing a page and changing certain words but still keeping the same meaning, which isn't productive at all.

All that should then be listed in WiKirby:Naming policy, and WiKirby:Image standards and WiKirby:Audio standards should list them and link back to the naming policy. Help:Moving pages should mention files and explain when they should and shouldn't be moved.

What do you all think? - Gigi (talk • edits) 20:17, 14 May 2021 (UTC)

Support

1. I find no problem with any of these changes, with the no file redirects rule being especially helpful and the rule regarding all filenames having certain parts certainly helping out with being consistent, even if just a small bit. ---PinkYoshiFan 22:19, 14 May 2021 (UTC)
2. Per my comment down below. Superbound (talk) 06:01, 15 May 2021 (UTC)
3. General support for this. See my input down below for details. --Samwell (talk) 16:59, 17 May 2021 (UTC)
4. I've been thinking and I now agree with almost all of the proposals. The file redirects could be used for something and only should be disabled for most purposes. We should be cropping transparent files to make them look at their best. I realize that having one specific way to name files is too strict and new contributors might break the rules immediately if stricter file naming rules are applied. - GameDoor64 (talk) (edits) 22:07, 17 May 2021 (UTC)
5. I haven't really considered before the reasons found below in the discussion panel as to why preventing the creation and existence of file redirects may cause some problems. I'm largely neutral either way regarding this. If we do end up keeping certain file redirects, as long as we diligently keep them off articles, I've nothing against it. As for recommending images to be cropped and optimized on some policy pages, I entirely agree with it. As for file naming guidelines... I really don't think we need any strict guidelines as Gigi said. A lot of moves I've seen have seemed unnecessary. Renaming "KSSU Birdon Artwork.png" to "KSSU Birdon artwork.png" is very unnecessary, for example, so I generally agree that we should only move files if there is a problem in which the file needs to be moved, not just because of personal preference. Some sort of ordering for the respective subjects in file names could possibly be positive, especially in "sets" of similar files and to avoid a situation where "KSSU Birdon Artwork", "KSSU Birdon artwork", and "Birdon Artwork KSSU" all exist for example, but renaming many if not all files to a set order does largely seem like an unachievable task that's not really worth the effort in all, and I could definitely see said "sets" being defined differently between editors and becoming controversial, as Gigi said. Sorting through these different definitions and picking out one and strictly using it honestly seems like more work than it's worth to me, especially since again, as Gigi said, we're a Kirby wiki, and having extremely strict guidelines just doesn't seem fitting for us. As long as the file tells me simply what I want to know about it, I'm satisfied.

To summarize, I generally agree with this proposal and support it. -- Jellytost♡ (talk) 06:31, 27 May 2021 (UTC)

Oppose

1. I agree mostly, but disagree on a few minor points such as putting the game abbreviation first and allowing special characters. --kirb 09:37, 27 May 2021 (UTC)

Neutral

1. Point 1 and 2 go without a say, but I disagree with third's subpoint 1 and subsequently 4. Policy is supposed to guideline editors into naming new files well in the first place, so 4th doesn't need to happen (and instead say to not capitalize "Artwork / Sprite / Screenshot"). Order doesn't matter because they only affect categories really (they're findable by searching too), so sure there, but I'd prefer type on last place. If someone is willing to make a small set of consistency moves at a time, that's fine. (Again, regardless of actual vote outcome, please regard the discussion made below, so multi-point proposals don't end up 100% yes or 100% no). ⁠–⁠Wiz (talk · edits) 08:29, 15 May 2021 (UTC)

Discussion

I fully agree with points one and two.

Point 1: File redirects are not necessary, and only take up space. As the proposal states, they only exist to help new users not accidentally move a file and break many pages. Adding a note in the policy stating that file redirects are discouraged will not only let new users know, but also remind them to properly change the links on images they moved.

Point 2: Both optimizing and cropping are two helpful tactics to reduce file space and size, especially when loaded on pages. It is a very good idea to encourage these. (It should be noted that it actually increases the total space used up as MediaWiki keeps all versions of a file unless they are specifically deleted, and even then the file exists only visible to admins+.)

Point 3: The third point is one where I partially disagree. I do agree that all filenames should contain the subject, WiKirby game abbreviation, and image type unless not needed. The parts I don't completely agree with are that the order does not matter, non-proper noun capitalization is up to the uploader, and files should not be moved unless necessary.

Subpoint 1: I think that the order of the words of the filename can be important in situations where multiple files exist, all with the same name but different order. I have moved many files and seen many situations where "KSSU Kirby Artwork", "KSSU Kirby artwork", and "Kirby Artwork KSSU" all exist as an example. This is why I personally always put the game abbreviation at the beginning, so when I scan through the image category, all of the similar files are grouped together. In regards to the Commemorative Illustration category, it is a very rare occurrence. In it's case the subject should go at the beginning of the name because of how long "Twitter Commemorative Illustration" is. For nearly every other category, the game abbreviation is 2-5 characters long, and does not take up a lot of space (KA, KSS, KRtDL, KPR, KF2), and the image type (sprite, artwork, screenshot) is at the end of the filename usually. Putting the game abbreviation is my personal preference, because if every image starts with the abbreviation, none of them do in regards to alphabetical order.

Subpoint 2: Proper nouns should always be capitalized in filenames, but other words probably shouldn't. I'm not sure if it should be a rule, but it should be suggested that words such as "concept artwork", "screenshot", "and", and "scene" don't really have to be capitalized. (They nearly always aren't right now.) I would ask that we suggest uploaders to not put any words in FULL CAPS that aren't supposed to be, as this is not useful and kind of annoying.

Subpoint 3: Special characters can be allowed in filenames, with the exception of non-readable characters (Japanese, Arabic, Russian) and periods (which can mess with the filetype). We should probably also ban emojis from filenames although nobody has attempted uploading emoji names yet as far as I know. While special characters are allowed, they should only exist if they are part of the name, such as allowing "KSSU Daroach's Airship screenshot.png", but not allow adding extra characters that don't need to be there. In general, there shouldn't be extra words/characters added to filenames. ("KA Kirby sprite.png" vs "Awesome Kirby picture (Adventure) image ~ sprite.png")

Subpoint 4: I think that files should be moved to match with similar files. If there are a lot of files like "KSS Stone artwork.png", than if one file is "Spark Artwork KSS.png" it should be changed to fit in with the rest. It doesn't need to be required or top-priority that filenames be similar to others in their group, but it shouldn't be a bad thing to make one file fit in with the rest. --kirb 20:37, 14 May 2021 (UTC)

For reference, I don't want to make extremely strict rules to naming files. Most of your counterarguments seem to favor that.

Subpoint 1: I will be honest, I fail to see the point you're making here. Can you explain better?

Subpoint 2: Again, it doesn't really matter if they aren't capitalized or not unless it's proper nouns. Moving a file just to change that isn't necessary. If you think it is, could you please elaborate?

Subpoint 3: Fair enough. That is what I was going with that.

Subpoint 4: The issue with this is where you draw the line. What are "similar files"? How do we define that? Do all artwork files need to follow the same pattern? Or just files from a certain game? Or just copy ability files? It starts to become extremely arbitrary.

Again, I just want a simple set of guidelines just to make sure people aren't naming a file like "poppy bros. jr. kssu.png". I really don't want us to make very specific guidelines to files because they are mostly hidden to editors. And I keep seeing unnecessary edits to files that I would really rather see stop. That is all. - Gigi (talk • edits) 20:47, 14 May 2021 (UTC)

I agree that it can be difficult to determine what makes files "similar", but I mainly didn't want to be prohibited from moving a few files to match with closely-related files. I think all files in a "set" should follow the same format. A "set" being very specific, such as all copy ability sprites from a certain game, or every screenshot from a certain stage. Most images are not like this, but many are. If all of the Super Star Copy Ability sprites follow a format except one, I would want to rename that one. I can however see that many of the moves I have done were not necessary, and I will try not to move files that already have acceptable names. --kirb 21:05, 14 May 2021 (UTC)

The issue happens when someone else considers a "set" different from someone else, or really when different "sets" are used on pages of the same subject. An example: ability icons are usually grouped together in galleries, but some copy ability pages don't do that and icons are between various kinds of files. Compare for example Beam#Gallery and Archer#Gallery, they are very different. Again, it is really arbitrary, and if we made rules for each case we would be here all day making rules and, frankly, we're a wiki about Kirby. We don't need a million rules. Which is again why I think we should have some basic ones and leave the rest for the uploader. - Gigi (talk • edits) 21:27, 14 May 2021 (UTC)

When you say "special characters", which ones do you mean? I don't think we should allow any characters that aren't on a standard QWERTY keyboard. --kirb 01:07, 18 May 2021 (UTC)

I do agree on the first proposal that file redirects shouldn't be allowed and that we should optimize images. I however don't agree on the third proposal. I have renamed over 100 files just to name them like this: KSSU Plasma Wisp artwork. I believe that we should name files like what I mentioned before. - GameDoor64 (talk) (edits) 21:00, 14 May 2021 (UTC)

Your personal guidelines are basically the same as mine. I'm confused as to what you go against my proposed guidelines for files. Care to elaborate? - Gigi (talk • edits) 21:27, 14 May 2021 (UTC)

I just believe that we should have the files named in a certain way for organization. I can see the reason that you're behind with having the files named in any order of abbreviation, subject, type of image. But it'll make finding images easier provided we don't have file redirects. - GameDoor64 (talk) (edits)

I just don't believe we need extremely strict guidelines for file naming when we have categories and galleries and the search function. For me as long as the file name gives me enough information about the file it should be good. Moreover, I would rather to see energy spent on actual bad file names than perfectly fine ones. Not to mention that every user has their personal way to name files, and I fail to see a good reason to move good file names that doesn't have any problems. I personally have my own issues with files starting with the game abbreviations, but I won't go on my way to rename files like that because, honestly, it's not my place, even as the editor-in-chief, to impose my personal opinion on a small thing such as a file name. And frankly, the effort it would be to make all files follow some extremely specific guidelines is too much more work than it's worth. - Gigi (talk • edits) 21:54, 14 May 2021 (UTC)

Why I don't like "strict file name format":

1. Causes a lot shenanigans. "KSA Susie Artwork.png" is bad, but "KSA Susie artwork.png" is better? Or "Archer KSSU sprite.png" versus "KSSU Archer Sprite.png"? Like why, they basically the same.
2. As Gigi mentioned above, there is no way we ever agree on what format should be used, as any variation has their own pros and cons. Starting with subject helps navigating game categories, but starting with abbrevs helps in character images. And there's nothing to stop us from just accepting both, so why bother?

I mentioned this some time ago (in abbreviations proposal), and brought it up on Discord few days ago - the descriptiveness matters the most. I strongly support moving files only if there is an actual problem with them. Pointless moves are pointless, bring little to no improvement (or sometimes do the reverse) and clog recent changes.

Points 1 and 2 are just writing already widely accepted unwritten rules, so no problem from me there too. Superbound (talk) 06:01, 15 May 2021 (UTC)

Update: I'm not opposed to allowing file redirect as panda said below me if we decide to do so. Superbound (talk) 10:51, 20 May 2021 (UTC)

To be honest I disagree that file redirects are unnecessary and shouldn't exist. Those who say that probably don't care about external sites linking to our wiki. By not redirecting old filenames to their new names, you break every single link to that old name. And even worse, we don't know how many times that old name is linked to in other sites we don't control.

See Cool URIs don't change by the W3C on why old links shouldn't break.

Now I'm not saying we should allow internal linking to redirects. They should be relinked to the new name. Preventing the creation of redirects is still okay, as long as the old name is not more than two days old, or the old name was blatantly inappropriate and offensive.

A common argument by those who want to exterminate ala Dalek the file redirects is that they cost space. But the thing is, the moment you rename a file, you already took up some space. The moment the redirect was created, you can't take that space back by "deleting" it. In fact "deletions" in MediaWiki are more of just archivals and hiding of content from non-admins. They don't free any space, and will only waste even more space because every "deletion" is logged. pandakekok9 (poyo) 13:56, 15 May 2021 (UTC)

I'll assume this doesn't refer to external sites using up WiKirby's bandwidth with their src attribute, but the ability to find moved files after redirect's deletion. There are 2 ways to delete a file redirect - one is by auto-deleting it when moving it (which tells where the file got moved to), and another is by tagging it for deletion, and the delete tag expects a reason for that. When deleted, all actions with the file or last content when manually deleted is always visible in the reference. ⁠–⁠Wiz (talk · edits) 01:29, 16 May 2021 (UTC)

Nope, I'm not referring to those sites who eat up WiKirby's bandwidth via the img src attribute, but rather those who link via the anchor tag.

Of course you can still find the new name after deleting or preventing the creation of the redirect. It's always logged in the deletion log. But you forgot one thing: the old name can be recreated, thus hiding the new name in obscurity. Of course such thing is very rare, but it can happen. And besides, the average user most likely would be annoyed of not being automatically redirected to the new name.

So with that in mind, what's the point of deleting such file redirects then? None. pandakekok9 (poyo) 02:09, 16 May 2021 (UTC)

Now that you bring this up, I am unsure myself why this wiki has always deleted file redirects. It has been an unwritten rule for as long as I've been in this wiki. We even recently added the permission for any user on Autopatrol+ to move files without a redirect exactly because we deemed them unnecessary.

I am honestly neutral on this subject: as long as pages don't use file redirects I'm okay with that, and I could instead just mention that in the policies and we could start allowing file redirects, and we would need to revert back that permission and only allow Admins+ to move files without redirects.

I do have a question, however: what if a file is, say, named "Kirby KSSU.png" and it is moved to "Kirby KSSU artwork.png". Would a file redirect make sense here? A file named "Kirby KSSU" could be any file of Kirby from KSSU, a sprite, artwork, screenshot etc. In short, generally on WiKirby we move files because of bad or not specific names, would you still argue that these file redirects should exist? - Gigi (talk • edits) 23:02, 16 May 2021 (UTC)

Good question. I think it depends on the age of the old name, and as well as the knowledge on how many times it was linked to. If the old name is relatively new, maybe preventing the creation of a redirect is okay. If a redirect already exists though, they shouldn't be deleted, even if it was a mistake, or the old name is relatively new. Redirects should only be deleted when its name is obviously inappropriate or offensive. A good rule of thumb would be, "if in doubt, don't delete or prevent the creation of a redirect." pandakekok9 (poyo) 04:23, 17 May 2021 (UTC)

And by the way, I won't go as far as removing the privilege of moving files without a redirect for Autopatrol+. They are trusted, established users of the community, and our community is relatively small, so I trust they will do good judgment on whether to create a redirect or not. pandakekok9 (poyo) 04:25, 17 May 2021 (UTC)

Samwell's input

So, let me try to give my thoughts on all the points made here as succinctly as I can so as to avoid this discussion panel getting too much longer than it already is.

• File redirects: I don't remember when the precedent started to delete all file redirects, but the reasoning that I held for the practice was specifically to prevent situations where redirect links were used in articles and gallery pages. I've personally had to chase after quite a lot of image links that weren't properly changed after a move and were creating viewing issues on pages, and it's easier to find those discrepancies when they are red links via the special pages. However, I don't have anything against file redirects existing so long as we are diligent in keeping such links off articles.
• I've nothing to add regarding cropping transparent images or optimizing files, since I basically agree with the original proposal.
• File naming guidelines: This one's a bit tricky, since a great deal of unwritten precedent was established by Trig Jegman when he started Project Clean-Up. In doing so, he set up what was for him a standardized policy that he personally used across the dozen or so wikis he was working on simultaneously, which paid little regard to whatever file naming policies may have existed beforehand (which admittedly for us was not substantial at the time). Personally, I still think it's a good idea to standardize file names to follow one rule set consistently (such as game abbreviation always appearing at the beginning, or always at the end, whichever one we'd decide on), but at the same time, I understand that there's already been so much file moving based on changing standards over the years. The prospect of having to do it all again feels like a Sisyphean task, and it may not ultimately be worth the effort. Also, for lack of a better term, a lot of Trig's name change fixation was fairly petty, as can still be seen on the Project Clean-Up page, and I've felt like tossing out entire sections of the file renaming columns as not worth the trouble. In short, I generally agree with Gigi's sentiment on this last point, that file moves should only be done when the name is not fit for purpose, not just because the capitalization is slightly off.

In summary, I support the proposal generally, but remain neutral on the matter of file redirects existing or not. I will leave that one to Gigi and the rest of the community to decide on. --Samwell (talk) 16:59, 17 May 2021 (UTC)

Small adjustments to Good page criteria (March 15th, 2021 - March 29th, 2021)

So, it was briefly discussed on the Discord that some adjustments should be made to the criteria for deeming an article Good in order to accommodate pages covering entities that only appear once in the series and/or have little to be said about them. On behalf of those in that discussion channel, I propose the following changes to the Good articles criteria on the Featured content policy as follows:

• Minimum number of bytes for a page to be Good to be reduced from 2,000 to 1,000 (assuming the page is otherwise complete).
• Status of subpages to no longer be a factor in determining whether the main article is deemed Good or not.

This will be a relatively minor change to the policy, but it should allow many short but complete pages on our wiki to receive the Good mark, as well as sparing the blushes of many of our larger complete pages that have incomplete gallery sub-pages. What say you all? --Samwell (talk) 01:49, 15 March 2021 (UTC)

Support

1. Definite support. The main thing about a good article is that it should only have to be the best it can feasibly be. If the article's about a minor subject that can't reach 2,000 bytes, but it's still otherwise a fully fleshed-out article, that shouldn't have to hold it back. We definitely want as much detail as possible, but we don't want to encourage padding, either. StrawberryChan (talk) 01:53, 15 March 2021 (UTC)
2. I agree. Some pages are fully completed but still under 2000 bytes. And a page can be good without it's subpages being so. --kirb 01:56, 15 March 2021 (UTC)
3. Agreed, not all short pages are necessarily bad (an example that comes to mind is most of the K&TAM rooms). Removing the subpage requirement doesn't hurt either. ---PinkYoshiFan 11:18, 15 March 2021 (UTC)
4. Actually I think we should remove the bytes requirement, which seems unnecessary IMO and can be an inaccurate metric for completeness (who knows, maybe someone suddenly knew of a way to abstract the content of a 1000-byte good article to a template, shrinking the article down to like 900 bytes. Should we demote the article just because someone knew of a better way to encode an article?), and let the patroller+ judge whether an article is complete enough and of good quality. But this is a good start. As said by others already, there are articles that are short but can't be expanded because it's already complete. --pandakekok9 (poyo) 15:34, 16 March 2021 (UTC)
5. I support. This sounds like a reasonable idea. Pages can be complete and be worthy of being marked as 'Good' and be under 2000 bytes. They can also be 'Good' even if their subpages are not. -- Jellytost♡ (talk) 02:55, 18 March 2021 (UTC)
6. As said by others above, if an article covers all information that can be added without question it deserves to be granted good status. Unnecesarily bloating pages with half-correct information to reach 2000 bytes only hurts the credibility of the wiki. For subpages, those often are only relatively minor in general and don't need to affect the main pages in a negative way. Support all the way. Infinite Possibilities (talk) 08:54, 18 March 2021 (UTC)
7. The Good status is just for pages that are complete. The 2,000 byte limit just encouraged padding for small pages. --DeepFriedCabbage 17:54, 29 March 2021 (UTC)

Oppose

Neutral

Revise image standards (sprite-based images, Virtual Console, etc.) (February 25th, 2021 - March 11th, 2021)

Greetings, puffballs and others. In the past, we've had a number of discussions about what constitutes a Good game screenshot on WiKirby, and going by "native resolution" as a default rule has been the de-facto standard for some time now. However, recently, a few hiccups here and there have led me to realize that the current standards are a little too tight in places, and a little too ill-defined in others. As such, I'd like to propose an amendment to the image standards by making the following the new guidelines for what constitutes a Good game screenshot:

Sprite-based games

Screenshots of sprite-based games are Good if and only if they are "pixel perfect"; meaning the pixels are rendered at a 1 to 1 ratio from game to screenshot. It does not matter what is used to capture the screenshot (native console, Virtual Console, emulation, etc.), as long as this is the case. In addition, these screenshots must be clean (no visual distortions and precisely cropped for full screenshots) and originally rendered in lossless format (PNG in our case).

Sprite-based games (along with full screenshot resolution in parentheses) consist of the following:

• All Game Boy games (160x144px)
• All SNES games (256x224px)
• All Game Boy Advance games (240x160px)
• All Nintendo DS games (256x192px for single screen, 256x384px for both screens)
• Kirby's Adventure (256x224px or 256x240px, depending on the way the image comes out)
• Kirby's Dream Land 2 (160x144px for Game Boy, 256x224px for Super Game Boy)
• Kirby Tilt 'n' Tumble (160x144px)

Non-sprite-based games, native or unofficially emulated

Screenshots of non-sprite-based games that are not being played on Virtual Console are Good if they match the native resolution of the console they were originally made for. In addition, they can be in a file format other than PNG as long as they are clean with no significant distortion.

Non-sprite-based game screenshots should follow the standard resolution of their home consoles, as follows:

• Nintendo 64 (320x240px or 640x480px)
• Nintendo GameCube and Wii (640x480px or 854x480px for widescreen)
• Nintendo 3DS (400x240px for upper screen, 320x240px for lower screen)
• Wii U and Nintendo Switch (1280x720px or 1920x1080px)
• Wii U Game Pad (854x480px)

Virtual Console games

Screenshots of games emulated using Virtual Console or any other official Nintendo emulation method can be marked as Good if and only if they match the native resolution of the console they are being played on, are clean, and are not sprite-based. They must also all be marked with the {{VC}} template (a file template marking an image as coming from Virtual Console that will be made if this proposal passes). For the sake of clarity, games that are being played on backwards-compatible devices with higher resolution (such as Wii games on Wii U) will also be treated as Virtual Console.

That should about do it. Let me know if there are any concerns with this proposal, and I will seek to make further amendments where applicable. --Samwell (talk) 21:04, 25 February 2021 (UTC)

Support

1. Support; the image standards definitely need more consistency, and this seems like a good solution. The Virtual Console template, in particular, feels like it will be incredibly useful in the long run, as we may want to provide VC screenshots later on for comparison (for example, Zero's arena in Boss Butch). StrawberryChan (talk) 21:13, 25 February 2021 (UTC)
2. These changes definitely look like they would help the clarity of our policies, and a VC template is definitely a good idea to differentiate them from native shots while still being allowed on articles. --YFJ (talk · edits) 22:20, 25 February 2021 (UTC)
3. Clarity is good, especially with how to deal with official upscales. ---PinkYoshiFan 22:24, 25 February 2021 (UTC)
4. This is a good compromise for everything we have available. Keeps things consistent, while still allowing screenshots from every console that can run each game when applicable. - Gigi (talk • edits) 22:33, 25 February 2021 (UTC)
5. Not much new to say from me, I agree with all changes made by this proposal, especially VC template. Superbound (talk) 11:46, 26 February 2021 (UTC)
6. I also don't have anything new to point out here. It sounds like a reasonable solution with consistency. This VC template also sounds like a good idea. -- Jellytost♡ (talk) 07:30, 28 February 2021 (UTC)

Oppose

Neutral

Discussion

I see that KDL2 has a specific rule about SGB. I think this one needs to be cleared up. Should we include the KDL2-specific border from SGB when making screenshots in SGB? Also note that a real Game Boy would only run KDL2 in monochrome, and without any border, therefore screenshots like this one are inaccurate, since it is colored and doesn't show any SGB border. So my point is, should we still allow SGB screenshots of KDL2 without the border? If so, then I don't see the point of allowing SNES resolution for KDL2. pandakekok9 (poyo) 14:52, 28 February 2021 (UTC)

Keep in mind that the stated resolution applies only to full screenshots, and that an image can still be marked as Good if it crops out unnecessary detail (as is often done to highlight specific characters or objects). So, for Super Game Boy screenshots, it is okay to crop out the border if there is no need to show it. --Samwell (talk) 16:01, 28 February 2021 (UTC)

Okay, that cleared that up for me, thanks. pandakekok9 (poyo) 02:36, 1 March 2021 (UTC)

Regarding SNES games, screenshots coming from Kirby's Toy Box were all 256×239 (which is one of valid resolutions, mind the odd number), and all screenshots on the 'net are this resolution too. I followed Pandakekok9's first upload and cropped all 8 currently uploaded screenshots to 256×224 manually since I couldn't find a way to emulate at this height. Should this be a valid alternative resolution? —Viperision (talk) 17:30, 2 March 2021 (UTC)

Kirby's Toy Box is a sprite-based game, so just use whatever resolution you need to keep a full screenshot pixel perfect. --Samwell (talk) 17:46, 2 March 2021 (UTC)

What to do with bigger but JPG images and smaller but PNG images (February 22, 2021 - March 8, 2021)

There are plenty of images on this wiki, which also includes artwork. As many may know, PNG is the best for artwork, however, sometimes it isn't the largest one available, like with Kirby 64 Cilly...

(left - JPG, right - PNG)

...or Air Ride Warpstar.
File:WarpstarKAR.jpg
(left - JPG, right - PNG)

Significant drop in resoltiuon. On the other hand, images aren't that often used to be this large, and most of them are in galleries in following size:

• 

  OH NO, COULD IT BE–

• 

  WARPSTARS?!

• WarpstarKAR.jpg

  lmao they r scared of us

• 

  ha ha silly snowguys

As you can see, it's hard to note a difference in quality, but transparency works better here.

So what do we do?

• List both - In case something like this happens, both images will be displayed, with caption like "Smaller but transparent version od a previous artwork"
• PNG > JPG - Favor smaller PNG over bigger JPG.
• JPG > PNG - Inverted version of above.
• Case-by-case basis (so nothing changes) - This is oversimplifaction of something complicated, and each case like that should be reviewed seperatly.

Superbound (talk) 18:56, 22 February 2021 (UTC)

List both

1. This has been my de-facto way of handling this artwork, so I'll go with this option. --Samwell (talk) 19:45, 22 February 2021 (UTC)
2. Listing both means keeping both. In the worst-case scenario, convert a JPG to PNG (and upload to same filepage) to preserve both versions. —Viperision (talk) 20:18, 22 February 2021 (UTC)
3. Second choice. --DeepFriedCabbage 19:41, 27 February 2021 (UTC)

Case-by-case basis (so nothing changes)

1. It is heavily redundant in my opinion to use the same image twice for things, but that said, I think that is truly situational about the image's quality overall. In more instances than not, a JPG is usually larger and cleaner, and despite having a background, is easier to make out. JPGs are also usually better to avoid situations Like this where transparency in images doesn't always look good, especially for dark mode nerds like myself. In other circumstances, the PNG may be a higher quality despite being smaller, and would look better in both galleries AND infoboxes, where JPGs generally only look good in galleries. I would stress that both have their advantages and disadvantages, and if an editor isn't sure, they can either bring it up on discord or upload both and allow the community to decide. Trig - 22:04, 22 February 2021 (UTC)
2. PNGs are only different enough than JPG (from a visual standpoint, at least) to where we should only replace JPG with PNG the PNGs have transparent backgrounds or if the JPG is smaller than or equal in size to the PNG. So basically, (in my opinion) if the JPG is bigger and the PNG isn't transparent, then use JPG. Otherwise, use PNG. ---PinkYoshiFan 22:09, 22 February 2021 (UTC)
3. Agreed on case-by-case. PNG isn't always automatically better than JPG and vice-versa; it's ultimately down to the image itself. Generally a PNG with a transparent background is most preferable for an infobox, while a JPG can look fine if a transparent version of the image isn't available. Listing both seems redundant to me. StrawberryChan (talk) 03:40, 24 February 2021 (UTC)
4. I've been thinking and I'm going to go with case-by-case here. These cases seem rare from what I've seen, and generally it's better to have both, but it really depends on the case. Rather than make a very black and white rule for a situation that doesn't happen that often, I would rather keep it case-by-case. - Gigi (talk • edits) 16:07, 24 February 2021 (UTC)
5. As cases are not unified, neither should our solution. Enough said. --kirb 04:06, 25 February 2021 (UTC)
6. I honestly can't add any more to what's already been said. PNG is not inherently superior to JPG or vice versa, and it really comes down to the individual quality of the images. --YFJ (talk · edits) 21:58, 25 February 2021 (UTC)
7. I think PNGs are generally better than JPGs, but if we have a JPG that's tranparent, we should include both. --DeepFriedCabbage 19:41, 27 February 2021 (UTC)
8. JPGs are usually inferior to PNGs, but it all comes down to the quality of the image itself since that isn't always the case. Having a hard rule for PNG over JPG or vice-versa would be a bit too tight and would likely do some damage to the overall quality of our images. Listing both is a better alternative to that, but as stated above, due to redundancy, that probably would not be the best option here. Therefore, in my opinion, this should be done case-by-case. -- Jellytost♡ (talk) 07:30, 28 February 2021 (UTC)

Neutral Comments

1. Superbound your captions are funny :p. --kirb 22:13, 22 February 2021 (UTC)

Discussion

To respond to Viperision, I would intensely affirm that images should never ever not ever be converted from lossy to lossless or lossless to lossy, as it entirely butchers the quality of the image and is generally entirely ineffective at comparing multiple images. There is no harm to having two images and one being deleted, as mentioned in my vote. Trig - 22:04, 22 February 2021 (UTC)

JPG to PNG is this "worst-case scenario" in order to (if listing both is not a viable option, which I doubt) attempt to preserve two versions of same artwork. It's still valid to try conversion, investigate whether CMYK to RGB butchered anything, and decide to (not) upload. My "list both" vote regards cases where both (JPG and PNG) versions have valid advantages, in order to not have a perfectly fine transparent but smaller PNG version be deleted, and vice-versa for larger JPG versions. For wiki's display purposes it may not be all that important and most users will likely not notice another version preserved in file logs, so definitely list both and don't bother with conversion. —Viperision (talk) 20:17, 28 February 2021 (UTC)

Reform WiKirby: Abbreviations (January 23, 2021 - February 6, 2021)

Alright. You remember the Great Debate we had on WiKirby talk:Abbreviations? This is where we put that into effect.

Let me get this out of the way. The purpose of the abbreviation policy page is to standardize naming patterns for filenames. And that's where it miserably fails. More than one abbreviation per game? Abbreviations for consoles and Kirby Super Star subgames? Abbreviations for characters that no one will ever use? Yeah, let's fix that.

I propose we completely rewrite the abbreviations list and only use the following abbreviations:

Kirby's Dream Land - KDL
Kirby's Adventure - KA
Kirby's Pinball Land - KPL
Kirby's Dream Course - KDC
Kirby's Dream Land 2 - KDL2
Kirby's Avalanche - KAv
Kirby's Block Ball - KBBa
Kirby's Toy Box - KTB
Kirby Super Star - KSS (as determined by discussion)
Kirby's Star Stacker (Game Boy) - KSSGB
Kirby's Dream Land 3 - KDL3
Kirby's Star Stacker (SNES) - KSSS
Kirby 64: The Crystal Shards - K64
Kirby Tilt 'n' Tumble - KTnT
Kirby: Nightmare in Dream Land - KNiDL
Kirby Air Ride - KAR
Kirby & The Amazing Mirror - KaTAM
Kirby: Canvas Curse - KCC
Kirby: Squeak Squad - KSqS
Kirby Super Star Ultra - KSSU
Kirby's Epic Yarn - KEY
Kirby Mass Attack - KMA
Kirby's Return to Dream Land - KRtDL
Kirby's Dream Collection Special Edition - KDCSE
Kirby: Triple Deluxe - KTD
Kirby Fighters Deluxe - KFD
Dedede's Drum Dash Deluxe - DDDD
Kirby and the Rainbow Curse - KatRC
Kirby: Planet Robobot - KPR
Team Kirby Clash Deluxe - TKCD
Kirby's Blowout Blast - KBBl
Kirby Battle Royale - KBR
Kirby Star Allies - KSA
Kirby's Extra Epic Yarn - KEEY
Super Kirby Clash - SKC
Kirby Fighters 2 - KF2

Super Smash Bros. series - SSB
Super Smash Bros. - SSB64
Super Smash Bros. Melee - SSBM
Super Smash Bros. Brawl - SSBB
Super Smash Bros. for Nintendo 3DS / Wii U - SSB4
Super Smash Bros. for Nintendo 3DS - SSB4-3DS
Super Smash Bros. for Wii U - SSB4-WiiU
Super Smash Bros. Ultimate - SSBU

Kirby: Right Back at Ya! - KRBaY

What say you all? Vote below or voice any suggestions you may have. --YFJ (talk · edits) 21:59, 23 January 2021 (UTC)

Support

1. I say yes, as we need more consistent abbreviations.--kirb 22:01, 23 January 2021 (UTC)
2. I've no issue with this set of abbreviations, as I believe we've done a more than adequate job of ironing them all out. I am looking forward to having a consistent set of abbreviations on the wiki for file naming purposes. --Samwell (talk) 22:02, 23 January 2021 (UTC)
3. Abbreviations being inconsistent is a major problem that needs to be fixed. This fixes that, so support. ---PinkYoshiFan 22:03, 23 January 2021 (UTC)
4. Support. I'm guilty of adding a lot of the superfluous abbreviations myself, and it's better to be concise and consistent. StrawberryChan (talk) 01:06, 24 January 2021 (UTC)
5. The abbreviations chosen above should do well, and having consistency would be a good idea, so I support. -- Jellytost♡ (talk) 21:08, 24 January 2021 (UTC)
6. Abbreviations are looking really simple and clean for file naming, so I'm on the support side. Hexelectron (talk) 10:14, 25 January 2021 (UTC)
7. Consitency is good and all that. Superbound (talk) 18:34, 25 January 2021 (UTC)
8. Best to have only one abbreviation per game, and the choices are all good. - Gigi (talk • edits) 18:56, 27 January 2021 (UTC)
9. Only having one abbreviation per game brings more consistency which is a good thing. And the choices are the most common abbreviations for their respective games.Infinite Possibilities (talk) 14:04, 30 January 2021 (UTC)

Oppose

Neutral

Add Colored Titles to Dream Friend Pages (January 19th, 2021 - February 2nd, 2021)

The title of the Kirby page uses a custom color for the font, pink. As of Kirby Star Allies, each of the delineated Dream Friends were given a specific color for their name and two colors for the background of their summon screen. I propose that we add a custom color to the titles of the Dream Friend pages. While there could be some debate for which colors to use, I think the colors used specifically for the character's names makes the most sense. My logic is, we have specific colors associated with each of the Dream Friends, and a method of adding color to individual page titles. It would be a fun visual flair for characters highlighted as important to the series. The only drawback currently is that the special font that Kirby's page uses isn't currently on every Dream Friend's page, as the font is used exclusively for featured pages. That being said, we could vote to add the color once each character's page gets featured, and add color to the ones that are currently using the font. Either way, it would be a nice use of the (at the time of posting this proposal) new font's color feature, and exemplify a little bit of extra trivia from the Kirby series. LeoUnlimited (talk) 02:55, 20 January 2021 (UTC)

Support

1. I support this; it'd be a cute detail. I could work out the colors for each of them once this passes and they're featured. StrawberryChan (talk) 02:58, 20 January 2021 (UTC)
2. I concur, granted we can get all the Dream Friend articles featured. After all, would be a shame to add the color to a page that was not up to snuff. --Samwell (talk) 03:05, 20 January 2021 (UTC)
3. Colors, colors, everywhere, I want them on the names all around. And that gives me a huge support, for they are super ultra astound! On a serious note, however, that's a nice little detail and I'd like that, especially if Kirby's title color is pink. Hexelectron (talk) 03:07, 20 January 2021 (UTC)
4. Yes. Color good. Much add.--kirb 03:08, 20 January 2021 (UTC)
5. I feel that, since we do this for Kirby, it's only fair we do it on Dedede, Meta Knight, and Bandana Waddle Dee as well. And I'm certainly not opposed to doing it for the other Dream Friends, too. --YFJ (talk · edits) 03:18, 20 January 2021 (UTC)
6. It would be a nice touch to the Dream Friend articles, and it will do no harm, so I support. -- Jellytost♡ (talk) 05:50, 20 January 2021 (UTC)
7. It would be a nice touch, but we should only use the special font if it's already an FA, and instead just colorize the preexisting font if not. ---PinkYoshiFan 12:59, 20 January 2021 (UTC)
8. I also support this, even if as of right now most Dream Friend articles aren't featured; the ones that are at least deserve some color. - Gigi (talk • edits) 17:32, 20 January 2021 (UTC)
9. I support this; it would add more variety to the article titles. Hopefully we can get all the Dream Friend articles featured so they can all have colorful titles. --DeepFriedCabbage 18:58, 20 January 2021 (UTC)
10. I don't see anything speaking against it. It would set them apart more from regular articles and is a cute asthetic. Infinite Possibilities (talk) 16:26, 23 January 2021 (UTC)

Oppose

1. I would prefer plain white over other colTemplate:Or, but that's not the main reason I'm opposing. I don't like how the proposal affects only Dream Friends. Other featured characters should be treated as equal, as they are (mostly) the same but still high quality. Superbound (talk) 18:34, 25 January 2021 (UTC)
2. I doubt that this changes the end impact, but I want to emphasize that this creates an even larger inconsistency amongst page design and its one that I would drastically prefer to not exist. Trig Jegman - 14:47, 26 January 2021 (UTC)
3. It works for Kirby since it's pinkish on pink background, however looking at most Dream Friends' main colors I'm can't imagine they would work as text color (except for Meta Knight and blue at some extent). Take King Dedede (blue, yellow, red) and Daroach (grey, red) for example. It would also create inconsistency and some people prefer less (clashing) colors. —Viperision (talk) 10:18, 2 February 2021 (UTC)
4. Thinking about it, I'm more convinced by the opposition here, than the supporters above. Consistency is important. --pandakekok9 (poyo) 10:46, 2 February 2021 (UTC)

Neutral

Discussion

If the proposal passes, why don't we go full aetjic and color other things in the pages, like tables? Superbound (talk) 18:34, 25 January 2021 (UTC)

Perhaps a few colTemplate:Orful touches to the wiki could do nicely, but we mustn't make anything too colTemplate:Orful since I know there are plenty of users who wouldn't take very kindly to vivid colTemplate:Ors. -- Jellytost♡ (talk) 04:58, 30 January 2021 (UTC)

I think it's important that this doesn't open the floodgate to full inconsistency for the sake of playful design. This is about the upper limit, in my opinion. I can definitely see the reasoning against doing so, and keeping it solely to Dream Friends is important with regards to establishing a boundary. StrawberryChan (talk) 12:22, 2 February 2021 (UTC)

Though the proposal has technically passed, I would like to show some examples of colored title text: King Dedede, Meta Knight, and Bandana Waddle Dee. These are based on the two-tone colors used by their Dream Friend icons. Any thoughts before the full go-ahead? StrawberryChan (talk) 22:31, 3 February 2021 (UTC)

Replacing the image-based title font (January 5th, 2021 - January 19th, 2021)

This has been a bit overdue, and I'm not really sure how detailed this needs to be, but I'll go ahead and do my best to explain it. Basically, the "title font" (currently used for the titles of featured articles, as well as a few odds and ends like the old home page) is based the font from Kirby's Dream Collection and works by using individual sprites of each letter, which are then converted from text to images. Aside from being somewhat slow and inefficient, this presents a major problem for those who use screen readers: since the title font is not an actual font, the screen reader will not read the title properly, thus resulting in missing information for people with blindness or visual disabilities. This isn't an insignificant portion of people, so it can't just be ignored.

The solution was to find a way to convert the title font to an actual font rather than images. While the actual font, Pop Happiness, is free to download for personal usage, using it in commercialized work requires an expensive license, and since the wiki has ads running, this is not feasible. We were able to find a workaround by using a free substitute, Delfino, which is based on the same font (it's traced from the dialogue in Super Mario Sunshine, hence the name). It's not a perfect recreation, but it gets the job done, and solves the above problem as well as looking cleaner in close-up. Delfino has been implemented on the wiki's server and is currently being used on the main page. There is already a template ready to go, so the final step is properly implementing it across the wiki.

Image-based title font:

     

Text-based title font:

Hello world!

Above is a comparison between the two methods. A major benefit to the image-based title font are that it's more accurate to the games, but the cons are that it's screen-reader incompatible, blurry at higher resolutions, takes longer to load, and inflexible (new characters require new images). By contrast, the text-based title font is less accurate and a bit choppy at extremely high resolutions, but it being an actual font is a major boon; it can scale to any size, it's faster to load, compatible with screen readers, and can be formatted in any way as long as it's CSS compatible. Because of this, I believe it's the best approach to implement and switch to it. StrawberryChan (talk) 02:38, 6 January 2021 (UTC)

Support

1. Of course. I think accessibility as well as infinite scalability (which the PNGs didn't have due to being bitmap) is a huge plus IMO. --pandakekok9 (poyo) 02:49, 6 January 2021 (UTC)
2. This would make screen readers (and copy-paste, the thing that started this back in August) work, which is a big plus. Also would help simplify the template further. ---PinkYoshiFan 23:06, 9 January 2021 (UTC)
3. While the text-based one's outline is a bit too thin, this improves accessibility and loading times. --DeepFriedCabbage 01:56, 10 January 2021 (UTC)
4. Also agree! Never thought that added accessibility would be a key component in resorting to text instead of imagery. – Owencrazyboy17 (talk) 02:34, 10 January 2021 (UTC)
5. It seems things will be more efficient this way, and I see no problems with making the change, so support. -- Jellytost♡ (talk) 06:03, 11 January 2021 (UTC)
6. Looks like benefits outweigh the take backs by a lot. Supporting. Superbound (talk) 12:30, 16 January 2021 (UTC)

Oppose

Neutral

1. I believe this was already going to happen regardless, we just had not gotten around to it yet, so I am not entirely sure a proposal is necessary. --Samwell (talk) 02:40, 6 January 2021 (UTC)

I thought the last step was to get final approval from the community before we went forward with it? Otherwise, I was just waiting for nothing. Which, I mean, I wouldn't put past myself. :p StrawberryChan (talk) 02:43, 6 January 2021 (UTC)

Discussion

Just one question, if the proposal passed, is Delfino font going to be implemented by changing {{Title font}} directly or totally new template will be created, while the image-based one will remain for archival/other purposes? Superbound (talk) 20:00, 9 January 2021 (UTC)

{{Title font}} will be changed and the image-based one will be moved to {{Title font (old)}} or something like that. StrawberryChan (talk) 13:39, 10 January 2021 (UTC)

Perhaps {{t|Title font image}} or {{t|Pop Happiness font}} would be a better name? Superbound (talk) 12:30, 16 January 2021 (UTC)

For a preview of what it will look like on a featured article, see this page (permalink). There's this annoying empty space though, and I'm not sure what's causing it. pandakekok9 (poyo) 10:57, 11 January 2021 (UTC)

I looked at it some and it looks like the empty space is caused by the line breaks between the featured template, title font template, and infobox template. ---PinkYoshiFan 15:31, 11 January 2021 (UTC)

Adjust naming policy to prioritize romanized Japanese names over internal data names (December 19th, 2020 - January 2nd, 2021)

Currently, in the Naming policy, it is stated that internal file names have priority over any non-English official title. The reasoning for this was that these internal names, however temporary they may have been to the developers, were often easier to understand. However, this priority comes with a few notable caveats, which can be summarized as follows:

• It is hard to argue that internal names are really official, since they were not intended to be seen in-game or shown in promotional material.
• Internal file names are typically difficult to source, and many of the ones we use here are not sourced properly for that reason.
• For games like Kirby Mass Attack, Japanese names tend to be the only ones available, and tend to appear more frequently in-game, making them more legitimate than internal data titles.
• Recently, it has become a trend for external sources like the Kirby JP Twitter to provide additional information about otherwise anonymous enemies and other entities that appear in recent Kirby titles. The policy I think should be changed to better recognize this feed as a legitimate source of information on the series, whether it be in English or not.

So, what this proposal seeks to do in short is to change the order of the Priority in Naming as follows:

1. In-game names. Newer names have higher priority in most cases.
2. Nintendo-published promotional material, including instruction manuals, website blurbs, and Nintendo-published strategy guides. If there are multiple names used among these sources, those that are most distinctive and commonly used take priority.
3. Any officially licensed non-Nintendo-published strategy guide. If there are multiple names used among these sources, those that are most distinctive and commonly used take priority.
4. Any non-English official name, following the three above priorities as with English names. Romanized Japanese names take priority here.
5. Internal file names. Use only as a last priority, as these names tend to be either short-hands or early development names. However, these may be used as additional sources to back up names from point 3.
6. Conjectural names. Use only if there is no official name of any kind to be found.

What say you all? --Samwell (talk) 16:47, 19 December 2020 (UTC)

Support

1. Yes, in game names were not intended for use. Romanized Japanese names are not English, but still more official than dev names. --kirb 17:04, 19 December 2020 (UTC)
2. I agree as well. These names were not intended for the public to see, only for those developing the game and those sneaky little people who look in the game files after release. Non-English names that are mentioned in-game or in strategy guides (or even Twitter) should be prioritized instead of internal names, not the other way around. – Owencrazyboy17 (talk) 17:16, 19 December 2020 (UTC)
3. I was looking at the naming policy today and thought the same. Japanese names are usually (at least I think) more well-though, since as mentioned earlier are supposed to be seen as public, unlike data names (example: Haltworker). Kirby JP Twitter should also be acknowledged as a better source. Support. Superbound (talk) 17:22, 19 December 2020 (UTC)
4. Agreed. Non-publicly released titles used in early development definitely should not have priority over any official non-English title. It makes sense to use non-English titles before internal file titles. -- Jellytost♡ (talk) 18:43, 19 December 2020 (UTC)
5. Even if an official name is foreign, it's still official, and that's better than a placeholder we aren't supposed to see. ---PinkYoshiFan 19:31, 19 December 2020 (UTC)
6. Let's be honest, most of the internal file names we use are just nicknames used in development, and oftentimes in Japanese to start with anyway. I think this makes sense--and if we want English names, digging through official strategy guides is still an option. --YFJ (talk · edits) 19:11, 21 December 2020 (UTC)
7. Agreed here; Japanese names are still official and should be prioritized, even if they need to be translated. That being said, filenames should also be taken into account when it comes to how the Japanese names are romanized; for example, Grandy comes from the English filename, but matches the writing of the Japanese name. StrawberryChan (talk) 03:17, 22 December 2020 (UTC)
8. I'm agreeing as well.This solution seems more logical. Official none English names are way more reliable than internal file names, as those could be missunderstood more easily. Infinite Possibilities (talk) 20:35, 25 December 2020 (UTC)
9. Internal data names are starting to become really informal for me now that I think about it. I prefer Japanese or English names of various entities as they come from an official source, and internal data names may be a bit misleading, like with the case of Iron Ball, which could be easily confused by me for a wrecking ball. -- Hexelectron (talk) 01:34, 26 December 2020 (UTC))

Oppose

Neutral

Modifying the website for a Christmas theme (December 3, 2020 - December 10, 2020)

For the Christmas season, I think it would be a prudent idea to make WiKirby Christmas themed. All it would require is adding Christmas/Winter-related Fabrics into the main CSS file. As long as the fabrics chosen aren't too flashy, it would honour the season and make the site appear cozy. I have a preview, although the fabric chosen for the Upcoming Games section may be too bright.

The admin who enacts this should dim or lighten the fabric if it appears too busy. The current fabrics are dimmed, so this should not pose a problem.

I would suggest using this theme from as soon as possible (it is already Christmas season) to January 6, as that is the end of the Christmas season. --kirb 22:38, 3 December 2020 (UTC)

https://media.discordapp.net/attachments/323530530681520129/784183432334147654/Wikirby_Christmas.png?width=1025&height=456

Support

1. Makes sense to celebrate the season, although we should probably establish a date range for it. ---PinkYoshiFan 23:11, 3 December 2020 (UTC)
2. I agree. The range for this could be the rest of December after it passes (hopefully). It would make sense to also go the extra mile for Halloween, New Year's and the like, though that's just me... – Owencrazyboy17 (talk) 21:43, 5 December 2020 (UTC)
3. Support. I myself have considered requesting themes for Christmas and occasions similar, but it seems you've beat me to it. I would also support Owen's idea of doing this with other occasions as well. -- Jellytost♡ (talk) 23:14, 5 December 2020 (UTC)

Oppose

Neutral

1. This is easier said than done, I think, and it's a bit too late for me to fully support it in time for Christmas. It's a good idea, but I think we should work on the CSS themes during the "off season" so we don't have to rush them. StrawberryChan (talk) 04:59, 6 December 2020 (UTC)
2. It'd be better to not rush seasonal redesigns, but I'm not opposing. Since these are just for season/occasion celebrations, we don't have to be consistent with date durations (case basis). I can think of Christmas & NY and Halloween for full-on skin redesign, while Carnival (February 16th), AFD, Easter (April 4th in 2021) and such can be accompanied with minor additions. Troubling to find a decorative summer holiday (Marine Day?), everything seems to happen October-April. —Viperision (talk) 00:54, 10 December 2020 (UTC)

Discussion

(I think I'm allowed to discuss on my own proposal.) Some people are wondering about how quick the proposal will have to be enacted or about other seasons. It's actually not very difficult to change the skin; any interface admin just has to change the pattern files in the main CSS file. In regards to other seasons, while there might be some fabrics that match a certain season, we don't necessarily need a new theme for every holiday. We could just keep it to Christmas, unless it is requested that more holidays/seasons be added. (This proposal is only for Christmas.) The fabric images have mostly already been chosen. The date range for the Christmas season theme for later years should be December 1 to either December 25/26, or January 6, depending on what our definition of the end of the Christmas season is. --kirb 12:06, 10 December 2020 (UTC)

Sub-nomination for Featured pictures pertaining to occasions and holidays (November 25th, 2020 - December 9th, 2020)

After noticing that Featured pictures that are focused on certain occasions and holidays do not currently usually align with their appropriate days, as well as seeing a picture abruptly Featured and thrown onto the main page for Halloween, I thought a sub-nomination page for pictures pertaining to occasions and holidays would be a good idea.

My idea is pretty simple. Each occasion and holiday this sub-nomination page would cover (listed below) would have its own picture cycle exactly like the main one. Pictures in the cycles would change to a different one on every certain occasion and holiday. If the picture in the sub-nomination is voted in, it will be placed in a cycle for the occasion or holiday it states. (The pictures set up for nomination must state what occasion or holiday cycle it is going to be placed in if it gets voted in. That is the only voting rule here that is different.)

The sub-nomination would cover pictures pertaining to:

• Christmas
• Halloween
• Kirby's Birthday
• Easter
• Valentine's Day
• New Year's Day/New Year's Eve

(If you think an occasion and/or holiday should be added or removed, feel free to say so in 'Discussion'.)

Lastly, the Featured template on these would work how certain license do (a Halloween Featured picture for example would have {{Featured|Halloween}} placed on it).

What do you all think of this? -- Jellytost♡ (talk) 04:49, 25 November 2020 (UTC)

Support

1. Highly agree. That way we don't be cheating the system every single time like we did previously. – Owencrazyboy17 (talk) 05:03, 25 November 2020 (UTC)
2. I agree since it makes more sense than having holiday-specific FPs featured year-round, although how would we retroactively apply this to the already featured ones? ---PinkYoshiFan 12:06, 25 November 2020 (UTC)
3. Yes, it would be nice to have a Christmas image up for a month while still regularly featuring normal images. --kirb 01:43, 27 November 2020 (UTC)
4. Definitely agree. Fun little Kirby images can still stay up alongside a Dedede Santa Claus as a side-feature. So we don't mess up what we're gonna feature for the holidays. Hexelectron (talk) 05:23, 3 December 2020 (UTC)
5. I am in agreement to this, as it would allow for nice seasonal artwork to match the time of year rather than simply having holiday-themed artwork pop up in the queue whenever. If we do this, I would like for the holiday-themed images to be removed from regular rotation in the featured image queue. StrawberryChan (talk) 04:56, 6 December 2020 (UTC)

Oppose

Neutral

Discussion

I think it should include Kirby's birthday, but I'm also kind of iffy about Thanksgiving Day, as I can't remember any image that would that event. Superbound (talk) 15:55, 25 November 2020 (UTC)

Hmm, you're right about both. I'll go ahead and swap out Thanksgiving for Kirby's Birthday on the list. -- Jellytost♡ (talk) 08:08, 28 November 2020 (UTC)

Another question, how long are those cycles and when they will happen? Does this mean that images featured during cycles will never appear on the front page again? Superbound (talk) 10:55, 28 November 2020 (UTC)

Whatever week the occasion/holiday is in, a picture that has already been voted in to be featured will be featured for that week. Once this week ends, the normal cycle will resume. Also, no, the picture will be featured again. It swings around to older pictures that were voted in, just how the current featured picture cycle works. This answers your question above as well, Pinkyoshifan. -- Jellytost♡ (talk) 05:09, 3 December 2020 (UTC)

I don't think I understand. After the special pictures are featured, they are sent to normal queue like they were ever special? That sounds like feature fast-track with extra steps. Superbound (talk) 11:41, 3 December 2020 (UTC)

Let me explain the process and what I'm requesting in my proposal here:

This proposal is requesting a sub-nomination for the list of occasions/holidays listed above. Each occasion/holiday would get its own queue of pictures that were voted in through the sub-nomination. The pictures in each of these would cycle through each-other every certain occasion/holiday. For example, a Christmas picture that was voted in via the sub-nomination would be featured one Christmas. The next Christmas the year after would feature this picture again if there were no other pictures in the Christmas featured picture queue. It's almost identical to the normal queue.

They aren't really "special" pictures, only ones that would be featured on a certain week instead of any week of the year to avoid any oddness. The time a picture would be featured would be on the week of the occasion/holiday. Another example, a Halloween picture would be featured on October 26th, reach Halloween itself on the 31st in that week, and then the normal featured picture queue would continue on the Sunday of that week, featuring a regular picture. This would make it so a picture pertaining to a certain event would be featured sometime around the day, and on the day as well, while not harming the regular queue in the process.

Understand? I believe that is my full concept. -- Jellytost♡ (talk) 01:22, 4 December 2020 (UTC)

Yea, I think I understand now. Superbound (talk) 11:39, 6 December 2020 (UTC)

(reset indentation) I'd also propose we add a few Japanese holidays to the list since they have appropriate art from the Kirby JP Twitter (White Day, Marine Day, Hinamatsuri, Tanabata). StrawberryChan (talk) 04:56, 6 December 2020 (UTC)

Hmm... That is an interesting idea. However, I do not think those holidays are well known enough to have pictures featured for them. Also, the latter two pictures you linked to only barely exceed the size needed for a picture to be featured. -- Jellytost♡ (talk) 05:47, 7 December 2020 (UTC)

Abolish semi-protection for all mainspace pages (November 11th, 2020 - November 25th, 2020)

Alright. Since we've got the Moderation and Confirm Accounts plugins settled in at this point, it seems to me that retaining semi-protection for various articles (restricting editing them to only autoconfirmed users and above) is no longer necessary. I propose we remove semi-protection from all articles that have them and abolish the idea of using semi-protection in the future on mainspace content.

Keep in mind, this does not apply to full-protected articles (those that only Admins+ can edit). Those will remain as is. Also, users can still have their user pages and related pages semi-protected if they want.

What say all ye? --Samwell (talk) 19:35, 11 November 2020 (UTC)

Support

1. Yes. Semi-protection is meant to deter vandalism, but the extensions completely eliminate it, and the redundancy is unnecessarily restrictive. ---PinkYoshiFan 19:38, 11 November 2020 (UTC)
2. Agreed on it being redundant and non-user-friendly now. StrawberryChan (talk) 19:45, 11 November 2020 (UTC)
3. I thought about it and decided that it is unfriendly to new users when many pages about main aspects of Kirby are blocked from editing. It will discourage new users, because they probably would not want to start their editing career on an obscure page. And as others have said, there are anti-vandalism measures in place already. I do beleive that certain pages should have protection, such as user pages and talk pages. --kirb 14:48, 18 November 2020 (UTC)
4. I also agree on that notion. Since we already have tools in place that effectively prevent vandalism, why bother semi-protecting mainspace articles? Of course, user pages and talk pages should be exceptions to that rule, as I found out the hard way a few months back... Per all. – Owencrazyboy17 (talk) 17:21, 18 November 2020 (UTC)
5. Oh yeah, user pages and talk pages should definitely stay protected. But for the normal articles, such protection is indeed redundant. Superbound (talk) 18:39, 18 November 2020 (UTC)
6. Per all reasoning above. While I can understand Trig's point and slightly agree with it, I think abolishing Semi-protection will be fine, since having it as an extra layer of protection isn't greatly needed when Moderators are already on the watch. -- Jellytost♡ (talk) 03:49, 19 November 2020 (UTC)
7. Moderation just already does what semi-protection seeks to do, and it's more effective while reducing roadblocks to anonymous users. I don't see a real downside. --YFJ (talk · edits) 03:56, 20 November 2020 (UTC)

Oppose

Neutral

I think that there are some general pages that do not need this anymore, but I would still consider leaving it for a few of the largest pages such as Kirby or King Dedede, as generally these pages will see the most attempts to vandalism, and would perhaps encourage the creation of an account instead. Talk pages could also be utilized. Trig - 19:45, 11 November 2020 (UTC)

Discussion

Bump. Should be archived. Superbound (talk) 10:55, 28 November 2020 (UTC)

Tweak minimum voting requirements for proposals (September 10th, 2020 - September 24th, 2020)

So, when I first set up this system, I sought to only allow senior users to vote by specifying that users could not vote on proposals unless they had been registered on the wiki for at least two weeks and have made at least 100 edits to mainspace. While I still believe that users should not be able to make accounts and then immediately vote on proposals, I have a simpler method of determining eligibility.

I propose that voting rule #1 be changed to read as follows:

• Proposal adding and voting is open only to registered users who have attained autopatrol status or above.

This to me will simplify the process and give the WiKirby staff a little more freedom in determining voting rights, since autopatrol can be granted at any time to users who show good editing spirit. Let me know what you guys think of this idea. --Samwell (talk) 15:38, 10 September 2020 (UTC)

Support

1. You, my friend, are a genius. I agree with this change; 100 edits and two weeks is kinda cumbersome when it would be easier to have it bestowed to you sooner as long as the edits aren't all bad. – Owencrazyboy17 (talk) 16:03, 10 September 2020 (UTC)
2. I wasn't actually aware that the requirement wasn't just being autopatrol. Sounds good to me. StrawberryChan (talk) 19:35, 10 September 2020 (UTC)
3. As mentioned in the proposal, this will simplify the regulations and let anyone who edits in good faith vote, which are both good. ---PinkYoshiFan 23:40, 10 September 2020 (UTC)
4. Yea. This is a much simpler way to go about the rule, and Proposal voting will be considered by whoever feels that a certain user should be marked as autopatrol. Honestly, even if this is just a small tweak in the rules, it makes autopatrol an even more important, and trusted role. MetaDragon (talk) 01:09, 11 September 2020 (UTC)
5. I support. Funnily enough, earlier this year I accidentally voted on a proposal before I had 100 mainspace edits, which then was reverted, but I was already on the autopatrol usergroup back then. So I was already a trusted editor, but without a certain number of edits I couldn't vote on proposals. I would rather have trusted editors in general vote than editors that edited a certain number of times, because quality and quantity are two different things. - Gigi (talk • edits) 01:52, 11 September 2020 (UTC)
6. Per Owen and Gigi, no rank or voting right should be edit-gated, as easy as it is to do 100 uselessly minor edits or have to wait 2 weeks which equals a whole individual proposal duration. It'll effectively be a clean and valid editor approval system. —Viperision (talk) 06:52, 11 September 2020 (UTC)
7. Per all. This makes a lot more sense. I agree with this change. --DeepFriedCabbage 17:18, 16 September 2020 (UTC)
8. I suppose this makes sense. There's no automatically bestowed right after 100 edits anyway, so this makes it a lot easier to check voting eligibility. I agree that 100 edits does feel kinda arbitrary as well. --YFJ (talk · edits) 17:54, 16 September 2020 (UTC)

Oppose

Neutral

Discussion

Also, if this passes, I will create a badge template similar to the staff rank badges to hand out to all active users who have autopatrol status, so there's no confusion. Y'all will get this badge on your user pages: --Samwell (talk) 15:43, 10 September 2020 (UTC)

What will on another hand be an autopatrol rank regulation, other than "cherrypicking" editors who get noticed? Say if we were to get a great amount of new editors doing out RC a favour, but go unnoticed at the time and want to vote, do they just contact staff for it? We have the requests through election form but this is just autopatrol. —Viperision (talk) 06:52, 11 September 2020 (UTC)

Just to be sure, the proposal affects only voting, and non-autopatrolled users will still be allowed to participate in disccusion? Superbound (talk) 11:06, 11 September 2020 (UTC)

To answer Viperision, the process of picking autopatrol will still be done manually by staff, but general qualifications for the role are relatively slim. Typically, all a user needs to be added to autopatrol is good editing history and at least a week or two of activity.

To answer Superbound, yes, users who cannot vote yet can still participate in discussion. --Samwell (talk) 18:16, 12 September 2020 (UTC)

Add a process for revoking a page's "Good" status (August 6th, 2020 - August 19th, 2020)

For a while, after a page was marked "Good" by a patroller+, it was a permanent status. That was changed a while ago with a proposal, however, and now a page may have its "Good" status revoked by patrollers+:

In the case of Good status, patrollers+ may revoke it at any time if it no longer meets the requirements for such status. At least one (1) week should pass before it can be returned to Good status. ~WiKirby:Featured content policy#Unfeaturing an article

This sounds good on paper, but usually when a page is marked "Good" and suddenly doesn't meet the requirements anymore, it's due to some improvement templates. Many times it takes an editor or two to take their time to improve whatever is asked, and the page meets the requirements again. So, many times, it's counterproductive to remove the "Good" status, only for hours later it be edited to meet the requirements again, but a week has to pass before it can get its "Good" status back.

So, my proposal is to instead add a process for revoking a page "Good" status, as follows:

• A patroller+ finds a "Good" page that no longer meets the requirements
• Said patroller+ adds a "Candidate for 'Good' status revocation" notice to the page
• Then they go to the page's talk page and explain their reasoning for flagging the page as such, and ask the opinion of other editors
• Other editors comment on the talk page, agreeing or disagreeing
• Ideally, work is done in the page flagged so that the proposed revocation is avoided
• If the issues outlined by the patroller+ are fixed before a week has passed since the start of the discussion, they should remove the notice from the page and end the discussion
• If at least a week has passed, the issues outlined weren't fixed, and there's no disagreement from other editors on the revocation, then the patroller+ may revoke the page's "Good" status and remove the notice

I know this may sound a bit too long of a process, but this isn't much different from when for example we want to move a page to a new name, or split a page's section. I just wanted to detail it to make my idea clear enough. Also, yes, if this passes, a "Candidate for 'Good' status revocation" notice will be created, and only patrollers+ may add it to pages and start the process as I outlined.

(Finally, I want to credit Samwell for the idea of the creation of the notice template for this proposal. Thanks!) Gigi (talk) 00:22, 6 August 2020 (UTC)

Support

1. While it is not the method I would personally take, I do believe that this will be a better process than just allowing a page's Good status to be revoked at any time and then having to wait a week to reinstate it, so I support. --Samwell (talk) 03:53, 6 August 2020 (UTC)
2. Better than the current system, so per Samwell. ---PinkYoshiFan 21:02, 7 August 2020 (UTC)
3. After some time and consideration, I have decided to support. This method is much cleaner than the original and makes marking a page as "Good" that much more important. MetaDragon (talk) 23:09, 7 August 2020 (UTC)
4. Support; it seems like the best way to handle this, and a week seems like the right amount of to make it a fair vote. StrawberryChan (talk) 04:59, 16 August 2020 (UTC)
5. Changing my vote to support: since this system will probably go through some adjhstments, we can try this out Superbound (talk) 14:55, 18 August 2020 (UTC)

Oppose

Neutral

1. This seems to be a suitable process. In my opinion, opening discussion for revoking "Good" from a page is a great idea, however, the process is quite long and dragged out. I will stay neutral for now, it is a matter that I will have to consider more deeply. MetaDragon (talk) 02:03, 6 August 2020 (UTC)
2. As Superbound and MetaDragon said, this seems too long and drawn out, but I guess it's better than the current system... ---PinkYoshiFan 11:07, 6 August 2020 (UTC)
3. Gonna stay neutral on this. I'll admit the current process isn't great but I agree with the other neutral voters in that this process is a bit too drawn-out for my liking. This system has merit but moving from "not structured enough" to "too structured" doesn't really help matters much. --YFJ (talk · edits) 05:41, 18 August 2020 (UTC)

I also think it can be too long, however I need to think of it more deeply, so I may change my vote. Superbound (talk) 06:56, 6 August 2020 (UTC)

Discussion

Wait, does this process is for articles only or for files too? Superbound (talk) 07:48, 6 August 2020 (UTC)

They said page and not article, so probably both. ---PinkYoshiFan 11:07, 6 August 2020 (UTC)

I was considering it to apply for both. Gigi (talk) 14:53, 7 August 2020 (UTC)

For those that are claiming that the process is long, how would you shorten it? Gigi (talk) 14:53, 7 August 2020 (UTC)

I thought about "If nomination gets X support/oppose votes, it will pass/fail instanly", however, this rule shortens the amount of time fixes can be done, but on the other hand, if fixes are done after the hammered nomination, then it can be regooded, do I dunno Superbound (talk) 15:23, 7 August 2020 (UTC)

A week just seems a bit too long... Maybe like three days? Or would that be too short? ---PinkYoshiFan 19:15, 7 August 2020 (UTC)

A week for me feels like a reasonable time to fix whatever issues are present and, if that's not enough time, then the status should be lost. If it's three days, it could start and end on weekdays, and editors may not possibly have the time to work on the page at all during that time due to work/school. And, like I wrote in the proposal, if the issue is small and can be fixed quickly enough, like in one day, then the process ends early. I really don't see the issue with leaving it at one week at most all things considered. Gigi (talk) 20:51, 7 August 2020 (UTC)

Ok, I misread it at first and didn't realize that it ended early if the issue was resolved. ---PinkYoshiFan 21:02, 7 August 2020 (UTC)

I think this system would be great with some kind of promoting to fix issues of "Ungood nominees". However, I have no idea how to do that :\

Also, "other editors" means that any user (including IPs), will be able to vote? Superbound (talk) 08:34, 11 August 2020 (UTC)

↑? Superbound (talk) 04:15, 17 August 2020 (UTC)

Since it won't be a formal vote, I suppose we could allow everyone. Personally, I don't see any anonymous editors participating in a discussion like that anyway however. Gigi (talk) 14:07, 17 August 2020 (UTC)

It has been a (slightly) informal rule since the beginning that voting requires a signature. Since IPs do not have accounts or names, they cannot sign. Therefore, they cannot vote. --Samwell (talk) 14:22, 17 August 2020 (UTC)

Ah, fair enough. Gigi (talk) 14:33, 18 August 2020 (UTC)

Just a quick note: I don't intend to make this process a final one at all, in fact I encourage us to try it out a couple times if it passes, and then we can adjust whatever we feel is needed. Gigi (talk) 14:33, 18 August 2020 (UTC)

Ah, ok Superbound (talk) 14:55, 18 August 2020 (UTC)

Combination of Personal Image and Personal Audio; Changes to Policy (August 4th, 2020 - August 18th, 2020)

In my attempts to help reduce unused content, I have stumbled across Template:Personal Audio. Nobody at this time uses this template, and I don't necessarily see why we must distinguish between the two types of media in the WiKirby:Personal content policy. It feels unecessarily restrictive, and has not proven to be of any significant conflict in the past. Since no one is utilizing the two forms of personal content, and there is not much of a reason to distinguish the two, I suggest the following changes are made:

Current suggestions:

• Combine personal audio and personal images template/category into personal media/personal file
• Change policy to allow 5 total files (instead of 3 and 3)
• Change policy page accordingly.

Trig Jegman - 17:23, 4 August 2020 (UTC)

Support

1. Makes sense, especially since personal audio is unused, so per proposal. ---PinkYoshiFan 17:32, 4 August 2020 (UTC)
2. I also support this. There wouldn't be much reason to have a lot of personal audio files anyway, outside of very specific cases, so just making it "personal media" makes sense. StrawberryChan (talk) 19:52, 4 August 2020 (UTC)
3. I agree with all other supporters in this matter, I have never seen any user with personal audio. It seems fair to merge these. MetaDragon (talk) 00:39, 5 August 2020 (UTC)
4. Support, it will be good to take it (Personal Audio) out of unused categories. Superbound (talk) 19:11, 6 August 2020 (UTC)
5. Nobody really has any personal audio, nor do I see anyone uploading much in the future. Merging sounds like a good idea. Support. --YFJ (talk · edits) 05:41, 18 August 2020 (UTC)

Oppose

Neutral

Implement image cycle for Featured Images (June 14th, 2020 - June 28th, 2020)

A while ago, we had proposal regarding cycle for Featured Articles. Citing YFJ:

“

So I noticed that we have a rather large catalog of previously featured articles, which are perfectly suitable to feature on the main page, but were only ever featured once. While we have no shortage of good articles eligible for featurement, it doesn't quite feel right to just leave previously featured articles behind. Is Kirby's Dream Land 2 doomed to never appear on the main page again? Would it have to be refeatured? Neither option sounds very great, so I propose we implement FA cycling. It would work like this: every Sunday at 00:00 GMT, the current FA will be replaced by the next one on the queue. New featurements will automatically take the next spot on the queue. [...]

”

— -YFJ (talk · edits)

The same could be said about FP, and I propose the same solution regarding pictures. The system would start on nearest Sunday from this proposal passing. I would also like to add that some images like this which (from my understanding), got featured but never appeared to Main Page. Images are important, since they add real visual on this wiki. What you all think? Superbound (talk) 16:00, 14 June 2020 (UTC)

Support

1. I agree. Makes sense to have a cycle for both, not one or the other. – Owencrazyboy17 (talk) 16:30, 14 June 2020 (UTC)
2. This wasn't already a thing? ---PinkYoshiFan 13:07, 15 June 2020 (UTC)
3. I didn't do this earlier since my main concern was getting FAs refeatured, although I did plan to do this somewhere down the line. As long as unfeaturements for pictures become a thing as well, I support. --YFJ (talk · edits) 18:18, 16 June 2020 (UTC)
4. Same for Featured Article cycling. If we only focus on the latest one, the others will lose their spotlight. --DeepFriedCabbage 18:29, 18 June 2020 (UTC)
5. Yes, this should be applicable to all featured content (the only other one now and needing some love being WiKirby:Featured Video Nomination). There's no endless supply of images to feature, and some never get to be seen years after having been featured. —Viperision (talk) 00:11, 28 June 2020 (UTC)

Oppose

Neutral

Proposals usually don't get any votes after first 24 hours, so here's bump. Superbound (talk) 07:38, 16 June 2020 (UTC)

@YFJ: I didn't propose unfeaturements because it didn't make sense to me - what you see is what it's gonna be. Images can't be outdated, and stuff like size can only change when reuploaded, which can be easily tracked, and only image that could be unfeatured would be File:KSSU Ice Artwork.png. Looking back at it... it sounded better in my head :/. Unfortunately, I think it's too late to change proposal, so it's gonna require seperate one. Superbound (talk) 09:12, 18 June 2020 (UTC)

Yeah, I gotcha. Images really can't become outdated the way standard articles can, although I do think there should be a way to reverse FP nominations regardless. It isn't urgent but I feel there are a few FPs that...really shouldn't have passed in the first place. But I'm cool with saving it for another time. --YFJ (talk · edits) 17:17, 27 June 2020 (UTC)

Song titles (April 24, 2020 - May 8, 2020)

This isn't much of a major proposal, but it's something that came up while talking in the Discord; a change to the article naming policy specifically for songs. Right now, the current policy is to use the latest name regardless of circumstance, and while that works fine for characters, places, objects, or other things that have been renamed in localization over time (like Pop Star to Planet Popstar), it doesn't fully work for songs, since oftentimes remixes will use new names that only apply to that remix, not the song as a whole. (For example, just because the remix of "Green Greens" in Planet Robobot is called "Re: Green Greens", it doesn't mean every version of the song is now retroactively called "Re: Green Greens".) With that in mind, the proposal is essentially a minor footnote to be added to the naming policy:

• In the case of music, the latest title should be used only as it applies to its original incarnation, and not any remixes.

This would also result in a few articles here and there being renamed, such as "A Well-Earned Rest" to "Ripple Star: Stage Select" (which had previously been proposed, but shot down under the current policy). Does that sound okay? StrawberryChan (talk) 21:19, 24 April 2020 (UTC)

Support

1. Yes 2: The return of Yes. In the case of A Well-Earned Rest, the remixes are clearly named differently, since they serve different purposes. But the articles should represent the... representative version of the song, usually being the original song, so the original title should be used as well. --Cowguy™ [talk · contribs] 21:52, 24 April 2020 (UTC)
2. Yeah, remixes should not be retcons for song titles, and this will simplify things. Per all. ---PinkYoshiFan 22:20, 24 April 2020 (UTC)
3. Completely agree. Many songs fall into this category, and it really doesn't make sense to consider the song's name to be the name of a remix that came years after and has nothing to do with the original theme. Another good example of this is Dark Castle's theme, which under the current policy is supposed to be named "Neon Laboratory", due to its Planet Robobot remix, and I don't think I need to explain why the later name for the theme isn't ideal. Gigi (talk) 23:09, 24 April 2020 (UTC)
4. I don't particularly like the use of remix. Generally, it's that song's main motif used more than the actual song. Either way, better distinctions should be made for at least songs that are remixed and songs that have sections and the use of what name goes where. Trig - 01:20, 25 April 2020 (UTC)

Oppose

Neutral

Discussion

I fully agree with this proposal. Additionally, oftentimes the only official name for a song is for a rearranged song that doesn't make any sense in context of the original version, such as A Well-Earned Rest. Conjectural names should definitely be used in these circumstances. So support vote from me. Wait, what's that? Admins can't vote on proposals? Blast. --YFJ (talk · edits) 21:32, 24 April 2020 (UTC)

Implement FA cycling and remove good/featured permanency policy (April 24, 2020 - May 8, 2020)

So I noticed that we have a rather large catalog of previously featured articles, which are perfectly suitable to feature on the main page, but were only ever featured once. While we have no shortage of good articles eligible for featurement, it doesn't quite feel right to just leave previously featured articles behind. Is Kirby's Dream Land 2 doomed to never appear on the main page again? Would it have to be refeatured? Neither option sounds very great, so I propose we implement FA cycling. It would work like this: every Sunday at 00:00 GMT, the current FA will be replaced by the next one on the queue. New featurements will automatically take the next spot on the queue.

In addition, with this change I am also proposing the introduction of unfeaturement. Our current featurement policy states this: "Once an article or image has become featured, it cannot be removed from the list of featured content. In the event that a featured article or image is made obsolete by new information, that obsolescence should be addressed as quickly as possible to keep it up-to-date." Sometimes, however, this is easier said then done, and sometimes we have articles such as Waddle Dee that were never eligible for featurement in the first place, and it just wasn't noticed upon its nomination. No article can keep its quality forever; it's just wiki nature. This policy also extends to good articles, and I think that as patrollers+ can add good articles, they should be able to remove them too.

If you have any suggestions or improvements in mind, be sure to let me know in the comments! --YFJ (talk · edits) 21:07, 24 April 2020 (UTC)

Support

1. What's the point of featuring articles if they only get a week of fame and a fancy icon? Plus, unfeaturing would be easier than updating articles, although there should be some time to update them before unfeaturing. I fully agree with the proposal. ---PinkYoshiFan 21:11, 24 April 2020 (UTC)
2. Agreed. It's good sense to be able to un-feature content especially so articles that are under construction don't get undue spotlight, and it allows for a more communal sense of building up content rather than just being one-and-done. StrawberryChan (talk) 21:19, 24 April 2020 (UTC)
3. Yes times 2. Or maybe 4. Or maybe 27. As Pinkyoshifan said, if an article only gets a week or two of recognition, well, then, it's not really getting the treatment that great articles like the featured ones should deserve, is it? Having featured article cycling sounds like a good idea to me. But this means that featured articles'll get more recognition, so removing articles that no longer are worthy of that recognition seems like it'd also be a good idea. This proposal definitely gets Cowguy's Seal of Approval™. --Cowguy™ [talk · contribs] 21:32, 24 April 2020 (UTC)
4. I agree. Featured articles should get more spotlight, not just when they have just been featured. And while ideally I wouldn't want to see articles losing featured and / or good statues, it may be needed for various reasons. Gigi (talk) 23:00, 24 April 2020 (UTC)

Yes. I actually thought unfeaturing was allowed here before, and was planning to unfeature 3 articles. Also, as for the cycling, it's good to have every featured article get the spotlight at certain points. --DeepFriedCabbage 21:46, 24 April 2020 (UTC)

Oppose

Neutral

Discussion

Forgot to mention this in the proposal, but unfeaturement nominations will take two weeks or a unanimous five-vote support for one side, just like featurement nominations. --YFJ (talk · edits) 21:14, 24 April 2020 (UTC)

That works. Also, will there be a page for all unfeaturing, or will it be on the talk page? ---PinkYoshiFan 21:16, 24 April 2020 (UTC)

It will be a subpage of WiKirby:Featured Article Nomination that holds all unfeaturement nominations. --YFJ (talk · edits) 21:21, 24 April 2020 (UTC)

Change featured article requirement 3 (February 7, 2020 - February 21, 2020)

As WiKirby's first-ever proposal, I would like to propose a change to our featured article policy; namely, requirement number 3, which states that, to be featured, "An article with an opening abstract of sufficient length, consisting of at least two paragraphs." This is a good guideline that encourages lengthy abstracts, but as we recently witnessed in the failed nomination of My Friend and the Sunset last week, this guideline can exclude articles that are perfectly fine nominees for featurement simply because they only have a one-paragraph abstract. Moreover, as nominater Fubaka stated over on Discord, introducing a second paragraph in this article would only cause redundancy, and that would actually lower the quality of the article.

This is a problem, but fixing it is a very easy and minor change. Simply rewording it to say "an article with an opening abstract of sufficient length (preferably consisting of at least two paragraphs)" would still encourage longer abstracts while avoiding redundancy scrapes. To be completely clear, this does not make all articles with one-paragraph abstracts automatically eligible for featurement. If an article's abstract is lacking in info, or a second paragraph could be introduced without causing redundancy, an oppose vote is perfectly valid. All this change would do is prevent predicaments like My Friend and the Sunset, where the only way to make it eligible for featurement would be to add a redundant second paragraph to the abstract. --YFJ (talk · edits) 23:04, 7 February 2020 (UTC)

Support

1. Scrooge200 (Talk) Allow me to make the first ever proposal vote, which will lead to the first ever featured article on a song. Scrooge200 (talk) 23:11, 7 February 2020 (UTC)
2. I concur such change for the solution of an issue it displays. —Viperision (talk) 13:39, 8 February 2020 (UTC)
3. I don't see why length has to be a requirement. ---PinkYoshiFan 23:03, 8 February 2020 (UTC)
4. I agree. There are definitely pages out there that don't need a second paragraph but deserve to be featured articles. --JRJ007 (talk) 01:23, 11 February 2020 (UTC)
5. Lending my support. I think an abstract isn't always necessary if the details can be better covered in the main article. StrawberryChan (talk) 20:55, 11 February 2020 (UTC)
6. I support this proposal. After all, one of the writing policies states "Short articles and/or sections aren't bad if there's not much to talk about." Two policies shouldn't contradict each other, and I don't think length should be a requirement. --Cowguy™ [talk · contribs] 01:31, 19 February 2020 (UTC)
7. Agree with literally everyone else for this particular proposal. Similar to what Cowguy said, short articles do not automatically mean they're bad. Sometimes there's not much to talk about, so trying to add more information would just be unnecessary fluff. – Owencrazyboy17 (talk) 01:52, 19 February 2020 (UTC)

Oppose

Neutral

Discussion

Keep in mind that administrators + may not vote on the proposal here. It will be our job to review the proposal and approve or veto it if it passes. That said, I see no reason why I would want to veto this proposal. --Fubaka (talk) 23:08, 7 February 2020 (UTC)

I concur a change. As "sufficient length" is not a conditional description, and may not always be compatible with the part that tells "opening abstract of at least two paragraphs" — FA previews sometimes reduce/remove less significant lede content (e.g. descriptions of Japanese names, lengthy "also known as" parts, etc.), but in my opinion they also shouldn't obligate to only containing lede content. This is subjective to each article. Otherwise, articles shall be worked on regardless of FAN-ing them and such criteria, and may not always be compatible with it.
On that topic, there's not a picture at all in a soundtrack article, let alone a lede one (of an infobox) — well obviously, this is a soundtrack, the substitute here is a sound-player.. well more of them, likely of "equal weight" for each game appearance.. but is any of that an applicable embedded main-page FA content? Alone, or within an infobox "compacted out" that'd be cut out to more significant infobox content (and match the FA container size)? Would we instead seek for other images, in this case possibly an excrept of introductory notes from (official) music sheets? —Viperision (talk)

When it comes to music pages, I typically don't think it's necessary to include images, since the article in question only covers audio. If there are applicable images, however, then it's usually good to include those, such as CDs, or scenes specifically associated with the music in question. --Fubaka (talk) 07:14, 9 February 2020 (UTC)