Commons talk:Criteria for speedy deletion/Archive 1

Content added while evading a block or ban

On English Wikipedia, pages created in any namespace by banned or blocked users evading their ban or block are candidates for speedy deletion. That seems like sound policy, and the omission of a corresponding provision here seems to be more of an oversight than an intentional decision, as I see no discussion about it on this talk page. I propose adding the following to the Commons:Criteria for speedy deletion#General reasons section:

10. Content added while evading a block or ban

Pages in any namespace created by banned or blocked users evading their ban or block. This criterion should not be applied to pages which have substantial edits by others or to transcluded templates.

—LX (talk, contribs) 15:45, 25 March 2013 (UTC)

If I understand you correctly, the IMO only practically relevant question is whether DRs filed by an IP which is likely associated to a banned/blocked user, should be tolerated. Of course, such DRs may be retaliatory, which makes them a problem for the targetted user. As far as I remember from the PK case, there was no general consensus. --Túrelio (talk) 16:05, 25 March 2013 (UTC)

I'd rather not let individual cases dictate policy, but what brought my attention to this omission was a copyright violator using confirmed sockpuppets to continue to upload files. Allowing known copyright violators to continue to tie up community resources with evaluation of their uploads obviously makes blocking/banning meaningless. Likewise, allowing banned users to tie up community resources with evaluation of deletion discussions which they had lost their privilege to create also makes blocking/banning meaningless. I can understand that people have differing views on individual blocks/bans, but to oppose effective enforcement of all blocks/bans on that basis is clearly an obstruction of the greater good. One controversial sentence does not mean that all prisons should have revolving doors. —LX (talk, contribs) 16:37, 25 March 2013 (UTC)

 Oppose I believe the intention here is to delete all uploads from sock accounts, rather than IPs. We have plenty of precedence for this not happening, as there have been several sock accounts blocked in the last year where there were significant numbers of uploads made. These were judged on their own merits as to whether they were in scope for the project and correctly met the licensing policy. We do not need to have knee-jerk reactions and encourage yet more sock hunters (some of our contributors seem only here for the LOLz of sock-hunting; it can become disruptive in its own right). Frankly, I don't care much about people having legitimate alternative accounts, and as many as they fancy, so long as all their accounts comply with policy, do not corrupt discussions intended to create a community consensus - for example by voting several times in one DR, are not used to harass other users and are not used to evade blocks, bans or other community or office conditions. Uploading can be used disruptively, but mass deletions of in-scope content should not be encouraged. --Fæ (talk) 16:16, 25 March 2013 (UTC)

+1. Where sockpuppeting is identified by copyright violators, we already can and do take that into account in applying COM:PRP. For the rest, we're better off judging uploads on merits than encouraging witch-hunts. Efforts are better spent elsewhere. Rd232 (talk) 16:33, 25 March 2013 (UTC)

This proposal is explicitly not about pages created by users having legitimate alternative accounts, so I'm not sure why you're bringing that up. This is about pages created by users evading a block or ban using alternative accounts (or IP addresses). Such accounts are by definition not legitimate. Furthermore, the proposal aims to make pages created by such accounts candidates for speedy deletion; it does not mean that such content must be deleted without exception. —LX (talk, contribs) 16:47, 25 March 2013 (UTC)

What problem is this solving on Commons? Are there examples? Rd232 (talk) 17:16, 25 March 2013 (UTC)

I think I addressed that in my response to Túrelio. —LX (talk, contribs) 18:10, 25 March 2013 (UTC)

Yes and no. I already said that I think we handle copyvios by known copyright-violating sockpuppets adequately; speedy deletion won't help very much with that I think, since the issue is really identification, and once you have that, you can apply COM:PRP. And the community doesn't agree with banning DRs from banned users, because copyright issues should be taken seriously whatever the source. Clearly abusive DRs can already be closed early and/or deleted, so again I don't see what's gained. Finally, COM:CSD is a failed proposal, so is complicating it further really likely to help it ever become policy? Rd232 (talk) 18:46, 25 March 2013 (UTC)

COM:PRP does not mention speedy deletion, and regular deletion discussions and copyvio identification take a lot of time and resources even without having to bring up uploads from banned copyright violators or verifying each and every copyvio. In practice, I'm sure many such files are speedily deleted without too much time spent on them. This is more of a proposal to document existing practices rather than to change them. Even if you consider COM:CSD a failure, no other page does a better job of describing how speedy deletion is used on this project. —LX (talk, contribs) 19:26, 25 March 2013 (UTC)

COM:PRP does not mention speedy deletion - well of course it doesn't. But the key issue is identifying sockpuppets, and once they are identified, a mass DR with "person has previously violated copyright repeatedly, and is socking to upload more - delete all per COM:PRP" is not unusual and not unduly problematic, and gives a minimum of "are you sure it's them?" process as well. Rd232 (talk) 19:48, 25 March 2013 (UTC)

You are right that many files of blocked users are speedy-deleted without carefully checking each file, depending on the quantity and type of files to check. I just don't want a rule that explicitly allows deleting anything without even looking at the thumbs or a summary, even if the user is blocked. If it looks like the continuation of the bad behaviour of the user, we should be of course allowed to speedy-delete, and these socks are usually blocked anyway. -- Rillke^(q?) 21:17, 31 March 2013 (UTC)

When I had to decide whether speedy or not I often also consulted this page besides using Common Sense. -- Rillke^(q?) 19:30, 25 March 2013 (UTC)

If it would be worded Pages in any namespace created by banned or blocked users (at Commons) evading their ban or block and fitting any other deletion or speedy-deletion criterion or intended for disruption […], or similar. And when not being applied retrospective (if it turns out after 1 year that it was created by a blocked user) = There must be a reasonable time-limit., I could support it. I just fear seeing overly hasty admins destroying useful stuff like in one case I know from en.wp. -- Rillke^(q?) 19:30, 25 March 2013 (UTC)

If one must prove that another speedy deletion criterion applies, then this one becomes redundant. I think that giving disruptive users a green light to continue to tie up resources even after they've been blocked is a bigger problem than the occasional good-faith completely reversible mistake. Deletions can easily be undone if there is consensus to do so. —LX (talk, contribs) 16:05, 26 March 2013 (UTC)

•  Oppose Content should be judged on its own merits. Of course, if a person who had been banned for copyvio started adding "own work", we might not assume good faith, but if the content is good, why should we delete it? If it is not good, then we don't need this proposed rule to get rid of it. I can think of several editors, past and present, who are very abusive and difficult to deal with who have contributed perfectly wonderful images. If one of them is banned for abusive, counter-productive activities, and other interaction issues, should we than delete his or her work? If he or she sneaks more work onto Commons, should we delete it? I think not. .     Jim . . . . (Jameslwoodward) (talk to me) 13:15, 26 March 2013 (UTC)

  That sends a very inconsistent message. "You can't participate in the project, because you're disruptive, but feel free to ignore your block. We'll continue to accept your contributions as long as they're good." If a user is blocked, they're blocked from making bad contributions and good contributions alike. If they're ready to make good contributions, they should appeal the block. —LX (talk, contribs) 16:05, 26 March 2013 (UTC)

•  Oppose Mostly per Jim. --Herby ^{talk thyme} 13:53, 26 March 2013 (UTC)
•  Comment I'm seeing multiple problems here:

If someone identifies a copyright problem, I'd prefer if the copyright problem is taken seriously instead of being speedily redacted. Therefore, I don't think that this deletion criterion should apply to deletion requests or addition of other deletion tags such as {{Copyvio}}.

If someone uploads an image and adds it to a different project, we are causing trouble to that project by deleting that image, unless the user's contributions also are unwanted on that other project. Keep in mind that file information pages only tell if a file is in use on a Wikimedia Foundation project. It might be in use on another project somewhere and deletion would cause problems to that project. It may be fine to speedily delete recently uploaded files unused on other Wikimedia Foundation projects, though.

The proposal is not clear about what to do if the blocked user uploads an image to Wikipedia or Flickr which is later copied to Commons by another user. Should that image also be speedily deleted as it was originally uploaded by a sockpuppet? This may also mean problems with the way Commons tries to be a media repository for other projects. --Stefan4 (talk) 22:44, 29 March 2013 (UTC)

 I withdraw my nomination. Clearly but weirdly, consensus is that unlike on Wikipedia, blocked users are pretty much free to edit with impunity using sock puppets. OK then. —LX (talk, contribs) 18:45, 30 March 2013 (UTC)

No, I think you have misinterpreted my comments, and maybe those of others. I said nothing about freely editing with sock puppets, just that there is no reason for this added rule. Either the contribution is good, or it is not. If it is good -- it has a solid license and good educational value -- then there is no reason to delete it. If it is not good, then we can delete it under other rules.

Please remember that all the WPs work with words, which must judged in context. It is often difficult to sort good from bad. Words can come from many sources. On the other hand, we deal with images, which stand on their own, not in context. With few exceptions, images are unique, and if we delete one because we have blocked the source, it cannot be replaced. .     Jim . . . . (Jameslwoodward) (talk to me) 19:07, 30 March 2013 (UTC)

This section was archived on a request by: —LX (talk, contribs) 18:45, 30 March 2013 (UTC)

New policy page

I've tagged this as {{Policy}} instead of {{Proposed}} because, as you can see, none of the content/policy mentioned is new to Commons. This page is just a comprehensive page describing the criteria for speedy deletion at Commons. Rehman 05:45, 6 April 2011 (UTC)

 Oppose. Either it's covered by existing policy and thus redundant or it contradicts current policy --  Docu  at 10:41, 6 April 2011 (UTC)

Could you pinpoint exactly which policy or phrase does any part of this page contradicts to? It can't (obviously) be a redundant page as nearly all projects have a page which explains their relevant CSD (see interwiki links on the left). Rehman 10:54, 6 April 2011 (UTC)

The current policy is at COM:DP#Speedy deletion. I don't really get the objection to new policy contradicting current policy, though -- unless you assume that the current policy is perfect and could never be improved. Jafeluv (talk) 11:02, 6 April 2011 (UTC)

Fixed the tag (remove {{Policy}} added by Rehman without prior discussion). --  Docu  at 11:07, 6 April 2011 (UTC)

There ought to be a criterion for promotional content in the gallery namespace. Jafeluv (talk) 11:02, 6 April 2011 (UTC)

Yes, missed that. Thanks. Rehman 11:04, 6 April 2011 (UTC)

I also think it might be a bit early to call it policy. There's no harm in leaving it as proposed for now, and change it once we all agree it's equivalent to current policy (or we all agree on the changes).
I don't think speedy deletion of out of scope images is allowed by current policy, nor is deletion of low quality pornography (I don't even think anyone agrees on what pornography is).
Other than that, I think derivative work of non-free content, failed license review and license laundering should be subsections of copyright violations. –Tryphon^☂ 12:29, 6 April 2011 (UTC)

Okay, changed to {{Proposed}}, per above and discussions elsewhere. :) Rehman 12:45, 6 April 2011 (UTC)

FOP

I note that FOP is on the list. I think we have decided that FOP issues are not subject to speedy deletion.      Jim . . . . Jameslwoodward (talk to me) 11:42, 6 April 2011 (UTC)

"No FOP" is currently in the deletion dropdown. But I guess that refers solely to DRs and not SDs? Rehman 11:45, 6 April 2011 (UTC)

I have never used it from the dropdown -- I generally close DRs of images using the DelReqHandler default for the image itself (which generates a reference to the DR) -- so from my point of view, it could be removed from the dropdown. Others may differ, but it certainly isn't a Speedy.      Jim . . . . Jameslwoodward (talk to me) 11:56, 6 April 2011 (UTC)

I have never used it either. I'll be bold and remove it from the dropdown and this page. If anyone has a problem, we could always restore and discuss... Rehman 11:59, 6 April 2011 (UTC)

Alphanumeric prefix

Hi Leyo! Please pardon me for reverting, I would like to discuss that with you. Basically enwiki requires such alphanumerics to be "memorized" by users and admins. They even sometimes call it like "Deleted per G7" and so on. Nothing wrong with it, just that it's their style, and not Commons. The big difference between enwiki's and Commons' alphanumerics are:

• Here, we will use it purely for ease of navigation and communication.
• Here, no volunteer admin or user would ever need to know what on earth GA3 should supposed to mean.

I hope you understand. I too myself to really dont like the "requirement" enwiki has for the codes, but that really is not what I am trying to do, I really do not want to copy enwiki. Looking forward to discuss on this. Kind regards. Rehman 12:22, 6 April 2011 (UTC)

I understand your argument, but I keep my opinion that we should get rid of these abbreviations. Enumerating and anchors are OK for me, but not the bold abbreviations in the title. Such a proposal was once raised in village pump, maybe even by you. --Leyo 12:45, 6 April 2011 (UTC)

Yup, I guess that would be me. ;) Rehman 12:48, 6 April 2011 (UTC)

Completely agree with Leyo here. Even if it's not made a requirement to know their meaning, admins will inevitably start using them to refer to the deletion rationale, and it will make it even harder for casual users to understand what's going on. –Tryphon^☂ 12:53, 6 April 2011 (UTC)

I think the good outweighs the bad here. As I explained here, users would have easy access to more detailed explanation, plus it also increases the ease of communication and navigation. Am sure it wouldn't be that much of a problem if a few admins use those terms (so long as they don't require others to)? Rehman 13:01, 6 April 2011 (UTC)

How can you be sure about this? Concerning navigation: The anchors may remain there, but not the abbreviations. --Leyo 13:05, 6 April 2011 (UTC)

The abbreviations at the mediawiki dropdown and this csd page + the anchors all work together; if we keep one, we should keep all. For instance, a user clicks on the "F2" link in the deletion log, landing in the CSD page, s/he sees nothing referring to F2, but instead just a random list of text. The view may be pointed to the right line due to the anchor, but that may not always work, nor would all users actually realize why the page shifted to this line... Rehman 13:11, 6 April 2011 (UTC)

I strongly oppose to add abbreviations to MediaWiki:Deletereason-dropdown. That is exactly the point, we do not want to copy en.wikipedia. --Leyo 13:22, 6 April 2011 (UTC)

Well, that is exactly what I propose, quote: "This would shorten/unclutter the deletion log, and enable us to provide a more detailed explanation on the reason why the content was deleted (at the target page at COM:CSD), thus actually helping the author/uploader understand on current policies better, and potentially reducing the current "user ignorance" level (where currently users actually don't fully understand the deletion reason in the log, and mostly ignore it and reupload)". IMVHO, I don't think we should stop such an helpful improvement just because enwiki is following a similar strategy... Rehman 13:27, 6 April 2011 (UTC)

Linking is possible without adding the abbreviation. --Leyo 13:29, 6 April 2011 (UTC)

Loops back to my comment above ("The abbreviations at the...")... Rehman 13:33, 6 April 2011 (UTC)

Yes, but I disagree. The line/title linked to should have the same text as in the deletion log. Then, nobody would get confused. --Leyo 13:39, 6 April 2011 (UTC)

Still, that would contradict the main purpose, "[...]enable us to provide a more detailed explanation on the reason why the content was deleted [via "F2"-type link from the deletion log, to the CSD page]...". Rehman 13:47, 6 April 2011 (UTC)

Good news to most of you, guess we don't need the controvercial alphanumeric prefix after all :-) But yes, we would need the anchors to prevent the deletion dropdown from going bananas. Rehman 00:23, 7 April 2011 (UTC)

This is exactly what I suggested above. Obviously, I did not express myself clear enough. --Leyo 09:07, 7 April 2011 (UTC)

Can the abbreviations be removed from Commons:Criteria for speedy deletion now? As an example “GA3” could changed to “3” (i.e. keeping numbering) or to “*” (i.e. no numbering). What is the preferred option here? --Leyo 08:01, 8 April 2011 (UTC)

This is Commons not 'pedia - we try to help folk understand here - esoteric prefixes don't do that. --Herby ^{talk thyme} 15:41, 8 April 2011 (UTC)

Rolling out links

Since no further issues are put forward on the way of linking, I will be rolling out the new linking method to the deletion-dropdown, in the way discussed above (linking whole sentences). Rehman 03:04, 14 May 2011 (UTC)

Speedy categories

Some comments on:

C2. Renamed category. - Categories that are renamed may be redirected to the new category or deleted.

C3. Duplicate or improperly named category.

Suggest to

• group in C2: Renamed or duplicate
• In C3: Improperly named

Suggest to add in categories, galleries and gallery talks a simple: "Broken or orphaned redirect". The general one is far too confusing. --Foroa (talk) 13:48, 6 April 2011 (UTC)

Done. I have completely removed C3 as it perfectly fits in C2 as well; trying to shorten the list as much as possible to avoid confusion to new contributors. As for the separate redirect-deletions, I think separating them would only increase the size of the list and cause confusion (my opinion), but I agree, the text below it need some rephrasing ;-) Rehman 14:07, 6 April 2011 (UTC)

Please keep separate C3: Improper naming for cats in Chinese or that violate basic naming rules.

Cross name space redirects far too complex for common user. Might be a separate item on the end of the general list. Implausable is very subjective. --Foroa (talk) 14:39, 6 April 2011 (UTC)

My bad, I forgot about the naming rules and thought C3 was for typos and etc; added it back. Did some changes to the redirects part, any better? Rehman 14:50, 6 April 2011 (UTC)

• I would suggest "C3. Improperly named category: The category is improperly named and/or violates basic naming rules." seems vague even though "naming rules" is linked. Is this going to make admins feel as if it is OK to delete "XXXX in YYYY" categories that don't seem to fit? I would suggest that obvious cases would fit "G2. Unused and implausible, or broken redirects." Shouldn't any others go to deletion discussion, and then "G4. Recreation of content previously deleted per community consensus." if established as bad categories? --Closeapple (talk) 08:03, 8 April 2011 (UTC)

• Also on "C3. Improperly named category" (if it's kept as a criteria): The description should say that this type of category should be redirected rather than deleted, unless it meets some other criteria as well (such as "G2. Unused and implausible"). --Closeapple (talk) 08:03, 8 April 2011 (UTC)

• There is no consensus if category redirects should be deleted or not for now, and it should be stressed in the proposal very clearly that category redirects generally can't be speedily deleted. Trycatch (talk) 10:06, 8 April 2011 (UTC)

my comments on this topic, from further down the page (my bad for starting a new section, but things are getting pretty fragmented here) Commons_talk:Criteria_for_speedy_deletion#RE:_categories_&_redirects Lx 121 (talk) 14:48, 24 June 2011 (UTC)

Empty categories

• For "C1. Empty category": Didn't "routine" empty category deletion used to require a certain number of days empty? Is that still the case? --Closeapple (talk) 08:27, 8 April 2011 (UTC)

• For "C1. Empty category": I would suggest that exceptions to speedy deletion be made for certain forms of categories that exist for comprehensiveness and ease of HotCat/Cat-a-lot use (e.g. by year, by country, by U.S. state), when categories of the same form at the same level already contain files that prove that the subcategorization is viable. Something like this, for example:

  This does not apply to categories such as "by year", "by country", "by state", if categories of the same type at the same level exist, and 3 or more of those categories contain 3 or more files or subcategories each, and 10 or more files remain that could be subcategorized into one of the empty categories. Such categories may still be deleted if empty for more than 60(?) days, or by normal deletion discussion process.

  My purpose is to prevent instant deletion of things like, say, "Category:1981 in Illinois", "Category:1982 in Illinois", "Category:1983 in Illinois" if there were still a lot of files in Category:Illinois in the 1980s that could be sorted by year. (Right now that is not the case.)

• Exactly what is the reason to delete empty categories, as long as they're named correctly and can potentially be used in the future? guillom 07:39, 15 April 2011 (UTC)
  • I can see why some of them might be deleted, but this shouldn't be done speedily as determining which have possible use (e.g the Illinois categories noted above) and which don't (e.g. "Category:1980s London trams" (there were no trams in London in 1980s)) is far too complicated for a single administrator to judge in a couple of minutes (which should be the case for all speedy candidates). Thryduulf (talk) 11:28, 26 April 2011 (UTC)
• I also do not think certain types of empty categories should be speeedy deleted if named properly. Besides the examples here we also have, e.g., latin taxon names, where higher levek taxon navigational templates may list yet to be populated taxon catgories. Simply having them there is a great help with HotCat and inhibits the creation of categories which do no follow an already standardised category naming scheme. --Slaunger (talk) 21:45, 21 June 2011 (UTC)
• I think it's a very bad idea to speedy delete categories which are candidates for being populated sooner or later, because it's contradictory to HotCat tool usage. For instance, empty categories related to administrative divisions (if reasonably large) should not be speedy deleted, as I saw too frequently for communes of France. Croquant (talk) 09:59, 22 June 2011 (UTC)

my comments on this topic, from further down the page (my bad for starting a new section, but things are getting pretty fragmented here) Commons_talk:Criteria_for_speedy_deletion#RE:_categories_&_redirects Lx 121 (talk) 14:49, 24 June 2011 (UTC)

F2, F3, F4

"Replaceable and/or low quality pornographic content", "personal events, and/or other non-educational content", and "promotional content" are not criteria for speedy deletion. The text also links to the rejected Commons:Pornography, which is inappropriate for a page up for promotion to policy. COM:PORN and Commons:Deletion policy#Regular deletion both state that a standard deletion request must be filed for these types of files. The determination as to scope is a subjective one. – Adrignola talk 18:06, 6 April 2011 (UTC)

Also see Commons_talk:Deletion_policy#Change_.22Out_of_scope.22_to_a_speedy_delete_reason_and_add_.22Sexual_content.22_as_a_valid_speedy_delete_reason - there is not concensus to speedy delete per "scope" and "Sexual content". Admins just dont care and delete anyway. But that does not mean that this is policy. --MGA73 (talk) 19:22, 6 April 2011 (UTC)

F2, F3, and F4, are all in the current dropdown, and hence used as speedies (DRs are normally closed as "Per: [LINK]", so the dropdown is almost entirely for speedies). If those are not speedies, should we remove them from the dropdown as well (so that it reduces the chances of admin error in speedying them)? In my personal opinion, I think images of F2-F3-F4, if clearly meeting the description, fits well as speedy criteria... Rehman 00:32, 7 April 2011 (UTC)

As MGA73 stated above, we already had this discussion at Commons talk:Deletion policy and the overwhelming consensus was against them. Commons:Sexual content was also rejected by many due to the suggestion that "pornography" would be subject to speedy deletion. If we wish to follow our own policies, respect consensus, and cater to the desires of our users, it would then suggest they be removed from the drop-down. – Adrignola talk 01:12, 7 April 2011 (UTC)

Then remove it is... Rehman 02:09, 7 April 2011 (UTC)

• These tend to be quite obvious by way of being crap images from a quality perspective rather than because of content. That said we do not (surely) require endless images of male genitalia even if they are ok qualitywise. How many examples for educational use do we need. --Herby ^{talk thyme} 15:40, 8 April 2011 (UTC)

Start a DR and find out :-) The result was not that we should keep all images but that it should not be a single admin that desided. History shows that some admins think that all penis pictures should be nuked and if we allow admins to delete what they do not like we will have a mass deletion (again). --MGA73 (talk) 19:13, 11 April 2011 (UTC)

