Wikipedia talk:Files for discussion

From Wikipedia, the free encyclopedia
  (Redirected from Wikipedia talk:FFD)
Jump to: navigation, search

Admin bot to delete old revisions of non-free files[edit]

Thoughts on this? An adminbot to delete all old file revisions of images in Category:Non-free files with orphaned versions more than 7 days old if there's only one editor in the file history (to filter out cases where the file is later changed to non-free, which might require admin review). It seems pretty safe to automate deleting old revisions of rescaled images marked as non-free by the original uploader. ~ Rob13Talk 04:59, 29 January 2017 (UTC)

I wonder how common that scenario is. My impression is that most files tagged for removal of old revisions were edited by 3 people, the uploader, the reducing bot and an user who tagged it for reduction. And bots and users cleaning up new uploads. I also wonder how many admins do in-depth reviews of such requests. Jo-Jo Eumerus (talk, contributions) 09:58, 29 January 2017 (UTC)
Even then, it should be pretty safe to process these via bot. There's a weeklong delay before the old revisions are deleted, and any sort of vandalism/abuse of the system is typically resolved within that timeframe. See also: here & here. Also, ping for @Ronhjones who originally suggested the idea. -FASTILY 00:44, 30 January 2017 (UTC)
  • I see no issue here, sounds like a good idea. -- Iazyges Consermonor Opus meum 02:22, 30 January 2017 (UTC)
  • Obviously works for me! Typically we don't delete old versions, we use User:Legoktm/Frescaled.js script (since it takes way too long manually!) which uses revdel to hide all the oversize images (there may be more than one!) and remove the template. This approach therefore still shows the file history. If there is an issue with the reduction, it's not that difficult to revert. I would rather all big files be reduced and manually revert back 0.1% rather than have 99.9% too big (and I think 0.1% could be overestimated!) I'll ping @Diannaa: as she has an interest in this field.Ronhjones  (Talk) 14:19, 30 January 2017 (UTC)
  • I have no objection to a bot doing this task, as like Ronhjones, I have discovered that the number of cases that actually require human intervention is vanishingly small (0.1% is probably overstating the error rate by quite a bit). Current practice is to use revision-deletion of the old revisions rather than outright deletion, as this helps ensure the correct person gets notified if/when the file gets nominated for deletion as an F5 or for some other reason, because the upload history is visible on the front-facing file description page rather than hidden in the back. — Diannaa 🍁 (talk) 14:29, 30 January 2017 (UTC)
  • @Sphilbrick: you have done thousands of these lately; what's your opinion? — Diannaa 🍁 (talk) 14:32, 30 January 2017 (UTC)
I'm traveling - due to arrive tomorrow. Probably supportive, but would like to give it some more thought tomorrow when I am not brain dead.--S Philbrick(Talk) 01:17, 1 February 2017 (UTC)
  • I asked DeltaQuad if she could handle this, and she's looking into it. ~ Rob13Talk 02:22, 31 January 2017 (UTC)
  • Support As Diannaa notes, I've processed quite a few of these and whenever doing so, vaguely wondered why it wasn't a bot task. My supposition is that it used to require more thought early on, but that's not important, the important fact is that there are a lot of these, the error rate is exceedingly low, and if a mistake occurs it can be undone. Like Jo jo, I would not restrict it to a single editor. A single editor is quite rare. Most involve a bot but many involve a human doing a reduction, so one cannot even limit it to a single editor other than bots. It would be nice to ensure that the bot is either dedicated to this task, or configured so that if a problem occurs, it is easy to identify the history to undo. --S Philbrick(Talk) 12:50, 2 February 2017 (UTC)
  • Support per above, the error rate is low and it is normally those with more than one human editor involved that cause the problems - especially when it's not a reduction but a new version of the image. Bollywood movie posters are where I see edit wars most, over which version and rather than argue of which of two files the edit war is over which revision of one file. Nthep (talk) 20:40, 2 February 2017 (UTC)
  • Support, the room for error is small especially if it's just uploader->bot->deleter. The other cases can go to a category for manual processing, where admins can use the same script being used right now. While we're on the topic of non free revisions, there's a bunch of files where this applies that weren't reduced by the bot (some of which are the edit war case). Fastily any plans to bring back Fbot 8? — Train2104 (talk • contribs) 06:26, 15 February 2017 (UTC)
