Wikipedia talk:Proposed deletion

From Wikipedia, the free encyclopedia

File PROD RfC Planning

After a lot of discussion on WT:FFD, consensus was achieved there for a file PROD, that would operate on the same basis. Is their consensus here or is anyone strongly opposed? -- Iazyges Consermonor Opus meum 02:44, 5 March 2017 (UTC)

Oh... I see the discussion has started. For better link: Wikipedia talk:Files for discussion#File PROD. Also, is RFC tag needed? --George Ho (talk) 06:48, 5 March 2017 (UTC)
This needs an RfC. The discussion referred to above is only a workshop/brainstorm session, which is by itself not suitable for establishing policy. -FASTILY 09:07, 5 March 2017 (UTC)
Yes check.svg Added the RFC tag. George Ho (talk) 09:24, 5 March 2017 (UTC)
If this is going to be a full RfC can someone familiar with the relevant discussions summarise the background and word a neutral question? Sam Walton (talk) 18:22, 5 March 2017 (UTC)
Iazyges, can you do what Sam said? George Ho (talk) 19:21, 5 March 2017 (UTC)
@George Ho: Done. Iazyges Consermonor Opus meum 20:08, 5 March 2017 (UTC)


There is clear consensus for proposed deletion to also be applicable to files, and there was no consensus for changing the procedure substantially from that for articles, with most suggested changes receiving little to no support. The proposal receiving most support was a requirement for the file to be orphaned prior to being proposed for deletion, but this did not reach a consensus. There was consensus that a version of Template:Deletable image-caption should be created for PROD, to be shown next to images tagged for proposed deletion and added automatically by a bot.

I have created a new section, below, detailing the future steps that are necessary following this discussion. Sam Walton (talk) 14:46, 23 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.

Should files be PROD-able? Iazyges Consermonor Opus meum 20:08, 5 March 2017 (UTC)

