Inkipedia talk:Ink Pump

The Ink Pump

Welcome to the Ink Pump. Similar to Wikipedia's village pump, the Ink Pump serves as a general place for the Inkipedia community to discuss the wiki as a whole, whether it be ideas, proposals, technical issues, or notices.

Remember to put new discussion sections at the bottom of the page.
You may also wish to view recent talk page discussions.
Archives available here. Inactive topics should be archived when this page reaches 40 topics or 50,000 bytes. Any Inkipedia user can archive the page.
Current page size is 35,296 bytes.

Establishing User Content Policy

I've been mulling this over for awhile now, but I believe now it is time to act: There is a lot of user-only content on Inkipedia. More specifically, there is a subsection of users that are using the platform more as a social platform or a fanon-driven sandbox than are actually developing the site and the important mainspace content. This doesn't fall in our scope, nor does it make sense in the broader sense of the platform to host these projects as they exist themselves. A bulk of the issue stems around the high volume of user images, although not exclusively. I propose that we push the site into a new direction, with one of the following three outcomes:

• (1) Establish a formal limit for personal content per user. The specific details of this can be established more specifically if people opt for this answer, although I suggest 10 files plus signature materials. This is the format near all affiliate NIWA wikis opt to use. (For example, WiKirby allows five files per user)
• (2) Expand/revitalize the 'Blog:' namespace to be supportive of Fanon content, establishing specific rules and guidelines on how those posts are made, managed, and maintained. User pages that meet the criteria would be integrated into this space. As an example, Fallout Wiki has an independent namespace for user projects and content.
• (3) Create a completely separate Fanon/social wiki space akin to Pikmin Fanon and the Fanon Wiki network.

Alternatively, we could do nothing, or, if someone else has a better suggestion, could be used instead. There could also be a hybrid of the options above. The long term goal is to encourage mainspace editing, and—with multiple users having 30% or fewer edits for the wiki compared to their user pages—it appears this is not the focus. This is a good way to get back on track to content based edits.
This is not supposed to be a specific attack on any one user, nor is it saying that the work being done has no value, however I believe it is time to evaluate its purpose on Inkipedia itself and where it should possibly move. Please feel free to vote or offer suggestions/responses below. Trig Jegman - 19:18, 26 January 2023 (UTC)

Option 1 definitely seems to be the most drastic, with many user pages and sandboxes consisting of many more than 10 images, however, it would also get the job done very well if your goal is to reduce the amount of user-only content on the wiki (which I’m assuming is the goal). Option 2 is my personal favorite. Bringing back the “Blog:” namespace is long overdue and it is definitely the least harsh option on here. Option 3 is a little confusing if I’m being completely honest. Like, I understand the point, but, why would we pick this option over the other two? It’s outclassed in both ways because it accomplishes neither of the goals as well as the other two. Thank you for listening to my TED talk, and have a great rest of your day! Jacobearth • chit-chat 21:43, 26 January 2023 (UTC)

Option 1 would be best; Option 3 is decent, but the creation of a fanon wiki isn't Inkipedia's business. I don't think it'd be fair to the bureaucrats to have them host and/or manage a separate looser wiki unless it's something they're on board with.

I strongly agree that this is an issue that needs to be addressed. Often I'll see users repeatedly make very long edits detailing the stories they have for their Splatoon OCs, or things like their extensive opinions about various Splatoon lore/updates/popular interpretations, to the point the amount of content on those userpages is better suited for a personal website (or, as you proposed, a separate fanon style wiki). I think restricting the amount of user images allowed per user in addition to the permitted length a user page can reach would help keep Inkipedia tidier, while encouraging new users to not turn their pages into what is essentially their own webpage, fully removed from being related to editing Inkipedia.

Wikipedia's policy on the matter is perhaps too strict for a videogame encyclopedia's standards, but worth consulting in the process of addressing this. I am personally very disheartened every time I see massive edits to userpages when I check Recent Changes. Inkipedia is not a host for people's opinions.

Option 2 is interesting and worth considering, but I fear allowing users to create blog posts (even within guidelines) would further enable the types of users that focus on editing their userpages to continue posting unrelated content. The best use of the blog namespace on other wikis I've seen have been blogposts regarding massive updates being made to the related wiki or wiki software, rather than being directly related to the content the wiki covers. I fear ushering the current unusual use of userpages towards the blog namespace might devolve into the style of Fandom wikis' talk board pages, which are notoriously full of users posting whatever's on their mind, wiki related or not. Yoshifan52 (talk) 22:24, 26 January 2023 (UTC)