Since the removing of "Replaceable and/or low quality pornographic content" from the list, I noticed we have quite some number of low quality penises loafing around the CSD categories. ;-) That SD criteria was helpful IMO. Rehman 15:00, 19 April 2011 (UTC)

Regardless of whether you think it is helpful or not, the community consensus is that these should not be speedily deleted so they should not be speedily deleted, whether you like it or not. Feel free to see if consensus has changed if you want though. Thryduulf (talk) 11:31, 26 April 2011 (UTC)

Uh, I know, I was just saying... Rehman 12:26, 26 April 2011 (UTC)

Promotional criterion

Overall, this is a great idea; I've always wished that we had a more helpful speedy deletion policy, and this is significantly better than what we have now. I'd like to see a general criterion permitting deletion of pages created for promotional purposes: the current proposed policy permits deletion of several different kinds of pages as promotional, so my suggestion would simplify things without changing the force of the proposal. Nyttend (talk) 03:39, 7 April 2011 (UTC)

So I am no longer allowed to speedy the numerous pdf files with curriculums, biograhies, (pseudo-)scientific articles, promotions, catalogs ... --Foroa (talk) 10:40, 7 April 2011 (UTC)

COM:SPEEDY states that a page that falls outside of Commons' scope can be speedily deleted, but files that are not realistically useful for an educational purpose, including those for "advertising or self-promotion" are listed under regular deletion. If that's not acceptable, then Commons:Deletion policy needs to be updated, at which point this page can reflect that one. – Adrignola talk 13:46, 7 April 2011 (UTC)

Ok, then I will not delete those pdf files anymore, there must be thousands of them. --Foroa (talk) 17:50, 7 April 2011 (UTC)

I take it that's sarcasm? They can be nominated for deletion. Or the aforementioned policy can be revised. There's thousands of files depicting nudity that some consider out of scope but we saw the blow-back that occurred when they started getting speedied. I've been watching Commons talk:Deletion policy and haven't seen any discussion there for revisions to the policy to be made in over a month. – Adrignola talk 18:22, 7 April 2011 (UTC)

Foroa, I'm confused: to what part of my statement are you responding? Nyttend (talk) 00:42, 8 April 2011 (UTC)

My comment was not completely on the right place, but to me a promotional gallery and a promotional pdf file are in the same class, except that a pdf is worse as it cannot evolve or be modified. This was combined with the fact that the speedy deletion for promotional files has been removed. I have more than enough hassle and complaints without having to go through deletion procedures. --Foroa (talk) 06:07, 8 April 2011 (UTC)

Why not just add "PDF text files" as a criterion? "Promotional" is way too large as many images at Commons are to some extent promotional in nature. --  Docu  at 06:15, 8 April 2011 (UTC)

Should self-published advertising be the criteria instead of file type?MorganKevinJ^(talk) 13:27, 8 April 2011 (UTC)

That's basically the same thing. If I take a picture of my city which happens to include a sign for my company, is that self-published advertising? –Juliancolton | ^Talk 13:33, 10 April 2011 (UTC)

• Guidelines are great - rules can be less than helpful. Sometimes you come across folk who are spamming us with webpage shots/promotional stuff that is of no value (except to them). In this case generalisations are dangerous (I also agree with Foroa). --Herby ^{talk thyme} 15:38, 8 April 2011 (UTC)

How about "self-published advertising with no clear educational purpose" MorganKevinJ^(talk) 03:22, 12 April 2011 (UTC)

I would make it "self-published advertising when it is clearly without educational purpose" instead. Using "no clear purpose" is quite broad: speedy criteria should never be able to catch anything that might actually survive a deletion discussion, right? Consider this recent upload, which was obvious self-published advertising, and did not at first seem to have "clear" educational purpose to an admin (the deletion nominator), but then ended up surviving after discussion anyway: Commons:Deletion requests/File:EntreDientes.png. --Closeapple (talk) 00:19, 13 April 2011 (UTC)

Author or uploader request deletion of recently-created unused page or file.

In my opinion, in this variant it's a very bad criterion. There are problems with some users who want to show their protest and ask to "delete all my uploads because I can". If a user has uploaded something useful but unused (e.g. a photo of a notable subject but still without Wikipedia article) and then in 29 days he/she shows his/her protest and nominates this file for deletion per G7, will we delete it? In my opinion, this criterion should work ONLY if user gives a valid reason for deletion and not whenever he/she decides his/her work should be deleted, or in case the file is not usable instead of not used. We should not offer an easy way for users who suddenly decide to delete all their uploads — NickK (talk) 19:52, 7 April 2011 (UTC)

Agreed. I would like to see a criterion equivalent to G7 of the English Wikipedia. -FASTILY ^(TALK) 02:40, 8 April 2011 (UTC)

Maybe this should be limited to 7 days. --  Docu  at 06:13, 8 April 2011 (UTC)

• This set of criteria (G7) should clarify "unused". Does this mean "Author or uploader requests deletion of recently-created unused page or file unused on any Wikimedia project other than Commons itself"? Or is it intended that speedy deletion would be cancelled by any other claim or observation of the work being used under a free license already (even off-wiki)? --Closeapple (talk) 07:45, 8 April 2011 (UTC)

• Any statement of this set of criteria should come with an explicit warning that deletion from Commons will not revert a properly permitted free license of works already in copied circulation, whether on or off Wikimedia projects; that way, an uploader will know not to involve Commons with attempts to retroactively prohibit works that are already in the wild off-wiki. (Whether it applies to works not yet in circulation, with no quid pro quo exchanged, is probably much less irrelevant to Commons process, since G7 is a courtesy anyway.) --Closeapple (talk) 07:45, 8 April 2011 (UTC)
  • And in the even wilder on-wiki, too. Today, the file is speedied on request. Tomorrow, I upload a DW of the file, properly attributed - but the link to source is red. So what? NVO (talk) 18:26, 8 April 2011 (UTC)

• Because the licenses of media (i.e. files) would appear to be much more important than those of, say, gallery pages or categories: perhaps the criteria should be split into speedy deletion requests by users for their own files and speedy deletion requests by users for their other types of pages. The other types of pages (non-files) could perhaps be put under other general criteria instead (accidental pages, etc.) --Closeapple (talk) 07:45, 8 April 2011 (UTC)

• I've always deleted (pretty much) requests from folk who have just uploaded something & then realised that they didn't read the licensing. I know that we do not need to but annoying folk unnecessarily is - well unnecessary I guess. --Herby ^{talk thyme} 15:36, 8 April 2011 (UTC)

  Here we have another side: if a user finds out that he didn't have a right to upload something and decides to delete it, he has only 30 days to read the licensing, and after that he will have to launch a DR. I agree that this criterion need to be more flexible, depending on the reason given by uploader — NickK (talk) 00:57, 9 April 2011 (UTC)

If the uploader didn't have the right to upload a given image to begin with, then it's a simple copyvio situation and can be speedied under F1... no drama involved. But I do agree that the timeframe should be shortened down from 30 days to something closer to 7. Tabercil (talk) 21:51, 9 April 2011 (UTC)

Shortened down to 7 days... Rehman 02:45, 18 April 2011 (UTC)

ok so how is this time-critical? - assume that copyvios are a separate issue; assume that minor, technical deletions, such as a bad name, or re-organization of material are handled as separate issues; assume that any other outstanding reasons for deletion (vandalism, defamatory, etc.) are separate issues, & consider this as a "standalone" question:

user uploads a file

licensing, etc. is correct, & the file is now under an irrevocable free/open source license (or it's PD; if it was ALWAYS PD, then that's a factor worthy of consideration also)

file (at least nominally) fits within commons' "scope"

the uploading user now wants the file deleted

this NEEDS to be handled as a speedy WHY?

deleting materials that meet the above criteria should ALWAYS be subject to open discussion/debate

(so should "scope" questions, too; but, separate arguement... )

Lx 121 (talk) 06:56, 24 June 2011 (UTC)

GA1. Empty gallery.

"This includes pages that contain text but no images or only a single image." Should a gallery with a single image be speedy deleted? What's wrong with a single-picture gallery? And such deletions may be problematic, because they will break links from Wikipedia articles. Trycatch (talk) 09:54, 8 April 2011 (UTC)

Nothing wrong with "single picture" ones at all. --Herby ^{talk thyme} 15:33, 8 April 2011 (UTC)

Generally I create a new category about sthg.-someone if I notice that there are more than a single media related to him/her or it. That includes also derivative works created by myself (typical example: this photo, categorised under Rugby union players from South Africa, from which I created a derivative one here; later I categorised both images under the category Bismarck du Plessis; another typical case could be when I cut the image of a single player from a photo picturing a bunch of players, and paste as a new file, and so on). My concern is, would I be wrong if I created a category for a single media file? -- Blackcat (talk) 10:41, 9 April 2011 (UTC)

I think the idea is that a single-image gallery (not category), with no imminent additions, would be useless as it does nothing more than using the file page itself and putting it in a category. My guess is that it is unlikely that single-image galleries have been linked from other places very often, unless the gallery used to have many more pictures that were later deleted; and remember that galleries, since they are "articles", can be redirected to their appropriate category (or single file) with a simple #REDIRECT statement. --Closeapple (talk) 06:03, 10 April 2011 (UTC)

A picture in a gallery can have a description (e.g. "John Smith in 1999 at AVN Awards ceremony") in contrast to a category. That's why even very small galleries could be useful. Trycatch (talk) 06:35, 10 April 2011 (UTC)

Yes, but what about a single-file gallery in contrast to a single file's own page? --Closeapple (talk) 09:30, 10 April 2011 (UTC)

Gallery is just more condensed and relevant presentation of information that saves for user mouse clicks and time (like Wikipedia vs Google). User don't need to open and decipher descriptions of many individual pictures (or a single one) -- the relevant information is gathered on a single page. Trycatch (talk) 14:58, 10 April 2011 (UTC)

Agreed Trycatch - also there is an issue with "search" - I'd prefer to see folk find relevant content as easily as they can. --Herby ^{talk thyme} 15:16, 10 April 2011 (UTC)

By no means should this be a reason for deletion: galleries with one image serve a number of important navigational purposes. Here's another reason: websites that use Commons content sometimes only use those in the gallery (like the Encyclopedia of Life, eol.org). —innotata 01:22, 22 April 2011 (UTC)

 Okay, removed the single file part... Rehman 01:32, 22 April 2011 (UTC)

F7. File is corrupted, empty, or in an unallowed format.

