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

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.

Voting

Support

1. Iazyges Consermonor Opus meum 20:08, 5 March 2017 (UTC)[reply]
2. — Train2104 (t • c) 21:34, 5 March 2017 (UTC)[reply]
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)[reply]
4. Support with the proviso that they are orphaned and unsuitable for commons: — xaosflux ^Talk 00:45, 6 March 2017 (UTC)[reply]
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)[reply]
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) Monty₈₄₅ 01:27, 6 March 2017 (UTC)[reply]
7. Support. MER-C 04:36, 6 March 2017 (UTC)[reply]
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 (talk • contribs • logs) 08:41, 6 March 2017 (UTC)[reply]
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)[reply]
10. Why not?  Sandstein  19:12, 6 March 2017 (UTC)[reply]
11. Makes sense to me. – Juliancolton | ^Talk 19:25, 6 March 2017 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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 ^(TALK_CONT) 03:22, 7 March 2017 (UTC)[reply]
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)[reply]
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)[reply]
18. Support and, while we're at it, maybe merge FfD into MfD. KATMAKROFAN (talk) 22:57, 9 March 2017 (UTC)[reply]

    @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)[reply]

    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)[reply]

    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)[reply]

    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)[reply]

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

    @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)[reply]

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)[reply]

    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)[reply]

20. Support Seems like a reasonable (and probably helpful) idea. The conditions Thryduulf states aren't bad ideas, either. Ks0stm ^{(T•C•G•E)} 00:36, 19 March 2017 (UTC)[reply]
21. Support Sounds pretty logical to me. -- numbermaniac (talk) 03:48, 19 March 2017 (UTC)[reply]
22. Support Makes sense to me. Smooth for FfD. - RYPJack (talk) 05:03, 23 March 2017 (UTC)[reply]

Oppose

Neutral

Discussion

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

Parameterized. See Template:Deletable image-caption/testcases for examples — Train2104 (t • c) 14:52, 6 March 2017 (UTC)[reply]

• 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)[reply]
• 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)[reply]
• 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)[reply]

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)[reply]

• 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)[reply]

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)[reply]

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)[reply]

If you can, Iazyges, you may withdraw the proposals that receive unanimous opposition. George Ho (talk) 04:46, 15 March 2017 (UTC)[reply]

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)[reply]

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)[reply]

Require the file to be unusable in any article

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

Support

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 (talk • contribs • logs) 06:19, 12 March 2017 (UTC)[reply]

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)[reply]

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)[reply]

   (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)[reply]

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. Monty₈₄₅ 14:45, 12 March 2017 (UTC)[reply]

   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)[reply]

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)[reply]

Oppose

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)[reply]
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)[reply]
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)[reply]
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)[reply]
5. Oppose, counter-intuitive. -- Iazyges Consermonor Opus meum 17:30, 12 March 2017 (UTC)[reply]
6. Change to here, based on comments above (plus the image caption). Callanecc (talk • contribs • logs) 08:04, 13 March 2017 (UTC)[reply]

Require the file to be unsuitable for Commons

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

Disallow on non-free files

Create something similar to ((Deletable image-caption)) and use it

Support

1. Iazyges Consermonor Opus meum 16:32, 11 March 2017 (UTC)[reply]
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)[reply]
3. Bot-created captions are good. ♠PMC♠ (talk) 05:52, 12 March 2017 (UTC)[reply]
4. Yes, bot inserted captions. Callanecc (talk • contribs • logs) 06:23, 12 March 2017 (UTC)[reply]
5. Obviously. -FASTILY 07:49, 12 March 2017 (UTC)[reply]
6. MER-C 09:00, 13 March 2017 (UTC)[reply]
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)[reply]

Oppose

Neutral

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)[reply]

   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)[reply]

Disallow on files tagged with ((Keep local))

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)[reply]

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

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)[reply]

1. Support -- Iazyges Consermonor Opus meum 01:09, 13 March 2017 (UTC)[reply]

Oppose

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)[reply]
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)[reply]

@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)[reply]

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)[reply]

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)[reply]

   @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 ^(TALK_CONT) 23:28, 14 March 2017 (UTC)[reply]

   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)[reply]

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)[reply]
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)[reply]
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)[reply]
4. Not a "requirement" no. Callanecc (talk • contribs • logs) 07:27, 16 March 2017 (UTC)[reply]

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)[reply]

Support disallowing on files marked as having derivative versions

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

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)[reply]

   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)[reply]

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)[reply]
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)[reply]

   @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)[reply]

   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)[reply]