Commons:Village pump/Proposals

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?

Start a new discussion

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 Commons[edit]

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 file[edit]

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 1[edit]

Support As the suggester -- Eatcha (talk) 10:08, 8 November 2019 (UTC)
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)
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 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. GMG ^talk 20:34, 30 November 2019 (UTC)
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)
Oppose Too complex procedure. It would make tons of additional backlog. – Kwj2772 (talk) 22:44, 1 December 2019 (UTC)
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)
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. -- Veikk0.ma (talk) 14:42, 6 February 2020 (UTC)
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)
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 https://cloud.qencode.com/pricing 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 1[edit]

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. --Fæ (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 2[edit]

Support -- Eatcha (talk) 10:09, 8 November 2019 (UTC)
Support Kaldari (talk) 16:00, 12 November 2019 (UTC)
Support – Kwj2772 (talk) 20:22, 30 November 2019 (UTC)
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)
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)
Support - Tibet Nation (talk) 18:25, 29 December 2019 (UTC)
Support Keep, transcode and make available when patent issue is gone.--So9q (talk) 10:47, 16 January 2020 (UTC)
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. -- Veikk0.ma (talk) 15:14, 6 February 2020 (UTC)
Support Good idea too Doc James (talk · contribs · email) 03:32, 10 February 2020 (UTC)
Support This is extremely useful. —Justin (koavf)❤T☮C☺M☯ 04:34, 10 February 2020 (UTC)
Support This is a brilliant idea, and a great balance between functionality and values. --Pratik.pks (talk) 03:05, 11 February 2020 (UTC)
Support Is there a holding-pen somewhere where the mp4 files can be saved until the patent expires? Archive.org maybe? Victorgrigas (talk) 19:06, 11 February 2020 (UTC)
Strong support Perfect. --pandakekok9 04:52, 11 March 2020 (UTC)
Support We need this. -Theklan (talk) 08:23, 16 March 2020 (UTC)

Discussion for Proposal 2[edit]

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. --Fæ (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]

Tracked in Phabricator
Task T209437

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 3[edit]

Support -- Eatcha (talk) 10:09, 8 November 2019 (UTC)
Support --D-Kuru (talk) 16:04, 5 January 2020 (UTC)
Support Victorgrigas (talk) 19:05, 11 February 2020 (UTC)
Support --Vulp here 03:00, 19 February 2020 (UTC)
Support Along with proposal 2. --pandakekok9 04:52, 11 March 2020 (UTC)

Discussion for Proposal 3[edit]

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

@Masum Reza^📞 Here you are:

MSUCodecComparison2017
ieee, analysis of H.264, H.265, VP9 and AV1
HEVC: RATING THE CONTENDERS
Or... you just go to Wikipedia and read it, What I wrote is from Wikipedia. Can you see the blue links, it's for evidience seekers? I knew someone may ask for evidence. Thanks, Eatcha (talk) 10:36, 8 November 2019 (UTC)

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. --Fæ (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)

NO ACTION:

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 app[edit]

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 4[edit]