Should this be a speedy deletion criterion? Not infrequently such problems can be fixed -- corrupted files can be repaired, files in an unallowed format can be converted to a free format. Moreover, users (and admins as well) too often do not distinguish between problems with MediaWiki rendering (it's full of bugs) and problems with a file itself. IMO there is no need for haste in such cases. Trycatch (talk) 09:54, 8 April 2011 (UTC)

Empty is empty - pointless. Format/corrupt is another matter (tho corrupt I do tend delete to indicate re-uploading welcome) --Herby ^{talk thyme} 15:35, 8 April 2011 (UTC)

I agree with Herby's sentiments - empty I'll kill on sight. Haven't spotted unallowed or corrupt files myself so I don't know what I'd do, though I suspect I'd do the same as Herby... Tabercil (talk) 21:47, 9 April 2011 (UTC)

Is this what we're talking about? It was a fairly easy fix.--Chaser (talk) 16:27, 10 April 2011 (UTC)

Yup. Or another real-life example from today -- File:V lesnom kraju by Nikolay Tretyakov.jpg. MediaWiki still can't correctly render CMYK JPEGs, bugzilla:24854 still is not fixed. And there are a lot of similar rendering bugs. Trycatch (talk) 16:39, 10 April 2011 (UTC)

Well the latter example makes sense, provided the uploader is notified with a message telling them this is the only version and they can always just re-upload. But it might make more sense as a delayed speedy deletion: give the uploader 14 days to re-do it with a good version. Any objection?--Chaser (talk) 18:04, 10 April 2011 (UTC)

I have objections -- we already have a process of delayed speedy deletion -- it's called regular deletion. Uploader may be absent from Commons, may be already dead or may have not idea how to fix the problem. That's why community review is essential. Trycatch (talk) 05:00, 11 April 2011 (UTC)

Looking at the DR, I now see what you mean. Perhaps this is not appropriate for even delayed speedy.--Chaser (talk) 19:30, 11 April 2011 (UTC)

Another example from today's DR: File:Snapshot 2010-05-31 21-27-48.tiff (I think this file should be deleted, but on unrelated grounds, not as a "corrupt file"). But such cases are not so frequent to create for them a special deletion pipeline. Trycatch (talk) 20:17, 11 April 2011 (UTC)

Regarding the first deletion request, I believe that the easiest way to distinguish between a problem with the MediaWiki software and that of the affected file itself is to view the source of the file directly (via the upload.wikimedia.org server), but even then it would still be difficult to distinguish the two. I've recently had to DR someone's image because it didn't show up correctly in either FireFox or Chrome, but the uploader had complained in the request that it had shown up on his/her browser (which is probably an outdated IE 6 of some sort); so whatever browser someone is using for the image save IE 6 would render the image unusable. It could be a MediaWiki bug, I don't know, but for me it appeared corrupt. For a format/container/extension that doesn't fit the guidelines in Commons:File types that can easily be converted into a free format by an external program, and the resulting redirect deleted. :| TelCoNaSpVe :| 23:45, 17 April 2011 (UTC)

As for corrupt, I've understood it to mean stuff like SVG files embedding files from the local computer (which obviously cannot work), those cannot be fixed at all without input from the author and so are pointless. I've speedied them countless times in the past. -- Prince Kassad (talk) 17:30, 25 April 2011 (UTC)

Exact or scaled-down duplicate

• In "F8. Exact or scaled-down duplicate": There was the phrase "(in size or quality)" which was deleted by Trycatch (talk · contribs) because the phrase was vague. I'm pretty sure I know what the intent of that phrase was: that a file can be deleted if it's a recompressed/overcompressed/lossier JPEG than an existing file. So I've added "or is a blurrier or 'lossier' copy of an existing file that was not derived from it". The reason I've added "that was not derived from it" is that, for example, some file that appears to be a "better copy" may actually be derived from an attempt at sharpening or enhancing the older original file that then comes up for deletion; we don't want to speedy-delete the more-original image that the "better copy" image was derived from. Hopefully my edit was not controversial. --Closeapple (talk) 11:29, 10 April 2011 (UTC)
  • I am afraid that this edition will open too large room for interpretation. This criterion is already abused very often (non-duplicates get speedily deleted as duplicates), so I feel that any vagueness and any further extension of this criterion will be simply dangerous. Different JPEG-compression of the same picture is a rare enough situation to not to modify for this case highly important general rules. Trycatch (talk) 14:48, 10 April 2011 (UTC)

    OK: If it's rare, no reason to complicate things. Remove "or is a blurrier or 'lossier' copy of an existing file that was not derived from it". Is it also rare for someone to take a low-resolution image and attempt to resize it upwards (probably resulting in an awful looking thing) or otherwise upconvert it? --Closeapple (talk) 03:35, 12 April 2011 (UTC)

• Unused exact duplicate is a clearly good reason for speedy deletion IMO -- George Chernilevsky ^talk 11:18, 18 April 2011 (UTC)

agreed, but the problem is: i. making sure that ONLY exact duplicates get removed this way (& that they are unused and/or use cannot be "merged"). ii. making sure that there is not some "extraordinary reason" for keeping the dupes. some admins are (much) more careful than other admins Lx 121 (talk) 15:18, 24 June 2011 (UTC)

what about maintaining smaller-sized versions of files for use where the "BIG" files are unsuitable? - is that not also part of our mission as a "media repository"? Lx 121 (talk) 07:00, 24 June 2011 (UTC)

this topic is now being covered in (at least) 2 different sections, see: Commons_talk:Criteria_for_speedy_deletion#File:_Exact_or_scaled-down_duplicate.

Lx 121 (talk) 15:10, 24 June 2011 (UTC)

Separate criteria for OTRS?

This would be useful since not all admins have access to the OTRS system MorganKevinJ^(talk) 23:58, 10 April 2011 (UTC)

What situation do you have in mind where an OTRS-approved file would be at risk of speedy deletion? I can't think of any myself. – Adrignola talk 02:04, 11 April 2011 (UTC)

Not permission tickets but copyvio and persistent abuse of OTRS pending. Coyvio tickets are not very frequent but they need to be respond to quickly to avoid legal issues. MorganKevinJ^(talk) 01:01, 12 April 2011 (UTC)

I don't know that any image I've tagged as copyvio per an OTRS email has stuck around for a whole day. I'm not seeing that it's a big deal so long as we can at least tell them that we have started the process to delete it (and that we watch to make sure it actually is deleted, of course). VernoWhitney (talk) 02:18, 12 April 2011 (UTC)

why does an OTRS or OTRS-pending (that is not an obvious/proven copyvio) need to be done as a speedy? Lx 121 (talk) 06:46, 24 June 2011 (UTC)

Comments

Some comments from me:

1. Gallery criterion 2 (unintentionally created gallery) is redundant with general criterion 1, which includes accidental creations.
2. I don't think it's necessary or useful to limit gallery criterion 3 to "encyclopedic" articles only. Material that is out of scope and clearly not meant to be a gallery should be speedied from the gallery namespace, regardless of whether its content is encyclopedic or not.
3. Category criterion 3 shouldn't be there imho. If the category is improperly named and empty, delete it as empty. If it has content and the only problem is its naming, it should be renamed (after which it can be deleted per criterion 2). If the categorization itself is inappropriate the category should be delinked and then removed as empty.
4. The copyright violation criterion should apply in all namespaces.

Jafeluv (talk) 12:42, 11 April 2011 (UTC)

My opinions,

• For #1, good point to discuss. IMO we come across GA2 quite often, and I think having separate criterion for that provides more information and avoids confusion. Of course, that's just my view.
• For #2, I can't think of any "non-encyclopedic" content that may end up in the Gallery space; if it is copyright violation, the text should in most cases be in some way "encyclopedic" (and fall under GA3), right? The only non-encyclopedic content I can think of, that may land in the Gallery-space, falls under G3.
• For #3, yes I think that has accidentally survived unnoticed. I'll be bold and remove it, anyone can add it back if they feel it should be there.
• For #4, very little "copyright violation" ever end up in places other than files, userpages, or even gallery-space. So IMO, adding them to all would only cause confusion/clutter the page. But again, open for discussion.

-Rehman 02:47, 14 May 2011 (UTC)

Re #2: Fair enough if that's how people feel. I would rather continue to link to COM:SCOPE directly rather than COM:CSD#GA3, though -- GA3 gives the impression that the problem with such pages is that they're "encyclopedic", rather than the actual reason (that they are out of scope for this project). I would hesitate to call much of the out-of-scope gallery-namespace stuff we delete every day encyclopedic.

Re #4, sorry, I don't see your point. Because copyvios don't often end up in other namespaces, they should go through DR in the cases they do? I think copyright violations should definitely be speedyable in all namespaces.

Jafeluv (talk) 00:24, 15 May 2011 (UTC)

Redirects

If we are going to develop a detailed list of criteria (I approve in principle), I think we should spell out when redirects are speedy. For instance, I've just deleted File:Aratinga solstitiali -pet in Italy -upper body-8a.jpg as a dupe, and recreated as a redirect (per policy). However, User:Snowmanradio has tagged it for speedy as an "unused redirect". That is not part of existing policy, and isn't listed here. In some cases I'd strongly object to that reason, in this case I'm not bothered.

My general attitude is if the redirect is "harmful" in some way, delete it. If its harmless, keep it. Comparing to en here - I don't think their R2 (cross-space redirects) is appropriate for us - we routinely link from galleries to categories.--Nilfanion (talk) 21:09, 12 April 2011 (UTC)

Make it explicitly clear that "unused redirects" are not unused if they can be linked from other Wikimedia projects. We've had some problems like sysops deleting "unused or broken redirects" that were linked to from other projects, which broke a lot of imagelinks, and if IIRC created a lot of bad blood between enwp and commons too. :| TelCoNaSpVe :| 05:26, 15 April 2011 (UTC)

A broken redirect is a different matter, however. It does no good at all- the image that was in use is no longer there, and so it should be deleted and the various unlinking bots sent to work. Unused redirects are another matter, and, IMO, should generally be left alone, but a broken redirect serves no one being left live. Courcelles (talk) 04:05, 16 April 2011 (UTC)

The enwiki R2 criterion doesn't apply to redirects to category namespace. Jafeluv (talk) 08:35, 16 April 2011 (UTC)

I hope if any editor made a mistake when he publish any thing in Wikipedia or upload any file is clearly and fully advised on how to re-correct his work by giving him the proper diagnosis of the mistake he done and the proper treatment for this mistake and hope he given at least 1wk to re-correct his work. Thank you mush, EMAD KAYYAM

--EMAD KAYYAM (talk) 14:07, 17 April 2011 (UTC)

• There appears to be a general mis-understanding of the use of redirects, and they are often almost automatically marked for speedy deletion after a move/rename of files. These redirects are often then (mistakenly) deleted as "Unused and implausible, or broken redirects..", "unused" interpreted as having no links to them ('orphaned'). I don't think anyone quite knows what "and implausible" means. I think it needs to be made explicit here that the policy is to leave redirects from renames unless there is good reason (eg pejorative, offensive or crude language). I think an exception can be made for files which are uploaded and renamed shortly afterwards at the request of the uploader, perhaps <7 days as proposed for "Author or uploader request deletion.". The standard edit summary message options should be changed to "pejorative, offensive, crude or broken redirects" and "newly uploaded and renamed file redirects" (or similar). On the assumption ;-) that any other redirect deletions are few in number, they can be normal deletion requests. --Tony Wills (talk) 09:06, 27 April 2011 (UTC)

  I think the criteria for redirects should be:

  • Broken redirects. Redirects to targets that do not exist and have no obvious alternative target.
  • Newly uploaded file redirects. Redirects created as a result of file moves made less than 7 days after the upload where the previous title is not useful and there is no known use of the old title that will not automatically be fixed by a bot.
  • Author requests. Newly created redirects, including those created by page moves, where requested by the author within 7 days of creation and which are not useful search terms. This does not apply to files.
  • Pejorative redirects. Redirects from titles that are unambiguously pejorative or grossly offensive, including those only so in the context of the target, and where there is no alternative target that would not be pejorative or offensive. If a reasonable person might not find it offensive, or there is a chance it is not pejorative, then it is not eligible for speedy deletion. Merely containing sexual language, including slang terms, is not sufficient grounds on it's own.

  Things that I've rejected as speedy criteria (but which can and probably should normally be deleted normally) because there are too many exceptions, or the criteria is subjective:

  • Nonsense - other languages, systematic or technical naming, and other things can appear to be nonsense to those unfamiliar with them.
  • Misleading - if it's blatant enough to be unambiguous (e.g. "Dogs in Thailand" to "Cats in Egypt") then it's almost certainly vandalism. If it's less clear than that it needs discussion.
  • Crude or offensive - unless it's unambiguously grossly offensive then we don't need to speedily delete it. What one person finds offensive is not the same as what the next person finds offensive, so it's too subjective.

  These are my ideas and they can probably be worded better and maybe 2 and 3 can be combined? Thryduulf (talk) 10:34, 27 April 2011 (UTC)

I like Thrydulf's lists and line of reasoning. A question:

• The principal reason for keeping redirects is that while we have a bot that will change all links within WMF projects, our policy permits off-WMF users to link directly to our pages. We therefore cannot know whether a given file name has any inbound links and is actually unused in the wider world. Leaving a redirect protects those links, if any, from breakage.
• I wonder if the same line of reasoning should be applied to galleries and categories? I have no idea how many outside users illustrate web pages by saying, "For more examples of this, please look at [this Wikimedia Commons Category]".

     Jim . . . . Jameslwoodward (talk to me) 10:55, 27 April 2011 (UTC)

Yes it does, and should be a consideration, but one crucial difference is that links back to actual media may be trying to fulfill our attribution requirements - so of much greater relative importance. I tried to do some "inanchor:" google searches and only found about 5000 pages where both "wikimedia" and "category" were in links back to Commons (discounting links from other wikimedia projects), of these a lot were just link farms and wikipedia knock-offs (and I couldn't find a way to only search for anchors containing exactly "commons.wikimedia.org/wiki/category:"). But another reason for maintaining redirects is so that our wiki page version history integrity is maintained, which indicates that redirects to all name-spaces are important. (As an aside; I would like to see a "commons:" page outlining the need for redirects with the arguments for and against maintaining the various types so that we don't need to rehash this stuff every few months) --Tony Wills (talk) 11:33, 28 April 2011 (UTC)

Please bear in mind redirects created as a result of a page move and redirects resulting from a deletion of a duplicate file should be handled identically. I agree with the basic criteria Thryduulf sets out above.--22:02, 1 May 2011 (UTC)

my comments (a whole $0.02 worth!) on this topic, from further down the page (my bad for starting a new section, but things are getting pretty fragmented here) Commons_talk:Criteria_for_speedy_deletion#RE:_categories_&_redirects Lx 121 (talk) 14:50, 24 June 2011 (UTC)

U3

3. Inappropriate use of userpages.

Inappropriate use of userpages ... or those that do not fall under the project scope may also be deleted.

Wait, what? Speedy delete user pages that do not fall under project scope? I currently see no guidelines for what even determines if a user page falls under the project scope, or even how a user page would. Found it. This should be removed, out of scope has never been an accepted reason to delete, and most users would probably be very peeved to have their pages speedy deleted without their permission by an admin who thought they were out of scope than to just have a regular deletion discussion.AerobicFox (talk) 16:19, 19 April 2011 (UTC)

At the very least, promotional-only userspace pages should be deleted on sight. Jafeluv (talk) 16:37, 19 April 2011 (UTC)

Sure, but it will depend on the user. A new account created just for promotional purposes, using user pages to advertise, etc, should be speedy deleted. A general rule of thumb though should be that a speedy deletion should either 1. be immediately necessary(rmv offensive/misleading/disruptive material) or 2. be uncontroversial(deleting gibberish, maintenance, etc). If there is a chance that a user trying to work with the community in good faith will contest the deletion of their page, and there is no immediate need for a speedy deletion then it should undergo a normal deletion review, and not be subjected to a sole admin's review. Cases of spam, advertising, should be handled sperately from "out of scope".AerobicFox (talk) 21:44, 19 April 2011 (UTC)

Something somewhat related. Rehman 23:25, 19 April 2011 (UTC)

Sounds like U3 could be merged with (Gallery)4 and might better as a general criterion for speedy deletion of purely promotional material? --Philosopher ^{Let us reason together.} 11:04, 21 April 2011 (UTC)

I'd go much more slowly here. On the one hand, if a brand new user creates a user page that is purely promotional, that's certainly a {{Delete}}, but I'm not sure it needs to be {{Speedy}}. A DR is certainly more polite and gives the newbie a chance to ask what's going on and why. But, on the other hand, we have several professional or semi-professional photographers who have provided many images to Commons who have user pages that are self-promotional by any standard. Those certainly don't deserve {{Speedy}} and in most cases might not even be {{Delete}}. And, of course, there's the fact that many of our own user pages have a certain amount of bragging on them -- I've done this or that, here are my beautiful pix, and so forth. Drawing the line will not always be easy.      Jim . . . . Jameslwoodward (talk to me) 13:04, 27 April 2011 (UTC)

Right, but at least in the image cases and the second userspace case, those aren't "purely promotional," but "promotional but also within scope." --Philosopher ^{Let us reason together.} 04:54, 1 May 2011 (UTC)

File, #3

3. Derivative work of non-free content. It would be more accurate to say: "A screen shot of non-free content" because derivative work is allowed under copyright law and in this case, only confuses the issue. USchick (talk) 22:38, 22 April 2011 (UTC)

• Under United States Code: Title 17, section 106(2), it is specified that only the owner of copyright has the rights to do and authorize the preparation of derivative works. In the absence of license permitting the creation of a derivative work from the copyright owners, derivative works are a copyright violation. See also [1]. --Moonriddengirl (talk) 23:52, 22 April 2011 (UTC)
• A derivative work of non-free content is a copyright violation, period, except for exceptional cases such as where the author of the original work releases their contribution to the derivative work under a free license but not the original work (to my knowledge, this has never occurred). There are also derivative works in which the original work is de minimis, but I'm not sure whether this properly called a derivative work at all. Dcoetzee (talk) 03:31, 27 April 2011 (UTC)

Unusual duplicates

This question is easy enough on the surface, Exact duplicates can be identified, in strictest sense they are bitwise identical. Scaled down versions may be harder to judge and sometimes needs admin judgement: A downsampled version of high quality image, with a very lossy JPG compression, will have different appearance because of the higher compression.

However, I'm concerned about two cases I've seen in the duplicate queue:

1. What to do when its media not a static image: For example, see this DR.
2. What do do when the two files depict 2 different subjects, which happen to be identical. For instance, File:Blason ville fr Saint-Pôtan (CôtesArmor).svg and File:Blason ville fr LeChâtellier (IlleVilaine).svg are 2 Coats of Arms for 2 different settlements, but are the same design.

I do not think we should be speedying either of these: For the first case, the lower quality video may have real utility for low-bandwidth users trying to stream it. As for the second, the files are of different objects (which coincidentally have the same appearance). Merging them would result in a more complex and potentially misleading description, it might be better to keep the two files for that reason alone.--Nilfanion (talk) 22:19, 1 May 2011 (UTC)

Different SVGs of the same subject cannot usually be merged unless they're identical files. As for video, does the software downscale videos? If not then these are (temporarily) useful, but create a maintenance problem, since the thumbnail has to be updated every time the original video is - both need to be tagged and crosslinked carefully. Fortunately videos don't change very often, but this is a concern. Dcoetzee (talk) 11:19, 3 May 2011 (UTC)

• My main rationale for deleting duplicates (given that nothing is actually really deleted, just hidden), is that it is a maintenance issue: If you have two copies of the same image, you then have extra work to keep the two descriptions, categorization etc in sync (everytime you make a change to one, you should duplicate the change on the other) - a good waste of time, best just have one copy! "Deleting duplicates" is really a matter of "merging duplicates". By this rationale the COA question is easy, two independent sets of description (one for each settlement), means two identical images are fine.

Unfortunately this line of reasoning yields the opposite result for scaled down videos or gif animations (which can't be automatically scaled by wiki software) - the two different resolution versions should have identical descriptions, it's a pain to have to remember to update both whenever a description is changed - we should only have one version of the description. We somehow should have both files glued to the same description page - one way would be to have a subpage on one with the description etc, and transclude that into all copies. --Tony Wills (talk) 11:59, 3 May 2011 (UTC)

I suppose rather than complicating the description, having no description or categorization on the scaled down version and a simple link to the full size version would be adequate - but various bots would object. --Tony Wills (talk) 20:05, 3 May 2011 (UTC)

Yeah makes sense to me - the reason I'm unsure about the video is I don't know how competent MediaWiki (or extensions) are in handling it. I will note we have the same issue with static images too: A major reason Commons:Deletion requests/Superseded was shut down was even when the SVG was an exact replacement for the PNG, the PNG may still be useful - as it might be specifically crafted for 200px display, and render better at that resolution than the SVG. This might also apply with comparison between a 200px PNG and a 1000px PNG.

And as for identical files, different subject, another example is File:PBB GE PCDHB14 221450 x at tn.png is a duplicate of 6 other files: But each has a different caption for a different gene. I don't have the relevant knowledge to be able to merge their descriptions, and there may be good reasons to have a file for each gene. It looks possible to merge the descriptions, but it needs someone who knows what they are doing not just a random admin.--Nilfanion (talk) 10:11, 11 May 2011 (UTC)

• Yes, I don't see much point in merging those sorts of duplicates, the policy is "there should only be one copy..." it is not "must only be...". Perhaps we need an equivalent of {{Go away}} to tell future generations of duplicate squashers not to bother this one :-) --Tony Wills (talk) 13:23, 12 May 2011 (UTC)

File: Exact or scaled-down duplicate.

We should add that when deleting "Exact or scaled-down duplicate" files deleting admin has to make sure to merge matadata description pages. For example poor quality file might have much better quality description with much more details or with much better use of internalization templates. --Jarekt (talk) 02:16, 4 May 2011 (UTC)

Yes, we need to get into the habit of thinking of it as merging duplicates, rather than deleting duplicates. This merge work can be carried out by non-admins to help speed up the clearance of the duplicates category. --Tony Wills (talk) 02:54, 4 May 2011 (UTC)

 Updated proposal. It is the responsibility of the tagging user to do the merging, I mentioned that in the text. Rehman 03:22, 11 May 2011 (UTC)

No please don't :-). Two immediate problems with that approach, first many duplicate tags are added incorrectly as the user doesn't understand what "exact duplicate" is about, so following that guideline they may trash the description that actually describes the differences. I suppose the admin can revert those last edits if he/she decides it was an invalid request - but that means more admin work. 2nd does that mean the admin will take no responsibility to check that has been done, and assume the merging has been done, and just execute the deletion/redirection? --Tony Wills (talk) 09:03, 11 May 2011 (UTC)

I cleared the duplicate queue last night. There were ~75 in Cat:Duplicate, and I deleted only 18, so a quarter of them. If the onus is put on the tagging user to get the metadata merged, they may do so badly and the deleting admin will not notice unless they look carefully - resulting in poorer captions and inappropriate merger of content. I'd prefer to leave work that to the admin, as merging the descriptions is one of the steps QuickDelete.js helps the admin through - its not hard. Given that I support Jarekt's original proposal (also adding that licensing info can also be lost in a duplicate-merge).--Nilfanion (talk) 10:07, 11 May 2011 (UTC)

we have 2 different sections of the page both discussing this topic (my comment is in the above, & i'm far too lazy to write another one), see also: Commons_talk:Criteria_for_speedy_deletion#Exact_or_scaled-down_duplicate Lx 121 (talk) 15:14, 24 June 2011 (UTC)

I have on a couple of occasions uploaded a scaled-down duplicate (duly marked as derivative) of a JPEG (photographic) file and was right to do so. In those cases, the originals were so huge that my browser was having difficulty showing them; there was absolutely no reason for the photographs to be so big, and without loss of quality I achieved a reduction from 3-4 MB to 2-3 kB, so that the wiki article with the reduced pictures opened without difficulty. (It was also an opportunity to straighten the images.) If anything, it is gargantuan originals which need deletion, not the thrifty improvements. Hogweard (talk) 21:20, 26 June 2011 (UTC)

Care to give us an exact example? I mean, images in article probably won't care for the quality, as they should be 1000 pixels wide at max, but the instant you try to print them, the story will most likely be different... Esby (talk) 22:10, 26 June 2011 (UTC)

An example is: File:Palmyra Square, Warrington - DSC05907.JPG. The original is about 3.7 MB, and the derivative (in which I also straightened the picture) is just 0.2 MB. I found that the original was slowing the display down massively, but using the derivative the page appeared at once. (The derivative was not used on Wikipedia, incidentally but was used in another wiki project.) Hogweard (talk) 18:09, 27 June 2011 (UTC)

Templates

I would like to propose to add the following to the template section:
2. No longer used sub-templates
As templates evolve frequently new sub-templates are created and old unused one need to be deleted. As long as the functionality of the main template is unaffected and the sub-templates are not used they can be deleted.
3. No longer used templates
Exceptions are templates intended to be substituted and well documented utility templates. Special care should be paid to language specific internationalization sub-templates which might be used even if Special:WhatLinksHere utility does not list any transclusions. In case of most templates deletion should be discussed with the creator or on the template talk page.

End of proposed addition. Templates rarely go through standard deletion process and are regularly deleted. One of the most common reasons is that template is no longer used. The above addition, I believe captures current practices. --Jarekt (talk) 02:56, 4 May 2011 (UTC)

Makes sense. Maybe it could be extended to all kinds of subpages of deleted / missing pages. –Be..anyone (talk) 03:15, 7 July 2011 (UTC)

Back up a bit

If we are serious about "The criteria for speedy deletion specify the only cases in which administrators have broad consensus support to, at their discretion, bypass deletion discussions and immediately delete files or pages.", don't we need to back up a bit as it transpires that this discussion nor vote hasn't been widely advertised. I think broad concesus requires that the broader membership of the Commons community are involved. So why not place notices on village pumps (there is more than one) and other usual places. --Tony Wills (talk) 23:44, 12 June 2011 (UTC)

Ah what the heck. 1. Rehman 02:26, 13 June 2011 (UTC)

I have now had the time to read all the submissions here and review the changes on the proposed policy page. I don't think we have been very methodical in updating the proposed policy in line with the discussions here, and will go through each one. But first I would like to discuss an overview of the proposed policy: There appear to be two types of speedy delete, there imperative deletions eg attacks or "obvious" apparent copyright-violations and then there are deletions for everyday maintenance (these lists are of course subject to refinement).

Imperative deletions:

Apparent copyright violation.

Fair use content.

Derivative work of non-free content.

Failed license review.

Missing essential information.

License laundering.

Inappropriate use of userpages.

Content intended as vandalism, threat, or attack.

Recreation of content previously deleted per community consensus.

Temporary deletion for history cleaning or revision suppression.

Office actions.

Maintenance deletions:

everything else

In line with the preamble of the proposed policy I think we need to handle the two classes of speedy deletion seperately and as a matter of policy:

For the general class of "imperative" deletions, the normal recourse if someone wants the decision reversed would be to talk to the deleting admin and failing that, an undeletion request.

But for "maintenance" type deletions, as they represent no immediate harm to the project, there should be a speedy undelete if someone wants the decision reversed. If necessary then a DR can be filed and normal processes followed. --Tony Wills (talk) 19:04, 14 June 2011 (UTC)

I like the classification of the criteria, and I support the adding of text explaining these. But I do not support reshuffling the criterion according to this (if that was proposed). Rehman 03:52, 15 June 2011 (UTC)

agree with the basic principle of separation into categories along these lines; respectfully disagree about some of the sub-categorizations.

especially: maintenence = "everything else"

that seems dangerously broad (which, i would argue, is a KEY PROBLEM with the draft text of this proposal as a whole)

how about we consider "time-critical" deletions & "non-time-critical" deletions?

time-critical deletions would be (basically):

i. anything that is clearly illegal (prooven copyvio, child porn, etc.)

ii. malware; i.e.: anything that is infecting user's computers and/or breaking mediawiki/our servers/etc.

open to other suggestions for what should be considered as "time critical" here...

i am NOT including files being used for vandalism as a "time-critical deletion" on commons (anymore), since we now have reasonably adequate anti-vandalism tools in place on most/all major projects, & deleting a file is no longer necessary to prevent its use in this manner. therefore, such files can be properly considered on questions of scope, & their deletion is no longer an "urgent" matter.

non-time-critical deletions would be, to borrow a line from above "everything else".

(which raises the obvious question: why should ____-type deletions (which are non-critical), be pushed through on speedy? consider that as a REAL question, not simply as rhetoric)

one reasonable example of a "non-time-critical" deletion -type, that could justifiably be done as speedy would be absolutely non-controversial, technical, maintenance work; removing exact duplicates, tidying up misnamed-whatever, etc.

or a user wanting their own "mistakes" removed (excluding correctly licensed, non-duplicate media files, which have merit re: scope; such deletions should certainly be discussed!)

i'm sure other users could offer many further examples or non-time-critical deletions that they feel should be done as speedy, but it is MUCH easier to draw up an "exclusive" list of deletions which ARE time-critical, rather than an "inclusive" list of ones that aren't...

& i've digressed enough; as i said @ the beginning: support the basic concept of organizing speedy deletions by "types", disagree about the details, & suggest "time-critical" & "non-time-critical" as the obvious, logical primary criteria for this categorization of the SPEEDYs.

Lx 121 (talk) 14:13, 24 June 2011 (UTC)

G3 - Content intended as vandalism, threat, or attack.

I am missing privacy violation in this. Privacy violation is not exactly vandalism and it is not always a threat or attack. I think it should be added. Lymantria (talk) 07:33, 22 June 2011 (UTC)

how do you define it? & what standard of proof, to justify a speedy? Lx 121 (talk) 12:01, 22 June 2011 (UTC)

Like FOP, privacy is so dependent on what each person sees in an image and the local law that it should never be a speedy. As I understand it, German law would forbid many images that would I, an American, would not even question -- that is not to say which is correct, just that they are so different that it difficult to consider using speedy.      Jim . . . . Jameslwoodward (talk to me) 15:30, 22 June 2011 (UTC)

Exactly... [2] as an example. ·· —N·M— ^talk ·· 06:23, 24 June 2011 (UTC)

But when it comes to publishing of telephone numbers, (email) addresses and that kind of personal stuff (not of the user himself), I suppose that would be a privacy violation both in the more narrow and more wide interpretations of privacy violation - here in Europe and there in North America respectively - wouldn't it. It is not a threat or attack. I think it would be worth thinking of adding a subject like this. Kind regards, Lymantria (talk) 14:29, 29 June 2011 (UTC)

Privacy is already covered by the current Commons:Deletion policy, at COM:D#Privacy. One of the weaknesses of this proposal is that it isn't clear [... well not to me it isn't...] what would happen to the speedy-related content in that policy; would everything be removed from there if this policy is adopted? Rd232 (talk) 15:15, 29 June 2011 (UTC)

Indeed. And then you have two policy pages covering the same subject and any changes to one have to be reconciled with the other. Merging the content of this page to COM:DP was my original position and the (non-)outcome of the discussion reaffirms this belief. – Adrignola talk 15:19, 29 June 2011 (UTC)

some points from S's vote

the following (was moved to here) is a copy of my vote's comment in section #Moving_to_making_this_an_official_policy.

• • It is not clear to me why we need F76? If it is a copyvio F1 (with specific comment added) does apply if not it should be a DR.
  • F8 should emphasize to merge the file page contents before deletion to not loose information. The user vs. bot thing is not clear to me. Why should a "user" upload be preferred if it is newer?
  • C1 is not general - should include a warning not to delete empty categories right away and maybe ask the creator if in doubt.
  • T2 should be a DR.
  • Also I oppose to silently legitimating office actions (G9) with this policy.

--Saibo (Δ) 20:52, 22 June 2011 (UTC)

I don't understand the first point; are you sure you are referring COM:CSD#F7? For the second point, it is to avoid something like this (there are many more such discussions, this is the latest), and to avoid bots sending messages to bots. For the fourth point, it depends; there are a huge number of templates that are tagged as unused that always come up at CAT:CSD, which are legitimate speedies and would take unnecessary time and resources going through a DR. We could discuss this in a new section. And as for the fifth point, please see my reply to Tabercil above. Rehman 02:00, 22 June 2011 (UTC) (changed numbering since you missed (my formatting fault) my third point. --Saibo (Δ) 20:52, 22 June 2011 (UTC))

Typo - I meant F6 (lic. laundering), thanks and sorry. More comments by me later this day. Cheers --Saibo (Δ) 03:45, 22 June 2011 (UTC)

@2 - COM:CSD#F8: Apparently a bad wording. Should be "comparing between a author uploaded file ...". Is this what F8 should mean?

@4 - COM:CSD#T2: Why should templates be different from files/pages? Also there is no advice to be careful or ask the creator/contributors. It is general: "you may delete what you like (as long as it is unused) - a carte blanche". Isn't it?     As said in my main comment: Admins can also do other deletions which are not covered by these criteria if they think it is okay.

@5 - COM:CSD#G9: I will not support this policy as long as we legitimate deletions for every reason WMF likes. I have a new name for this: "Jimbo rule". ;-)

I hope I did understand everything. Please correct me if I am wrong. Cheers --Saibo (Δ) 20:52, 22 June 2011 (UTC)

F1 title

It appears to me that the current title of F1 "Apparent copyright violation" (emphasis added) does not really match the text of F1 "Content is clearly a copyright violation..." (original emphasis). I suggest that the title of F1 should be changed to "Blatant copyright violation", "Obvious copyright violation", or something else along those lines. cmadler (talk) 17:42, 23 June 2011 (UTC)

 Support as I mentioned above. Carl Lindberg (talk) 18:41, 23 June 2011 (UTC)

strongly  Support, for reasons stated above; invites abuse, with NO open review of the deleting admin's actions possible. also wish to note that this is only ONE of the many loopholes in this poorly-drafted proposal, that need fixing. calling a "quasi-vote" on this proposal, with such a loosely-worded draft, & without even having a locked-down version of the text, was grossly premature. at least the "sex policy" people had their stuff in good order, when they asked for a vote. Lx 121 (talk) 05:11, 24 June 2011 (UTC)

sorry, when i first commented in this section, i slightly mis-read the original posting & thought the user was sreferring to a difference between the wording of the text in the existing deletions policy page & the equivalent text in this new proposal for speedy; it's still not good to have a dissonance in the text, & could end up being "corrected" later, in a way that broadens speedy powers still further. the rest of my proceeding comment should be taken as a "general rant" about the problems with the draft text & the way this vote has been "organized"; rather than as specific to this (sub-)issue. Lx 121 (talk) 14:38, 24 June 2011 (UTC)

 Oppose What is perceived as clear copyright violation is not necessarily one. In most of these cases, files get speedied because they are a copy of a file found elsewhere on the web. This is indeed in most cases a copyright violation but in some cases this happened with permission of or by the copyright holder. Cases where the copyright violation is absolutely certain are rare. They are typically restricted to those cases where we get a statement of the copyright holder through OTRS. --AFBorchert (talk) 06:36, 24 June 2011 (UTC)

i'd be quite happy to have a stricter "standard of evidence" for "proof-of-copyvio-therefore-speedy", but it's already a "disputed issue" within the community (i.e.: we don't have a consensus on consistent standards for that).

however, BROADENING the terms of speedy-copyvio, as this policy proposal does, is pretty clearly a bad idea... Lx 121 (talk) 07:35, 24 June 2011 (UTC)

Whether or not one supports or opposes the proposed guideline/policy, and whether or not one supports this particular item within the guideline/policty, I'd hope that we could at least agree that headings/titles should accurately describe and match the content under them. My point is simply that this title does not match the content within it, so obviously either the title or the content should be changed to make them consistent. It appears to me that the error is in the use of the word "apparent" in the title, and that the title should be made to match the content under it, so that's what I suggested. I'm neither supporting nor opposing the full proposal, just trying to ensure that we all understand what it actually says! cmadler (talk) 13:30, 24 June 2011 (UTC)

& yes, i was completely off-topic from the original point (sorry @cmadler). agree that the title & contents should match, & would very much prefer the "tougher" standard (clear/prooven copyvio), rather than the "weaker" one (apparent copyvio). Lx 121 (talk) 14:30, 24 June 2011 (UTC)

RE: categories & redirects

except for time-critical fixes, like vandalism, or EXTREMELY obvious technical moves, category (& redirect) deletions should ALWAYS be discussed.

cats & rdrs are part of a SCHEMA of organization; just because a category is currently empty does not mean that it shouldn't be there.

if we have, for example: Germany in 1790, 1791, 1792, 1793, etc.

certain years might be empty, but that doesn't mean they should not be listed.

& YES THERE ARE ADMINS WHO WOULD DELETE SUCH THINGS as "empty/unused"

perhaps not in such a blindingly obvious case (not anymore, at least; one hopes... ); but in other situations, where there is a less overwhelming combination of obviousness & precedent, then yeah.

it happens, & it's worse when the deletion is by someone who is unfamilliar with a technical subject, or doing "pointy" edits, or both.

Lx 121 (talk) 06:41, 24 June 2011 (UTC)

...& ok, there are already at least 3 discussions already going on above, about the same subjects (not to mention various, sundry mentions in other comments). things are starting to get a bit fragmented on this page & it might be time to re-organize a bit(?)

about categories #1 Commons_talk:Criteria_for_speedy_deletion#Speedy_categories

about categories #2 Commons_talk:Criteria_for_speedy_deletion#Empty_categories

about redirects Commons_talk:Criteria_for_speedy_deletion#Empty_categories

Violation of personality rights

There exist gross violations of COM:PEOPLE and our recently passed resolution which should be deleted on sight or when a justified complaint is received (through OTRS). This is currently missing in this policy and in my opinion the current state shouldn't be made policy as long as this important point is omitted. --AFBorchert (talk) 06:43, 24 June 2011 (UTC)

refer to above, who is going to decide what is or isn't appropriate? If the admin is a "keep-it-all type" it won't go anywhere and if the admin is a "deletionist" everything will be gone. Who will watch the watchers? ·· —N·M— ^talk ·· 07:08, 24 June 2011 (UTC)

Nashville Monkey, we get from time to time complaints regarding violations of personality rights through OTRS. And in some of these cases a swift and urgent action is required, i.e. a speedy deletion to protect the depicted person in conformance to our policies (i.e. COM:PEOPLE) and applicable law. --AFBorchert (talk) 08:44, 24 June 2011 (UTC)

Oh, I understand that completely. I'm talking about images where someone is over-vigilant and applies their own form of (possibly warped) judiciousness to the process. Which is why, if proper safeguards against such things were in place, I would be less opposed.·· —N·M— ^talk ·· 08:50, 24 June 2011 (UTC)

Nothing happens here without having others who can check such as a case. For oversight, checkuser, or OTRS, we have also off-wiki communication channels (mailing lists) which allow to discuss sensitive things among others who have full access to these cases. Hardly anything happens in this area without consulting the opinions of others. But it would not be helpful in some of these cases to discuss it openly here before the file is deleted. This could be even more harmful for the victims. However, I would like to let all know openly that such processes can take place by having a clause in the policy which mentiones this. And even then it can still be discussed at COM:UDEL or by asking others who have access to recheck a particular case. --AFBorchert (talk) 09:20, 24 June 2011 (UTC)

(edit conflict, i'm inserting my comment here, to avoif confusion, as it is the original post i'm addressing)

that's nice, but it's an OFFICE document, which was "passed" by the wmf board, & NOT by the commons' community, or by the wm community as a whole.

(i don't remember any community-wide discussion of this text, before it was "approved"; did i miss that somehow?)

it's also a "non-binding resolution", that "urges", rather than "orders".

These two points are related - it urges careful consideration of these issues without going into the specific details involved on any particular project. People familiar with Commons, for instance, are needed to work out a policy on personality rights that works here. --SJ+ 16:11, 4 July 2011 (UTC)

finally, it's a badly thought out & weasel-worded text; if applied literally, as written, it would result in the removal of VAST quantities of legit material.

for example: "The evidence of consent would usually consist of an affirmation from the uploader of the media, and such consent would usually be required from identifiable subjects in a photograph or video taken in a private place." - anyone see any potential problems with this part?

does the original upload licensing NOT count as an "affirmation"?

if not, then what standard of proof is required? - should we ADD an "affirmation" to the upload process?

No, the current upload process does not include a step where one affirms personality rights release of any people in the photo. Adding one to the process, or a field for it, would be a fine way to improve tracking this. --SJ+

& who is going to administer/verify this stuff? OTRS?

if OTRS is running it, then what about openness & transparency & the ability of the community to review everything?

OTRS is limited to the "select few", who would now have an effective & unmonitored (by the open community) veto over materials @ commons.

I agree that OTRS is a poor way to handle this - simply getting uploaders to specifically state rights release would be a step. personality-rights washing, like license-washing, will always be a concern; newbie accounts that only upload one set of photos should be [and generally are] held to higher standards of validation for both copyright and personality rights, when there's reason to believe the images are not theirs. --SJ+

no offense is intended to the previous commentor, & nothing i've said is meant to be taken personally by them, BUT this is typical wmf/office cruft. high-minded, detached from "on the ground" realities, & impractical.

If you care about the topic, I would be delighted to see suggestions for how to improve on the language. You could publish it as an essay here, or even suggest an amended text for the resolution for the Board to consider. --SJ+

fulltext of the resolution follows:

This resolution regarding subject consent for images of identifiable living people was approved unanimously on 29 May 2011.

The Wikimedia Foundation Board affirms the value of freely licensed content, and we pay special attention to the provenance of this content. We also value the right to privacy, for our editors and readers as well as on our projects. Policies of notability have been crafted on the projects to limit unbalanced coverage of subjects, and we have affirmed the need to take into account human dignity and respect for personal privacy when publishing biographies of living persons.

However, these concerns are not always taken into account with regards to media, including photographs and videos, which may be released under a free license although they portray identifiable living persons in a private place or situation without permission. We feel that it is important and ethical to obtain subject consent for the use of such media, in line with our special mission as an educational and free project. We feel that seeking consent from an image's subject is especially important in light of the proliferation of uploaded photographs from other sources, such as Flickr, where provenance is difficult to trace and subject consent difficult to verify.

In alignment with these principles, the Wikimedia Foundation Board of Trustees urges the global Wikimedia community to:

Strengthen and enforce the current Commons guideline on photographs of identifiable people with the goal of requiring evidence of consent from the subject of media, including photographs and videos, when so required under the guideline. The evidence of consent would usually consist of an affirmation from the uploader of the media, and such consent would usually be required from identifiable subjects in a photograph or video taken in a private place. This guideline has been longstanding, though it has not been applied consistently.

Ensure that all projects that host media have policies in place regarding the treatment of images of identifiable living people in private situations.

Treat any person who has a complaint about images of themselves hosted on our projects with patience, kindness, and respect, and encourage others to do the same.

Approved 10-0.

Lx 121 (talk) 07:27, 24 June 2011 (UTC)

Lx 121, the WMF foundation is the owner of this site. They kindly respect the community but it is quite unwise by the community to forget that we are operating on private property which requires some principal guidelining resolutions which are also the ground on which this remains an organization which gets funded by donators and keeps its tax-free status. And the community is represented on the board. We just had the elections. --AFBorchert (talk) 08:44, 24 June 2011 (UTC)

closure date of the vote / translation ?

I am feeling sorry to ask but:

• When is the supposed closure date of the current vote?
• what will be done if this policy is accepted in this state and that the before-mentioned problems and technical abuses happend ?
• why is the policy proposal only in english with no translation proposal available at all ?

Esby (talk) 20:16, 25 June 2011 (UTC)

Moving to making this an official policy

As discussions progress above, feel free to vote in making this an official policy. Rehman 12:45, 6 April 2011 (UTC)

• Merge to Commons:Deletion policy. Shouldnt be sepreate

• {{Oppose}} - it's way too early for a voting, the proposal wasn't even announced anywhere. Trycatch (talk) 10:03, 8 April 2011 (UTC)

•  Oppose per Trycatch - anyway guidance and good admins are infinitely more useful that folk who endless debate how many angels can balance on a policy. --Herby ^{talk thyme} 15:43, 8 April 2011 (UTC)

•  Support. I think we've reached a fairly good CSD standard, thanks to the many work/discussions above and elsewhere. It's about time to make this official. Rehman 11:46, 10 June 2011 (UTC)

•  Support I think speedy deletion is essential tool for fighting flood of copyvio, but it is also tricky business which can be easily abused. A policy would help in defining the standard code of conduct. --Jarekt (talk) 12:38, 10 June 2011 (UTC)

•  Oppose I think more lattitude should be allowed for speedy deletion. For example, new files that consist of vandal-text written into an ms-paint file. I suggest a "new files that are clearly out of scope" category. --99of9 (talk) 13:22, 10 June 2011 (UTC)

"New files that consist of vandal-text written into an ms-paint file" falls into the existing COM:CSD#G3. Rehman 13:28, 10 June 2011 (UTC)

Ok, fair enough, I'll alter that slightly. I don't mean vicious attacks, I just mean plain obvious out of scope rubbish. --99of9 (talk) 00:00, 11 June 2011 (UTC)

• Merge to Commons:Deletion policy. There's no sense in having two separate pages on this. – Adrignola talk 14:16, 10 June 2011 (UTC)

Strong oppose to merge. SD is different of DR, and these two should be kept on separate pages for ease of understanding to readers. Of course, the SD part of the Deletion Policy could be pointed to this page, bot not vice versa; a simple summarized explanation may be kept at the policy page instead. And besides, nearly all projects have a page referring to "Criteria for speedy deletion", it would be consistent to have one here too. Rehman 14:32, 10 June 2011 (UTC)

We'll have to agree to disagree. Wikibooks, my original/home wiki, simply has Wikibooks:Deletion policy. And Commons is similar in having a section on speedy deletions at Commons:Deletion policy#Speedy deletion. A deletion policy covers speedy and standard deletion and I don't agree that splitting it up eases understanding. You're going to be linking to shortcuts in the deletion reasons anyway. They can simply reside at Commons:Deletion policy. – Adrignola talk 19:09, 10 June 2011 (UTC)

I still don't think we should move content from this page and merge into the Deletion Policy. But of course, others' views may differ. Rehman 03:45, 11 June 2011 (UTC)

•  Comment I have no problems with the stated proposal, just noting File/3 (“Derivative work of non-free content.”) is IMO just a special case of File/1 (“Copyright violation.”), the same might be even said about a few others File-related reasons. Also, I think “obviously out of scope” should be a speedy reason as well… Finally, General/7 is just strange: Either you want to prevent removing files used by external websites, or you don’t care. This has nothing whatsoever to do with uploader-requested deletion, it’s completely orthogonal to that. Should you want to care for external websites, you need to ditch all “unnecessary” file deletions (i.e. all except copyright violations and the like). E.g. an “exact or scaled-down duplicate” might be used elsewhere as well. Also note that not even going through a regular deletion request would help in this case. Do you think all reusers of Commons’ images watch Commons image description pages? There ideally should be a mechanism similar to GlobalUsage, but… --Mormegil (talk) 15:20, 10 June 2011 (UTC)

•  Comment I share some of the concerns of Herby and would like to see the comments by those admins who perform most of the speedy deletions like Túrelio, Martin H., Jameslwoodward, Fastily, Foroa and others. And I've following notes regarding some individual points:

  1. F1: Content is clearly a copyright violation. In most of the cases, we simply assume that we have a copyright violation if we, for example, see another copy of a particular file elsewhere and if no permission is documented within some time frame. While we can pretty safely assume a copyright violation in most of these cases, we are not 100% sure about this unless we get a statement of the copyright holder. It is a case of the precautionary principle that applies here. As long as we have reasonable doubt, we delete it. But this is not necessarily a case of a clear copyright violation. I suggest to reword this to Content appears to be a copyright violation.
  2. F3: Derivative work of non-free content. Seems too broad to me as this possibly includes {{FOP}} cases.
  3. I fail to see cases of out-of-scope crap, i.e. unwanted promotional stuff, spam, unwanted pdfs (see Foroa's comment above) and the all too common abysmal low-quality cases of COM:PORN. Putting such crap through regular deletion requests puts too much load on the backlogs.
  4. I fail also to see the option to nuke the uploads of a user where sufficiently many uploads appeared to be copyright violations and where we do not trust the remaining uploads even if we cannot find from where they have been taken from.
  5. Gross violations of COM:PEOPLE should be possibly speedily deleted, in particular in case of depicted minors who could be harmed -- see also this resolution.
  6. If we are indeed striving for completeness, we need to include the OTRS cases, i.e. files tagged with {{OTRS pending}} or {{OTRS received}} for more than 30 days.

Finally, I am missing the announcement of this poll at COM:VP and similar places. Policies must be accepted by the community, not just by admins. --AFBorchert (talk) 17:27, 10 June 2011 (UTC)

For 1, I changed the "Copyright violation" to "Apparent copyright violation" (if thats the right word). For 2, I've added "This does not include FOP cases" to the description. For 3, see the section #F2, F3, F4, and the section immediately below it. For 4, I don't see why we can't simply use COM:CSD#F1 for this? For 5, I think we need a new section to discuss this. For 6, I've changed the description; better? And as for the last point, I've added a note to the watchlist-note page. Of course, I can post another at VP if you want me to. :) Rehman 04:02, 11 June 2011 (UTC)

For me, "apparent copyright violations" are cases that should go through DR. It's only the clear cases that should be speedily deleted. But maybe I'm alone with that opinion... Jafeluv (talk) 16:03, 11 June 2011 (UTC)

•  Comment - Can you please include a recommendation to document the speedy deletions, at least in the cases where the boiler plate doesn't tell the whole story? I'm thinking especially about copyvios, some admins do include the link and reasoning, but others simply delete it with "Copyright violation", and it makes it harder to understand what happened if you can't see the deleted file. Also in the case mentioned by 99of9, what was the "plain rubbish" should be defined in the deletion message, at least in general terms.-- Darwin ^Ahoy! 00:46, 11 June 2011 (UTC)

•  Comment As someone who watches the new stuff being uploaded, I think it looks good. I'd say 98% of what I speedily pull out of the new uploads would fall under F1 - undeniable copyvios. The only item which jumps out at me is G9 - if it's an office action wouldn't it be announced as such during the deletion? I think we can trim this one from the list. Tabercil (talk) 02:13, 11 June 2011 (UTC)

I thought of that too, but I believe we should keep them for the same reason as en.wiki (and maybe some other projects): They are part of SD criteria (immediate deletion, without discussion). 1 2. But of course, we could always discuss this further. Rehman 03:50, 11 June 2011 (UTC)

Good point... about the only speedy deletes I do on EN these days is pulling out pics that have been moved to Commons, so I'm not up to date on what criteria there is over there. I can live with G9. Pencil me in as supporting - just waiting to see how some of the really heavy SD-using admins (Túrelio and Martin H. especially) respond before formally committing. Tabercil (talk) 04:02, 11 June 2011 (UTC)

Okay :) Rehman 04:06, 11 June 2011 (UTC)

•  Comment Regarding others' bits about this not being widely advertised — a notice is now being advertised on watchlists. Nyttend (talk) 03:29, 11 June 2011 (UTC)

What do you mean "advertised on watchlists" ? Do you mean that those who have edited the discussion page will know about it??? Doesn't really sound like wide advertising. --Tony Wills (talk) 02:01, 12 June 2011 (UTC)

•  Support -Open to edit..--...Captain......Tälk tö me.. 06:00, 11 June 2011 (UTC)
• Sounds sensible. Now can anyone explain how it interacts with Commons:Superseded images policy - or even what on earth that page is trying to say? Rd232 (talk) 00:48, 12 June 2011 (UTC)

It doesn't interact with Commons:Superseded images policy at all in the respect that "superceded" images are not speedy deleted. --Tony Wills (talk) 02:01, 12 June 2011 (UTC)

•  Oppose I still don't see where this has been advertised to the general community, was there a note about the discussion on village pump, or a note about this vote? As policy is not reviewed very often we ought to get a real consensus before making new policy. --Tony Wills (talk) 02:01, 12 June 2011 (UTC)

In case you haven't noticed, it's currently "advertised" on everyone's watchlists, and has been mentioned more than once above. That's your reason to oppose? Rehman 02:27, 12 June 2011 (UTC)

I don't understand the assertion that it is "advertised" on "everyones" watchlists, the only "advert" on my watchlist says "The Wikimedia Board of Trustees election has started. Please vote.", where do you mean? More importantly has it been "advertised" on village pumps? --Tony Wills (talk) 05:50, 12 June 2011 (UTC)

As per the watch list, the notice is there..look into the Watch list option's under the board elections notice...its default for all user's as per mediawiki..--...Captain......Tälk tö me.. 06:52, 12 June 2011 (UTC)

The notice is on watchlists via MediaWiki:Watchlist-details. Not sure why you can't see it. Rd232 (talk) 12:24, 12 June 2011 (UTC)

It seemed to be that the cookie ID was not incremented from the previous message that was on that page. I've now incremented it, so anyone who hid the previous watchlist message should see this new one. – Adrignola talk 14:45, 12 June 2011 (UTC)

Only on English users' watchlists, not everyone's. /Ö 19:12, 12 June 2011 (UTC)

Only people whose preferences are set to "en-English" to be specific. So now I know why I, and the non American English speaking world have not been notified that there is a vote going on (and are probably unaware for the same reason that there is even a discussion going on). --Tony Wills (talk) 20:45, 12 June 2011 (UTC)

See MediaWiki_talk:Watchlist-details#Localisation for a suggestion on how to localise watchlist notices. Rd232 (talk) 22:10, 12 June 2011 (UTC)

I didn't think anyone went through the trouble to change from a default en to en-gb. For now a simple transclusion of MediaWiki:Watchlist-details should allow those using British or Canadian or Australian English to see the same information. – Adrignola talk 22:29, 12 June 2011 (UTC)

The point was users of different languages, not different English variants. We're a multilingual project and many people prefer to use the Commons interface in their native language. Jafeluv (talk) 22:39, 12 June 2011 (UTC)

Alternatively, use MediaWiki:Sitenotice-translation (show it to all logged-in users). There's more experience there with localising. Rd232 (talk) 00:31, 13 June 2011 (UTC)

•  Support I don't see any problems in the current criteria, and we rather ought to have some policy on this. —innotata 13:39, 16 June 2011 (UTC)
• We do need a wider notification but as for the proposal itself I support--Ben.MQ (talk) 19:23, 17 June 2011 (UTC)

• Oppose. (i) Strong and formal criterias are not needed, ie this policy doesn't solve a problem like a generalized administrators abuse history of what should be or not speedy deleted, according what I see on Commons:Undeletion requests.
  (ii) Furthermore, this system works for speedy deletion on en. but are rareful on other Wikimedia projects. I've the feeling this is typically a US thing (e.g. US police uses an intervention codes nomenclature or administrative judges handling security clearances cases use guidelines A to H, and mitigating circonstances 1a to 1f) or at least something working very well in US, but not an universal system. Even without the numbers, I do'nt feel comfortable with such a classification.
  (iii) Such restrictive criterias could be dangerous, as they could block an administrator to ues common sense. --Dereckson (talk) 14:07, 21 June 2011 (UTC)

Please see my comment below, to Fetchcomms. Rehman 02:00, 22 June 2011 (UTC)

•  Oppose Strong oppose any (G) (C) (F) (1) (2) (3)-labeled policies. Extremely confusing for new users; I have always liked Commons' system where we can explain things in plain text rather than referring to a policy with a myriad of numbers. None of these criteria are controversial to me and none are new. We don't need to add to the bureaucracy. The only thing we need is Common Sense™. ←fetchcomms 21:35, 21 June 2011 (UTC)

As I understood Rehman some weeks ago the numbers will not show up in the log files. I would oppose this, too. Such logs look not nice/too technical/bureaucratic. Cheers --Saibo (Δ) 22:16, 21 June 2011 (UTC)

Yes, Saibo is right. The codes proposal was dropped long time ago. The only places these codes can be seen would be within anchor links, and discussions like this one. The reading user would never see these codes in logs or the CSD page. Please scroll up and see further discussions on the codes. Bringing this up again and again only confuses people reading this; the codes are no more, and is only being used in places like this discussion, to ease communication and accessibility. Rehman 02:00, 22 June 2011 (UTC)

Log files are irrelevant. People are still going to tell users "your file was deleted because of F5" or whatever, or users will read this discussion and be confused by all the number/letters. I certainly am, already. Someone tell me why we need to add this extra layer of bureaucracy by spelling every little bit out and abandoning common sense. Again: none of the the principles behind these criteria are new. We do not need fuss and debates about "did this really satisfy criteria X?" Then people start ignoring the spirit of the rules and obeying their letter. Common sense = IAR = beautiful. ←fetchcomms 19:38, 22 June 2011 (UTC)

•  Oppose Switching on common sense and good reasoning is not emphasized enough. Adding short comments if the standard text is not enough should be encouraged. Regarding the fictive "we need a XY rule for all possible cases": there is still the possibility to simply enter free text if an admin is sure that e.g. a duplicate template can be deleted right away. If no one beats him afterwards everything is okay and no one cares about - common sense. Generally, I think this new policy / reasons would be beneficial as they would make logs more clear (with links to this policy) for non-power-users. Some points:
  • It is not clear to me why we need F76? If it is a copyvio F1 (with specific comment added) does apply if not it should be a DR.
  • F8 should emphasize to merge the file page contents before deletion to not loose information. The user vs. bot thing is not clear to me. Why should a "user" upload be preferred if it is newer?
  • C1 is not general - should include a warning not to delete empty categories right away and maybe ask the creator if in doubt.
  • T2 should be a DR.
  • Also I oppose to silently legitimating office actions (G9) with this policy. --Saibo (Δ) 22:16, 21 June 2011 (UTC)

follow up: see #some points from S's vote

•  Support, while not having an out of scope criterion is concerning, we'd essentially do we we've always done: send it to DR and when nobody comments, make a unilateral decision. I'm okay with the status quo. I hope the judging sysop for this discussion actually reads it and doesn't count votes: the current consensus is clear. Blurpeace 02:05, 22 June 2011 (UTC)

Just to mention: yes, it "is clear" that there is no consensus. This is a basic policy and it even cites "broad consensus", so this is not a 50 %+ vote. Seems to me a bit early to get this to policy. --Saibo (Δ) 16:45, 22 June 2011 (UTC)

Most of the items cited in this policy are noncontroversial and happen every day without anybody saying anything. The only thing we're doing here is taking "out of scope" officially off the platter of decisions sysops can make unilaterally (see my point about why that's moot anyway). The majority of opposition to this becoming policy can be summed up pretty easily: people trying to ward off bureaucracy. The argument doesn't make much sense because it stems from the idea that it would be harmful to gaining new editors. If you think this policy or its wording will harm newbies per se, you haven't been editing this project long enough. Our issues stem from the impenetrability of the community itself and the difficulty of our subject matter in general. You can't blame a single policy for the problems we have here and having this as policy won't change anything. We just need to continue stressing that using loaded legal terms (including our own shorthand provisions in regular discussion) isn't conducive to getting our purpose across to the public. Bureaucracy will be anywhere and everywhere regardless of any attempt to deter it through preventive measures: projects like ours just don't work like that. Blurpeace 23:54, 23 June 2011 (UTC)

•  Weak support Although some of the criteria are a bit out-of-scope, as others have said, it is definitely a net positive to have more boilerplate speedy deletion criteria for files/pages that are encountered frequently on Commons. Logan _Talk ^{Contributions} 02:56, 22 June 2011 (UTC)
•  Support - Although I am missing a possibility to act on privacy violations - for which it should not always be necessary that stewards fly in here. (See below). Lymantria (talk) 07:36, 22 June 2011 (UTC)

•  Oppose Common sense is the best guideline.--Leit (talk) 09:23, 22 June 2011 (UTC)

•  Oppose While I would agree with most of the cases. I'd like to know the intent of such policy? Restricting exactly what the administrators are allowed to do? Allowing to delete content automatically the instant they match the criterii, thus making holes for exploit and potential attacks? Honestly, there are points that can lead to problems:

• the point are sorted by namespace, the first one being (gallery); but gallery is not a namespace, but a type of page. Gallery without images are not gallery, they are just pages...
• User intended to create encyclopedic content gallery. I don't see why we should deleted uncontroversial encyclopedic contents in gallery because it is on Commons and not on Wikipedia. Of course, we do have controversial contents sometimes in gallery that should be deleted... But this does not mean we must transfer all those contents to wikipedia (or other projects). Here's an example (in french, it could need an english translation btw) of an encyclopedic content that would get deleted from Commons by applying the policy strictly. In this example, You cannot really separate the images from the process and the associated explanation... If one think we should do, then we should remove all the description of the medias... It could probably be merged to a template or something similar to be put on all related medias, but it's mainly an organization problem, not an allowed content policy issue.
• I honestly don't think we need the template specific part. This should be covered by the uncontroversial maintenance...
• 4. Userpage of indefinitely blocked user. "The user owning this userpage is indefinitely blocked.". Can someone explain me what means the second sentence? I think the explanation could be better here.

Esby (talk) 09:35, 22 June 2011 (UTC)

•  Oppose STRONGLY - 2 reasons: 1. as stated above, we already have a page for deletion policies, & we do not need a separate page for this. 2. the proposal significantly expands the criteria for speedy deletions it has been VERY nicely-worded to achieve that effect; it creates BROAD definitions of speedy criteria, which would be open to "re-interpretation" & abuse.

  also; point of order: since a vote has been called on this policy proposal, the persons initiating this vote should have LOCKED IN the version of the text we are voting on.

  and finally, why do we keep having major policy votes every 1-3 months, mostly about what should & should not be deleted from commons?

  Lx 121 (talk) 12:00, 22 June 2011 (UTC)

•  Oppose I strongly oppose this idea because it makes it very difficult for new users to understand (G)(C)(F)* deletions because they have no idea what the heck they mean. It is a number and a letter that only make sense to those who know the policy (CSD). I would rather we explain to the users in plain text why their image is going to be deleted. Joe Gazz84 (talk) 13:22, 22 June 2011 (UTC)
•  Support Its tough to have a better policy that this one, and both this page and deletion Policy page are different.Vibhijain (talk) 13:34, 22 June 2011 (UTC)
•  Support Well-crafted policy. --Skeezix1000 (talk) 13:58, 22 June 2011 (UTC)
•  Support strongly. |Irritating how I can't even speedy error images I've uploaded.Blofeld Dr. (talk) 14:01, 22 June 2011 (UTC)
•  Support Per Vibhijain and Skeezix1000. TFCforever (talk) 14:23, 22 June 2011 (UTC)
•  Weak support - stupid question from an anonymous ex-Wikiholic, do you have something like template:Prod here? It's no substitute for a proper SD policy, but a nice way to speed up "simple" deletions. Admins only have to check that a "Prod" is uncontested, and that there was never a AfD procedure — don't hit me if AfD is GfD here ;-) –Be..anyone (talk) 14:41, 22 June 2011 (UTC)

  {{No permission}}, {{No source}}, and {{No license}} are like that one, in that they have a one week delay before deletion if uncontested and the issue is not resolved. – Adrignola talk 15:06, 22 June 2011 (UTC)

  Thanks for info, just in case I created the arguably missing {{No source}} redirection. The "Prod" business on en:w: is more flexible, it allows users to give any reason they wish for a proposed deletion, including reasons covered by more specific templates, i.e., when the user doesn't know the specific template. –Be..anyone (talk) 15:39, 22 June 2011 (UTC)

•  Neutral I can live with this, although I do not much like the new drop-down list that will almost certainly follow it. I will certainly edit some of those explanations there as we all get accustomed to them.

As for the question of notice, I don't think we have a policy on the notice required for changing policy; perhaps we should. Anyone who believes that this has had inadequate exposure is free to help that. Since I am essentially a monoglot, I'm sorry I can't help.      Jim . . . . Jameslwoodward (talk to me) 15:26, 22 June 2011 (UTC)

•  Support. Seems to cover the major cases that seem unambiguous or blatant. Certainly there are others that are just outside these limits that have a snowball's chance at passing DR. But it gets harder to specify many more classes that we (commons community) could not tolerate existing even for the timeframe of a DR and that would not start to include acceptable (or at least arguably-acceptable or fixable) ones. English wikipedia has a series of redirects from the acronyms and number/letter designations to the specific parts of the policy, so it's easy for editors to link the jargon when leaving comments to novice uploaders. DMacks (talk) 16:17, 22 June 2011 (UTC)
•  Support but  Merge to Commons:Deletion policy. Just like, I would like if there were an abbreviation like instead of "Criteria of Speedy Deletion type: Category 1" there is like "CSD C1". Ebe123 (talk) 18:37, 22 June 2011 (UTC)

Oh heavens no. This is the sort of attitude that drives away new contributors--internal abbreviations and wikispeak is so detrimental to retaining editors. ←fetchcomms 20:38, 22 June 2011 (UTC)

Agree with Fetchcomms. Logan _Talk ^{Contributions} 21:50, 22 June 2011 (UTC)

•  Support Good step forward to improve and maintain usefulness of the Commons content. -- btphelps ^{(talk) (contribs)} 19:52, 22 June 2011 (UTC)
•  Support Speedy deletion works well on the English Wikipedia, I don't see a lot preventing it from being applied to files. WikiCopter (talk) 20:05, 22 June 2011 (UTC)

"Speedy deletion works well on the English Wikipedia"--lol. ←fetchcomms 20:38, 22 June 2011 (UTC)

•  Oppose I strongly oppose because 1)There's no summary of the differences between what is currently policy and what this will make policy - either from supporters or detractors. http://commons.wikimedia.org/wiki/COM:DP#Speedy_deletion compares how? 2)Also, what's being voted on wasn't locked down, so this is a bogus vote anyway. 3)This makes abusive speedying easier to justify. There's no rush(TM). --Elvey (talk) 20:46, 22 June 2011 (UTC)

•  Support Yes it may make abusive speedying easier to justify, but it is also a way to deal with clearly speedy-able images which had one admin or passerby decline the self-written nomination. It's better than having files languish for months at COM:DR. Regards, MacMed (talk) 23:27, 22 June 2011 (UTC)

•  Support This seems reasonable to me. --Walter Siegmund (talk)

• < s >  Oppose This can be abused for ignorance. What works in a place (wikipedia) does not necessarily work in another place (Commons). And it is not always obvious to recognize a “clearly speedy-able images” or an “obvious copyvio”. 201.167.18.134 06:41, 23 June 2011 (UTC)< / s > Please log in to vote. --Walter Siegmund (talk) 13:45, 23 June 2011 (UTC) -- REVERSING STRIKETHROUGH by user-admin Wseigmund. inappropriate action for at least 3 reasons: 1. in the rather "mushy" wording of the announcement (A proposal for adopting Commons:Criteria for speedy deletion as official policy has been initiated. All users are invited to participate.), it doesn't indicate that only registered users who are logged in can "vote"; nor can i find anyplace where this is stated as a requirement for participation in this discussion. 2. the "vote", such as it is, has been extremely poorly organized. there is no "locked down" text, revisions are STILL occuring "on-the-fly"; the announcement doesn't even call for a "vote"; & the "voting section" could certainly be more clearly labelled, & better organized! 3. the ADMIN who "invalidated" this user's vote is a supporter of the proposal. he(?) voted in favour, on the line above, then struck out an opposing vote, on a "technicality"!? this is a breathtakingly inappropriate action, not to mention an obvious conflict-of interest; any qualified admin should know better than to take such an action. this isn't an FP vote, it's an open community discussion; unless the user-admin wishes to present evidence of sockpuppeting, or some similar abuse, by the opposing-voter, then with all due respect: HANDS OFF! Lx 121 (talk) 06:19, 24 June 2011 (UTC)

•  Support. Intresting idea, since a file nominated for the 2010 POTY honor was disqualified. Dhe Zerohander (talk) 07:35, 23 June 2011 (UTC)

•  Conditional support: Instead of G, C, F 1, 2, 3 use #Attack, #Corrupted file etc. etc. It's not freaky wikispeak and new users will understand what the problem is Ancient Apparition ^(talk) 09:34, 23 June 2011 (UTC)

•  Support There is lots of useless images that should be deleted. The commons is too expensive. EternamenteAprendiz (talk) 11:34, 23 June 2011 (UTC)

•  Oppose Way too broad, to allow deletion without discussion. As a specific example: "5. Missing essential information. The file is missing essential information, such as a license, permission, or source. Such content may be given a grace period of seven days (since tagging) before being deleted." That lets the deleter decide what information is essential, and delete immediately: I have seen administrators on EN insist that exact page number within a book, or year of publication of that book, for example, is "essential information". --GRuban (talk) 12:30, 23 June 2011 (UTC)

•  Support in general. I have concerns with the wording of the "derivative work" section... sometimes that is obvious, but not always, and perhaps those should go through a discussion when there is significant additional expression supplied by the uploader. I do see the FOP cases are exempted, which is along those lines, but people tend to interpret the term "derivative work" pretty broadly and this one may get abused. Screenshots may not always be a derivative work really -- they may technically be a "copy" if there is no copyrightable expression supplied by the uploader. Second, I would change the label "Apparent copyright violation" to "Clear copyright violation". That is what the text says. Files which are simply believed to be a violation, with no evidence, should go through a regular DR. Lastly, on the duplicate thing -- I would make mention that the licenses should also be the same. It's probably a (very) rare case, but for example a larger version licensed CC-BY-SA and a scaled-down version licensed CC-BY should both be kept. Carl Lindberg (talk) 13:51, 23 June 2011 (UTC)

•  Oppose for reasons I've stated before on this topic. Also, I agree with Fetchcomms, above. Killiondude (talk) 22:01, 23 June 2011 (UTC)

•  Oppose - Fair use images should not be speedy deleted. Commons is widely perceived as being more trouble than its worth by other projects. I believe this to be a fair characterization. Speedy deleting fair use items that are used by local projects is not acceptable. Deleting fair use eligible images, as opposed to moving them back to local projects, is the number one reason that other projects hate Commons. You continue to try to make it easier and easier to delete more and more, yet continue to show a fundamental disregard for the negative impact your laziness has the other projects. There's no other way to describe it. Either you don't care, or you're lazy. Either way, it's wrong. I don't like yelling, but you guys don't get the message. Sven Manguard (talk) 04:11, 24 June 2011 (UTC)

STRONGLY agree with sven!" & an extremely good & valid point to raise. this has been a long-term failure in commons' policy. if we're determined not to host the "fair use" stuff (which is somewhat of an empty gesture, in that it's still on the same servers; not to mention we host wmf-restricted files), then we should at least have a default policy of moving the fair use material to the project(s) it's being used on. right now, it seems to be hit-or-miss, depending on who is doing the deleting... (putting this comment where it would have been, if someone hadn't moved the whole page while i was writing it. >__<) Lx 121 (talk) 06:14, 24 June 2011 (UTC)

Maybe if [you guys] didn't upload fair use images here, we wouldn't have to delete them. Maybe if [you guys] decided to build a bot, you might be notified. theMONO 05:16, 24 June 2011 (UTC)

Fair use images have never been acceptable on Commons as part of this project's goals and never will be as far as I know. --O (谈 • висчвын) 05:53, 24 June 2011 (GMT)

...& the above 2 comments are completely missing the point; it is UNHELPFUL to just ERASE in-use materials (much less erase them on a SPEEDY!) the commons project has some clearly stated mission goals. screwing up other wm projects, because we CAN'T BE BOTHERED to fix something properly, is not on the list... Lx 121 (talk) 06:14, 24 June 2011 (UTC)

No I don't think those two comments miss the point. The goal of Commons is clear as spelled out in Commons:Welcome: "Wikimedia Commons is a media file repository making available public domain and freely-licensed educational media content" (emphasis mine). It is not intended to be an image repository for all the projects, which is what it'd need to be for it to host fair use materials. Additionally, I think you're overlooking something: not all projects allow fair use media to begin with (e.g., DE I know doesn't and I'm fairly sure ES doesn't just to name two), so the assumption that an in-use item should be moved over to the local project doesn't work in all cases. If the item doesn't work there and doesn't work here, then what's to be done... it's DOA irregardless. We're here working on improving Commons, not working on umpteen local projects. Tabercil (talk) 21:11, 25 June 2011 (UTC)

Fair points on both sides here. Wouldn't it be possible to agree at least that when a fair use image has been moved from a project which permits fair use, it should be moved back instead of simply deleted? Rd232 (talk) 12:24, 26 June 2011 (UTC)

Part of the issue here is that because most regulars at Commons have an understanding of copyright, they tend to assume, incorrectly I might add, that everyone has an understanding of copyright. You are always going to have people who think "I found it on the internet, therefore it must be free" and people on other projects that don't quite realize that fair use isn't the same thing as free use. Since you can't stop people from making honest mistakes in the first place, the onus has to be on fixing the problem with a minimum of collateral damage, both to the other projects and to the uploaders. Too often I see images just get unceremoniously tossed, and even more unfortunately, I see the uploaders get trashed rather than taught. Sven Manguard (talk) 20:26, 27 June 2011 (UTC)

•  Support It's time to set some things straight. No, it's not perfect; it should be adapted over time. I like the number system and it'll be great when we finally get a

port of Twinkle. Cheers, theMONO 05:16, 24 June 2011 (UTC)

with all due respect to the user, the above vote & comment is exactly what i'm worried about with this overly-broad, poorly worded, draft proposal. it invites WAVES of speedy deletions, with NO discussion, NO open community process (or transparency of the record) possible (admins-only for checking deleted materials); with endless, tedious, "reviews" for any material that actually has "defenders", & NO discussion & NO review for the rest. SPEEDY is already being abused, this policy would make it FAR worse. Lx 121 (talk) 06:14, 24 June 2011 (UTC)

• What happened to being mellow? Like many others who have commented before me, the existing deletion policy already fulfils this proposed policy's goals. But more importantly, this proposal would simply further de-humanise at least some administrators who are active within the deletion processes. It may certainly decrease the number of characters to be typed into deletion log comments, but may very well mean a massive increase of characters when explaining a possibly misguided speedy deletion to the community. This especially applies to users in good faith finding that their file got speedy deleted for reason(s) they are unfamiliar with. The onus is on the deleting administrator to clearly explain and discuss, if applicable, the reasons why such file got deleted. In case of perpetual disagreement, there exists a process for wider comment. In the proposed policy's current form, I can only see more evasiveness from deleting administrators when asked to clarify their actions, as the only reply may be to read stuff. Therefore, I  Oppose this as a separate policy. However, I may be able to accept this only as a supplement to the existing deletion policy, like the essays on this notorious English Wikipedia policy, such that the supplement does not stray from the spirit of the parent policy. --O (谈 • висчвын) 05:53, 24 June 2011 (GMT)
•  Oppose • per Lx 121, Sven Manguard, GRuban, Elvey, Leit, and a whole lot of others listed above showing common sense. Some (not all) admins can't do the right thing now, and you want to give them these kinds of powers carte blanche? Amazing. —N·M—^talk ·· 06:57, 24 June 2011 (UTC)
•  Oppose until the present version is replaced by a new one taking remarks into account. Croquant (talk) 07:11, 24 June 2011 (UTC)
•  Support Will make maintenance easier. Hekerui (talk) 12:24, 24 June 2011 (UTC)
•  Support - Utilizing numbered CSD criteria would makes Commons more user-friendly. -FASTILY ^(TALK) 03:52, 25 June 2011 (UTC)

with respect, if that is the only reason you support this move, i would STRONGLY urge you to read very carefully through those numbered criteria, & think carefully about the ways they could be applied... Lx 121 (talk) 09:39, 25 June 2011 (UTC)

•  Support - above reasons.. --Srikant Kedia 10:09, 25 June 2011 (UTC)
•  Support in general, but the text needs polishing. Ruslik (talk) 14:25, 25 June 2011 (UTC)
•  Support as per Ruslik Joyson Noel ^{Holla at me} 15:32, 25 June 2011 (UTC)
•  Oppose because of "5. Missing essential information. The file is missing essential information, such as a license, permission, or source. Such content may be given a grace period of seven days (since tagging) before being deleted." Some admins are tagging and deleting images that are clearly free regardless of whether there is permission or source. /Pieter Kuiper (talk) 20:47, 25 June 2011 (UTC)
• This vote has a problem. While most items are super helpful and should be policy, there is this Fair Use bit, which should never become policy. So I cannot support this bright move because of this one serious problem. If this item was out, I would strongly support all the rest. Hoverfish (talk) 22:53, 25 June 2011 (UTC)) -- for purposes of "vote counting", i believe this means that User:Hoverfish is an  Oppose(?) Lx 121 (talk) 10:14, 26 June 2011 (UTC)
•  Oppose Too much complex. I think COM:DP can cover it. – Kwj2772 (msg) 13:55, 26 June 2011 (UTC) I don't think it needs to be a policy. Currently speedy deletions are performed in accordance of deletion policy. I think making it a policy will have no differences and only increase bureaucracy. – Kwj2772 (msg) 14:07, 26 June 2011 (UTC)