Background: As of right now, files that are low res, unusable, or have other probelms 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: Allow files to be tagged with PROD, and follow the same guidelines and policies as PROD.



  1. Iazyges Consermonor Opus meum 20:08, 5 March 2017 (UTC)
  2. — Train2104 (t • c) 21:34, 5 March 2017 (UTC)
  3. Support Badly needed. As one of the few admins who work at FfD, I, on a daily basis, find files that need discussion which have not been discussed because they are drowning in a sea of vanity images and other unencyclopedic cruft. -FASTILY 00:28, 6 March 2017 (UTC)
  4. Support with the proviso that they are orphaned and unsuitable for commons: — xaosflux Talk 00:45, 6 March 2017 (UTC)
  5. Support. No further explanation needed, though the PROD should not be used just to orphan and then delete the images. How PROD handles the images can be discussed at another time. George Ho (talk) 00:50, 6 March 2017 (UTC)
  6. Support with the proviso that they should either be orphaned, or some notification should occur each place it is in use. (Removing the image would be an adequate notification) Monty845 01:27, 6 March 2017 (UTC)
  7. Support. MER-C 04:36, 6 March 2017 (UTC)
  8. Support per Xaosflux with the proviso that the image is orphaned and is unsuitable for Commons (so the CSD criteria would apply to non-free files). Might also need to consider an alternative for files with {{keep local}} perhaps depending on the reason it needs to be kept locally. Callanecc (talkcontribslogs) 08:41, 6 March 2017 (UTC)
  9. Support a great idea. Integration into the "Article alerts" for Wikiprojects would also be very useful :). --Tom (LT) (talk) 08:52, 6 March 2017 (UTC)
  10. Why not?  Sandstein  19:12, 6 March 2017 (UTC)
  11. Makes sense to me. – Juliancolton | Talk 19:25, 6 March 2017 (UTC)
  12. Per consensus at Wikipedia talk:Files for discussion#RFC on routine file deletion and ensuing discussion, the basic PROD criteria (notifications, minding previous noms) works. My only nagging concern is that File PROD will supersede the logical orphaned fair use deletion process (it's important for page watchers to see that a file is up for deletion even if they don't watch the file itself). This could be resolved through bot tagging, I imagine. Mixing non-free and free in the File PROD queue will also slow down processing, but that doesn't appear to concern the FfD regulars, at least. czar 21:14, 6 March 2017 (UTC)
  13. Support. I'd prefer this actually be a new WP:CSD, but action is better than no action. Steel1943 (talk) 21:37, 6 March 2017 (UTC)
  14. Support. We should have done this years ago, in my opinion. I wouldn't mind a CSD either, as long as it's truly a CSD with the 'S' allowing for 'speedy' not 7 days waiting. ~Anachronist (talk) 23:22, 6 March 2017 (UTC)
  15. Support with variances 2, 3, 4 in some form, 5 per Steel1943 below, 6 in some form,[(stricken due to the option subsection below)] with guidance recommending leaving a notification for the uploader and the user who placed {{keep local}} if it is present (as suggested by the template itself). Unlike others above, I would not prefer or support a speedy deletion criteria, as I haven't seen one with a scope and definitions I could get behind. Proposed deletion gives others time to review the request. — Godsy (TALKCONT) 03:22, 7 March 2017 (UTC)
  16. Support. To the best of my memmory, this is the reason we have PROD - articles where no one even tried to oppose the deletion becoming so common. עוד מישהו Od Mishehu 04:04, 8 March 2017 (UTC)
  17. Support. This would make it a lot easier for the people at FFD. There's no reason they should have to be swamped with random crap no one is contesting when they're trying to discuss files with actual content or copyright issues. ♠PMC(talk) 23:40, 8 March 2017 (UTC)
  18. Support and, while we're at it, maybe merge FfD into MfD. KATMAKROFAN (talk) 22:57, 9 March 2017 (UTC)
    @KATMAKROFAN: This proposal was created to make it easier for those knowledgeable in file copyright to find cases needing their attention. How would merging files in with userboxes, project pages, and other miscellaneous pages help with that? --AntiCompositeNumber (Leave a message) 17:37, 10 March 2017 (UTC)
    Noooo MfD is already bogged down enough with Draft: - now if someone could resurrect DRAFT PROD or improved Draft CSD first....... — xaosflux Talk 18:08, 10 March 2017 (UTC)
    MfD gets more attention than FfD. The draft backlog problem can be resolved by creating a separate WP:Drafts for deletion page. KATMAKROFAN (talk) 20:37, 10 March 2017 (UTC)
    I think WT:MFD would be a suitable venue to discuss separating the drafts, wouldn't it? George Ho (talk) 21:36, 10 March 2017 (UTC)

    Scratch that; drafts have been discussed there. George Ho (talk) 21:38, 10 March 2017 (UTC)

    @KATMAKROFAN and George Ho: For the record, creating a "Drafts for deletion" process has been discussed before. See Wikipedia talk:Drafts/Archive 3#Process for deleting drafts. Steel1943 (talk) 04:08, 12 March 2017 (UTC)
  19. Support iff (1) the file is not in use, and (2) the uploader (including of previous versions) and anyone who has made a significant edit to the file page (explicitly including adding {{Keep local}}) is notified. Thryduulf (talk) 09:37, 14 March 2017 (UTC)
    There is the "Nailing it down" section, Thryduulf. May you please amend your rationale and then vote on below proposals? George Ho (talk) 19:52, 14 March 2017 (UTC)
  20. Support Seems like a reasonable (and probably helpful) idea. The conditions Thryduulf states aren't bad ideas, either. Ks0stm (TCGE) 00:36, 19 March 2017 (UTC)
  21. Support Sounds pretty logical to me. -- numbermaniac (talk) 03:48, 19 March 2017 (UTC)
  22. Support Makes sense to me. Smooth for FfD. - RYPJack (talk) 05:03, 23 March 2017 (UTC)




Several possible variances from standard PROD were discussed at WT:FFD. I'm listing them all here for benefit of this discussion:

  1. Require the file to be unusable in any article
  2. Require the file to be orphaned (in all namespaces|in articlespace|outside the userspace)
  3. Require the file to be unsuitable for Commons
  4. Create a listing page connected to FFD, rather than just relying on tags
  5. Disallow on non-free files
  6. Create something similar to {{Deletable image-caption}} and use it
  7. Disallow on files tagged with {{Keep local}}

  • "Free-for all PROD", where the tagger can use any reason they wish, works fine with articles and books. Given this experience, it will probably work fine with files, so any additional restrictions need to be justified. On the other hand, few users browse the file namespace, and tags aren't shown on the Media Viewer. So it's less likely that a reader will notice the file has been tagged for deletion and possibly de-PROD it. Today's delayed CSD criteria have no special requirements, though they are a) driven primarily by legal reasons rather than suitability for the encyclopedia and b) primarily used on new (F4, F6, F7) or or orphaned (F5) files. Unlike these criteria, PROD is based on usefulness rather than admissibility, and is likely to affect many older files as well. Thus, I do think some additional rules should apply. To allow maximum flexibility, I'm leaning away from my earlier support of an orphaned-outside-userspace requirement. The application of {{Deletable image-caption}} by a bot to article uses of the file seems sufficient, as it provides visibility without restricting flexibility or placing extra burden on the tagger. A gallery WP:PRODSUM could also be made, though the date-sorted category already provides a gallery and is sufficient for patrolling. — Train2104 (t • c) 01:08, 6 March 2017 (UTC)
