Commons:Village pump/Proposals/Archive/2023/08

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Some bot should take care of Categories for discussion logs

Currently there is no user that creates the Commons:Categories for discussion/XXXX/XX nor the Commons:Categories for discussion/Archive/XXXX/XX pages. The former are literally created by the first user who happens to start a Cfd that month, and the former are literally created by SteinsplitterBot when it archives the first closed Cfd that month. Compare that to the Commons:Deletion requests/XXXX/XX/XX pages which are created by SteinsplitterBot months beforehand. For example Commons:Deletion requests/2023/08/17 was created by the bot on July 1.

Now I also see that SteinsplitterBot hasn't archived any Cfd's since March so we probably need a bot taking care of the archiving as well, or if Steinsplitter can take upon himself to do all this. Jonteemil (talk) 00:29, 17 August 2023 (UTC)

The problem with the log pages being created by the gadget instead of intended creation is that the log templates don't get added unless somebody like myself add them manually.Jonteemil (talk) 00:31, 17 August 2023 (UTC)

New WikiProject Performing Arts/Switzerland

Hello,

We have begin a new meta-project called "Swiss Performing Arts Projects" and we will be glad to open also a WikiProject Page on this topic in Commons.

It's allright for you?

Have you any advices for us? Titel? Hierarchy? Good exemple?

Thanks in advance! SAPA bdc (talk) 08:12, 18 August 2023 (UTC)

  • @SAPA bdc: We don't really have a lot of WikiProjects on Commons. What would be gained by having one specifically on Commons as against just referring people to the one on Meta? (That's not a rejection of the idea, or a merely rhetorical question, it's a straight-out question.) - Jmabel ! talk 20:12, 18 August 2023 (UTC)

Amendment of 'scope' to allow for Document archival.

Courtesy notification of Commons_talk:Project_scope#Proposed_change_in_wording. ShakespeareFan00 (talk) 08:48, 18 August 2023 (UTC)

Allow old orphan works

CLOSED:

Accepted. No real opposition, and stalled for nearly 2 months. Yann (talk) 10:27, 22 August 2023 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Hi, I propose that we allow old orphan works without a proof of publication, we should consider that the works were published at the time of creation. This should concern works in the public domain in the country of origin and in USA (i.e. free of URAA). We often delete old orphan works because no proof of publication was made, or because there is no evidence for the author's death, but such a proof is very difficult. This proposal comes out of a current request on COM:UDR.

Categories of works

  • Works created before 1928 (for 2023) without proof of publication.
  • Works created more than the pma duration in the country of origin, which would satisfy {{PD-1996}} if published at the time of creation (e.g. works created before 1946 for 50 years pma countries).

