Commons:Village pump/Proposals

• Community portal
  • introduction
• Help desk
• Village pump
  • copyright
  • proposals
  • technical
• Administrators' noticeboard
  • vandalism
  • user problems
  • blocks and protections

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/2025/09.

COMMONS DISCUSSION PAGES

• Commons Help desk
• Village pump (general discussion)
  • Copyright
  • Proposals
  • Technical
• Graphics and photography discussion
  • Photography critiques
  • Image improvement
    • Illustration workshop
    • Map workshop
    • Photography workshop
    • Video and sound workshop
• Categories for discussion
• Undeletion requests
• Deletion requests
• Volunteer Response Team/Noticeboard
• Translators' noticeboard
• Work requests for bots

---

• Contact administrators
  • Vandalism
  • User problems (Dispute resolution)
  • Blocks and protections
• Bureaucrats' noticeboard
• CheckUser requests
• Oversight requests

---

• Telegram
• IRC ^webchat
• Commons mailing list (archive)
• Commons' bugs on Phabricator

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?
  
  

 

Start a new discussion

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

Disallow administrators from supervoting when closing SCOPE related DRs

I think we all agree that it's important for administrators use a measure of neutrality when making decisions. At least we should. There's been many instances over the years where admins have closed SCOPE related deletion requests as keep or delete based on their own personal opinions, not the number of users who voted that way or even based on the strength of their arguments. I have yet to see an instance where doing so didn't either just cause needless drama, the files to be re-nominated for deletion, or both.

At the end of the day it should be on members of the community to decide what exactly is in scope and educational for our project. It's not, or at least shouldn't be, on individual admins to decide what is based on their personal opinions and regardless of how many users in the DR disagree with them. Doing so just pisses people off and discourages participation. So supervoting in SCOPE DRs should not be allowed. I don't expect there to be any consequences for it, but the DR where it's done should re-opened and/or re-closed by another, more neutral administrator.

Votes (Disallow administrators from supervoting when closing SCOPE related DRs)

• Abstain as proposer. Although I obviously support it. --Adamant1 (talk) 18:03, 3 September 2025 (UTC)
• Support banning supervoting in general. A DR should either be uncontested or have a clear consensus for an admin to act on it. That should be common sense. --Dronebogus (talk) 18:08, 3 September 2025 (UTC)
• Support supervoting like that just makes a mockery of the process- why bother having a discussion/!vote if it all depends on what the closing admin thinks. DoctorWhoFan91 (talk) 18:11, 3 September 2025 (UTC) Do whatever folks, but probably start by assuming good faith of each other
•  Oppose there are many cases where users vote who are not active community members. There are regularly cases with coordinated voting. GPSLeo (talk) 18:22, 3 September 2025 (UTC)

  One can fight coordinated voting by questioning the coordinated voters. DoctorWhoFan91 (talk) 18:27, 3 September 2025 (UTC)

  Admins can ignore obvious cases of vote manipulation or “empty” votes with no argument. That could be written as a carveout. But a good-faith consensus cannot be overridden by a single admin’s opinion. Dronebogus (talk) 18:29, 3 September 2025 (UTC)

  @GPSLeo: Coordinated voting already isn't allowed. So I wouldn't say an administrator who ignores it is "supervoting" anymore then I would if they ignore vandalism, obvious harassment, or anything else along those lines when closing a DR. That's not supervoting. --Adamant1 (talk) 18:28, 3 September 2025 (UTC)

  This only moves the problem where to draw the line between legitimate expression of interest of a group and not legitimate coordinated voting. The majority of coordinated voting (mostly coming from a discussion on other wiki) on deletion requests does not violate any rule. GPSLeo (talk) 18:35, 3 September 2025 (UTC)

  Do admins even do anything to stop coordinated voting now? Because in my limited experience they don’t. Dronebogus (talk) 18:37, 3 September 2025 (UTC)

  No, if not done using sockpuppets or using inappropriate language there is no policy against this. We can only just ignore their votes and comments. I think this is the correct way to handle this. GPSLeo (talk) 18:42, 3 September 2025 (UTC)

  It really depends. At least in my experience if an account is an SPA they usually factor that in to the close and ignore them. Or if it's a sock they will block it and not count the vote. But I don't think it actually effects this in any meaningful way. Otherwise the whole thing just becomes circular. "We can't have this policy because another policy doesn't exist" and so and so forth. You have to draw a line somewhere. --Adamant1 (talk) 18:44, 3 September 2025 (UTC)

•  Oppose People level accusations of supervoting when they don't like the outcome of the discussion, but I can't recall a single situation where someone leveled that accusation and the community went "yep, that close was a mistake". I'm sure it has happened, but the overwhelming majority of accusations - as is the case with the accusations leveled against Abzeronow and myself above - are spurious. I'll go into more detail about the the Exey Panteleev situation in that discussion thread, but for this discussion thread, I'll just say that trying to codify a policy around a highly subjective term typically leveled by people angry at the outcome of a messy discussion isn't going to solve any problems, it's just going to make messy situations more messy. The Squirrel Conspiracy (talk) 20:19, 3 September 2025 (UTC)

I can't recall a single situation where someone leveled that accusation and the community went "yep, that close was a mistake" @The Squirrel Conspiracy: That's because there is no meaningful "community" on here at this point because of issues like this one. Fully stop, there's literally zero point in contributing to a DR, let alone is there any in contesting the closer of one, if participants who reasonable arguments are just going to be ignored by whomever closes it. This stuff is always circular and self justifying though. Admins do things to turn people off from participating in deletion requests. So then the lack of participation becomes the justification for you guys to continuing to do it. --Adamant1 (talk) 02:06, 4 September 2025 (UTC)

•  Oppose I get the point but I don't think it's supervoting, when most of the time it's admins making tough and complex decisions some people will not like because of their (perceived) negative outcome. --Bedivere (talk) 02:29, 4 September 2025 (UTC)

  I forgot to mention: questionable decisions can always be revised or even reversed. Closure or so called supervotes are not written in stone. Bedivere (talk) 02:43, 4 September 2025 (UTC)

  @Bedivere Where does one ask an admin to re-open a closed discussion on Commonns? DoctorWhoFan91 (talk) 14:25, 4 September 2025 (UTC)

  @DoctorWhoFan91: At least from what I've seen there isn't an official process to do it. So you usually have to ask the admin on their talk page. 99% of the time they will just talk in circles, refuse to do it, and just act like the user is being argumentative though. Kind of the same as some of the comments here claiming that the only reason anyone would care about supervoting is because they don't like the outcome or whatever. --Adamant1 (talk) 15:04, 4 September 2025 (UTC)

  Ignoring other people’s opinions because you’re the one in a position of power isn’t a “tough [or] complex decision”. You’re treating non-admin Commons users like they’re children and you know what’s best for them even if they don’t like it. Dronebogus (talk) 13:34, 4 September 2025 (UTC)

  Well, other people's opinions can be wrong too. And as I said, responding to @DoctorWhoFan91 an admin can be reached on their talk page or you can just renominate the conflicting image for deletion again. Bedivere (talk) 15:00, 4 September 2025 (UTC)

  At least from what I've seen asking the admin about it on their talk page it doesn't lead to anything except pointless arguing. There should really be more official processes and guidelines for this stuff outside of asking you guys to pretty please with a cherry on top to reverse your own crap actions. --Adamant1 (talk) 15:08, 4 September 2025 (UTC)

  "an admin can be reached on their talk page"- while they say shit like "the images illustrate the concept well" and the concept is "unicode characters on naked women"?? Like I'm trying to assume good faith, but all it says to me is "men would find anything educating if it's on a naked woman."

  I did renom them, TSC had an issue with it and closed the discussion- so don't say there is a process for getting admins to listen while they do stuff like that. DoctorWhoFan91 (talk) 15:09, 4 September 2025 (UTC)

  I think the process should be “administrator recall”. Dronebogus (talk) 19:27, 4 September 2025 (UTC)

  I was thinking more "a place to discuss DR closes" and not "let's just be a spinoff of en.wp"(like calm down, mate). DoctorWhoFan91 (talk) 20:01, 4 September 2025 (UTC)

•  Oppose per Bedivere.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 02:35, 4 September 2025 (UTC)
•  Oppose I've disagreed with many closes, and I've run into some tone-deaf admins. That said, closing is not just counting votes but rather evaluating the stated positions; it is not a vote. Furthermore, outlawing supervoting would enable canvassing and ballot stuffing. Glrx (talk) 22:30, 4 September 2025 (UTC)
•  Oppose. If there's a specific close that is problematic, we can talk about that, but I see no evidence of a systemic problem. Frankly, I think allowing the Panteleev discussions to go on for any amount of time was generous, given how many previous DRs there had already been with the same arguments and same outcome. When a settled matter is brought back up over and over, that's not building consensus; that's just an endurance test. Genuine community consensus should not be overturned because the minority is more persistent. –IagoQnsi (talk) 16:08, 5 September 2025 (UTC)

  If you actually took the time to go through the discussions instead of just saying per this person and this person, you would see that the arguments are usually different. DoctorWhoFan91 (talk) 17:11, 5 September 2025 (UTC)

Your claim that the people who want the the Panteleev images to be deleted are just a persistent minority is patently false. The persistent minority is the two or three people who repeatedly steamroll any discussion even slightly related to the photographs with their handwaving nonsense. The majority on here have always wanted the images to be deleted though. Administrators just can't be bothered to not go with whomever makes the shortest, lamest non-argument in any given DR for some reason. But if you actually look through the discussions essentially everyone except for 1 or 2 users who repeatedly steamrolled the discussions wanted the images to be deleted. --Adamant1 (talk) 17:16, 5 September 2025 (UTC)