•  Support Strongly! - Commons needs a speedy deetion method simailar to that of the english wikipedia to allow users to flag items for IMMEDIATE review, that OBVIOUSLY violate copyright; e.g. Items that contain copyright watermarks, items with obviously false information in the content description and licencing information, ect. In my time on commons i have seen quite a few of such images, but waiting a week or more for them to be deleted along with the not so easy process is not ideal for for copyright violations of such a high magnitude. --Koman90 (talk), Network+ 19:39, 26 June 2011 (UTC)

we HAVE a speedy deletions procedure; this vote isn't about creating one, it's about expanding the codification of procedures beyond what's already on the "general page" of deletion policies. what we don't have @ commons is the manpower (HUmanpower?) to keep up with everything; commons has grown to >10 million media files in a VERY short time, & the size community of regular editors here is a small fraction of the wp/en "regulars". if you think the deletions backlog is something, you should see the backlog for sorting new - incoming media files... 209.195.82.178 19:50, 27 June 2011 (UTC)

•  Oppose on two points. Images that are fair-use should be moved to the wiki where they are in use if can be done. If a user accidentally posts an image here that is fair use then there is no reason not to move it there before deleting it(except certain special circumstances). More importantly though is the speedy deletion criteria for images missing "essential information". Many of these images are clearly free, for instance an image that is marked with "My own work" but lacks permission or source obviously shouldn't be deleted let alone speedy deleted, but the current proposal would allow for inappropriate speedy deletions of such images.AerobicFox (talk) 20:56, 26 June 2011 (UTC)
  • Addendum: G4 shouldn't be a subject for speedy deletion. Out of scope claims can be highly subjective and the line between a "promotional gallery" and a "useful gallery" can be ambiguous and should be determined through a normal deletion discussion.AerobicFox (talk) 00:40, 27 June 2011 (UTC)