~~Support~~ -- Eatcha (talk) 10:10, 8 November 2019 (UTC)
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)
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)
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 4[edit]

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. --Fæ (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.

Definition of educational[edit]

There are objects with many thousands pictures of them and a huge amount of these images has an acceptable or good quality. But it would be difficult to find an educational use where this many images are needed. And no one would forbid to upload now images of these object and none of these images gets deleted because it is just one with many similar ones. The current policy says that images are in scope if they are used in an other Wikimedia project or if they can be used for educational purposes. Educational is defined as "providing knowledge; instructional or informative".
To have many pictures of one object in scope I would propose to add "showing the real world with every detail" to the definition of educational. I think that would include many images of the same subject in the scope while preventing mass upload of fictional or promotional content. Of course this should also not include media violating the human rights of someone. --GPSLeo (talk) 20:48, 28 January 2020 (UTC)

By default the Vulcan philosophy of Infinite Diversity in Infinite Combinations has applied.

It's already sort of in the policies, though guidelines can always improve their wording. --Fæ (talk) 20:57, 28 January 2020 (UTC)

I disagree; "showing the real world with every detail" is already part of educational use. Showing hundreds of largely similar images of the Tower Bridge (which I'm guessing this is in response to) is not showing unique details of anything, and I'd argue we should be pushing back at new uploads of the same object in the same way. A thousand pictures of the Tower Bridge, each mostly not overlapping, showing the Bridge at detail you can't get from File:Tower Bridge from Shad Thames.jpg would be awesome, and I don't think anyone would object to that.

Basically, I don't think the rule adds anything at all, and while it appears to me to be about a subject on which you and I disagree, I don't think it clarifies the disagreement for the larger audience. (I'd also say it's largely moot; nobody, including me, is rushing to delete files from those categories I complained about.)--Prosfilaes (talk) 21:31, 28 January 2020 (UTC)

I also do not think that this would make any major change, but with this words some misunderstandings and ambiguities of educational and the project scope could be eliminated. I would disagree that there are enough images of some objects. I see no reason that we can not store a huge amount of images, storage is not very expensive. One example that images where it looks like there is no use for them can have a use case: I used File:Silberteich 18.jpg and File:Silberteich 19.jpg to find the exact location of the WLE finalist File:Silberteich.jpg. --GPSLeo (talk) 11:04, 29 January 2020 (UTC)

If we're going to toss the flood gates open, why not start with ceasing to delete photos people upload of themselves and their bands and the like? That's contentious and frustrating to the uploaders, and they can be neatly stuck away in the category tree and forgotten at little cost.

One of my hiking buddies complained that one of his friends would post photos of their hiking trips, but instead of a selected few, he'd post 300+ images, making them extremely tedious to go through. When I'm in the mood, I can rack up hundreds of photos in a couple days. If I uploaded them all, I think it worsen the quality of Commons, make it harder to find useful images. I have hundreds of pictures of the desert cottontail; I've uploaded one, not great quality, video, because it's the only video on Commons where you can actually see how the cottontail moves. And if I were to encourage myself and others, it would not be to upload the same tourist pictures; a picture of a local park, as of yet undocumented on Commons, is worth way more than another of the Tower Bridge.--Prosfilaes (talk) 21:41, 29 January 2020 (UTC)

As I sad there are use cases for many pictures of the same. For finding the best for most common uses we should better look on improving the quality image assessment procedures. --GPSLeo (talk) 09:30, 30 January 2020 (UTC)

I think the adding mediocre, poorly categorized images quickly overwhelms the value of any of those use cases. It takes work to handle them.--Prosfilaes (talk) 01:13, 7 February 2020 (UTC)

If I may add a further opinion: I do agree with Prosfilaes that for objects where we already have hundreds or thousands of highly similar and redundant images, adding even more should be discouraged unless new ones are in some aspect of superior quality or show previously-unseen details. Similarly, I believe that deleting redundant images does serve a purpose. Among hundreds or thousands of images showing the same object, naturally some will be of better, others of worse quality. Now, if an article editor or any other user is in need of an image, having to look through an endless number of images just to find the better ones is difficult and highly time-consuming. On the other hand, if redundant images are continuously sorted out, with inferior ones being deleted and the better ones kept, it is far more easy to find the images that one actually wants to see. GFJ (talk) 19:33, 29 January 2020 (UTC)

There's another option between ignoring and deleting, which I'd call curating. E.g., pick the best photos of the tower bridge, from various observation points and weather conditions. Then put {{Superseded}} on any inferior image that matches one of these, and put all such images in a "superseded" subcategory. --ghouston (talk) 02:50, 30 January 2020 (UTC)

The curation used to be on galleries, not in categories. Pick the best handful of images to illustrate a subject and put them in a gallery. Entry points to topics should prefer the galleries, if we go that route. Other than potentially having different links from Wikidata, seems like that should be just as easy (if not easier) than curating categories. Carl Lindberg (talk) 03:55, 31 January 2020 (UTC)

I think that this is a solution to a small problem, which will have serious negative consequences. Here is a hypothetical educational useage: I want to illustrate the difference of winter weather in some village. What I am searching for (in this hypothetical) is an outside photo of any objects that was made in December of each year. Your approach would delete many such photos, simply because the objects on them are already illustrated elsewhere, but I was not searching for those objects, I was looking at everything around them (is there snow, how much of it, what kind of snow, etc). So by trying to make it slightly easier for a user to find a good image, you have just made it completely impossible (unless the user is an admin and is able to look at deleted images, but then they have lost all their categorisation, etc). On that ground I am in strong opposition to this proposal. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 05:39, 7 February 2020 (UTC)

I don't think anyone suggested deleting images that are not actually redundant, such as images that show the same object, but in different seasons/backgrounds/landscapes. The image of a village in summer is certainly not redundant to an image of the same village in winter and both should absolutely be kept, I very much agree with you there. Where I believe that deletions are useful is only with "real" redundancy. If we already have 20 images of an object in the same season, with the same background (including general weather, vegetation, etc.), then we don't need 20 more. In this scenario, with real redundancy that takes backgrounds, etc. into account, deleting inferior images is highly useful. GFJ (talk) 20:17, 7 February 2020 (UTC)

Ok, I have typed an answer, and then deleted it. As it stands, I do not believe that this is a constructive proposal, and your response actually points to the problem with it. Anybody who will want to delete a file will say "Yes, of course we allow all educational media here, but this is a 'real' duplicate." We already have a policy about deleting scaled down duplicates, and everything else is the step in the wrong direction. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 20:50, 7 February 2020 (UTC)

Have a look at Category:ZooSphere Gymnopleurus sericeifrons. These are my uploads, I think none is redundant, but they all have the same background and every photograph is one of a large set of exactly the same insect. --Fæ (talk) 10:05, 19 February 2020 (UTC)

Once again, this appears to boil down to how one defines "redundancy". The images from the above category indeed show the same dung beetle, but from different angles, thereby highlighting different details. Like you, I would not consider such images redundant. If the angles were the same, then yes - but that's not the case. Obviously, exhaustively defining "redundancy" is nearly impossible and also not very helpful, different users will always have different criteria for what they consider redundant. Luckily, with Commons:DR we do have a system for peer review. I am not in favor of this proposal. What I do want to achieve with my comments is to make the point that even if it may not be too often, there indeed can be cases where non-identical images are so redundant that deletions become useful to make it easier to find the actually good ones. However, as said before, the threshold for redundancy must of course be high. Here's an example: would most of you say that this image is redundant to this one, but of significantly lower quality? GFJ (talk) 12:45, 19 February 2020 (UTC)

WRT example, no they are not redundant. Both are a bit pants if the intention is to illustrate the game though. --Fæ (talk) 12:49, 19 February 2020 (UTC)

Commons:VideoCutTool[edit]

Our video cut trim tool is working fairly well (still improvements needed of course).

Wondering peoples thoughts about adding this to the left sidebar for video files, similar to how we have the "CropTool" for images? Doc James (talk · contribs · email) 03:18, 10 February 2020 (UTC)

I would love to have a direct link to this tool from the target video. Having this on the side bar would be great. Thanks -- Eatcha (talk) 03:25, 10 February 2020 (UTC)

Usually to alter the sidebar one edits MediaWiki:Sidebar. But I do not see the tools listed. Doc James (talk · contribs · email) 04:16, 10 February 2020 (UTC)

How many times has it been used?

Independently of whether this gets accepted or not, would it be an idea to bundle some helpful video tools together, and offer it as optional? Then people who want to work with video can just turn them on at once. Effeietsanders (talk) 04:47, 10 February 2020 (UTC)

Probably only been used a dozen times. It is just getting functional. What other video tools do we have to bundle? Doc James (talk · contribs · email) 05:45, 10 February 2020 (UTC)

I would love to have a video editing tool as part of Commons seen under/next to videos, happy to help with things if needed to make it easily available to people. I have no opinion as to whether it should go in the sidebar or underneath the video itself, as long as its obvious the tool is available (also not sure if there are different requirements for either). John Cummings (talk) 10:00, 10 February 2020 (UTC)

Does anyone know how to do this? User:Steinsplitter? Doc James (talk · contribs · email) 04:45, 20 February 2020 (UTC)

Restrict Computer-aided tagging to autopatroll users till the major problems are solved[edit]

The Computer-aided tagging tool is producing many bad edits, especial by new users. (Discussions on: Village pump & Commons talk:Structured data/Computer-aided tagging) There are many feature requests to solve these problems and the AI has to become better too. Because of these problems this tool should be restricted to trusted and experienced users with autopatroll rights for now. When the tool works very well it could be open for everyone, even IP users. --GPSLeo (talk) 19:30, 15 February 2020 (UTC)

I agree, though this doesn't go far enough. I have an RfC in draft. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:50, 16 February 2020 (UTC)

AI has to become better - We will be making it better by doing the verification job for Google (it's not bad). Reinforcement based learning, rejected tags will be not shown again. How do you think they improve these results ? -- Eatcha (talk) 10:46, 16 February 2020 (UTC)

I agree with @Pigsonthewing: that this tool is a nightmare. Tags are of no use, we need precise depict statements only. Please could you ping me Andy once the RfC is open? :-) --Vojtěch Dostál (talk) 13:06, 17 February 2020 (UTC)

Proposal to implement blocking by abuse filters[edit]

Following the scoping discussion #Time for abuse filters to block (temporary and permanent) (permalink), a formal proposal for consideration.

One of the standard abilities for abuse filters in mediawiki is to allow blocking of accounts or IP addresses (Block the user and/or IP address from editing) based on criteria in a filter. It has not been something that we have typically needed over the earlier years as we haven't had persistent vandalism or spam. Things have changed, and it is the time for us to move to having blocking functionality available.

[technical detail https://noc.wikimedia.org/conf/highlight.php?file=abusefilter.php and setting $wgAbuseFilterActions['block'] = true;]

If that occurs we also need to define a default period for blocks. I suggest that the default would least demonstrate that we are looking for a minimal approach, so let that be the most gentle setting. Though noting that this would just be a default, and a dropdown with other values will always be present for selection.

To have this change made at Commons, we would need to demonstrate a consensus of the community, and lodge a phabricator site request. Noting that this is a technical change, not a policy change to what we block, or to the blocking policy. Accordingly I propose:

Wikimedia Commons moves to have enabled the ability to block through its abuse filters.
Default periods for blocks to be 2 hours for user accounts, and 2 hours for IP addresses.

I also note that if consensus is reached that Commons administrators will need to work to operational guidance and that is being developed in a separate section, and is outside of the scope of this technical request, and will have a separate consensus. — billinghurst sDrewth 12:58, 15 February 2020 (UTC)

Support[edit]

Support as proposer — billinghurst sDrewth 12:59, 15 February 2020 (UTC)
Support --Herby ^{talk thyme} 13:30, 15 February 2020 (UTC)
Support Christian Ferrer ^(talk) 19:27, 16 February 2020 (UTC)
Support Kaldari (talk) 00:30, 17 February 2020 (UTC)
Support unfortunately because there's not enough admins.--BevinKacon (talk) 12:43, 22 February 2020 (UTC)
Support But don't allow non technical users to touch the filters Eatcha (talk) 14:57, 22 February 2020 (UTC)
Support I've actually thought about making this very proposal before. This can be extremely useful in dealing with LTAs. In fact, my relatively recent dealings with an LTA was what make me think about wanting this. However, there would have to be some restrictions. My original filter has been modified to be much more broad at this point to capture more of the LTA's attacks. Currently, there are false positives. Not many. But even a few being caught by a blocking filter would be too many in my mind. For that reason, admins who use this functionality need to be aware of what they are doing and be willing to monitor their filters extremely closely to ensure that any false positives are dealt with quickly and the filter is modified to preclude them. The filter debugging page can be used to quickly undo errant blocks under such a scenario. A blocking filter is a nuclear option and it should be treated as such. I do believe that it is an option that we should have and I do believe that in very limited circumstances it would be a massive benefit to be able to do but the ramifications of its use need to be fully understood by those that use it and the consequences for misuse should amount to admin abuse. --Majora (talk) 17:33, 23 February 2020 (UTC)
Support --pandakekok9 01:48, 14 March 2020 (UTC)

Oppose[edit]

The referenced consensus is weak, two supports and general discussion is not convincing. This type of systems decision can and should be made on convincing reports and analysis. We do not have to implement the filter in order to do testing, we can simply run a test of the proposed filter against past contributions and analyse what the impact would be, both positive impact for reducing disruption to this project, and negative impact for possible good-faith contributors. Without this, it is unclear what a "minimal approach" is, or how it would be measured. So, let's have some test reports so the community can vote against more than hypotheticals. --Fæ (talk) 13:13, 15 February 2020 (UTC)
Oppose I have personal bad experience with vandalism-detecting filters in en.wiki. I do not know, what kind of edits are considered vandalism by bot. I have seen no analysis yet about proposed filters. What if quarter of blocks will be false positives? I do not know that, I feel, that nobody knows. After test run and analysis my vote can change. Taivo (talk) 19:00, 15 February 2020 (UTC)
@Taivo: Every edit you have been making is already going through every active abuse filter, there is no change involved here. The suggested change is an action that comes from an abuse filter. From your 167k edits, maybe you can explain and relate on your experiences with abuse filters affecting your editing here, I can see about 42 interactions in the logs.
With regard to the processes, I covered that separately below, and our process would not be getting that criteria, that is why we test and manage. We already know what is happening here. I gave specific links to meta's logs (abuse and block) where there is the process in place and it can be demonstrated what is happening. I perfectly understand a cautious approach, and that is what is being proposed. — billinghurst sDrewth 09:41, 16 February 2020 (UTC)
"Every edit you have been making is already going through every active abuse filter"

Technically that's true, but many filters exclude administrators and even more exclude patrollers/autopatrollers. So an admin never tripping an abuse filter doesn't mean much. - Alexis Jazz ^{ping plz} 12:36, 18 February 2020 (UTC)
Oppose on procedural grounds. This should go at VP and not here. VP has twice the page watchers and is the appropriate place for seeking community consensus. GMG ^talk 02:44, 16 February 2020 (UTC)
@GreenMeansGo: This seems to be resolved now. Kaldari (talk) 00:30, 17 February 2020 (UTC)
Oppose, abuse filters themselves are open to abuse, if an admin doesn't like certain behaviour it can be blocked and having an automated blocking process will only create a less collegial working environment for everyone. Imagine being a newbie doing his/her first edits and then getting permanently blocked because you triggered some filter, you probably won't even know what filter you triggered and your only impression of this website is that you're not welcome (for whatever reason), this is something that already happens on other Wikimedia websites. What's worse is when we allow some users (sysops, rollbackers, autopatrolled, Etc.) to do some edits but block others for the exact same edits, this just creates an even more unfair system where some users are more disadvantaged than others. We need more human eyes on admin actions, not less. Countless of free files already get deleted because someone who doesn't properly understand "Commons:licensing" tags some image as "unsourced" or "speedy" and then an admin just deletes it. So why would we make an already imperfect system even more imperfect? Also, unblocking is a nightmare, it's already difficult to get unblocked now, let alone if you're blocked by an automated system and don't even know what you did that was wrong and saying that you understand why you've been blocked and won't do it again is a prerequisite for unblocking but sysops can still decide to leave the block in place. This will just create a whole lot more problems than it solves. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 10:58, 23 February 2020 (UTC)
Oppose The possibility of false positives makes this a non-starter for me. I also agree with a lot of what Donald Trung said. Abzeronow (talk) 18:23, 27 February 2020 (UTC)
Oppose I don't oppose the essence of the idea, but I do oppose this form. For starters, the duration should be reduced to 1 hour and only increased to 2 hours if that is proven to make a real difference in practice. AF blocks should be partial blocks unless there is absolutely no other way. User talk (the namespace in its entirety, not just the user's talk page) should not be blocked unless talk page abuse is what the filter targets. Equally, if talk pages are the target, File: should not be affected. And last but definitely not least: we will require more transparency. While the filters themselves can't be made public as this would explain exactly how they can be evaded, there should be a public list of all current targets. Basically a list of LTAs, spammers with description and the like. If it's not on the list, there shouldn't be an AF block. And when any entry on that list or any particular filter is disputed by the community, that filter should be disabled until the dispute is resolved in discussion. And by that I mean actually resolved in discussion, so not what Jameslwoodward did. - Alexis Jazz ^{ping plz} 08:34, 29 February 2020 (UTC)

Neutral[edit]

Comment[edit]

In response to Fæ. Umm, I referenced no consensus, this is the discussion for consensus. I mentioned a scoping discussion.

With regard to your request for analysis, there is plenty of evidence of spambots active here, and those attempting to be active here. We have been manually been blocking these for years, and this is to stop having to do this manually. This proposal does not change what we are blocking, to that there is no change, it is the processing from manual to automated. This becomes about ensuring that the filters are targeted appropriately, and tuned appropriately for their use, and to agreed measures, some here are close though would need tuning to go the next steps. I linked to some of those active blocking filters at Meta, which would be similar, though not exact that were performing well on 700+ wikis covered by global abuse filters. — billinghurst sDrewth 14:27, 15 February 2020 (UTC)

Suggested guidance followed at #Draft of operational guidance for use of blocking by abuse filters. Feel welcome to make suggestions, or asked for clarifications to be made. — billinghurst sDrewth 14:31, 15 February 2020 (UTC)

@Billinghurst: As I indicated previously, if you are seeking broad community consensus for site-wide changes, you need to transfer these discussions to the village pump. AN is a place for requesting administrator assistance, not a place for building community consensus, and having this discussion here instead of there is out of order. GMG ^talk 14:34, 15 February 2020 (UTC)

When I scanned the referenced discussion, it read as a proposal with votes. You mention "general agreement" a few lines in, but the title "Time for abuse filters to block" I read literally. If you want to discount that discussion as no evidence of consensus, that's fine.

However in line with GMG's point, the history here is (1) run a proposal for "general agreement" that people vote on, (2) run a proposal to "implement" that is laid out as a vote, (3) run a proposal for "we would need to demonstrate a consensus of the community", which this presumably is not.

That's 2 votes more than we actually need and seems exhausting for the limited numbers of volunteers that will be interested and know what we are talking about. --Fæ (talk) 20:09, 15 February 2020 (UTC)

Fæ, I wrote the following to the subject line "Time_for_abuse_filters_to_block_(temporary_and_permanent)"
Hi. To me we have some persistent LTAs and enough spambots getting caught against filters, that I think that it is time that we consider the ability to apply blocks with spam filters, either short term application or permanent. The blocking ability is now in place in numbers of wikis, and has been for a number of years and it is not seen as problematic or out of control. If we did go down the path, we would want to look at some concepts and practice around what would, and how would we apply temporary or permanent blocks, though as we already have a good blocking policy and application of that, then it is not about novel concepts of why we are blocking. If there is a general feeling of agreement, then I will put forward a more specific plan. …

So please don't selectively quote or misrepresent what has been said. I said that I would come forward with a proposal, and I have done so. I did not call for votes, and no body counted votes, they expressed opinions as guidance to my opening statement. I would also like to address the contradiction in some of the argument. It is indicated that this is a limited scope argument for a limited set of people interested and knowing about what we are talking. Yet also argued that the conversation should be at another forum where it would be of less interest and less relevance and small knowledge base, so how does that work? This is an administrator only action, and there are numbers of administrators who keep away from the area, so how is that going to progress in a more inexperienced forum. — billinghurst sDrewth 10:08, 16 February 2020 (UTC)

The contributors affected by this change are not limited to administrators. It is weird to limit the discussion or consensus to those in the sysop group, when it is everyone that will be affected by it. From what you are saying here, I don't understand why you are replying to me, because I am not an administrator, so by the logic above, I have no say here on what happens. --Fæ (talk) 13:09, 16 February 2020 (UTC)

Info Comment made before the move from COM:AN --Fæ (talk) 20:02, 16 February 2020 (UTC)

Comment Hard to reply to this. I think the time period should be reduced to 1 hour, that's typically enough for a human to look at it. In my experience even humans have a hard time correctly identifying abuse. Also, these automated blocks should virtually always be partial blocks: user talk should never be blocked, unless user talk page abuse is specifically the target of the filter. I've experienced more than once the situation where I got blocked on a site by some automated process and as a result I also couldn't complain about my block, because I was blocked! And of course, how do we decide what kind of thing will be eligible for an automatic block? - Alexis Jazz ^{ping plz} 12:36, 18 February 2020 (UTC)

@Alexis Jazz: To my best knowledge, abuse filters can't partially block users, but blocking talk page access can be modified. I think talk page access should never be blocked using abuse filter.

We will most probably hide these filters so that people won't be able to bypass them. That's especially needed for LTAs. When we're sure that the filter is working properly, an administrator can bring it up on administrators' noticeboard. If there is at least one support and no oppose or there is general consensus, we can enable the blocking feature. These blocks should surely be monitored routinely. I can't think of any other proper way, because logs and code of a hidden filter is not available to non-admins. Maybe we should create an "edit filter managers" user group here as well so that skilled non-admins can work on filters too. Ahmad^talk 15:42, 18 February 2020 (UTC)

@Ahmad252: well I do remember one time (can't remember the exact details now, doesn't really matter) when I wasn't able to contribute to a WMF project. Somebody had misconfigured the abuse filter and basically everybody who wasn't a trusted user was blocked from editing. They hadn't gotten any complaints, because doh, nobody who was affected could file any. That's something we should really avoid. - Alexis Jazz ^{ping plz} 15:46, 18 February 2020 (UTC)

@Alexis Jazz: While I remember the incident you are talking about such a thing is no longer possible. The abuse filter now has an emergency shutoff function that would automatically turn the filter off if it is hitting too many people all at once. So while it is possible to design a filter to turn off editing for everyone, in practice the shutoff would stop that pretty quickly. As for your other comment that this should be a partial blocks I don't think that is possible. In any case, these types of filters, as I mentioned above, should really only be used as a nuclear option and such a thing is really only useful for persistent LTAs who repeated test multiple edits very very quickly to try to find a way around our current filter system. With blocking filters their first hit would short circuit their attempts immediately. The time frame for blocks can always be discussed and changed or tweaked. And if I recall correctly from the documentation the time frame set is only a default anyways. It can be modified during the creation of the filter. --Majora (talk) 17:46, 29 February 2020 (UTC)

@Majora: Emergency throttling looks neat. Is it known whether it works well in practice? And I know partial blocks are currently not possible with AF, but that could be requested if it hasn't been requested already. That does leave one thing which I actually do find important and probably also should exist for the current abuse filters: a public description of what it is targeting, if at all possible with a link to some related discussion or checkuser request. - Alexis Jazz ^{ping plz} 18:05, 29 February 2020 (UTC)

@Alexis Jazz: I don't know how well it works in practice. I've never designed a filter bad enough to have triggered it (luckily). I also don't know what Commons's settings are. The emergency shutoff is hard coded into each project's settings and those settings are not viewable by normal people. So we would have to ask what are settings are. All abuse filters have a public title. For most of these cases where a blocking abuse filter would be warranted I'm not sure a detailed description would be appropriate. Enwiki has a LTA page and I've actually heard of long term abusers trying to tailor their attacks to get a page there. They see it as a mark of pride. I'm not entirely sure naming an abuse filter directly after a specific LTA wouldn't have the same effect. That's why, at least in my experience, such filters have much more vague names. --Majora (talk) 18:09, 29 February 2020 (UTC)

@Majora: it's a balance between being effective and being open. What about a revision ID for the related discussion? - Alexis Jazz ^{ping plz} 18:17, 29 February 2020 (UTC)

If there is a specific revision ID or a specific discussion about a LTA I wouldn't mind putting that in somewhere. But for some LTAs I'm not aware of any community discussion regarding their persona non grata status here. They just are vandals. Pure and simple vandals, so discussions may not have occurred. If we are requiring a community discussion for a blocking filter to be used I wouldn't oppose including a link to that in the filter title. --Majora (talk) 18:21, 29 February 2020 (UTC)

Comment - If abuse filters are going to block users, I think there must be a bot that notifies users of their blocks properly so that they will know how to appeal their block. Abuse filter doesn't do that, so the blocked user wouldn't know how they can appeal. Ahmad^talk 15:44, 23 February 2020 (UTC)
Question Since the contents of abuse filters can be hidden to non-administrators, are there any plans to use blocks in those hidden filters? I don't think that's a good idea. pandakekok9 02:08, 12 March 2020 (UTC)
@Pandakekok9: Filters for LTAs are generally always hidden. This is so they can't just look at the filter and figure out, immediately, how to get around it. As this feature would really only be used to block long term, highly active, abusers I would imagine that all blocking filters would be hidden by necessity. For example, one of the main filters that I monitor tracking a very long term abuser is generally tripped half a dozen times or more before they either give up for the time being, get through and are blocked that way, or get blocked by a watchful admin before they can actually make a edit (we have filter logs displayed in real time on IRC). Recently, on the 11th, they were blocked by the filter 8 times in the span of 5 minutes. With a blocking filter this would have been stopped at the first filter trip. --Majora (talk) 00:26, 14 March 2020 (UTC)
@Majora: Okay, seems fair enough pandakekok9 01:47, 14 March 2020 (UTC)

To those that have opposed this proposal, Fæ, Taivo, GreenMeansGo, Donald Trung, Abzeronow, and Alexis Jazz. In the past few hours I've blocked 4 IPs and 1 2 accounts that are part of a long term, extremely active, abuser. I happened to be connected to the abuse filter log channel on IRC which allowed me to quickly notice and block them before any actual edit could be made but that is often not the case. It is situations like this that a blocking filter would be used for. There are no false positives (in the spirit of honesty there were some in the very early stages when I had a logic error in the code that has since been fixed). I can't really stay awake forever monitoring the IRC channel and this type of option being available in our toolkit would certainly help stop the disruption in these cases. --Majora (talk) 01:11, 18 March 2020 (UTC)

Maximum block length[edit]

This proposal is to set a fixed maximum length for indefinite account blocks, after which administrators are encouraged to remove the block and consider re-applying for another 4-year term if there are specific realistic reasons to expect that removing the block could cause damage to the owner of the account, or to the goals of this project. The maximum block length is proposed to be 4 years.

Context and qualifications

Wikimedia Commons has no standard for a maximum length of edit blocks, no equivalent of the English Wikipedia "standard offer" and though there are blocks that have lasted for more than a decade, there is no such thing as a Wikimedia Commons account ban. This proposal cannot overturn a WMF office action, though for users that are banned on other accounts, reviewing a long term indef Wikimedia Commons block may result in recommending a global ban or asking for a WMF office action to replace the Wikimedia Commons block.

The benefits of adding this to COM:Blocking policy would be to remove blocks that are cosmetic or where the original rationale for the block may have been superseded by later policies and systems, for example, the WMF office lock. There would be no need for the account owner to run an unblock request for this review to occur. --Fæ (talk) 16:41, 21 February 2020 (UTC)

Maximum block length, votes[edit]

Support as proposer. --Fæ (talk) 16:41, 21 February 2020 (UTC)
Oppose No relevant example has been shown. Creation of tons of log entries for unblocking users that don't request anything is useless admin work. If at all, we should create a policy for new blocks only, and have a well elaborated list of possible exceptions. --Krd 17:09, 21 February 2020 (UTC)
Oppose Mainly as per the first Krd's sentence, it seems like work for a profit not obvious. Christian Ferrer ^(talk) 21:54, 21 February 2020 (UTC)
Oppose But mostly on technical grounds. Removing blocks from users who haven't even logged in in ages seems like a waste of time. For deceased users, this may be considered if the account is globally locked to prevent abuse. (no need to continue shitting on someone after they passed away) Also, 4 years is too long if we are hoping anyone will come back. 2 years tops. - Alexis Jazz ^{ping plz} 03:25, 22 February 2020 (UTC)
Oppose per Krd, but I do like Christian Ferrer's idea below. -- CptViraj (📧) 03:42, 22 February 2020 (UTC)
Oppose any users who want return will already have requested it, otherwise you are free to contact them on their talk page or email to see if they are even still active.--BevinKacon (talk) 12:40, 22 February 2020 (UTC)
Oppose They should create a new account and have a new start, much better than living a life of a indef blocked user. Ask your yourselves , would you trust a new user who appears really nice or an user with past problems ? Thanks for reading my lines.-- Eatcha (talk) 15:02, 22 February 2020 (UTC)
Support, I support the idea behind the proposal, just not its technical implementation. For example this person was blocked for 8 (eight) years and has now returned as a net positive for Wikimedia Commons. It is not uncommon for 10 (ten) year old blocks to still be enforced because evasion of the original block by itself is considered to be abusive and these blocks are factually impossible to lift (plenty of admins believe that users shouldn't receive more chances than what they "originally had"), we basically have a culture that says "respect old blocks, regardless if there is a 0% (zero percent) chance of the abuse repeating. For years I had thought about proposing "a maximum sanction length", for example at "Commons:Editing restrictions" two (2) extant entries read "They may not use any alternate accounts. They may upload a maximum of three images per week. All images they upload must be their own work. They must give a link to all online sites where they have previously published images they have uploaded. They will not reupload any previously deleted images." These restrictions basically say that they are forever "second-class users" who may not engage in non-disruptive behaviour which is considered normal for other users because of something that happened 7 (seven) years ago. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:10, 23 February 2020 (UTC)
Oppose Would create further workload for administrators, to the point it would be unworkable. Indef users are welcome to use the request for unblock, if it has been quite sometime since they were blocked. Bidgee (talk) 11:25, 23 February 2020 (UTC)
Huh? How is looking at a maximum of 24 account blocks, most of which will be obvious decisions, be "unworkable". One admin could do it in about an hour and a half. --Fæ (talk) 11:42, 23 February 2020 (UTC)
Oppose The vast majority of people I block are either spammers or vandals - anything other than indef would be silly. --Herby ^{talk thyme} 12:18, 23 February 2020 (UTC)
Oppose Pointless mission-creep, sorry. No need for it. Rodhullandemu (talk) 12:46, 23 February 2020 (UTC)
Oppose Looks like a lot of completely redundant work. --jdx ^Re: 14:26, 23 February 2020 (UTC)
Oppose Per Krd. --AFBorchert (talk) 10:14, 27 February 2020 (UTC)
Oppose. Unfortunately there are cases where indefinite blocks are the only suitable remedy. It is counterproductive to review these blocks periodically if the original situation has not changed. Érico (talk) 12:36, 27 February 2020 (UTC)
Support I support shorter default block periods. I think 4 years is a good length of time for a default block period. I would apply it to new blocks and to old blocks per request of blocked party. Longer block periods should be set only per community consensus. --Jarekt (talk) 18:48, 4 March 2020 (UTC)

And this would be for vandalism only accounts? --Herby ^{talk thyme} 18:55, 4 March 2020 (UTC)

Support Christian Ferrer's proposal below, as long as their request is positive/neutral/empty per Alexis Jazz. Oppose original proposal. --pandakekok9 09:20, 17 March 2020 (UTC)

Maximum block length, discussion[edit]

There may be standard exceptions, such as sock accounts where the puppeteer's primary account is the one that should be reviewed. However, these types of exception should be added as guidelines that supplement block policy. Self-blocks or self-requested blocks, are ultimately meaningless after 4 years and probably should not be considered an exception as the account is effectively retired anyway. Accounts such being blocked as 'unapproved bot' are again redundant after 4 years, unless the account owner is a known active puppeteer, or is known to intend to resume disruptive behaviour.

Examples of accounts that would be reviewed are User:Juiced lemon (harassment 2007), User:Mbdortmund (deceased 2012), User:Saibo (self block "Commons" 2013). Accounts like User:DcoetzeeBot which were blocked in alignment with a WMF office action but were never locked by the WMF, should be passed back for the WMF to decide if they wish to block the account. At the time of this proposal, there were just 24 accounts which are indef blocked for more than 4 years, so doing reviews to consider whether re-blocks are necessary and justifiable are not a significant burden for Administrator time. There are no examples I have seen so far where the account could not be unblocked or the indef block replaced with a global ban or WMF lock. --Fæ (talk) 16:41, 21 February 2020 (UTC)

Question What problem is this trying to address? What is the benefit of unblocking indef blocked accounts after 4 years (or any other fixed length of time)? Why unblock accounts is the user has not requested it? World's Lamest Critic (talk) 18:55, 21 February 2020 (UTC)

Comment What about a maximum duration (of, say, 2 years) when blocking accounts that have actively contributed for at least 6 months and aren't socks? As a way to still allow indef for vandalism-only accounts etc. I think lifting blocks for deceased users is not a good idea. They can't return, ever. If anything, we should perhaps have a special status for such accounts, or simply apply a global lock to prevent any possible future abuse of the account. That would also allow removing any project specific blocks. It would be mostly cosmetic, but calling someone unwelcome after they died is, meh, not nice I guess. - Alexis Jazz ^{ping plz} 20:45, 21 February 2020 (UTC)

So... why shouldn't we just wait for the user to request unblock? Administrators are required to notify blocked users. Block notification templates also tell users about appealing their block. If someone wants to return, they can appeal. In my opinion, many never consider returning to Commons after, say, 4 years of being blocked. If someone hasn't appealed their block in the last 4 years, I think there is a very low possibility that they ever come back. Ahmad^talk 22:09, 21 February 2020 (UTC)

I don't think it all that unlikely that they'll come back, but I suspect if they haven't created a new account in four years, they aren't going to reopen their old ones, and anyone blocked for four years who has been operating under other accounts is not going to do anything good with a suddenly unblocked account.--Prosfilaes (talk) 22:16, 21 February 2020 (UTC)

@Ahmad252: because in practice I sometimes see admins who feel personally hurt or who refuse to give a user another chance as a result of thinking "once a bad user, always a bad user". I can't even recall any unblock request after a long period of time that was granted. The only actual result from this is that we encourage anyone who gets indefblocked to sock, because requesting to be unblocked is futile. - Alexis Jazz ^{ping plz} 22:30, 21 February 2020 (UTC)

@Prosfilaes: Some will come back, but I think they should request unblock first. Unblocking all blocked users will create too many log entries, I'd say it doesn't worth it if the user isn't going to come back. As Christian Ferrer said below, we can alternatively accept unblock requests after 4 years automatically.

@Alexis Jazz: I see. I counted them using Jarry1250's template transclusion count; ~ 309 granted requests, 1107 declined (question: if 1107+309 is 1416, then why does Category:Reviewed requests for unblock return 1362 requests?). However, that's just a number; I know it doesn't mean much. Anyways, I think Christian Ferrer's suggestion below is a better choice. In that case, user will make an unblock request, so that we know that they still are willing to edit. Ideally, however, I'd say we should discuss this more, and try to solve the main problem: unblock requests being declined for no clear reason. I don't know much about this (maybe because I'm somehow new), but I'd like such a discussion to be started. Ahmad^talk 22:50, 21 February 2020 (UTC)

@Ahmad252: I'm not familiar with "Jarry1250's template transclusion count", link? I do see that hastemplate:"unblock granted" gives 308 results, but the majority of those would have been granted less than a month after being blocked. So your chances of being unblocked after a year or so still seem slim to none. Actually, 308 granted unblock requests.. that seems incredibly low. With ~1400 unblock requests total it doesn't seem terrible, but that number also seems low. I think people either don't know how to request unblock or have no faith (and rightfully so IMHO..) that it'll be granted in many cases.

Two examples that immediately come to my mind are Amitie 10g and Slowking4. Amitie 10g made mistakes, I won't argue about that. But as the Dutch say "waar er twee vechten hebben er twee schuld" which roughly translates to "where two people are fighting, both are guilty". And Ellin Beltz isn't fully free from blame either. Amitie 10g was wrong in the way he treated her, but the complaints weren't hollow. And it's quite a long time ago. Even a request to just get access to the File: namespace again was declined, instead a threat was made to revoke his talk page access. Admins seem to expect people to grovel or something, and even if one did, I doubt their unblock request would be granted.

Slowking4 is a different matter entirely. Slowking4 is a disrupter, no question about that. And sometimes he went too far. But we need people who speak up when they spot a problem! He requested to be unblocked and IIRC that was refused mainly because he wrote m:User:Slowking4/wikicommons has cancer. It's just a list, the title is the primary reason the unblock was declined AFAIK. Now, where I consider myself a bit of a wordsmith, Slowking4 can be more of a butcher. But I have said pretty much the same things and worse as Slowking4 has, I just don't say "x has cancer" and don't resort to disruption, at least not as often as Slowking4 did. Also, as you can tell from that page, Jcb was an important factor that bothered Slowking4. That's not going to be a source of conflict anymore.. - Alexis Jazz ^{ping plz} 04:03, 22 February 2020 (UTC)

@Alexis Jazz: That's here. Thanks for examples. I understand (I'd prefer to not go into details here), but I was thinking... What happens after the (semi-)automatic unblock? What if the unblocked user makes a little mistake? I know that blocks must be preventative rather than punitive, but we've already blocked them for 2/4/n years. Should we just block the user indefinitely in this case, or block them for another two/four/n years? Ahmad^talk 15:39, 23 February 2020 (UTC)

@Ahmad252: Unless a user clearly has nothing but bad intentions, I think they should never be blocked for more than 2 years. And if the unblocked user makes a little mistake, that should just result in a warning or short block, as usual. If they continue with the bad behaviour that got them blocked in the first place, leeway would be limited. They would be reminded/warned, but if nothing changes it's another 2 year block. But this would obviously be to be judged on a case-by-case basis. - Alexis Jazz ^{ping plz} 18:27, 23 February 2020 (UTC)

Comment Despite my oppose vote above, I like the idea of a new chance for blocked users, but I absolutely don't like the systematic aspect. As an alternative, taking things from the other end, maybe an unblock request made 4 years after the block should be accepted automatically. Christian Ferrer ^(talk) 22:20, 21 February 2020 (UTC)

I'd say reduce that to 2 years and accept any neutral/empty or positive unblock request. Obviously, if someone tries "{{unblock|I want to break stuff!}} there's no point in granting that. - Alexis Jazz ^{ping plz} 22:38, 21 February 2020 (UTC)

I personally think that Alexis Jazz and Eatcha said it best, it would be better if blocks can "non-technically" expire, in this case "clean starts" can start again, and then they won't be bothered by people who hate them and will stalk their edits to see if they repeat any mistake they made in the past. If a new user registers an account and makes a few mistakes most people will try to talk to them and teach them what is and isn't acceptable, but if a previously blocked user makes a mistake, it doesn't matter that they were previously blocked for uploading copyright violations, massively categorising images in a wrong manner now means that they should be blocked because "disruption is disruption". Vandals will be vandals and they are blocked on sight, but a young child blocked for constantly uploading selfies and then returning in a few years to upload high quality images that are within scope should not be punished for "socking". --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:17, 23 February 2020 (UTC)

There are many cases where an indefinite block is appropriate. Here we're talking about active contributors, often established contributors. I agree that in in practice it's often better to block "only" for 5 years, because we have no idea how the person might be after such a long time. Indefinite blocks work only if we implicitly assume that the person may come back with a completely different identity and improve their conduct so drastically that nobody will notice they're the same person (or not without looking very hard). Some speedy process to consider unblocks could be interesting: it doesn't need to be super bureaucratic, maybe it's enough to ask that the user requests the unblock, at least N other users endorse it (1? 2?), and an admin administers the unblock. We could make a list of users who've been indefinitely blocked year for several years and who are still active on some other Wikimedia wiki, just to get an idea. Nemo 16:21, 23 February 2020 (UTC)

Standard offer[edit]

As the maximum block proposal looks like a non-starter, how about we agree an equivalent to enwiki's WP:Standard offer? It's only an essay, but it helps guide administrators as to where to draw a line under old bad behaviour, without encouraging the blocked person to either give up entirely, or effectively pretend to be a newbie by losing their contribution history with a clean start account.

Lifting the main points from that essay, this becomes:

Wait at least six months, without sockpuppetry or block evasion; i.e. with no edit, using any account or anonymously, on Commons
Promise to avoid the behavior that led to the block
Don't create any extraordinary reasons to object to a return

This could just be an essay, but if agreed then any unblock request that met these criteria would almost certainly succeed. Thoughts about why this might not work on this project? As things currently stand we have a few old indef blocks that literally are not blocks but bans, it's time we recognize what that means and rethink whether the project needs bans that are not global bans. --Fæ (talk) 11:30, 27 February 2020 (UTC)

I simply can't agree with the standard offer, it's not a real unblocking scheme, it's just an excuse sysops use to not review any unblock requests before six (6) months, when you go to the ArbCom they will say "Wait at least six months, without sockpuppetry or block evasion; i.e. with no edit, using any account or anonymously." as a copy-pasted message, use the UTRS, they will say "Wait at least six months, without sockpuppetry or block evasion; i.e. with no edit, using any account or anonymously.", ask any individual sysop "Wait at least six months, without sockpuppetry or block evasion; i.e. with no edit, using any account or anonymously." It's a copypasta message sysops use to tell people "go away for six (6) months", but after those six months there's no guarantee for return. It doesn't actually mean that you're more likely to be unblocked after six months, it's just an excuse for sysops and others to ignore any block requests made before six months. Productive users should be able to return if they will genuinely stop, all this does is create more bitterness and apathy. Don't get me wrong, a return should be possible, but the standard offer is not a good solution. In fact, I would switch it around, if an indefinitely blocked person would give a good case to be unblocked but some people still doubt their sincerity the block length could be shortened to "only" six (6) months. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 05:34, 28 February 2020 (UTC)

Comment Also, the above proposal isn't wholly rejected because people don't want blocked users to be able to return, but because it creates more admin workload by forcing them to re-block users based on time. "Commons:Blocking policy" currently reads "blocking is designed to be a preventative measure and not a punitive one", which could easily be elaborated upon by simply making a new policy proposal that if a block after 2 (two) years (or some any other number of time) is being appealed that it should automatically be granted and that if the block were to be evaded after this time that their new accounts could be seen as "clean start" accounts and may not be re-blocked unless they are either (1) WMF banned, or (2) engaging in disruptive behaviour (the kind which would get anyone blocked). This would actually make blocking a more preventative action rather than a punitive one. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 05:45, 28 February 2020 (UTC)

Abbreviated Dutch names[edit]

Dutch names that are suffixed with "szoon" ("son of") are very often abbreviated to "sz". The most famous example probably being Rembrandt Harmenszoon van Rijn, often rendered as "Rembrandt Harmensz. van Rijn" or "Rembrandt Harmensz van Rijn". In a large number of these cases, the abbreviated version has become the most common rendering of the name. On Commons, we sometimes write these names with the period (Dirck Jacobsz., Jan Ewoutsz., Lubbert Gerritsz.), and sometimes don't (Leendert Claesz, Arend Fokke Simonsz, Ernst Jansz). In English language sources, it seems that the period is generally left off of these abbreviated names, while Dutch sources more commonly use the periods. Would it make sense for us to try to implement a standard practice for these? Here are the options:

Option A: Always expand abbreviated Dutch names
Option B: Always use a period when abbreviated
Option C: Never use a period when abbreviated
Option D: Handle on a case-by-case basis (status quo)

Kaldari (talk) 19:32, 28 February 2020 (UTC)

I never actually realized it, but category names are almost always English here. See Category:Artists from Japan, nothing in the Japanese script. So I guess we should follow the English sources. - Alexis Jazz ^{ping plz} 09:01, 29 February 2020 (UTC)

Option C would be best IMO, but I could be persuaded by arguments to use Option A since this is a multilingual project. Abzeronow (talk) 18:40, 29 February 2020 (UTC)

Comment, whichever option wins, it would be best to create category redirects from the others. We don't have a "COM:COMMONNAME" policy for main titles, so if one option wins out it might mean that the more commonly used names might be less likely to be created by experienced users, so redirects will make it more easier to find the new non-standard titles. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:40, 6 March 2020 (UTC)

Acceptance of files from external sources without a license review[edit]

Rehash of this one-year old proposal with changes made to ease the opposition.

We have an endless number of files from external sources without a license review. Many have been around for many years, many of the links died. Thanks to Donald Trung's proposal to archive all external links, this shouldn't be a common sight anymore from now on. But we still have all those old files that were never reviewed. Deleting everything makes no sense. Pretending license reviews are not needed makes no sense. This proposal does not apply to files without a source. Applying it to files with a source that still works, can be fixed or a source that can be checked through archive.org or similar means is discouraged. When such files are found they should be upgraded to a license review.

Proposal to keep files with a source that is no longer available and that:

was uploaded by a former or current license reviewer, administrator or OTRS-member and there is no indication that the file did not originate from the indicated source and there is no reason to suspect that the file is not properly licensed.

matches all of the following: Has a similar or identical source to files with a license review or uploaded by the groups above (for "example.com/gallery1", "example.com/gallery2" would be similar) Matches the general style of those files. Locations, subjects, time period, photography/art style, EXIF if present, watermarks. Not every single thing needs to match, but we should be convinced the work is from the same source. There is no indication that the file did not originate from the indicated source and there is no reason to suspect that the file is not properly licensed. Comes from a source with a general waiver/license (no exclusion of specific files, or only exclusion based on criteria that we can tell without having the source available, for example: "the license only applies to photos taken in Italy") or the license is embedded in the file (for example in the end credits of a video or EXIF) Uploaded by a human user (not bot) who was not known for engaging in copyfraud in the time period of the upload.

or (fallback in case the conditions above can't technically be met)

The community is convinced the file in question came from the indicated source and is properly licensed.

These files will be marked as "This file was uploaded from a trusted source" (or similar), won't require a license review and any "no source" tagging on these is automatically invalid. This proposal does not override COM:PRP, COM:SCOPE and similar relevant policies.

Examples of general waivers/licenses:

A weblog with a license that applies to the whole weblog, for example lasvegasvegas.com. (now defunct)
A website with a license that applies to all users, for example Skitterphoto.
An account (where the account can be determined with the source url, metadata, etc) where a license tag applies to all files from that account. For example {{PD-CAGov}} for https://www.flickr.com/photos/californiadfg/ or a Flickr account that states on its "about" page that all their photos are freely licensed.

Which means no:

Flickr and YouTube accounts for which there is no license tag that could be applied to all files from that account. Even if the account is generally known to tag all their files as Creative Commons: it is possible (and it happens) that an account will omit some files for whatever reason.

Main changes that were made compared to the previous proposal:

This type of tagging is merely discouraged instead of forbidden for uploads that do have a valid source. It may be impractical to check thousands of files just in case archive.org archived 1 or 2 of them. When found, such files should be "upgraded" to a regular license review.
Bot uploads are not (automatically) covered. (this was added for BevinKacon) This may still be used as a guideline when judging such uploads, but the community has to discuss this on a case-by-case basis.
"not known for copyfraud" changed to "who was not known for engaging in copyfraud in the time period of the upload". If a user engages in copyfraud later this doesn't affect the status.
Source examples added.
Also allow files with embedded license from sites without a general waiver.
Fallback added.

Hopefully more luck this time. - Alexis Jazz ^{ping plz} 11:45, 29 February 2020 (UTC)

Pinging @Roy17, Yann, Tuvalkin, 4nn1l2, Vulphere, Kaldari - Alexis Jazz ^{ping plz} 11:45, 29 February 2020 (UTC)

Pinging @GRuban, Clindberg, BevinKacon, Ankry, El Grafo, Snaevar - Alexis Jazz ^{ping plz} 11:45, 29 February 2020 (UTC)

Comments on accepting files with no license review[edit]

Support I think it is a good idea to keep some files as suggested above. Files uploaded by trusted users from sites no longer online should be low risk. We still have the opportunity to start a DR if we think a file is no good. Also if someone contact us and claim they are the copyright holder we should act on it.

Wikipedia don’t have license review so there are most likely many files hosted locally where the source is no longer active. I think we should consider to accept some of their files too. --MGA73 (talk) 13:38, 29 February 2020 (UTC)

Support per User:EatchaBot/Hanooz (all files require review), he is a trusted user and also an administrator but commons doesn't have enough fa-N/4/3 users. Other galleries available at Category:Files requiring license review sorted by user name -- Eatcha (talk · contribs) 14:36, 29 February 2020 (UTC)
Support Okay, I like it, thanks for working on this. -- Tuválkin ✉ ✇ 15:50, 29 February 2020 (UTC)
Support --GRuban (talk) 16:52, 29 February 2020 (UTC)
Support Abzeronow (talk) 17:35, 29 February 2020 (UTC)
Support, per my involvement in the original discussion. Anyhow, any copyright violations can still be deleted on those grounds, files from Flickr that pass the Flickr license review can always be deleted based on freedom of panorama laws, so the same applies with these files, the only difference being that these files will not be automatically deleted if the original source can't be verified. This is exactly why we need to bring external link archiving ASAP. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 21:56, 29 February 2020 (UTC)
Support We shouldn't delete files that are extremely low risk. At the same time we must abide by COM:PRP. Hopefully this is a good compromise. Kaldari (talk) 00:50, 1 March 2020 (UTC)
Oppose--Herby ^{talk thyme} 18:57, 4 March 2020 (UTC)

@Herbythyme: it helps if you explain what your issue with the proposal is. - Alexis Jazz ^{ping plz} 01:06, 5 March 2020 (UTC)

Support per MGA73's comments. --Leoboudv (talk) 21:48, 5 March 2020 (UTC)
Support. Agree with MGA73's comments as well. Carl Lindberg (talk) 17:13, 6 March 2020 (UTC)
Support we can start a DR when there is a serious doubt about the source. Christian Ferrer ^(talk) 17:52, 6 March 2020 (UTC)
Support per Kaldari and Christian. --pandakekok9 09:25, 17 March 2020 (UTC)

Category overdiffusion by date[edit]

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 votes[edit]

Support as proposer. --HyperGaruda (talk) 20:36, 29 February 2020 (UTC)
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)
Support I don't find these "buildings by year" categories helpful at all. -- Deadstar (msg) 16:50, 1 March 2020 (UTC)
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)
Support Such over-categorization makes it impossible to find anything on Commons. Kaldari (talk) 02:54, 2 March 2020 (UTC)
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)
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)