Discussion

  •  Support We should not require over complex requirements for works most probably in the public domain. Yann (talk) 14:05, 13 June 2023 (UTC)
  •  Question What is an "orphan work" as far as this proposal is concerned? --Rosenzweig τ 15:59, 13 June 2023 (UTC)
  •  Weak support for now but we should clearly define what would qualify as an orphan work because as it is we have uploads that tell us that they're anonymous or unknown when sometimes the bare amount of research or actually looking at the photograph sometimes gives us a named author. Abzeronow (talk) 16:31, 13 June 2023 (UTC)
  • I'm generally in favor of assuming publication unless there is some specific indication they may not have been published right away (negatives from a photographer's estate, or company archive, or that kind of thing can be such exceptions). But I don't think that should trump anonymous considerations, or {{PD-old-assumed}}. For photographic terms based on a lifetime, assuming the photographer died the year of publication isn't a great idea, I don't think (the 1946 line for 50 pma countries you gave). For one example, the UK repealed their law's allowance for orphan works -- there is a licensing scheme now, and that is all. The EU has an Orphan Works Directive, but the requirements are stiff, and I don't think the result can be considered "free" even after those are met. So for me, I dislike the deletions of normal works solely based on no proof of date of publication (particularly if just a URAA situation) -- but the rest, not sure I'd make changes. If there is a known author name, either wait for PD-old-assumed or find life details. That is what PD-old-assumed is there for. If we aren't virtually sure it's anonymous (which often means we know of an old publication to show that), then probably the same. But works which have passed 70pma, and were created before 1927 but we aren't 100% sure were published then, sure I'd keep those. COM:PRP says we should not allow works with a significant doubt, but usually the question of publication is more of a theoretical doubt to me -- most works were published near the time they were created. Oftentimes (such as the EU), the terms for anonymous works start at "public display" as well, not strict publication. If there is some specific factor which increases the chance of delayed publication, that may push things into significant doubt territory. But there may be some way we can indicate the publication question usually does not rise to a significant doubt, maybe. Carl Lindberg (talk) 16:49, 13 June 2023 (UTC)
  • I have family pictures of the early 1920s (my grandparents' wedding, etc.), and these can't be uploaded to Commons with the current rules. It seems exaggerate to wait until 2045 to be able to upload them to Commons. Yann (talk) 17:44, 13 June 2023 (UTC)
  • I think it is very frustrating not to be able to upload old family photos, but if the photographer was 25 at the wedding and died as 80 – which isn't far-fetched – their 70 years pma term lasts to 2045. Thus it is highly probable that the photo is still under copyright for some time, and if they were professional and your grandparents were celebrities of some sort, it is very much possible that their heirs know about their copyright. The limit of 120 years is not unreasonable if we want to respect the law (it also corresponds to the US 120 years since creation). –LPfi (talk) 18:39, 13 June 2023 (UTC)
  • This assumption is not reasonable, and that is the point of my proposal. All people who might have known the photographer of these pictures died decades ago. So it is not reasonable to ask for the name of these photographers. So assuming unknown photographers, the copyright in France expired before the URAA date. If I upload these to Commons, I will probably be the first to publish them, and therefore I would own the (new) copyright for 25 years. This is a complicated reasoning, which depends on the country of origin. So I suggest to generalize and simplify this with a new rule. Yann (talk) 20:05, 13 June 2023 (UTC)
    So in your case the reasonable assumption of it being anonymous would suffice. In Finland most photos are below the threshold of copyright and protected for a shorter term (which ended before the URAA date if taken before 1966), However, in countries where the 70 years pma applies to ordinary photos, a photo that could have been published may well be under copyright. Even the current 50 years for "photographic pictures" in Finland is quite unreasonable – I am not allowed to use childhood photos from my family album other than in private. A biography could not legally use the photos (at least not if published in the USA), even though I am a heir of the rights to most – I just don't know to which ones. For family albums the "published immediately" gives too long a term to solve the problem, and still has no reasonable legal grounds. –LPfi (talk) 06:23, 14 June 2023 (UTC)
  • I think I would consider those either published and anonymous, or unpublished (and anonymous) with the family owning the copyright. Presuming of course the photographer's name was not on them. The only way I would consider those unpublished is if the initial copyright vested in the family (which in older laws was more common), but in those cases they are licensable. Carl Lindberg (talk) 22:37, 13 June 2023 (UTC)
  • @Clindberg: I am not sure I follow your reasoning here. These pictures are in a family album for the last 100 years. Does inherit the album constitute publication? If not, they are certainly unpublished. It was most probably a professional paid for that, as a camera was a rare and expensive item at the time. And they certainly didn't trust an amateur for such important pictures (for them). But nobody knows who was this photographer, and even less what agreement my grandparents had with him. So certainly fit the definition of orphan works. We lack pictures of that time, partly due to the uncertainty of copyright status. Allowing such pictures would certainly not create great legal risk for anyone, but would benefit Commons. Yann (talk) 22:55, 13 June 2023 (UTC)
  • If the copyright was owned by the family, no I do not think they become published, but the copyright would be inherited (and thus can be licensed by the heirs, if the copyright still exists). Honestly, if they were not made available for 70 years, they also become PD in the EU (but that EU 25-year publication right may need to be licensed, which the family would own regardless of the original copyright). If you believe that the photographer still owned the copyright, then I would consider the act of selling the photos to the family to be publication (or making available to the public, or whatever). If there were specific rules about commissioned works in older laws, those may need to be followed. Carl Lindberg (talk) 23:09, 13 June 2023 (UTC)
  • In the current Finnish law, rights to portraits by default stay with the photographer, who nonetheless isn't allowed to publish them without the subject's permit. Thus, no such photos can be published during the protected term, unless either party knows the identity of the other, which would be extremely rare with a studio out of business since decades. I am afraid this arrangement might be common in the EU. –LPfi (talk) 06:42, 14 June 2023 (UTC)
  • Yep, that seems to be the case since 1961. Older photos apparently still follow the older law, and would be interested in what that says. I think they had a copyright law in the 1920s, and maybe an ordnance from the 1880s before that. Most countries do not have an explicit portrait right like that, even in the EU, though some do. That one is interesting in that the copyright is owned by the photographer but need the person's permission to do anything with it. The person can publish it in certain ways without permission from the author. But probably not "free".
    • @Clindberg: No, not free, the ways to use the photo without author's permission are very limited. Also the original 1961 version of the law is available at Finlex (in Finnish and in Swedish). However, at that time, photographic pictures where handled in a separate law, which might not be digitised (probably enacted at the same time; I think they were included in the copyright law through 446/1995). Photographic images did not have their copyright retroactively extended in 1995. The older copyright law is 174/1927 (amended in 1930 and 1941), which likewise doesn't seem to be digitised at Finlex. –LPfi (talk) 08:07, 15 June 2023 (UTC)
  • For non-professional photos in family albums, most are still under copyright, and most photographers would not object to the family using them any way they want. I'd be seriously upset if my cousin objected to my uploading a photo of my mother taken by his father – although legally I'd need to have his permission. I would be equally upset if some guest, who photographed my mothers family, objected to my publishing the photo they took and gave us.
    Thus, even if I don't know who took a photo and the rightholders might recognise it, knowing their rights, I might want to take the risk rather than letting the photo rest in the attic. The main risk is if somebody uses a family photo in a book and the photographer happens to have a greedy heir. Whether that is a real risk with most family photos from the 1920s (or even 1950s), I don't know. Can they prove they are right in who took the photo?
    –LPfi (talk) 18:58, 13 June 2023 (UTC)
  • No, this is wrong. We are talking about pictures taken nearly 100 years ago. 99% of these pictures are out of copyright, but it is difficult to prove it. Yann (talk) 20:08, 13 June 2023 (UTC)
  • The term of 70 years after creation had of course run out before 1996 for now-100-year-old anonymous works. However, where the term had not ended before the URAA date, they got 120 years in the USA (95 years after publication would not apply for unpublished family photos). This applies to most family-album photos in the EU taken after 1925. I believe the exceptions are limited to photos below the threshold of originality (common in Finland and Sweden) and some special cases. LPfi (talk) 06:58, 14 June 2023 (UTC)
  • That's why I only propose this for works created before 1928 for 70 years pma countries. Please do not confuse my proposal with different interpretations. And no, this is not limited to photos below the threshold of originality. Yann (talk) 14:50, 14 June 2023 (UTC)
    I think the proposal boils down to assuming photos created to be published to have been published soon after creation and photos in family albums to be anonymous, unless there is evidence to the contrary (the uploader should check notes in the album and on the back of the photo) or reason to be especially cautious (photographers' archives). That seems reasonable to me. However, I don't see any grounds to assume works to have been published anonymously (which would be required for published 50-years-pma 1945 photos to be PD-1996). –LPfi (talk) 08:42, 15 June 2023 (UTC)
  • @LPfi: Are you sure that pre-1996 copyright expiration for an unpublished work makes it PD in US? Per my knowledge URAA applieas only to published works. If an anonymous work remains unpublished till 2003 then it is irrelevant what is its status outside US: it becomes PD in US 120 years after creation. Ankry (talk) 00:16, 16 June 2023 (UTC)
    • @Ankry: that's true for anonymous works, but if the author is known it is 70 years after date of death. - Jmabel ! talk 01:22, 16 June 2023 (UTC)
      In that case the 1920s wedding image would be copyrighted in the USA until early 2040s, unless the photo is accompanied by the photographer's name or was published before 2003. Is that true?
      For such photos (if we can be quite certain it wasn't published), the question is whether we want to keep applying the precautionary principle to old orphan works: it is under copyright but in this case we don't just hope they won't sue, but more or less know they won't (if the couple wasn't famous and the wedding didn't make headlines).
      –LPfi (talk) 07:41, 16 June 2023 (UTC)
      @LPfi: Only if the work was really unpublished, which in the U.S. case is a torturous question (no legal definition so depended on jurisdiction and court decisions). The sale of the photos might itself be considered publication, and if not then the common-law copyright would probably be considered transferred to the family, in which case they could license it. So, insofar as this proposal is about assuming such old photos were published and/or made available to the public around when they were created, and then following copyright law based on that assumption, I'm OK with it. Photos taken by the family usually could not use that assumption, but those can be licensed (by heirs) if they want them uploaded. But I don't think an arbitrary cutoff regardless of what the copyright law is in the country origin is a good idea -- PD-old-assumed is what we have for photos we know almost nothing about, and I don't see a good reason to ignore that. Carl Lindberg (talk) 15:15, 1 July 2023 (UTC)
  • I would judge this on a case-by-case basis, and actually already do so. That is, if a picture looks like it was created with publication in mind (especially publicity and similar photos), it is a reasonable assumption that it was published close to the time of creation; photos made for a family album are a different matter. Gestumblindi (talk) 19:31, 13 June 2023 (UTC)
  •  Support Personally I kind of look at this like how images of graffiti are usually handled. Mainly in most there isn't a way for the original photographer to prove they are the person who took the photograph to begin with. So it's extremely unlikely that anyone will sue for copyright infringement in those cases. Like with Yann's example of the pictures of his family. What are the actual chances that the original photographer can even prove they took the pictures to begin with? Plenty slim to none. More so if it's a relative of the photographer. So I don't see why we couldn't take a more relaxed position on such cases like we do with graffiti. Although I agree with Gestumblindi that it should be done on a case by case basis. I've seen people claim that a photo was published anonymously just because they didn't know who the photographer was when they uploaded the image. I don't want to see a similar thing happen here, where being lenient with old orphaned works without a proof of publication allows people to just disregard the normal guidelines because in their opinion the photograph is a one off that was taken by a none professional at an informal family event or whatever. Issues like that can be figured out later though. --Adamant1 (talk) 21:22, 13 June 2023 (UTC)
like how images of graffiti are usually handled Hi, you do know that there are accounts systematically searching for graffiti and murals in countries without freedom of panorama (like France, Italy and the US) and then propose deleting them? --Enyavar (talk) 06:48, 14 June 2023 (UTC)
  •  Question Again: What IS an "orphan work" as far as this proposal is concerned? --Rosenzweig τ 06:40, 14 June 2023 (UTC)
    This would be a work the copyright owner of (1) is unaware of their copyright and (2) cannot be traced. (1) is impossible to know, (2) is easy to state but difficult to prove. The copyright laws of EU have a definition, and allows special handling of orphan works by a few select institutions. To enact this proposal, we need to formulate reasonable working definitions of (1) and (2) or handle them purely case-by-case (arbitrarily or with a slowly developing praxis). I assume we should add a discussion to some guideline, as bases for the case-by-case decisions. –LPfi (talk) 07:07, 14 June 2023 (UTC)
     Support, @LPfi, you wrote, "The copyright laws of EU have a definition, and allows special handling of orphan works by a few select institutions."
    Can the Wikipedia Foundation or the German Wikipedian group apply to allow Wikimedia Commons to be one of the "few select institutions" to "allow special handling of orphan works?" perhaps, a written process or checklist for evaluating potential "orphan works."
    Thanks, -- Ooligan (talk) 04:38, 1 July 2023 (UTC)
    For Finland, it would at least require a change in the copyright law. I assume the same is true for other countries. Regardless, the DIRECTIVE 2012/28/EU ("on certain permitted uses of orphan works") allows only some uses by the institution itself – preserving and making the work available, not relicensing – and requires that the institutions pay for the use of the work would a rights holder appear. Thus, orphaned works would not be free to use in the Commons sense even if Commons were identified as one such institution. –LPfi (talk) 10:06, 1 July 2023 (UTC)
    By the way, I have also argued in the past that we should allow (modern) orphaned bystander selfies, where the owner of a camera asks a stranger to take a photo of them and neither person retains any contact info or identifying details about the other person and the photographer does not retain any copy of the photos or proof of authorship. But of course, that's a separate discussion. -- King of ♥ ♦ ♣ ♠ 22:21, 15 June 2023 (UTC)
"Common sense" and "Copyright Rules allowing stuff on Commons" are mutually exclusive. A non-overlapping venn diagram. --Enyavar (talk) 15:15, 24 July 2023 (UTC)
  • Yes. In many jurisdictions, an implicit licence (or copyright transfer) to the camera owner would be assumed. Without that licence you wouldn't be allowed to publish the photo on social media. There are still complications; the extent of such an implicit licence could be ill-defined. If the camera owner isn't allowed to relicense the work, then this is a class of orphan works. One problem is that the bystander might recognise the photo and might not have intended for the photo to be put in widespread use. If you took a photo of a to-become celebrity and then find that your photo is used unattributed all over the net, you might not be happy. –LPfi (talk) 10:22, 1 July 2023 (UTC)
    I agree on the bystander photos. There are also arguments that the pictured person could be a co-owner of the copyright as well, since they often choose what is in the photo, pose themselves, etc. There's not much sense in following copyright to the letter in those cases, as you get a nonsensical result anyways, and there are decent arguments for co-authorship anyways. Carl Lindberg (talk) 15:15, 1 July 2023 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Prevent IP users from creating deletion requests

1 . it is not that hard to create an account. IPs are so hard to follow, which IP created good or bad DR?? how can we prevent this? even, they are unable to upload files but can request for deleting?

2. loooooook at that DR, bro thought we will delete a file because it is "nonsense" 💀💀💀. these users are just slowing our work. so please, stop IPs for creating DRs!!!! ----modern_primat ඞඞඞ TALK 21:35, 1 August 2023 (UTC)

Looks to me like that is probably a deletion request for an out-of-scope personal photo. Badly formed DR, but we get those from logged-in users, too. - Jmabel ! talk 21:38, 1 August 2023 (UTC)
I've deleted the user's files as F10/G10. They're already blocked on enwiki as NOTHERE (and possibly socking there as en:User:Jio Giga Fiber). As for the IP, it's not exactly the most useful DR. but better to draw attention to out-of-scope/spam files that way than not at all. Pi.1415926535 (talk) 22:26, 1 August 2023 (UTC)
Just to be clear: User:Pi.1415926535, you are saying that the uploader is blocked, not the IP who User:Modern primat is complaining about, correct? - Jmabel ! talk 03:16, 2 August 2023 (UTC)
@Jmabel: Correct - en:Bong Girl Creation is blocked on enwiki (not on Commons). IP 181.43.1.29 is not blocked on Commons and has not been active on other wikis. Pi.1415926535 (talk) 03:34, 2 August 2023 (UTC)
The proposal appears to be to prevent DR's from IP users, in general.  Oppose "these users" may still form valid DR's, just like named users may create unreasonable DR's. --Enyavar (talk) 05:47, 2 August 2023 (UTC)
Indded «named users may create unreasonable DR's» and if they persist they may be sanctioned for it. On the other hand, unlogged users cannot be sanctioned for anything because IP addresses are volatile and one can always reappear under a new one. Why is this so hard to understand? -- Tuválkin ✉ ✇ 15:32, 25 August 2023 (UTC)
 Comment: Maybe the English Wikipedia essay “Wikipedia:IP editors are human too” (which, by the way, is an English Wikipedia essay, not a Commons policy nor a Commons guideline) should be updated in the light of so-called A.I. having become cheaply available. And when I say updated, I mean completely upended. Frankly, I have been on the recieving end of much fingerwaving about how I (as a internet fossil who started using networked computers in 1984) should update my views on how to do stuff online, it’s sadly now my turn to warn (as apparently few seem to have comprehended this notion) that many “people” we intertact with online are nor really individual humans thinking and acting real time on their own, and one way to be fairly sure about those who are is to trust continued, consistent pseudonyms. I.P. addresses are inherently volatile and one cannot seriously engage in good faith discussions with the people (or merely people-initiated processes?) behind them. I.P.s should be allowed to contribute, sure (who run away with Modern primat’s goalposts?!), but should not take part on discussions — for the same reason they are not allowed to vote. -- Tuválkin ✉ ✇ 19:33, 2 August 2023 (UTC)
  • Vandalism deletion requests are a very minor problem compared to the problems caused by other types of vandalism. I would support a general ban for IP edits but just do not let them create deletion requests does not solve any problem. --GPSLeo (talk) 18:39, 2 August 2023 (UTC)
  •  Support wholeheartedly! (And thanks to Modern primat for creating this.) -- Tuválkin ✉ ✇ 19:33, 2 August 2023 (UTC)
  •  Oppose In my experience, I have not noticed a particular problem with deletion requests filed by IP users in comparison to requests filed by logged-in users. We should stay as open as possible unless there is a pressing need, and I don't see that pressing need in this case. Gestumblindi (talk) 19:44, 2 August 2023 (UTC)
  •  Oppose totally agree with Gestumblindi. IP requests are not necessarily worse than DR by logged-in users. This solves nothing. Moreover, I feel anyone should be able to request deletions, including incidental users (i.e. IP users). This should not be complicated with requiring log in. --P 1 9 9  ✉ 20:11, 2 August 2023 (UTC)
  •  Support This would save a lot of admin time needed to deal with invalid and malformed requests. Yann (talk) 20:42, 2 August 2023 (UTC)
    The admin time saved by banning IPs from creating deletion request in marginal compared to the admin time needed for all other things IPs do including removal of licenses resulting in accidental deletions. GPSLeo (talk) 04:34, 3 August 2023 (UTC)
    There's an exact dozen of DRs I just had to tag with {{Speedy keep}} because they incurred against COM:INUSE, all filed by a single ip within 24h. I think there’s two for each of the admins who said in this discussion they don’t mind closing DRs. -- Tuválkin ✉ ✇ 22:28, 3 August 2023 (UTC)
    I do not said that there is no problem. But if there are 20 nonsense deletion requests every day this would be very minor compared to the some hundred cases every day where they add nonsense text, change the author or remove the license. GPSLeo (talk) 04:48, 4 August 2023 (UTC)
    And you point is…? I cannot even parse the argument that since IPs poop all over the chessboard, there’s no reason to support this proposal. What, then? Is there a standing proposal to block all IP editing? Where it is?, I wanna support it (maybe I don’t, but anyway). There’s none currently? Okay, so why not some incrementalism and support this one small step now and deal with the rest later? -- Tuválkin ✉ ✇ 12:43, 18 August 2023 (UTC)
  •  Oppose banning IP users who are able to edit from creating deletion requests. I'm actually, like GPSLeo, fairly open to banning all unregistered editing (although I could probably be convinced otherwise, and the sysadmins aren't open to it so it doesn't really matter), but I don't see anything special about deletion requests that necessitates this. —‍Mdaniels5757 (talk • contribs) 02:04, 3 August 2023 (UTC)
  •  Oppose Concur with Mdaniels5757 and GPSLeo, and I actually think it would make more sense to ban IPs from nominating files for speedy deletion and 7-day deletion since there's less scrutiny there; if IPs are to continue to be allowed to nominate files for deletion at all, DR is actually the preferred way for them to do it. -- King of ♥ ♦ ♣ ♠ 16:15, 3 August 2023 (UTC)
    Wait, what?! I.p. can nominate speedy deletions, too, not only simple DRs? (Swoons!) -- Tuválkin ✉ ✇ 22:34, 3 August 2023 (UTC)
    Well, an admin still has to check whether the (speedy) deletion request has any merit. Gestumblindi (talk) 18:02, 8 August 2023 (UTC)
    More needless work piled on admons, the. It would be interesting to contrast the oppsing and supporting votes cast by admins in this proposal and compare their respective activity in cleaning up after IP activity. -- Tuválkin ✉ ✇ 00:31, 23 August 2023 (UTC)
  •  Oppose I'd probably support a general ban on IP Editors since there's plenty of places outside of DRs where they are a nuance, but singling out DRs just seems like the wrong way to go about it. --Adamant1 (talk) 22:28, 3 August 2023 (UTC)
    Yes, let’s not enact a rule against the smothering of kittens because there’s mean people around who also drown them: Unless we can have a rule against both smothering and drowning, no kitten should be saved! (This is inspired in the wikilove template about «A kitten for you!»; it just means I cannot understand that reasoning behind that argument.) -- Tuválkin ✉ ✇ 22:33, 3 August 2023 (UTC)
    In German-language Wikipedia, there are also occasionally calls to ban IP editors from filing deletion requests, and I have always asked for actual statistical data to back the perceived issue up (that is, showing that the percentage of "bad" IP deletion requests is much higher than of "bad" deletion requests by logged-in users). As it turns out, people could never back up this "gut feeling" with actual data, and the percentage of deletion requests by IP users that result in a deletion (meaning that, presumably, the DR was correct, as an admin accepted it and deleted the article) is also fairly high. - Here on Commons, I think that there are many more DRs by logged-in users anyway, and of the small percentage of IP DRs, many are also fine. Gestumblindi (talk) 10:03, 4 August 2023 (UTC)
    I think the dewiki discussion is not comparable to the problem here. On dewiki the discussion is more about sockpuppety and harassment. Here we are talking about simple vandalism or accidental clicks on the wrong button. GPSLeo (talk) 11:15, 4 August 2023 (UTC)
    At least from what I've seen IP editors are mostly fine in deletion requests. They do a lot of vandalism editing to the village pump and other main talk pages. That's not to say they aren't an issue in DRs though. Just that it isn't a unique problem. So I don't think it's worth passing a proposal that treats it like one. Although on the other hand maybe it would be a good way to test the waters. Who knows, but I'm not changing my vote regardless. --Adamant1 (talk) 00:13, 5 August 2023 (UTC)
  •  Oppose. While I understand that IPs will create nonesense at times, the fact that IPs can create DRs is a net positive—we don't want people to abstain from nominating genuine copyright violations for deletion because of the hurdle of account creation, and the proportion of bad DRs created by IPs is not so bad as to require that we throw the baby out with the bathwater. — Red-tailed hawk (nest) 02:58, 8 August 2023 (UTC)
    Yes, let’s file deletion requests for each and every of the soon 100 million files we host. I’m sure that would cover all of the bad ones which could be then deleted. It’s a really effective process. -- Tuválkin ✉ ✇ 12:46, 18 August 2023 (UTC)
    Yeah...'cus that's a real issue that is happening. --Jonatan Svensson Glad (talk) 20:00, 21 August 2023 (UTC)
    Sarcasm would look bad on you, as an admin — even had managed to do it properly. -- Tuválkin ✉ ✇ 00:27, 23 August 2023 (UTC)
  •  Oppose, many IP editors nominate copyright violations for deletion, we shouldn't higher the bar to fight copyright violations. In fact, someone who has never made an account here might not even know that you could nominate a file for deletion if it wasn't explicitly stated like the "Nominate for deletion" button we have now, so removing that option would let a lot more copyright violations stay undetected for longer. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:13, 18 August 2023 (UTC)
  •  Strong oppose this would probable cause a spike in DMCA requests instead. Forcing someone register in order to request the deletion of a file is not furthering the goal of Wikimedia, nor would it be a great deterrent against bad DRs, simply a roadblock in the way of a potential good one - and I'd rather revert a bad DR than loose out on one goo one. --Jonatan Svensson Glad (talk) 19:57, 21 August 2023 (UTC)
    You seriously think that a well meaning person with no prior knowledge of Commons’ inner workings and a good case for a file deletion would rather initiate a DR than ask for its deletion in the file’s talk page?… -- Tuválkin ✉ ✇ 15:36, 25 August 2023 (UTC)

We clearly don't have consensus to change this, and I suggest we end the discussion rather than waste more time on it. Does anyone object? - Jmabel ! talk 01:56, 23 August 2023 (UTC)

This discussion has attracted comments that are helpful to revisit the matter in the future — both points against allowing unlogged users to file Deletion Requests, and support for two very interesting conflicting notions:
  • omg IPs are people too!, therefore oppose
  • unlogged users are a bane indeed but they should be barred from all editing, not only DRs, therefore oppose
So, let this stay open for longer, please. -- Tuválkin ✉ ✇ 15:41, 25 August 2023 (UTC)

Bad image list

Some wikis have bad image lists (MediaWiki:Bad image list) to prevent image vandalism showing on pages. Unfortunately, this is kind of useless because these lists generally cover only a small fraction of the images that could be used for vandalism. Often, the vandals will post close up images of genitalia. Is there some way to put all close up images of genitalia in a category so they could all be put on a bad image list en masse? Obviously this won't totally solve the problem, but I think this is what the bad image lists were intended to prevent and it's no longer working. Of course, it's not mandatory to block these images from showing, it would be up to the admins of each wiki. Kk.urban (talk) 19:13, 2 August 2023 (UTC)

These categories already exist: Category:Close-up photographs of human penises and Category:Close-up photographs of human vulvas. You should not name such a list "Bad image list". This would be very offensive against the photographers and the subjects of the photo. The list could be called "Files used in vandalism context". GPSLeo (talk) 19:28, 2 August 2023 (UTC)
No, that is a bad idea, as GPSLeo pointed out. There are a lot more images that vandals can use, including close-ups of human genitalia, therefore I believe that this would only be a fruitless attempt to address a much larger issue. 20 upper 14:24, 3 August 2023 (UTC)
At least in some language versions, IP edits (including those from vandals) are not directly shown to most readers until they have been reviewed (Pending changes review) by community members, although everyone can request to see the latest non-reviewed version. This helps to combat vandalism. There are also anti-vandal bots which (afaik?) can detect and flag "bad" insertions from IPs and new users (such as insertions of "penis penis penis" in text form) so that human patrollers can remove those edits right away. Maybe the bots can be made more sophisticated to detect "bad" image insertions as well? Still, creating an exhaustive list of images that are "bad" is not something we should do on Commons. Creating bots smart+flexible enough to deal with bad-faith insertions is the task of bot-programmers. Also, here is one of the rare cases where I'd like to see semi-AI helping us. --Enyavar (talk) 15:42, 3 August 2023 (UTC)
You are asking if it possible to create "general" filters for certain types of content? Commons is Not generally Censored, but given the direction certain jurisdictions are moving ( such as the United Kingdom, which wants online hosts to be circumspect about identifying legal but potentially harmful or offensive material.), a review of how 'bad' content is identified is warranted. There are also ethical and privacy concerns raised by hosting certain types of sensitive image, such as those of anatomical subjects. ShakespeareFan00 (talk) 08:54, 18 August 2023 (UTC)
Commons is Not generally Censored General filters wouldn't be censorship anymore then the current practice of categorizing images based on if they have nudity or not is. Categorize just don't seem to work well for the purpose of hiding nudity. But it would be laughable to call putting an image showing people having sex in a sub-category specifically for those types of images censorship. Even though it technically serves to filter what kinds of images people are being exposed to. --Adamant1 (talk) 09:12, 18 August 2023 (UTC)
No, we aren’t censored and the BIL on Enwiki is a last resort that comes with serious costs— namely I’d have to jump through bureaucratic hoops if I wanted to use an interesting, valuable file like File:Eveready Harton in Buried Treasure.ogv educationally on an article like w:The Good Old Naughty Days. We don’t need to force people to ask permission to use an anatomical image of a penis on their local article “human penis” Dronebogus (talk) 17:35, 30 August 2023 (UTC)

Advanced upload stash

Dear community,

I know that we already have some sort of upload stah, but I have some ideas for a potential better one. I think about the possibility to upload for example up to 500 files in a private stash, that can only be accessed by the user itself. Once uploaded, the files can be equipped with information about source, author, and all the stuff. When filled in and done, the files can be published immediately or, as an extra feature, can be published on a desired date (up to 28 days in the future).

A temporarily private stash (for up to 28 days) would it make possible to upload first, and make sure that the files are on the server, and to fill in things later. Sometimes, some errors prevent publishing or a computer crash occur after the upload, but before the publishing, which can be really annoying when you already spent several minutes on filling out things, and all progress is lost. With my idea, the files and information (changes) before publication are saved in real-time (server-side), so you don't lose anything, and can publish them when you think you're done with all. What do you think? Greetings --PantheraLeo1359531 😺 (talk) 12:30, 4 August 2023 (UTC)

Addendum: The files would be deleted 28 days after upload, so they won't be used as personal cloud storage --PantheraLeo1359531 😺 (talk) 12:31, 4 August 2023 (UTC)
Currently, I only use the standard upload tools, where it can take an hour to upload just two dozen files, if you want to do it properly. So I am well aware of the benefits of such a change/addition, in general.
But as an alternative idea: I'd like to see a downloadable attribution tool so that frequent uploaders can pre-set licence/date/description(s)/categories on the local hard-drive, and then just upload when all preparations are done. As a bonus, such a tool wouldn't require a re-programming of the current user interface; and nobody would need to worry about new user namespace requirements, time limits, storage limits etc. --Enyavar (talk) 16:13, 9 August 2023 (UTC)
@Enyavar: it can take an hour to upload just two dozen files: what is the speed of your Internet connection? How big are the files? (I ask because this is 5-10 times slower than what I experience from my usual setup). - Jmabel ! talk 17:37, 9 August 2023 (UTC)
Typing takes time - for a number of literally 24 images, one hour means you finish describing+categorizing each file in under three minutes, which seems a lot faster than how I actually work. So apologies for exaggeration, I'm probably never that fast. If you only need 15-30 seconds (!?) per file, that probably means there's not much content or variation to describe in the first place. I even usually skip that unfriendly claims-tagging-interface in the final step, but I do try to compose meaningful descriptions for each file I upload, sometimes in multiple languages; possibly transcribe and even translate text; and find the most appropriate categories.
Yet, sometimes I find my computer lost internet connection somewhere along the way, critically right when I finally submit the finished uploads --> that is an hour potentially gone to the drain, although I found workarounds to prevent that. Among others, a golden rule to never try to upload more than ~10 images in one go. The upload-process is well-designed, no doubt, but a stable internet connection throughout the process chain is required.
The uploader's idea is "first upload in one fell swoop, then finish the descriptions+categories in a private space so that the images are already safe on the server". My counter-proposal was "be enabled to describe+categorize on the local PC first, then upload in one fell swoop". --Enyavar (talk) 19:15, 9 August 2023 (UTC)
@Enyavar: Right, I thought your remark was about upload speed. I was talking only about the speed of uploading numerous files of essentially the same subject matter (e.g. images of a particular parade). - Jmabel ! talk 20:42, 9 August 2023 (UTC)
unfriendly claims-tagging-interface I take it you are using the Upload Wizard. I avoid it like the plague. I just ping-pong between two tabs and use Special:Upload. I copy-paste wikitext from one photo to the next, and make the necessary edits each time. Low risk (at worst, in the rare case of failure, it's one photo at the time) and from what I can tell, much faster. - Jmabel ! talk 20:42, 9 August 2023 (UTC)
Same here, exactly. -- Tuválkin ✉ ✇ 15:45, 25 August 2023 (UTC)
@Enyavar: There are several bots or automated tools which work that way. See COM:Upload tools. Yann (talk) 20:45, 9 August 2023 (UTC)
At least personally a lot of my uploads take a long time to finish and often fail halfway through the process. That's with Spectrum in a fairly urban area to. So they really need to implement the ability to resume failed uploads or something. Honestly, I'm kind of surprised they don't have the feature already. --Adamant1 (talk) 04:47, 13 August 2023 (UTC)
 Support we need sth better but without having to download third party apps.
uploading files to wmf servers and preparing the file descriptions are two separate tasks. with the current upload form/wizard, 1st task must be done without disconnecting, but the 2nd task is something that can be done even if connection is intermittent. but now we can only do the 2nd after we have done the 1st (but before clicking the final submit button). when a lot of files are batch uploaded, if we want to avoid problems occurring when we slowly fill up the file descriptions, in other words we have to finish the descriptions quickly, there's only 1 way under the current wizard design: giving very basic filenames and descriptions, and only go back to edit after we have successfully submitted the uploads. RZuo (talk) 16:32, 28 August 2023 (UTC)
@RZuo: Have you tried drafting the file description page locally and then uploading with our upload form for experienced users and copy/paste?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:54, 30 August 2023 (UTC)

Adding OpenEXR (EXR) to the list of allowed filetypes on Commons

Hi folks!

While searching for files, I often found the EXR filetype. I am wondering because the filetype is not allowed on Commons (yet).

Because of this, I want to ask, or suggest to add EXR to the allowed filetypes. OpenEXR is an open filetype especially for images with high color depth (and HDR). The filetype is suitable for panoramics (up to 32 bits per channel) and high quality textures (for meshes etc.). See for more information: https://en.wikipedia.org/wiki/OpenEXR

What do you think?

Greetings, --PantheraLeo1359531 😺 (talk) 15:14, 28 August 2023 (UTC)

My understanding is that this format is primarily intended for use as an intermediate format in film production. Can you give any examples of how it could be used in Commons, particularly given that it is not supported by web browsers? Omphalographer (talk) 02:43, 31 August 2023 (UTC)
The advantages are saving in up to 32 bits per channel for HDR photographs (especially panoramas), it can be read by many image viewers and can save many layers and several channels (also z-buffer afaik). It is also common in assets for computer games or to save raster images with many different information that are rendered or generated by computer software. So it is used in professional production of media, 3D scenes or other professional rendering and CGI (VFX, etc.) --PantheraLeo1359531 😺 (talk) 15:55, 31 August 2023 (UTC)
This also possible with the widely used TIFF. If that has not enough information we should get support for DNG. GPSLeo (talk) 16:28, 31 August 2023 (UTC)
It seems like EXR saves far more disk space than TIFF --PantheraLeo1359531 😺 (talk) 12:02, 1 September 2023 (UTC)
If you use some compression TIFF files can also be very small. GPSLeo (talk) 13:45, 1 September 2023 (UTC)
As far as I'm concerned, "you can also do that with A" is not a convincing argument against supporting B. El Grafo (talk) 10:09, 8 September 2023 (UTC)

MP4 and MKV videos

Good night! I have a suggestion to upload video files with MKV and MPEG4 codec, which in turn will save participants from having to convert videos to lower formats. MasterRus21thCentury (talk) 22:18, 25 August 2023 (UTC)

We only allow file types that are not patent encumbered. —Justin (koavf)❤T☮C☺M☯ 07:49, 26 August 2023 (UTC)
 Oppose per Justin.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:14, 26 August 2023 (UTC)
Wouldn't MP4 be automatically accepted once the parents expire or would that need another discussion to "reach consensus"? As the only reason I can find for its exclusion is the patents. In fact, it might be wise for the Wikimedia Commons to just automatically accept any and all formats for files (unless all files in that format are automatically out of scope, like .TXT files) the moment there are no intellectual property issues, that would save the community a lot of time with these endless decades long discussions over formats. We simply block formats if they prove disruptive and allow them all by default (again, as long as there are no IP issues as there currently are with .MP4 files.). --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 16:56, 31 August 2023 (UTC)
MP4 containers nowadays are usually used to transfer AVC (H264) or HEVC (H265) video, not MPEG4; the patents on AVC don't expire for a few years still, and HEVC for quite some time. Omphalographer (talk) 17:14, 31 August 2023 (UTC)
Exactly this ^^^^^ —TheDJ (talk • contribs) 18:33, 8 September 2023 (UTC)
At the end of this year, will we have a way to accept MP4 files but reject ones with AVC (H264), HEVC (H265), or other patent-encumbered codecs?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 05:46, 10 September 2023 (UTC)
Same question re MKV.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 05:48, 10 September 2023 (UTC)

Limit file overwriting to users with autopatrol rights

There are many disputes on overwriting of files and also many cases of long undiscovered bad overwrites. To prevent this I would propose that file overwriting is only allowed to users with autopatrol rights. Users without autopatrol rights should remain to be able to overwrite their own files. This simple change would prevent a lot of time consuming disputes. As the requirements to get autopatrol rights are low this would not prevent users from doing useful contributions. GPSLeo (talk) 07:31, 13 August 2023 (UTC)

I may support this, but could we start this with an edit filter/tag to determine how widespread this activity is, and perhaps stave off some of those "undiscovered" mistakes? Elizium23 (talk) 07:45, 13 August 2023 (UTC)
Elizium is right, out of the blue I have no indicator how often overwrite actions by non-autopatrollers happen at all, and how often this turns out to be an undiserable action. Also, can this be tagged/filtered retro-actively?Enyavar (talk) 10:15, 13 August 2023 (UTC)
Checking how often this happened in the past is a bit complicated. But I create an abuse filter to monitor all cases from now on Special:AbuseFilter/290. GPSLeo (talk) 10:51, 13 August 2023 (UTC)
I had a look at the filter hits: Since yesterday 19:00 UTC there were 74 files overwritten by users without autopatrol rights. I had a look at all these edits. 20 of the overwrites are fine. In 20 cases it could be discussed if the overwrite violates the guideline. In 34 cases there is a clear violation of the COM:OW guideline. GPSLeo (talk) 09:45, 18 August 2023 (UTC)
 Support I agree with XRay but in any case new users don’t have any good reason to be trusted with such a powerful potential vandalism tool Dronebogus (talk) 03:39, 20 August 2023 (UTC)
  •  Question: in cases where non-autopatrolled users have legit reasons for overwriting, how do you envision they submit an overwrite request in the future? --HyperGaruda (talk) 05:41, 20 August 2023 (UTC)
    They should just request autopatrol rights. I do not think that there are cases where a user is trustworthy for overwriting but not for autopatrol rights. Alternatively we could create a template that can only be placed by admins/patrollers to make an exception for a file. GPSLeo (talk) 15:55, 21 August 2023 (UTC)
 Support.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 12:56, 26 August 2023 (UTC)
 Support - A great idea. Nosferattus (talk) 06:24, 27 August 2023 (UTC)
if a user is denied autopatrol but the overwrite request is justified, how are you gonna process that request?--RZuo (talk) 14:42, 27 August 2023 (UTC)
  •  Weak oppose. I'm not sure if this is such a good idea. It seems like it will fundamentally change editing unless you're one of a small group of editors. I have overwritten a decent number of files, for things like SVG code cleanups. I only got autopatrolled because I asked for it when I needed to upload and MP3 file. But on the other hand, the rate of misuse by well-intentioned editors seems to be high. But could making greater efforts to educate newer users of when to overwrite files be the better approach? Edit: There are also files that need to stay updated, like File:Gestational limits for elective abortion in the United States.svg, which I could not have worked on unless I was autopatrolled or someone allowed uploads by all. The Quirky Kitty (talk) 08:23, 14 September 2023 (UTC)
  •  Comment - First (1st) of all, having seen a large amount of problematic overwrites by new and sock accounts I acknowledge that this is a major problem and a common cause for edit warring. However, there are plenty of legitimate cases where users who very likely aren't eligible for autopatrol will run into problems if they cannot overwrite a file. At the Graphics Lab there are a fairly number of WikiGraphists with no user rights that upload high quality SVG files, many of these users barely have any uploads and edits in general but the few edits they have consists of taking on requests and / or cleaning up SVG source codes (something which can only be done by overwriting files). Another issue is that if non-autopatrolled users can't overwrite their own files they might upload a similar file and then request deletion for the original, minor cropping or censoring faces, license plates, Etc. for privacy reasons are common examples here. Further regarding SVG files we could see situations where users will upload nearly identical SVG or even identically looking SVG files and then nominating the original for deletion over errors in the code ("Bad code") or over minor colouring issues that could've easily been fixed by overwriting.
There are a number of unforseen consequences that I simply haven't seen anyone bring up here. Perhaps if such a filter is put in force it should exclude users overwriting their own files. We don't want a vandal replacing a highly visible picture of the Louvre with their penis or vagina, but also don't want to limit technically skilled users with barely any contributions from cleaning up SVG source code. The issue with the latter is that SVG files are the files that are most likely to be overwritten, edit warred over, and vandalised, so excluding them wouldn't make much sense either. If technically feasible we should limit new users overwriting files uploaded by others (namely users who aren't currently a part of a file's upload history), but we should also find a way to allow users without Autopatrol right to help with improving them. Sometimes non-Autopatrolled WikiGraphists overwrite a current coat of arms with a better version because the current one has a minor factual error. A look at "File:Flag of the Vatican City.svg" shows how many trusted Wikipedians without Autopatrol rights helped improve this image. Personally, I'd say that the best solution that would take the least time and introduce the least unnecessary workload would simply having a daily list of overwritten files by non-autopatrolled users showing the previous iteration of the file and the new iteration. I'm fine with a template to allow overwriting, but it would also be a lot of work to manually add them to uploads where they should be allowed. As this has already passed I'm only adding suggestions as this will affect flags and coats of arms which are commonly overwritten by Wikipedians with barely any Commonswiki edits.
Another issue is that users cannot show with which files they would like to overwrite without separately uploading them creating needless duplicates or even making overwriting the original more difficult because of duplicates. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 22:54, 10 September 2023 (UTC)
 Support Good idea. Yann (talk) 15:19, 23 September 2023 (UTC)

Implementation problem

There is a clear consensus to limit the file overwriting. I tested the implementation and ran into a problem. The limitation itself is no problem and could be turned on at any time by switching the abuse filter to blocking. But there is problem with allowing particular files. My idea was to make the template {{Allow Overwriting}} that can only be placed by users with patrol rights and the make an exception for all files with this template on the file page. The problem is that there is no way to check the wikitext of the file page when a file upload is logged. So it seems that we would need a new user right and protection level to get the ability to make exceptions of particular files. Writing all exceptions into the abuse filter is not practical.(For the low amount of test files this is no problem.) As the solution for the exceptions might take a while do we want to implement the limitation without the ability for exceptions for now? --GPSLeo (talk) 15:23, 31 August 2023 (UTC)

Ping at @P199, Krd, Glrx, A.Savin, XRay, Dronebogus, Tuvalkin, Jeff G., Nosferattus, and C1K98V: are you fine that we wait for a response on the bug report
Tracked in Phabricator
Task T345896
. Then if the problem can not be fixed that fast we implement this despite the problem that exceptions are only possible if they are written directly into the abuse filter? GPSLeo (talk) 09:24, 8 September 2023 (UTC)
Yes --A.Savin 09:50, 8 September 2023 (UTC)
Yes, Thanks. C1K98V (💬 ✒️ 📂) 10:09, 8 September 2023 (UTC)
Sure. --XRay 💬 11:47, 8 September 2023 (UTC)
Of course, yes. -- Tuválkin ✉ ✇ 13:08, 8 September 2023 (UTC)
Yes, BTW, the bug link isn't working for me. Nosferattus (talk) 17:26, 8 September 2023 (UTC)
@Nosferattus: That was fixed by GPSLeo in this edit to reference phab:T345896.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 05:39, 10 September 2023 (UTC)
OK as long as new user can overwrite his own uploads. Glrx (talk) 18:23, 8 September 2023 (UTC)
@GPSLeo: What would the filter rules be until phab:T345896 is resolved?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 05:42, 10 September 2023 (UTC)
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals/Archive/2023/08&oldid=814724782"