I appreciate your thoughts about this, Train2104. However, under the current rules of PROD, if the PROD template is removed, the PROD shall not be reinserted. Rather a deletion discussion may be needed, i.e. FFD. Just like articles, a user may reject the deletion proposal as "controversial" on a file. Thoughts? George Ho (talk) 01:16, 6 March 2017 (UTC)
Also, if an article went through the deletion discussion once, it is ineligible to be PRODded. Same will go for files. Right? George Ho (talk) 01:19, 6 March 2017 (UTC)
Should do. 01:22, 6 March 2017 (UTC)
Of course I agree with the inability to re-PROD, it's the foundation behind uncontroversial deletion (I'm assuming all the current rules are being copied over and am only considering possible additions). But the issue is in my mind is one of visibility - if I were to read a PROD'ed article, I'd immediately notice the tag and may remove it. Without the caption notice, I could see the image and never know the file was up for deletion. (didn't there use to be a bot that automatically put the notice on DI'ed files?) — Train2104 (t • c) 01:24, 6 March 2017 (UTC)
Went to Template:Deletable image-caption/sandbox and then added the PROD notice. Would that do? --George Ho (talk) 01:46, 6 March 2017 (UTC)
I think there should be two separate templates, or a parameter that specifies which one to show. — Train2104 (t • c) 06:08, 6 March 2017 (UTC)
Ehh.... two separate templates would be mind-boggling, but I won't oppose the idea. Would "speedydel image-caption" and "PROD image-caption" do? If two separate templates are not a good idea, we can try the parameter thing. However, I don't know much about the coding. Shall I ping one of template editors then? George Ho (talk) 06:54, 6 March 2017 (UTC)
Parameterized. See Template:Deletable image-caption/testcases for examples — Train2104 (t • c) 14:52, 6 March 2017 (UTC)
  • I could see a keep local exception, but I think it's implicitly covered by the "do not delete without discussion" part of the keep local template. Iazyges Consermonor Opus meum 01:23, 6 March 2017 (UTC)
  • Strong support "Disallow on non-free files" ... since such files already have alternative means of deletion in place, namely several WP:CSD. Steel1943 (talk) 21:43, 6 March 2017 (UTC)
  • If the proposal passes (well, the decision is close to unanimous), the Twinkle system must be updated to reflect the changes. George Ho (talk) 05:43, 7 March 2017 (UTC)
Iazyges, can you postpone the "Nailing It Down" section, or can you separate it "Nailing It Down" from this discussion? This is too soon, though I see unanimous support on extending the PROD to files. It's a little too distracting. George Ho (talk) 20:20, 11 March 2017 (UTC); edited, 20:21, 11 March 2017 (UTC); edited, 20:23, 11 March 2017 (UTC)
  • We can't have both orphaning the images and using the deletable image caption. If you remove the image, there's no place to put the caption. --AntiCompositeNumber (Leave a message) 15:55, 12 March 2017 (UTC)

I think we should postpone the below proposals and then continue surveying the above proposal. I don't want the RfC discussion to devolve into a mess. Also, most of the below proposals receive major opposition. Seems that applying current PROD system to files is passing unanimously. George Ho (talk) 02:20, 15 March 2017 (UTC)

The simpler this is, the better. The goal is not to replace/amend FfD, and I think some folks are getting confused by that. -FASTILY 04:10, 15 March 2017 (UTC)
If you can, Iazyges, you may withdraw the proposals that receive unanimous opposition. George Ho (talk) 04:46, 15 March 2017 (UTC)

Nailing it down

@Train2104, Fastily, Xaosflux, George Ho, Monty845, Callanecc, LT910001, Sandstein, Juliancolton, Steel1943, Czar, Godsy, Od Mishehu, Premeditated Chaos, and KATMAKROFAN:

@Train2104, Fastily, Xaosflux, George Ho, Monty845, Callanecc, LT910001, Sandstein, Juliancolton, Steel1943, Czar, Godsy, Od Mishehu, Premeditated Chaos, and KATMAKROFAN: Re-pinging since this ping by Iazyges probably didn't work per WP:ECHO guidelines. Steel1943 (talk) 04:13, 12 March 2017 (UTC)