Overdiffusion discussion[edit]

Where to codify this[edit]

Commons:Categories would be the most obvious page, but which section is the most appropriate? I was thinking of either a small addition to Commons:Categories#Categorization tips (specifically the bullet point "when?") or a more descriptive separate subsection in Commons:Categories#For more appropriate categorization. --HyperGaruda (talk) 20:36, 29 February 2020 (UTC)

Overdiffusion wording[edit]

This depends on where we would like to elaborate on overdiffusion. --HyperGaruda (talk) 20:36, 29 February 2020 (UTC)
I'm generally supportive, HyperGaruda but I don't know what you mean by "by-date categories should always be accompanied by its date-free counterpart or date-free subcategory thereof". Can you please explain? - Themightyquill (talk) 12:02, 1 March 2020 (UTC)
- @Themightyquill: for example: File:Al Masjid Al Haram - panoramio.jpg is currently only in a by-date category (Category:Great Mosque of Mecca in 2014). Its date-free counterpart would be Category:Great Mosque of Mecca, but if a more specific subject-based subcategory had existed, e.g. Category:Minarets of the Great Mosque of Mecca, I'd use the latter one instead. In the end, the file would be in both Category:Great Mosque of Mecca in 2014 and in Category:Great Mosque of Mecca. I hope this makes it a bit more clear? --HyperGaruda (talk) 12:25, 1 March 2020 (UTC)

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)