•  Oppose due to poor process (lack of translation, timely advertising, and summary of changes from existing situation), and concerns over fair-use and "copyvio" aspects at least. --Avenue (talk) 16:31, 27 June 2011 (UTC)
•  Oppose on primary concern of process (per Avenue) and additional concerns about wording of the "missing essential information" and copyvio criteria. cmadler (talk) 19:45, 27 June 2011 (UTC)
• comment the letter and number codes may seem impersonal, but they allow an easier mapping to the other languages that may be used here. A textual reason should be there too, but may be hard to understand if the user does not read English, whereas a code can be looked up in a table for their own language. Also I think it is unfair to close this when the advertisement for this has only just appeared on the English language watchlists. There should be input from non English users here. Graeme Bartlett (talk) 22:00, 27 June 2011 (UTC)
•  Oppose The page should elaborate more specific rules. The formulations in this proposal seem too broad. For example categories should not be speedy deleted if there as still files inside. Or if it was brought to the attention of the admin that a number of Wikipedia articles are linking there. The proposal to speedily delete "inappropriate" user pages is not wise. Admins could use this when they have a personal conflict with a user. This sort of deletion should be slow and reviewed by the community. "The file-namespace is empty. Empty file-pages are subjected to uncontroversial speedy deletion, unless they are being used as redirects" does not take into accounts the prefilling of description pages performed when using the flickr upload tool. When using this tool there is a lapse of time during which the file page is edited with no file inside. Teofilo (talk) 12:51, 5 August 2011 (UTC)