•  Oppose The Squirrel and Bedivere above said it all. Yann (talk) 16:02, 6 September 2025 (UTC)

Wow, you mean administrators don't want any kind of basic standards for how they make decisions? Who could have figured. --Adamant1 (talk) 16:54, 6 September 2025 (UTC)

 Support The lack of policy on supervoting means that admins are ultimately free to ignore the arguments of other users that they don't agree with, which goes against the idea of a consensus process, and, ultimately, of a wiki. Chaotic Enby (talk) 17:51, 6 September 2025 (UTC)

No, no, you don't understand- admins are trying to protect us from the evil canvassers by ignoring the opinions of everyone must themself. DoctorWhoFan91 (talk) 18:10, 6 September 2025 (UTC)

@DoctorWhoFan91: I'm not going to do it myself because I'm sure whomever does would get blocked, but it would be hilarious if someone closed this as approved even if it's not and then went off about how administrator's only voted due to being canvassed lmao. But I really do wonder how people don't see the hypocrisy or precedent that's being set by opposing this. At that point @Dronebogus: might as well close the proposal to ban AI images of people as rejected even though he's essentially the only who voted against it. Why the hell not? --Adamant1 (talk) 23:05, 6 September 2025 (UTC)

•  Oppose per Glrx. --ReneeWrites (talk) 22:10, 6 September 2025 (UTC)
•  Oppose because I don't think sysops should take their own opinion into account when determining consensus or making decisions – and if they cannot, that raises questions on whether they're even suitable for sysop in the first place. --SHB2000 (talk) 23:43, 6 September 2025 (UTC)

  @SHB2000: So you’re basically saying you agree with the proposal, but oppose it because you think sysops should just be expected to refrain from supervoting out of the goodness of their hearts? What’s wrong with just making it a rule then? Dronebogus (talk) 03:38, 7 September 2025 (UTC)

•  Oppose, I don’t understand the premise of the proposal here, but I disagree with closing a DR solely based on “number of votes” or “strength of arguments” in a DR (including SCOPE DRs). When an admin closes a DR, it should always be based on relevant copyright laws first, then Commons policies, then existing Commons consensus, then only finally consensus in the DR discussion. Sometimes I disagree with outcome of a DR, but I do trust the closing admin made the decision with careful consideration and with their experience and knowledge, not with their personal opinions. As SHB2000 mentioned above, if indeed an admin is closing DRs solely based on their personal opinion, then it is not a matter re-opening DRs, but a matter of whether they are suitable to be an admin. Tvpuppy (talk) 02:23, 7 September 2025 (UTC)

  About your last line- yes, it's also about that person's suitability as admin, but I think people are trying to find an alternative that does not risk lowering the already low number of sysops. DoctorWhoFan91 (talk) 06:24, 7 September 2025 (UTC)

  Why not appoint new sysops who actually represent the community then? Dronebogus (talk) 04:45, 9 September 2025 (UTC)

•  Oppose Closers have to make decisions based on policy, including scope. When there are close cases, they give what we hope is their best interpretation. Unfortunately, they can be wrong, and worse, correct decisions can be quietly overruled through speedy deletions later and then, if noticed, have to be appealed as Commons:Undeletion requests. But that's not a good reason to try to turn admins into robots. As for "appointing new sysops", more users would have to want to act in that role and go through a nomination process, but we all know that there are not enough admins to come anywhere near keeping up with all the deletion requests, etc. -- Ikan Kekek (talk) 05:14, 9 September 2025 (UTC)

  Nobody’s trying to turn admins into robots. We just want admins that neutrally implement a valid community consensus. If they want to express an opinion, they can actually participate in the discussion like everybody else. Dronebogus (talk) 18:47, 9 September 2025 (UTC)

  "We just want admins that neutrally implement a valid community consensus." In other words, you just want deletion requests to be majority decisions. You don't need an admin for that, just a script that counts votes after a specified amount of time and closes a thread as a keep or deletion. But that would cut policy out of the decision. -- Ikan Kekek (talk) 02:20, 10 September 2025 (UTC)

  No, that’s strawmanning my position. I want a human sysop who can weigh voters’ arguments to an extent, but not one who is just going to disregard a majority consensus because they don’t like that consensus or implement a close based entirely on their singular personal opinion that has nothing to do with what anyone said in the DR. If admins are allowed to close literally however they like why have a DR at all? Dronebogus (talk) 02:37, 10 September 2025 (UTC)

  So they can consider arguments. It doesn't obligate them to agree with the majority. -- Ikan Kekek (talk) 03:29, 10 September 2025 (UTC)

  Unless the majority consists simply of empty votes, obvious sock/meat puppets, or non-arguments there’s no reason to go against it. Dronebogus (talk) 06:35, 10 September 2025 (UTC)

•  Support Supervoting is not a thing on Commons. It seems quite obvious to me that admins should not override good faith consensus; nor should they decide affirmative on proposals they themselves proposed. This common practice needs to stop. --Enyavar (talk) 08:07, 25 September 2025 (UTC)
•  Oppose One or two users agreeing to delete a file is not a reason to delete it, if nobody else notices the deletion request to oppose it. Deletion must be based on policy and rationality, and administrators are supposed to know the policies well. MGeog2022 (talk) 15:03, 24 October 2025 (UTC)

Discussion (Disallow administrators from supervoting when closing SCOPE related DRs)

• Flawed premise - There is no such thing as "supervoting" on Commons. That is a Wikipedia concept. For better and worse, we afford admins more leeway here to enforce policy, make decisions, reduce disruption, etc. Two things, though: first, it's hard to separate this from the context, which is (yet again) the Geekography images. I'll hold off commenting until the above proposal is resolved, since we're otherwise wasting time talking about an unusual case. Second, one thing I would support -- which you may or may not see as related, but has become a pet peeve of mine -- is to have some language somewhere that encourages admins to articulate reasons for a closing decision other than e.g. "per discussion" when the discussion is not self-evident. But that would be a different proposal, of course. — Rhododendrites ^talk |  18:18, 3 September 2025 (UTC)

  “There’s no such thing”? Why, because you say there isn’t? It’s literally going on right now with multiple admins closing DRs based on personal whims. Admins should have to respect community consensus; otherwise why even have a vote? Dronebogus (talk) 18:22, 3 September 2025 (UTC)

  [sigh] No. Read the actual policies that apply here. Commons doesn't even have a "consensus" policy, and it's barely mentioned in most policies. That does wind up how we make a lot of decisions, but it's not the organizing principle that it is on Wikipedia. The deletion policy just says The file/page may be deleted on decision by an admin if there were good reasons given in the debate for doing so instead of "assessing consensus and making a decision". Point is, you're applying principles from Wikipedia to Commons. The bludgeoning and assumptions of bad faith are starting to get out of hand with this stuff. — Rhododendrites ^talk |  18:33, 3 September 2025 (UTC)

  The debate was actively going on- and abzeronow was involved in it. There were reasons being given in the DR and here on the village pump- abzeronow actively chose to ignore them.

  I hope I'm not doing the bludgeoning (I'm definitely not doing the bad faith thing). DoctorWhoFan91 (talk) 18:37, 3 September 2025 (UTC)

  In my experience ‘bludgeoning” usually means “I think you’re talking too much and hope some admin agrees enough to threaten you into shutting up”. Dronebogus (talk) 18:39, 3 September 2025 (UTC)

  I'm going away from this discussion- it feels like it's gonna turn into a mess, and I don't want to get punished by association for anyone else's edits. DoctorWhoFan91 (talk) 18:42, 3 September 2025 (UTC)

  Good idea. Dronebogus (talk) 21:09, 3 September 2025 (UTC)

  In retrospect I probably should have waited until the other proposal was finished to do this one since there is some overlap. Even though I think minimal and there's plenty of other examples. That said, I agree the timing could have been better. I just to have some free time and it was on my mind anyway. But that's still my bad for not waiting to do it. --Adamant1 (talk) 21:36, 3 September 2025 (UTC)

  The issue there was not just the "supervoting"(call it whatever you want on whatever project)- it's the fact that it was closed with the words "in scope" while the scope is very actively being argued- it's very much an admin imposing their own view- one which they won't even discuss btw- they just repeat the statement. DoctorWhoFan91 (talk) 18:24, 3 September 2025 (UTC)

  @Rhododendrites: "Supervoting" isn't something that Wikipedia came up with. It's been a concept in the corporate world for when certain shareholders, like founders or management, have significantly more voting power than other shareholders. It's certainly not something that's confined to the Geekography images on here either. --Adamant1 (talk) 18:26, 3 September 2025 (UTC)

  Yes. But you're using it in the way one would on Wikipedia. — Rhododendrites ^talk |  18:33, 3 September 2025 (UTC)

  So? W:Wp:CIR is an Enwiki concept but it still applies here. Dronebogus (talk) 18:37, 3 September 2025 (UTC)

  Commons inherits a lot of it's policies, terms, and the like from Wikipedia even if they aren't explicitly laid out anywhere. So I don't really see what the problem with that. Call it supervoting or whatever, but there's still the general concept of administrators making non-neutral closes based on their own personal opinions that this is trying to address. So I don't think the exact semantics matter that much. --Adamant1 (talk) 18:41, 3 September 2025 (UTC)