Old maps of ... by year[edit]

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)

Installation of the extension:MobileDetect[edit]

Hi guys, I was trying to create optimized pages for mobile and desktop, however they are so far from each other that would be better to create to versions, special for contests.

Can we install the mw:Extension:MobileDetect, this enable the <mobileonly> tag, the < nomobile > is already installed by default, so this extension would online allowed the <mobileonly> that can easily optimize wiki pages here.

Thank you for your time. -- Rodrigo Tetsuo Argenton^m 03:07, 4 March 2020 (UTC)

Hi. MobileDetect is still a beta extension, and, as far as I know, has never been installed on a Wikimedia wiki. I suggest you first ask about the current status of the extension at mediawikiwiki:Extension talk:MobileDetect and see if it's ready to be installed on Wikimedia projects or not. Ahmad^talk 08:35, 4 March 2020 (UTC)

all that extension does is set display:none on some content. You can accomplish the same thing via mediawiki:mobile.css. Bawolff (talk) 08:34, 15 March 2020 (UTC)

Apply a default of Good Faith for very old files[edit]

A 2008 upload where the "own work" statement has been questioned using a deletion request, with no verifiable copyright issue

A 2010 upload being deleted as an out of scope "personal" photograph, despite the selfie being of a Wikipedia article creator and an established music composer and academic at the University of California.

