Commons:Village pump/Proposals

Community portal
Help deskVillage pump
Administrators' noticeboard
vandalismuser problemsblocks and protections

Shortcuts: COM:VP/P· COM:VPP

Welcome to the Village pump proposals section

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

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

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

We don't have enough videos, some proposals to Improve the issue of meagre video files on Wikimedia CommonsEdit

As per Special:MediaStatistics less than 1% of our files are videos, in size 4.97% of our total storage is video.
Q Why do we need more video?

  • A Visual stimulation grabs users’ attention, our goal of developing and maintaining open content, wiki-based projects and providing the full contents of those projects to the public free of charge is incomplete without educational videos.

Q How does a normal-user upload video (at present)?

  • A They either use FFmpeg(or any other video conversion tool) or upload via Commons:video2commons. Please note that new users are not aware of Video2commons and it's also restricted to AutoConfirmed Users for obvious reasons. Users editing through tablets/phones/phablets/cheap computers can't uses FFmpeg as it's slow.

Q Are we ignoring this problem?

  • A You know better, than I do.

Q Would it break WMF's server?

  • A Commons:video2commons runs on WMF server, it doesn't break it. WMF has enough processing power to handle the conversion.

Please feel free to oppose any of the following proposals, but don't forget to provide a realistic solution to increase the number of videos on Wikimedia Commons.

Proposal 1: Support conversion of MP4 files to open format like WebM & delete/nuke the MP4 file after uploading the transcoded Webm fileEdit

  • Most of the Video cameras record in MP4, smartphones record in mp4. The uploader is required to convert the video to Webm, otherwise, they can't upload to commons.
  • Conversion takes too much time(sometimes even days), expensive computers, etc.
  • It should be understood that videos would be recorded in MP4 no matter what we do, now conversion can either be done on the uploader's computer or WMF's servers.
  • By doing the conversion on the WMF server we can increase the number of video files. And by deleting the mp4 file, we are not hampering with WMF's goal of supporting open-source.
  • By not allowing the conversion on WMF servers we are certainly hampering upload of many educational videos.

Votes for Proposal 1Edit

  • Symbol support vote.svg Support As the suggester -- Eatcha (talk) 10:08, 8 November 2019 (UTC)
  • Symbol support vote.svg yes, please. Many content creators can't upload educational videos to Commons because it doesn't support uploading of mp4 files. Masum Reza📞 10:51, 8 November 2019 (UTC)
  • Symbol support vote.svg Yes, please, I have tried uploading videos before discovering Video2Commons but gave up until I found out about the tool. A lot of newbies or just general users who do want to upload video files to Wikimedia Commons will be empowered to do so if this proposal gets accepted. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 14:43, 11 November 2019 (UTC)
  • I Symbol support vote.svg Support whatever of these proposals allows uploads of MP4. As it happens, the US government normally releases video in this format, and I have more than once downloaded and tried to upload a video only to remember that I forgot that the format isn't allowed. I'm not really qualified to comment on the technical nuances. GMGtalk 20:34, 30 November 2019 (UTC)
  • Symbol support vote.svg Support same as GMG, proposal 1 or 2, it's mostly what developers think is more doable. Because that's usually the bottleneck. In fact, it may not matter what we vote anyway. We can't force any developer to work on it. - Alexis Jazz ping plz 20:50, 30 November 2019 (UTC)
  • Symbol oppose vote.svg Oppose Too complex procedure. It would make tons of additional backlog. – Kwj2772 (talk) 22:44, 1 December 2019 (UTC)
  • Symbol oppose vote.svg Oppose - MP4 patents will eventually expire (around 2027?). We might as well keep the files around so we can use them once that happens. Plus we may want to re-transcode from the original sources at some point due to better codecs, fixes to transcoding bugs, etc. Kaldari (talk) 23:19, 31 January 2020 (UTC)
  • Symbol oppose vote.svg Oppose. Unless the WMF can't afford the storage space, there's no reason to delete the uploaded source files. They should be kept for future use, mostly re-encoding the VP8 and VP9 versions if such a need arises, generating versions for future formats such as AV1, and making future editing of the uploaded video files viable with less quality loss (see Commons:Lossy and lossless for why). Proposal 2 should be the short term solution, and Proposal 3 the long-term strategy. -- (talk) 14:42, 6 February 2020 (UTC)
  • Symbol support vote.svg Support the allowing of uploading of MP4. No position on whether we keep or delete the MP4 after conversion. Doc James (talk · contribs · email) 03:31, 10 February 2020 (UTC)
  • Symbol support vote.svg Yes, please - The first is a sure shot yes. Can someone quantify the cost per annum for having a mp4 to webM set-up? There are many "free online converters online" who support themselves via ad. So i don't think this will be by any chance the costs will run in millions of $. W.r.t second half - that can be debated. However, the first half is a definite yes.--Pratik.pks (talk) 03:08, 11 February 2020 (UTC)
  • Pratikpks I don't have stats for total minutes of videos but tells that VP9 + Webm is the costliest combination supported on commons. AV1(in webm) is not supported but if we support that would be the costliest combination possible. If we we assume that every single video on commons is 5 mins, it would cost about $1 million(VP9+webm). For AV1 + webm itwould be about $2.5 million. Based on Special:MediaStatistics. PS: all these videos are uploaded in many years. -- Eatcha (talk) 05:33, 11 February 2020 (UTC)
  • Thanks for quantifying the amounts, Eatcha. So (VP9+Webm) costs $1 million to convert around 82,000 videos uploaded to date. So if we are to now apply these conversion for prospective videos, and assume 10K videos uploaded per year (it will costs $125K) or assume a bump in the number of upload to videos to 20,000 videos (due to easy conversion of mp4 to WebM) - it will cost ($250K). This pricing is based on an external provider, and if we do it on in-house servers, we could save around 50%, right? So the costs will reduce the ($62.5K - $125K per annum). Does that sound reasonable? Any further upward/downward adjustments in pricing? --Pratik.pks (talk) 02:45, 19 February 2020 (UTC)
  • Pratikpks $62.5K - $125K per annum is reasonable to me considering total donations, it depends on WMF. is it reasonable to them ? -- Eatcha (talk) 03:49, 19 February 2020 (UTC)
  • I don't have any numbers myself, but my gut feeling is that the numbers cited above are significantly higher than the true cost (especially if excluding any sort of salary of the people setting it up, and the fact that these servers already exist regardless of what happens with this proposal). I don't think we should make any assumption on cost of this proposal. If its unreasonably expensive WMF will tell us.Bawolff (talk) 11:13, 20 February 2020 (UTC)

Discussion for Proposal 1Edit

With regard to the upload of a non-free mp4, these do not have to be visible on Wikimedia Commons, so the proposal as written is unnecessarily complex or negative.

The upload process puts the file on a WMF server where there are some checks and information like EXIF data is parsed in order to create the page that later appears on Commons. A video pre-processing stage can occur at that point, which can logically either reject the video file due to parsing errors, unrecognized codecs, any other type of error, or successfully release the webm version. The mp4 original could be retained in a file archive as a potential future reference, including the advantage of being able to automatically re-process the video should the pre-processing software be upgraded or indeed being able to release the mp4 should Commons policies change or the nature of the copyrights for that format change. -- (talk) 11:08, 8 November 2019 (UTC)

The software, as written, mostly assumes that the initial verification stage is relatively fast, where transcoding can take a long time (possibly even hours for a long HD video). So making MediaWiki work that way, might involve some effort. That said, i think the effect of what you are saying is good, and perhaps can be accomplished more efficiently with slightly different technical implementation. Bawolff (talk) 02:47, 23 December 2019 (UTC)

Technical question: When I upload a long, high-resoluted video, I use CPU capacity of a Wikimedia Server. Is there any way for the upload website to use my own CPU for video conversion? --D-Kuru (talk) 16:07, 5 January 2020 (UTC)