• I'm not going to vote in this discussion, but a close where there is no consensus to delete and no clear policy reason to delete is not a "supervote". There was a discussion in which I was thinking of deleting based on whether a particular crop was in scope but the discussion was also full of animosity between the nominator and the uploader and I felt the merits over policy was overshadowed by that. So I noted in the close that there would be no prejudice in reopening that discussion with a different nominator so the discussion could be solely focused on discussion of if the crop was in scope or not. Abzeronow (talk) 01:23, 4 September 2025 (UTC)

Cool. I never said this has anything to do with the Exey Panteleev photographs in my original comment and I've been pretty clear since then that it's a wider problem. Apparently I can't make a proposal about a long standing issue just because you got in a row with a couple of users about some photographs that I never brought up and could really give a crap about though. Go figure. --Adamant1 (talk) 01:58, 4 September 2025 (UTC)

OK, I can accept that you were just trying to make a broader point based on a number of incidents, the timing made it seem like it was a continuation of the discussion above. Somebody had to close the DRs that had been open since May, and I didn't see consensus to delete. Abzeronow (talk) 01:36, 7 September 2025 (UTC)

@Abzeronow: That's fair. I doubt even necessarily even disagree with the way you closed the DR. Since there was already precedent to follow at that point. It's more just a general thing. The timing for the proposal was bad though. So it's natural for people to think they are connected. --Adamant1 (talk) 03:08, 7 September 2025 (UTC)

Strange proposal. It's not really explained or defined what supervoting entails. How will someone asses if it is supervoting or not? The described behaviour ("individual admins to decide what is based on their personal opinions and regardless of how many users in the DR disagree with them") is in my opinion currently not allowed. See Commons:Administrators: "administrators have no special editorial authority by virtue of their position, and in discussions and public votes their contributions are treated in the same way as any ordinary editor". I very much agree with the quoted sentence --Isderion (talk) 22:11, 6 September 2025 (UTC)

"Supervoting" just means closing a discussion based on the admins personal preferences instead of voters' opinions. It's not that complicated of a concept. You can say that's not currently allowed, and your correct to a degree, but there's no formal way to have a bad close reviewed outside of begging the admin to reconsider it. Which 99% of the time they aren't willing to do. Cool if people don't think dislowing supervoting is the answer to that, but then what's the solution since graveling to clearly unresponsive, tone deaf adminstrators when they make mistakes clearly isn't cutting it? --Adamant1 (talk) 22:23, 6 September 2025 (UTC)

• Very few things on Commons are actually a vote. For example, in a DR, if one person makes a solid argument that a work is copyrighted and not licensed, it doesn't matter how many people say, "but the file is really important." For another example, if a duly licensed file of a questionable map related to the current war is in use on the Russian or Ukrainian Wikipedia, our policy is that we might add {{Factual accuracy}}, but it shouldn't matter how many people prefer actual deletion unless the issue is first settled on the Wikipedia in question. Conversely, no admin is going to come out and say, "This is a judgement call and I can see that there is 80% agreement but I don't like it so I'm going the other way," so it is never going to be a clearcut supervote.
• I've seen a fair number of bad closes get overturned. What do we gain by the specific adoption of a rule around "supervotes"? How is a "supervote" functionally any different than any other bad close? - Jmabel ! talk 01:27, 7 September 2025 (UTC)

  I don't see how it is. Admins have to rule on policy. That's not a "supervote" to me, just a decision. -- Ikan Kekek (talk) 05:07, 9 September 2025 (UTC)

I've seen a fair number of bad closes get overturned. @Jmabel: Have you? I haven't. I guess for me it's more about trying to avoid contentious decisions in the first place. Especially one's related to neutrality. Since there's been real issues lately with administrators doing involved editing and/or making decisions based on their own personal preferences. I don't think it matters so much with questions of copyright, as there's clearly no room for give there.

But I do think admins should stay as neutral as possible when it comes to determining the educational value of any given image or set of images on here. Since there's more room for interpreting SCOPE then exists for copyright. I don't think the small amount of admins who close DRs should be determining what's educational for everyone else though. --Adamant1 (talk) 03:08, 7 September 2025 (UTC)

• I oppose this specific proposal but think that it's a very valid issue worth discussing. A few thoughts on the proposal and the discussion above...
  - COM:CONSENSUS might be red but Consensus is still a major part of the project and of DRs. COM:Administrators links to the essay COM:Staying mellow so obviously Consensus has some level of policy support here. Yes, COM:Deletion requests makes it clear that administrators are empowered to make a decision based on copyright and policy against consensus of a discussion in the DR, but many of our DRs are not clear-cut copyright/policy decisions, and require some level of interpretation or preference. COM:Administrators says Apart from roles which require use of the admin tools, administrators have no special editorial authority by virtue of their position, and in discussions and public votes their contributions are treated in the same way as any ordinary editor which could be read a few ways, but to me this implies that they have additional power in DRs to use the tools, but not necessarily in making editorial decisions. We could probably have a long discussion on this topic and make the above quote a little more clear (in either direction).
  - en:WP:Supervote isn't banned on Wikipedia - it's an essay describing behaviours that arise from their discussion closure policies. We could have a similar essay here discussing the same topic with the nuances unique to Commons. The Wikipedia essay distinguishes between various variations of supervoting (generally a bad thing) and admin discretion (part of the role we entrust to admins); I'm sure the discussion here is intended to discuss the former and not the later. And if we try to avoid COM:WIKILAWYERING about whether every concept must have a policy (or even essay?) page on Commons for it to be discussed, I think it's easy to imagine the cases where a "supervote" could be problematic.
  - COM:Deletion requests says: The debates are not votes, and the closing admin will apply copyright law and Commons policy to the best of their ability in determining whether the file should be deleted or kept. Any expressed consensus will be taken into account so far as possible, but consensus can never trump copyright law nor can it override Commons Policy. If the closing admin is unable to say with reasonable certainty that the file can validly be kept, it should be deleted in accordance with Commons' precautionary principle. It is not the task of the closing admin to engage in detailed legal or factual research in order to find a rationale to keep the file. Under the rules of evidence we apply here, the burden of showing that the file can be validly hosted here lies with the uploader and anyone arguing that it should be kept.
  ---^This specifically directs the closing admin to "say with reasonable certainty". What does it mean to say something with reasonable certainty - put it in bold type? Declare it like Michael Scott from en:The Office (American TV series) declared bankruptcy (with exclamation marks)? They should not only "say it with reasonable certainty", but explain their reasonable certainty (or lack thereof, leading to the precautionary principle).
  - If we were to have guidance in this area, I think it should advise (similar to Rhododendrites above): In general, administrators should close deletion requests based on weighing the arguments and interpretations raised in the discussion and their validity against Commons policy and copyright. Administrators may close deletion requests against discussion consensus based on policy and copyright, but when doing so they should clearly explain the policy or copyright rationale for their closure.
  ---^A closure against discussion consensus which does not have a clearly explained policy or copyright justification is likely to be relitigated by the discussion participants, which is a big waste of many volunteers' time.
  - I agree with Dronebogus below that the other half of this is the ability to constructively appeal closure, which today is not a problem when appealing deletions via COM:UDR, but not for appealing Keeps, where re-nominating 1) could be speedy closed and 2) might not get any additional input in order to assess whether the initial decision was correct.
  -Consigned (talk) 21:22, 10 September 2025 (UTC)

  Excellent post. I agree with your proposed guidance. -- Ikan Kekek (talk) 22:36, 10 September 2025 (UTC)

• With regard to "scope" what I think Wikimedia Commons needs is the inverse of precautionary principle. If there is a significant doubt about the "scopeness" of a particular file, it should be kept. Simple as that. If there are Wikimedia Commons users who claim somehow something is educative, please en:Wikipedia:Drop the stick and back slowly away from the horse carcass. Strakhov (talk) 01:20, 13 September 2025 (UTC)
  • Re: If there are Wikimedia Commons users who claim somehow something is educative… @Strakhov: despite a lot of respect for you, I disagree. There are users here who will defend practically all porn as somehow educational; there are users who will defend anything they agree with politically no matter how much it is simply non-notable user-made propaganda; there are users who will defend ridiculously extensive collections of family photographs of their own relatives; there are people who defend false and misleading maps, utterly imaginary user-fantasy flags, and all manner of AI slop. I could go on. If we bow to everyone's notion of what should be in scope we become a completely indiscriminate media collection, distinguished from (say) Flickr mainly by providing unlimited free hosting. - Jmabel ! talk 07:07, 13 September 2025 (UTC)

Possible new proposal: implement a formal DR close appeal system?

This proposal is obviously never going to be approved, so instead of banning “supervoting” should there instead be a formal system for appealing bad “keep” closes? I know one exists for bad deletions, but the only way to appeal a keep closure is either re-nominating the file or directly confronting the admin responsible. As demonstrated recently admins can simply dismiss the former as system-gaming (or some other technical objection) and have no obligation to even respond to the latter let alone implement it. Therefore there functionally is no way for bad keep closures to be appealed effectively. --Dronebogus (talk) 18:58, 9 September 2025 (UTC)

A formal process for appealing DRs isn't necessarily a bad idea, but the tide is well against you in this case. If this is a proposal you want to pursue even beyond the present case, you may want to just take some time, gather evidence of a range of DRs you weren't involved with where an appeal system would've helped, and put together a concrete proposal for people to consider. — Rhododendrites ^talk |  19:54, 9 September 2025 (UTC)