A very early 2004 upload of an 1896 photograph. Placed by a template design in Category:Images without source, though the history shows a dead source link was removed in 2011. Files in this maintenance category have a history of being speedy deleted without discussion and is a sub-category of the main speedy deletion category.

Proposal

To extend the guidelines of Grandfathered old files to there being a "presumption of good faith" for files hosted for more than 10 years.

Suggested additional guideline text:
All files hosted for over 10 years for which no issue has been raised during that time as to being in-scope or having evidence of a copyright problem, should be treated with a presumption of good faith. This means that speedy deletions should be avoided unless there is verifiable evidence of a copyright issue for a file or series of files, and while deletion requests are encouraged for problematic files, the nominations should be written starting from a position of good faith and deletions based on scope need to be based on more than personal subjective value.

Background

In discussions about cases of very old files put up for speedy deletion as apparent selfies COM:CSD#F10, and deletion discussions where the nomination is based on suspicions rather than evidence of copyright violations, it is clear that there is no general principle that a file that has been hosted for more than a decade and might even be highly valued and reused on sister projects, should be handled with a good faith presumption as being correctly released and in-scope, unless there is a verifiable rationale based on policies to delete.

A consequence of currently having an effective default of bad faith means that files may be mass deleted without individual scrutiny, and effectively deleted "on suspicion" without a specific rationale to justify the action, putting the burden of evidence on anyone objecting to deletion. As these files have been hosted for over 10 years, it is the case that the files get deleted and will stay deleted even if there is zero evidence that there ever was a copyright issue, or that there was any meaningful consensus to delete; most deletions of old files pass by with barely any comment.