Reminds me of the SmashWiki's probation thing, which I think should be somewhat implemented here in order to encourage mainspace edits. — Exaskliri _(they/them) (talk | contribs) 22:51, 26 January 2023 (UTC)

The only things that concern me are Options 2 & 3, as the former I'm wondering if the blogs will be protected from spam changes/reviews, as I'm very protective of my Fanon and don't want to see it discriminated. For the latter, I agree with some comments about it. This wiki is more organized and filled to the brim with official info to research on, while Fandom wikis, I feel, are a goldmine for spammy users and fan-generated content some might be uncomfortable with of disagree to. Yes, my Canon Sandbox is "so" dang big, as I may plan on dividing it into parts. The current one becoming the introduction to the world, battle rules and Splatfests. While the characters and story parts will become individual sub-pages (as they take up the bulk of my Sandbox now...), and have links to them in the former page. OR, as Yoshifan52 said, make some sort of form or private website to contain that content and have a link to it on my User page. But right now, I don't have the time, money "and" tech to do it yet, as I'm busy with irl stuff (finding a comfortable job, house chores, etc.) AND grinding in Splatoon 3 on the daily.

PS; I apologize that most my recent edits here were in userspace. I haven't had the time to add new info to mainspace or it has already been added. Sincerely, P.J. GT(talk) 23:47, 26 January 2023 (UTC)

You have edited your userpage almost 900 times; this, combined with the amount of content on it, is the exact kind of userspace editing behavior I think should no longer be allowed. Yoshifan52 (talk) 00:13, 27 January 2023 (UTC)

I don't mean to be subjective and begin an argument, but are you mentioning my user page or my Sandbox about the amount of edits? If its the latter, I can agree and possibly plan on either dividing its content into separate sandboxes or copy it into a private website or Google Form when I aquire my preferred tools to do it. P.J. GT(talk) 00:20, 27 January 2023 (UTC)

Your userpage's statistics page (not the sandboxes') says there have been 841 edits made to it, the vast majority of which were made by you. That is an extremely high number of userspace edits. Your main sandbox page has been edited 743 times, and its contents seem to be an extension of your userpage, rather than a proper sandbox; it is full of fanon information rather than tests of wiki features or prototypes of mainspace articles. Yoshifan52 (talk) 00:45, 27 January 2023 (UTC)

@Yoshifan52; That may be because of my system of updating my game stats weekly (Might change it to seasonal rn), grammar/spelling fixes, removal of might-be offensive content and my Splatfest/Big Run results. So should I ditch my ongoing Weapon Ideas table and delete it and trim-down some stuff? Also, this may be off topic but, should I split my Sandbox Page to separate Sandboxes each for an Intro/details, Characters, and Story pages respectively, or copy it over to a Google Dock/Drive or a private website? I'd be glad to have some help with that. Sincerely, P.J. GT(talk) 02:06, 27 January 2023 (UTC)

I like the probation idea mentioned by Exaskliri. I like option 1. I don't think option 2 or 3 would help. So, I want to go with some combination of option 1 and SmashWiki's probation process. Heddy (talk) 23:52, 26 January 2023 (UTC)

I'm in a similar mind, though I don't feel strongly for implementing a Probation-like policy. User image limit, yes. As noted, I don't really have additional energy to start/maintain a fanon wiki. I do think we need some policies that says what Inkipedia is not, and some guidelines on userspaces in a slightly more lenient way to the Wikipedia policy linked above. A quick reminder that you can filter out userspace edits from the recent changes (though obviously this can't be done for patrolling edits). Slate Talk Contribs 00:17, 27 January 2023 (UTC)

Would a decision here be made by a vote or a consensus? (As a side note, a personal image limit would be good, but maybe we could make a template for things like splatfests? Perhaps something like the translation template, where you can't click on the flags, but it still has the image? We could change out the flags for the splatfest icons, and we could have different parameters be options of [just going off what I see on other's pages] a personal choice, a synopsis, and stats? Just spitballing). Xando (ping) 21:31, 27 January 2023 (UTC)

There would need to be a consensus for any major change, per the consensus policy. Heddy (talk) 00:57, 31 January 2023 (UTC)

I like option 1 the most, I'd need a better explanation of what further guidelines other than limiting the number of files you can upload. I think the discord lately has been very focused on community matters than wiki matters so any socials can go there or to any other social media/blog/forum website. Shahar (talk) 14:19, 28 January 2023 (UTC)