Theoretically, yes. The problem is, the technology for doing so is mainly used to mine Bitcoin on unsuspecting users systems (one study found that literally half the use of Webassembly was to mine cryptocurrency.) I'm not completely familiar with Webassembly, but if there is a way to compile existing conversion code for the web, it's still going to be a lot of infrastructure that has to be written. If there's not, or it doesn't work well enough, doing it would be a huge project. So I wouldn't hold my breath for it.--Prosfilaes (talk) 02:10, 7 January 2020 (UTC)
So this is an interesting question. There's a couple points I'd like to make:
  • Wikimedia has lots of servers, at least several hundered. video scaling is a very small part of it. Part of the issue here of course, is not just that transcoding video takes a lot of cpu, but it takes a lot of cpu in a row (Some parallization is possible, but you can't just split it up amongst 10 different computers to take a tenth of the time).
  • Long ago there used to be a firefox extension called firefogg, which integrated with UploadWizard and caused videos to be converted as part of that.
  • WebAssembly can be used for this sort of thing. In fact, the reverse of that is kind of how we play videos/audio on iPhones where there is no other option [1]
  • Generally speaking, if we are creating transcoded assets (i.e. the resized videos), we would want to do it on wikimedia servers for quality assurance reasons. We wouldn't want a vandal to upload the 640p version to be something different than the original file.
Generally speaking I think w:WP:PERF applies here to a certain extent. Bawolff (talk) 11:08, 20 February 2020 (UTC)

Proposal 2: Allow uploading of MP4 files, only provide transcoded Webm files to download/stream.Edit

  • Keep MP4 files, don't allow download of MP4 files nor streaming.
  • Instead, stream Webm version of the MP4 files and allow Webm version of the MP4 file to be downloaded.
  • It doesn't promote MP4, as we are disabling download and streaming. Users can no way get he MP4 file that was uploaded.
  • On August 26, 2010, MPEG LA announced that royalties won't be charged for H.264(patent expiring in 2027) encoded Internet video that is free to end-users.

Votes for Proposal 2Edit

  • Symbol support vote.svg Support -- Eatcha (talk) 10:09, 8 November 2019 (UTC)
  • Symbol support vote.svg Support Kaldari (talk) 16:00, 12 November 2019 (UTC)
  • Symbol support vote.svg SupportKwj2772 (talk) 20:22, 30 November 2019 (UTC)
  • Symbol support vote.svg Support, this would make uploading video files a lot easier as it is the de facto standard. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:36, 22 December 2019 (UTC)
  • Symbol support vote.svg Support I support this. I don't think the free content movement is well served by making it difficult for people to convert their works to free formats. I am strongly opposed to serving content in patented formats, but freeing content from patented formats seems like an obvious good. Additionally, the debian project seems to view MP4/h.264 as free enough to distribute transcoding software, which in my mind satisfies the requirement that Wikimedia's software stack should be forkable. Bawolff (talk) 02:52, 23 December 2019 (UTC)
  • Symbol support vote.svg Support - Tibet Nation (talk) 18:25, 29 December 2019 (UTC)
  • Symbol support vote.svg Support Keep, transcode and make available when patent issue is gone.--So9q (talk) 10:47, 16 January 2020 (UTC)
  • Symbol support vote.svg Support, with the exception of the proposal (all of these proposals, actually) conflating the MP4 container format and non-free video coding formats. A better wording would be non-free MP4 files or even better, specifying the video coding formats in question. MP4 is not non-free. Fully free MP4 files (AV1 + Opus) are possible and are actually served by Youtube, though I'm not sure whether Commons currently accepts them as uploads. -- (talk) 15:14, 6 February 2020 (UTC)
  • Symbol support vote.svg Support Good idea too Doc James (talk · contribs · email) 03:32, 10 February 2020 (UTC)
  • Symbol support vote.svg Support This is extremely useful. —Justin (koavf)TCM 04:34, 10 February 2020 (UTC)
  • Symbol support vote.svg Support This is a brilliant idea, and a great balance between functionality and values. --Pratik.pks (talk) 03:05, 11 February 2020 (UTC)
  • Symbol support vote.svg Support Is there a holding-pen somewhere where the mp4 files can be saved until the patent expires? maybe? Victorgrigas (talk) 19:06, 11 February 2020 (UTC)
  • Symbol strong support vote.svg Strong support Perfect. --pandakekok9 04:52, 11 March 2020 (UTC)
  • Symbol support vote.svg Support We need this. -Theklan (talk) 08:23, 16 March 2020 (UTC)
  • Symbol oppose vote.svg Oppose as worded. Doesn't make any sense, why keep a file nobody can view, when by 2027 there will/are certainly be better codecs (e.g. AV1) available? -FASTILY 22:21, 13 April 2020 (UTC)
    • @Fastily: All web video codecs use lossy compression (AFAIK), so the originally uploaded file will still be the highest quality regardless of what other codecs are available in the future (assuming that the uploader doesn't re-encode it from an uncompressed master and re-upload it once the newer codecs are supported). In other words, every time a video gets transcoded it loses quality, so retaining the original (and using it once we can use it) is desirable. Kaldari (talk) 01:02, 30 April 2020 (UTC)
  • Symbol support vote.svg Support but I would go further and allow downloads of original MP4 files (but no streaming and no server-side transcoding into MP4 of any sort). I am not a patent lawyer, but I believe that merely copying a file around verbatim does not make use of a patent in any way. Here I think our goal of avoiding non-free file formats is outweighed by the fourth freedom: the "freedom to make changes and improvements". Video compression is lossy, and any editing should always take place on the original file. -- King of ♥ 19:55, 22 May 2020 (UTC)

Discussion for Proposal 2Edit

There is no advantage in "displaying" a mp4 that reusers cannot access, or viewers see. For this reason it's really the same as proposal 1 in my eyes, as the choice of whether to keep an original video in the filearchive is the same issue. -- (talk) 11:12, 8 November 2019 (UTC)

I think the implied difference is that under this proposal the MP4 files would more easily be made available for streaming and downloading in 2027 (once all the patents have expired), without requiring undeletion of all the source files. Kaldari (talk) 16:00, 12 November 2019 (UTC)
Also saving the file in a MediaWiki way, allows re-transcoding if there is some bug in the transcoding process or we need to transcode to new formats later like AV1 (Its always best to transcode from original where possible). Bawolff (talk) 02:49, 23 December 2019 (UTC)

Proposal 3: Use AV1 codec instead of VP9/VP8 as the main codec, (AV1 is new and better free codec)Edit

  • AV1 is a new and better free codec then VP9, AV1 can use WebM, mkv, and mp4 as a container.
  • It was developed as a successor to VP9 by the Alliance for Open Media (AOMedia).
  • Tests from Netflix showed that, based on measurements with PSNR and VMAF at 720p, AV1 was about 25% more efficient than VP9 (libvpx).
  • Similar conclusions with respect to quality were drawn from a test conducted by Moscow State University researchers, where VP9 was found to require 31% and HEVC 22% more bitrate than AV1 for the same level of quality.
  • Facebook showed about 40% bitrate savings over VP9 when using a constant quality encoding mode.

Votes for Proposal 3Edit

  • Symbol support vote.svg Support -- Eatcha (talk) 10:09, 8 November 2019 (UTC)
  • Symbol support vote.svg Support --D-Kuru (talk) 16:04, 5 January 2020 (UTC)
  • Symbol support vote.svg Support Victorgrigas (talk) 19:05, 11 February 2020 (UTC)
  • Symbol support vote.svg Support --Vulphere 03:00, 19 February 2020 (UTC)
  • Symbol support vote.svg Support Along with proposal 2. --pandakekok9 04:52, 11 March 2020 (UTC)
  • Symbol support vote.svg Support -FASTILY 22:21, 13 April 2020 (UTC)

Discussion for Proposal 3Edit

  • There is a lot of arguments here without any evidence. Masum Reza📞 10:20, 8 November 2019 (UTC)

@Masum Reza📞 Here you are:

There does not need to be a proposal agreed for this to proceed as a task on Phabricator. As this is a fairly technical point, and there may be operational issues that are not known here, but might be known to the Phabricator community, it makes sense to start the Phabricator discussion anyway. -- (talk) 11:11, 8 November 2019 (UTC)

  • I think this should be left to the multimedia devs to decide. There's lots of technical considerations involved (Client support, maturity of implementations, different performance requirements for encoding) as well as technical work that someone has to do to make it happen. Bawolff (talk) 02:16, 23 December 2019 (UTC). Addendum: I would add, I doubt this proposal would address the issue. Most users do not know what AV1 is, lack of AV1 support is not the reason we have few videos. Bawolff (talk) 02:54, 23 December 2019 (UTC)

Snowball per objections below MorganKevinJ(talk) 01:50, 20 November 2019 (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.

Proposal 4: Integrate any open-source video conversion suite inbuilt the commons android/IOS appEdit

  • It should facilitate the uploading of videos directly from smartphones, as users don't need to download an extra app to convert video. (It's gonna be very slow BTW, due to less processing power of phones)

Votes for Proposal 4Edit

  • Symbol support vote.svg Support -- Eatcha (talk) 10:10, 8 November 2019 (UTC)
  • Symbol oppose vote.svg Oppose Idea is good but we want high quality and not fast encoded content. That is not possible on mobile devices. Even on a high end desktop most encodings can not run in real time. --GPSLeo (talk) 09:46, 9 November 2019 (UTC)
  • Symbol oppose vote.svg Oppose I tried running this on OnePlus 7TP, and it can't even transcode the videos recorded using the device itself. And of course, you can fry eggs after transcoding 4K videos. Transcoding must be done on WMF servers. --Eatcha (talk) 15:15, 9 November 2019 (UTC)
  • Symbol oppose vote.svg Oppose Legal hell. (actually not so much "hell" as "it's going to cost millions of dollars in patent licensing") - Alexis Jazz ping plz 16:03, 9 November 2019 (UTC)

Discussion for Proposal 4Edit

Devolving processing to the client side may make sense, or not. I would like to see some trials of what the outcomes or (dis-)benefits to the user experience are. Expecting users to wait for an hour for a 4 minute video to be pre-processed and hogging resources on their phone during that time, would not be a workable scenario. -- (talk) 11:16, 8 November 2019 (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.

Wrap up the proposalEdit

The Proposal 2 was far accepted by the community, the 1 and 2 ca not coexist, so we can start the implementation of 2 by now.

The Proposal 3 is too aggressive, and can not talk to actual mobiles, they also do not cannibalise the proposal 2, with some acceptance of the community, can we set a date to it start in the future?

Eatcha can we close this proposal? -- Rodrigo Tetsuo Argenton m 22:26, 19 March 2020 (UTC)

There's nothing I can do, the proposal is indeed accepted by the community but WMF legal's stance is important, no one's going to start working on it till then, but video 2commons decodes the copyrighted format on wmf server maybe a community maintained API will do but I prefer a solution from WMF devs. // Eatcha (talk) 05:05, 20 March 2020 (UTC)

Category overdiffusion by dateEdit

Seeing the overdiffusion discussed in Commons:Categories for discussion/2019/06/Category:Mausoleum of Queen Arwa bint Ahmad Al-Suhayli by year made me cringe. Overdiffusion has been discussed previously (2018, 2019), but there has never been a follow-up. My main issue is the overdiffusion by date: a building will rarely look any different a year later so I really do not see the point of grouping pictures based on when they were taken. Yet there still are proponents of highly specific by-date categorisation and it has already rooted firmly into our category structures, so it will be very difficult to fix it. As a compromise, can we please at least codify that by-date categories should always be accompanied by its date-free counterpart or date-free subcategory thereof? --HyperGaruda (talk) 20:36, 29 February 2020 (UTC)

Overdiffusion votesEdit

  • Symbol support vote.svg Support as proposer. --HyperGaruda (talk) 20:36, 29 February 2020 (UTC)
  • Symbol support vote.svg Support I'm not happy to compromise on uch an obvious issue, but if there is no way of getting rid of the unwarranted by-date categories, it's a helpful initiative. --Jonund (talk) 15:49, 1 March 2020 (UTC)
  • Symbol support vote.svg Support I don't find these "buildings by year" categories helpful at all. -- Deadstar (msg) 16:50, 1 March 2020 (UTC)
  • Symbol oppose vote.svg Oppose: Certainly there’s many “cringe”-worthy cases of bad categorization one could find (lovely collegial tone, too), but as it is this proposal is one more deletionist wikilawyering attempt. Define “overdiffusion” first, in a clear manner (akin to that of overcategorization), one that can be approved by wide community consensus. (Question number 1: What is overdiffusion, as opposed to regular diffusion?) Only after that can the problem, if there’s one, be addressed. -- Tuválkin 17:04, 1 March 2020 (UTC)
    • (oh, this again) “overdiffusion” is not defined. Files pertaining to a given year should be categorized as such. If other characteristics of the file or its contents, other than date, get lost by categorizing by year, then create other categorization subtrees, instead of undoing the work already done. If someone wants an overview, create a gallery. If this proposal is meant to mean «use common sense and do no create date-cats prematurely», then word it as such instead of allowing that sensible original motivation to be hijacked by those who think that the ideal number of categories is zero because wikidata and intersection and deep search and other bogus reasons. -- Tuválkin 01:55, 24 March 2020 (UTC)
  • Symbol support vote.svg Support Such over-categorization makes it impossible to find anything on Commons. Kaldari (talk) 02:54, 2 March 2020 (UTC)
  • Symbol neutral vote.svg Neutral These categories might be sometimes useful (for example, if I know I have taken a picture of the building on a certain day I can relatively easily find it), but I do not see any reason why these categories should not be hidden.--Ymblanter (talk) 06:45, 2 March 2020 (UTC)
  • Symbol oppose vote.svg Oppose, while I can understand that not every building changes every year, major renovations and remodeling are a thing and buildings that retain the same address can change ownership and both exterior and interior decorative styles over the years. If a re-user is looking for Images of a certain building when it was owned by Company X and not Company Y or because a large part of it was damaged because of some natural disaster and had later been remodeled then these categories are very helpful. Images which basically contain the exact same building but with little difference 5 (five) years later or earlier can already be deleted if they don't add anything educationally of value on their own. These categories furthermore prevent the overpopulation of certain categories like "[Year] in Chicago" by narrowing it down and therefore makes it easier for re-users to find images. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:26, 6 March 2020 (UTC)
You make it sound as if I was proposing to entirely do away with date-based categories, which I am not. --HyperGaruda (talk) 06:58, 7 March 2020 (UTC)
  • Symbol support vote.svg Support except in cases where we have literally 100+ images in many of the resulting categories. And even then this should typically not be the only axis of diffusion, and it shouldn't be intersected with the others. -- Jmabel ! talk 16:58, 18 March 2020 (UTC)
  • Symbol support vote.svg Support Most cases I've seen like this (particularly with people by year) are ridiculous. Keep it simple please, and avoid this type of category unless it's *really* necessary. Thanks. Mike Peel (talk) 10:28, 24 March 2020 (UTC)
  • (Oh, the word "ridiculous", yet another token of collegiality and good faith.) Categories that categorize people by year intersect with Category:nn-year old humans; it’s better than categorization of individual files when there is enough of them — which is the case. -- Tuválkin 14:16, 28 April 2020 (UTC)
  • Symbol support vote.svg Support: In general, intersection is a thing that can and should be done by software. If one day the UI will provide this feature in a reasonable manner we will get rid of millions of obsolete categories. However, I'm not sure if that will happen during my lifetime... --Achim (talk) 19:50, 25 March 2020 (UTC)
  • You’re supporting the destruction, now, of something you (wrongly) think will be made obsolete in a far future? Why? -- Tuválkin 14:16, 28 April 2020 (UTC)
  • Symbol support vote.svg Support but this doesn't solve the underlying issue, which is categories existing when they shouldn't. We should prohibit by-date subcategories of static subjects unless they reach a certain size. -- King of ♠ 05:06, 21 April 2020 (UTC)
    "Prohibit" is another warm and fuzzy word. And what would the penalty be against such prohibition? -- Tuválkin 14:16, 28 April 2020 (UTC)
    Actually, I Symbol oppose vote.svg Oppose this proposal, even though I agree with the general sentiment that overdiffusion is a problem. I do not believe that by-date categories should be always accompanied by date-free categories, as in my opinion for a building that doesn't change over time, the sole reason for by-date categories to exist is for the purpose of diffusion. Either a building is the Eiffel Tower and we diffuse completely (i.e. the main category should ideally contain no images), or the building is not so popular and we don't diffuse by date at all. In response to your question: The "penalty" would be that overdiffused subcategories get nominated for deletion. -- King of ♥ 22:09, 23 May 2020 (UTC)
  • Oppose The general proposal. I think the system worked in that people say it as too overly categorized, took it for deletion and discussed it there. I don't think a general rule is warranted. If there was a general rule, then I would say we revise Commons policy so that it's something like "by year if you have more than 10 or else by decade or by century" or something general. It's the same with the maps discussion below. -- Ricky81682 (talk) 01:57, 22 May 2020 (UTC)

Overdiffusion discussionEdit

Case in point: Category:Jacob Riis Park by year. I can see separating out the year there were 450 photos (though I bet something else about them characterized WHY there were 450 photos that year, but one of these categories has all of 5 photos. - Jmabel ! talk 04:00, 28 March 2020 (UTC)

One person took a lot of photos. We should happy we have that. Otherwise, we would have all 450 photos in both Category:2018 in New York City (they are already in the month subcategories) and in Category:Jacob Riis Park. Separating out that year means that both parent categories are a little more organized. The five photographs may be too small but I think we need a broader discussion on categorization in general. -- Ricky81682 (talk) 02:03, 22 May 2020 (UTC)

Where to codify thisEdit

Overdiffusion wordingEdit

Problem with that is that is would invoke COM:OVERCAT, of which I am no great fan, and someone WILL come along and remove it from Category:Great Mosque of Mecca, citing that policy. Rodhullandemu (talk) 12:27, 1 March 2020 (UTC)
As you put it, I guess my proposal is indeed a request for adding an exception to the overcategorisation rule. I believe, however, it is more annoying having to browse through Category:Great Mosque of Mecca by year and all its sub(sub)categories (53 pages in total!) in an attempt to find pictures of, say, its minarets. --HyperGaruda (talk) 13:31, 1 March 2020 (UTC)
  • Per what I've said in the "old maps" section immediately below, how about:

Specific "... by year" categories bring a risk of overdiffusion, making images on a particular subject harder to find and harder to view together. Such categories should not normally be created, unless they bring together images of more than one different subject, that each have their own time-independent category.

I think this wording would help promote the existence of time-independent narrower subject categories, which I agree are to be encouraged (when there are enough images to fill them). Jheald (talk) 18:24, 1 March 2020 (UTC)
  • @HyperGaruda: Like Themightyquill, I'm undecided. Indeed, hiding content into thousands of small pidgeonholes (like, say, Category:June 2016 in Moscow with >1000 files) has more flaws than benefits. But taking your proposal literally, all files in this category should be piled up to Category:Moscow, which then will become impractically huge. So what works for a smaller (speaking only of file count) subject scope will not work for larger items. There should be some line drawn, but where and how? Retired electrician (talk) 08:53, 28 April 2020 (UTC)
Or, if the problem is the fact that some files might be categorized only with something like Category:June 2016 in Moscow and no other cat, then the solution is not to attack that single categorization, which is valid, to make it less useful, but to complement it with more categorization, as in the stork example above.
The solution is not to combat “overdiffusion”, which is a false problem — the real problem is a relative lack of categorization depth, when a file was subjected to more detailed categorization concerning one of its categorizable aspects and less so or none at all concerning others. That problem needs to be addressed — which is mostly done by curation work, not by wikilawyering proposals of new rules and their wording.
Overdiffusion is, at best, a red herring, and those even considering it are, again at best, misinformed about Commons categorization. -- Tuválkin 20:21, 29 April 2020 (UTC)
@Retired electrician: the problem is indeed as Tuaválkin described, where some images are only categorised by date. The example file however, already has other categories and subcategories of Category:Moscow, so there is no need for it to be in Category:Moscow as well. What I try to achieve with this proposal is to "force", if you will, people who add only a date category to also include something directly related to what is depicted. --HyperGaruda (talk) 18:47, 2 May 2020 (UTC)

Old maps of ... by yearEdit

  • I certainly see this issue with Old Maps. In most cases the most useful grouping for old maps is to bring together maps that all cover the same area, regardless of the exact year when they may have been created -- so one can see at a glance how the portrayal developed of the same subject, often over centuries, and so that one can find all those maps together, in the one category, ideally sorted into date order. Breaking out the maps on a single subject into a myriad multitude of subcategories "by year" (cf: Category:Maps of Hamburg by year) is a menace, and should be banned.
There may be a case for a separate category showing all the maps together from across a number of subjects that were created in a single year. I am not 100% convinced by this -- I suspect that kind of search will soon be handled by an SDC search, rather than a purpose-built category.
I would back a rule to say that "by year" categories should only be allowed if they bring together images of multiple different subjects taken in a particular year (where the different subjects each have their own specific categories, not "by year"). Images of a single subject -- eg a particular building, or a maps of particular defined region -- should have a specific time-independent category, which should not be split down by year unless it has become very full. Jheald (talk) 17:54, 1 March 2020 (UTC)
However, pinging @AnRo0002:, who has created a number of these categories for "Old maps of ... by year", and may take a different view. For myself I would burn almost all of these "by year" categories down. Jheald (talk) 17:57, 1 March 2020 (UTC)
Also pinging @Aeroid: who's made some of these. Jheald (talk) 18:16, 1 March 2020 (UTC)
New to this topic, sorry. Yes, categorizing the Hamburg Maps was quite some work. The problem was, that after an import the Hamburg Maps category had hundreds of maps, most of them in two versions and many also in more than these two. This was the easiest way to bring these groups of the same map together and I hoped this would help also in the future. I just followed some pre-existing categories and nav-bars which looked to me like a good idea. If this is problematic, I would like to understand what you would suggest to not have hundreds of maps of hamburg filling up one category. --Aeroid (talk) 20:10, 1 March 2020 (UTC)
@Aeroid: Where we have hundreds of maps of a place like Hamburg, I would first split by what they show -- do they show the whole of Hamburg, or only specific parts? Where they show eg the whole of Hamburg, I would order them by date created (I have a script that can help to do this), but leave them in the one category, so that they can be browsed and the sequence can be understood. So long as they show the same subject and are ordered in the category in sequence, a category size of two to three hundred maps is quite readily navigable, and far preferable to two to three hundred different categories. If the category still contains too many maps, then I would consider splitting by century. But I would be very reluctant to split more by time than absolutely necessary. To me splitting by subject makes more sense (while at the same time also having categories for specific atlases or map series that belong together. Jheald (talk) 20:36, 1 March 2020 (UTC)

Jheald describes one use-case. But there are others, orthogonal to it - for instance, someone may be researching "Hamburg in the 18th century". A solution my be to categorise by date and to have an "all old maps of Hamburg" category.

Or we could rely on well-applied sturctured data ;-) Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:23, 1 March 2020 (UTC)

@Pigsonthewing: I think the "Hamburg in the 18th century" case is quite well achieved when the maps are ordered by date, so that someone can just scroll through the category to then find all of the 18th century maps together. (Note that per the usual rubric, one would expect to find later maps depicting Hamburg as it was at an earlier date in c:Old maps of the history of Hamburg, etc.) What I don't think helps someone researching "Hamburg in the 18th century" is if they have to separately work through c:Category:1702 maps of Hamburg, c:Category:1705 maps of Hamburg, c:Category:1716 maps of Hamburg, c:Category:1720 maps of Hamburg, etc, each one only containing a single or a couple of images.
As for SDC, SDC searches will come in time. But I for one don't think they will ever fully replace the ease of clicking and browsing pre-curated categories. SDC may turn out to help a lot in making categories more fully comprehensive though. Jheald (talk) 21:37, 1 March 2020 (UTC)
I value the additional discoverability quite high. Note the additional use cases supported by the higher level categories like c:Category:1858 maps of Germany and c:Category:1858 maps of Europe inherited from categorizing it as c:Category:1858 maps of Hamburg and the different nav-bar that make this image discoverable. It becomes easy to find an adjaced map of SH in the same year.
Your "browsing" use case could well work if the UI had a capability to expand categories to images similiar to the categories that unfold subcategories on a categorie page.--Aeroid (talk) 09:01, 2 March 2020 (UTC)

2020 Wikimedia Commons' month of kindnessEdit

This project is an educational resource, a potential source of factual media and an outlet for many volunteers to contribute to something meaningful outside of our daily lives. Given that everyone is affected by the Covid-19 pandemic, some of us even living under government restrictions on movement, it is proposed that this April is our project's month of kindness.

Though many of us enjoy doing maintenance tasks and debating copyright issues and policies, this does not mean that we cannot achieve the same project goals without ever stopping being kind to others.

So, how about it? For the next month, we put away sarcasm, jokes at the expense of others, respond to the irritability of others with support, and think twice before pressing the "Publish" button. We can even ask for a site notice to run throughout April reminding us to make extra effort to be kinder in our actions. -- (talk) 12:47, 12 March 2020 (UTC)

See closing section, it may be appropriate to choose July instead of April. -- (talk) 17:32, 30 April 2020 (UTC)

Votes, month of kindnessEdit

  • Symbol support vote.svg Support as proposer. -- (talk) 12:50, 12 March 2020 (UTC)
  • Symbol support vote.svg Support a month of finding a reason to help, encourage, and support ever contributor is a fabulous idea... Gnangarra 13:13, 12 March 2020 (UTC)
  • Symbol support vote.svg Support That would be a change! --Ruthven (msg) 13:32, 12 March 2020 (UTC)
  • Symbol support vote.svg Support The GNU Kind communication guidelines can be a useful read as well. Nemo 14:16, 12 March 2020 (UTC)
  • Symbol support vote.svg Support, although I think that we should always try to be kind to each other, let's not forget that what some people experience as an attack may have been meant in good faith. But I do think that in general we should have "a welcome committee", especially for new users who have only uploaded copyright violations, these users usually get walls filled with threatening warnings and deletion requests, maybe having a special group of people dedicated to give them case studies and encouraging what files are allowed to be uploaded, how Freedom of Panorama (FoP) works, how you can recognise that an image from a website is freely useable (for example explaining that not all Creative Commons licenses are compatible with Wikimedia Commons), and other solutions directed at the individual and how they can both use and contribute to Wikimedia Commons. I believe that we should try to welcome users more with kindness, so we could have a higher editor retention rate. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 16:11, 12 March 2020 (UTC)
  • Symbol support vote.svg Support Ainali (talk) 19:53, 12 March 2020 (UTC)
  • Symbol oppose vote.svg Oppose to the non-implementation of this proposal. --pandakekok9 09:08, 14 March 2020 (UTC)
  • GA candidate.svg Weak support To put away sarcasm, jokes at the expense of others, respond to the irritability of others with support, and think twice before pressing the "Publish" button is a good recommendation for all the year round, but on the other hand, declaring a single month as "month of kindness" might seem contrived, forced, and also implying that we otherwise aren't kind. In my experience, most people here are kind enough all the time; and I'm not sure that those who are unreformable grumblers and grinches will react well to such a declaration. Gestumblindi (talk) 19:25, 14 March 2020 (UTC)
  • Symbol oppose vote.svg Oppose This should be normal behaviour, if it isn't then that needs to be fixed in the longer term, not just for a month. Thanks. Mike Peel (talk) 19:46, 14 March 2020 (UTC)
  • Symbol support vote.svg Support We should be grateful all year long but it's nice to have Thanksgiving to remind us. Similarly with charity and Christmas or romantic love and Valentine's. Sounds like a good theme. I will say that launching something like this on April 1 is a bad idea, tho. —Justin (koavf)TCM 20:14, 14 March 2020 (UTC)
  • Symbol support vote.svg Support as Mike Peel mentions, this should be normal behaviour, but maybe it could stimulate certain contributors :-) Lotje (talk) 07:30, 15 March 2020 (UTC)
  • Symbol support vote.svg Support // Eatcha (talk) 02:55, 23 March 2020 (UTC)
  • Symbol support vote.svg Support This feels really corny, but probably what Commons will need in April. Abzeronow (talk) 20:04, 28 March 2020 (UTC)
  • Symbol support vote.svg Support.--Vulphere 10:02, 15 April 2020 (UTC)

Discussion, month of kindnessEdit

  • Let's brainstorm how to implement this better, maybe we could add more kinder wording to some templates, like we could keep a notice of copyright violation in its entirety, but sithen add a small statement like "If you have any questions about how copyright works you can ask me (with an explanation of how pinging and replying works) or visit the copyright village pump". Maybe this month can also be dedicated to create more user-friendly tools and we can host a contest where those that develop tools that help users with certain problems can benefit. Kindness is more than just being nice, it's also trying to prevent future conflicts. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 16:16, 12 March 2020 (UTC)
Category:Talk page trimmer is something you add your talk page to now. It trims down shouty deletion notices and copyvio notices to the bare minimum. Many folks have said they find these large standard but shouty notices unnecessarily hostile.
A different option could be to have an initial full notice, but then intelligently add further notices about the same thing in an automatically shorter form that avoids being a "warning" or looking like "escalation" but more a "notification". -- (talk) 16:24, 12 March 2020 (UTC)
I am personally not a fan of the trimmer, but do understand why some people like it. But if a user had had less than 1000 (one-thousand), or possibly less than 10 previous DR or copyright notices, edits it may automatically add a notice for where they can learn more about copyright, the project scope, Etc. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 16:55, 12 March 2020 (UTC)
  • I'll suffer physical problems if I can't use sarcasm. Besides that, I try to treat everyone with the respect they deserve all year round. - Alexis Jazz ping plz 16:59, 12 March 2020 (UTC)
    • Perhaps for April, you could take extra caution to keep the sarcasm to those that realise it's not meant to be unkind and maybe where there is not a peanut gallery that might misuse it? -- (talk) 17:20, 12 March 2020 (UTC)
      • I may need a wikibreak soon anyway, but I'm not sure it'll coincide completely with April. - Alexis Jazz ping plz 17:34, 12 March 2020 (UTC)
  • If I might make a recommendation: Rather than a sitenotice, perhaps an editnotice on all talk namespaces would be more helpful. --Yair rand (talk) 21:06, 12 March 2020 (UTC)
  • No objections to this idea, but I oppose to a site-notice. I just can't understand it. 4nn1l2 (talk) 00:49, 13 March 2020 (UTC)
  • How about we revive Commons:Silly things as a start? :) And maybe we should prepare the best April Fools for this year. pandakekok9 09:15, 14 March 2020 (UTC)
    And maybe use the month of April to encourage the use of the thanks feature and WikiLove (I already have one photographer in mind to give a barnstar). pandakekok9 09:18, 14 March 2020 (UTC)
  • What about a Wiki Loves silliness and encourage funny photos, that meet scope and promote them to the main page, lets laugh a bit Gnangarra 03:01, 18 March 2020 (UTC)
Yeah, let's make Commons:Silly things great again! :D And make it daily for that month, instead of weekly. pandakekok9 03:47, 18 March 2020 (UTC)

Closing and next actions for "the kindness project"Edit

As the vote has been open for 16 days with supermajority support, and we need a bit of time to take any actions, I suggest we discuss the closure. If the implementation is in a week's time (4 April) this neatly skips the potential for misuse for April Fool's jokes and gives sufficient time to get some feedback on the wording of any notice(s).

As suggested in the discussion, the addition of an edit notice may be more useful than a site notice, in particular as edit notices only get seen by editors, not readers. Other thoughts welcome! -- (talk) 20:21, 28 March 2020 (UTC)

Any suggestions as to what month this would best run as April is now ending? It may be an idea to pick July, as there are a number of celebrations that may not be happening in 'real-life' but help foster goodwill (Pride, Independence, etc.) -- (talk) 16:03, 30 April 2020 (UTC)

Photographs of established academics, writers, artists are in scopeEdit

There is significant debate and muddying the waters caused by deletions of photographs of people because they might not meet Wikipedia's more stringent definitions of notability. It is proposed that to reduce uncertainty, COM:Scope is interpreted by the following "norms":

  • Photographs of University academics either a faculty member in full-time tenure as a lecturer or researcher, or where they work under time-limited project contracts but are reasonably established by their peer-reviewed and independently cited publications in their field, are of educational value.
  • Photographs of writers or journalists of any kind with a track record of referenced publications that can be rationalized as having a reasonable public footprint or impact, are of educational value.
  • Photographs of artists including photographers and performance artists who are well established in their field, for example with a track record of gallery exhibitions, catalogues of their works, formal public recognition of their works through independent reviews or prizes, or non-trivial sales of their works are of educational value.

The understanding on Wikimedia Commons of "educational value" is only related to any decisions on sister projects against their local policies on notability, by anyone meeting those separate notability policies will always be in scope on Commons. The decision of whether photographs of people are in-scope on Commons is based on educational value and this value is assessed independently of article or media deletions on sister projects.

Reference previous discussion Commons:Village pump/Archive/2020/02#Would photos of university faculty members be accepted. -- (talk) 12:18, 17 March 2020 (UTC)

Votes (established academics, writers, artists)Edit

  • Symbol support vote.svg Support as proposer. -- (talk) 12:22, 17 March 2020 (UTC)
  • Symbol oppose vote.svg Oppose extending COM:SCOPE here beyond "used in a Wikimedia project". I note, that it may be automatically extended if Google Scholar or a similar database is imported into Wikidata. But this did not happen yet. Ankry (talk) 12:46, 17 March 2020 (UTC)
Nothing in this proposal is not already covered by Scope (explicitly "freely-licensed educational media"). That you appear to be limiting this project's scope only to photographs of use to Wikipedia is a misunderstanding of Scope. -- (talk) 12:48, 17 March 2020 (UTC)
This contradicts my understanding of educational purpose. Personal photos of non-notable people are unlikely to be useful in any educational process. So assuming that being a faculty member or a writer who write a single book makes somebody automatically notable is not a good idea, IMO. This activity may be accidental, people change their job and ask us later to remove their image from Commons for privacy reasons. My position is that if we cannot be sure that we will be able to keep an image permanently, we should not allow to upload it. Ankry (talk) 07:03, 18 March 2020 (UTC)
  • Symbol support vote.svg Support Would be certainly be useful in clarifying Common's scope policy. Abzeronow (talk) 14:42, 17 March 2020 (UTC)
  • Symbol oppose vote.svg Oppose I believe that the enwiki essay en:WP:CREEP is useful here. If something merits an article on any project it is already in scope here. Adding additional lines is pointless and unnecessary. If they don't merit an article, having a picture of them doesn't serve our purpose at all. We aren't a repository for random photos. --Majora (talk) 20:31, 17 March 2020 (UTC)
@Majora: I would add to that/clarify that the "something" only needs to merit an article or Wikidata item. It doesn't actually need to have one. If/when the article/item is created, the photo can be added to it. Our actual scope is even more broad, but for the sake of simplicity I'm omitting some things. - Alexis Jazz ping plz 21:20, 17 March 2020 (UTC)
That is a fair point, Alexis. Most of what Fae wants to add to the scope page already merits an article on some other project. If we just follow our own guideline as it is already written there shouldn't be a problem. If a deletion occurs on scope grounds that you think shouldn't have happened please request undeletion. Scope DRs are some of the hardest ones admins have to deal with. Especially when there isn't additional comments besides the nominator. I expect us to make mistakes from time to time on such things. --Majora (talk) 21:34, 17 March 2020 (UTC)
  • Symbol support vote.svg Support, although what the definition of "Established" is can vary from person to person, and while someone living in Bumfrick, USA might believe that Singy McSingface is an "established artist" because they're really famous in their village or hamlet, people from the village over might have never heard of them. This system can very, very easily be abused. On the other hand, many upcoming writers, artists, and academics may have free images of themselves available right now that may be deleted from the internet tomorrow and could have been imported today. There are many reasons why this should and shouldn't be adopted, but I am leaning more towards a support simply because it will be more inclusive towards the global academic community and the benefits outweigh the deficits. Very straightforward and would make it easier for people to identify who is and isn't within scope. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:06, 17 March 2020 (UTC)
  • Pictogram voting comment.svg Comment I think all cases mentioned fit the Wikidata notability guidelines and so the photos are in scope as "The aim of Wikimedia Commons is to provide a media file repository: that acts as a common repository for the various projects of the Wikimedia Foundation.". --GPSLeo (talk) 22:14, 17 March 2020 (UTC)
  • Symbol support vote.svg Support + politicians including local authorities + sportspeople. 4nn1l2 (talk) 16:25, 18 March 2020 (UTC)
@4nn1l2: that's why I think we need a more broad rule, if we need one at all. I don't like specifying all these groups. What about YouTubers? (or are those covered by artists?) TV personalities? CEOs of major companies? If the subject is eligible for a Wikidata item or could be used in (a section of) an article that would be within the scope of another project, regardless of whether or not that item or article actually exists in the present, the file should be kept. - Alexis Jazz ping plz 17:56, 18 March 2020 (UTC)
@Alexis Jazz:, here is the notability policy of d:Wikidata:Notability. I don't see anything useful there. Is "clearly identifiable conceptual or material entity" useful enough? If so, let's write it here on Commons and stop depending on Wikidata. I agree with a very broad interpretation of SCOPE. We only need to delete images of "nobodies". Some Wikipedians come here and nominate images of a recently-deleted Wikipedia article for deletion here at Commons. I don't think we should honor such requests. 4nn1l2 (talk) 03:43, 19 March 2020 (UTC)
@4nn1l2: the full quote is "It refers to an instance of a clearly identifiable conceptual or material entity. The entity must be notable, in the sense that it can be described using serious and publicly available references." and that's quite good, it may even roughly match Commons scope. Some random files:
Yeah, seems quite good. - Alexis Jazz ping plz 18:35, 19 March 2020 (UTC)
  • Symbol oppose vote.svg Oppose the job titles provided are not globally defined, making this proposal very open to interpretation. Besides, any person who is "well established in their field" will be mentioned or have their page on another project.--BevinKacon (talk) 20:25, 18 March 2020 (UTC)
Not necessarily. w:Vivian Stephens, an African-American romance author only got a English Wikipedia page this year despite being a founder of the w:Romance Writers of America, one of the largest writing organizations in America. Stephens should have gotten a Wikipedia page 10 years ago! I think clarifying the guidelines to include established writers, artists and University professors is a step in the right direction, as it further reinforces that we are not an annex of Wikipedia, but a peer project of Wikipedia. Abzeronow (talk) 17:56, 19 March 2020 (UTC)
  • Symbol support vote.svg Support such photographs could be very useful for people writing articles in magazines, local newspapers etc. But the possible usage such pictures (as mentioned by Fae) isn't obvious for everyone. Therefor it's best to spell it out. Natuur12 (talk) 23:23, 20 March 2020 (UTC)
  • Symbol oppose vote.svg Oppose: As per Majora. The existing policy already covers such cases sufficiently and the proposal unnecessarily bloats our guidelines. Also, if despite of the danger of excessive formalization and bureaucracy the aim is to create more specific definitions of what is considered educationally useful than what we already have, one should at least be consistent and do this for every notable profession, every notable type of object, every notable event. Spelling out details for only very few particular professions, but not for the majority of other notable professions, seems rather random and is in my opinion not helpful. GFJ (talk) 22:25, 22 March 2020 (UTC)
  • Symbol support vote.svg Support Per Fæ, commons shouldn't follow Wikipedia. Curating media files is different than writing an encyclopedia. // Eatcha (talk) 02:54, 23 March 2020 (UTC)
  • Symbol neutral vote.svg Neutral I think the current form of COM:SCOPE is enough to cover such things. We can always use COM:DR to establish a consensus on interpreting COM:SCOPE. I won't mind though if this proposal passes, but it should be broader per 4nn1l2. --pandakekok9 02:10, 24 March 2020 (UTC)
  • Symbol support vote.svg Support The general principle of it, the listed photographs are already in scope, I would never think of nominating anything like that for deletion, unless there is some other problem (copyright, etc). However, I think that listing several accepted photographs can be misleading to some admins, who haven't familiarised themselves with the scope of the project, they may start deleting other in scope photographs with "Not in the list of acceptable media" or something like that as a rationale. I am unsure how to make it clear that this is a non-exhaustive list, since it may be that the misunderstanding is often intentional. ℺ Gone Postal ( ) 10:48, 24 March 2020 (UTC)
  • Symbol neutral vote.svg Neutral I think the current form of COM:SCOPE is enough to cover all those examples. I would Symbol support vote.svg Support adding them as examples, but I agree with User:Gone_Postal that we do not want to make scope more restrictive for files not on the list. --Jarekt (talk) 17:39, 25 March 2020 (UTC)
  • Symbol oppose vote.svg Oppose Can we please not start creating lists of individual subjects that are or are not in scope? COM:SCOPE is short and concise and I'd hate to see it turn into another de:WP:RK. Our rule is Must be realistically useful for an educational purpose. When something is used on a Wikipedia, that implies that it is educationally useful. Something not being used on any Wikipedia means nothing. Keep in mind that there are many language versions of Wikipedia, there are many other sister Projects and there are many, many non-Wikimedia educational Projects that benefit from us providing media files. Something not being considered "notable" on en.WP doesn't mean much. --El Grafo (talk) 11:28, 30 March 2020 (UTC)
It may seem weird, but "Something not being used on any Wikipedia means nothing" is not how COM:Scope is being interpreted right now, even by some administrators and bureaucrats. An article deletion on the English Wikipedia is being used as a reason to delete perfectly in scope files of these types from Commons; that's "something" rather than "nothing". -- (talk) 11:44, 30 March 2020 (UTC)
If that's the problem we're trying to solve, shouldn't we amend COM:SCOPE to make that rule more explicit instead of adding an exception for a very small subset of files? (Personally I think that is already quite clear, and if the document is being ignored, amending it will not solve anything). – BMacZero (🗩) 16:39, 4 April 2020 (UTC)
  • Symbol oppose vote.svg Oppose per GFJ. – BMacZero (🗩) 16:39, 4 April 2020 (UTC)
  • Symbol oppose vote.svg Oppose per Majora, also per the concerns of Gone Postal. I would support adding one or two examples per Jarekt, though. Sebari – aka Srittau (talk) 09:56, 8 April 2020 (UTC)
  • Symbol support vote.svg Support make this explicit because there are obviously people who do not understand these are in scope and insist on Wikipedia-level notability. - Jmabel ! talk 22:30, 14 April 2020 (UTC)
  • Symbol support vote.svg Support. Educational value should be considered not only as educational value in our projects but an also in webs or books out of Commons. Closing DR's with the rational "in use" should be include also educational use out of our project. -- Geagea (talk) 01:59, 19 April 2020 (UTC)
  • Symbol neutral vote.svg Neutral I think we want to ensure that COM:SCOPE is sufficiently permissive, but listing it all out is going to be a mess. Soon we'll be making criteria about small-town mayors, members of the C-suite of a Fortune 500 company, etc. I think for starters, anyone who performs publicly in front of a large audience is in scope; so if you go to a conference, you can just upload the pictures you took of all the presenters without worrying about scope issues. Anyone who publishes a paper in a recognized journal should also be in scope; perhaps Wikimedia will decide to host open-access journals one day and it will be useful to link the authors to their pictures. Actually, a professional-quality photo of anyone (could be a portrait or a picture of them doing something) is in scope; it can be used to illustrate photographic techniques, the activity they are engaging in, w:Man, w:Woman, w:Boy, w:Girl, etc. It's the poorly taken selfies we want to keep out. -- King of ♠ 04:53, 21 April 2020 (UTC)
  • Symbol oppose vote.svg Oppose From en:Wikipedia:Keep it short and simple: "Keep rules and procedure pages simple and short, or else people will not read them, and may avoid the project." Thuresson (talk) 05:29, 1 May 2020 (UTC)

Discussion (established academics, writers, artists)Edit

  • I think this can include more cases, some mentioned above by 4nn1l2. Moreover, there are files of things other than people (e.g. free/below COM:TOO logos) that can fall within the project scope, and be used to illustrate a Wikipedia article or a Wikidata item in the future (or even now, in some cases). It might be better to encourage everyone to use common sense and determine if a file is likely to be used in another project, or to make this proposal broader. Sometimes, COM:SCOPE can be very tricky. Ahmadtalk 18:48, 23 March 2020 (UTC)

Computer-aided tagging tag in new tag propertyEdit

As there are many problems with the Computer-aided tagging tool but also with missing features with the federated Wikibase instances it would be the best to add and use a real "tag" property like people know from other platforms.

So the depicts property can remain with the best and most specific statements for later advanced querying and we have a very easy searchable tags.

Statements by the Computer-aided tagging tool should become added in the new "tag" property and not in the current depicts property. --GPSLeo (talk) 11:11, 29 April 2020 (UTC)

@GPSLeo: I think this is at least an interesting proposal that is worth thinking about. Have you tried to reach out to the StucturedData people to get some feedback? --El Grafo (talk) 09:34, 13 May 2020 (UTC)

This - very sensible - idea was put to "the StucturedData people" back in February; their response (in this diff) was:

"There's not really much of a response to give. The tool is built to aid users in tagging depicts statements. 'Feeding a different property' as you suggest defeats the purpose of the tool, and from what I can tell other users are not strongly backing your suggestion on the VP or this page. If there's a different conversation going on around your proposal where users are showing such strong support for an alternative property that I haven't seen, I'm happy to share that with the team if it will help change minds and show community support here."

Note that the current method is completely at odds with the consensus expressed at COM:DEPICTS. I've asked the same WMF staff, several times, to provide evidence of consensus for the model they apparently want us to adopt, and they've continually ignored that request. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:34, 19 May 2020 (UTC)

Theoretically it also would be possible to just use the depicts property as a tag property and create a new property for "exact item you see on the image" but depicts (P180) is not commons exclusive it is also used on Wikidata with the "most exact" meaning. --GPSLeo (talk) 10:20, 19 May 2020 (UTC)

Removal of DRbox when closing DRsEdit


{{DRbox}} can be seen on many archived DRs and they don't really do any good there. They take place and shift the focus from the actual discussion. I propose that it be included in the closing procedure to remove <noinclude>{{DRbox}}</noinclude>. Thoughts on this?Jonteemil (talk) 22:19, 29 April 2020 (UTC)

Good idea. I think DelReqHandler tool should be updated to remove the template when closing the discussion. Nonetheless, I created Commons:Bots/Requests/AhmadWikiBot 3 for this. I personally think removing it from closed DRs is pretty uncontroversial; when the discussion is closed, there is no need to add the deletion template to the file page, notify the uploader and/or add the DR to the daily log. Ahmadtalk 21:24, 30 April 2020 (UTC)
Thanks, the bot request looks good.Jonteemil (talk) 23:17, 30 April 2020 (UTC)
@Ahmad252: Since your bot task now was approved, the only thing left is updating Mediawiki:Gadget-DelReqHandler.js. Do you know how to do that?Jonteemil (talk) 07:51, 10 May 2020 (UTC)
I think that will take some time (because the tool should be smart enough not to remove the template from DRs that are still open). For now, I'll let it be; especially because I'm going to run the bot every month. I do, however, appreciate if anyone else is interested in adding this feature to the tool. Ahmadtalk 08:19, 10 May 2020 (UTC)

suggestion concernant ce fichier: File:COVID-19 Outbreak Hospitalized in France 13 Regions & DomTom.svgEdit

Bonjour Je voudrais faire une remarque sur la carte de France que vous éditez.

A- en haut à gauche le nombre de décès tient une très grande place qui ne se justifie pas. B- en haut à droite les nombres d'hospitalisés, en réanimation et guéris sont écrits en tout petit.

  C'est pratiquement illisible alors que la date tient une place énorme.

Pourquoi ne pas mettre le A à gauche où il y a plus de place et le B à droite ?

C- en bas à gauche il doit être possible de mettre ce tableau verticalement pour le rendre lisible.

Cette carte est très bien faite et vous pourriez la rendre encore plus lisible. Merci d'en tenir compte si possible. Cordialement

Henri DIDELLE —Preceding unsigned comment was added by 2A01:CB15:803D:D500:345B:9A4E:13:410E (talk) 14:27, 7 May 2020 (UTC)

This page is for discussing proposals relating to the operations, technical issues, and policies of Wikimedia Commons - I would suggest contacting the person who has been updating the file every day: @Antidote2020:. If it needs further discussion, that should probably take place either on the file's talk page or Andidote2020's. Storkk (talk) 14:40, 7 May 2020 (UTC)
@Henri Didelle : merci pour vos remarques et compliments, je vous invite à poursuivre ici → File talk:COVID-19 Outbreak Hospitalized in France 13 Regions & DomTom.svg. Antidote2020 (talk) 19:39, 7 May 2020 (UTC)

page proctectionEdit

Images that are sexual content are on Commons so that why we need to put some measurement to secure it we all know we are in 21st century and research is not limited so people young than the age of 18 will have access to these. We should but many opinion on ground to solve this problem. Some people can see this has a advantage to criticize Commons and discourage other from using it. We need to act fast let put idea on table. Tbiw (talk) 02:36, 13 May 2020 (UTC)

What does this have to do with site security? —Justin (koavf)TCM 03:03, 13 May 2020 (UTC)

Proposal: avoid excessive use of gender in diffusing categoriesEdit


Subcategories based on gender should be permitted for a profession if and only if one of the following applies:
  1. physical appearance is important to that profession (e.g. acting, modeling)
  2. gender is highly relevant to that profession for some other reason (e.g. vocalists; athletes in most competitive sports).

Besides professions, this should apply also to categories about affiliation with an institution or organization (e.g. members of the faculty of a particular college or university; alumni of a particular college or university; people associated with a particular newspaper or magazine) or receiving a particular award (e.g. Nobel laureates).

To be clear: categories about gender as such are fine (we certainly want to keep Category:Men by name and Category:Women by name); the issue is about intersecting and diffusing categories. And, as with any other category about people, categories about gender may be difffused by nationality and even subregional classification (e.g. U.S. states) is fine: e.g. there is no problem with Category:Women of the United Kingdom or Category:Men of Washington (state) .

Jmabel ! talk 01:12, 15 May 2020 (UTC)

Votes (gender categories)Edit

  • Symbol keep vote.svg Agree - I also find categories like that annoying. --Jarekt (talk) 01:34, 15 May 2020 (UTC)
  • Symbol support vote.svg Support per my comments at the previous thread. -- King of ♥ 02:11, 15 May 2020 (UTC)
  • Symbol support vote.svg Support Yes, yes, yes. There's no reason to have this type of intersection category. Pi.1415926535 (talk) 02:52, 15 May 2020 (UTC)
  • Symbol support vote.svg Support (obviously, as proposer) - Jmabel ! talk 04:14, 15 May 2020 (UTC)
  • Symbol support vote.svg Support TommyG (talk) 06:46, 15 May 2020 (UTC)
  • Support unless there is a good reason to categorise by gender, we shouldn't be doing. ~~ Alex Noble - talk 06:54, 15 May 2020 (UTC)
  • Symbol support vote.svg Support see previous discussion -- B2Belgium (talk) 08:22, 15 May 2020 (UTC)
  • Symbol oppose vote.svg Oppose a general guideline. Such decisions should be taken on a case-by-case basis.
Take Category:Female writers for example.
Does gender matter for writing as a profession? Maybe not. However, commons dont only serve commons but all wikis. Many wikis distinguish writers by gender: Category:Women writers (Q7944338). Their users might find it odd that the corresponding cat does not exist on commons. Deleting these cats might create unnecessary hurdles for both the categorising effort and finding media for use.--Roy17 (talk) 13:54, 15 May 2020 (UTC)
@Roy17: Do you have a different, perhaps looser, guideline to propose, or do you think that because of that example there should be no rule at all on this? - Jmabel ! talk 14:33, 15 May 2020 (UTC)
Writer is a very general topic and it encapsulates the problem of this proposal. lawyers, politicians, physicians, photographers... are some other common professions that come to mind. this proposal is gonna get rid of all of their subcats. then ppl are gonna ask, why some jobs are listed in Category:Women_by_occupation (or the men cat) while these most common ones are not?--Roy17 (talk) 14:45, 15 May 2020 (UTC)
  • Symbol oppose vote oversat.svg Strong oppose Without refining the categories to some extent you have a general pool that is too broad to be of any use. Your proposal to refine them by nationality is not based upon historical reality. 1) Nationality is a fairly recent development in the scheme of history. Prior to the development of national borders, people identified with their community and ethnic culture; 2) Women, did not have nationality in their own right in the majority of countries in the world until the 20th century (in France 1927, the US 1922-1940, in Canada 1940, in Britain (and most of their colonies) until 1948, etc.) In many instances, they became stateless if they divorced a foreign spouse, i.e. Maymie de Mena or even if their nationality was settled were still required to take on the residency of their spouse in various US states, see Patsy Mink, into the 1960s. In some countries women still do not have their own nationality; 3) Nationality has often changed by the whim of war or treaties, redrawing boundaries on a map with no relationship to the culture to which people identify. Communities, even movements, fought long hard battles to be recognized legally for their identifying ethnicity, gender, beliefs to be validated and protected by law by numerous "nations". Simply categorizing people by national boundaries diminishes the complexities of their existence and removes the context of their history; it also can reclassify people into a category to which they never identified except on paper. It impacts readers/searchers as well, by making it far more difficult to find the subjects they might be interested in reading about or adding a photograph to, as it has broadened the grouping so that it has become irrelevant. This and the one below are both IMO bad ideas. SusunW (talk) 17:31, 15 May 2020 (UTC)
  • Symbol support vote.svg Support While IMHO Commons usually should support category-equivalents for wikipedia articles (and "wikidata content items"), with regard to categories I do not think is strictly necessary to provide the equivalent here. If somewhere "a" wikipedia does an inconvenient categorization, Commons should not be required to replicate the same schema here. IMO occupation+nationality (meaning 'citizenship') should be generally avoided too (except maybe for sportspeople and the like) (using a broader notion of "significant country/region/place wrt that occupation wrt that person" instead), but that's not being discussed here. Commons categories are not intended to provide reading stuff. Women by occupation and Men by occupation categories might be deleted if they are a problem, hanging "female actors" and "male actors" only from "Actors" instead. Strakhov (talk) 18:31, 15 May 2020 (UTC)
  • Symbol oppose vote oversat.svg Strong oppose I don't understand why of this proposal. Just think on gender difference in sport. Susun explained very well why. --Camelia (talk) 19:41, 15 May 2020 (UTC)
    The proposal does cover and make an exemption for such cases. -- King of ♥ 20:18, 15 May 2020 (UTC)