Not at the moment, but it can be done if the need arises. -FASTILY 06:45, 15 February 2017 (UTC)
  • I'm not as privy to the bot specifics, but why wouldn't we have the bot that handles {{Non-free reduce}} automatically remove (revdel) the content of previous revisions? A spot check of the category shows that it's mostly resizes from DatBox task #6 (pinging @DatGuy). czar 16:16, 16 February 2017 (UTC)
DatGuy is not an admin and the bot policy says that adminbots need to be run by admins. Jo-Jo Eumerus (talk, contributions) 16:26, 16 February 2017 (UTC)
I'm suggesting that we address the source by amending the existing task rather than setting up another bot round. (Though the latter would still be needed for cleanup at first.) Sure, it might entail transfer of bot duties, but that's surmountable. Question is how best to handle the issue czar 16:51, 16 February 2017 (UTC)
As per Eumerus, I cannot run an adminbot. I don't think that a task to clear the category would be merged into my bot's current task since one is for resizing, and the other is for deleting, which is pretty much different topics, unlike what current adminbots do. Dat GuyTalkContribs 17:14, 16 February 2017 (UTC)
God, that's a huge backlog. I've worked since my last comment on a script, which I believe 100% works. See here. Dat GuyTalkContribs 19:02, 16 February 2017 (UTC)
Other link has been removed for some reason, see Dat GuyTalkContribs 00:17, 23 February 2017 (UTC)
@DatGuy: If you try that from a PC and comment out the "api.apiDelete" line and have print "APIdelete ",page.unprefixedtitle at same place then the list of deletes is often too big - e.g. File:KNBN Logo.png shows 5 calls - it's including the first version which is already deleted. (I could not find module userpass, so used mwclient which I have already - seemed to work). Not sure how Wiki will like being asked to hide a hidden image! Ronhjones  (Talk) 20:45, 1 March 2017 (UTC)
Another example File:KNTM season 3 cast .jpg has 3 calls. Ronhjones  (Talk) 20:47, 1 March 2017 (UTC)
@Ronhjones: Userpass is a file that I use to keep my passwords secure, so as I can share the code. The line for version in todelete: is the one that says to go through each individual version. Try adding "print version" under it. Dat GuyTalkContribs 21:25, 1 March 2017 (UTC)
@DatGuy: - see User:Ronhjones/Python Ronhjones  (Talk) 00:55, 2 March 2017 (UTC)
All - note Wikipedia:Bots/Requests_for_approval/RonBot Ronhjones  (Talk) 22:46, 2 March 2017 (UTC)

RFC on routine file deletion[edit]

