WiKirby:Proposals

Your opinions matter!
Welcome to the Proposals page. Here, WiKirby's editors may propose changes to the way the wiki operates, including how to handle certain categories of content, quality standards, or even just making aesthetic suggestions. Any user who has Autopatrol status or above may make a proposal or vote on one, and after two weeks of voting, if it passes, it will be incorporated into policy. Please see below for the specifics on how to make and/or vote on a proposal.
How to make a proposal
Please use one of the following templates to make a new proposal: Single vote: This is for proposals which only propose a single change to the wiki. ==(insert proposal here) (insert date here)== (insert details of proposal here and sign with ~~~~) {{Support}} {{Oppose}} {{Neutral}} ===Discussion=== {{clear}} Multi-option vote: This is for proposals which include many possible changes to a particular element of policy. One option should always be to keep things as they were. It is recommended that no more than 8 options are given in a single proposal, including the "no change" option. ==(insert proposal here) (insert date here)== (insert details of proposal here and sign with ~~~~) {{Option|1|(option title 1)}} {{Option|2|(option title 2)}} {{Option|3|(option title 3)}} {{Option|etc.|(option title etc.)}} {{Neutral}} ===Discussion=== {{clear}} Multi-facet vote: This is for proposals which want to make several smaller changes to a single element of policy (for instance, making several changes to how the main page looks). Each change needs to be voted up or down individually. There should not be more than 5 parts to a proposal like this. This type of proposal should not be made without approval from wiki administration. ==(insert proposal here) (insert date here)== (insert summary of proposal here and sign with ~~~~) ===Change 1=== (insert details here) {{Support}} {{Oppose}} {{Neutral}} ====Change 1 discussion==== ===Change 2=== (insert details here) {{Support}} {{Oppose}} {{Neutral}} ====Change 2 discussion==== ===Change 3=== (insert details here) {{Support}} {{Oppose}} {{Neutral}} ====Change 3 discussion==== etc. {{clear}} Once a proposal is made, the voting period begins (see voting regulations below). Voting period for a proposal ends two weeks after it starts, at 23:59:59 UTC on the 14th full day of voting. An administrator can veto a proposal at any time, although such action should always be justifiable and agreed upon by multiple admins. Administrators should not use this right to add more weight to their own opinions.
Restrictions
Users may propose many different changes or additions to the wiki. The following things, however, may not be voted on: Proposals which target specific users (such as bestowing or removing ranks or rights). Proposals which violate the law, as specified in the general content policy. Proposals which seek to overturn a recently (within the last 8 weeks (or 56 days)) approved proposal. Re-submitted proposals which were recently (within the last 8 weeks (or 56 days)) rejected, and which have not been significantly altered.

Current Proposals

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)

Oppose

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)

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)

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)

Proposal Archive

Successful proposals
Failed proposals

WiKirby's help and policy

Basic help

Getting started • Categories • Colors • Disambiguation • File uploading • Formatting • Formatting file pages • Moving pages • Protected Page • Redirects • References • Tables • Talk pages • Templates • User Navigation Bar • Userboxes

Advanced help

Advanced tables • Creating navmaps • Creating templates • Custom Signatures • HTML • Page history • Special pages • Tabs • Template documentation • Using infoboxes

Policies

Abbreviations • Article creation • Article manipulation • Audio standards • Blocking of users • Categories • Citing • Community polls • Conjecture • Cookies • Copyrights • Deletion of content • Disputes • Featured content • File use • Formatting specifics • General content • General disclaimer • Glitch disclaimer notes • Glitches • Image standards • Infoboxes and Navboxes • Interwiki • Language • Layout • Localization • Long pages • Naming • Non-Kirby content • Personal content • Privacy • Sourcing standards • Stubs • Talk pages • Trivia sections • User accounts • Videos • Writing style • Writing specifics

Useful links

About WiKirby • Affiliates • April Fools • Archive • Current events • Dedication • Discord • Featured Article Nomination • Featured Picture Nomination • Good recommendations • IPA • Maintenance (Project Clean-Up) • Proposals • Ranks (Bots • Check user • Editor-in-Chief • System Admin) • Sandbox • Social media • Special pages