It's obvious (18-0 as of writing) that this proposal will pass, so let's work on the specifics. Add "support" next to any of the criteria that you support. Iazyges Consermonor Opus meum 16:32, 11 March 2017 (UTC)

Require the file to be unusable in any article

SNOW closed

Iazyges Consermonor Opus meum 16:32, 11 March 2017 (UTC)

  1. I don't know how "unusable" a file is, but if that's a synonym for "orphaned", and absolutely not. George Ho (talk) 04:23, 12 March 2017 (UTC)
  2. Requiring the file to be unusable puts the cart before the horse, doesn't it?. The PROD'er should have to explain why they think the file is not needed. If they believe a file is "unusable", then they should make a case as to why. But they shouldn't have to if they have another valid rationale for deletion. ♠PMC(talk) 04:47, 12 March 2017 (UTC)
  3. Even though there is precedent for some sort of "unusable" (see WP:F10), I don't think it should be a precondition. PRODs need a reason, after all. — Train2104 (t • c) 05:03, 12 March 2017 (UTC)
  4. Unusable sets the standard too high IMHO - PRODs need a reason and can be easily contested if someone does actually see a use for the image. Callanecc (talkcontribslogs) 06:17, 12 March 2017 (UTC)
  5. Oppose per above. Defeats the purpose proposal, which is to give editors the opportunity to explain why a file is not needed. -FASTILY 07:55, 12 March 2017 (UTC)
  6. Changing per arguments above. Iazyges Consermonor Opus meum 17:30, 12 March 2017 (UTC)

Require the file to be orphaned (in all namespaces|in articlespace|outside the userspace)