I love option 1. Mostly just because I feel like I have too much userspace stuff. I end up using the time I have to edit that, anyway, so that should be limited. (Basically, I'm an amazing example of being too immersed in my userspace edits. :,) ) Arivaki-Kun (banter) 18:35, 28 January 2023 (UTC)

Although I'm not very active on here at the moment, I think this is a great idea. The purpose of this wiki it to provide info on the franchise, not to be a social media platform for fans. WoomyGirl85 (talk) 17:21, 5 February 2023 (UTC)

I am also a very immersed Sandbox editor, and I definitely could use a push to make Inkipedia a better place. Option 1 seems like a “cold turkey” way to limit these actions from happening, and would be a quick route out. I would be fine with any of these options, but it seems rather extensive to create another website to cater to us canon sandbox creators and similar folks of the wiki. I don’t really think the probation seems necessary unless someone is continuing to push the limits. All in all, I think that this is a great idea.

Clarinet.octo File:Marina.png (talk)File:S3 Tableturf Card Murch.png 03:13, 6 February 2023 (UTC)

---

To continue this effort, here is the semi-formal definition of a user image as well as three individual feedback points (number, subpages, lock to ac) for debate. I would like to know what you think will work best for the finalized policy so that way the proposed policy is the most supported option.

A user file is a personal file belonging to a user for the purpose of being used on their userpage or a related userspace page. Examples include images of personal Inklings, stats, gear, or fanart.

What constitutes a user file is purpose. Some files uploaded may be used on a namespace draft page—these are not user files as their end goal is to be integrated into a mainspace or wiki policy page. User files specifically are intended to remain in User: and Blog: namespaces.

A user may also have images to use for their signature. These files, given their unique usage, will also not be considered as a user file, although their amount should be kept minimal.

(1) Limiting user files seeks to increase efforts editing on-wiki. Here are several proposed guidelines (in general order from least to most strict):

• Ten user images, no greater.
• Seven user images, no greater.
• Five user images, no greater. This is the most common policy held by affiliate wikis.
• Three user images per year of active contribution (min of 36 constructive edits per calendar year).
• Ten user images plus a probation status akin to SmashWiki—if edit to userspace ratios don't line up, be unable to edit userspace until mainspace is addressed.
• Five user images plus a probation status akin to SmashWiki—if edit to userspace ratios don't line up, be unable to edit userspace until mainspace is addressed.

No account will have user content grandfathered in. All files exceeding the limit will be deleted on November 1st, 2023 (example date, but an established hard number with exceptional advance) at administration's discretion. Users will be asked to remove content prior as to only preserve the most important files for their space.

(2) Additionally, non-draft and non-maintenance user subpages should never exceed five regardless of the option voted on above.

(3) Lastly, a third proposal to lock the creation of User pages to autoconfirmed is suggested.

Please let me know your thoughts on all three policy changes as suggested above. Trig Jegman - 17:06, 11 February 2023 (UTC)

I think putting a limit on the amount of user files one can have is a great idea. Five user images sounds like the best choice.

I would like to point out that some new users are uploading random Splatoon memes and fanart without putting them on their user page. New users have also been uploading duplicate files. If there was anyway we could make it so only autoconfirmed users could upload files that would be a major help. By doing so we could lower the chances of unneeded files being uploaded. Odd (Talk) 17:45, 11 February 2023 (UTC)

@Oddlilgoof If someone is having difficulty learning to use Inkipedia and uploads duplicates as a result, I don't see how an autoconfirmed requirement would change that. If anything, it would just delay them learning file management until later.

An autoconfirmed requirement would not help the wiki, it would hurt the wiki by preventing people from uploading the files they joined the wiki to submit. When this autoconfirmed-to-upload requirement was tested in the past for Inkipedia, users would come to the Discord and complain that they can't contribute files. Just imagine the users who hit that wall and don't even have the energy to complain on Discord or on wiki, we would be missing valuable contributions without even knowing it.

Besides, an autoconfirmed requirement would be such a major change that I believe it would need a separate policy proposal anyways. My opinion is that the user content policy should focus on what content users can upload and maintain on their user pages, it should not focus on access restrictions. Heddy (talk) 04:45, 16 February 2023 (UTC)

@Heddy That does make sense. We can always just splat the duplicates and tell the user not upload duplicate files having them learn from their mistake. Many users come here to do good. I didn’t really think about how if we put a restriction on uploading files people would still upload duplicates by accident. Thank you for bringing this to my attention :) Odd (Talk) 12:17, 16 February 2023 (UTC)