RFC closed so as to work on proposal. Iazyges Consermonor Opus meum 01:19, 2 March 2017 (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.

Background: As of right now, unencyclopedic files are nominated for deletion through Files for discussion, and almost all are deleted after waiting a week. There's almost never participation at these discussions beyond the nominator and the deleting administrator. FFD is currently filled with such nominations, and these low-importance nominations make it substantially more difficult for our experts on copyright matters to find the nominations that require their attention.

Proposal: Files would be tagged with an alternative "routine file deletion" template, and, if the tag is not contested within 7 days (the current period of FFD before a nomination may be closed), the file is deleted. This proposal aims at separating these routine deletions from more advanced discussions that need additional comments. A list of files currently nominated for routine file deletion will be maintained by a bot at a subpage transcluded on WP:FFD to ensure such files receive the same visibility as other FFD nominations. This is intended purely as a change in administrative workflow to ensure editors can find the more controversial deletion nominations or queries about a file's copyright status.

Definition: An unencyclopedic file must meet one of the following two criteria:

  1. No realistic potential for use in the mainspace. It cannot be used in any article, either for an article about the image, or with the image serving any useful role. (This includes low quality and blurry photos per MOS\Images.)
  2. A "vanity image", files that cannot be used by anyone but the uploader, if the uploader has made few contributions to the English Wikipedia outside of their userspace.

Administrator instructions: When closing a routine file deletion, an administrator must verify the file meets the definition of an unencyclopedic file. If the file is unencyclopedic but otherwise fits the scope of Commons, it should be moved to Commons rather than deleted. Examples of such files may be files which are unlikely to benefit the English Wikipedia in any way but may benefit sister projects. If the nomination appears likely to be controversial, the administrator should procedurally nominate it for a full deletion discussion. Otherwise, the file may be deleted citing "routine file deletion" as the rationale. Files deleted routinely are eligible to be undeleted upon request.

Should the workflow of FFD be split between routine deletions and full deletion discussions? Iazyges Consermonor Opus meum 01:32, 15 February 2017 (UTC)



  • Support as nominator. -- Iazyges Consermonor Opus meum 01:32, 15 February 2017 (UTC)
  • Support See my comment below - anything is better than nothing, the status quo at FFD doesn't help anyone. — Train2104 (talk • contribs) 06:21, 15 February 2017 (UTC)
  • Support Badly needed. As one of the few admins working FfD, I routinely see files that need discussion drowning in a pile of selfies/non-controversial cases. -FASTILY 06:47, 15 February 2017 (UTC)
  • Support - This would be much more efficient and is be consistent with WP:PROD.- MrX 13:04, 15 February 2017 (UTC)
  • Support - Neat proposal. I know that the definition of "unencyclopedic file" is very strict and too precise, but we can revisit the criteria later. Right now, the proposal should clean up the FFD problems that I addressed a few or several months ago. I generally prefer one-on-one talk with uploaders. Nonetheless, I don't mind the "routine" thing. George Ho (talk) 01:49, 16 February 2017 (UTC) Switched to oppose. --George Ho (talk) 04:08, 25 February 2017 (UTC)
    Support-ish Instead of doing the proposal as proposed, just make this a new speedy deletion criterion with a 7-day wait, similar to what we already do with some templates and files already. In my opinion, creating this as a "brand new process" seems highly unnecessary when making this a new CSD criterion would work just fine. (P.S. Majora, see here; this proposal is essentially identical to the idea I posted on your talk page.) Steel1943 (talk) 22:27, 24 February 2017 (UTC)
    Changing to "Oppose as written" per Nabla. Steel1943 (talk) 23:57, 24 February 2017 (UTC)
  • Support. Sounds workable, and we know that the general idea works with articles. Why not just call it "file prod", since it's largely working out the same way if I understand rightly? Nyttend (talk) 22:57, 24 February 2017 (UTC)
  • Support. PROD works for articles. It will probably work for files. KATMAKROFAN (talk) 00:41, 25 February 2017 (UTC)
    @KATMAKROFAN: I agree, which is why I oppose this proposal, because it doesn't propose to use PROD, but something else. Shouldn't this be in the 'oppose' section? ~Anachronist (talk) 02:20, 25 February 2017 (UTC)



  • Oppose. one, do we need 50 shades of deletions? (i.e., too much instructions); two, as Steel1943 said, this is so close to a speedy criterion that most likely it is possible to work it out as a new (or expanded) CSD; three, I doubt this will take more eyes into the process, so either it will not get more attention to "non-routine" deletions, or the "routine" deletions will have even less attention, even if as visible as currently; four, if a discussion does not have enough participation, participate, instead of devising ways for files (or articles) being deleted with less and less scrutiny - i.e., if you see a no-participation discussion, instead of closing it, !vote to delete, or not - Nabla (talk) 23:34, 24 February 2017 (UTC)
  • Oppose as written per my comments in the "Support" and "Discussion" sections. After reading Nabla's comment here, I'm convinced that this should be opposed as written. I support the idea ... but not the instruction creep that comes along with the proposal as written, as well as the fact that this will create a brand new backlog for administrators as opposed to a subgroup of an existing backlog ... such as if this were rewritten to be a new WP:CSD criterion instead. This idea would be more effective as a new speedy deletion criterion, probably "F12", stating that files tagged with this can be deleted after a 7-day waiting period, can be uncontroversially restored through WP:REFUND if deleted in this manner, and while also defining what "unencyclopedic" means when writing the official speedy deletion criterion. Anyways, yes, make this a CSD. Steel1943 (talk) 23:57, 24 February 2017 (UTC)
  • Oppose as written, but instead make such a thing like CSD db-f5, the unused fair use, so that anyone can contest, it can be undeleted on demand, and we probably need to tighten up the "nonencyclopedic" definition. Each thinks they know it when they see it, but opinions may differ. Graeme Bartlett (talk) 00:21, 25 February 2017 (UTC)
  • Oppose. WTF is wrong with WP:PROD? Just use that on images with the correct rationale and be done with it. ~Anachronist (talk) 01:13, 25 February 2017 (UTC)
    @Anachronist: WP:PROD, as currently written, only applies to articles, not files. --AntiCompositeNumber (Leave a message) 22:47, 28 February 2017 (UTC)
    So, expand the scope of WP:PROD. It is clear that it needs expanding rather than adding a different parallel procedure for files. As an admin, if I saw a file with a prod tag, I would treat it like any other prod. There is really zero reason to restrict WP:PROD to articles. ~Anachronist (talk) 22:54, 28 February 2017 (UTC)
  • Switching to oppose. After a re-opening, reading recent opposing comments, and then "keep" votes at mass individual nominations at Wikipedia:Files for discussion/2017 February 19, I think more communication is needed. Also, after this discussion is over, we can propose extending the usage of WP:PROD to media files, i.e. no longer limit to just articles. However, per Nabla, many, if not most, readers would not be aware of the PROD-ding on the media files. Chances of extending PROD to media files are inconclusive as we're unsure whether PROD-ding helps a lot. Also, after this discussion, we can re-discuss the "unencyclopedic" criterion separately to lessen the speedy deletion requests. --George Ho (talk) 04:08, 25 February 2017 (UTC)
    • @George Ho: Issues such as the ones you bring up here are why I think this proposal should be a CSD instead of a PROD extension to files. Making a CSD for this proposal would be a lot less complicated (and probably more likely to pass) than a PROD amendment. Steel1943 (talk) 20:45, 25 February 2017 (UTC)


  • I support the idea of a "routine uncontroversial" deletion process. However, this definition of unencyclopedic file seems quite strict. The way I read it, anything that could be used in an article is ineligible, which includes low-quality images that have been superseded by better ones. It's also another completely new set of deletion logic introduced. I envision something similar to book/article PROD: Files must be orphaned or used only in the userspace at the time tagged and time of deletion, it must be tagged for a week, the tag may be removed by anyone including the uploader or processing admin, upon removal it cannot be restored. — Train2104 (talk • contribs) 06:21, 15 February 2017 (UTC)
Our original idea was similar to PROD, however it shifted over the course of development, as others felt it would be better to have it still be part of FFD, but separated. -- Iazyges Consermonor Opus meum 12:50, 15 February 2017 (UTC)
@Train2104:, it is also likely that the definition of unencylopedic will be expanded later on, the definition right now is just groundwork to get rid of the majority of unencyclopedic Images, but can be expanded later to include more. Iazyges Consermonor Opus meum 15:54, 15 February 2017 (UTC)
I will also add that WP:MOS\IMAGES states that low quality or blurry photos should not be used in articles, so in technicality low quality images do not meet the "can be used" policy. I will add a clarifier to the RFC. Iazyges Consermonor Opus meum 16:03, 15 February 2017 (UTC)
  • One thing to discuss is how it will be added to twinkle and other tools. My personal suggestion would be for there to be a box "Routine" you can tick, that adds it to the routine deletions area, instead of the normal FfD area. Iazyges Consermonor Opus meum 16:08, 15 February 2017 (UTC)
  • Honestly, I'd prefer it to work like a Prod. Jo-Jo Eumerus (talk, contributions) 16:11, 16 February 2017 (UTC)
  • This is sounding more and more like a delayed speedy (tag & wait seven days before final consideration). Is there any reason why we wouldn't use that process rather than reinventing a File PROD and all the scripts/templates that must go along with it? (It isn't like the rationale would differ such that it needs to be specified each time.) Let's discuss cases. In the interest of getting more specific than "unencyclopedic", I think we're mainly discussing personal images and logos (unused and with no associated article, uncontroversially deleted as long as the uploader does not dissent). But I think this proposal comes down to how we want to handle low-quality, unused images, such as outdated diagrams from 2007, which might be uncontroversially deleted but still could have potential use and thus are owed more scrutiny than that we give unused personal photos/logos. That's the benefit of listing those for consideration/discussion rather than tagging them into a category (as a holding cell). I worry that we will waste a lot of time referring files from File PROD back to discussion if we're not clear about which images do not warrant discussion. On the other hand, I suppose that anyone who regularly patrols FfD to rescue orphaned files could also do the same with a speedy category. Food for thought, and worth getting to the weeds on handling those edge cases sooner than later. czar 16:46, 16 February 2017 (UTC)
  • @George Ho, Train2104, Fastily, and MrX: A RFC can be closed at any time if their is obvious consensus. Is there consensus? I don't think anyone, or at least a significant amount of people, would oppose it no matter how long it runs. -- Iazyges Consermonor Opus meum 22:29, 18 February 2017 (UTC)