If the image is being used (in any namespace), it should go to FFD as deleting it is/could be controversial. In the image PROD policy there is likely going to need to be a note that the image must not be used and orphaning it prior to PRODing might be considered gaming the system depending on the reasons behind it. (If it's a NFCC or questionable copyright issue then orphaning first might be acceptable, for example). Callanecc (talkcontribslogs) 06:19, 12 March 2017 (UTC)
If a PROD is contentious, then I'm fairly certain that it'll get kicked over to FfD, which is completely fine. I believe that is the current case with article PROD and AfD. -FASTILY 07:53, 12 March 2017 (UTC)
  1. Support, should be orphaned from mainspace already - as for the comments that someone may orphan it then prod it: (a) more editors watch articles and would see this then if it was not needed (b) if the file is in use in an article then we are putting extra burden on the deleting admin to go clean up the articles when they delete the file. — xaosflux Talk 13:30, 12 March 2017 (UTC)
    (a) You're assuming that most of the 5.3 million articles are watched by active users; this is not always true.
    (b) No, that is not true. See ImageRemovalBot.
    -FASTILY 04:27, 13 March 2017 (UTC)
  2. Support - Having the watchlist notifications to effected articles that would come from orphaning an image is a lot better than a template no one may see. Monty845 14:45, 12 March 2017 (UTC)
    Your comment seems to be misplaced; you've just supported the first half of this proposal, which happens to build on your suggestion. -FASTILY 22:12, 13 March 2017 (UTC)
  3. If the file is in use it needs discussing. If the image is superceded by a better version, replace it then nominate it - this will give added visibility. Thryduulf (talk) 22:05, 14 March 2017 (UTC)
  1. No need to orphan the file and then PROD it. Just simply PROD the file and that's it. George Ho (talk) 04:23, 12 March 2017 (UTC)
  2. I think forcing the image to be an orphan will just mean people will orphan images and then PROD them. If there's a good reason to img-PROD an image that's linked in an article, I think the burden should be on the PROD'er to explain that. ♠PMC(talk) 05:15, 12 March 2017 (UTC)
  3. Oppose. Bad idea. Very confident that there will be instances of people deliberately orphaning files to PROD them, which will cause extra work for people trying to keep said files. -FASTILY 07:49, 12 March 2017 (UTC)
  4. Oppose Extra work for the deleting admin could be solved by a delinker bot, and is likely to be limited to one article. Showing a use for something becomes more difficult once it has been removed from any article where it is used. --AntiCompositeNumber (Leave a message) 14:19, 12 March 2017 (UTC)
  5. Oppose, counter-intuitive. -- Iazyges Consermonor Opus meum 17:30, 12 March 2017 (UTC)
  6. Change to here, based on comments above (plus the image caption). Callanecc (talkcontribslogs) 08:04, 13 March 2017 (UTC)

Require the file to be unsuitable for Commons

SNOW closed
  1. Same argument as "unusable in any article". — Train2104 (t • c) 05:03, 12 March 2017 (UTC)
  2. On second thought, no need to require something. In fact, a PROD tag can be removed at any time. George Ho (talk) 05:05, 12 March 2017 (UTC)
  3. Burden should be on the PROD'er to explain why the image deserves deletion. If "so bad Commons wouldn't want it" is part of that rationale, then so be it. But it shouldn't have to be. ♠PMC(talk) 05:17, 12 March 2017 (UTC)
  4. Yes, but on the understanding (maybe this should be in the image PROD policy too) that one of the actions which should be taken before PRODing an image is that it should be copied to Commons. Maybe the bot which checks whether an image can be copied to Commons, checks images which are currently PRODed first. Callanecc (talkcontribslogs) 06:22, 12 March 2017 (UTC)
  5. Oppose. May encourage questionable file transfers. If a file has been PROD'd, then there is probably a good reason it hasn't been moved to Commons. IMO it'd be more beneficial to simply encourage editors to apply common sense. -FASTILY 07:49, 12 March 2017 (UTC)
  6. Per Fastily. Iazyges Consermonor Opus meum 17:29, 12 March 2017 (UTC)
  7. Per Fastily. Thryduulf (talk) 22:05, 14 March 2017 (UTC)

Create a listing page connected to FFD, rather than just relying on tags

SNOW closed
  1. Iazyges Consermonor Opus meum 16:32, 11 March 2017 (UTC)
  2. Oppose listing page that requires human intervention. Support bot-generated summary for ease of patrol. — Train2104 (t • c) 05:03, 12 March 2017 (UTC)
  3. Using categories works fine for PROD, I'm ok with sticking with that. Although a bot-generated summary would be fine, per Train2104. ♠PMC(talk) 05:18, 12 March 2017 (UTC)
  4. No need. Callanecc (talkcontribslogs) 06:22, 12 March 2017 (UTC)
  5. Oppose. The existing category system is more manageable IMO.-FASTILY 07:49, 12 March 2017 (UTC)
  6. Oppose Might have issues with WP:NFC as well, specifically no non-free content outside of articlespace. --AntiCompositeNumber (Leave a message) 13:13, 12 March 2017 (UTC)

Disallow on non-free files

SNOW closed

Iazyges Consermonor Opus meum 16:32, 11 March 2017 (UTC)

  1. Absolutely not. PROD-ing should also apply to non-free files. We can work on the CSD soon after the proposal is over, i.e. lessening or increasing the criteria. --George Ho (talk) 04:29, 12 March 2017 (UTC)
  2. Allow, it's a better alternative to orphan-then-F5. — Train2104 (t • c) 05:03, 12 March 2017 (UTC)
  3. Yeah, I don't understand why we would prohibit use on non-free files. We shouldn't wait to PROD if there's an applicable or necessary CSD, but if there isn't, PROD should be fine. ♠PMC(talk) 05:50, 12 March 2017 (UTC)
  4. Absolutely not, sort of ruins the point of having image-PRODing. Callanecc (talkcontribslogs) 06:24, 12 March 2017 (UTC)
  5. Oppose. No, this is a key part of this proposal. -FASTILY 07:49, 12 March 2017 (UTC)
  6. Oppose. No need for restrictions like this. Thryduulf (talk) 22:06, 14 March 2017 (UTC)

Create something similar to {{Deletable image-caption}} and use it

  1. Iazyges Consermonor Opus meum 16:32, 11 March 2017 (UTC)
  2. Have a bot place the captions for awareness as I discussed above. No tagger intervention should be required. — Train2104 (t • c) 05:03, 12 March 2017 (UTC)
  3. Bot-created captions are good. ♠PMC(talk) 05:52, 12 March 2017 (UTC)
  4. Yes, bot inserted captions. Callanecc (talkcontribslogs) 06:23, 12 March 2017 (UTC)
  5. Obviously. -FASTILY 07:49, 12 March 2017 (UTC)
  6. MER-C 09:00, 13 March 2017 (UTC)
  7. If requiring images to be orphans doesn't pass (if it does this is obivously moot). Thryduulf (talk) 22:07, 14 March 2017 (UTC)
  1. (Switched from "oppose") Changing the "caption" template is developed at the sandbox and the testcase. --George Ho (talk) 04:26, 12 March 2017 (UTC); edited. 06:03, 12 March 2017 (UTC)

    Update: Hmm... A caption notification would be less effective or overlooked. When the FFD discussion on one image ended, no one else seemed to bother removing the FFD caption, which I added. Four days after the discussion ended, I had to remove it. I think the same may apply to other types of caption notifications. --George Ho (talk) 08:04, 20 March 2017 (UTC)

Disallow on files tagged with {{Keep local}}

SNOW closed
Iazyges Consermonor Opus meum 16:32, 11 March 2017 (UTC)
  1. I don't think this should be a formal part of the policy, but it is something that patrollers should take into account when reviewing PROD's and determining whether or not to send to a full discussion. — Train2104 (t • c) 05:03, 12 March 2017 (UTC)
  2. If it's "unencyclopedic", say it's unencyclopedic. Otherwise, "Keep local" is adequate enough unless a file may deserve a PROD-ding. --George Ho (talk) 05:24, 12 March 2017 (UTC)
  3. Burden of proof is on the PROD'er. If there's a pressing reason to PROD something tagged with "keep local", the PROD'er should be free to make a case, but the reviewer should take the keep local tag into account. ♠PMC(talk) 05:54, 12 March 2017 (UTC)
  4. Shouldn't be formal part of the image-PROD policy but should be something taken into account. Callanecc (talkcontribslogs) 06:24, 12 March 2017 (UTC)
  5. Oppose. The PRODing editor should take this into account, however unencyclopedic is still unencyclopedic. Users should not be encouraged to believe that this template is a silver bullet that makes files magically immune to community processes. -FASTILY 07:49, 12 March 2017 (UTC)
  6. Switching per arguments above. -- Iazyges Consermonor Opus meum 17:32, 12 March 2017 (UTC)
  7. Oppose per Fastily. MER-C 09:00, 13 March 2017 (UTC)
  8. Oppose per Fastily, but the person placing the keep local tab must be notified of the prod. Thryduulf (talk) 22:08, 14 March 2017 (UTC)

Providing notification to article watchers

Because orphaning an image would make it impossible to put a caption on the image, and putting a caption on the image would satisfy one of the reasons for orphaning the file, only one of these options should be picked. --AntiCompositeNumber (Leave a message) 22:04, 12 March 2017 (UTC)

Pinging @Callanecc, Xaosflux, Monty845, George Ho, Premeditated Chaos, Fastily, Iazyges, and Train2104: for comment. --AntiCompositeNumber (Leave a message) 22:08, 12 March 2017 (UTC)

Please '''Support''' only one of the following:

Require that images be orphaned before PRODding
Use {{Deletable image-caption}} or similar
George Ho (talk) 22:12, 12 March 2017 (UTC) Oops, my mistake. George Ho (talk) 22:15, 12 March 2017 (UTC)
  1. Support -- Iazyges Consermonor Opus meum 01:09, 13 March 2017 (UTC)
  1. (mistakenly voted one of above options) Changing the "deletable image-caption" template is under development at the sandbox and the testcase. If the parameter version in the sandbox/testcases doesn't work, maybe create more caption templates then. However, using any of above options to orphan the file would not benefit readers. George Ho (talk) 22:15, 12 March 2017 (UTC)
  2. Oppose as premature. We only need to consider this *if* there is consensus to require orphaning in the first place. -FASTILY 04:30, 13 March 2017 (UTC)
@Fastily: This is the wrong section for this (Seems you and George Ho, and I all did the same thing). -- Iazyges Consermonor Opus meum 04:53, 15 March 2017 (UTC)
Umm.... #Providing notification to article watchers says that either option (requiring orphaning before PRODding or adding a caption template) is needed as justification for orphaning a media file. This is the right section. --George Ho (talk) 05:42, 15 March 2017 (UTC)

Require notifications to uploaded and editors of file page

@Train2104, Fastily, Xaosflux, George Ho, Monty845, Callanecc, LT910001, Sandstein, Juliancolton, Steel1943, Czar, Godsy, Od Mishehu, Premeditated Chaos, and KATMAKROFAN: (copying the mass ping above) The nominator must notify:

  • The user(s) who uploaded the current or any previous version of the image.
  • Any user who has made a significant edit to the file page or its talk page. This specifically includes categorisation and placing of templates but excludes simple spelling/typo fixes and bots.

The nominator or a bot must place a note on:

  • Any non-archived talk page the image is used on.
  • The talk page associated with any non-archived page the image is used on.

Support requiring notifications

  1. Support As proposer Thryduulf (talk) 22:28, 14 March 2017 (UTC)
    @Thryduulf: Regular (article) proposed deletion doesn't require notification; rather it is recommended (WP:PRODNOM). The more similar this is to that, the less instruction is needed. I'd rather see a proposal for [It would be better to propose] this change to prod as a whole. — Godsy (TALKCONT) 23:28, 14 March 2017 (UTC)
    I too would like to see this applied to regular prod, but file prod will remain a separate but similar process and so it needs to explicitly apply here too. Thryduulf (talk) 23:42, 14 March 2017 (UTC)

Oppose requiring notifications

  1. Per Godsy, requirement is unnecessary. We can notify related projects or individual contributors of files. --George Ho (talk) 23:35, 14 March 2017 (UTC)
  2. Oppose; on the principle that I also oppose forcing a notification for PRODs in general. It's polite, sure, but I don't think it should be a requirement. ♠PMC(talk) 03:30, 15 March 2017 (UTC)
  3. Oppose per above, and also because this is out of scope for this RfC. A general notification requirement should be discussed with the community at large in an RfC specific to that purpose. -FASTILY 04:00, 15 March 2017 (UTC)
  4. Not a "requirement" no. Callanecc (talkcontribslogs) 07:27, 16 March 2017 (UTC)

Disallow on files marked as having derivative versions

@Train2104, Fastily, Xaosflux, George Ho, Monty845, Callanecc, LT910001, Sandstein, Juliancolton, Steel1943, Czar, Godsy, Od Mishehu, Premeditated Chaos, and KATMAKROFAN: (copying the mass ping above) Files that are explicitly marked on their description page and/or talk page as being the source for other files (whether by a template or otherwise) on any Wikimedia project may not be prodded unless all derived images have been deleted (note: check they have not been moved to Commons).

Re-pinging @Train2104, Fastily, Xaosflux, Monty845, Callanecc, LT910001, Sandstein, Juliancolton, Steel1943, Czar, Godsy, Od Mishehu, Premeditated Chaos, and KATMAKROFAN: as the ping required sig. George Ho (talk) 23:19, 14 March 2017 (UTC)

Support disallowing on files marked as having derivative versions

  1. Support as proposer. Thryduulf (talk) 22:28, 14 March 2017 (UTC)
  2. I agree, this should go to a deletion discussion to ensure that all authors of the original image have been appropriately attributed. Callanecc (talkcontribslogs) 07:29, 16 March 2017 (UTC)

Oppose disallowing on files marked as having derivative versions

  1. I don't see a purpose. As said, the PROD can be removed just once. If so, the image may not be re-PRODded per current rules. --George Ho (talk) 23:20, 14 March 2017 (UTC)
    That's completely irrelevant - files with derivative versions should not be subject to PROD. Whether an image has a derivative version is entirely independent of whether it has been nominated for PROD previously. Thryduulf (talk) 23:44, 14 March 2017 (UTC)
  2. Having dirivitive versions is only an attribution issue - simply have someone check that all dirivitive images are properly attributed. We don't actually need to keep the old versions, only their attribution. 03:55, 15 March 2017 (UTC)
  3. Oppose explicitly writing this into policy. I'm not against this in principle, but spelling out *every* single specific use case is ludicrous and amounts to pure Instruction creep. Editors are expected to apply common sense, and if they can't, then we block them. -FASTILY 04:06, 15 March 2017 (UTC)
  4. Oppose Agree with Fastily here. We don't prohibit deletion of articles that have been split, and attribution of users and sources is what matters not the actual source file. — Train2104 (t • c) 15:02, 15 March 2017 (UTC)
    @Fastily and Train2014: This is not about writing every use case into policy or preventing deletion, it is about requiring active participation in a deletion discussion to ensure that attribution is done correctly. You should also note that we do prohibit simple deletion where articles have been split - see template:Split article, particularly The former page's history now serves to provide attribution for that content in the latter page, and it must not be deleted so long as the latter page exists.. Thryduulf (talk) 15:27, 15 March 2017 (UTC)
    For articles, yes, for files, no; please re-read Train2104's oppose. And yes, it is still process creep. -FASTILY 09:30, 18 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.

Implementing File PROD

Per the closure of the above discussion, these are the steps I have identified that need to occur for the implementation of File PROD. There is likely more that needs doing, so please add to the list as necessary, and mark items as done. Sam Walton (talk) 14:46, 23 March 2017 (UTC)

Policy page

Wikipedia:Proposed deletion should be updated to reflect the above consensus.

Before doing this I think there should be a discussion as to whether or not to use the same page. WP:BPROD is a totally separate page from WP:PROD. — Train2104 (t • c) 14:49, 23 March 2017 (UTC)
I made a first pass at the lead, but undid because I wasn't aware of WP:BPROD, and I agree it may make more sense for a separate page, though I think I would advocate for adding the information here since it was decided above that the process and rules would be essentially the same as for articles. Sam Walton (talk) 15:03, 23 March 2017 (UTC)
Yes, use the existing page plz. Too many pages make memorization difficult. Jo-Jo Eumerus (talk, contributions) 15:46, 23 March 2017 (UTC)
I agree, if at some point down the road FPROD ends up being so different from normal PROD that it needs its own article, it can be done. Iazyges Consermonor Opus meum 17:18, 23 March 2017 (UTC)
Updating the existing page, PROD, is better than creating a separate, new one. --George Ho (talk) 17:52, 23 March 2017 (UTC)

Caption template

A version of or option for Template:Deletable image-caption for PROD should be created.

I've created one in the sandbox. Template:Deletable image-caption/sandbox — Train2104 (t • c) 14:52, 23 March 2017 (UTC)
I think I'd personally prefer that the template made mention of proposed deletion, or linked to the page (either here or a new page, per above) that described the process. Sam Walton (talk) 15:04, 23 March 2017 (UTC)
See the testcases for the full functionality of the template. — Train2104 (t • c) 15:08, 23 March 2017 (UTC)
Ah, I misunderstood. That looks great! Sam Walton (talk) 15:10, 23 March 2017 (UTC)

Yes check.svg Done — Train2104 (t • c) 00:30, 24 March 2017 (UTC)

Caption bot

A bot task should be filed to add and remove the caption template automatically.

What about removing the caption template? I removed one four days after the FFD discussion ended. --George Ho (talk) 17:03, 23 March 2017 (UTC)
Added "and remove" :) Sam Walton (talk) 17:06, 23 March 2017 (UTC)