Moving forward

Particularly in view of the closure mess, maybe a new approach would help. Much of the policy does seem to have general support; it's specific parts of it that are contentious. So why not tag the contentious bits as "proposed, under current discussion" (maybe with strikethrough to make it visually very clear) and approve the policy? That way we don't need to reach agreement on all the various contentious bits before benefitting from the formalisation of policy on the various widely-supported points. That puts less pressure on the discussion, and moves it forward to focussing on the contentious bits (each one should get a subsection on this talkpage). Rd232 (talk) 12:20, 26 June 2011 (UTC)

A more appropriate action to take would simply to remove all the contentious bits(F2, F5), and then see if widespread consensus is reached.AerobicFox (talk) 20:59, 26 June 2011 (UTC)

Yes, that's a great idea. --SJ+ 15:56, 4 July 2011 (UTC)

Summary of opinions above (later additions):

• Oppose on principle: Herby, Dereckson, fetchcomms, Leit, Lx121, JoeGazz84, 201.167.18.134, Killiondude, O, Nashville Monkey
• Oppose on specifics: Esby (encyclopedic gallery pages; template criteria), Elvey (lack of clarity of what's voted on and how it differs from status quo), GRuban (too broad), Sven Manguard (Fair use should be moved to another project, not just deleted), Croquant (present version needs to reflect discussion), Peter Kuiper (re F5, "missing essential information" - concern about overuse), Hoverfish ("fair use bit"), TonyWills (insufficient discussion to date), AerobixFox, Sj (fair use, "missing essential information"), Saibo, Avenue, cmadler, Lx121 (proposal expands speedy practice, drafting process chaotic)
• Support: Rehman, Jarekt, Mormegil ("no problems with the stated proposal"), Tabercil, Captainofhope, innotata, BenMQ, Blurpeace, Logan, Lymantria, Vibhijain, Skeezix1000, Blofeld Dr., TFCforever, Be..anyone, Dmacks, EBE123 (but merge), btphelps, WikiCopter, MacMed, WalterSiegmund, Dhe Zerohander, Ancient Apparition (but: no abbreviations), EternamenteAprendiz, Carl Lindberg, theMONO, Hekerui, Fastily, Srikant Kedia, Ruslik (but tweak text), Joyson Noel (ditto), Koman90
• Neutral: Jameswoodward
• ? 99of9 wanted more latitude for G3-type deletions, but seemed to accept that G3 covered the concerns, but the vote remains Oppose
• ? Adrignola says "merge", which is merely procedural (whether the content is here or on another page), not for or against the proposal.
• ? Saibo "oppose" but "Generally, I think this new policy / reasons would be beneficial as they would make logs more clear (with links to this policy) for non-power-users."

Notes: "out of scope" criterion? privacy-related criterion? Substantial opposition to using abbreviations like "F1", but some also like the idea.

Summary of the summary:

• 9 oppose on principle
• 8 14 oppose on specifics (i.e. more drafting needed, might support then)
• 32 support (but some note need for drafting tweaks)
• 4 3 neutral, unclear, or "not ready yet"

REALLY do not want to pick a fight here, but i'm still getting a count of only 29-30 clear support votes vs (now) 23 clear oppose votes; i don't see where the extra 2-3 supporters are, to be counted? Lx 121 (talk) 20:29, 27 June 2011 (UTC)

There are 32 names in my listing above under Support. You should be able to find the discrepancy there. But it really doesn't come down to 1 or 2 votes, especially as discussion is ongoing. Rd232 (talk) 21:32, 27 June 2011 (UTC)

The main purpose of this exercise was to get a sense of the value of further discussion. Just under 20% oppose on principle and just under 60% broadly support the proposal, with a further 15% potential supporters if the proposal is revised to meet their concerns. Next question: how can we move the discussion forward? What about moving the contentious criteria from the current policy to a subpage, as a new proposal for amendment (to be discussed separately), and then seeing if there is consensus to implement the uncontentious parts of the policy. If there is, further discussion can then be made on the amendment. Rd232 (talk) 21:07, 26 June 2011 (UTC)

Note: I was not really opposing on the 'gallery' topic, I was just saying here it was not logic to regroup it in a namespace section while galleries are not namespace... and while it is not logic to talk of empty galleries, unless we mean we want to delete pages that contains only <gallery></gallery>? and in thase case those are not galleries but pages... Esby (talk) 22:19, 26 June 2011 (UTC)

Thanks for this write-up! Put me to "Oppose on specifics" please. --Saibo (Δ) 23:17, 26 June 2011 (UTC)

OK, updated. Rd232 (talk) 23:49, 26 June 2011 (UTC)

Would it be fair too say that the contentious bits are "copyright violation" (F1), "fair use" (F2) and "missing essential information" (F5)? A couple of people raise other points but that looks to me like the main issues to remove for further discussion a bit later. Rd232 (talk) 23:54, 26 June 2011 (UTC)

I believe the main issue is that we don't want some material speedy deleted based on these actual criteria, mostly because it can be abused. this includes the 7 days grace that exist in some case and should not be reducted to dust. Esby (talk) 14:55, 27 June 2011 (UTC)

? by "actual criteria" do you mean F1/2/5, or the policy as a whole? And I don't mean that taking out the contentious bits for separate discussion necessarily means they will later be adopted, in case that wasn't clear. There might, with further discussion, not be a consensus for adding them at all - but then we'd still have the rest of the policy. PS By the way, I think it would be easier to understand how the proposed policy fits in with the current Deletion Policy if the latter was better organised. See Commons_talk:Deletion_policy#Structure. Rd232 (talk) 15:21, 27 June 2011 (UTC)

By actual criteria, I mean the one that are are actually defined and were voted in this page. What's the current vote and remark just shown that's the vote phase was not ready yet. I am honestly still puzzled to know if such policy is needed: there are already conditions to delete files, including speedy ones. On my initial oppose I was wondering of the intent of this policy: restricting the administrators or giving them the super-cow powers? I think this tries to manage both and fails because of it. The proposal lacks logic, for my template oppose it's justified to my eyes by the fact that templates can have heavy interactions, depending how they are used, and that an usage / non usage is just a matter of a few edits, so it can lead to abuse... It is also covered, in my opinion, by the Uncontroversial maintenance case. So technically, general section should come first, and specific cases after, supposed they must be differentiated. Imo, if there should be any doubt in a speedy deletion, it should not be speedied, that's all. Esby (talk) 20:54, 27 June 2011 (UTC)

•  Support Seems ok to me, my only issue would be with the appeal process, the link to appeal a Speedy Delete is rather small, at the bottom of the box from what I remember (might be incorrect though). I have no issues with these points. Oaktree b (talk) 01:28, 28 June 2011 (UTC)

•  Oppose I have no idea when, if, or how this vote is supposed to close, but I don't approve of the "threat or attack" or "inappropriate userpages" criteria as I've raised below. I think this vote needs to be better advertised, go on for longer, and use a more stable consensus draft before a "closure" can count as resolving the issue. Wnt (talk) 03:14, 28 June 2011 (UTC)

•  Oppose (1) Too many flaws. (2) Needs a lot more input from editors and users without English native language. S a g a C i t y (talk) 06:17, 28 June 2011 (UTC)

•  Support This is badly needed and the policy is well-crafted. Kelly (talk) 07:00, 28 June 2011 (UTC)

•  Oppose too many flaws IMHO. JJ Georges (talk) 10:30, 28 June 2011 (UTC)
•  Support The flaws are not weighty but the benefits are. Blue Rasberry (talk) 06:31, 1 July 2011 (UTC)

•  Oppose lack-of-clarity; are we still voting on the original proposal here, OR are we voting on the "moving forward" subsection?

any "moving forward" needs to happen AFTER the above vote (on the original proposal) is closed ("accept", "reject", or "no consensus"). it's disrespectful of the process, & of the community, otherwise.

once the discussion & voting there has concluded, i have no problem with starting a new discussion(s?) for individual items.

Lx 121 (talk) 11:36, 1 July 2011 (UTC)

•  Support: It needs to be an official policy.--The Master of Mayhem (talk) 13:28, 1 July 2011 (UTC)

•  Oppose This started originally as an attempt to refactorize policy, not to change it, i.e. moving the speedy deletion part into a separate page. Afterwards it became a general discussion about what can be speedied and what not. It is surely a good thing when the community debates and reformulates policy. However, I do not think that it is a good approach to replace a working policy by a new policy which needs to be amended. It would put us into an unbearable situation to live with a temporary policy that skips copyright violations, fair use, and cases of missing essential information. I would suggest another approach: Make a vote whether the refactorization is supported and a vote for each individual debated point. And whenever a change is proposed in reference to the old policy, it would be helpful to have a rationale explaining what is the perceived problem with the old policy and what is to be solved by changing it. Finally, I suggest to get a broad consensus beforehand over which period such a vote shall be run, and how it is evaluated. In my opinion we should run it over four weeks and we should require a 2/3 supporting majority to implement a change. --AFBorchert (talk) 16:03, 1 July 2011 (UTC)

• ((support)) RDN1F (talk) 22:15, 1 July 2011 (UTC)
•  Support Good step forward; useful criteria --High Contrast (talk) 06:58, 2 July 2011 (UTC)

•  Oppose LPfi (talk) 23:54, 2 July 2011 (UTC) Too many issues. In the current draft policy e.g. nearly all file deletion reasons are problematic: Apparent copyright violation: too broad, should be "obvious" as before. Fair use content: media moved from other projects should be moved back. Derivative work of non-free content: not to be deleted if not copyvio ("derivative" should probably be interpreted in the legal sense, which is not guaranteed). Missing essential information: admins do miss the essential information when written in plain text instead of as templates. License laundering: laundering or supposed laundering? File-namespace is empty: please check the language. --LPfi (talk) 23:54, 2 July 2011 (UTC)
•  Oppose per AerobixFox and others. The fair use and "missing essential information" are too aggressive and will make Commons less effective (the former makes it less effective in supporting other projects, the latter less effective at gathering and preserving valuable free content images). Redrafting this without F2 and F5 criteria, and adopting a few other minor tweaks recommended, looks like it would reach consensus. --SJ+ 15:56, 4 July 2011 (UTC)

• Weak  Support. This is a good initiative, but I don't see why clear cut FOP cases aren't included. Do we really need a separate DR for every contemporary Norwegian sculpture? That's unnecessary red tape and a waste of our time. Regards, --Kjetil_r 21:49, 4 July 2011 (UTC)
• A very late  Oppose. Mainly per Fetchcomms and that it's too complicated. —stay (sic)! 10:03, 7 July 2011 (UTC)

SECOND attempt to close the vote

Overall, I just saw 38 users supporting and 21 opposing. The voting has ended, so, the final result is Support. Do you agree with this? Dhe Zerohander (talk) 21:20, 5 July 2011 (UTC)

how did you get those numbers!? with respect, they do NOT seem to be at all accurate. the "support" is grossly inflated, & your oppose count seems a bit low... Lx 121 (talk) 23:52, 10 July 2011 (UTC)

No. The page talks about "broad consensus", this is less than 2/3 and there has been a lot of complains about how the voting has been announced and confusion about what we are voting about. Please read some of the discussion before stating such conclusions. --LPfi (talk) 22:08, 5 July 2011 (UTC)

I don't really agree. Consensus is not determined purely by polling. There is strong enough consensus to move forward, rather than to say "stop, abandon this", but it needs to be taken forward in some way that attempts to resolve the many issues. User:Rd232/speedydraft may be useful. Or maybe someone could attempt a shorter draft of COM:CSD which only covers the criteria which exist in current policy. Make sure there is a baseline consensus for that, and then propose additions to that individually.

I have to say, though, that I'm increasingly unpersuaded that there is a real need for a separate policy. Specific criteria can be proposed to be added to current policy - this may just be easier, even if it's frustrating for people who've worked hard on this policy proposal. That would also make it easier to be clear about what's exactly being changed from the status quo. Rd232 (talk) 09:32, 6 July 2011 (UTC)

Multidimensional  Oppose! First of all: this vote is not closed — in the top of my browser today (11:29, 6 July 2011 (UTC)) I have a very clear message

— which clearly indicates that Dhe Zerohander's closing of the vote is premature. Secondly I  Oppose the proposal itself, which is to make official a set of rules rather than to discuss individual rules themselves. Some of the presented criteria for speedy deletion are sound, others are really premature, such as speedy deletion of articles that (sometimes by mistake) were created here, rather than on Wikipedia. A slow and deliberate port to Wikipedia followed by a deletion here would be preferable. I think the initiation of this vote is not deliberated enough. Rursus (talk) 11:29, 6 July 2011 (UTC)

Perhaps you do not understand the impact of your proposed change. I do a lot of New Page patrol. In the last two months I have deleted 1,097 such pages as out-of-scope and I am by no means the only Admin doing NPP. In perhaps one in five hundred cases the writer will ask that I undelete the article. The rest are a mix of biographies of ordinary people and their kids (by whatever standard you define "ordinary"), promotional pieces for individuals, web sites, or products, and so forth. In the very rare case that an article appears to be relevant and does not already exist on WP:EN, I will ask the creator about it.

Remember, too, that this criterion allows me to delete articles in any language -- even the large number of them that I cannot read. It is easy to see that a page is not a Commons Gallery even if it is written in one of the non-Latin alphabets. We do not have the Admin resources to read articles in all of our languages and determine whether they are worth transferring elsewhere.     Jim . . . . Jameslwoodward (talk to me) 12:07, 6 July 2011 (UTC)

Requests to remove the notice at MediaWiki_talk:Sitenotice#.7B.7Bedit_protected.7D.7D and MediaWiki talk:Watchlist-details#Edit request have been unanswered since 1 July. Rd232 (talk) 12:55, 6 July 2011 (UTC)

I think the issue you explain is an example of why these policies should be discussed, explained and well written. There are lots of cases where admins frustrated about the backlogs want to be able to quickly get rid of stuff, while there are equally frustrated newby contributors, who cannot find the page they created or the file they uploaded.

Also deletions that are necessary and follow practice are bad when the creator/uploader/whatever doesn't understand what is going on. I cannot even point them to policy, when it's the "there is no rules" section that is applied. Most people hesitate to beg for their files to be undeleted: they suppose that either the decision to delete was informed or the admin is arrogant, what could they do to turn his head? And why contribute somewhere where they are turned down?

Whenever we can, we should be kind against good faith contributors. Pointing them to Commons:Undeletion requests/Current requests because "a wrong speedy delete is no deal, they can be undeleted" is not what I want to do, especially when English is their third language (as it mostly is among my acquaintances) and they may be less linguistically skilled.

--LPfi (talk) 14:21, 6 July 2011 (UTC)

Good points. It doesn't necessary lead to the conclusion of a separate policy, but it does lead to the conclusion of providing more detail in policy. Even if the extra detail is written in a way that allows quite a bit of admin discretion, it will help clarify things for users. It also points, perhaps, to having numbered criteria (the F1, F2 etc style some dislike), to provide an easier handle to make sure users don't get lost looking up the details of why something has been deleted or may be deleted - especially if they jump from the English policy to a translated version. Rd232 (talk) 14:58, 6 July 2011 (UTC)

Concur with LPfi and Rd232. The main point is that the rules are more elaborated before considering attaining them as policy. It's also better to elaborate and discuss them individually. Rursus (talk) 18:01, 6 July 2011 (UTC)

i do think it might be time to close this vote as "no consensus" though. it's certainly been a messy process, & we no longer have any real clarity about what's being voted on (original text, revised drafts, "moving on", etc.?). Lx 121 (talk) 23:58, 10 July 2011 (UTC)

First Attempt to Close this Vote

excuse me, but on what basic are you "archiving" the above part of the discussion? & how do you justify hiding it in a "collapse"? the first (botched) attempt to close the vote is an important part of the record of this process, & should NOT be "downplayed" in this manner Lx 121 (talk) 11:24, 1 July 2011 (UTC)

That attempt to close the vote was fairly obviously a mistake. The record of it isn't going anywhere, but there is no need to dwell on it. Were this section not between the first vote/discussion and later ones about what to do next, I wouldn't bother collapsing it, but it is, and leaving it here uncollapsed makes a messy process even messier. Rd232 (talk) 19:24, 1 July 2011 (UTC)

Fully agree. A vote that requires users to read 15 pages of discussions on 20 different items without clear conclusions is never going to work. --Foroa (talk) 06:16, 27 June 2011 (UTC)

I'm not quite sure who you're agreeing with here. I think this first attempt at declaring the discussion concluded has been rejected, and doesn't require further discussion here (in theory, if anger at the attempt were great enough, further action against the editor in question might be proposed elsewhere). But that's not the same as a vote close "never going to work" - the discussion continues above, and if the contentious parts are removed for further discussion, the bulk of the draft policy seems close to having consensus (whilst recognising that a substantial minority oppose on principle, the minority's small enough not to block consensus). Rd232 (talk) 10:37, 27 June 2011 (UTC)

I think the problem is that this poll was not properly set up. That is, what counts as "consensus"? Simply majority, two-thirds, etc.? This is fortunately not as big of a mess as the en.wp pending changes poll, but if we don't get these things straightened out beforehand, everything is disputed. ←fetchcomms 21:28, 27 June 2011 (UTC)

Isn't two-thirds normally a minimum for this sort of thing? Rd232 (talk) 18:08, 29 June 2011 (UTC)

As a relatively frequent contributor to Commons this is the 1st time I have visited this page to vote and I am frankly amazed that someone thinks that it is already time to bring this matter to a conclusion. As the two editors above say we need to start over, with a proposal that is fixed and final. S a g a C i t y (talk) 13:18, 27 June 2011 (UTC)

• I'm not sure what the current status is, but I would note that the "vote" is somewhat problematic as votes were cast over a long period while modifications were still continuing, and it was unclear as to what votes apply to which version. The whole thing has become somewhat unmanagable, and I'm not sure that there was any thoroughness in transfering discussion here to ammendments on the policy page. May I suggest we start by agreeing on the basic structure of the policy page, then discuss, comment, ammend, and vote on each section :-) --Tony Wills (talk) 13:08, 29 June 2011 (UTC)
  • This thread was originally about the vote closure (which is done and dusted), but it's now drifting into discussion of the vote, even as the voting sort of continues and I've made several efforts to move discussion forward. Frankly, it's a fairly complete mess. Perhaps it needs someone to take the bull by the horns and bring the current process to a stop, and restart discussion (as opposed to voting). I suspect, though, that enthusiasm for such discussion may now be limited. So an alternative would be to give up on the separate policy page (at least for now), and identify particular elements of the proposal which actually differ from current policy (see User:Rd232/speedydraft) which are likely to get consensus, and propose adding them to the existing Commons:Deletion policy. Rd232 (talk) 14:00, 29 June 2011 (UTC)
    • Tabling the current discussion and proposing a small number of individual changes to the existing policy is a good way to proceed. It may be more fruitful to discuss changes individually. People may object to a set of changes even when they agree with a majority of the individual items. --Walter Siegmund (talk) 23:51, 29 June 2011 (UTC)

History merge for files

Seeing no mention of this under CSD G6, is it possible to merge the upload history of files now (thanks to file moving), as it always has been for pages? I was trying to bring this up at AN with little luck. If file history merges are possible, this should be mentioned, and it should be decided under what circumstances these are appropriate. ▫ JohnnyMrNinja (talk / en) 00:21, 27 June 2011 (UTC)

Possible, yes. I see little use, as attribution is almost always provided in the description. Except, we need attribution for derivative images, but we usually do not delete the originals anyway. ←fetchcomms 03:26, 27 June 2011 (UTC)

My thinking was that replacement images uploaded to a secondary title might sometimes be better at the same title. Either way the history is preserved, and people can link to each file individually, but we aren't cluttering the project with second-best versions. Also, we have no idea how many other sites around the web are hotlinking these images (which I'm told is something we want), so having better images go in the same spot means all wikis and outside sites automatically get the best version, no link-changing required. Specifically, at the thread I linked to above on AN, I was attempting to upload a higher-quality version of a Flickr image (that the original author had re-scanned, and himself re-uploaded on Flickr). The Flickr bot won't replace an image, so it uploaded to a secondary location. It is not an exact duplicate (as the original is poorer-quality), so it simply gets marked as an "other-version". Wouldn't, in this case, a history merge be ideal? Both copies are accurate for when they were uploaded, but the original is completely superseded by the new image, and it would be unwise for anyone to use the older scan over the new scan. Instead of clogging the category, or deleting history, why not just histmerge? I mean, this isn't going to cure the common cold, but would there be any harm in cases like this, providing the admin performing the merge judged it appropriate? ▫ JohnnyMrNinja (talk / en) 10:56, 27 June 2011 (UTC)