Go ahead and close it if you want. Preferably let's wait for a few or several more days until nothing substantially fresher and newer comes up, but you can close it right now if you like. --George Ho (talk) 01:37, 19 February 2017 (UTC)
User:George Ho I'll wait till Presidents' Day (Feb 20th for non-Americans). Iazyges Consermonor Opus meum 15:04, 19 February 2017 (UTC)
I have re-opened it per a suggestion by Fastily. -- Iazyges Consermonor Opus meum 12:48, 24 February 2017 (UTC)
I reverted the additions at WP:Files for discussion/heading and then changed the status of WP:ROD as "proposed". George Ho (talk) 13:01, 24 February 2017 (UTC)
Oppose placing extra requirements on the closing admin: if this process fails they should not have to be the "nominator" for a new FFD - the existing discussion may be able to be used - if the file could be of use elsewhere this says it should be moved to commons - but by who -that shouldn't be the admin's job either. — xaosflux Talk 13:45, 24 February 2017 (UTC)
Hardly extra, I am extremely doubtful a ROD will be opposed. Ever. The whole point Is that no one ever responds. Iazyges Consermonor Opus meum 14:00, 24 February 2017 (UTC)
There is the "Oppose" section above, Xaosflux. You can vote there. George Ho (talk) 19:40, 24 February 2017 (UTC)
I don't really oppose the entire concept of what is basically PROD for files - just that part of the implementation and think it should be discussed. Wikipedia:Proposed_deletion#Procedure_for_administrators is a decent start - its doesn't have a requirement, only a suggestion. — xaosflux Talk 20:54, 24 February 2017 (UTC)