Five images per user alongside a hard deadline by which everyone needs to tidy up their current user images sounds best to me. I'm still a fan of the probation period concept, but that's ultimately up to the admins, since they'll be the ones with that additional workload. I'm 100% for both file uploading and user page editing being limited to autoconfirmed users; another wiki I work on implements that, and I find it excellent at helping block out spam/obvious mistakes/users that create an account, then a user page, then never make any edits. Yoshifan52 (talk) 22:49, 11 February 2023 (UTC)

@Yoshifan52 autoconfirmed is too restrictive as an upload requirement. Imagine joining to make an important contribution and being told you need to wait 4 days + 10 edits for your account to be confirmed. Many users would just silently give up and we would be missing out on valuable contributions without even knowing it.

If someone is learning to use Inkipedia and uploads obvious mistakes as a result, I don't see how an autoconfirmed requirement would change that. If anything, it would just delay them learning file management until later. Heddy (talk) 04:49, 16 February 2023 (UTC)

Oh hmm, good point. Yoshifan52 (talk) 06:21, 16 February 2023 (UTC)

I should mention that we have the ability to create requirements completely separate from the autoconfirmed process. For example, 2-hour account age required to upload, or 2 edits required to create a user page. Though I do think such a discussion should be separate from this user content policy proposal. Heddy (talk) 02:23, 17 February 2023 (UTC)

The problem with locking user pages to autoconfirm is that autoconfirm is a very easy status to reach. Only 5 edits and 1 day are required to become autoconfirmed. With vandalism, this is very easy to do. I fear that users who want to use this wiki as a social media platform will simply make unhelpful edits in order to unlock the userspace. If we were to gatekeep the userspace like this, we would need to raise the autoconfirm requirements. (Additionally, I've only ever seen ads in the userspace, which is another sign of it being way too full) Bobby(talk) 02:08, 12 February 2023 (UTC)

Between it being relatively easy to become autoconfirmed, and blocks placed upon misbehaving editors only lasting a day or two, maybe Inkipedia needs to become a touch more strict when it comes to new users. Altering the autoconfirmation process (which I believe is handled by the system, not by staff going through lists of recently registered users) and/or directing less knowledgeable editors towards the rules a bit better on something like the main page could potentially help a lot. Yoshifan52 (talk) 07.24, 12 February 2023 (UTC)

I've been on and off about 20 or so wikis in my time and from what I have personally observed, I don't really believe in harsher autoconfirm=ensuring quality edits mentality. I think it only creates a more elitist spin and dissuades new or inexperienced editors from making attempts to make changes or contribute at all because the tools are not provided to them. This rings doubly true because Inkipedia is just kinda one of those places where it is people's first real wiki experience. If there's a unanimous agreement to restrict image uploading to AC, then I can add it in, but I'm pretty staunchly against the notion of increasing the AC requirements too significantly. Trig - 18:27, 12 February 2023 (UTC)

Good point, the resulting elitism could definitely be a problem. Yoshifan52 (talk) 23:41, 15 February 2023 (UTC)

I have not seen much discussion regarding the choice of image limit. I think I would like to start with an image limit of 10. 5 seems too restrictive, because the moment Splatoon 6 comes out, people who want an image of their character from each game will be devastated! Yeah probably not the best reason, but since this is already such a huge change I'd like to go with the least restrictive option. Though I'm not certain if that's the best choice. Can everyone please discuss what is the best choice? Heddy (talk) 12:41, 16 February 2023 (UTC)

Both odd and yoshi have stated 5, and I would agree. When hypothetical Splatoon 6 Return of the Octavians comes out, people can grid together the files or be old enough to have an alternative off-platform social media account dedicated to the sharing of personal content. Five allows for a brief summary and a bit of shine without becoming egregious. I've two files in use already, which would still allow me to show off an inkling for all three games. Trig - 13:00, 16 February 2023 (UTC)

I concur with 5 images per user; and if enough users don't like it, then a discussion about 7 or 10 might be good. I think there should definitely be no more than 10, though, because there's just no reason that I can see at this moment in time. -Xando (ping) 13:06, 16 February 2023 (UTC)

Alright then, seeing as there is a lot of support for a 5-image limit we may need to go with that. Once the policy proposal draft is finalized, I will open a vote to pass the policy if the vote shows a consensus.

Note: I looked at staff user pages and found that Shahar, P.J. GT, and StarAdamStar would all have to reduce their image count if this 5-image limit were to become policy. Do any of you object to this proposed limit? Heddy (talk) 02:31, 17 February 2023 (UTC)

Five is not enough considering we have three games already. Ten is a safe number and more flexible to allow some sort of creativity in the user page. Shahar (talk) 09:55, 17 February 2023 (UTC)

What happened?

I left a message on INK:PUMP and I checked to see if anyone got back to me, but then My message was gone! What happened? File:S3 Icon Callie.png Splat girl File:S3 Icon Shiver.png(talk) 16:52, 5 February 2023 (UTC)

Someone archived the past Ink Pump conversations. They must of thought your question wasn’t an ongoing conversation. If you want you could add the question here :) Odd (Talk) 17:25, 5 February 2023 (UTC)