I'm confused. If people are hotlinking the second-best versions, then histmerging them would break those links. In your example case, I would simply upload over the first image, without using the Flickr bot. If the second one is always preferable to the original, then no point in uploading it somewhere else. Also, not sure why clogging up the deletion log is an issue, and if everything is properly attributed already and the original isn't needed for attribution—there's no need to histmerge at all, it would take longer than deletion. ←fetchcomms 21:33, 27 June 2011 (UTC)

The issue is discussed in several sections of Commons talk:File naming. I agree with Fetchcomms in this case, but I think we should have consensus about when to use the old name there before dealing with it here. As long as there is no consensus such moves and deletions may be controversial and sorting out a bad history merge can be quite frustrating (luckily there are seldom many versions here, but in some cases there are). --LPfi (talk) 22:28, 5 July 2011 (UTC)

Current proposal vs status quo

I've copied the current policy draft to User:Rd232/speedydraft and annotated many of the headings. Heading in green: criterion is same as existing policy. Heading in red: criterion is new or substantially different. Most strikingly, the contentious criteria F1, F2 and F5 are (at least in this draft) the same as existing policy. So we seem to be in a situation where a substantial part of the opposition to a new policy derives from opposition to current policy! What are we to do about this? PS I couldn't have done this annotation without using my reorganisation of deletion policy at User:Rd232/deldraft, since Commons:Deletion policy is rather badly organised (all quotes are from the current policy, since the reorganising didn't change the meaning but did involve some rewriting for clarity). See Commons_talk:Deletion_policy#Structure. Rd232 (talk) 22:22, 27 June 2011 (UTC)

There is one point on which I disagree : I think C1 is substantially different, as the current version says only "Categories that are empty because all of the files they included were deleted can generally be deleted as well.", compared to the the much more general proposal "Categories that are empty are subject to speedy deletion", so heading should not be green. Croquant (talk) 07:39, 28 June 2011 (UTC)

OK, I've updated that. Feel free to make any other comments, or to edit the page. Rd232 (talk) 13:14, 28 June 2011 (UTC)

There is also "Missing essential information" where the grace period is changed to may be given a grace period. There have been complaints about the change. --LPfi (talk) 22:33, 5 July 2011 (UTC)

Aha, yes. I've changed F5 from green to red accordingly. Rd232 (talk) 23:45, 5 July 2011 (UTC)

"Content intended as vandalism, threat or attack"

I have no idea where the vote on this stands - I saw the banner today, came just now. But the way I see it the biggest flaw in this policy at the moment is the questionable use of "attack" among the criteria. To me it looks like there is a big push by Scientology supporters on Wikipedia to eliminate all the negative press about their cult, including Commons interviews and documents, and doubtless they will claim that anti-Scientology statements are "attacks" that fall under this reason for deletion. It sounds like this provision will become a Wikipedia-like BLP by the back door if enacted. We must not allow a quick kill that prevents people from finding out that such deletions even occur. I am also concerned about the provision about "inappropriate userpages" which may tie in with this. We must not underestimate this cult's ability to infiltrate sources of information and attack freedom of speech, and we must not allow political censorship to infiltrate Commons. Wnt (talk) 03:11, 28 June 2011 (UTC)

I agree that this is problematic. Many of our files are quite definitely a direct attack on somebody, see e.g. File:Alan_dershowitz_by_Latuff.jpg, which was kept at Deletion requests. Many such images are in scope and of historical relevance. We either need to omit this altogether, or be clearer that it applies to personal attacks that are not in scope. Dcoetzee (talk) 09:46, 28 June 2011 (UTC)

What about historic attacks? Category:Government propaganda - for example Bulwersator (talk) 12:50, 28 June 2011 (UTC)

• ?? I think that means vandalsim, threat or attack to wikimedia and/or the users here, not some general prohibition on images of vandalsim, nor a prohibition of images that threaten or attack anybody. --Tony Wills (talk) 12:49, 29 June 2011 (UTC)

Not for the first time, people are coming here to complain about parts of the proposed policy seemingly without being aware of what the existing policy says. From COM:D#General:_speedy_deletion: "Was uploaded with the intent to be used solely for purposes of vandalism, personal attacks, and/or spamming." NB there is another section for ordinary deletion of related content as "out of scope". From COM:D#General:, "Files apparently created and/or uploaded for the purpose of vandalism or attack. Pre-existing designs and symbols that are or have been associated with nationalistic, religious or racist causes are not out of scope solely because they may cause offence. Provided they are legal to host and otherwise fall within Commons scope (e.g. if they could for example be used to illustrate a Wikipedia article on a hate group) they should be kept." True, the G3 header in the proposed policy is a slightly ambiguous in using "attack" instead of "personal attack", but the description makes it clear that this is the meaning, i.e. the same as existing policy. Rd232 (talk) 14:04, 29 June 2011 (UTC)

Any speedy deletion policy has to be objective, clear, and conservative, leaving more ambiguous deletions for deletion requests. I'd argue that identifying an attack that could not serve an encyclopedic purpose is such a subjective endeavour that unilateral action should never be taken in this case, and as such it should not be mentioned here. Dcoetzee (talk) 20:46, 29 June 2011 (UTC)

Then go to COM:D and propose amending existing policy. Rd232 (talk) 00:09, 30 June 2011 (UTC)

Here we're getting to the core problem: when you copy a whole bunch of existing policy, slightly changing all the wording, who knows what changes in meaning and enforcement this creates? The original says "Files apparently created and/or uploaded for the purpose of vandalism or attack", which, though having some ambiguity, pretty clearly seems limited to Wikimedia users grinding their own personal axes. But "Content intended as vandalism, threat or attack" sounds like a whole new meaning. Content is different from files. Intended is different from created for the purpose of. The net result is that a dangerously ambiguous phrase is turned into one which is ripe for full-scale abuse. This is why I don't think we should copy up a policy loosely based on another policy. Wnt (talk) 06:37, 30 June 2011 (UTC)

Please tell me you're not just going by the heading in the proposed policy, and slipping a sliver of difference between that and the existing policy (which at the time the wording was copied had no relevant heading). Just below the heading the proposed policy says "Content that is posted with the intention of causing damage, or with the intention of threatening, harassing, or attacking another person or user." If anything this is clearer and more limited meaning than the existing policy. The existing policy permits speedy deletion for "Files apparently created ... for", which includes exactly the scope that people have concerns about here about "attack" potentially including external content creators. By contrast, the proposal clearly limits the "attack" intention to people posting content to Commons. (This could be made even clearer by changing "posted" to "contributed to Commons".) Rd232 (talk) 08:17, 30 June 2011 (UTC)

You're right, that stuff is listed under speedy deletion in the deletion policy. That was my misunderstanding. Dcoetzee (talk) 10:05, 30 June 2011 (UTC)

I think part of the motivation and support for this proposal comes from COM:D having been a bit of a mess. My recent reorganising helps, but it can still be improved. Confusion about what exactly the policy says seems a bit too common, and I'm sure that's because it's not as easily understandable as it should be. Rd232 (talk) 10:24, 30 June 2011 (UTC)

Policies and guidelines should not be decided by counting votes

As clearly demonstrated above, this approach to creating policies does not work. Please read en:Wikipedia:Polling is not a substitute for discussion.

The way to create and develop policy is:

1. Document existing practices
2. Discuss whether or not the document accurately reflects existing practices
3. Once consensus is clear, adopt the document as policy
4. Discuss additions or changes as necessary, one by one
5. Once consensus for a given addition or change is clear, update the policy
6. GOTO 4

—LX (talk, contribs) 18:47, 29 June 2011 (UTC)

FWIW, it seems to me like a lot of the support comes from a sense that it would be good to have a really clearly written policy, whilst a lot of the opposition (and doubts of supporters) come from concrete policy differences between the current policy and the proposal. In other words, support is more on presentation (it's clear) and opposition more on substance (it's different in meaning). (Although that thesis is a bit undermined by opposition to the propoal which is oblivious to the current policy being the same in some contentious areas.) One conclusion to draw would be to try and improve the current COM:D policy to make it clearer and more helpful, without changing the meaning or expanding deletion freedom, and add any bits from the proposal we can identify as non-contentious; and later on propose the more contentious changes/expansions. Rd232 (talk) 20:37, 29 June 2011 (UTC)

One thing that might help with clarity is i) numbering and ii) using icons (eg an icon for speedy deletion, one for ordinary deletion requests, one for 7-day-wait deletion). This would particularly help internationalization and English-as-second-language readers. I can find anything suitable - somebody would need to create them I think. Rd232 (talk) 21:05, 29 June 2011 (UTC)

The policy says that voting is no substitute for discussion toward consensus, but how do you detect consensus without a poll? As a matter of fact the policy doesn't forbid polls. The general rule for consensus in Wikipedia is 2/3 in a poll in cases where there are a lot of opinions to avoid standoffs.

For the rest I deeply agree with the essence of User:LX:es criticism against the failed voting process above. The process needs to be backtracked to before someone got the impulse of starting the voting process immaturely, and from there further discuss till many voices consider going to a poll for consensus. Rursus (talk) 18:14, 6 July 2011 (UTC)

Commons_talk:Deletion_policy#Speedy_additions

Whilst the discussion here can continue to try and resolve this rather messy situation, I thought we could try and move things along by adding the least controversial parts of the proposed policy into COM:D. See Commons_talk:Deletion_policy#Speedy_additions. (That would turn 5 red headings at User:Rd232/speedydraft green.) Rd232 (talk) 18:49, 29 June 2011 (UTC)

SPEEDY "nots"

i've been spending FAR too much time on this policy debate & it's so "busy" here with other issues (i.e.: the approval process/vote), that i haven't had much time to critique the document, but here's an obvious point:

why is there NO part of this document, where is it stated in clear & strong language what is NOT appropriate use of SPEEDY?

20:12, 29 June 2011 (UTC)

En's CSD didn't used to have such a section either, until I added one. Since a section describing what's not speedy deletable would be descriptive/informative rather than prescriptive, anyone can feel free to add it at any time. Dcoetzee (talk) 20:48, 29 June 2011 (UTC)

A counter-argument to that request is that any use of SPEEDY not expressly approved by the community is inappropriate. w:Wikipedia:Don't stuff beans up your nose makes an argument against making such a negative list. cmadler (talk) 12:39, 30 June 2011 (UTC)

hahaha! but admins are "supposed to" know better (re: nasal bean insertion)! :P Lx 121 (talk) 18:44, 30 June 2011 (UTC)

"Supposed to"...but see also w:Wikipedia:Village stocks, which includes a deletion of Commons:Deletion requests. cmadler (talk) 12:36, 1 July 2011 (UTC)