Pinging Train2104, Fastily, and MrX to notify them about the reopening via relisting that the discussion is reopened. George Ho (talk) 03:16, 25 February 2017 (UTC); edited. 03:43, 25 February 2017 (UTC)

  • To avoid creating all sorts of red tape, just copy PROD, with just templates, no formal listing, any reason for deletion that the nominator desires, and easy undeletion. As files are less visible than articles and having a bot go around tagging articles seems a little excessive, there should be the condition that the file is orphaned outside the userspace. As it's most similar to PROD, we can call it that. I would suggest that if this is implemented, that CSD F10 (and maybe even CSD F5) be discontinued with those files tagged under this new system. — Train2104 (t • c) 03:29, 25 February 2017 (UTC)
  • I think extending Wikipedia:Proposed deletion to cover files is something to consider.— Godsy (TALKCONT) 06:06, 25 February 2017 (UTC)
    That's exactly why I opposed this proposal. There's nothing wrong with PROD and there is no reason why it can't be used on files. ~Anachronist (talk) 06:15, 25 February 2017 (UTC)
How about a separate discussion itself about the criteria for an "unencyclopedic" file? Afterwards, let's do other deletion proposals. Sounds good? Also, will this be another central discussion? George Ho (talk) 21:49, 1 March 2017 (UTC)
  • Yeah, I think the next course of action is workshopping what exactly constitutes "unencyclopedic" and choosing whether the proposal should be a new Delayed speedy criterion or an extension of the Proposed deletion process (i.e., figure this out in advance). When you have consensus, bring it back to a wider discussion. There is rough agreement that this is the right direction but the devil is in the details. czar 21:53, 1 March 2017 (UTC)
    • I agree with the previous two comments.- MrX 22:00, 1 March 2017 (UTC)