In reference likely to this message here, I have no idea what you were asking for. Trig - 17:44, 5 February 2023 (UTC)

Mechanics Navbox

I made a Navbox template for various mechanics, but I'd like some feedback on it. Template:Navbox/Mechanics Bobby(talk) 21:41, 7 February 2023 (UTC)

Looks pretty good to me! Not sure where we should put it, if you want it on a page. Good job, though! Arivaki-Kun (banter) 21:58, 7 February 2023 (UTC)

I was going to put it on the pages of all the items inside it.

Bobby(talk) 21:59, 7 February 2023 (UTC)

Could use some color adjustments, but looks great! I had noticed this wiki was missing a navbox for Mechanics despite having so many Mechanic pages, happy to see someone took care of it. Wonderful work! Yoshifan52 (talk) 22:15, 7 February 2023 (UTC)

Cool. Just wondering! Thanks! Arivaki-Kun (banter) 22:18, 7 February 2023 (UTC)

It looks great!! I saw the Checkpoint introduced in the first game is on there, but wouldn't it be Spawn point instead? :0 Since Checkpoint redirects to the page for Spawn point. FancyRat 23:06, 7 February 2023 (UTC)

DLC

Nintendo just announced splatoon 3 DLC! Let's get new articles out right away :) Lofiguy (talk) 17:17, 9 February 2023 (UTC)

we are already on it xD Ratch 18:24, 9 February 2023 (UTC)

Great :) Lofiguy (talk) 19:26, 13 February 2023 (UTC)

Gear Seeds

Should we make an article regarding gear seeds and LeanYoshi's gear seed checker? It's technically canon, isn't it? But should it be an article on its own or added to the gear page or the hacks page? Woomy? (talk) 18:25, 13 February 2023 (UTC)

Do we have a hacks page? I can't find one. Lofiguy (talk) 19:30, 13 February 2023 (UTC)

@Woomy? No, from what I saw, it is not canon and should not be added.

@Lofiguy We do not have a hacks page because it is non canon and not our concern. We do have a page for Glitches, though.

-Xando (ping) 19:38, 13 February 2023 (UTC)

Alright then. Sorry for the confusion, I meant the glitches page but said hacks instead. Woomy? (talk) 19:41, 13 February 2023 (UTC)

Something big is missing...

There's something that I've noticed isn't on this wiki, and coming from the Minecraft Wiki, it really bothers me. We are completely lacking in all clips of various short noises. Everything that makes sound in Minecraft has a sound table on its wiki page, and I know that lots of things in the Splatoon games make noises too. Does anyone know how to make a "sound byte" template where you click a small icon on an infobox and it plays an associated sound byte?

I am aware that this would require a LOT of datamining to take out all the individual sound bytes and upload them onto the wiki, but I'm pretty sure I can find someone who's got the knowledge and time to do that. Bobby(talk) 19:38, 13 February 2023 (UTC)

That would be really cool... we should add it! Lofiguy (talk) 02:22, 14 February 2023 (UTC)