Is not only about sport. In Italian Wikipedia we struggle for the categories splitted by gender from a while, as they, apart from a few exceptions, are not allowed. And every time we organize our events based on female professions, our mostly used "base" for articles to write / translate are the Commons categories (as Wikidata queries are not yet "accessible" for a lot of users). So, no, apart from the identity and women's recognition and equality reasons expressed by others, there is also a practical issue. For us would be a big problem. --Camelia (talk) 21:41, 16 May 2020 (UTC)
Wikidata & Listeriabot do a great job creating lists. IMHO keeping gendered categories in Commons in order to have articles to write in it.wikipedia... doesn't make much sense. Wikidata works much better for that. And it's pretty easy creating those lists. Strakhov (talk) 03:05, 17 May 2020 (UTC)
  • Symbol oppose vote.svg Oppose and — Strong oppose because a "hell no, are you out of your mind?" option isn't available. A broad general guideline is problematic for any number of reasons, and the one proposed above is absolutely horrible. Nationality per SusunW is a problem for all the reasons she lists, and "relevant in the profession" is nothing but ghettoization (pigeonholing people in only certain occupations opens another can of worms over whether "gender is highly relevant" in a category). This needs to be done on a case by case basis. Montanabw (talk) 19:47, 15 May 2020 (UTC)
    "Highly relevant to that profession" - as a subjective criterion, that means deciding on a case by case basis. What alternate criteria do you propose for guiding the "case by case" decision on whether to diffuse by gender? -- King of ♥ 20:18, 15 May 2020 (UTC)
    ”Case by case basis” is the default for all wiki discussions so doesn’t need special rules. The problem is your suggested limitations, which in practice become policy and getting exceptions is more drama-inducing than just leaving it well enough alone: I mean, are you serious that the criteria for diffusion should be “physical appearance is important to that profession (e.g. acting, modeling)“ and “gender is highly relevant to that profession” —two most unbelievably sexist criteria imaginable? You have got to be kidding! Montanabw (talk) 00:46, 16 May 2020 (UTC)
    Given that you've said "case by case basis", that implies that you do not believe that all professions should be diffused by gender. Can you give some examples of such professions, and why you would not diffuse them by gender? -- King of ♥ 04:10, 16 May 2020 (UTC)
    @Montanabw: You can try {{subst:User:Tuvalkin/Template:No way!}}… -- Tuválkin 01:00, 16 May 2020 (UTC)
  • Symbol oppose vote oversat.svg Strong oppose as per the many reasons given above. As someone who uses the Wikipedia categories regularly when creating off wiki discussions about women in various roles in life it would seriously limit my ability to work. When it is no longer necessary to talk about women's involvement in an area of life because equality has become so ingrained that it is a meaningless topic, then, and only then, should this topic be discussed again.Antiqueight (talk) 20:29, 15 May 2020 (UTC)
  • Symbol oppose vote oversat.svg Strong oppose per the solid reasons already mentioned. --Rosiestep (talk) 23:10, 15 May 2020 (UTC)
  • Symbol oppose vote oversat.svg Strong oppose I've been working on List of African-American women in medicine and it's already hard enough finding good photos for article like these. I can't imagine how much worse it would be if I had to sort through all of the images of doctors/nurses/midwives/PAs just to find what I need for these kinds of articles. There's no stigma is separating categories by gender, race or any other valid criteria. Leave things as they are. As a librarian, I would like to mention that even cataloging conventions for libraries have categories for gender, race, etc. It's professional and necessary. Megalibrarygirl (talk) 00:17, 16 May 2020 (UTC)
  • I Symbol oppose vote.svg oppose, too. E.g.: When I created Category:Female tram drivers, and pretty much every time I add one more file to it, I wonder how useful / empowering / clarifying it is, versus how objectifying / segregating / exotifying it may also be felt. My goal was/is to illustrate a detail aspect of reality, as with any other category, but also to very clearly exemplify how women not only could, but actually can — do a “man’s job”. I am glad to add my vote to that of a few fellow female editors above. -- Tuválkin 00:41, 16 May 2020 (UTC)
  • Symbol oppose vote.svg Oppose I had read the previous discussion, and I'd say this proposal has good intentions (especially the LGBT part). However, I agree with the opposers above. Such problem can't be solved by a very broad proposal. It should be dealt with in a case-by-case basis via CfD. If only CfDs are more active and closed more often... --pandakekok9 01:54, 16 May 2020 (UTC)
  • Symbol oppose vote.svg Oppose for the reasons already given above, as they've stated things better than I ever could. I especially echo Antiqueight statement on equality. Huntster (t @ c) 07:11, 16 May 2020 (UTC)
  • Symbol support vote.svg Support soft Symbol oppose vote.svg Oppose These diffusing categories are messy and generally unnecessary, this move is needed. Having taken a beat, I think this move could be made for some categorisations, but as a swift and unilateral move like this it might be too clumsy and cause too much unintended consequences that would swamp any perceived benefits. Smirkybec (talk) 10:14, 18 May 2020 (UTC)
  • Symbol oppose vote.svg Oppose, strongly. This isn't about branding people, rather about search instruments. The proposal will remove a search instrument which, I am sure, is important to the reusers of content. People who come here for "stock photos" are looking for red brick buildings, yellow brick roads, and women operating pneumatic hammers. That's normal, especially given today's emphasis on "equal representation" of sexes in the media. Why discourage these specific searches by hiding Rosie the Riveter among many men? Retired electrician (talk) 10:54, 18 May 2020 (UTC)
    I guess the thing is, it is useful to have separate categories for men and women at work. What is not useful IMO is classifying portraits of people, who happen to be of an occupation but not actually depicting them engaging in that occupation, separately by male and female. -- King of ♥ 17:14, 18 May 2020 (UTC)
    @King of Hearts: That's precisely the kind of reasoning that I oppose. Reusers of free content don't seek "any" portraits, they have specific demands, they have already "painted the portrait" of what they need. They look for, say, bearded men wearing high hats or curvy blondes wearing ... where was I... never mind. The point is, sex - being probably the most important facet of human appearance, - is a valid and needed search criteria. Unconditionally, regardless of "depicting them engaging" or not. Retired electrician (talk) 11:37, 22 May 2020 (UTC)
  • Symbol support vote.svg Support - Dividing most people-related categories by male, female, non-binary, etc. is pointless and arbitrary. We don't do this for race or age or hair color, so why do we do it for gender? Kaldari (talk) 04:00, 21 May 2020 (UTC)