Examples:

Commons:Deletion requests/Files in Category:Personal files repeated mass deletions of all files categorized as 'personal', many being uploaded over a decade ago.
Commons:Deletion requests/Files uploaded by Subway06~commonswiki over 100 transport photographs uploaded between 2009 to 2012, where there was a watermark for which there is no evidence that this is not the same person and there never has been evidence of any copyright problems.

--Fæ (talk) 11:41, 4 March 2020 (UTC)

Votes: Good Faith for very old files[edit]

Support As proposer. --Fæ (talk) 11:41, 4 March 2020 (UTC)
Support. I do come across old stuff that looks rather suspiscious from time to time. So far cowardice prevails... My main concern would be the legal ones on copyright. --Herby ^{talk thyme} 11:59, 4 March 2020 (UTC)
This just puts "good faith" in the guideline. It does not stop anyone from deleting very old copyright violations, or speedy deleting very old copyvios, which in my view should always have a basic presumption of good faith for the uploader unless evidence demonstrates they are license laundering or similar. --Fæ (talk) 12:06, 4 March 2020 (UTC)
Support Seems to be reasonable. I would definitely (even without such a policy) not nominate a file for speedy deletion that has been uploaded a long time ago. ℺ Gone Postal (〠 ✉ • ✍ ⏿) 12:08, 4 March 2020 (UTC)
Support Blue winged leafbird didn't want to be deleted, and wasn't. - Alexis Jazz ^{ping plz} 12:19, 4 March 2020 (UTC)
Support I agree oldies should not be speedied. Also see #Acceptance of files from external sources without a license review above about what to do with files without a review. --MGA73 (talk) 14:48, 4 March 2020 (UTC)
Support Abzeronow (talk) 16:37, 4 March 2020 (UTC)
Support in principle, although I would recommend to amend COM:CSD as well. Something along the the lines of Files are not eligible for speedy deletion if they have been uploaded more than 10 years ago. under the File heading. Sebari – aka Srittau (talk) 18:52, 4 March 2020 (UTC)
Support, in fact "Commons:Project scope/Precautionary principle" literally reads "Commons' users aim to build and maintain in good faith a repository of media files which to the best of our knowledge are free or freely-licensed. The precautionary principle is that where there is significant doubt about the freedom of a particular file, it should be deleted." unfortunately in practice most people that cite this policy act as if it reads "The precautionary principle is that where there is any doubt about the freedom of a particular file, it should be deleted." which has gotten a number of free educational and useful files deleted from Wikimedia Commons already. We should at all times be caution of copyright, but there is a difference between good faith doubts and copyright paranoia. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 22:55, 4 March 2020 (UTC)

We abandoned the precautionary principle when we kept hosting monkey selfies. Andy Dingley (talk) 15:05, 6 March 2020 (UTC)

Support} (I think) What am I supporting here? I oppose bulk speedy deletion of these old files, simply for the formatting (or not) of their metadata. Yet if that's the majority view here, why does it appear that the process is going ahead anyway? Andy Dingley (talk) 15:04, 6 March 2020 (UTC)
Oppose no reason has been given why 10 years, why not 9, or 5? It is far too broad, file should at least be in use. I still actually find spam and other speedy files older than 10 years. This will just grow the DR backlog. If it's an issue with CSD F10 criteria, then the proposal should be to amend that.--BevinKacon (talk) 20:42, 9 March 2020 (UTC)
Support Reasonable proposal. It doesn't prohibit well-founded deletion requests and if an image turns out to be problematic after all, deletion is still possible. Speedily deleting content that has been here for 10 years and more doesn't seem appropriate to me. Of course there is some arbitrariness to choosing 10 years, but I also find this time span reasonable. If this causes the DR backlog to get somewhat longer, so be it - there is no hurry. Gestumblindi (talk) 12:22, 12 March 2020 (UTC)
Oppose assumption of uploaders' good faith should be equally applied to all regardless of the age of their uploads. Such a rule would only be hotbed for bureaucratic, mechanistic decisions.--Roy17 (talk) 01:04, 17 March 2020 (UTC)

Discussion: Good Faith for very old files[edit]

"instead of putting the burden of evidence on anyone objecting to deletion" @Fæ: shouldn't "objecting to" be "supporting" in this line? - Alexis Jazz ^{ping plz} 12:19, 4 March 2020 (UTC)

Yes, it is confusing as there's a double negative in the language, however the background bit is not the text that is proposed to be added to the GoF guideline. --Fæ (talk) 12:28, 4 March 2020 (UTC)

It may be worth highlighting that effectively the precautionary principle already does this for us, just not clearly. As PRP requires significant doubt to exist for a file to be deleted, there is a burden on the deletion nominator (or speedy tagger) to have examined the file and be able to explain why significant doubt exists. When we are talking about very old files, this means that in the years of Commons hosting the file and reusers relying on the image page release statement, every year that passes must make the effective water margin higher for how we understand "significant". Clearly, if a file is verifiably a copyright violation, say because we can look at a prior publication with a non-free license, or the uploader says they made a mistake, then there is a common understanding that this makes the doubt significant. However if someone is concerned because EXIF data is missing, or the uploader has not responded to questions, there's a big difference between a file uploaded last week and a file uploaded seven years ago.