Bot request filed. While writing the request I ran into a question - should the caption template also be added on user pages and talk pages? — Train2104 (t • c) 17:13, 24 March 2017 (UTC)

PROD template

Template:Proposed deletion should be updated to read and function correctly on file pages, or a new template should be created.

I've created Template:Proposed deletion/dated files/sandbox, but I need someone more familiar with the intricacies of writing for substitution to put a conditional in the main template (file goes to this, all other to the article version). I'm also not sure of the wording to use...suggesting the user edit the file description page to address the concern seems like it won't work for most of the common FFD deletion reasons. Suggesting the user upload a new version may be a little WP:BEANSy. — Train2104 (t • c) 15:09, 23 March 2017 (UTC)
The template should also include some form of Commons-detection, if possible, so people don't prod files on Commons. — Train2104 (t • c) 15:14, 23 March 2017 (UTC)
Template:Proposed deletion/sandbox for service. I don't think we can detect Commons files, though. Jo-Jo Eumerus (talk, contributions) 15:55, 23 March 2017 (UTC)
I implemented a hackish Commons checker by looking for "/commons/" in the filepath...not sure the false positive/negative rate of that. — Train2104 (t • c) 16:00, 23 March 2017 (UTC)

UW templates

The various user warning and notification templates should be updated or created.