As proposer, I would be open to extending this to race and ethnicity as well as gender, but I think that case is less clearcut, and I'd like to see first if we have consensus about gender, leaving race and ethnicity to a separate discussion. Conversely, I think it is fine to diffuse categories by nationality and even subregional classification (e.g. U.S. states), as long as we understand that the same person may qualify for inclusion in more than one nationality, etc.


  • Categories keep being split and diffused by gender where gender has nothing to do with the matter. Diffusion by gender is not like diffusion by nationality, where we might usefully break up a big category into dozens of smaller categories: for gender, at least one of the resulting categories will always be at least half as large as the parent category. What possible purpose does it serve to split bass players, or non-fiction writers from the United States, or jazz composers by gender? How is this any more valuable than splitting categories by, say, height or hair-color?
  • Diffusing by gender often has the effect of "ghettoizing" the women in a mostly male profession.
  • What on earth are we then supposed to do with transgender or non-binary people in this respect?

How to put this in practice if adopted:

If adopted this would ultimately result in merging quite a few pairs of existing categories. We would not be able to do this all at once. However, I believe the direction to head would be clear:
  1. Stop creating additional categories that violate this policy.
  2. Categories where there is reasonable doubt as to whether diffusion by gender is appropriate will each merit a CFD discussion.
  3. For categories that clearly violate this policy, or for those where a CFD discussion results in a decision that this diffusion is inappropriate, the category can be turned into a {{Cat redirect}} to the appropriate ungendered parent category, and the usual bots that operate on that template will recategorize any files and subcategories appropriately. (Obviously, if anyone wants to move subcategories and files by hand, they would be welcome to do so; I'm just pointing out that in general no one will have to do that.)

(Thanks to the several people who commented at Commons:Village pump#Overuse of gender in categories, especially User:King of Hearts whose wording in that discussion I have drawn on heavily.)

Jmabel ! talk 01:12, 15 May 2020 (UTC)

Comment: I thought it was long settled that where categories listing gender exist, they are either to be fully diffused (no "generic" category and both a men and a women's category instead) or fully non-diffused AND if subcats are needed, then there are BOTH men's and women's subcats. I strongly oppose "ghettoizing" anyone by race, gender, nationality, ethnicity, and so on; i.e. there should not be a "general" category and then just a "female" category. However, there is probably a discussion to be had about how to categorize people who are non-binary in fully diffusing categories. I also think it is often not necessary to sex-segregate small categories ("Category:Professional underwater basket weavers of 1970", for instance). Overall, the creation of gendered categories should be handled on a case by case basis. Montanabw (talk) 19:54, 15 May 2020 (UTC)

Patrol reformEdit

See Commons talk:Patrol#Patrol reform. pandakekok9 10:50, 19 May 2020 (UTC)

Category:Buildings by year of photographingEdit

Where is the best place to have an overall discussion about Category:Buildings by year of photographing and the various types of buildings as subcategories? It's really a Category:2018 photographs by subject question as bazaars, castles, cinemas, educational institutions belong within the building by year category. At the same time, it's not clear when you actually get back to the same buildings from the top-level subject. Category:Buildings photographed in 2018 is a subcategory of Category:Structures photographed in 2018 which is a subcategory of the (all red links) Category:Architecture photographed in 2018 which I assume is supposed to be the top level category for photography by subject. We kind of need an overall discussion. -- Ricky81682 (talk) 01:49, 22 May 2020 (UTC)

Proposal: Clear Uploaded Files Only After They Have Been Reviewed For Copyright ViolationsEdit

  • Problem: There has been long a large discrepancy between the volume of file uploads and the capacity of Wikimedia Commons to check whether they actually conform to copyright laws. The bottleneck is the limited number of admins: While any user can upload and review a file, only an admin can decide the case.
  • Consequence: There is a huge backlog of pending cases, waiting weeks and months for being finally sighted and decided by an admin, while the copyright violating material stays on Commons – against the law. Even more, many uploaded files that are copyvios are never detected as neither users or admins more closely review them.
  • Solution: Files could still be uploaded by any user, but they should only be cleared for use after they have been reviewed by another user or admin for adhering to copyright laws. Only this way it is ensured that the number of checked and uploaded files is identical.
  • Comment: The current checking system is dependent on random chance. It is only a question of time that third parties (press, companies, major copyright holders) become aware that Wikipedia Commons is not only the largest online image deposit but might be also its largest copyright violator. The damage to Wikipedia's reputation would be immense and lawsuits may follow. We need to be proactive to avoid such a situation. Gun Powder Ma (talk) 11:47, 22 May 2020 (UTC)


  • Symbol oppose vote.svg Oppose per the arguments on the Discussion subsection. It's just not practical, with the size of the patrol and LR backlog and small number of active volunteers right now. --pandakekok9 13:48, 23 May 2020 (UTC)


  • Pictogram voting comment.svg Comment I think this system will introduce even more delays and backlogs. I sympathize with the problem but do not like the solution. --Jarekt (talk) 15:14, 22 May 2020 (UTC)
  • Agree with Jarekt. The delays will only get longer, and people will not have the gratification of uploading images and using them right away, which will likely just prevent good images from being uploaded as it's too much bother. There is a reason the DMCA exists, if stuff was missed -- that is kind of the purposes of those, to avoid the lawsuits. Those will be handled promptly. Also keep in mind that most things we call "copyright violations" really aren't -- the lack of fair use is policy, but our actual usage often still falls under that. Many uploads are more policy violations, rather than actually being illegal. Obvious problems via speedy delete usually happen fairly fast. It's far from perfect, but I think the potential damage in this proposal far outweighs the possible benefit. Carl Lindberg (talk) 19:07, 22 May 2020 (UTC)
  • Rather than random, copyvios are most frequently connected via the same upload account. Significant copyvio activity is often resolved by mass speedy deletions without needing people to accidentally discover each file. Those that monitor recent changes spot and tag these obviously connected uploads pretty efficiently. -- (talk) 19:31, 22 May 2020 (UTC)
  • This doesn't seem practical due to current backlogs. More COM:AF, bots, speedy deletion criteria and restricting mass uploads from Flickr would reduce the problem.--BevinKacon (talk) 11:16, 23 May 2020 (UTC)
  • I'd love to see a solution to this issue. I spend quite a bit of time looking at new uploads these days. Quite a number need more than the amount of time I can spare to be anything like happy with licensing. It might be useful to look at the simply personal images (which seem far more prevalent these days) but it's a thorny problem. --Herby talk thyme 11:23, 23 May 2020 (UTC)
  • I agree that there are a fair number of bad files being uploaded here, but I don't really think we have the number of active volunteers here to make the proposal work. Patrolling and license review operate in similar ways, and both have massive backlogs. I imagine a lot of users (excluding the ones probably reading this, to which this is their home project), just upload images ad hoc when required for use on another project. If this was no longer quickly possible (this process would become backlogged), then this supply of images would dry up. I'd rather have a useful image host with a few copyvios than a completely copyvio free host with no media to host. ~~ Alex Noble - talk 12:08, 23 May 2020 (UTC)
    • I do wish it was only a few - I'm guessing (from what I've seen) that at least 20% of new uploads are copyvio. Maybe 30%+ are questionable... --Herby talk thyme 13:22, 23 May 2020 (UTC)
  • I heard on a long ago previous discussion about the possibility of automatic copyvio checking via TinEye or Google Images. Is it still being worked on right now? pandakekok9 13:50, 23 May 2020 (UTC)
  • I'm not going to "vote" against it as there's clearly no consensus to implement it, theoretically a system of clearance could be implemented for users with proven bad trackrecords of copyright abuse in lieu of blocking. The original proposal is a useful idea, but unfortunately will introduce more problems than it solves. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 23:05, 23 May 2020 (UTC)

Ban certain custom licensesEdit

As we've seen at Commons:Deletion requests/Template:Resolution restricted-by-sa and Commons:Village pump/Archive/2020/05#Images licenced under GFDL-1.2 and CC-BY-NC-(SA/ND), there are many problems with custom licenses, the two main ones being: 1) legal uncertainty due to not being backed by a formal legal document; and 2) incompatibility with other free licenses. I would like to call upon the community to help draft an addendum to COM:L to ban certain types of custom licenses after some date in the future, similar to Commons:Licensing#GNU Free Documentation License.

In my opinion, the ban should at the very least include {{Resolution restricted-by-sa}}, but should not be so broad as to ban {{PD-self}} (even if {{Cc-zero}} is preferred). Some potential points of contention are:

  1. What is the definition of "custom license"? The most obvious definition would be "a license whose text exists only on a wiki", but there is a loophole: uploaders who want to use a custom license could just put it on their personal website.
  2. Should we ban only ShareAlike custom licenses, or something broader? ShareAlike is particularly odious because it only works in practice if there is a large enough ecosystem of works under the same license to remix with, and that obviously doesn't exist for custom licenses.
  3. If we want to ban more than ShareAlike custom licenses, where do we draw the line? Again, we probably don't want to ban {{PD-self}}.
  4. Currently, the way we deal with custom licenses made by third parties (think big organizations/governments) is with a community review on COM:VPC to see if the license is acceptable. Assuming we want to continue accepting third-party custom licenses, how do we distinguish between those who are allowed to create custom licenses and those who aren't?

Note: There is nothing to !vote on yet. Once we come up with a formal proposal, we can proceed with a !vote. King of ♥ 00:27, 24 May 2020 (UTC)

  • Perhaps develop a whitelist of acceptable base licenses already present on the site? It doesn't have to be exhaustive to the point of spelling out individual country variants of Creative Commons, of course (i.e all those at Category:CC license tags), but it would allow us to control on a more basic level what is and isn't permitted in terms of what goes in to custom templates. Huntster (t @ c) 04:53, 24 May 2020 (UTC)
    I think a whitelist might be too restrictive and add too much bureaucracy. We would have to maintain the whitelist and have a community-wide discussion every time we wanted to add a new license. I don't want to change the current approach, where anyone can create a tag for a (published) license they believe in good faith to comply with COM:L and someone else can raise it for discussion or nominate it for deletion if they disagree. -- King of ♥ 05:17, 24 May 2020 (UTC)
  • Pictogram voting comment.svg Comment 1) Copyright is too much of a minefield for us to leave things like license tags up to single individuals. 2) We should focus on streamlining our content for re-users by standardizing our media's meta data as much as possible rather than catering to a bunch of individuals' egos. If you're asking me: Ban all custom license tags made up by individual users for their own stuff. Especially the ones that are just a variation of the regular CC-tags with custom colors etc. Custom licenses by third party organizations are a different matter, of course. --El Grafo (talk) 10:09, 24 May 2020 (UTC)
    I like the idea, but it can be hard to define. Where do you draw the line between: 1) a Commoner who has no other accounts; 2) a Commoner who also has a personal website; 3) someone who has a personal website but isn't really a member of the Commons community; 4) someone who operates a website that others can contribute to, but still contains mostly their own works; 5) someone who operates a popular website that lots of people contribute to? I assume we want to allow the last scenario. Case in point, after Unsplash stopped using CC-0, we stopped accepting photos from them not because it was a custom license per se, but because the terms of the license were unacceptable (i.e. the prohibition against "compil[ing] photos from Unsplash to replicate a similar or competing service"). If Unsplash switched to an acceptable custom license, then I'm sure we'd still be accepting photos from them. -- King of ♥ 17:09, 24 May 2020 (UTC)
  • Pictogram voting comment.svg Comment What about a type of procedure where every new license template has to become aproved by a couple of license reviewers and/or admins. --GPSLeo (talk) 20:47, 24 May 2020 (UTC)
  • Pictogram voting comment.svg Comment I think that what @GPSLeo: suggest is a good idea. It is simple and can go fast. For example if we say 5 admins support and no disputes.
