Commons:Village pump/Proposals

Shortcuts: COM:VP/P • COM:VPP

Welcome to the Village pump proposals section

This page is used for proposals relating to the operations, technical issues, and policies of Wikimedia Commons; it is distinguished from the main Village pump, which handles community-wide discussion of all kinds. The page may also be used to advertise significant discussions taking place elsewhere, such as on the talk page of a Commons policy. Recent sections with no replies for 30 days and sections tagged with {{Section resolved|1=--~~~~}} may be archived; for old discussions, see the archives; the latest archive is Commons:Village pump/Proposals/Archive/2022/12.

COMMONS DISCUSSION PAGES (index)
Please note
  • One of Wikimedia Commons’ basic principles is: "Only free content is allowed." Please do not ask why unfree material is not allowed on Wikimedia Commons or suggest that allowing it would be a good thing.
  • Have you read the FAQ?

 
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 5 days and sections whose most recent comment is older than 30 days.

Protect all nudity and sexuality related files from IP editsEdit

Files in the field of nude people and files related to human sexuality are much more often vandalized than other files. The in many cases the vandalism consist of harassing language to the people depicted on the photo. If this kind of vandalism if not reverted immediately it is a serious personality rights problem. To solve this problem I would propose that we protect all files under the following categories form IP edits:

An other less invasive solution could be that we do not protect all files, but protecting all files indefinitely if they got vandalized once. --GPSLeo (talk) 15:50, 28 October 2022 (UTC)

A good idea to protect those categories so that volunteers can spend their time better than checking and repairing vandalism by anonymous users. Wouter (talk) 09:35, 5 November 2022 (UTC)
@GPSLeo I am somewhat biased towards these kind of categories, and have never observed such vandalism. Was it quickly revdel’d in each case? Or have I just not been looking at enough histories? Brianjd (talk) 14:22, 5 November 2022 (UTC)
  Oppose: "in many cases" is not a convincing argument. I could only support such a motion if the OP could show that, say, 80% of IP edits to such images were vandalism. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:04, 9 November 2022 (UTC)
  Oppose per above. Also because it depends on a hopelessly undefined category. Nude or partially nude people is in Nudity or partial nudity, whose long-running CfD is a mess. I noted there that even bare feet qualify as nudity, at least in one user’s opinion!
The category problems just keep going. Just to pick some random examples, Human sexuality contains Books about human sexuality and Lewinsky scandal. I expect there are many more subcategories that should not be protected in the way proposed here. Brianjd (talk) 10:42, 9 November 2022 (UTC)
  Weak support Sexuality-related media could definitely be a magnet for some very bad edits and should probably be held to higher scrutiny than your average content, but this could also just be a rule of thumb than a straight up rule. —Justin (koavf)TCM 10:47, 9 November 2022 (UTC)
@Koavf How does this work as a rule of thumb? Protection is already handled by administrators, who are elected by the community for their good judgement; they don’t need this rule. Brianjd (talk) 11:43, 9 November 2022 (UTC)
And as I wrote, it wouldn't be a rule. A rule of thumb is general good advice, so the way it would be enacted is that admins would keep their eyes on these categories and media and pay special attention to them. I don't even understand what you don't understand about what I wrote. —Justin (koavf)TCM 11:45, 9 November 2022 (UTC)
@Koavf I’m obviously using rule as an abbreviation for rule of thumb. I’m saying that admins already have good judgement and don’t need this rule of thumb on top of that.
Also, admins don’t have time to pay special attention to these categories; they barely have enough time to do things that actually require admin rights. So what are you actually proposing? Brianjd (talk) 11:53, 9 November 2022 (UTC)
I am proposing what I just wrote. I don't know how to reword it. —Justin (koavf)TCM 12:00, 9 November 2022 (UTC)
  Oppose can you provide evidence of widespread vandalism that would justify the protection of such broad topic? I have seen some but should we also remove the ability for them to list a file for deletion? I think that it would be of no benefit. Bidgee (talk) 12:11, 9 November 2022 (UTC)
  •   Question, wouldn't this also make it impossible for IP users to nominate abusive files of nudity for deletion? Not everyone wants to make an account to combat vandalism and a lot of users who edit with an IP are good faith users. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 12:45, 17 November 2022 (UTC)
    @Donald Trung Yes, it would make it impossible for unregistered users to nominate files for deletion. Ironically, some of those deletion nominations are the most abusive thing I see on this category of files (and legitimate deletion nominations tend to come from registered users). Even so, Bidgee above also raised this issue, and opposed this proposal on that basis. Brianjd (talk) 12:56, 17 November 2022 (UTC)
  •   Comment Like Bidgee above, I think such a proposal should be based on facts, on actual "evidence of widespread vandalism" in the subject area. That is, if it can be shown with actual data that there is significantly more vandalism and related issues there than on Commons in general, I would support the proposal, otherwise oppose. Gestumblindi (talk) 00:56, 7 December 2022 (UTC)
  Oppose no evidence provided we need such drastic measures. I think we can SNOW close this. Dronebogus (talk) 01:06, 30 December 2022 (UTC)

Enable ProveIt or Citoid on CommonsEdit

References are often used here:

However citoid and Help:Gadget-ProveIt aren't enabled here, even if you manually activate the VisualEditor in your Beta settings here. So:

  • Many people don't use the templates and instead write the sources "manually":
    • The format is inconsistent across pages.
    • It's often in the uploader's language instead of a standard international format that anyone can read. Good luck reading references in Chinese, for instance: File:南宋疆域图(简).png.
    • There are bare URLs, often pointing to "dead" websites, using a template would enable bots to automatically archive these URLs as on Wikipedia.
  • Many people copy/paste the equivalent templates from Wikipedia, however these templates aren't identical. For instance "first1" isn't displayed here (see Template_talk:Cite_book#Extra_authors) so the authors are often hidden on Commons ("first" or "author" should be used instead on Commons).

So I suggest enabling ProveIt (remove the "hidden" parameter, see Help_talk:Gadget-ProveIt#Enabled_here?) and/or citoid to allow people to automatically generate citations based on a URL, doi, or ISBN and provide better references to readers. What do you think? A455bcd9 (talk) 12:24, 13 December 2022 (UTC)

Support for enabling both. (ie. formal citoid support on visual editor at site configuration and adding provelt to gadgets) -- Zache (talk) 12:36, 13 December 2022 (UTC)
Support since I've seen both tools do much good in other wikis. Sophivorus (talk) 13:16, 13 December 2022 (UTC)
@Sophivorus: If we enable these tools here they will not be enabled by default: right? Only editors who manually enable them in their preferences will be able to use them? A455bcd9 (talk) 13:23, 13 December 2022 (UTC)
@A455bcd9 Regarding Proveit, yes. Regarding Citoid, I'm not sure but I think it'll be enabled for all users. Sophivorus (talk) 13:32, 13 December 2022 (UTC)
@Sophivorus OK for ProveIt. Regarding Citoid, as the Visual Editor isn't enabled by default on Commons (it has to be enabled in the Beta features) I think that all users won't have access to Citoid by default BUT all users who have already enabled the Visual Editor on Commons will then automatically see the Citoid gadget. Am I correct? A455bcd9 (talk) 14:14, 13 December 2022 (UTC)
@A455bcd9 Probably, yes. Sophivorus (talk) 14:17, 13 December 2022 (UTC)

Adding NOTHERE to Blocking policyEdit

Looking at this current discussion, there is an argument that the blocks do not fall under Commons:Blocking policy. I suggest adding the equivalent of en:WP:NOTHERE to blocking policy. I think this would actually reflect consensus here as I vaguely recall blocks of users who spend their time either fighting or making up copyright claims or misusing the help desk or are just somewhat trolling overall (but not harassment of another user specifically which is covered). Ricky81682 (talk) 22:59, 27 December 2022 (UTC)

I also note that categorization fighting (namely a failure to follow consensus) is a common reason for people to be blocked and could either be considered edit warring or just plain disruptive editing. Ricky81682 (talk) 23:10, 27 December 2022 (UTC)
Sorry, but what does NOTHERE mean? Block anyone who's blocked on :en:Wikipedia? (because that's the subtext here). Or is it for some other reason that you "vaguely recall blocks of"? Andy Dingley (talk) 23:23, 27 December 2022 (UTC)
Not here to assist in assist in the creation of a media repository of free-to-use images. I said equivalent as we are not an encyclopedia and there are plenty of people who edit here who are blocked on other projects. NOTHERE isn't even a policy on English and official policy here only lists "common" reasons for blocks. Ricky81682 (talk) 23:40, 27 December 2022 (UTC)
So of the ten headings for Commons block policy, which are you planning to block Benlisquare under? Uploading anime style represenations? Unislamic uploads?
Your stated position is completely inconsistent: you're advocating NOTHERE, then confirming that's it's not even a policy on en:WP. You're looking to block people for the same reasons as Wikipedias, then acknowledging that "there are plenty of people who edit here who are blocked on other projects". Or did you mean "misusing the help desk"? (We don't have a help desk) Andy Dingley (talk) 23:56, 27 December 2022 (UTC)
What is Commons:Help desk if not a help desk? Ricky81682 (talk) 00:00, 28 December 2022 (UTC)
Sorry, I thought you were still talking about Wikipedia. Where misuse of the question-based reference desks does attract abuse, and sometimes blocks. The Commons help desk is much more restricted, simply on how to use Commons, and I've never seen a block arise from it. Andy Dingley (talk) 00:12, 28 December 2022 (UTC)
Let me look over history and see if I can find examples. I'm trying to figure out a generalized description as "misuse of Commons resources" is not accurate. I do know people have been blocked for uploads that are used to be disruptive on other wikis (I'm thinking of flags mostly) but maybe this is an exercise going nowhere if people would rather have blocks done without any explanation provided. Ricky81682 (talk) 00:34, 28 December 2022 (UTC)
I do not think we need a real policy change but maybe we should rename "Vandalism" to "Vandalism and counter productive behavior". The word Vandalism means damaging something without any further intention behind it. Many of the users blocked are not blocked for intentional harm but due to ignorance or because of being only here to distribute their (political) message. GPSLeo (talk) 08:01, 28 December 2022 (UTC)
“counter productive behavior” is rather broad and open to interpretation. Bidgee (talk) 08:35, 28 December 2022 (UTC)
No, this is just an extension of this bizarre public humiliation war against a user who uploaded too many AI-generated pictures of boobs and threw a tantrum about it. We have our own NOTHERE, it’s “not a web host” and “not an amateur porn site” and we don’t randomly use them against active users we particularly dislike. Dronebogus (talk) 00:31, 29 December 2022 (UTC)
NO. a "catch-all crime" is a hotbed of abuse of power.--RZuo (talk) 20:55, 29 December 2022 (UTC)

Make renaming policy more strictEdit

Nearly every day there are disputes and complaints on renamed files. For solving this I would propose the following changes to the renaming policy without limiting renaming to admins only.

I refer to the criteria of the current Commons:File renaming policy.

Under the new policy renaming should only be done in the following cases:

  1. By the uploaded under any of the current cases.
  2. By an administrator if they see an urgent need.
  3. By every file mover unter the criteria 2, if it is really only a name like img_0001.jpg. Under criteria 3, 5 and 6. In all of these cases the uploader can undo the renaming and the person who wanted the file renamed has to discuss this with the uploader.
  4. Renaming in other cases of criteria 2 and 4 has to be proposed and the uploader can veto withing 14 days. If the uploader disagrees an admin has to decide after hearing the arguments of both sides. If the uploader agrees or does not respond the file can be renamed. If the uploader is blocked the files can be renamed directly.

GPSLeo (talk) 16:52, 29 December 2022 (UTC)

  • Oppose Your case for these changes is poorly made and very unclear. You have given no justification for these changes, and the changes you mean aren't precisely stated.
Most obviously the effects here would be to limit the actions available to filemovers and limit some to admins only. That is both technically problematic (filemovers can move any files, the permissions limit doesn't recognise your definitions) and it's also placing admins as "content judges", something we've always opposed.
You are unclear as to whether you're discussing requesting renames or making renames. Uploaders (point #1) can't rename, they can only request.
Are your arbitrarily numbered bullet points related to the numbered policy reasons? (then why not type in the numbers and make them stable? – we've been down that path before)
Your #2 "By an administrator if they see an urgent need." is effectively "these policies may be ignored at the whim of any admin". That is a terrible change (we've just seen a case of that, which you were active in commenting upon). How about an admin who decides to rename "young girl" to "disgusting pornography against my own religious views"?, because matters of personal or religious offence are always the most urgent thing ever!
Your #3: isn't it always policy (under BOLD for one) that any editor, not just an uploader, can challenge a rename, until we've discussed it and demonstrated consensus for a change (or not). Uploaders can't "undo" anything here.
Your #4: introducing a new discussion period and a 14 day delay (twice that of a DR) before we can perform simple renames of filenames. It also gives uploaders a veto, whatever the issue!
Also #4: "an admin has to decide after hearing the arguments of both sides." Seems to be ignoring consensus, also permitting an involved admin who made the first change to simply ignore the discussion.
None of this is in line with Commons policies or principles. It's also giving several more excuses for poor and subjective admin decisions against policy or the consensus amongst editors. Andy Dingley (talk) 18:53, 29 December 2022 (UTC)
Yes these rules are complex but I tried to find a way to restrict file renaming a bit more without totally banning it or limiting to admins only. Yes the points are assuming that the uploader has renaming rights, but as most active uploaders have these right this is the regular case. The second point with the urgent need is only because of the fourth case and is of course limited to the renaming guidelines. The current state is that the uploader does not have any kind of prioritized opinion on their file names. To Number 4: I do not understand why you say this is something totally new? This is very similar to the procedure of deletion requests or the categories for discussion process.
But of course an other alternative could be using the same procedure as for categories for discussion for file renaming, then we would not need such kind of complex case handling procedures and rules.
On the need for these changes:
On the Commons:Administrators' noticeboard/User problems there is currently one long linked to file renaming.
On Commons:Administrators' noticeboard/User problems/Archive 101 there are three cases.
On Commons:Administrators' noticeboard/User problems/Archive 100 there are two long cases.
On the German Forum there were two long discussions in October and November. GPSLeo (talk) 19:45, 29 December 2022 (UTC)
i skimmed thru some discussions.
i'd say most quarrels about file renaming are due to two kinds of users:
  1. unqualified, careless filemovers (who make useless cosmetic changes, apply rules wrongly...)
  2. stubborn uploaders (who refuse any renaming of their files, even if renaming is clearly justified)
and the solutions accordingly would be:
  1. remove filemover
  2. ignore them
anyway, i dont seem to see urgent needs to change COM:MOVE.--RZuo (talk) 20:55, 29 December 2022 (UTC)
Oppose per Rzuo. There’s nothing so bad about the current policy it needs changing. This is terrible and confusing needless bureaucracy. On top of that this is ANOTHER attempt at giving admins even more unchecked power despite the fact that there is a long dispute at the noticeboard over at least two admins overstepping their bounds. Please read the room and withdraw this. Dronebogus (talk) 00:58, 30 December 2022 (UTC)
User:GPSLeo writes, "The current state is that the uploader does not have any kind of prioritized opinion on their file names." This could not be farther from the truth. They select a filename on uploading, and if it's an appropriate filename, it is very unlikely ever to be changed by anyone else. ("Unlikely" doesn't mean it can't ever happen, but it is rare for a well-named file to be renamed to something else unless the uploader wants to modify it themself.) - Jmabel ! talk 01:31, 30 December 2022 (UTC)
  •   Oppose, regarding the owner being able to veto it. If you contribute something to the Wikimedia Commons you are contributing it to be improved by others, see "Commons:Ownership of pages and files" "You agreed to allow others to modify your work here. So let them.", as long as it's an improvement it should be welcome. Also, not sure why blocked uploaders should be seen as second (2nd) class users, if they have talk page access (TPA) they should be able to make reasonable arguments. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 22:10, 14 January 2023 (UTC)
  •   Oppose It look like you want to eliminate COM:FNC 2-6 to an admin opinion situation. That is more open to vague interpretation not more strict. What is the purpose of 3 if admins could do it themselves? If it is not settled, I think admins currently ask for there to be some sort of consensus on the file talk page rather than force a move. We should probably have a better system that say if the file move request is rejected or opposed after the fact, then what should be done. -- Ricky81682 (talk) 00:04, 15 January 2023 (UTC)
  Oppose The proposal should have been titled ‘Make renaming guideline more confusing’, because Commons:File renaming is indeed labelled as a guideline, and making it more confusing is exactly what this proposal does. Other users above have already discussed that confusion, but there are even more issues:
  • The new guideline still allows renaming ‘by the uploade[r] under any of the current [criteria]’. One of the current criteria is: ‘At the original uploader’s request.’ At first glance, this appears to make all that stuff about uploader vetoes redundant. But the current criterion comes with a footnote: ‘If a file mover feels that a proposed new name is disruptive or inappropriate, they can suggest a different name or decline the request.’ Combine this with uploader vetoes, and surely nothing good will happen.
  • There are two different types of uploader vetoes. In some cases, the uploader can undo the rename at any time, and repeating the rename then requires discussion. In other cases, the uploader has only 14 days (but still twice the standard length of a deletion request!) to object. This is just more confusion with no explanation at all.
  • The uploader can undo renames made under the current criterion 5, and repeating the rename then requires discussion. But the current criterion 5 is for changing names that violate policies and guidelines. Why is this eligible for an uploader veto at all?
Brianjd (talk) 14:40, 20 January 2023 (UTC)

AI generated media guidelinesEdit

Per the discussion at Commons:Village pump#Category:AI generated images, I've created a very rough draft of some guidelines for AI generated media on Commons. Feel free to edit boldly and discuss on the talk page. Nosferattus (talk) 03:00, 30 December 2022 (UTC)

File renaming criterion 3 supplementEdit

i propose appending a sentence to criterion 3 Commons:File_renaming#cite_ref-3: (Please include explanation of the error.) .

renaming requests involving technical, historical or geographical stuff like special:diff/722907648 are really impossible for layman filemovers to determine their validity. RZuo (talk) 10:59, 5 January 2023 (UTC)

  • @RZuo: I don't think the criterion as such is a problem, but there ought to be somewhere that we clarify what is meant here by "obvious". If you are a filemover, and it is not obvious to you whether the correction is right or wrong, and you don't either see a consensus about the move or know that the person requesting it has the relevant expertise, then you have no business executing the move. - Jmabel ! talk 01:22, 6 January 2023 (UTC)
    the word obvious can be deleted, but that doesnt help.
    requests can be related to something that all 100% filemovers and sysops cannot understand. it could be spiders, mayan language, dg-category... i can make some related to the cantonese language, which no other commons user would understand. (commons/wikipedia "penetration rate" is super low in my community.)
    the point is, we need to tell users explicitly to include evidence for proposed changes. surprisingly the whole page doesnt mention that at all.
    i chose that position to insert this short sentence, because it needs to be transcluded and easily seen in the rename gadget. RZuo (talk) 21:29, 7 January 2023 (UTC)
  • ^What he said. I've come across plenty of renames that haven't been obvious to me so I've either declined them or left them (depending on what the dispute was). If it's not obvious to you then don't move it. –Davey2010Talk 18:16, 6 January 2023 (UTC)
    I would hope that someone shoots a comment to the requestor's talk page telling them you don't understand the request. People do not always realize they are using technical jargon unless they are told. I wonder if we need a place for controversial file renamning requests but the file talk page is sufficient. Ricky81682 (talk) 22:15, 16 January 2023 (UTC)

Germany protected area naming convention and category structureEdit

In the Commons:WikiProject protected areas we created a naming convention and concept for a unified category structure for the protected areas in Germany. Are there any doubts on rolling out this concept for all protected areas in Germany? Within this we also want to create a bunch of empty categories linked to Wikidata to have them prepared to be used for Wiki Loves Earth. GPSLeo (talk) 09:49, 7 January 2023 (UTC)

Looks good to me, thanks for doing this. Would you need a bot, or is the idea to do it manually? Ymblanter (talk) 20:54, 7 January 2023 (UTC)

Arbitration Committee for CommonsEdit

In the last months we had many disputes between users in many cases involving admins in the dispute. To solve this Commons should also get an Arbitration Committee to find good solutions for these long lasting discussions and disputes. There was a proposal from 2007 Commons:Arbitration (failed proposal) but this was rejected because Commons was much smaller and such an instrument was not needed. I would propose the following concept:

  • The ArbCom has ten members elected for two years. If one member leaves there will be a new election for replacing this member.
  • Everyone can candidate for the ArbCom and admins can still do their regular admin activities.
  • In the election candidates with the most support votes and with at least 2/3 support votes are elected.
  • Decisions are done by fife of the members. ArbCom members they were somehow involved in the prior discussions on a case are excluded from the case.
  • Everyone can bring a case to the ArbCom, but the ArbCom can decide to not accept the case and leave it to e regular admin decision.
  • Copyright related discussions are not a topic for the ArbCom.
  • The ArbCom should fine a decision within 14 days.
  • The decision together with an explanation will be published.
  • The subjects of the decision or a group of ten users can request a reevaluation of a case by the ArbCom.

This is a first concept to create a guideline and then implementing this. --GPSLeo (talk) 06:56, 14 January 2023 (UTC)

DiscussionEdit

I am wondering what advantages this will bring to the Wikimedia Commons. For years I have thought of proposing a Commonswiki ArbCom myself but having closely looked at the English-language Wikipedia's ArbCom I realised that it can also have a lot of issues, namely I seem to find a lot of formerly productive users being ArbCom banned but very few seem to ever be unbanned. Having looked at the Dutch-language Wikipedia's ArbCom I'd say that I find their level of transparency better, e-mails sent to the Nlwiki ArbCom are published and other users can give their insights and opinions on the cases, this actually makes it a more community-driven thing. But still, the main thing I see ArbComs do it add another level of bureaucracy and often making it impossible to get unblocked. Users who are ArbCom banned can get blacklisted from e-mailing them and not even know that they're Blacklisted essentially making any future unbans impossible.

I do think that we should have an Appeals Court for indefinitely blocked users with no access to e-mail and talk page as there is no such system or UTRS here, but for everything else I can hardly think of anything that the ArbCom really improve. The ArbCom cannot dictate guidelines and policies, only their interpretation.

Again, I really like the idea of a Commonswiki ArbCom, but having seen how they can bureaucratise content creation at the Enwiki I am not sure if they'd actually be beneficial to the Wikimedia Commons. Perhaps we should have a less powerful ArbCom here that deals with less. An advantage to an ArbCom is that they can actually take action against abusive admins as the current system here is severely broken (something which user "Alexis Jazz" brought up several times before he quit editing here), but I'm not sure if the benefit of occasionally getting rid of the few bad apples is worth the creation of a powerful ban hammer that can stifle discussion about topics that have been brought up to it (which other users will claim are "done" and "dead horses" if brought up later).

I'd support the creation of an ArbCom with less powers than the Enwiki one, perhaps limited to reviewing admin actions and reviewing blocks and appeals. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:57, 14 January 2023 (UTC)

If the Commonswiki ArbCom cannot talk about copyright ©️ can it then basically only talk about interpretations of "COM:SCOPE"? As basically "COM:LICENSING" and "COM:SCOPE" are the only two (2) rules around here from which all other rules eventually stem, I don't really see how having a small council dictate how to interpret this would be more beneficial than wide community discussion as is the rule today. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:59, 14 January 2023 (UTC)

I think the copyright restriction is missing the mark. If a user dispute originated from a copyright dispute, this ArbCom absolutely should be able to handle it. Instead, the restriction should be replaced with: "ArbCom does not have the power to order the deletion or undeletion of any pages, or to pass any binding community-wide policy without community consensus."
One thing I've observed is that there tends to be a lower threshold for indefinitely banning or blocking users on English Wikipedia than on Commons. The creation of an ArbCom will probably make Commons more like English Wikipedia in this respect. Whether that's a good idea - who knows? -- King of ♥ 04:11, 15 January 2023 (UTC)
I would exclude copyright related questions from ArbCom topics because they are complex legal questions and they might not have the ability to discuss them in a proper way. The ArbCom should focus on social problems. And yes I also would see the scope of the ArbCom on reviewing admin decisions, but not blocking someone after the discussion is also a decision that could be reviewed by them. --GPSLeo (talk) 06:41, 15 January 2023 (UTC)
One additional thing that the ArbCom could handle is appeals of blocks involving non-public information (i.e. CheckUser or Oversight blocks), although this would require, like English Wikipedia, that arbitrators be granted these permissions. Overall, I think this is a good idea, although I'd probably fiddle with the criteria. —‍Mdaniels5757 (talk • contribs) 18:38, 15 January 2023 (UTC)
One of the requirements Copyright related discussions are not a topic for the ArbCom. is quite strange given what this project is revolved around and should be removed. Some cases that could involve copyright issues may need to be clarified by those elected based on existing policies here, if need be. Also what Mdaniels5757 said. Other than that, an Arbcom is needed for this place. 1989 (talk) 07:55, 16 January 2023 (UTC)
  Strong support Having an ArbCom was long overdue. I agree that an ArbCom shouldn't deal with copyright, that's a job for the wider community. It should deal with incivility, assumptions of bad faith, complex abuse of permissions (especially filemover!), etc. However, my main concern is: How will the ArbCom maintain language neutrality? --Matr1x-101Pinging me doesn't hurt! {user - talk? - useless contributions} 21:46, 16 January 2023 (UTC)
  • I'm in support as long as ArbCom remains focused on human behaviorial issues since as admin/filemover decisions and not on copyright issues per se. One can dispute whether an admin's closings are repeatedly bad (and thus at undeletion all the time) without getting into the actual copyright issues that are underlying them. Similar with someone who starts a bunch of deletion requests that go nowhere because they are a controversial view of copyright (the issue is whether that itself is disruptive). The problem is, unlike English, topic bans aren't that common an option so if the only options are bans or no bans, you don't have many tools to use to control behavior. I suspect this will become mostly a fight over "admin abuse" like ANU is becoming since there are few other things that go to the level above that of admins. -- Ricky81682 (talk) 22:11, 16 January 2023 (UTC)
  Oppose it's impossible to select rational people from a pool full of the opposite. it will just end up with another bunch of self-important buffoons.--RZuo (talk) 20:27, 18 January 2023 (UTC)
@RZuo: Please point to a previously identified "bunch of self-important buffoons" with consensus or retract your statement.   — 🇺🇦Jeff G. please ping or talk to me🇺🇦 04:56, 19 January 2023 (UTC)
@RZuo I concur with Jeff G.. Also, the fact that someone happens to disagree with you doesn’t automatically make them irrational. Brianjd (talk) 14:11, 20 January 2023 (UTC)
  Support A Commons ArbCom is a good idea. I also agree that copyright related discussions should be excluded from ArbCom. Abzeronow (talk) 17:34, 19 January 2023 (UTC)

New speedy deletion criterion proposalEdit

I propose to add the following speedy deletion criterion:

X. Images globally replaced by text
This includes images globally replaced by HTML, wiki markup, and LaTeX.

Rationale: These kinds of uploads are quite common and deletion is uncontroversial. Currently, they have to go through a full deletion request and bind extra administrator resources. Once these images are replaced by HTML/wiki markup/text/LaTeX, they serve no educational purpose and can be deleted.

Note: I think my wording definitely could be better, so please drop suggestions!

--Matr1x-101Pinging me doesn't hurt! {user - talk? - useless contributions} 20:05, 18 January 2023 (UTC)

@Matr1x-101 Can you give me an example? Ricky81682 (talk) 02:21, 19 January 2023 (UTC)
An example should include an automated way to make the replacements.   — 🇺🇦Jeff G. please ping or talk to me🇺🇦 04:29, 19 January 2023 (UTC)
@Ricky81682: Just visit Category:Images with a TeX equivalent for some examples. And that's only LaTeX! --Matr1x-101Pinging me doesn't hurt! {user - talk? - useless contributions} 08:36, 19 January 2023 (UTC)
I'm skeptical about this. I'm happy to get rid of mathematical formulae that someone hacked into MS word and exported to png (or jpg *shudder*) because they didn't know how to otherwise get that into their article (assuming they have indeed been replaced). I'm happy to get rid of things like File:Activité E s = 0,9 .jpg, but images like File:Calculation of refractive index increment.jpg have qualities that cannot be replicated by putting the formula into TeX. Files that are about the typesetting like File:Blahtex-comma-bug-1.png should not be deleted for this reason. Similarly, the whole archive of Mathematical formulas from Brockhaus and Efron Encyclopedic Dictionary is not something we should nuke without discussion just because we can replicate them in TeX.
I'm talking about random text/maths in an image (like this file) that has been screenshotted off MS word or something else. We should leave anything handwritten/scanned from paper out of this SD criterion, due to concerns about ambiguity. --Matr1x-101Pinging me doesn't hurt! {user - talk? - useless contributions} 17:56, 19 January 2023 (UTC)
In any case that should   exclude things like PDF scans of public domain books that have equivalents on Wikisource. 1) These are still important as source material and 2) A wall on sans serif text on a wiki is not a replacement for a properly typeset book page.
Taking a step back, these are essentially being considered for deletion as out of scope. With the notable exception of unused personal images, we do not normally speedy delete out of scope images. That's because 1) these are often much less clear cut as one might think and 2) them being low-risk images, there is absolutely no need to hurry. For anything but legal reasons, blatant abuse, and things like obvious duplicates, we should probably stick to a regular DR. El Grafo (talk) 11:39, 19 January 2023 (UTC)
The speedy deletion criterion for selfies ({{Selfie}}) was accepted, so I don't see what the problem with this is. --Matr1x-101Pinging me doesn't hurt! {user - talk? - useless contributions} 17:39, 19 January 2023 (UTC)
@Matr1x-101 I'm not saying there is a problem, just that we should be careful about introducing new CSD. Anything scope related has the potential to be controversial, so we should think twice and make sure the new criterion leaves as little room for interpretation as possible. The original proposal was unacceptable, the new one below might work. Looking back at the 2018 discussion, important points for the acceptance of COM:CSD#F10 were that 1) selfie uploads are indeed very common, 2) often users kept re-uploading selfies after their initial uploads were deleted. So it was (is) a very common problem plus related to abuse. At least abuse doesn't seem to play a role in this proposal. How common is the problem we are talking about here really? El Grafo (talk) 10:43, 20 January 2023 (UTC)
@El Grafo, it's quite a big problem. If we look at Category:Images with a TeX equivalent, there's ~600 images (incl. images in subcategories). Let's assume 150 have been globally replaced by TeX (really conservative estimate). That's 150 deletion requests! And that's only images that have been reported with {{Use TeX}}. There are probably hundreds, if not thousands of low-quality maths formulas, that haven't been reported. And that's only Maths formulas! I don't know much about the numbers for screenshots of text (because no one uses {{ShouldBeText}}, its hiddencat has 2 members), but I suspect it to be even more. --Matr1x-101Pinging me doesn't hurt! {user - talk? - useless contributions} 22:24, 20 January 2023 (UTC)
Another thing to keep in mind is that Commons is a project on its own that does not only serve the Wikimedia projects. Sure, on Wikipedia you can render the structural formula of 6-hexane using TeX, but I'm sure there's a target audience for an easy to use graphics file like File:6 - hexane.svg. --El Grafo (talk) 11:16, 20 January 2023 (UTC)

Revising the wordingEdit

Hi, so I'm revising this criterion's wording, because there seems to be concerns about deletion of handwritten/scanned text. Also, wikicharts/graphs are explicitly excluded.

X. Images globally replaced by text
Images globally replaced by HTML, wikitext, and/or LaTeX, with no reason to keep. This criterion should not be used to delete handwritten or scanned works.

--Matr1x-101Pinging me doesn't hurt! {user - talk? - useless contributions} 17:56, 19 January 2023 (UTC)

@Matr1x-101: I have moved your signature to below the proposal so that (hopefully) future responders can use the reply tool. Also, when a speedy deletion criterion has to use the phrase ‘with no reason to keep’, something is wrong. Brianjd (talk) 14:02, 20 January 2023 (UTC)
[W]ith no reason to keep sounds pretty redundant on second thought, so that phrase should probably be removed.
Also, the phrase "with no reason to keep" is not strictly required, for this criterion to work. --Matr1x-101Pinging me doesn't hurt! {user - talk? - useless contributions} 22:10, 20 January 2023 (UTC)
  •   Comment, I'm not sure if this is a good idea in general for speedy deletion, let's say that we have a text graph or index of a specific subject, this is an index that was later copied to be a part of a Wikipedia article and is converted to wikitext. Now you run your own website and want to include the index on your own website and simply want to copy the Wikimedia Commons' image, but you find that the file is gone and can only copy the wikitext but the formatting of the wikitext doesn't work for your website. What do you do? In this case nothing, as the original file is irretrievable for non-Commonswiki admins. Is this really that common of an issue that it has to go through speedy deletions rather than regular deletion requests? What if the file was used on other websites (outside of Wikimedia Wiki's) and links to the Commonswiki file? I simply don't see which problem this solves that regular DR's can't handle and uncontroversial cases are as easily closed as speedy deletions. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 23:28, 20 January 2023 (UTC)

Rename ‘Photographs of identifiable people’ to ‘Photos and videos of people’Edit

I propose three changes:

  1. Remove the word ‘identifiable’. See below.
  2. Add the word ‘videos’. Obviously, all the issues that apply to photos also apply to videos. (The name really should say something like ‘visual recording’, but I expect the name actually proposed here will be more popular.)
  3. Change ‘photographs’ to ‘photos’. This just makes a long name a bit shorter.

The current guideline is inconsistent as to whether personality rights apply when the subject is not ‘identifiable’. Despite its name, its summary says nothing about identifiability:

Commons respects the legal rights of the subjects of our photographs and has a moral obligation to behave ethically with regard to photographs of people. The legal rights of the subjects constitute non-copyright restrictions on use of images. Country-specific laws may affect what content we can host, how it may be published, and whether consent is required to re-use it.

The guideline itself also suggests that personality rights can apply to people who are not ‘identifiable’, with statements like:

  • ‘Certain legal and ethical issues may remain if the person … cannot be identified.’
  • ‘The provenance of an image may taint its use irredeemably. A "downblouse" or "creepshot" photograph is not made ethically acceptable just because the subject's face is cropped out. A paparazzi telephoto shot of a naked sunbather does not become acceptable merely by pixelating the face.’

This is supported by deletion requests like:

This confusion creates real problems: at Commons:Deletion requests/File:Topless Barcelona.jpg#File:Topless_Barcelona.jpg 3, a user pointed out that some laws seem to require consent regardless of identifiability, but users try to get around this by pointing to the word ‘identifiable’ in the guideline’s name. Brianjd (talk) 11:39, 19 January 2023 (UTC)

I'm inclined to support this at the level of the guideline's name, because some of the moral and privacy-related issues don't require identifiability or have different degrees of identifiability. As for File:Topless_Barcelona.jpg, we could use someone with more knowledge about Spanish law. Certainly by the letter of the law that file should be deleted, but I'm seeing several forums where people talk about how, in practice (by journalists, etc.), blurring the face is seen as an acceptable fix. — Rhododendrites talk |  13:45, 19 January 2023 (UTC)
@Rhododendrites Yes, that is an old discussion; we need a new discussion with knowledgeable people. It was just an example I had handy; I expect the same issue would occur with other countries. Brianjd (talk) 13:49, 19 January 2023 (UTC)
I think we should stay with identifiable add and a section or a separate page of the special cases where permission required also if the person is not identifiable. And I think we should not start renaming every guideline to cover that we also habe videos. As videos can have sound we could create an extra section or page to cover this additional topic. GPSLeo (talk) 17:31, 19 January 2023 (UTC)
@GPSLeo What, exactly, are those ‘special cases’, and why is consent not required in other cases? I don’t think there is a clear answer: it is a complex balancing act between the rights of the subject and the rights of people who use the photo. So how can we split this guideline into two pages? Adding a separate section (to the same page) has the same problem. Adding a separate section also has the problems I described in the proposal: it just creates a lot of confusion. Brianjd (talk) 09:30, 20 January 2023 (UTC)
I think there are basically four cases.
  1. Person is identifiable and the event is public and there is a public interest on having this photo published. (nothing required)
  2. Person is identifiable but the situation was not public and there is no public interest. (permission required)
  3. The person is not identifiable. (nothing required)
  4. The person is not identifiable but in this special cases the photo violates the intim space of the person. e.g. nude people. (permission required)
Maybe this could be covered on one page. But the last point could also be moved to COM:NUDITY. GPSLeo (talk) 13:44, 20 January 2023 (UTC)
@GPSLeo Items 1 and 2 leave a gap. You list ‘event is public’ and ‘public interest’ as if they are two distinct things (which they are). What if one is present and the other is not?
On the other hand, items 3 and 4 overlap, with contradictory results. Item 3 should say ‘the person is not identifiable and does not violate the intimate space of the person’.
Item 4 has its own problem: it’s starting to feel like nudity (or similar) is the only example. Indeed, it must be if we are considering moving it to COM:NUDITY (Commons:Nudity). But it is not the only example. The first deletion request listed in the proposal (Pinging @1Veertje) provides another example where the person is not ‘identifiable’, yet consent is required. Brianjd (talk) 13:58, 20 January 2023 (UTC)
Of course is not always clear if photo falls under 1 or 2. I think the "and" at 1 is fine. I do not see that we have cases relevant for Commons covered by the "public interest" criteria but not the "public event" criteria. Only "public event" is not sufficient to justify the publishing the public interest is needed too. You referred to Commons:Deletion requests/File:Obese office worker at lunch break in Brisbane, Australia.jpg? The people on the photo are clearly identifiable. GPSLeo (talk) 14:15, 20 January 2023 (UTC)
@GPSLeo I referred to the discussion, not the file. The discussion made it clear that (at least in the nominator’s opinion, which went unchallenged) the image would still be unacceptable even if it was edited so that the person was no longer identifiable. Brianjd (talk) 14:20, 20 January 2023 (UTC)
@GPSLeo I do not see that we have cases relevant for Commons covered by the "public interest" criteria but not the "public event" criteria. Only "public event" is not sufficient to justify the publishing the public interest is needed too. Then there is no need to say ‘public event’:
  1. Person is identifiable and there is a public interest. (consent not required)
  2. Person is identifiable and there is no public interest. (consent required)
But in many cases (I would say that vast majority of cases), there is no public interest. There is only a public event. Under your proposal, consent would be required for all those cases. Brianjd (talk) 14:27, 20 January 2023 (UTC)
If the file would be modified to make the people unidentifiable this would be fine. The discussion was also about the context file was used. But as Commons we can only handle the file description and categories here. The Wikis and external reusers also have to make sure to not violate the personality rights through the context they use the file.
Yes maybe "public event" could just be removed from this. If there is not public interest and no other kind of permission the file has to be deleted. But as an example that you do not want to wait many minutes until no person stands in front of a building you want to make a photo of could be a legitimate interest. Of course then you are not allowed to crop and zoom this person when using the photo. If there is an event like a sports event or a conference there are rules for this event you accept by attending. In most cases such rules cover if photos can be taken and published. GPSLeo (talk) 14:39, 20 January 2023 (UTC)
@GPSLeo But as an example that you do not want to wait many minutes until no person stands in front of a building you want to make a photo of could be a legitimate interest. You changed from ‘public interest’ (which does not apply here) to ‘legitimate interest’ (which is not well defined).
If there is an event like a sports event or a conference there are rules for this event you accept by attending. In most cases such rules cover if photos can be taken and published. But Commons doesn’t usually care about such rules. If it’s public, it doesn’t require consent. That seems to be a very well established rule on Commons.
This discussion just keeps getting more confusing, which just reinforces my comment above: this is a complex balancing act between the rights of the subject and the rights of people who use the photo that needs to be discussed in a single guideline. And that guideline’s name should not contain the word ‘identifiable’. Brianjd (talk) 14:51, 20 January 2023 (UTC)
I wrote: If it’s public, it doesn’t require consent. That might seem strange to you, because it doesn’t apply in Germany. But looking at the behaviour of other Commons users, it’s clear that German laws would seem strange to them. Again, this is complex and confusing and should be discussed in a single guideline. Brianjd (talk) 14:55, 20 January 2023 (UTC)
The rules are basically the same in the hole EU and I think in many regions these ruled tend to be more strict than in Europe. Could you give an example of a photo on Commons where you do not see public interest/legitimate interest having this photo published? GPSLeo (talk) 16:52, 20 January 2023 (UTC)
Adding a separate page to discuss sound is a fine idea, but belongs in a separate discussion. Brianjd (talk) 09:31, 20 January 2023 (UTC)
I actually believe we should rename ALL policies to "Media files" instead of "photographs" or "photographs and videos", as this would cover the full scope of the project. Furthermore I think striking the identifiable from this policy is a good idea. Adding something about weighing the value of the picture against the possible harm to the person depicted in edge cases could also be a good idea. --Kritzolina (talk) 18:29, 19 January 2023 (UTC)
@Kritzolina Audio recordings have separate legal issues, and may have other issues too. I am not sure that they belong in the same guideline as visual recordings.
But as I write this, I realise there are other categories of media, like drawings, paintings and AI-generated works. Where do these fit in? Brianjd (talk) 09:35, 20 January 2023 (UTC)
Also, I think that ‘photos (and videos) of people (who may or may not be identifiable)’ is a reasonably accurate description of the current contents of that page. With an accurate name, we might be able to start cleaning up that page. On the other hand, trying to expand the scope of that page will probably just create an even bigger mess, which no one will ever be able to fix. Brianjd (talk) 09:39, 20 January 2023 (UTC)
Like I said above, I support the idea of creating more pages to discuss these other issues. For example, we already have Commons:AI generated media#Deep fakes (which surely needs expansion, but that is also a separate discussion). Brianjd (talk) 09:43, 20 January 2023 (UTC)
@Kritzolina: If Commons had the luxury of writing a logical set of policies and guidelines from scratch, I would probably suggest a lot more changes. But Commons doesn’t have that luxury. Its lists of uploads and deletion requests are growing every day. It needs justifiable guidelines it can apply now.
So our priority must be to fix the existing guidelines, without redefining them in ways that could create an even bigger mess. The guideline ‘Photographs of identifiable people’ currently describes photos (and videos) of people (who may or may not be identifiable). So let’s rename the guideline to reflect that and get on with fixing the guideline’s contents. If there are other types of media that can be dealt with in substantially the same way as photos, then we might be able to add them to this guideline, but that’s it. Anything else needs to go in separate pages.
Audio recordings have separate legal issues to visual recordings, and may have other issues too. They definitely need to be covered by a separate page. AI generated media already has its own page (special mention to the section on deepfakes, which refers back to the photos guideline).
For other media (drawings, paintings, sculptures, anything else I might have missed), I am not sure whether they can be dealt with in substantially the same way as photos. Brianjd (talk) 11:17, 20 January 2023 (UTC)
Hm, I don't directly oppose renaming it - I might have a bit idealistic ideas about improving policies on commons, I know. I just think if we do something, we should do it right and include all media, but I am also happy to support a smaller fix as suggested by you.--Kritzolina (talk) 15:47, 20 January 2023 (UTC)

The need to improve understanding of licensing for new uploadersEdit

Commons:Deletion requests/File:Concurso de canto Nuestra Voz 2015.jpg

Yet another DR where the content is probably intended for use here, but we just can't keep it because the situation is unclear. The uploader appears to be an agent acting for the subjects, but not the photographer. As we've all seen so many times before, it's labelled as "Own work" and this just isn't plausible. The uploader has a handful of edits and a few years later, we're left with no practical option other than deletion.

Clearly uploaders still aren't understanding our needs here. We need to communicate better. We need to make them more aware of what 'own work' has to mean, and give them better guidance for how to work with other people's creations (I'm thinking here of the case where they can and should be uploading here, but there needs to be better recording of this and the necessary permissions).

How can we do this? The upload wizardry seems unchanged for as long as I can remember, and it's clearly not meeting our needs here. What can we do to improve communication to these new uploaders?

Static pages haven't worked. We have an upload wizard, surely that could become more responsive and interactive if uploaders are claiming "own work" through it? Can we engage them more, have some sort of dialogue as to just what they mean by this, and are they reaching the level of proof needed? (i.e., a push towards COM:VRT if needed).

I'm tired of seeing DRs like this. Everyone acts in GF, but the end result is negative for both sides. We should be able to do better. Andy Dingley (talk) 13:57, 20 January 2023 (UTC)

See Commons:Village pump/Copyright/Archive/2022/04#Permission for own work as well as Commons:Village pump/Archive/2021/07#UploadWizard instructions do not align with actual VRT requirements for my comments on the issue. For the latter, unfortunately parts of the UploadWizard interface are on TranslateWiki instead of Commons, so I'm not sure how to update it. -- King of ♥ 21:20, 20 January 2023 (UTC)

When copyvio is incidental and easy to fix, place a burden on deleters to do soEdit

Tons of w:WikiProject Apple Inc. images keep getting speedily deleted for incidental copyvio (e.g. a picture of a MacBook Air, that is partially copyvio because of the copyrighted wallpaper).

Because these are speedy deletes, there isn't any time for anyone on enWiki to react by blurring the wallpaper to "rescue" the image. File:IPhone 14 Pro - 2.jpg was just speedily deleted, despite being used on the high-traffic w:Apple Inc. article. It's untenable. Pictures of modern Apple products are extremely rare. We no longer have any good (non-render) images left of the iPhone 14, and without my past interventions, we wouldn't have a single pic of the iMac M1 or the MacBook Air M1/M2 either.

Propose, specifically for pictures of computers, where the copyvio is incidental:

  • Impose a burden on deletion nominators. The copyvio can be fixed without deleting the picture, so deleters should have a burden to fix it, before deleting the previous revision. (edit: withdrawn; I invite contributors to comment on Davey2010' and King of Hearts' proposals instead)
  • Or: figure out a way to give people on enWiki a chance to fix these issues, before these images are lost to time.

Surely there's a better way than this. DFlhb (talk) 17:39, 20 January 2023 (UTC); edited 01:28, 21 January 2023 (UTC)

  •   Support the following exception to COM:CSD: If only a portion of an image is a copyright violation, and the image is COM:INUSE in a way that would not be rendered useless by the removal/cropping/blurring of the offending portion, then the image is ineligible for speedy deletion. This applies as well, for example, to a collage of 5 pictures of a city where one of its components is deleted as a copyvio. So compared to your proposal, I am expanding the scope to be not specific to computers, but also limiting it to only in-use images, since not every photo of a copyrighted iPhone screen is worth saving via editing. I also don't want to put the burden on deletion nominators in general; as long as they use DR, those wishing to retain the image will have ample opportunity to fix it. -- King of ♥ 17:59, 20 January 2023 (UTC)
  • Clearly "speedy" should not happen in these cases, but I think there should be no specific burden on the deleter. The normal deletion process gives plenty of time for someone to "rescue" the file. "Burden on the deleter" to fix rather than delete means that no one could ever delete on this basis. - Jmabel ! talk 18:54, 20 January 2023 (UTC)
I think the correct CSD template for such cases is {{Dw no source since}} wich already gives seven days so solve the problem. GPSLeo (talk) 19:13, 20 January 2023 (UTC)
The problem is that in a lot of cases, it qualifies for F1 or F3 as well. Some users will exercise good judgment and use DR or one of the 7-day options when more appropriate, but others just try to get an image deleted as quickly as possible, and right now what they're doing is technically compliant with CSD policy even if it is not the best option. I think we should tweak the policy to explicitly ban people from using speedy when the image can plausibly be fixed and there is clear value in doing so. -- King of ♥ 19:22, 20 January 2023 (UTC)
@King of Hearts: I'd have no problem with that. - Jmabel ! talk 20:22, 20 January 2023 (UTC)
  Support - I would go one step further and say these images should not be deleted at all but instead moved to a category where people can check it from time to time and blur the images if and when they have time, I've rescued plenty of images like this and would be more than happy to help from time to time, –Davey2010Talk 22:17, 20 January 2023 (UTC)
I far prefer this version to mine. I also really like King of Heart's idea, and the ineligibility for speedy. I support both both your idea and KoH's, and now oppose mine (burden on reviewers) due to the good arguments presented above. DFlhb (talk) 23:11, 20 January 2023 (UTC)
  Support, exactly what Davey2010 said. Also, I have noticed a number of DR's where the nominators have said that "this image is likely in the public domain but incorrectly tagged" like this one, maybe these should also have a category like "Likely free files with an incorrect license" or something. The Wikimedia Commons has a steep learning curve and many who have taken the time to learn the right licenses aren't taking the time to help others out, I think that a lot of well-meaning users come here to upload public domain files but don't know how to properly tag them and then see all their images deleted, this then translates into low user retention and this is because the burden is placed 100% (one-hundred percent) on the uploader to do everything right all the time, people will improve if you take the time to teach them, but if you speedily delete their images they're less likely to return. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 23:21, 20 January 2023 (UTC)
  Oppose Saying that the burden is on the would-be deleter to fix it amounts to saying these can never be deleted. If there is no way to delete images that have elements that are problematic with respect to copyright, regardless of how long they sit there without being fixed, we will accumulate large numbers of such images. They should not be speedied, but a week is plenty of time for someone to fix this for a given image if they care. - Jmabel ! talk 01:19, 21 January 2023 (UTC)
There is clear consensus against my initial proposal, so I'm withdrawing it. King of Hearts' and Davey2010's proposals seem the most likely to achieve consensus, so I'm editing the opening post to invite readers to comment on those proposals instead. Best, DFlhb (talk) 01:28, 21 January 2023 (UTC)