There is already an appeal process for deleted files and pages. It is at COM:UDR. While it is certainly not perfect, creating a new process isn't the solution. I would support some changes to the current process: formal rules about closing UDR, better archiving system, etc. Yann (talk) 16:20, 23 September 2025 (UTC)

@Yann: how would someone use UDR to appeal a DR that was closed as "keep"? - Jmabel ! talk 20:00, 23 September 2025 (UTC)

One would use DR for that, like it's done nearly every day. Krd 14:05, 24 September 2025 (UTC)

As I understand it, the proposal was made precisely because people have been chastised for starting a new DR shortly after one was closed as "keep," so saying that they can do what they've been chastised for is at least not a complete answer. - Jmabel ! talk 19:06, 24 September 2025 (UTC)

If they have new arguments, they can go that way and won't be chastised. If they don't have new arguments, they shouldn't get another decision. Project goal of Commons is to build a file repository, not to please everybody every time, and also not to build the best ruleset regardless of the required overhead. Krd 20:23, 24 September 2025 (UTC)

@Krd: A large part of this has to do with situations where the administrator who closed the DR as keep made a bad call. There's absolutely zero reason what-so-ever that whomever re-nominates the files for deletion should have to make new arguments or risk being attacked for it. --Adamant1 (talk) 00:55, 25 September 2025 (UTC)

As I explained above, I very strongly support this idea, and agree with Rhododendrites that it should be worked on and submitted separately. -Consigned (talk) 21:58, 24 September 2025 (UTC)