I do not know if we need a formal approval for licenses that is just some intro and an official license. For example: {{Cc-zero-Scot Nelson}}.
What about licenses like "User:xxx/Some-license"? They are easy for the uploader to make. But they are also easy for the user to change. That could be a risk.
The question is also how we find files that uses an "illegal" license. --MGA73 (talk) 09:43, 25 May 2020 (UTC)
  • I don't like the suggestion that a new licence type should be approved by anything less than full community scrutiny. Why on earth do we have to "go fast"? Too easy to game, and well known that some Wiki chapters (e.g. Austria) were/are dominated by GFDL-1.2 supporters who were not in the slightest interested in contributing outside of Wikipedia. The same was for Saffron Blaze with their {{Resolution restricted-by-sa}}. I don't think we should allow novel licences that are defined only on wiki. I also agree that a "share-alike" licence only works if it has cross-licence compatibility with other licences or is itself a hugely popular licence choice, and has been developed by an organisation with access to professional legal advice. I think we could come up with policy on "share-alike" that says firstly that any such licence needs community approval before acceptance, and secondly a short-list of characteristics such a licence has.
As for custom "licence" templates, I think they must always include an official template, so that the official licence cannot be tampered with. I see the use in them providing additional information about the copyright owner or how to contact them, etc, but as always, we should review them to ensure nobody tries to sneak extra restrictions into them. -- Colin (talk) 10:22, 25 May 2020 (UTC)
  • The problem I'm having is that some users identify (what they think is) a problem with a commonly used free licence (for example CC-BY-SA) and then write their own licence. These users typically don't have a legal team checking the licence, so the custom licence risks having much bigger errors than the licence that the user was trying to fix. In some cases, the licence could be seen as a lottery ticket where it is impossible to know how a court would rule if the right holder sues for copyvio. However, I can't think of a clear definition of such licences. Requiring licences to be approved by the community before their use on Commons sounds like a good idea.