If these are truly uncontroversial, I think PROD should just be expanded to include File:'s - process exists and works, why reinvent the wheel? — xaosflux Talk 22:25, 1 March 2017 (UTC)
Exactly. ~Anachronist (talk) 23:33, 1 March 2017 (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.

Workshopping unencyclopedic[edit]

  1. No realistic potential for use in the mainspace. It cannot be used in any article, either for an article about the image, or with the image serving any useful role. (This includes low quality and blurry photos per MOS\Images.)
  2. A "vanity image", files that cannot be used by anyone but the uploader, if the uploader has made few contributions to the English Wikipedia outside of their userspace.
I didn't see anyone against the criteria, but many though it should include more. What else do you think should be added? -- Iazyges Consermonor Opus meum 01:20, 2 March 2017 (UTC)
Low quality may be OK if it is the "best quality" for something that can no longer be photographed - but if not fair use really should be on commons. — xaosflux Talk 01:23, 2 March 2017 (UTC)
So are you asking us to decide whether these two concepts count as "unencyclopedic", or are you asking for more concepts, or what? Sorry that I'm somewhat confused. Nyttend (talk) 01:26, 2 March 2017 (UTC)

How about dropping the 'unencyclopedic' clause entirely, and reframing this as an extension to PROD as suggested in the RfC? As with article PROD and AfD, I would imagine that contentious file PROD cases would inevitably find their way to FfD. -FASTILY 01:28, 2 March 2017 (UTC)

That's part of the reason I'm confused. Maybe I misread the discussion, but I thought I was supporting something that was basically PROD for images, without an "unencyclopedic" requirement. Nyttend (talk) 02:04, 2 March 2017 (UTC)

Hey, Iazyges. After reading Nyttend's comments, maybe we should do one of two options: 1) re-ask ourselves and others whether we should retain or remove the "unencyclopedic" definition, or 2) suspend workshopping the "unencyclopedic" criterion and then focus on expanding the PROD instead. We can't do both at the same time. Thoughts? George Ho (talk) 02:45, 2 March 2017 (UTC)

Part of the reason I meant to support an image PROD idea is that these, like article prods, could be restored upon request by anyone, and barring outright problems (copyvio, attack image, etc.), there wouldn't be a reason not to restore one. Right now, lacking such a process, all images not candidates for speedy have to go through FFD, and then they can't as easily be restored as if we had an image-prod process. Nyttend (talk) 02:50, 2 March 2017 (UTC)

File PROD[edit]

Okay, so dropping the "unencyclopedic" definition discussion and workshopping an extension of Wikipedia:Proposed deletion (PROD), would the File PROD adopt all the criteria used in the current PROD (not previously PROD'd, no prior deletion discussions, no prior undeletions)? Should it exclude non-free files? Would the original uploader need to be notified? Etc. czar 03:03, 2 March 2017 (UTC)

Umm... How about taking the discussion to WT:PROD? Would that be a suitable venue? George Ho (talk) 03:21, 2 March 2017 (UTC)
As for the proposal itself, we could go for the extension to "File:" namespace. Any image, free or unfree, may apply. However, the image suitable for Commons should be excluded. Original uploaders deserve to be notified. Those swapping the image contents may be optionally notified. What about notifying the WikiProjects? --George Ho (talk) 04:28, 2 March 2017 (UTC)
I'll stand by my previous statement: all the conditions of the current PROD, plus orphaned outside the userspace. — Train2104 (t • c) 03:29, 2 March 2017 (UTC)
"orphaned outside the userspace". Bad idea. Concerned this is process creep, and because some users (myself included) create galleries of files for maintenance/research purposes (ex: User:Multichill/Free uploads/2014-01-03). -FASTILY 08:46, 3 March 2017 (UTC)
Personally I think it should mirror PROD, but require it to be unused outside of userspace. Non-free images would still fall into it I think. I have no issue with dropping unencylopedic entirely, and just making files PRODable. Iazyges Consermonor Opus meum 03:54, 2 March 2017 (UTC)
If we require images to be unused in mainspace, there's no point to using the process for nonfree images, because they already qualify for deletion if they're unused in mainspace; see {{orfud}}. Nyttend (talk) 12:08, 2 March 2017 (UTC)
Seconded. Also, I'm against orphaning images just to please the PROD. Why not PROD an image without orphaning it? George Ho (talk) 18:05, 2 March 2017 (UTC)
Agree with George. Creates extra work for both someone PRODing the file and someone wanting to keep the PROD'd file. -FASTILY 08:46, 3 March 2017 (UTC)
Iazyges, seems that PROD should be a simple process for "File:" namespace and not too complicated. We can simply propose an extension at WT:PROD without one or more extra rules. Thoughts? George Ho (talk) 09:06, 3 March 2017 (UTC)
Also, if extension is approved, maybe we can create a new caption template similar to either {{Deletable image-caption}} or {{FFDC}}, or we can modify {{Deletable image-caption}} and that's it. George Ho (talk) 09:09, 3 March 2017 (UTC)
Sounds good, although an RFC will probably be needed, rather than just a proposal. Iazyges Consermonor Opus meum 19:06, 3 March 2017 (UTC)
You may if you wish, but I think a newer section is more pleasing as this subsection is getting longer. George Ho (talk) 19:22, 3 March 2017 (UTC)

Moving forward[edit]

Would anyone object to a the same criteria as article PROD, but require it to not be used in article space? I have no hard connection to unencyclopedic, and no issue with PRODing them. -- Iazyges Consermonor Opus meum 03:53, 2 March 2017 (UTC)

I'd probably add that {{Keep local}} files should be exempted. Not sure if the articlespace exemption should be limited to articlespace either. Jo-Jo Eumerus (talk, contributions) 15:43, 2 March 2017 (UTC)
Ay, a wording of non-userspace might be better. Keep local files are likely to be used, so I don't think an exemption would be necessary. -- Iazyges Consermonor Opus meum 22:51, 2 March 2017 (UTC)
Agree with Iazyges. If it's contentious, then it'll end up at FfD anyways. FWIW the goal is not to replace FfD, but rather to move routine and uncontroversial deletions into a separate process. For that reason, the simpler and less instruction-creepy this is, the better. -FASTILY 08:46, 3 March 2017 (UTC)
Now that I think about it, I'm not so sure about "orphaned outside the userspace". Clearly, anything that is used in content space (article, template, project, category, etc) should NOT be eligible. But what about stuff used only on a talk page? In a draft? As for {{Keep local}}, exempting such files is probably unnecessary bureaucracy. — Train2104 (t • c) 02:41, 4 March 2017 (UTC)
"Clearly, anything that is used in content space (article, template, project, category, etc) should NOT be eligible". Why not? There isn't even a restriction like this for article PROD. Plus, if it's contentious, then it'll obviously get kicked over to FfD. -FASTILY 09:03, 5 March 2017 (UTC)

New discussion WT:proposed deletion#File PROD has started. George Ho (talk) 09:07, 5 March 2017 (UTC)

Closure script[edit]

As the backlog starts to slowly climb again, wanted to leave a little PSA that User:Evad37/XFDcloser, a new XFD script, works great with FfD both for closing and relisting. It's still in development, so leave a comment on its talk page if you have an issue. czar 18:56, 3 March 2017 (UTC)

What about closing multi-nom discussions, like Wikipedia:Files for discussion/2016 September 1#Tales of Eternia? Is the script compatible with a multi-nom discussion? --George Ho (talk) 06:45, 5 March 2017 (UTC)
Yes, it can handle multiple nominations, provided that either:
  • there is the same result for all files (e.g. Delete all); or
  • "No automated actions" is the selected option for "After closing" (e.g. for "keep [some], delete [others]" results, the FFD discussion can be closed by the script with a custom result, but then manual followup would be required for each file to implement the result) - Evad37 [talk] 04:03, 6 March 2017 (UTC)

File PROD accepted[edit]

The consensus at Wikipedia talk:Proposed deletion#File PROD agreed to apply PROD-ding to files. The change may likely reduce backlogging of FFD noms in the future. --George Ho (talk) 04:01, 25 March 2017 (UTC)

Star Athletica v Varsity Brands[edit]

A recent Supreme Court ruling in Star Athletica v Varsity Brands will affect files on the English Wikipedia and Wikimedia Commons. The ruling essentially states that any design elements of a useful article (clothing, cars, etc.) can by copyrightable if (i) the design elements can be separated from the useful article itself into a 2D or 3D work of art, and (ii) that work of art would be copyrightable. Note that the first prong of that test is quite broad, as interpreted by the Court, basically stating that if you can take a picture of something, that's "separating" it from the useful article. Dissenting opinions in the 6–2 decision stated the obvious that just taking a picture of clothing doesn't make it not clothing, as the shape of the useful article is still present, but sadly the majority did not agree. The short of it is that many more images will now be free after applying de minimis when that principle wasn't necessary before, and images that focus primarily on useful articles may become non-free and fall under the non-free content criteria.

Full text of ruling: [1] SCOTUSblog summary: [2]

Along these lines, I have a bot task proposed that will slightly alter the text in ~400 non-free use rationales to note that the uniforms in question are under both trademark and copyright protection, not just trademark. See Wikipedia:Bots/Requests for approval/BU RoBOT 35. ~ Rob13Talk 13:43, 29 March 2017 (UTC)