•  Comment @Dronebogus: It seems like there's support for the idea of implementing a formal DR close appeal system. Can someone (Dronebogus or anyone else) start a draft page or figure out the next steps to doing that? --Adamant1 (talk) 01:41, 25 September 2025 (UTC)

  I'm not interested in drafting it, but I have a few thoughts.

  • Anything I could support would require actively notifying on their user talk page the person [typically an admin] whose close is being challenged, and at least pinging everyone who had commented on the DR in question.
  • I'd suggest that there needs to be a lot of clarity about who can close the discussion on such a challenge (presumably never the person who starts the challenge, nor the prior closer).
  • I'd suggest that the drafter consider enumerating existing ways of overturning a DR.
  • Are there any circumstances where a DR resulted in a deletion and this new mechanism is to be used in preference to a UDR?
  • Is it required to attempt discussion with the closer before opening a formal challenge to a DR under this new mechanism?
  • Is there to be some limit on how many of these a single user can open in a given period of time, or about the same file, to prevent constant relitigation?
  • Is there a limit on who may use this mechanism? E.g. any user in good standing vs. at least auto-confirmed / just not topic-banned from doing so, etc.; possibly disallow the person who had started the DR in the first place.
  • I'd suggest that the drafter consider enumerating the proposed grounds for overturning a DR that this mechanism is intended to address. In particular, which of the following are and are not allowed?
    • Argument disputing the stated basis of closure, without any additional evidence.
    • Additional evidence not in the prior discussion (and is there any reason that wouldn't just be another regular DR).
    • "I just think this was wrongly decided" with nothing further to say.
    • Accusation of bias by closer.
    • Accusation of bias introduced via canvassing.
    • [doubtless there are others worth mentioning]

  Jmabel ! talk 03:47, 25 September 2025 (UTC)

  How much overlap would there be between this new mechanism and UDR? I don't spend much time at UDR but it seems to me like its purposes are 1) appealing a deletion that one disagrees with for whatever reason, 2) appealing a deletion based on new evidence, or 3) temporary undeletions e.g. to move to Wikipedia for Fair Use. Could 1 and 2 be done in the same place for both appealing deletions and appealing keeps? IMO the guidance you suggest should apply to both scenarios. Consigned (talk) 08:16, 25 September 2025 (UTC)

  • @Consigned: As I understand it, this is far more about appealing a "keep" than about appealing a deletion; as you note, we already have a solid mechanism for the latter. Also I could imagine it being a potential place do discuss future undeletion date, for which I believe we don't currently have a good forum. It is possible that it could be broader, including that it could be a broadening of UDR, supplanting the current UDR. - Jmabel ! talk 18:21, 25 September 2025 (UTC)

    I'm not seeing why any new procedure is needed in that situation. I remember starting a deletion request for a file that had previously been kept, giving as the reason code in the EXIF that demonstrated the file was previously uploaded on Facebook or Instagram. If the nominator provides a persuasive deletion reason, not just a restatement of a personal argument, it is likely to win the day. -- Ikan Kekek (talk) 03:33, 26 September 2025 (UTC)

    Or just be closed off hand by another administrator "per the previous discussion" or some nonsense. You think this whole thing is made up or that everyone who thinks it an issue just doesn't know how to make an argument? Come on. Know one would be wasting their time on this if it was that easy. --Adamant1 (talk) 04:08, 26 September 2025 (UTC)

    If it's purely an argument over scope, there's no new issue, and especially when files are COM:INUSE, a speedy close "per the previous discussion" is perfect. -- Ikan Kekek (talk) 04:35, 26 September 2025 (UTC)

OWID visualizations

We are gradually launching Our World in Data visualizations within MediaWiki. One can see a bunch of them on Basque Wikipedia as we continue to test and improve things.[1]

The gadget uses a data file like this. We do not want each language to have to create their own version of these data files so the request is can we host these here at Commons? And than have the gadget read the data file from Commons rather than locally. Note all the images used are stored here already.

They would look like this on Commons. I am not attached to the naming or the namespace this were to go in if accepted. Best

Doc James (talk · contribs · email) 15:22, 7 September 2025 (UTC)

Commons seems like a plausible host, but I'm still a bit confused. This is in the Basque Wikipedia but it's in English. How is localization to be done? What exactly would Commons be hosting? - Jmabel ! talk 16:58, 7 September 2025 (UTC)

Sure so with respect to translation all one needs to do is translate the first "world heatmap" image using the SVG translate tool and that will roll through the rest of the interactive graph.[2] Here you can see a mostly translated one.[3] We are auto translating the country names using Wikidata on MDWiki and it will roll out in EU WP soon. Also bits of the gadget also require translation when it is initially installed. You will notice a language parameter in the template used to call an interactive graph. Doc James (talk · contribs · email) 17:01, 7 September 2025 (UTC)

That answers my first question.

@Doc James: What exactly would Commons be hosting? - Jmabel ! talk 17:46, 7 September 2025 (UTC)

Would be hosting the data templates like https://commons.wikimedia.org/wiki/Template:OWID/meat-supply-per-person Doc James (talk · contribs · email) 06:36, 8 September 2025 (UTC)

Seems sane to me, but I doubt you will get votes here either way until this is more concrete. E.g.:

• Would this be a new namespace, or a new file type in the Data namespace?
• Would there be anything beyond the usual free-for-all in who is allowed to edit these? Is there a WikiProject willing to take the responsibility to watchlist them?
• Is there some sort of tool to validate these, or just "if they're broken, they're broken, and it's pretty obvious"?
• Is there anything Commons would have to do besides agree to host them?

Jmabel ! talk 20:05, 8 September 2025 (UTC)

We can do them exactly like this if folks are good with it. https://commons.wikimedia.org/wiki/Template:OWID/meat-supply-per-person

• In the template namespace (not exactly data files as basically a list of Commons images), but could put elsewhere if folks want
• Usual free for all edits, there is a .
• Yah we could build a validation tool eventually. Plan would be for these templates to be updated as more data becomes available on a yearly or so basis.
• Nothing more is required other than agreeing to host.

Doc James (talk · contribs · email) 04:13, 9 September 2025 (UTC)

Would also want to start Commons:List of interactive graphs to contain a list of the available items. Could also do it with categories under Category:Our World in Data. Whichever people think is best. Doc James (talk · contribs · email) 06:39, 9 September 2025 (UTC)

If they are in the template namespace, how are they to be accessed by sister projects? - Jmabel ! talk 22:49, 9 September 2025 (UTC)

The gadget will call them as "Commons:Template:OWID/meat-supply-per-person" Doc James (talk · contribs · email) 06:58, 10 September 2025 (UTC)

Can you invoke a template that way cross-wiki? I thought all you could do with a template on a different wiki is link to it. - Jmabel ! talk 17:29, 10 September 2025 (UTC)

We are loading the template into the gadget as a data file, so I think so. Our programmer is working on this as their next priority. Doc James (talk · contribs · email) 17:55, 10 September 2025 (UTC)

---

I feel like Doc James has clarified this sufficiently that it would be reasonable to vote on it. - Jmabel ! talk 20:10, 10 September 2025 (UTC)

@Doc James:

I'm still confused about the toplevel goal and how such templates will be used.

If your gadget is going to read and parse a template, then why not use Help:Tabular Data instead of a template? The gadget can figure out what to do with the files in the table. Easier to parse than a template.

Alternatively, you could put the graphs in a particular category. The gadget could use the MediaWiki API to retrieve all the files (e.g., countries) in that category and figure out what to do with them.

Glrx (talk) 20:29, 10 September 2025 (UTC)

The top level goal is to bring these multilingual interactive graphs to Commons and Wikipedia in all languages that want them.

Okay will look at the Help:Tabular Data as an option with the tech folks we have working on this. Doc James (talk · contribs · email) 04:44, 11 September 2025 (UTC)

User:Glrx what we need are basically large lists of svgs on Commons. This is not exactly data so not sure the tabular data space is the best place? Still thinking the template space is better as it will also allow other items such as you see here. Doc James (talk · contribs · email) 05:59, 11 September 2025 (UTC)

Why do you want to use SVG for simple graphics? For complex graphics using SVG might be necessary. For simple line charts and simple maps you should use mw:Help:Tabular data with mw:Extension:Chart for simple charts and mw:Help:Map data with mw:Help:Extension:Kartographer for maps. GPSLeo (talk) 06:59, 11 September 2025 (UTC)

The chart extension did not exist when we began development but i agree it would be a good idea for the country graphs. Will look into developing that. With respect to the heatmaps not sure how hard it would be converting the current svgs? Are there examples of heatmaps with mw:Help:Extension:Kartographer? Doc James (talk · contribs · email) 09:11, 11 September 2025 (UTC)

I think heatmaps or similar are currently not really possible. I think the only a bit more complex things possible are election result examples. GPSLeo (talk) 18:13, 11 September 2025 (UTC)

Okay, so maybe try to go with the chart extension for the country graphs and stick with the svgs for the heat maps... Doc James (talk · contribs · email) 18:31, 11 September 2025 (UTC)

Have requested activation of the underlying gadget here on Commons at Commons:Village_pump/Technical#Add_OWID_visualization_gadget_to_Commons Doc James (talk · contribs · email) 22:55, 29 September 2025 (UTC)

Voting

•  Support - Jmabel ! talk 20:10, 10 September 2025 (UTC)
•  Support --Timeshifter (talk) 06:02, 11 September 2025 (UTC)
•  Support --Renvoy (talk) 18:17, 11 September 2025 (UTC)
•  Support --Bedivere (talk) 15:14, 14 September 2025 (UTC)
•  Support --Prototyperspective (talk) 10:25, 15 September 2025 (UTC) Note: for users interested in this, there is this new WikiProject on English Wikipedia Wikipedia:WikiProject Data Visualization.

Adjust DR notice

Template:Idw

such that:

1. the 1st link from the top is the link to the actual DR (instead of Commons:Deletion requests now).
2. add some more visible signs that users should click that link and comment in the DR (instead of on their user talk pages). for example, something like

☞ <DR link> ☜

Reason: I notice that sometimes newbies reply under these talk page notices rather than going to the actual DR, so putting that link as the 1st should minimise this problem.

Here's a draft:

Some contents have been nominated for deletion at

☞ Commons:Deletion requests/Files in Category:1 ☜

This is a deletion request for the community to discuss whether the nominated contents should be kept or deleted. Please voice your opinion in the linked request above. Thank you very much!

... RoyZuo (talk) 18:48, 16 September 2025 (UTC)

I think it would help if you can make a draft on how the new layout could look like. GPSLeo (talk) 19:43, 16 September 2025 (UTC)

•  Support It's a good idea in theory. Although like GPSLeo I'd like to see an example of how the new layout would look but the current template could definitely be clearer. --Adamant1 (talk) 00:45, 17 September 2025 (UTC)
•  Support moving from "its entry" to a bigger link as proposed; I'm open to any wording/formatting in case other options are discussed. -Consigned (talk) 10:47, 19 September 2025 (UTC)

Draft

A page has been nominated for deletion at Commons:Deletion requests/File:HK SW 上環 Sheung Wan 皇后大道中 Queen's Road Centra… This is a deletion request for the community to discuss whether the nominated page should be kept or deleted. Please voice your opinion in the linked request above. Thank you very much! If you created this gallery, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues. Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

I have created a draft template at {{Idw/en/sandbox}}, following the draft suggested by RoyZuo above. Feel free to change it as the discussion continues. Thanks. Tvpuppy (talk) 02:42, 17 September 2025 (UTC)

 Support - Jmabel ! talk 03:20, 17 September 2025 (UTC)

I would support this, but I notice the language "If you created this gallery". Deletion requests most commonly apply to a single image. Should the language of the notice be tweaked further? -- Ikan Kekek (talk) 06:06, 17 September 2025 (UTC)

That sentence was copied from the current template {{Idw/en}}, and the word “gallery” is just the default word used when it is viewed at the template page. When it is actually used, it will change according to the namespace of the nominated file. Thanks. Tvpuppy (talk) 12:25, 17 September 2025 (UTC)

Great! And  Support, accordingly. -- Ikan Kekek (talk) 16:00, 17 September 2025 (UTC)

I would put the link in a button in mw-ui-progressive style to be even more visible: Commons:Deletion requests/Files in Category:1 GPSLeo (talk) 08:06, 20 September 2025 (UTC)

+1 - Jmabel ! talk 17:52, 20 September 2025 (UTC)

I have changed the draft to include the button as you proposed, and I agree it is now more visible. Thanks. Tvpuppy (talk) 23:45, 20 September 2025 (UTC)

I don't expect the notification to be changed more then it has at this point but it would be cool if there something in it about how files aren't actually deleted and that the uploader can do an undeletion request. Since I don't know how many misunderstandings and/or confrontations I've gotten into because people don't know that their files aren't actually deleted and there's an appeal process. --Adamant1 (talk) 00:40, 21 September 2025 (UTC)

Is the emoji still necessary? It seems redundant to the blue button. (And to be honest, it makes it a bit like a spam email.) Also, length can be an issue. File names can be too long for a button (or a link that looks like a button anyway). It would be nice to use an ellipsis when the button label is too long. whym (talk) 03:16, 21 September 2025 (UTC)

You’re right, I don’t think the pointing emojis are necessary now since the button is very visible already, so I removed them from the button.

I also added a character limit for the DR title displayed on the button that will add an ellipsis for overlong titles. I’m not sure what will be a good limit, so at the moment I have set it to 50. You can see the changes in the example above. Thanks. Tvpuppy (talk) 18:30, 23 September 2025 (UTC)

1. my design is using the underline and the fingers to induce a strong subconscious urge to click the link.
2. the button is more prominent, but it breaks the design. to retain that visual link, the phrase "linked request" should be boxed up in the same style. still, it's also not obvious to new users that the blue box/button is actually a link.
3. however, my personal preference is to avoid css styles as long as it's not necessary. the fingers were part of unicode 1.1 introduced in 1993, so they should work just like most letters for most users even if they have really outdated devices, or their software stripped the website of anything but raw text, or they cannot load anything but the text for whatever reason, etc.

RoyZuo (talk) 16:26, 24 September 2025 (UTC)

If we are concerned to make it look good without CSS (I'm not sure we should be), we could include the fingers but have CSS hide them when it styles the button. - Jmabel ! talk 19:55, 24 September 2025 (UTC)

I like that Commons is usable from text browsers, but I don't think they are a priority, mainly because Commons is a media (often, graphical media) repository. In a text browser I use (w3m), the main link of Template:Idw/en/sandbox is bold, underlined, and horizontally centered. I personally think that is enough. If people feel strongly about using the emoji, it could perhaps be included in the link (instead of outside), though. whym (talk) 08:54, 18 October 2025 (UTC)

Is current limitation of cross-wiki uploads sufficient?

We recently enabled the limitation of cross-wiki uploads to users who are autoconfirmed on Commons. This reduced the uploads of copyright violations and out of scope content using this tool a lot. I now had a look at the current uploads from users whose account is three days old. This shows that there are still more problematic than good uploads. I looked at the last 100 Uploads: 30 of these uploads are definitely fine, 21 are obvious copyvios, 21 are definitely out of scope including 6 self promotion photos with also unclear copyright. The other 28 are unclear with some requiring VRT confirmation on copyright or local evaluation if a that bad quality graphic should be in the article. I therefore want to discuss if we need to limit this tool even more to only autopatrolled users. As only 3 of the last 500 uploads using this tool were from autopatrolled users this would be a de facto ban of the tool. GPSLeo (talk) 08:13, 2 October 2025 (UTC)

Do you have perchance data about the geographic provenience of the still-problematic uploads? Are there any obvious socio-demographic trends visible, are there any language editions especially prone for copyvio uploads?

I fear the the WMF won't take it gladly if the tool gets de facto banned, so more fact-based granularity in restrictions would be needed, if possible. That said, I'm fine with a restriction to "autopatrolled" in order to effectively stymie first copyvios and then OOS media. Regards, Grand-Duc (talk) 08:34, 2 October 2025 (UTC)

I will look if I can analyze the data in relation to this. The amount of uploads per project looks like a simple representation of the project size. I also noticed that uploads on non Wikipedia Wikis (Meta and Wikidata) were fine with all 14 from the last 500. GPSLeo (talk) 09:04, 2 October 2025 (UTC)

I created a dataset from the last 30 days with the number of files uploaded per Wiki and the amount of these files they are already deleted. GPSLeo (talk) 09:43, 2 October 2025 (UTC)

Autopatrolled on which wiki? On Commons? This might be too restrictive. For example, autopatrolled is given manually on Commons and I only got it when I had over 100,000 edits. If I remember correctly, I've even seen users with over 500,000 edits on here who still were not autopatrolled. Nakonana (talk) 05:41, 4 October 2025 (UTC)

Thank you for the datamining, GPSLeo. The dataset would IMHO support a further restricting of cross-wiki uploads to everything that is as bad or worse than the current all-Wiki average, meaning Incubator, AR, EN, ES, PL and RU, with FR data providing the cutoff. Then, we / you(?) do the same datamining in, let's say, 6 months (to catch possible avoidance movements). The other Wikis can currently keep the current status. Regards, Grand-Duc (talk) 06:07, 4 October 2025 (UTC)

Restricting by rights on an other Wiki is technically not possible at the moment. GPSLeo (talk) 07:20, 4 October 2025 (UTC)

Wasn't the restriction enforced by a filter? I thought that filtering for strings (like Cross-wiki upload from XY Wikipedia) would be possible. Regards, Grand-Duc (talk) 07:42, 4 October 2025 (UTC)

There is global_user_editcount in abusefilter which could be used as proxy? --Zache (talk) 10:41, 5 October 2025 (UTC)

This could be an option. Maybe with a requirement of 500 global edits? GPSLeo (talk) 14:00, 5 October 2025 (UTC)

@GPSLeo: No, I don't think it's sufficient. Granularly restricting by source wiki would work, if the filters could be configured that way. On the other side of the coin, all users who can cross-wiki upload here can also upload directly here if they want, bypassing any restriction passed here (source wiki or autopatrolled-here only); it's not a high barrier to public participation.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 17:58, 4 October 2025 (UTC)

The "other side" is not really a counter-argument, if you were thinking that way. I think that even low barriers are helpful, in the same train of thought as modified or blocked DNS records are widely employed for anti-piracy motions. They are not hard to bypass at all, but likely deter casual downloaders. So, if upload restrictions continue to be enforced, we'll also likely deter people who would possibly commit casual copyvios. Regards, Grand-Duc (talk) 04:25, 5 October 2025 (UTC)

Based on the short discussion and some statistical evaluation I would propose the the following limitation that would have prevented 2/3 of the deleted files to be uploaded.

Proposal: We limit the use of the cross-wiki upload tool to users who are (auto)confirmed on Commons and have more than 100 global edits. We do not discriminate based on the project. GPSLeo (talk) 09:34, 6 October 2025 (UTC)

I don't like the idea of cross wiki uploads at all, given all the negative issues that have surfaced, but limiting it as proposed seems good to me. Bedivere (talk) 12:16, 6 October 2025 (UTC)

What are some of those negative issues that have surfaced? whym (talk) 12:11, 9 October 2025 (UTC)

users disproportionally uploading copyright violations instead of good contributions. Bedivere (talk) 19:37, 14 October 2025 (UTC)

What made you believe that it's "disproportionally" so? Can you share data or other evidence to help others see what you see? I did some comparison against general uploads before [4][5] (quarry:94356, quarry:94443), and I found no significant difference there. whym (talk) 08:58, 18 October 2025 (UTC)

How many good uploads would that have blocked? --Carnildo (talk) 21:18, 7 October 2025 (UTC)

!votes (limit cross-wiki uploads to confirmed on Commons and >100 global edits)

•  Support.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:59, 6 October 2025 (UTC)
•  Oppose seems to me to defeat the main purpose of cross-wiki uploads: that inexperienced users don't have to deal with two sites when developing content for one of our sister projects. "Confirmed on Commons" requires that they have actively edited Commons. Perhaps I could be convinced otherwise, but that is certainly how this strikes me. - Jmabel ! talk 15:01, 6 October 2025 (UTC)

Are "Sum of all paintings" project galleries welcome on wiki commons?

Continuing and summing up a debate started on the administrators' noticeboard:

The Sum of all paintings project contains around a thousand pages, which are wikidata-backed automated lists (edited by Listeriabot) acting as galleries for paintings either made by specific artists or belonging to a certain museum. As was explained to me recently by @Jameslwoodward, gallery pages belonging to the Sum of all paintings project do not conform to COM:Galleries since they do not use <gallery></gallery> tags and a simple caption, and would better be placed on WP. This would imply the deletion of all existing or at least all new pages created using the Sum of all paintings preferred format, the reason why all the non-conforming lists were not deleted before being that their existence and non-conforming structure hadn't been noticed.

My two main arguments for the modifying of the COM:Galleries guidelines in order to allow the preservation of the project on wiki commons are:

• Similar lists on WP are entirely user-made, the commons lists are based on wikidata entries, and are thus completely different (compare this to this, 90 vs around 360 entries). Even copypasting the commons lists to WP would require scrutiny of a thousand lists of different artists in tens of different languages, to check that every entry unique to each project has properly been added to the final WP list.
• The commons lists are in fact duplicates of similar lists found on wikidata (compare here to here). The commons lists are however, due to the structure of commons, much easier to find, as they are properly placed in each painter's Paintings category. By comparison the wikidata lists are only accessible through this category and nowhere else, which is impossible to reach if one is not aware of the existence of the Sum of all paintings project. I must stress that this ListeriaBot automated list is actually one of its kind on the entirety on the Internet: there's basically no other website that present such a detailed global catalogue of paintings, which is much better ordered than the Paintings category, and much more complete than the lists present on WP, as it is wikidata-backed. I think it is in the interest of the scope of the project to make this list as easy to find as possible, which will not be the case if it can be found only on wikidata.

Pinging all previous participants to the discussion : @Jameslwoodward, Yann, Edelseider, Jmabel, and Schlurcher: , pinging contributors to Sum of all paintings project :@Mateus2019, Niketto sr., and Tzim78: , as their work would be affected by the debate. Ostrea (talk) 10:00, 11 October 2025 (UTC)

 Support Yes, these galleries are obviously useful. Yann (talk) 10:02, 11 October 2025 (UTC)

 Support. Edelseider (talk) 10:03, 11 October 2025 (UTC)

 Support. We should be more flexible with galleries including supporting wikidata-based tables. --AFBorchert (talk) 10:21, 11 October 2025 (UTC)

 Support Don't see why wouldn't. Prototyperspective (talk) 12:00, 11 October 2025 (UTC)

 Support One of the examples of a good gallery page long present at COM:Galleries does not use the <gallery> tag at all: Pronunciation of Dutch municipality names. Perhaps we should explicitly add one of these as another such example so that there is no doubt in the future. - Jmabel ! talk 12:56, 11 October 2025 (UTC)

 Support per Yann --Mateus2019 (talk) 13:04, 11 October 2025 (UTC)

 Support Especially comments by AFBorchert and Yann including suggestion by Jmabel. -- Ooligan (talk) 20:05, 11 October 2025 (UTC)

I fail to see what needs to be changed.

How are those pages not acceptable under the current version of Commons:Galleries?

No text and no one say a gallery (or a photo album as a synonym) must be made using <gallery> tags. RoyZuo (talk) 21:20, 11 October 2025 (UTC)

https://www.oxfordlearnersdictionaries.com/definition/english/gallery "a collection of pictures". RoyZuo (talk) 21:21, 11 October 2025 (UTC)

As I said at AN, "I don't understand why Commons should host pages that belong on WP -- there are many pages very similar to these on WP, so why should these be here rather than there? We are a repository for images and other media. We explicitly reject anything that looks like encyclopedic content, so allowing these pages will require not only a change to COM:Galleries, but also to Commons:Project scope." .     Jim . . . (Jameslwoodward) (talk to me) 12:59, 11 October 2025 (UTC)

• support - agree this seems like a good use of gallery pages, and support modifying the guideline accordingly — Rhododendrites ^talk |  13:53, 11 October 2025 (UTC)

 Support per Yann, as also stated on the noticeboard --Schlurcher (talk) 15:41, 11 October 2025 (UTC)

•  Comment @Jameslwoodward, Yann, Edelseider, Jmabel, and Schlurcher: As you might know, I started SOAP in 2014 and I'm probably still one of the more active contributors (wonder why User:Ostrea didn't ping me). We have lists at d:Category:WikiProject sum of all paintings creators and some other places. Back in 2021 User:Mateus2019 started copying these pages to Commons ([6] [7]). Felt more like quantity over quality. I'm quite unhappy how it looks now, so I'm with Jim on this one: In the current form these are not galleries and have no place on Commons. So if we are going to do this, we should change them to galleries like I did on Paintings by Johannes Vermeer. Make good looking galleries or delete them. Multichill (talk) 18:39, 11 October 2025 (UTC)

  The reason's simple: your and your bots' contributions to the project have been of course immense, but I do not think you have ever, except the improvement you've recently created, contributed to a Commons Sum of all paintings page, and the history of these pages were my only way to find out who is involved at all in this slice of the Commons side of the project. It was either this or pinging the first 10 members in the SOAP participants list...

  I have to say the change you're suggesting does look superior to the rather detailed but dry lists we have now... if there's consensus on using it instead of the current format, perhaps a change of rules wouldn't even be needed at all to solve the situation Ostrea (talk) 22:33, 11 October 2025 (UTC)

  @Multichill: It looks good; does this format still provide a decent approach to having a bot maintain it, and does it provide a decent way of indicating pictures for which we do not have images? - Jmabel ! talk 02:33, 12 October 2025 (UTC)

  @Ostrea: it's a wiki project so I created Commons:WikiProject sum of all paintings and Category:WikiProject sum of all paintings a long time ago. We have to look at the category. Probably just have a (hidden) tracker category to keep an overview of automatically updating galleries.

  @Jmabel: I found Category talk:Paintings by Piet Mondrian (pl), bit of a weird place. Had to patch the template so that it now shows File:No-Image-Placeholder-landscape.svg if no image is available.

  Other people also in favor of changing these into real galleries instead of changing our policies? Multichill (talk) 12:32, 12 October 2025 (UTC)

  If we currently do not consider foto-focused lists like Paintings by Édouard Manet - Wikimedia Commons as Galleries, then I'm in favor of changing our policies. In my understand they are. If there is an option to improve their visuals in this case, even better, but this is a separate discussion. As I understand from AN this started as a scope and policy discussion and imho this should not have been the case. --Schlurcher (talk) 12:46, 12 October 2025 (UTC)

  @Schlurcher: These big table lists have no place on Commons in the gallery namespace in the current form. What's the point of having an exact copy of d:Wikidata:WikiProject sum of all paintings/Creator/Édouard Manet here?

  If we go back to the original proposal:  Oppose updating Commons:Galleries to accept these big table lists. Multichill (talk) 13:18, 12 October 2025 (UTC)

 Support They look like a form of gallery to me. I don't see we need a change of project scope at all -- these are not primarily encyclopedic text, nor really even primarily of text. They are simply a listing of images with a bit more factual information about them. If we need a change of wording to COM:Galleries to allow these, then do it. Wikipedia seems to disdain image galleries (en:WP:GALLERY) thinking they are more of a Commons thing. These can't move to WP since they would likely just be deleted under their policy, that they should be moved to Commons. I think these are firmly inside Common's scope. It's just another way to display the media we have -- the images are the focal point. However, if the data is already stored on Wikidata, using a method to query that data and generate galleries that way (as opposed to copying the data) is probably preferable. Carl Lindberg (talk) 22:04, 14 October 2025 (UTC)

•  Question Would this information be better suited to the Data namespace?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 19:44, 11 October 2025 (UTC)

  @Jeff G.: I don't think so, because (unless I'm missing something) it wouldn't provide thumbnails of the pictures at all. - Jmabel ! talk 02:31, 12 October 2025 (UTC)

  @Jeff G.: the data is actually on Wikidata and is retrieved using a SPARQL query. The gallery is just a nice visual representation of it. Multichill (talk) 12:42, 12 October 2025 (UTC)

 Neutral Personally, I think gallery pages as a whole shouldn’t be hosted here and that most of them should just be deleted. If we want a nice visual overview of "good images" for a topic, that should be handled through a proper gallery view or improved category browsing, not random wiki pages pretending to be galleries. Since that's not what this discussion is about, I'll just !vote Neutral. I don't find these Wikidata-based pages any worse than stuff like Farsta, which honestly just makes Commons look neglected. At least the Wikidata ones maintain themselves. --Jonatan Svensson Glad (talk) 23:08, 14 October 2025 (UTC)