Somewhat related to this are the big boilerplate templates which some users put on file information pages, such as User:Ralf Roletschek/Autor4. This template could be seen as a disclaimer. Many GNU and CC licences require you to include certain types of disclaimers with all copies of the work. For example, according to CC-BY-SA 3.0: You must keep intact all notices that refer to this License and to the disclaimer of warranties with every copy of the Work You Distribute or Publicly Perform. We rejected GFDL because the requirement to include a copy of the licence with every copy of a file is too restrictive, and then it's bad if people can circumvent this by providing a huge disclaimer of warranties which all reusers have to include a copy of. It is my understanding that a disclaimer has to be quoted verbatim (keep intact). In other words, it can't be translated, and if the licensor provides the disclaimer in multiple languages (in this case English and German), you may have to provide a copy of all language versions of the text. I think that we need to restrict the use of disclaimers. --Stefan2 (talk) 11:23, 25 May 2020 (UTC)
  • I think some of my concerns with custom licences have been voiced by others above. I have no problems with very very basic licences such as {{PD-self}}, {{Copyrighted free use}} and {{Attribution}}. But the ShareAlike ones are the ones I have huge problems with as some of them are contrary maybe not to the letter of policy, but definitely to the spirit of this project. And the flaws in the language of these tags are also problematic, as Stefan2 mentions above. I would in favour of a ban on custom ShareAlike tags / licences, and ones that are clearly more restrictive than CC-BY-SA-4.0. I would also be in favour of community involvement and approval for any custom licences--custom CC tags, namely the OTRS created tags that are a CC licence summary + OTRS permission should be exempted. --Ìch heiss Nat ùn ìch redd e wenig Elsässisch!Talk to me in EN, FR, PL, GSW-FR(ALS). 19:27, 25 May 2020 (UTC)