Though this proposal is to add 10 years in the guideline for simplicity, we can still delete files older than a decade, and that any more recent upload should still be handled in reasonable good faith. However, formalizing these words in the guideline helps all users to recognize the reality on this project that confidence in a hosted file can and should increase the longer we host it or the more it gets reused, on the basis that reuse means many more pairs of eyes have examined it. --Fæ (talk) 12:28, 4 March 2020 (UTC)

I support the intent of the proposal, however maybe we could simplify the language to indicate that files older than 10 years should be deleted through COM:DR process only. COM:DR process includes mass deletion. I think that that rule would be much easier to understand and apply. --Jarekt (talk) 18:38, 4 March 2020 (UTC)

Not really the intent. Speedies for very old copyvios, say when the uploader is demonstrated to be a serial flickrwasher, would be fine under the current wording. One might expect that the deleting admin or the speedy justification text that ends up in the deletion action comment, would point to some verifiable evidence that makes a DR discussion irrelevant.

Just to clarify, "additional guideline text" is the proposal, not the background section. --Fæ (talk) 18:48, 4 March 2020 (UTC)

If someone think a 10 yr old Flickr account is Flickerwashing would it Normally not start with DR or something where arguments and proof Can be presented?

Also if an account is Flickrwahing there could be some of the pictures where there are no other hits on TinEye and in those cases we could perhaps keep.

There is as far as I know no rule that says that A DR have to be open for a long time so if someone start a DR and make a super bull it proof case then it could be closed as delete shortly after.

Therefore I prefer a DR when the file is old. We can discuss is old is 1, 3 or 10 yrs. --MGA73 (talk) 06:20, 5 March 2020 (UTC)

Maybe a bot could automatically convert "Speedy" nominations into regular deletion requests for non-new files, maybe someone can find the statistics in what window most copyright violations get deleted the quickest and then programme a bot to convert all "speedy" nominations into deletion requests. Copyright violations will still be deleted, but educationally useful older files that were tagged by a user that doesn't understand sourcing won't then be blindly deleted by an administrator. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 23:02, 4 March 2020 (UTC)

Have a script working, refer to Category:Speedy deletions for files over 10 years old. It's a bit selective, avoiding categories for image pages without file timestamps. If it gets turned into an automated maintenance task, I can write up an explanation page. --Fæ (talk) 01:28, 5 March 2020 (UTC)

I think 10 yrs is a long time. I think 2-3 years is better. --MGA73 (talk) 06:20, 5 March 2020 (UTC)

Category:Speedy deletions for files over 3 years old. --Fæ (talk) 12:07, 5 March 2020 (UTC)

As I remarked on Fæ's talk page, I think this is a VERY poorly named category. When it popped (actually, the 10-year version) for 2 files in my watchlist, I thought they were being speedied, as I'm sure would many other people. - Jmabel ! talk 17:19, 5 March 2020 (UTC)

Any file in a subdirectory of Category:Candidates for speedy deletion is at risk of deletion, that's the point of the category. If subcategories include files which must never be speedy deleted, they should not be in that (admin maintenance) hierarchy.

To make the intention clearer, the files are resetting, and a new name of Category:Files uploaded over 10 years ago in a speedy deletion subcategory will be used, unless someone can think of a better maintenance category name. There'll also be a more restrictive choice of parent speedy related category and it'll be explicitly named in the edit comment to avoid any confusion. --Fæ (talk) 17:32, 5 March 2020 (UTC)

But some are solely in this category, because the lousy and scaremongering named Category:Speedy deletions for files over 10 years old is in the category, they have otherwise no reason for a speedy. This categories, if they are really just maintenance categories, must not put "innocent files" in a speedy category, like it was done with two of my uploads. These cats have to be renamed asap (or deleted), and definitely not put in any deletionist category, as then it's a selffulfilling prophecy. Grüße vom Sänger ♫ ^(talk) 18:46, 5 March 2020 (UTC)

What speedy deletion category is File:Friedrich V by Wybrand de Geest.jpg in, which was marked? Lacking source is not grounds for speedy deletion; why was that image marked? Carl Lindberg (talk) 15:09, 6 March 2020 (UTC)

Lack of source. Files are regularly targeted for that. I presume that you're one of those who realises, correctly, that we only need that to prove free licensing, when freedom is not already evident, as here. Andy Dingley (talk) 18:56, 6 March 2020 (UTC)

Question regarding the interpretation of "deletions based on scope need to be based on more than personal subjective value": Under the new guideline, would the specific image File:Tishos.JPG still be eligible for deletion if nominated in a regular deletion request for being out of scope? (In case the exemplary image gets deleted, for future reference: it is a portrait depicting a non-notable person, it is not in use (also not as a personal image on a user page), but it was uploaded more than ten years ago.) If the answer is yes, I fully support this proposal as I agree that for files of this age extra scrutiny is highly useful to prevent hasty deletions. If not, the proposal may require a little bit of rewording, however, as it might be (mis?)interpreted as Commons:Project scope no longer applying to files as soon as they have reached ten years of age. GFJ (talk) 12:43, 5 March 2020 (UTC)

The default of good faith, would mean that a nomination would have to be more than someone's subjective opinion that the photograph is out of scope. We do need illustrative selfies, so choosing to keep examples like this of "classic" bathroom mirror selfies before most mobiles came with user-facing cameras, no matter that they are of weak educational value, uploaded way back in 2008, is not unreasonable and can be argued to benefit the mission of this project.

A nomination that uses a good faith argument that there are demonstrable scope issues like it being intrusive in an unarguably personal space (like a hospital ward), or falls outside the normal definitions of legitimate content, like being a corrupted file, or containing hidden or personal data that is not reasonable to remove, are all potentially good faith reasons to proceed with a deletion discussion; "good faith" here is aimed at the intentions of the uploader and so a default of presuming sufficient value to reusers even when that is not immediately clear to the viewer. --Fæ (talk) 12:53, 5 March 2020 (UTC)

@GFJ: I agree with Fæ, it's a bit unfortunate of an example because selfies are such a new thing. Had it been an ordinary holiday photo where a non-notable person is obscuring the Eiffel tower, it could be a different story. Either way even the selfie you presented could be deleted in a DR (depending on how the discussion goes), but I wouldn't want to see that image getting tagged F10. (I haven't checked if the uploader is a contributor) - Alexis Jazz ^{ping plz} 09:35, 6 March 2020 (UTC)

Right, thank you both for your clarifications. Fæ's argument that the exemplary image illustrates a typical type of selfie from a certain period of time is indeed a valid reason for it being in scope, I can't say that I disagree. (If we had hundreds of similar, higher quality images illustrating the same thing this might be different based on COM:NOTUSED, but I haven't checked that and anyway this is a bit off-topic here.) My main concern was that the new guideline might be misinterpreted as Commons:Project scope essentially no longer applying for images older than ten years - basically preventing any old image, including the hypothetical Eiffel Tower-obscuring portrait, from being allowed to ever be nominated for being out of scope (and I'm not talking about speedy deletion here, only regular deletion requests). If I'm the only one who thinks the proposal might be misinterpreted that way, then that's great, nothing needs to be changed. In case others share this view, however, what about changing the last sentence of the proposed guideline to the following, just to prevent misunderstandings?

”This means that speedy deletions should be avoided unless there is verifiable evidence of a copyright issue for a file or series of files, and while deletion requests are encouraged for problematic files and Commons:Project scope continues to apply, the nominations should be written starting from a position of good faith and deletions based on scope need to be based on more than personal subjective value."

GFJ (talk) 10:11, 6 March 2020 (UTC)

Speedy deletions are good for duplicates, copyvios, files without a license, new files without a source and for illegal content. But for other files I think its best to start a DR. Just because a file have a bad description and is not used does not mean it is worthless. It could be that the person is in fact well known somewhere (or will be in the future) and the person who start the DR just does not know. With facial recognition it is possible to identify people. That can be both good and bad. But if we keep a lot of "selfies" then perhaps in 5 or 10 years when the person is a famous person and then we will suddenly have free pictures from when they were younger. Who would not love to see Donald Trump as a young boy? :-) On our own pc we get more space by deleting a file but on Commons we don't free space when we delete files. We just move them to a "hidden location". So we could chose to keep files instead of just deleting them. --MGA73 (talk) 11:16, 6 March 2020 (UTC)

Comment As always happens, just when you raise it in one place, you find fragments of discussions elsewhere too: Commons:Village pump#Bulk speedy deletions of many old files? Andy Dingley (talk) 15:02, 6 March 2020 (UTC)

Might be tangential, but I'm trying to understand: what (if anything) is the problem with lacking a source if something is obviously in the public domain (ineligible, dating from the 19th century or earlier, first published in the U.S. before 1925, etc.)? - Jmabel ! talk 04:17, 10 March 2020 (UTC)

Nothing. This is why it's nuts for standard templates like {{information}} to automatically add all uploads to speedy deletion subcategories, just because some of the parameters do not have (arbitrary) text against them like "own" or "not given" or even "unknown". The fact is that if you add "unknown" to every old looking file in Category:Images without source, that would probably be an adequate fix.

This change to our standard templates was made by @Jarekt: in November 2019 without any community consensus to support the change. Further, the change is protected as sysop-only, so that locks out the community and forces us to establish a consensus to change it back even though there was no consensus to make the original change.

Jarekt, would you care to fix the consequences of your change, rather than expecting everyone else to sort it out for you? Thanks --Fæ (talk) 11:04, 10 March 2020 (UTC)

You refer to [2] I think? I can't quite read that. Maybe Jarekt did something in error? - Alexis Jazz ^{ping plz} 11:58, 10 March 2020 (UTC)

@Jmabel: not much, mostly the question of a work being genuine or not. For example File:Poppy Field in Argenteuil, Claude Monet.jpg, originally in the source field only "ArtDaily.org" (no link) was entered and it's probably not a Monet. - Alexis Jazz ^{ping plz} 11:58, 10 March 2020 (UTC)

Good example, it's a #fauxnet. --Fæ (talk) 12:02, 10 March 2020 (UTC)

I also agree that lack of source for PD files is irrelevant to its copyright status and should never be a reason for deletion speedy or not, which is explained in Category:Images without source. Template {{Information}} was placing files without source in Category:Images without source since this edit by User:MECU in 2007. I never changed that behavior. The issue is that generally {{Information}} template does not know if a file is in PD or not so I guess the thinking was to throw them all into Category:Images without source where others can sort through them and nominate for deletion if necessary. Now it just happen that with SDC, the {{Information}} template can look for "copyright status (P6216)" set to "public domain (Q19652)" and not place PD images (with SDC) in Category:Images without source. Would that be desired behavior? --Jarekt (talk) 02:31, 11 March 2020 (UTC)