The Apache License

The Apache license, like the GFDL license, requires that a copy of the license be included with any use of the licensed material. This makes the material unusable for print applications and difficult for most on-line applications. We have severely limited the use of the GFDL license, see Commons:Licensing#GNU_Free_Documentation_License. We should similarly restrict the use of the Apache license. .     Jim . . . (Jameslwoodward) (talk to me) 12:46, 14 October 2025 (UTC)

•  Support § 4a of the Apache legal text appears quite similar to § 4H of GFDL-1.3, used in {{GFDL-1.3}}. Due to a similar argument, there was an accepted proposal to phase out GFDL for new uploads with few exceptions, see Commons:Village pump/Proposals/Archive/2018/08#No longer allow GFDL for some new uploads. I do not see any reason why should treat {{Apache}} differently from {{GFDL-1.3}}. --AFBorchert (talk) 12:52, 14 October 2025 (UTC)
•  Support not accepting the Apache license for new uploads. Yann (talk) 14:31, 14 October 2025 (UTC)
•  Support Glrx (talk) 15:37, 14 October 2025 (UTC)

 Strong oppose This is making a fool of the project, we will be a laughing stock for all free software developers and it is an insult to all those who worked to support free open source software.

• This is one of the most famous and widely used free software licenses which we need.
• There are many situations where share alike or giving attribution at all is not practical, all the CC BY licenses require listing all the modifications you made which is not practical, we cannot just keep banning all the restrictions because they are not practical sometimes.
• For example France decided that rule of the shorter term does not apply for US works that expired due to no renewal [8], so {{PD-US-not renewed}}, {{PD-US-no notice}} etc may not be in the public domain at all outside the US and totally impractical to use, no one suggested to stop using these tags.
• GFDL is a documentation license, it was never practical for images, Apache is a software license, they are not the same at all. No one is putting photos under Apache, when developers release their software under a free license we need to be able to use it and no one uses CC licenses for software because they are not suitable, see the Open Source Initiative and the Free Software Foundation advise against it, even Creative Commons suggests using software licenses
• Many software licenses require you to include the full license text, which is not impractical at all for software applications, they did it so that if you print out the code or something you have to include the license.
• Finally on the website for the license, it suggests at the bottom for using one file under the license you do not need to include the full license text but just a shorter version with a link to the license.

 $999$REAL 💬 ⬆   16:34, 14 October 2025 (UTC)