It would be too much of a waste of time and unnecessary for the wiki. In Minecraft, one might not know the noise of a "mob" or whatever (I don't play it) so they would look it up. In our case, even if you don't know what a torpedo or tacticooler sounds like, you can naturally see it over the course of a couple games and learn what they sound like, unlike Minecraft (from my knowledge) where crap can appear and disappear on a whim. -Xando (ping) 02:38, 14 February 2023 (UTC)

What about Octarians? Not everyone plays the singleplayer campaigns, and we have other voice clips on the wiki, but they're just links to download a big file. We document all of the music in the games, and someone might come here who's never played Splatoon and wants to know what the game sounds like. I know that sounds weird, but I think it's essential(or at least notable) information. Bobby(talk) 02:45, 14 February 2023 (UTC)

A handful of pages already have collections of sound effects, but they play in succession within a single audio file rather than individually on the page itself like the Minecraft Wiki does it. Additionally, the majority of all three games' sound effects haven't been datamined and/or uploaded by reliable sources, making it a bit difficult to get this up and running quickly. I really like the idea of pages having easy to listen to sound effects, but it seems like it'd be a lot of work. Yoshifan52 (talk) 02:38, 14 February 2023 (UTC)

This would make an interesting project. I can see arguments both for having sound effects and not having sound effects, though. Would the goal be to have one sound effect for say, each weapon or character? All of them? I would be concerned that having a significant amount of sound effects could lead to having really long pages. I would also like to suggest that if this is something to be undertaken, that the SFX uploaded are consistently formatted in naming and quality to ensure consistent playback from sound to sound: Otherwise, it may end up with some sounds being drastically different than others. That said, if Inkipedia does want to be considered as a complete encyclopedia for the series, it may not be unwise to actually try getting some of the more important sounds onto the wiki. I'm supportive of the idea—just making sure it's well organized before it is implemented. Trig - 02:45, 14 February 2023 (UTC)

@Trig Jegman I am wanting to document EVERY single little sound byte, but there's a good way to do it.

• Your recent overhaul of the File Template would make uploading all of them a breeze
• An infobox easily organizes them all on the page documenting the source of the sounds, or more specifically, a section on these pages.
• On the Minecraft Wiki, every page with a sound table has extremely small volume icons that you click on to play an associated sound byte. To be fair, Minecraft Wiki's sound table is very large, but that's because the sounds in Minecraft have a ton of properties due to the ingame /playsound command and the fact that Minecraft has subtitles for deaf players. Documenting Splatoon's sound effects would simply involve making a replica of this sound button and uploading a bunch of tiny files to the wiki.
• The sound tables here wouldn't be anywhere near as big, and even if they were, there are a LOT of tiny pages on the wiki that could use at least a little bit more content.

Because of the nature of organization on this wiki already, putting in tiny sound bytes would be like adding lettuce to a burger without any condiments yet, which has a very low chance to make a mess on your hands. Bobby(talk)

I meant more along the lines of the audio files themselves. I would, for example, encourage the use of MP3 as the sole format used so that these files can receive equal playback across browsers. I think this is a conversation that warrants more discussion for the validity of SFX on site first, though. I would like to hear more opinions on the matter. Trig - 03:15, 14 February 2023 (UTC)

@Bobbyawesome101 I would recommend starting a list of everything that needs an audiofile if you are truly invested in this project. Putting it in your sandbox would be a good idea. -Xando (ping) 18:30, 14 February 2023 (UTC)

User:Bobbyawesome101/Sandbox/List of sounds now exists. It is a skeleton for a list of sound bytes not present on the wiki. I invite anyone to fill it in, and perhaps rearrange the categories if it's not clear enough. Bobby(talk) 19:38, 14 February 2023 (UTC)

This list looks great so far! Yoshifan52 (talk) 02:04, 15 February 2023 (UTC)

Image editing guidelines

I added an image editing section to Inkipedia's image guidelines. In summary, please do not use edited images in wiki articles. Of course, these are just guidelines, not hard rules, but I do believe these new guidelines will improve the wiki. What does everyone think? Heddy (talk) 01:10, 16 February 2023 (UTC)

I think these guidelines are a great! I have seen many cropped images to show a specific character (Such as the one for Craymond’s infobox) and occasionally the photos look out of place. Should we replace the images that have been cropped with the original image? If so, I will help out when I can :) Odd (Talk) 01:19, 16 February 2023 (UTC)

The consensus on Discord and as evidenced by many such cropped images already on wiki, is that cropped images are acceptable. I've removed that part of the guideline. Now it's just no background removal and no upscaling. Heddy (talk) 01:27, 16 February 2023 (UTC)

Ok! Odd (Talk) 01:32, 16 February 2023 (UTC)

Tagging in here, I believe there are too many practical applications for cropped images where they are justified in being cropped as well as existing images to actually make a policy against it. A no cropped images policy would literally render all gear close-ups unacceptable to the standards. Rather, I would identify images that may need retaken at full size individually and utilize the Lowquality template instead to seek reupload, if not taken just by yourself. Trig - 01:34, 16 February 2023 (UTC)