This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.
Germany protected area naming convention and category structure
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)
@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 ! talk01: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. –Davey2010Talk18: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)
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.)
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.’
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. — Rhododendritestalk | 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.
Person is identifiable and the event is public and there is a public interest on having this photo published. (nothing required)
Person is identifiable but the situation was not public and there is no public interest. (permission required)
The person is not identifiable. (nothing required)
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)
@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)
@GPSLeoI 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’:
Person is identifiable and there is a public interest. (consent not required)
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)
@GPSLeoBut 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)
@GPSLeo Yes, I know there a lot of other countries that require consent, even in public. I mentioned Germany because you are from there.
I use the term ‘public interest’ to mean ‘this is important to society, and that means we are allowed to publish it even though we are normally not allowed to publish it’. That is a strict criterion. All of the files covered by the deletion requests linked above fail that criterion. Brianjd (talk) 12:00, 21 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)
@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)
I really get the impression Brianjb is overthinking all this. A law or rule that applies to a photograph applies to a sequence of photographs (a video). It doesn't apply to all "media" since that includes sound and text (we have scanned documents here). The "identifiable" is important. It is the first thing a stock photo website will test, whether the people in the image are at all identifiable. If they are, such a stock photo agency will insist on a model release (unless they want to hold news/documentary images with the limited appeal those have). If we just have a rear photo of people sitting on a bench and you can just see some hair or hats, there's no issue.
Wrt File:Yasield à Wikiconvention Francophone 2022 06.jpg there seems to be a gross misunderstanding of what is a private place, which is a place where you have an expectation of privacy. It does not mean a place where only some people are permitted to attend (attendants at a conference). I don't see the need to delete that image, nor is bluring the faces any help. All you've done is make an image that now has zero possible use. I am beginning to wonder, Brianjd, if you are trying to run before you can walk. It is not a good idea to propose or attempt to rewrite guidelines if you aren't understanding the basics.
The "topless barcelona" image was from a prior age, and the issues then were different and largely to do with a few users behavioural problems. I'm not seeing any good evidence that the guideline is misunderstood or needs renamed or fixed. I do so see someone wanting an algorithmic solution to a very complex problem, and that's not going to happen. All our guideline give general principals and editors may well have good reasons to deviate. An approach where people quote guideline sentences like they are gospel and then wikilawyer over the words is not good.
Some of the examples given were deleted for other reasons (copyvio). The Commons:Photographs of identifiable people guideline specifically warns editors to not think that blurring is a solution. Essentially, if you can see a blurred person in the photo, and your educational purpose is not to illustrate blurred people, then you've created a piece of shit. Let's not do that. There may be some use for it in journalistic media, but likely extremely limited. -- Colin (talk) 19:11, 22 January 2023 (UTC)
@Colin Currently, I am merely copyediting the guidelines. While doing so, I am discovering a lot of other issues that I cannot fix alone and starting discussions about them. I am not rushing in to rewrite something that I’m not qualified for, as you seem to be suggesting.
I should note, that since posting the above, I've learned about this "red lanyard" thing for WMF events. That changes things and should be documented.
Brianjd, I think you are going at this way tooo fast. If it seems I'm "picking on you" it is because you are proposing things left right and centre. -- Colin (talk) 15:28, 23 January 2023 (UTC)
The need to improve understanding of licensing for new uploaders
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)
One of those proposals seems to encapsulate a change to policy: "We can delete your own work at some unspecified times in the future, if it was ever published online anywhere else." That's quite a major change to policy, especially in an era of ubiquitous uploading.
In the past, that has not been policy. It has been used as if it were, usually in a pejorative and sometimes a deliberately harassing manner, but there has been scope for some pushback on the grounds of AGF and requiring some reasonable proof that it was not the "own work" as claimed. Our basis has been, "Claims of own work will be accepted as given, per AGF, unless there are some significant grounds for suspicion otherwise."
Reformulating that though as "Recognised own work can be deleted if there is other online publishing of it, unless VRT was used." would be a significant change. Andy Dingley (talk) 18:06, 21 January 2023 (UTC)
@Andy Dingley: I assume you are talking about the second link provided by King of Hearts. We do need to have a discussion about our policy towards works previously published elsewhere.
We also need to redesign the Upload Wizard (it is good that both linked discussions talk about this). Specifically, we need to get the rid of the defaults. No default ‘own work’; no default ‘CC BY-SA 4.0’. Uploaders need to explicitly select these things, after being presented with information about the implications. This is clearly justified by the steady stream of deletion requests for files with implausible ‘own work’ / CC BY-SA 4.0 claims. Brianjd (talk) 03:19, 22 January 2023 (UTC)
"our policy towards works previously published elsewhere"
We've needed a discussion about this for a long time. See the regular DRs on that basis, mostly affecting uploaders who haven't been active for years, hence default deletions, whatever the real merits of the case.
There are three or four interpretations of this policy: the policy, the version stated at upload time, the version in the minds of GF uploaders acting on the basis of that information, and then the version used to justify their later deletion. When these are out of sync (as they are), there's a problem. A question is outstanding on whether it's the uploaders or the deletionists who are out of step with policy, but whichever it is, there's a need to better communicate the actual situation to uploaders at the time. We should not be encouraging uploads, just to sandbag them in the future. Andy Dingley (talk) 11:18, 22 January 2023 (UTC)
I'm not opposed to having a discussion on how COM:AGF and COM:PRP should interact. However, the de facto policy is already that previously published work requires COM:VRT (with a few exceptions), so we should not mislead uploaders into thinking it doesn't, currently. -- King of ♥ ♦ ♣ ♠04:10, 22 January 2023 (UTC)
@Andy Dingley We should be able to do better at every aspect of our communication, but this is the proposals village pump and I don’t see an actual proposal here. It would help if we had some straightforward screenshots of the Upload Wizard (no funny arrows and textboxes, no funny languages or part of the screen cut off) to refer to. Can someone take those screenshots next time they upload a file? Brianjd (talk) 15:06, 21 January 2023 (UTC)
When copyvio is incidental and easy to fix, place a burden on deleters to do so
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.
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 ! talk18:54, 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)
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, –Davey2010Talk22: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 ! talk01: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)
Oppose the original withdrawn proposal. The "figure out a way" isn't actually a proposal so I assume that's to be ignored. King, is your INUSE proposal an exception to F1 only or an exception to all CSD claims? An F1 exemption may make some sense or at least require a discussion could be helpful but I need to do more thinking. I disagree with Davey's proposal as I expect we will just end up with an indefinite holding cell with lots of copyrighted / questionably copyrighted images forever. Category:Items with disputed copyright information has over 4600 images and I imagine INUSE ones will grow indefinitely just as well. I don't know if one continued discussion here is helpful or separate subsections would be better since the original proposal in this discussion has been withdrawn and it's no longer clear what people support or oppose. -- Ricky81682 (talk) 00:44, 25 January 2023 (UTC)
@Ricky81682: Primarily F1/F3, but the general spirit of my proposal is: "If an in-use image otherwise meets CSD but can edited so that it 1) no longer meets CSD and 2) continues to be useful in context, then it is ineligible for CSD." I could imagine this applying to F10 as well, e.g. a selfie of a non-notable person taken with a notable person. (On second thought, I think "in use" can be expanded a bit; we can also include categories which have relatively few images. The point of this qualification is just to ensure we don't waste time trying to save images not worth saving because we have lots of similar images; "in use" is another way of saying "best in class", but "rare" should count as well.) -- King of ♥ ♦ ♣ ♠01:13, 25 January 2023 (UTC)
I think making it a part of multiple CSD criteria is a bad plan. F3 could be revised to cut the "it is best for such issues to be resolved in a formal deletion request" splitting the baby language and just require a DR for FoP, and de mininis cases (which these are in a way). I don't think F1 needs to be messed with except maybe "The entire content ..." at the start to make sure no one tries to shoehorn the F3 exceptions into F1 (which would still require an admin that goes along with it). The INUSE issue may be irrelevant if we adjust the procedures for these cases. Otherwise most admins I think would take a INUSE example to a DR rather than speedy it and just open themselves to the drama that would occur from that (exception being the INUSE spam walled gardens). Ricky81682 (talk) 01:53, 25 January 2023 (UTC)
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!
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)
@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)
The fact that there are so many images doesn't mean it's a problem for DR. The category doesn't even say what needs to be done there. Do you have examples of DRs where it's a SNOW keep which would show that it's enough of a problem so that a CSD is helpful? I don't see any of those listed for deletion so examples would help. You may be jumping the gun here with a CSD. Ricky81682 (talk) 02:01, 25 January 2023 (UTC)
Imo, there's not much reason to keep these around, but there's also not much reason to get rid of them fast - or at all. They don't break copyright law, they're not vandalism or abuse, and they don't embarrass or offend anyone (other than our collective OCD). "Deleting" them will not even free up storage space, as they're just being hidden from public view. Just tuck them away somewhere where they don't clog up otherwise useful categories and move on to more important matters ... El Grafo (talk) 09:13, 25 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 wording
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-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.
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)
+1. Unpopular opinion: The same applies to raster graphics or photos used as templates for SVG variants. In my humble opinion, it is very bad practice, not to say gross mischief, to delete these after the SVG has been created. --Smial (talk) 11:19, 25 January 2023 (UTC)
Create a Commonswiki Community Tech Wishlist
The "Commonswiki Community Tech Wishlist" would be a localised version of the Community Wishlist Survey.
Introduction.
I would like to propose the creation of a localised version of the Community Wishlist Survey. This survey will function largely the same as the ones that currently exist at the Meta-Wiki and German-language Wikipedia.
I also prefer not to go into too much detail, namely if it should be annual or bi-annual, if the accepted proposals should number only a few or many. Whatever the outcome of that will likely be based on the available resources.
Benefits.
As the Wikimedia Commons is vastly different from other Wikimedia websites the technical needs of this website are also vastly different, something that positively affects the Wiktionary can also be used to help Wikipedia and Wikisource, but as this website primarily deals with multimedia its needs require more specialised proposals to deal with them.
Because of the much larger communities at various language Wikipedia's proposals dealing exclusively with issues faced by contributors and re-users of the Wikimedia Commons will likely not get upvoted much in a global survey, meanwhile these would receive proper discussion in a localised wishlist.
Support Commons has needs that other Wikimedia projects don't have and WMF should update or at least maintain tools like Flickr2Commons if they are willing. Abzeronow (talk) 18:46, 25 January 2023 (UTC)
Discussion (Commonswiki Community Tech Wishlist)
Obviously this wouldn't be for this year or maybe even next year, this proposal mostly exists to show both the Wikimedia Foundation (WMF) and Wikimedia Germany (WMDE) that the Wikimedia Commons needs specialised technical support that it simply isn't getting from the global community. At the Meta-Wiki survey the Commonswiki is only one (1) category like this but here we could have multiple copies for multiple specialisations like categorisation, uploading, deletion, undeletion, importing, simple maintenance (basically asking for unmaintained tools to be adopted by the WMF and / or WMDE if they're willing, for example the countless of issues with Flickr2Commons and Video2Commons), Etc. The proposal has to be this general because all the specifics would have to be negotiated with the Wikimedia Foundation (WMF) and / or Wikimedia Germany (WMDE) what is possible based on their resources. But if nobody here says "hey look, this project really needs some help from software developers" then our issues won't get fixed. We often run into technical problems here only to find out that the Commonswiki only receives the bare minimum to support it. Old features are rarely maintained, new features are rarely implemented, and some issues have been talked about for years without anyone addressing them. There currently doesn't seem to be a general software feedback nor feature suggestions portal at the Wikimedia Commons, meanwhile technical proposals that have been approved by the community get archived and nothing happens because nobody with the technical skills to make them happen is implementing them. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:49, 24 January 2023 (UTC)
The Community Tech Wishlist has dedicated staff and funding behind it. Are you proposing requesting a grant to fund a separate wishlist for Commons? Or would this wishlist just be a list of things Commons needs, which volunteer developers may wish to address? — Rhododendritestalk | 14:17, 25 January 2023 (UTC)
@Rhododendrites: , if possible I would like to request the WMF and / or WMDE to dedicate some resources towards this project as many tools are either unmaintained or have bugs caused by changes in the MediaWiki software itself. I think that volunteer developers should also be used but I have no idea how and where to request them to aid with these things, from what I've seen volunteer developers can also help with items on the existing community tech wishlists on other Wikimedia websites. Even if neither the WMF nor the WMDE would dedicate their resources to this it would still be a good roadmap for volunteer developers to show which technical matters are most pressing. For example I've seen multiple complaints in the Village pump regarding Flickr2Commons not detecting duplicates in some cases but then very little is done to improve the software, but if the software here can detect it why can't we just add the same technology to Flickr2Commons? My guess is that the people with the technical know-how simply don't know about this issue at all or may not know how pressing it is due to not enough people reporting on it. Currently there's no feature request hub at the Wikimedia Commons and even if someone would propose a feature here it's unlikely to actually get picked up by the people with the technical skills to do so, perhaps due to them not being aware of it. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:18, 26 January 2023 (UTC)
YES, please create a community-backed system for defining technical improvements that the community needs and request resources for implementing these. -- Zache (talk) 17:07, 27 January 2023 (UTC)
"I appreciate it's not on Commons itself but then neither is EN things as far as I know." The main issue is that the number of active editors on other Wikimedia websites far outnumber Commonswiki contributors, Active users of the Wikimedia Commons (Users who have performed an action in the last 30 days) currently number 37,254, compare this with the 125,895 of the English-language Wikipedia, meanwhile the the German-language Wikipedia only has 19.240 active users yet has its own community tech wishlist, this doesn't prevent users from voting and proposing in both. The Meta-Wiki's wishlist doesn't have to change either, as multimedia still affects other Wikimedia websites, but it doesn't affect them in the same way as here as they don't import or work with the same tools as we do. The main difference is that tools that work on Wikipedia often work on other written content-based projects, what affects the English-language Wikipedia also affects the Arabic-language Wikipedia, Croatian-language Wikipedia, Persian-language Wikipedia, Urdu-language Wikipedia, Etc. Meanwhile the Wikimedia Commons is the second (2nd) largest Wikimedia website by active users (behind the English-language Wikipedia and ahead of Wikidata with 24,415 active users), despite this almost all Foundation resources go to Wikipedia's and Wikidata and this is because the unique needs of this website aren't properly addressed through the current method. Just look at the recent open letter to the Wikimedia Foundation (WMF) entitled "Think big - open letter about Wikimedia Commons", most of the points listed in this letter are technical in nature and after almost a decade of there being a community tech wishlist at the Meta-Wiki these still aren't properly addressed yet. Another advantage is that less pressure on Commonswiki technical issues will allow the issues of smaller projects to have more chances to succeed at the Meta-Wiki list as well. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:35, 26 January 2023 (UTC)
Addendum to my comment immediately above, the 2020 wishlist also specifically excluded the Wikimedia Commons from its scope, and the entire top 10 (ten) of the 2022 survey only includes a single item from the "Multimedia and Commons" category and this entry even reads "Problem: SVG images are currently rendered as scalar images before being displayed in Wikipedia articles, because at the time SVG support was added, many browsers could not reliably display SVGs." (emphasis added), so the only "winning" proposal in this category primarily affects Wikipedia users. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:42, 26 January 2023 (UTC)
What about making a coordinated effort to use the community wishlist, and then use anything that doesn't get selected as a list of things we need. WMF has said they're going to be investing in Commons (see Commons talk:Think big - open letter about Wikimedia Commons, for example), and that could act as a roadmap without trying to start a separate wishlist project. Roadmap is fine, but starting a separate effort seems a bit much IMO. — Rhododendritestalk | 13:01, 26 January 2023 (UTC)
Thank you for your in-depth and helpful reply Donald, When you put it like that it does seem that Commons is being left behind, I want to support but do we really have enough people to make it work ?, Not that it's relevant but COM:POTY has been suffering as of late (there was a discussion on this somewhere) - If POTY is suffering what chance does this have ?, –Davey2010Talk15:29, 26 January 2023 (UTC)
"Roadmap is fine, but starting a separate effort seems a bit much IMO." Well, the current proposal is a bit vague, I don't think that they're mutually exclusive so honestly I think that a Commonswiki Community Wishlist might work different from the Meta-Wiki and German-language Wikipedia versions, replying to both comments, I think that a good way to implement it would be to have an indefinite technical feedback / suggestion infrastructure modeled on the Meta-Wiki and German-language Wikipedia community tech surveys where rather than having a fixed period of time where users can first suggest and then vote for new features this one would be more dynamic. I'll write the implementation below. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:15, 26 January 2023 (UTC)
Going on what I wrote directly above this comment I thought that a good way to implement the hypothetical Commonswiki Community Wishlist would be by being both dynamic (users could suggest new features and proposals at any time) and indefinite. This version would have a "Top 10 (ten) most requested features" and an option to see all (open) suggestions based on popularity and a separate top 10 (ten) based on category. This would also shown volunteer developers which features are the most requested by the community and which bugs require the most immediate response (think the Flickr2Commons tool not properly detecting duplicates for example).
This would actually be a dynamic community-driven request list, we could ask the Wikimedia Foundation (WMF) and Wikimedia Germany (WMDE) to help us but this would not be expected, if neither the WMF nor the WMDE would want to invest their resources into these suggestions it would still be a list that volunteer developers could work on.
This would then be an easy community feedback mechanism where all users, be they novice or experienced, could suggest and discuss technical ideas to improve the software and make the Wikimedia Commons easier to use.
There would also be archives, implemented proposals would have their own archive (based on category) and withdrawn (including duplicate) proposals would also have a separate archive (also, per category) similar to how administrator requests are archived here today.
The individual suggestion pages ("proposals") would also be a place where volunteer developers could discuss them with the wider community bridging the gap between the contributors and the developers. This would make it separate enough from the WMD-funded and WMDE-funded wishlist surveys to be its own thing. If a proposal here has like 80 (eighty) votes and hasn't been worked on in a year then it would make sense that someone could suggest it at the Meta-Wiki for the WMF to take it over if no volunteer does it here, this could make this list a launch platform for future proposals that could be implemented by paid developers if no volunteers pick it up, but rather than being an annual or bi-annual closes survey this dynamic survey would be able to evolve with the project and remain open for engagement and discussion at any point of the year. I hope that I've worded what I'm trying to suggest clear enough. If this seems too different from the above proposal I can withdraw it and then make a clearer proposal based on the revised implementation above.
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.
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 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)
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)
Support Without Arbcom, all new Checkusers and/or Oversighters have to be granted by stewards, which may be a lot of unfair spending of times, with Arbcom, we can grant em by ourselves. --Liuxinyu970226 (talk) 07:05, 22 January 2023 (UTC)
No, I don't think this will change will an ArbCom. Checkusers and Oversighters are elected by the community, but the bit is given by stewards. Yann (talk) 10:51, 22 January 2023 (UTC)
Oppose not completely, but in general, One of the worst things about ArbCom on enwiki is that it has never actually worked when it comes to dealing with admin abuse; editors yes; admins, no... as I have noticed for years that if you are an admin on enwiki, you do not fear the arbcom cause in most cases they will protect 'their own', even former admins...sad reality...so trying to make this project on par with enwiki is a bad idea..again as i said, in general, this project needs an arbcom level uhm "entity" but unlike enwiki, it should not be made up of admins and CU's only, thats is where this idea falls flat on its ass... if you are going to have 10 members, 5 of them have to be non-admins and picked from the community or else we end up with a pack of cockatoos running the zoo, atleast two users with CU access and 3 experienced admins, or else we end up like the US supreme court where one party has intentionally packed it with their own people allowing them majority and ability to change or enforce laws (which we already saw a negative outcome for in case of Roe-v-wade)...also i have to kinda agree with RZuo in terms of picking rational people to run this, we have a limited number of those uhm in this asylum as most have either left or have been bullied out..not sure where we would even go about selecting the right ppl for this cause after a recent issue of admin abuse on this wiki (one of which was very diabolical), i'm not sure i can trust new admins on this project..my only reason to support an arbcom was a recent block by admin of a crat on another wiki here for 6 months, this IMO was admin abuse and that admin refused to budge on this block or talk about it so yeah we need something to control abuse by admins on this project but at this stage arbcom (the way illustrated above) isn't the answer.. it will just create more issues..--Stemoc02:49, 25 January 2023 (UTC)
You are going to have a hard time finding people who are experienced enough here and interested enough to join ArbCom but aren't admins here. Ricky81682 (talk) 06:44, 25 January 2023 (UTC)
very much the point, 10 years ago, we could have but it will be harder now which may mean limited candidates if this does go through, also 10 years ago, INC could have fielded all 10 candidates on his own :P ...thus my point of corruption here being so high that we no longer have the right people to run this project.... Stemoc07:20, 25 January 2023 (UTC)
I also don't think an Arbcom full of failed admin candidates is ideal. Either way, I assumed the criteria for Arbcom was going to be people from the community. If so, we will likely end up with admins because they are supported by the community. Ricky81682 (talk) 08:02, 25 January 2023 (UTC)
thats the reason why arbcom is a huge fail on enwiki, all admins protecting admins, lets not do the same here and expect a different result, lets try something different, its odd we call it an arbitration "committee" and yet its basically an admin only committee, last i checked 95% of editors on enwiki are not admins and yet are not represented..rather have a few failed admins candidates selected for a committee that fully understands the plight of regular contributors than a bunch of egotist narcissists thinking they hold the power to decide the fate of people who actually "contribute" to the project ..a balance would be good..... the reason why i want non-admins is when INC was on his egotist run back then creating havoc and i was seeking help from admins here to do something about it, they refused, even when it got confirmed then he ran another admin account, and yet admins here would no ban him....I even went to meta which was my homewiki then and even pointed out how pathetic admins on commons were cause just like enwiki, they were protecting their own and refused to do anything about it and then global ban failed cause they decided it was a local problem and our local admins here were useless, if our useless admins and CU's had done their job correctly then and CU'ed him and found out his socks and blocked them, i would have trusted them more but nothing changed, INC was eventually Global banned a month later but if was due to something he did on another wiki cause admins on our wiki are and have been unfortunately pathetic when it comes to doing the right thing..this is why we should try something different .. why give people who want more power to get more power?.... Stemoc01:42, 26 January 2023 (UTC)
Presumably many users here are familiar with the internal operation of enwiki (and specifically their ArbCom, but some users (like me) are not. Multiple users above have posted comments that look like rants, which just makes things worse; it would be more useful to post evidence instead. Brianjd (talk) 04:32, 26 January 2023 (UTC)
Looks like it was donated to Category:History Colorado. Anyone have any experience or want to start a connection with the museum? I imagine that would be a lot better than just grabbing the images and trying to guess when or what he was photographing. Ricky81682 (talk) 21:58, 4 February 2023 (UTC)
Proposal: Improve Toolhub coverage of Commons tools by improving on-wiki tool documentation
Toolhub is a community managed catalog of software tools used in the Wikimedia movement. Technical volunteers can use Toolhub to document the tools they create or maintain. All Wikimedians can use Toolhub to search for tools to help with their workflows and to create lists of useful tools to share with others. You can read more about Toolhub in general on meta.
The Technical Engagement team is interested in talking with active contributors to Wikimedia Commons about finding more ways for the Commons community to use Toolhub. We are interested in having more tools that are helpful for workflows on Commons listed in Toolhub and for those tools to be more discoverable to folks who are contributing to Commons.
We think that updating Commons: Tools is one way to start on this problem. We are proposing a small project to build new templates and use them to make the list of tools readable by a bot.
At a first glance, that looks reasonable to me - but I'm sure we will find things to complain about as soon as you actually start doing things ;-) El Grafo (talk) 14:15, 7 March 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)
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)
,.png&action=edit&redlink=1){kind=link}
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)
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)