The Apache license is OK for software, but Commons is not hosting software. So we could make an exception "only software could be uploaded under the Apache license." Yann (talk) 16:48, 14 October 2025 (UTC)

But we are hosting screenshots, icons, and logos of softwares. Perhaps limit it to only disallow photographic media? --Jonatan Svensson Glad (talk) 17:25, 14 October 2025 (UTC)

•  Oppose The last few paragraphs of this suggest an actual copy of the license is not needed but rather just a link, which we already comply with. --Bedivere (talk) 17:37, 14 October 2025 (UTC)

• OK. If a link is sufficient, there is no reason to disallow this license. Yann (talk) 17:48, 14 October 2025 (UTC)

• Sorry but a link is not sufficient. That section begins with the statement: Include a copy of the Apache License, typically in a file called LICENSE, in your work. In case of a software package, the license does not have to be included in every file using the Apache license. But you have to include the full license nonetheless within the package, just not to every included file. This does not help us as we work with individual media files only, not packages. --AFBorchert (talk) 18:04, 14 October 2025 (UTC)

  No, that is for when you want to release the full package under the license, which you do not have to do because Apache is not share alike, so you can use it in MIT, GPL or even closed source projects, etc, in which case you just need to indicate specifically which files are under Apache.  $999$REAL 💬 ⬆   18:24, 14 October 2025 (UTC)

• It is quite simple. If a software package includes any Apache-licensed file, a full license text must be included as well, usually as a separate file. --AFBorchert (talk) 19:37, 14 October 2025 (UTC)

 Support I think for original new content we should even only accept CC 4.0 licenses and CC0. We of course need to accept Apache license for software screenshots like we do with GFDL/GPL. GPSLeo (talk) 17:40, 14 October 2025 (UTC)

 Oppose We already kick ourselves in the ass with the strictest possible interpretation of copyright, what's the use of adding additional restrictions? Entire operating systems are Apache licensed, this is absurd. -Nard (Hablemonos)(Let's talk) 18:09, 14 October 2025 (UTC)

 Question Is anyone actually using the Apache license for unrelated purposes (i.e, that are not derivatives of works already under the Apache license)? I can't say I've seen any. Pi.1415926535 (talk) 18:44, 14 October 2025 (UTC)

These examples exist and are easily found. Some finds: File:IPv6 CARE Mechanism.PNG, File:Ocean.jpg, File:Winzer classic1.JPG, File:Winzer classic2.JPG, File:Bärlauchlino1.JPG. --AFBorchert (talk) 19:47, 14 October 2025 (UTC)

Sorry, I should have clarified - is anyone currently uploading unrelated files using this license? All the examples I could find were >7 years old. If no one is currently doing it, then it's probably a non-issue, but also it wouldn't affect any current users if we did prohibit it going forward for unrelated files. Pi.1415926535 (talk) 20:21, 14 October 2025 (UTC)

 Oppose This could prevent/restrict the uploading of files under Apache license. I am aware that reuse comes with some challenges, but I don't think we should introduce more restrictions that go far beyond what is required by law (in this case). If possible, the advantages of other licenses should be highlighted, but I am against a ban or restriction of Apache-licensed files --PantheraLeo1359531 😺 (talk) 19:53, 17 October 2025 (UTC)

• The largest, widely approved open source software licenses such as MIT, GPL, also include this restriction, there were already tens of thousands of projects using them 10 years ago, the Commons app uses Apache 2.0, it is making a mockery of the project to claim that these are not free licenses. Commons:Choosing_a_license#Common_license_conditions also states full license text reproduction is an acceptable restriction. The Free Art License requires it too.

The MIT license text is also much shorter, where are we supposed to draw the line for what is acceptable? I looked at the old proposal for GFDL and on just the first comment saw a point that no one addressed, it is impractical to use almost any attribution licensed image on something like a coin that is too small to write it on.

It may be reasonable to restrict usage of Apache for photos, but there is possibly a reason to use GPL for photos; it was ruled by a court that including a CC BY SA image in a book does not require you to release it under CC BY SA, that makes it much less useful for creating new free media, it just keeps your image free. On the other hand the GPL requires you to release the whole program under GPL even if it just including a GPL library, it creates new free software. I am not sure if it would work the same way for images but if it did it would be a reason to use it.  $999$REAL 💬 ⬆   20:55, 14 October 2025 (UTC)