It depends on what you mean by "expressly approved" and "inappropriate." If there is consensus to overturn a speedy deletion, then it should be overturned. If the administrator realised (or should have realised) that there would not be consensus to delete, then the deletion was a misuse of privileges. If there is consensus that a speedy deletion was appropriate despite not being documented yet, then it should be codified. Our policies are not (and never will be) a complete list of everything that is allowed (or disallowed). Not every action needs to be pre-approved in writing. We've had (appropriate) speedy deletions long before we had any policy on deletion. The argument of en:Wikipedia:Don't stuff beans up your nose (don't feed ideas for disruption to vandals) hopefully doesn't apply to Commons administrators. —LX (talk, contribs) 12:00, 1 July 2011 (UTC)

The problem with what you suggest in regard to speedy deletion is that once it's deleted, the community as a whole can't really evaluate it because non-admins can no longer see the content. So I think true speedy deletion (delete on sight with little or no delay) should be limited to situations that have been expressly approved by the community. But deletions that allow a set time for objection (generally 7 days), such as {{No permission}}, {{No source}}, and {{No license}} can be more flexible because there's reasonable opportunity for any editor to object and/or fix the problem before the deletion is done. I'm personally a big fan of Wikipedia's Proposed Deletion system, in that it allows time for editors to review (and, if appropriate, object) a deletion, but can be used for any reason. So I'd argue for very narrow (and very clear) criteria for true speedy deletion, but a highly flexible proposed deletion-type system. cmadler (talk) 12:45, 1 July 2011 (UTC)

agreed, with the proviso that a "prod" system for commons cannot be just a "cut & paste" of the one from wp/en. different project, different objectives, circumstances, & "needs" Lx 121 (talk) 14:49, 4 July 2011 (UTC)

Proposal

Propose abandoning the current vote, because it has too many problems and in its current form isn't likely to get strong enough consensus to approve as is, and the changes required for consensus are many and quite complex. So i) close the vote section above ii) change the watchlist notice to talk about discussion and point it at a new section on this page; iii) try and summarise the issues and reformulate the discussion to figure out what to do. iv) move User:Rd232/speedydraft (same, with annotations) to the proposal page, to make it easier to understand what's going on relative to the status quo. Rd232 (talk) 21:58, 30 June 2011 (UTC)

willing to support this move with the proviso that the vote is closed (presumably as "no consensus"?) rather than just "abandonned".

any "do-over" attempts need to include a CLEAR record of the current proceedings; that's just basic commons procedure.

Lx 121 (talk) 11:28, 1 July 2011 (UTC)

Support per Lx 121; new procedure should be as described above by LX. cmadler (talk) 12:00, 1 July 2011 (UTC)

Many thanks to Rd232. I agree with LX (as referenced by Cmadler) on procedure. Closure should be with "no consensus" per Lx 121. --Walter Siegmund (talk) 15:13, 1 July 2011 (UTC)

Agree, with sincere thanks to the proposer(s) S a g a C i t y (talk) 16:01, 1 July 2011 (UTC)

Agree. We should go back to discussion. Rursus (talk) 18:25, 6 July 2011 (UTC)

Criteria c1

I was always under the impression that empty categories are even at times encouraged at Commons. Don't we have a policy or guideline that contradicts what's in the current revision? Thanks, Blurpeace 03:50, 1 July 2011 (UTC)

Agree; there are some matrices around that encourage creation of categories that will remain empty for a while. OTOH we should agree that nonsensical ones, such as Category:Tidal rivers of Switzerland or Category:Aircraft of the Napoleonic Wars should be speedily deleted. S a g a C i t y (talk) 16:07, 1 July 2011 (UTC)

what's wrong with aircraft of the napoleonic wars? (even assuming one means napoleon 1 & not n3) they had balloons & gliders/kites... :P (as re: n3, they were certainly using observation balloons by then)

Lx 121 (talk) 14:44, 4 July 2011 (UTC)

Yes, there have been multiple discussions on this page arguing in that direction (see above). I've removed the item. guillom 09:10, 3 July 2011 (UTC)

But when some category has moved or become obsolete it's the usual delete reason ... a×p_de^Hello! 16:15, 3 July 2011 (UTC)

"the USUAL delete reason" -- keywords here; is there any reason why it's BAD to prod unused categories, instead of using speedy? or better: define (& explain) the circumstances under which prod'ing would be bad & speedy would be better for this? Lx 121 (talk) 14:41, 4 July 2011 (UTC)

An example of why common sense is better than broad policy, hm? ←fetchcomms 04:00, 6 July 2011 (UTC)

Broad policy is common sense. For our purposes, it's the most balanced approach available. Blurpeace 08:53, 7 July 2011 (UTC)

My two cents on this policy

I recognize it's been some time since my last actions here and I still don't know when it's gonna be some more again, but still I thought of letting everyone know what I think of this policy. Reading it, I immediately recognized all of the reasons why I deleted stuff back then. There's nothing to disagree about concerning the content. But I really don't know why there's a need for this policy. It's not as if we ever had any problems with too many wrong speedy deletions. And if that ever happens, those going crazy need a good and fast de-sysop, as they obviously aren't able to see the difference between acceptable and unacceptable. No policy will work with such persons. That'd be the only good reason I could think of why we need this policy. Now I don't know what led to the creation of this page, but I really see the potential of how the seemingly good effects might come back just like a boomerang and hit us. You know, "policy" is a very strong word. It means "I know that the current situation really isn't perfect, but if at any time we do something against this policy, then we're seriously fucked up." Caution is advised in using it and excessive usage of it should be avoided. Because what matters in the end is common sense, not policy. I noticed already in my time how folks have tried to use policy to circumvent common sense. Adding yet another policy really doesn't help this matter. You know, I know the feeling that you apparently need a policy on something, because one believes it not to work, but I experienced it regularly that it really only seems to be necessary, but in fact it creates more damage than it solves in the end. You're usually better off without the policy. Back then, I've always wanted a good help page that explains new users why their images have been deleted. But for a reason, I've never wanted or actually planned a policy. The reasons cited on this page are the aspects why pages are deleted, but not necessarily does a page that matches one of these criteria have to be deleted. It's a huge difference in logic. Coming back to this page, I'd advise to make this an essay. It's a good information about the reasons that Commons admins delete pages for, and it's clear that caution is advised when citing it. Well, now that's been a bit more than two cents, but anyway, I hope my point is clear (I have intentionally not voted above, but made it an own section, because I don't see it as a vote). If any questions are left, please let me know. --The Evil IP address (talk) 18:29, 3 July 2011 (UTC)

+1 Yann (talk) 07:29, 4 July 2011 (UTC)

Also fully agreeing with you. Esby (talk) 14:55, 4 July 2011 (UTC)

Absolutely correct. There have never been major problems with speedy deletions, policies should never be used to override common sense. ←fetchcomms 20:26, 4 July 2011 (UTC)

Yes, there have been problems. Remember Jimbo and the old erotic art? There are also admins who seem to insist on URLs for obviously free images. See the log of US patent images from 1885. And User talk:High Contrast#Flagging US patent images as "source needed"?. This people may interpret "Missing essential information" very unreasonably. /Pieter Kuiper (talk) 18:01, 5 July 2011 (UTC)

That's not commonplace, and that's not something policy would solve. Jimbo, I think (not trying to bash him) would have done those deletions regardless of a policy. Those admins who insist on certain information? That's not a deletion policy issue, that's an issue regarding how much info Commons needs. A CSD policy does not change how much info is needed. And deletion is no big deal, we can undelete just as quickly as deleting something. All of the examples you cited are where common sense can be applied. Not just a policy, which people can also twist to their interpretations even easier. ←fetchcomms 04:03, 6 July 2011 (UTC)

We agree, I think: more policy texts will probably cause more problems than they might solve. But unwarranted deletions are are a problem, as long as we do not have an easy way of reverting the edits of CommonsDelinker in the projects. /Pieter Kuiper (talk) 08:48, 6 July 2011 (UTC)

One possibility is to write a new paragraph or two in the relevant section of COM:D which clarifies a bit the expectations of the community of how admins should interpret speedy criteria, eg on what situations might call for turning a speedy nomination into a DR, or on whether (or when) admins should be encouraged to not delete things directly under speedy deletion, but to tag instead (ensuring a second opinion from another admin). Rd232 (talk) 09:37, 6 July 2011 (UTC)

Simply agreeing with Yann, Esby & The Evil IP address. --Herby ^{talk thyme} 15:14, 6 July 2011 (UTC)

Idem, I agree with Herby, Yann, Esby & The Evil IP address. --Dereckson (talk) 22:22, 6 July 2011 (UTC)

+1 to above. I don't quite get why the default answer to every problem Commons has faced these past few months has been "X isn't working, lets make a policy!", especially when (nearly) every policy proposal fails due to lack of consensus. There has been a lot of good work on this page and it seems silly to tag it as {{Rejected}}. Therefore, I'd suggest we should try to convert this into some workable guidance. "Guidelines" are more in keeping with Commons ethos than "policy", as guidelines allow common sense to be applied.--Nilfanion (talk) 09:10, 9 July 2011 (UTC)

 Agree and let's rely on the common sense of administrators S a g a C i t y (talk) 10:37, 10 July 2011 (UTC)

 Agree with The Evil IP Address, etc. Wknight94 ^talk 13:31, 10 July 2011 (UTC)

 Agree "It's a good information about the reasons that Commons admins delete pages for, and it's clear that caution is advised when citing it." That is good sense and guidance. --Walter Siegmund (talk) 14:55, 10 July 2011 (UTC)

I disagree. We have a lot of problems with the speedy deletion pipeline. E.g. no source deletions (when adequately sourced pictures get deleted, because for example the sourcing was done in a some slightly non-standard way), "duplicate" deletions (when a restored version of a painting can be deleted as a "duplicate" of the original, or even the original can be deleted as a "duplicate" of a replica), out of scope deletions (e.g. promotional, but useful pictures can be deleted), and so on. The main problem with speedy deletion is that there is almost no community review on the speedy deletion pipelines, so a good picture can be easily deleted unnoticed by anyone. And when something get speedily deleted unnoticed effectively it's deleted permanently, because there are no useful tools for speedy deletion review even for admins (i.e. browse/search in deleted content). That's why a strict speedy deletion policy with a limited list of classes of pictures that can be deleted speedily (in a nutshell -- everything not obvious should be sent to DR for community review) is very important, and why dilution of speedy deletion criterions is dangerous. Trycatch (talk) 02:23, 11 July 2011 (UTC)

strongly agree with the above comment. another part of the problem though: one person's idea of "obvious" IS NOT the same an another person's. ultimately, it's always going to be a "judgement call" by the SPEEDY-deleting admin. that's why we need to be very careful about what we decide to include as "obvious". Lx 121 (talk) 02:53, 11 July 2011 (UTC)

I also agree with Trycatch's comment, and that's exactly why I'd like to see a robust and flexible PROD-type system, with very limited true speedy deletion. cmadler (talk) 11:46, 11 July 2011 (UTC)

Commons:Proposed deletion is a redlink, and en:Wikipedia:Proposed deletion a clear model to adapt (not least for the technical template bits, some of which are quite complex AFAIR). Propose it at COM:VPR? Rd232 (talk) 00:31, 12 July 2011 (UTC)

Some of the most relevant classes of proposed deletion already exist on Commons: That's what {{No source since}}, {{No license since}} and {{No permission since}} are all about. Remember PROD on en is an article, not an image, process. It might be appropriate to implement prod for "out of scope" deletions, but given the performance of the No Source I'm not sure another similar, but more contentious queue, is the way forward - it will just get backlogged and be prone to administrative errors...

One thing we could do (irrelevant to any policy of course) which will be an improvement on current systems would be to log what gets tagged with NSD etc. That strikes me as a bot task, and QuickDelete.js could be modified to add the file to the log page.--Nilfanion (talk) 00:51, 12 July 2011 (UTC)

Those examples are more like the en:WP:BLPPROD "sticky prod" system where the problem has to be fixed to avoid deletion. Standard "proposed deletion" can be opposed for any reason, or indeed no specified reason. Rd232 (talk) 14:23, 12 July 2011 (UTC)

Yes, but what classes of image deletion would a true prod make sense for? Is there potential for something other than "out of scope" (better handled by full deletion requests IMO)? When they are correctly used, files marked NSD/NLD/NPD must be fixed for us to be able to host them. Guidance on when admins should "delete on sight" as opposed to marking for deletion, so another admin can delete (making it a 2-man job) is more relevant - if that practice is discouraged we get a 2-man rule.--Nilfanion (talk) 16:02, 12 July 2011 (UTC)

password protected embedded files

Would like to add the following to criteria for speedy deleting of files...

9. Password protected embedded files.

The file contains additional embedded data in the form of a password protected archive.

This issue has come up here. Because of the serious nature of having unknown and quite probably illegal material residing on our servers, I believe this practice should be dealt with swiftly and firmly. In addition to deleting such files on sight, I think a zero-tolerance policy with regards to the uploader is called for as well. This is not an uninformed uploader who simply is unclear on the rules. This is an aggresive uploader who knows full well what he is doing and our response should be an immediate and indefinite block. – JBarta (talk) 09:42, 5 April 2013 (UTC)

 Support. --Túrelio (talk) 10:07, 5 April 2013 (UTC)

•  Support as we are not a personal file host. Also this should be detected by MediaWiki automatically (bugzilla:46921) and upload of such files should be refused. -- Rillke^(q?) 10:09, 5 April 2013 (UTC)

Indeed. That is even more important, since we can detect such discrepancies between image resolution and file size only by chance. --Túrelio (talk) 10:15, 5 April 2013 (UTC)

The most extreme instances can be detected by filesize alone, but I would think that's not an accurate detection method. Surely there must be a better way to detect such uploads. – JBarta (talk) 10:19, 5 April 2013 (UTC)

•  Support --99of9 (talk) 10:23, 5 April 2013 (UTC)
•  Oppose Although I voted delete in the DR mentioned above but there was a reason that they are copyvio/garbage files. However, if files were to be in Scope and properly licenced, then it would be appropriate to re-encode them making their sizes smaller, but not to delete them or to punish anybody. Sinnamon Girl (talk) 10:25, 5 April 2013 (UTC)
•  Support for clarity to avoid argument - files shouldn't contain other embedded files. But shouldn't it be worded slightly broader? It wouldn't be acceptable, for instance, if the embedded file wasn't an archive, or the archive wasn't password-protected - it would just be more obvious what was hidden. Rd232 (talk) 10:31, 5 April 2013 (UTC)

I'm not sure if it works for files other than archives. And while I can't see any reason to embed anything in a JPG before uploading it here, for me the really bad thing is the password protected archive. It would be nice if the wiki software could detect such a thing and refuse the password protected files outright and flag the rest for human inspection. What's troubling is that while these files by this particular uploader were fairly obvious, it doesn't take a much smarter idiot to do this in a less detectable way. Wikimedia servers may be loaded with such files and we'd never really know. Some sort of auto detection might not be a bad idea. – JBarta (talk) 10:52, 5 April 2013 (UTC)

I'm pretty sure steganography can be used to embed any type of file. Auto-detection would be good, but is probably difficult and may be computationally intensive. Worth flagging to developers if it hasn't been already, but it's not an easy ask. Rd232 (talk) 11:15, 5 April 2013 (UTC)

Thumbnails embedded in large images are a good example of a valid reason. Most modern digital cameras do this by default, by the way. This is why displaying a huge image folder with thumbs is usually very fast. -- Rillke^(q?) 14:56, 5 April 2013 (UTC)

Fair enough, exempt thumbnails. Is there any other valid reason? Rd232 (talk) 15:18, 5 April 2013 (UTC)

ICC profiles and other things (some XML files also describing metadata) that are usually saved in the file's metadata. -- Rillke^(q?) 15:32, 5 April 2013 (UTC)

Alright, well how about a wider prohibition on steganography then? Rd232 (talk) 16:06, 5 April 2013 (UTC)

Although our uploaders are discouraged to embed watermarks, it is usually useful to include some information easily allowing you proving you are the copyright holder/author (which can become really difficult for digital photos uploaded in full resolution). Generally, steganography should be prohibited, yes. It can be really hard to discover patterns in images, however. -- Rillke^(q?) 16:47, 5 April 2013 (UTC)

I'd hate to see this proposal go the way of so many others and get bogged down in details. I think we can all agree that embedded password protected archives is a bad thing. Let's agree on that and start with that, ok? Below is a minor rewording that can easily be expanded if necessary. – JBarta (talk) 23:17, 5 April 2013 (UTC)

That's the conclusion I was reaching. I would tweak the title to Encrypted embedded data (since embedded data is very common and usually fine), but basically, yes, let's just stick the narrow thing in the "policy" and then either have a discussion about broadening it, or just leave it and see how it goes. Rd232 (talk) 22:09, 6 April 2013 (UTC)

9. Embedded data.

The file contains additional embedded data in the form of a password protected archive.

• 1) Embedded hidden media is a bad thing. 2) Bad things should be speedy deleted. Therefore, media with hidden stuff should be deleted. Now let's try this again. 1) Badly cropped images are bad. 2) Bad things should be speedy deleted. Therefore, if an image was cropped incorrectly it should be speedy deleted. It is nonsense! The fact that something is bad doesn't mean that it should be speedy deleted, especially when it's trivial to fix the problem. Sinnamon Girl (talk) 04:31, 6 April 2013 (UTC)

You're entirely missing the idea of degrees of bad. Shoplifting is bad and murder is bad yet there are different punishments for each because they are different degrees of bad. Embedded password protected archives and watermarks are different degrees of bad. And not necessarilly trivial to fix... especially if there are many files and that have the problems these did. Bottom line is that embedding password protected archives in image files then uploading them here is an indefensible aggressive act by someone who knows exactly what they're doing. Such files may contain kiddie porn for all we know. This not a mistake or misunderstanding by a newbie uploader. This is someone who wants to distribute files (almost certainly illegal) through our servers. I can't see how we should tolerate that and somehow try to save and make use of whatever files they embed the stuff in. – JBarta (talk) 07:15, 6 April 2013 (UTC)

Right. It seems we run into the same strawman argument over and over again on this page. Something falling into a category of candidates for speedy deletion does not mean that administrators are compelled to delete it if there are circumstances that provide for a simple better solution. For every rule proposed here, someone comes up with some obscure and enormously unlikely corner case, and fear of entirely reversible collateral damage paralyses us and prevents us from getting anything useful done. Seriously, what are the odds that someone uses a correctly licensed, valuable photo as a mule for their password protected archive of child pornography and terrorist plots? And even if they do, it still makes sense to delete it until the file has been scrubbed. —LX (talk, contribs) 09:37, 6 April 2013 (UTC)

I do not see a majority following Sinnamon Girl's arguments. -- Rillke^(q?) 09:53, 6 April 2013 (UTC)

Seeing as this isn't policy, shouldn't we either add this to COM:D, or have another go at making it policy? Rd232 (talk) 10:31, 5 April 2013 (UTC)

As this proposal was created two years ago and speedy deletion is used all the time, it probably wouldn't be a bad idea to make it official policy. – JBarta (talk) 12:35, 5 April 2013 (UTC)

•  Support broad wording suggested by Rd232. I endorse LX's view. Walter Siegmund (talk) 15:56, 6 April 2013 (UTC)

Would either Walter Siegmund or Rd232 care to offer a version of a proposed addition that contains "broad wording suggested by Rd232"? – JBarta (talk) 18:52, 6 April 2013 (UTC)

I'm not sure. My discussion with Rillke above suggested it was harder to word it broadly to cover "bad stuff" without covering "good stuff" than I expected. I'm open to suggestions! Rd232 (talk) 22:05, 6 April 2013 (UTC)

Qualifying it with "malicious or encrypted" should be sufficient. —LX (talk, contribs) 23:28, 6 April 2013 (UTC)

I wonder if the following would serve? "The file contains obviously extraneous data, especially in combination with other factors, e.g., inconsistent metadata or dubious sources." Non-obvious cases will have to be considered by COM:DR. But, I think this covers Commons:Deletion requests/Files uploaded by Colorj123 without being too narrowly construed nor too broad. --Walter Siegmund (talk) 00:58, 7 April 2013 (UTC)

•  Oppose per Sinnamon Girl. Multichill (talk) 17:56, 8 April 2013 (UTC)
  • Embedding archives does not accidental happen but by intent, their content is usually out of scope and can't be accessed usefully using MediaWiki nor will in future and these archives may carry potentially malicious stuff. I don't like to be forced to download a full exploit-discovery toolset with some suitable arbitrary payload for "re-encoding". This is not my job. -- Rillke^(q?) 22:37, 8 April 2013 (UTC)
    • If the password-protected portion can be removed and still provide a useful media file, that would be preferable to deletion, and may preclude a *speedy* deletion. If there is no real way to remove the unknown content, then yes I agree they need to go, the quicker the better. Carl Lindberg (talk) 03:51, 9 April 2013 (UTC)

The prospect of a "useful media file" in such circumstances is slim. The uploader could care less about the cover file he's uploading. As with the uploads that prompted this proposal, the files had bogus filenames, nonsensical descriptions and who knows where they came from or what their true copyright status is. This is an uploader whos only purpose for uploading is to place hidden illegal files on a public server so they can be accessed by others. It stands to reason he's going to use whatever images he can lay his hands on. They may even have been downloaded from Commons, embedded with the archives and re-uploaded. I think it's absurd to even attempt to hunt down the copyright status and attempt to make use of these files. More trouble than it's worth IMO. And I'll tell you this... what's even MORE important here is that Commons may be loaded with such images right now that have slipped under the radar. As we speak Commons might be serving up kiddie porn to the assholes of the world and we're fretting over keeping the mule images? Being able to dectect this stuff on upload would be a very wise idea. Sorry, I'm a little passionate about this. Someone is ramming a pole up our ass and after the guy is kicked out, you're wondering if we might still make some use of the pole? – JBarta (talk) 04:17, 9 April 2013 (UTC)

pithy - but well put! And I'm concerned about things we're missing too. I'm going to start a new VP thread about detecting these things, since that's not a discussion for this page. Rd232 (talk) 08:00, 9 April 2013 (UTC)

Hang on - public discussion of how to detect these things is a bad idea. Maybe file a bug, so developers can discuss it more privately? Rd232 (talk) 08:06, 9 April 2013 (UTC)

Never mind, Rillke already filed a bug. Rd232 (talk) 15:54, 9 April 2013 (UTC)

•  Support Commons is not a free webhost and we shouldn't host material if we don't know if the material is safe (it could be a virus) or legal (it could be copyright violations, child pornography or anything). Of course, if a photo is useful and unquestionably free, it should be fine to simply reupload a new revision without this contents and delete the old revision. In this case, it seems that the only purpose was to get free hosting of unknown data, though. --Stefan4 (talk) 15:33, 9 April 2013 (UTC)
•  Support per a number of the above --Herby ^{talk thyme} 15:43, 9 April 2013 (UTC)
•  Support Commons cannot take any responsibility for things that cannot be inspected. --Foroa (talk) 16:36, 9 April 2013 (UTC)