WiKirby:Proposals/Archive-2023

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

Proposals

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:Ice Kirby KSSU 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)