There are 15 of these, which is a lot. It shouldn't be too hard to make them vary their content based on file vs article, but do we need all 15? I only see a handful that are actually routine cases (notify creator, notify on deprod, page ineligible for PROD). The rest seem like template-creep to me. I wouldn't object taking some to TFD. — Train2104 (t • c) 00:36, 24 March 2017 (UTC)
You can do TfD if you want. I don't object to the nomination. --George Ho (talk) 19:55, 24 March 2017 (UTC)
TfD created. — Train2104 (t • c) 01:52, 25 March 2017 (UTC)

Other bot tasks

Get a bot to create the daily categories and a version of WP:PRODSUM.


A request to update Twinkle should be filed.

Regarding this point - I haven't looked at the sandbox code yet, but if {{prod/dated}} is modified to work in the File: namespace, then Twinkle won't actually need to be updated. Saves the update. Primefac (talk) 15:12, 23 March 2017 (UTC)
My idea was to use two different /dated subpages with the same master template and syntax. Twinkle would still need to be updated to show the PROD option on file pages.
I've filed a task, and will update as necessary. Sam Walton (talk) 15:16, 23 March 2017 (UTC)
I discussed this at WT:Twinkle#The outcome of proposing to apply PROD to files. George Ho (talk) 17:02, 23 March 2017 (UTC)
Retrieved from ""
This content was retrieved from Wikipedia :
This page is based on the copyrighted Wikipedia article "Wikipedia talk:Proposed deletion"; it is used under the Creative Commons Attribution-ShareAlike 3.0 Unported License (CC-BY-SA). You may redistribute it, verbatim or modified, providing that you comply with the terms of the CC-BY-SA