• Hm. It is of course a free license, just like GFDL. It's an easier license to add, as it's not nearly as long as the GDFL. Inside something like an .svg it's not a problem at all. I think there were people actively using GFDL on photos on purpose entirely to make complying more difficult -- not sure we have that same issue with the Apache license. However, it should be heavily discouraged for new image uploads, and always has been I think. I did not think there was an absolute ban on GFDL -- if an image naturally has that license elsewhere, we should still allow it -- thought that was part of the original discussions. Similarly if there is an image in an Apache-licensed software project, we should allow uploading that image. It's just for self-taken images where the user is choosing a license, they should not choose Apache (or other software-oriented licenses). I'm not sure we need to go to the same lengths as the GFDL, but it is in a similar bucket I guess. I would make an explicit exception for images from Apache-licensed software products, and allow .svg files with the license in general (those are closer to code anyways). But, I'd also allow the same for GFDL. If people have translated the restrictions to a blanket ban on new uploads no matter what, then I'd oppose. If we still allow those types of uploads, and just ban say photographic images without any attachment to an Apache software project, I could see that. Carl Lindberg (talk) 21:51, 14 October 2025 (UTC)
• (Edit conflict) Nobody claims here that Apache isn't a free license. And if a file comes out of software package (like tons of Unicode emojis, for example from various open-source fonts), then we should, IMHO, accept such cases as well. But for regular photos (which is the bulk of our uploads) we should not support this option as this makes it unpractical for reusage. So the proposal, as I understand it, is to phase out this template for anything for which we have no good rationale (like screenshots, photos of smartphones with Apache-licensed icons, emojis etc). Similar restrictions have been introduced in regard to GFDL (see links above) without anyone claiming that GFDL is not a free license. --AFBorchert (talk) 21:59, 14 October 2025 (UTC)

@999real - with regard to GPL photos, please do not. The text of the GPL assumes that the licensed work is a piece of computer software; many of the terms of the license cannot be meaningfully interpreted with regards to photographic or other non-software works. Omphalographer (talk) 23:22, 14 October 2025 (UTC)

CropTool2

I've been using CropTool2 (see Commons talk:CropTool#CropTool2) and it seems to be equal to or better than the existing CropTool in all respects. I think it should become the main line offered in Preferences, superseding the existing CropTool. - Jmabel ! talk 13:54, 15 October 2025 (UTC)

• Agreed. No reason not to upgrade. --P 1 9 9  ✉ 14:13, 15 October 2025 (UTC)

Update file description page table

I propose giving the file description page table a much needed fresher look! See the example below of File:Official CSS Logo.svg. See the sandbox at Template:Information/sandbox and styles Template:Information/sandbox/styles.css.

Demo [Click to open]

Example taken from File:Official CSS Logo.svg at Template:Information/sandbox/testcases.

DescriptionOfficial CSS Logo.svg	English: The primary rebeccapurple logo of the CSS specification.
Date	12 November 2024
Source	https://github.com/CSS-Next/logo.css/blob/main/css.svg
Author	Javi Aguilar and The CSS-Next Community Group
Repository InfoField	https://github.com/CSS-Next/logo.css/
Nominal resolutions InfoField	Primary (1000px x 1000px) and small (32px x 32px)
File types InfoField	.avif, .ico, .png, .svg, .webp
Permission ( Commons:Reusing content outside Wikimedia">Reusing this file)

Waddie96 (talk) 22:32, 19 October 2025 (UTC)

We already have {{Information field}} when parameters beyond the usual set are needed. The vast majority of files do not need additional fields (and quite frankly, neither does this file). Pi.1415926535 (talk) 02:01, 20 October 2025 (UTC)

@Pi.1415926535 Hi it's got nothing to do with additional parameters, it's got to do with styling it and refreshing it's look a much needed fresher look. Read again 😄 Waddie96 (talk) 03:41, 20 October 2025 (UTC)

Proposal: Add AI-powered visual search for Wikimedia Commons

Hello everyone,

I would like to propose adding an (AI-powered visual search) feature to Wikimedia Commons. Currently, Commons search only works through text-based queries (titles, categories, or structured data). However, many users may have an image but not the exact keywords to describe it.

This new feature would allow users to upload or paste an image, and the system would use AI-based image recognition (such as similarity search or image embeddings) to find visually related files within Commons.

Benefits:

• Improves discoverability of media content.
• Helps editors find similar or duplicate files.
• Useful for GLAM, educational, and research purposes.
• Enhances structured data tagging and metadata accuracy.

A Phabricator task has been created for technical discussion and tracking: 👉 T408018 – Add AI-powered visual search for Wikimedia Commons images

Community feedback is welcome — please share your thoughts and suggestions below. If there’s consensus, the idea can be supported more strongly on Phabricator to attract developer attention.

Thank you! —GoldenJDM (talk) 19:53, 22 October 2025 (UTC)

AI tends to be very computationally expensive. Why would there be any advantage to doing this specifically within Commons to using existing free external tools? - Jmabel ! talk 03:03, 23 October 2025 (UTC)

I don't see the benefit for such software. The lead in AI-based searching that Google and OpenAI already have is most likely uncatchable, there's a gadget in your preferences that you can activate for image-based searches, or what should be the en:killer feature for such a search function here? Regards, Grand-Duc (talk) 03:12, 23 October 2025 (UTC)

I don't think this is needed much or would have a big impact or usefulness. Additionally, it doesn't seem readily possible now or in the near future but would take a lot of resources and effort to implement. Furthermore, there already is Google Images reverse search and Tineye as well as Commons category and Commons search, making this is more or less redundant. There also is a wish in the Community Wishlist about what you're describing: W212: Search Wikipedia with image or sketch search.

More useful would be a way to describe what one is looking for to some AI assistant which then tells you categories and/or a few files that match your description. This is one potential application of the many applications of wish W442: Adopt Wikipedia-trained WikiChat LLM & make it learn about help pages & categories to help newcomers also in the Community Wishlist. When it comes to duplicate files, there already is a check for similar files in the UploadWizard for example and it's not a plausible way what you're suggesting could be used efficiently.

To put things short, I don't think your idea is worth the effort but thanks for thinking about how Commons could be made better via technical development. Prototyperspective (talk) 15:15, 23 October 2025 (UTC)

The last time we tried this it was a huge loss of money, developer and volunteer time: See Commons:Structured data/Computer-aided tagging. GPSLeo (talk) 15:35, 23 October 2025 (UTC)

That this implementation was seriously flawed / low-quality doesn't mean the concept can't work well. However, this is about something entirely different than what's proposed here. Prototyperspective (talk) 15:47, 23 October 2025 (UTC)

In principle, some sort of image similarity or content recognition search would be great to have. But the ultimate deciding factor is going to be technological feasibility - the set of images on Commons is exceptionally large (currently 129M), and a lot of the typical tools for this sort of task will be unsuitable at that scale. (CLIP is probably not what you want; it's geared towards identifying broad classes of objects like "this image may contain a person", which are too broad to be useful on Commons.)

@GoldenJDM - this is probably a better fit for the meta:Community Wishlist than Phab, as it's not immediately actionable and requires planning. Omphalographer (talk) 01:26, 25 October 2025 (UTC)

Stricter blocking policy for copyright violations

We still have a huge problem with blatant copyright violations where people upload some photo they found on the internet as their own work. Currently these users are warned multiple times and get blocked for two weeks. After the block they continue with uploading copyright violations. I think we should be more strict and only give one warning. If there are blatant copyright violations after the first warning they should be partially blocked infinitely from uploading files. They should be able to appeal immediately if they explain that they now understand the rules. This process is only valid for blatant copyright violations like wrong own work claims, "source: internet" or source links to obviously non free content. This should not apply to content where the uploaded assumed it would be public domain (also if it is not) or derivative work and FOP problems. GPSLeo (talk) 12:36, 26 October 2025 (UTC)

simply  Strong oppose. modern_primat ^{ඞඞඞ ----TALK} 19:43, 26 October 2025 (UTC)

then put more admins here to cope with workship. modern_primat ^{ඞඞඞ ----TALK} 19:44, 26 October 2025 (UTC)

+ if people get banned then sock puppetery will thrive. current system of blocking for copyvio is good. modern_primat ^{ඞඞඞ ----TALK} 17:45, 27 October 2025 (UTC)

I think the people who upload copyright violations in that way are not the same people who create sockpuppets to continue with their project disruption. The users who are to be blocked from uploading with this rule do not know what Wikimedia is. GPSLeo (talk) 19:16, 27 October 2025 (UTC)

we'll see. hayırlısı olsun. modern_primat ^{ඞඞඞ ----TALK} 05:43, 28 October 2025 (UTC)

•  Strong support, thanks to GPSLeo for pointing this out.--Kadı Message 23:22, 26 October 2025 (UTC)

 Support, having reported overlooked mass copyvios in the past where the uploader turns out to have a talk page of warnings and earlier short blocks that they've waited out, not noticed, or not understood.

The time likely needed for the user to familiarize themselves with relevant policies and adjust their behaviour of an initial week-long block makes sense in nuanced situations where a user might be applying a policy wrongly or interacting inappropriately, while being an otherwise productive Commons user, but it doesn't seem applicable to someone who is claiming "own work" or "public domain" on clearly copyrighted content, and making no constructive contributions. Belbury (talk) 10:09, 27 October 2025 (UTC)

 Support - in my opinion, copyright violations are, at large, one of the most prominent dangers (if not outright number 1) to the integrity of the project. Strong signals like blocks (and knowing + applying en:WP:UBCHEAP for people appealing them) are sensible tools to deal with such uploads. Regards, Grand-Duc (talk) 21:15, 27 October 2025 (UTC)

COM:PHOTOCONSENT and VRT

When releasing the rights of photographs via VRT (COM:CONSENT) I believe there should be a way for photographers to confirm they have consent from people depicted in the photography as well (COM:PHOTOCONSENT). Then VRT members should be able to place {{Consent}} on the picture itself and there should also be {{consent|pending}} (which would be used by uploaders, in a similar way to {{Permission pending}}). It's moon (talk) 06:25, 28 October 2025 (UTC)