Sorry to mark you out if your later changes did not enable it. There are over 21,000 files in that speedy deletion subcategory so (1) it should not be a speedy deletion subcategory, (2) it's pointless without refinement. Mass dumping of old files in Images without source, should be stopped and preferably abandoned. If someone wants to make helpful backlogs, then a smart bot should do it, not just based on a missing parameter, but assessing if there are recognized source links anywhere in the wikitext, whether the EXIF data has something that makes it obvious, or whether the upload was from a trusted user who happened to upload the file 12 years ago, before someone invented new templates like "map" and decided to paste them mostly blank on the image page.

This has been crappy and unhelpful for a very long time, longer than most of us have been taking part in this project. Now would be a good opportunity to make it better and actually useful rather than something to be ignored. --Fæ (talk) 11:27, 11 March 2020 (UTC)

I agree that Category:Images without source "has been crappy and unhelpful for a very long time", and I would vote to remove it, especially since it mostly overlap with Category:Files with no machine-readable source which is added by MediaWiki software (see Special:TrackingCategories). There are actually few more cases where our templates add a maintenance category which is mostly duplicated by MediaWiki software.

Category:Media lacking author information (added by {{Information}}) and Category:Files with no machine-readable author ( added by MediaWiki)
Category:Media with locations (added by {{Location}}) and Category:Pages with maps ( added by MediaWiki)

I also find Category:Media lacking a description (added by {{Information}}) rather unhelpful. If any of the above categories are assumed to be speedy deletion categories than they cross the line from being merely useless to being counterproductive. --Jarekt (talk) 13:24, 11 March 2020 (UTC)

Comment (Edit conflict) The easy solution is to rename Category:Images without source to Category:Media without source in information template and put it in Category:Media missing information and make a link in Category:Media without a source to Category:Media without source in information template. That way all files are removed from the speedy deletion category and there is still a link to the category. --MGA73 (talk) 13:29, 11 March 2020 (UTC)

Category:Media without source in information template would be more descriptive name but it is also longer, and since {{Information}} template is used by about 90% of files I would just stick to the original name. However please re-categorize anyway it makes sense to make sure that that is not a speedy-deletion category. Another way would be to just stop adding it to the files, since it is unclear if anybody is using it for anything productive. --Jarekt (talk) 02:11, 12 March 2020 (UTC)

@Jarekt: I have used the category to fix a few hundred files. But I suck at working on one thing at a time so I already started to work on something else ;-) I think it could be a nice little project to have 100 users work on fixing source or whatever in those files. --MGA73 (talk) 11:20, 12 March 2020 (UTC)

┌─────────────────────────────────┘
If you want to fix hundreds at a time, you can do this fairly easily with VPN. Here's a real example:

Search for files in the category that have an obvious fix, like incategory:"Images without source" insource:"{{PD-Art|PD-old-100}}"
Load these in VPN using the link in the toolbar shown for any search, in this case this meant clicking "more" twice to get all 591 matches
Use a regular expression for as many good matches as possible, here /\|( *source *= *)\n/g changes to |$1Not necessary, PD by age.
Double check, examine sample changes, the run for real, in this example 355 changes were made and removed from the tracking category

As a random older example, the changes included File:Portrait of a soldier.jpg which was uploaded in 2007 as "old painting" but has never had a source and has yet to be fully identified as which 18th century painter created it. Clearly a speedy deletion would be highly inappropriate, so the automatic category was pointless, even though more details are needed for the image fully to be of realistic value. --Fæ (talk) 11:55, 12 March 2020 (UTC)

@Fæ: Yes! If we do it smart we can fix a lot with minimal work. Perhaps we should use a template to add text like that so it can be internationalized. --MGA73 (talk) 10:11, 16 March 2020 (UTC)

@BevinKacon: When we set up limits you can always discuss what is fair. When we speedy delete we have a 7 day limit. Why not 6 or 8 days? I doubt you would oppose speedy deletions just because we have a random set limit. As for spam and other issues you can still nominate for deletion. You just have to do it as a DR instead of a speedy. That way other users have a chance to comment. To be honest we have seen it many times that admins speedy delete without checking files carefully. --MGA73 (talk) 09:07, 17 March 2020 (UTC)
@Roy17: We should but we all know that it does not always work like that. We have many users that are no longer active on Commons so if someone mark their files with a speedy deletion then there is a good chance (or risk) that the files are deleted without anyone check them carefully. So asking users to be careful and chosing a DR if they think there is a problem with an old file does seem like a good idea to me. As an alternative we could stop using speedies and send all files through a DR but that would kill the process. I think it would be a good balance to be extra careful with old files. --MGA73 (talk) 09:07, 17 March 2020 (UTC)

Sanborn maps categorization[edit]

I'd like to start a discussion about all the Sanborn maps we have. This are literally thousands of maps out there organized by city but it's usually huge sets of the entire maps file located in a single category. For example, Category:Sanborn Fire Insurance Map from Boston, Suffolk County, Massachusetts originally had over a thousand files but it's really about fifteen volumes covering almost two decades. I had split some by individual files (see Category:May 1895 in the United States) but instead for Boston I've renamed them as Category:1885 Sanborn Fire Insurance Map from Boston, Suffolk County, Massachusetts, etc. in this category. However, Category:Sanborn maps of Brooklyn uses a "published in" date naming convention. Ideas on what is best? -- Ricky81682 (talk) 03:32, 7 March 2020 (UTC)

I would say that fieldwork date is usually more important for a map than its publishing date, but seldom both are known. And for now I’d say go ahead at dissiminating those lumpy cats and categorizing individual maps along as many categories as possible. Cat name harmonization can be done later (and it will never be done for empty/inexisting categories). -- Tuválkin ✉ ✇ 13:24, 11 March 2020 (UTC)
- I agree but when you have maps for 1887, 1889 and then 1895/97/98/99, they are very close in time. Other maps for smaller cities do include the month. -- Ricky81682 (talk) 00:23, 12 March 2020 (UTC)
Keep in mind that the batch upload is automated and I have run many "refresh" runs. This means that the subcategories of Category:Sanborn maps of the United States by state were created automatically based on LoC metadata, and may continue to be repopulated in precisely the same way. So, don't be surprised if a handful of new maps appear in those main categories and ignore any diffusions. Please also avoid renaming or moving categories, this would probably have the unintended consequence of me abandoning further refreshes.

See User:Fæ/LOC maps for project details.

Thanks --Fæ (talk) 13:44, 11 March 2020 (UTC)

I don't think it's humanly possible for me to complete this before your next round of work. Especially since the 1925 maps enter the public domain in a year and onward. -- Ricky81682 (talk) 00:23, 12 March 2020 (UTC)

Don't let me put you off. Diffusing the maps into better sub-sub-categories or extra information-adding cats is fine. It's only if you were wanting to move around or rename the main subcategories that could cause an issue. Any new maps would be available in the sub-categories but there will be no extra duplicates made or other errors if past uploads are recategorized. --Fæ (talk) 12:22, 12 March 2020 (UTC)

April 2020 Wikimedia Commons' month of kindness[edit]

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. --Fæ (talk) 12:47, 12 March 2020 (UTC)

Votes, month of kindness[edit]

Support as proposer. --Fæ (talk) 12:50, 12 March 2020 (UTC)
Support a month of finding a reason to help, encourage, and support ever contributor is a fabulous idea... Gnan garra 13:13, 12 March 2020 (UTC)
Support That would be a change! --Ruthven (msg) 13:32, 12 March 2020 (UTC)
Support The GNU Kind communication guidelines can be a useful read as well. Nemo 14:16, 12 March 2020 (UTC)
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)
Support Ainali (talk) 19:53, 12 March 2020 (UTC)
Oppose to the non-implementation of this proposal. --pandakekok9 09:08, 14 March 2020 (UTC)
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)
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)
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)❤T☮C☺M☯ 20:14, 14 March 2020 (UTC)
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)

Discussion, month of kindness[edit]

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". --Fæ (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? --Fæ (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 Gnan garra 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)

Historical weather data on Commons[edit]

Last week, I've posted a request for comments concerning import of Canadian structured weather data into Commons. Donald Trung advised us to post here so I can get the confirmation this type of files can be distributed through Wikimedia Commons. Please note this is only about historical weather data - forecasts are specifically excluded from this discussion.

My understanding of Commons:Project_scope leads me to think that hosting that kind of data is in the scope of Commons, because every requirement is checked:

it's educational content that "provides knowledge". This is especially true since the climate change research has become high priority in many countries during previous years.
shaped like what was proposed by Yurik in 2017 it's media files because JSONs is structured data that can easily be used to automatically generate graphs. As a matter of fact, it is already done on Wikimedia platform. Commons also now has a nice table based visualisation interface that allows everyone to directly read content in an intelligible way.
it uses free file format - a lot of tools can read/write JSON data, especially on the web.

Any thoughts?

Peuc (talk) 15:32, 13 March 2020 (UTC)

Yeah, from what I can tell it checks all the boxes to be in scope and this historical data will be very useful for anyone doing meteorological research (files don't just have to be useful for another Wikimedia website), so I don't see any reason to object to this. How many files will be imported and have y'all already worked out a categorisation scheme? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 19:21, 13 March 2020 (UTC)

Possible category tree may be "Category:Weather Data" ← "Category:Weather Data in [country]". Another level could be added depending on country first administrative level like "Category:Weather Data in [province]" for Canada. However it looks like category system won't make it soon, so these will be added later. This specific proposed import will probably be discussed more in depth during bot status request, but I'll answer your question here: it contains data of 8473 weather stations collected between 1840 and 2018. Having two datasets (monthly data and almanac), it will add 16133 JSON files into "Data:" namespace. Peuc (talk) 05:06, 14 March 2020 (UTC)

Request for uploading an image for last White Giraffe in Earth[edit]

Dear Admins , Reference to news . We have no images for this specie which slaughtered by poachers. Omda4wady (talk) 08:10, 15 March 2020 (UTC)

Unfortunately, the image is not available under a free license, which is not allowed in Commons. Neither is the video in the article. All we could do is ask the copyright holder of the image to consider releasing their photo under a free license. pandakekok9 08:19, 15 March 2020 (UTC)

Photographs of established academics, writers, artists are in scope[edit]

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. --Fæ (talk) 12:18, 17 March 2020 (UTC)

Votes (established academics, writers, artists)[edit]

Support as proposer. --Fæ (talk) 12:22, 17 March 2020 (UTC)
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. --Fæ (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)

Support Would be certainly be useful in clarifying Common's scope policy. Abzeronow (talk) 14:42, 17 March 2020 (UTC)
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)

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)
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)