Rename COM:ANUEdit

I propose to rename Commons:Administrators' noticeboard/User problems to Commons:Administrators' noticeboard/Problem users because the former is ambiguous: a) problems which normal users (but not admins) have because of the level of access; b) problems related to interaction of users.

User:King of Hearts tried to solve the issue with creating an edit notice (Template:Editnotices/Page/Commons:Administrators' noticeboard/User problems) but the problem seems to persist according to Special:Permalink/421492592#Sandbox got deleted (see the comment by User talk:Pandakekok9). 4nn1l2 (talk) 03:54, 25 May 2020 (UTC)

Yeah, the same here. Though I am near-native in speaking and reading English, when I look at "incidents" without enwiki lens, I don't expect it to be a venue to complain about other users. pandakekok9 04:12, 25 May 2020 (UTC)
  • Commons:Administrators' noticeboard/Incidents would probably result in the same problem. I prefer Commons:Administrators' noticeboard/User disputes. pandakekok9 04:11, 25 May 2020 (UTC)
  • I have always thought of this as a difference between w:WP:NPOV and COM:NPOV. Commons doesn't require a neutral point of view, so the title is based on a non-neutral POV (there's a problem with the user with whom you are in conflict). On the other hand, Wikipedia takes a more neutral stance and refers to it as an 'incident' instead. --Stefan2 (talk) 11:29, 25 May 2020 (UTC)
  • Not "problem users" please. Not everyone who gets reported there, is a problem user. --A.Savin 18:11, 25 May 2020 (UTC)
  • None of the alternates appear better than the current. User disputes would be wrong as issues like user naming or language issues are reported with no dispute, and as has been explained "problem users" implies bad users too. Though there's already a help desk, VP, VP/T, VP/C as well as more specific AN boards, so there no obvious need for extra boards either. -- (talk) 18:19, 25 May 2020 (UTC)