• A consensus to keep these images that express strong opinions shouldn't be misconstrued as supporting a change of policy that would disallow "excessively polemic" opinions--just the opposite. Rybec (talk) 08:06, 1 April 2013 (UTC)[reply]

  I'll put "An otherwise non-educational file does not acquire educational purpose solely because it is in use on a user page (the "User:" namespace) of another project, but by custom the uploading of small numbers of images for use on personal user pages is allowed. Icons for use with e.g. user boxes are allowed, too." on the policy page. --ilaiho (talk) 08:23, 1 April 2013 (UTC)[reply]

I think that the text "Einfaldlega betra en RÚV" (in all caps) needs to be removed from the image File:Skjareinn.svg. This text is in Icelandic, and translated it would be "Simply better than RÚV". RÚV refers to Iceland's national public-service broadcasting organization.--Snaevar (talk) 15:53, 1 April 2013 (UTC)[reply]

You can file a request at "Commons:Graphic Lab/Illustration workshop". — SMUconlaw (talk) 16:25, 1 April 2013 (UTC)[reply]

Thanks. Did that.--Snaevar (talk) 18:31, 4 April 2013 (UTC)[reply]

Wikimedia Foundation is developing a "Welcome to Commons" print brochure, similar to the Welcome to Wikipedia brochure. It's a very rough draft right now, and I'm eager for community feedback. In particular, I want to make sure it's as accurate as possible without going into the details too far (similar to what the Upload Wizard comic does, but with a little more detail). Here's the draft: Commons:Welcome to Commons brochure. Please give it a close read and leave feedback! The next step, after about two weeks of community feedback and revision, will be to hand it off to the designer.--Sage Ross (WMF) (talk) 15:33, 2 April 2013 (UTC)[reply]

I looked through it. It looks good - I did not find any issues. --Jarekt (talk) 15:01, 3 April 2013 (UTC)[reply]

Using the expiremental "Chunked uploads for files over 1MB in Upload Wizard" preference, it should be possible to upload files up to 500mb. Since there were some relatively recent changes in this area, there might still be problems. The current system uses the job queue. Once things are working fine, the 500mb limit can be raised by some amount (no more than 5GB though). Realistically page deletion and moves will start to get impractical with such large files pending a rewrite of the whole file layout system. Any problems can go in bugzilla. The primary bug is 36587 at the moment. Aaron Schulz (talk) 21:24, 2 April 2013 (UTC)[reply]

Hi! There are transcripts on the file page of File:Sextortionagent interview.ogg. Should they remain there or should they be moved to Wikisource? Thanks WhisperToMe (talk) 03:16, 3 April 2013 (UTC)[reply]

As it is, it's not of very great length. AnonMoos (talk) 09:19, 3 April 2013 (UTC)[reply]

Each individual transcript is not very long, but how many language versions should be posted until it is moved? WhisperToMe (talk) 20:44, 3 April 2013 (UTC)[reply]

• 
  Bordeaux {FR}
• 
  Antwerp {BE}
• 
  Brussels {BE}
• 
  Venice {IT}

So I have these files that are part of one set (that I will expand in the future), and the file names aren't harmonized. Just wondering, what tag between the parentheses  would be the clearest? Napoleon, Napoleonic or Empire? I'd like to get it "right" before I ask someone to harmonize them all. Lemmens, Tom (talk) 12:48, 3 April 2013 (UTC)[reply]

As I understand it "harmonising" isn't really a reason to request a rename. The current names are descriptive and correct. Sinnamon (talk) 12:58, 3 April 2013 (UTC)[reply]

Uploader requested is, in any case. :) Lemmens, Tom (talk) 13:15, 3 April 2013 (UTC)[reply]

Funny thing is that I've actually checked if you were the uploader... but I didn't check to see if your signature matches your User:name. Honest mistake, didn't mean to put you down or anything. Sinnamon (talk) 13:49, 3 April 2013 (UTC)[reply]

No problem. :) Any opinion on the best tag? Lemmens, Tom (talk) 15:12, 3 April 2013 (UTC)[reply]

what about <blah blah> (First French Empire).<ext>? Rbrausse (talk) 15:16, 3 April 2013 (UTC)[reply]

I cropped File:Leona Helmsley.jpg for use in her en:wp infobox because of our policy about mug shots. I noticed it is still full size in other language projects. Do those have a similar policy and should it be changed out?--Canoe1967 (talk) 17:07, 3 April 2013 (UTC)[reply]

You should ask respective projects. Ruslik (talk) 08:04, 4 April 2013 (UTC)[reply]

At File:Sextortionagent interview.ogg I notice that the listing of subtitles gives "Simplified Chinese" twice even though one set is Traditional Chinese. How should the labeling be fixed? Thanks WhisperToMe (talk) 18:31, 3 April 2013 (UTC)[reply]

Fixed. Ruslik (talk) 08:02, 4 April 2013 (UTC)[reply]

Thank you! WhisperToMe (talk) 18:37, 5 April 2013 (UTC)[reply]

Did anyone else notice the change to the colour scheme on March 31 (http://commons.wikimedia.org/w/index.php?title=Commons:Community_portal&diff=93642920&oldid=93641372) does anyone else care? Should we leave how the community pages look to the whims of individual editors-or is it the kind of thing that should be discussed first?--KTo288 (talk) 19:47, 3 April 2013 (UTC)[reply]

I don't protest this user's reversion but not everything needs to be discussed and decided —Mono 20:09, 3 April 2013 (UTC)[reply]

• Changing the tables to div elements was an improvement. The grey decorations looked fine to me; of course it's a matter of taste. However, other pages on the site (this page, Help:Contents, and the main page) have blue and yellow decorations, whereas Commons:Contact us has blue and grey. The site would probably look most pleasing if the colors were the same on the various pages. Rybec (talk) 00:37, 4 April 2013 (UTC)[reply]

Tervuren is a Belgian municipality. Some doglover a confusing redirect to a dog type. I renamed the redirect to Tervuren (dog), only the original redirect stil exist. Most people are looking for a municipality when they type in "Tervuren", not a dog (sub)breed.Smiley.toerist (talk) 22:55, 3 April 2013 (UTC)[reply]

Searching for "Tervuren" now takes you to Category:Tervuren. Also, "doglover" is fighting talk where I'm from --moogsi (blah) 02:02, 4 April 2013 (UTC)[reply]

"Doglover" is illegal in my country. Rodhullandemu (talk) 23:42, 4 April 2013 (UTC)[reply]

Earlier today, I discovered that uploads coming from mobile web lacked the author and source parameters in the {{Information}} tag, which get automatically added to uploads marked as "own work" via the Upload Wizard. We've made sure to add in the missing information for the mobile web uploads to date and will deploy a fix tomorrow. In the meantime, if you see new uploads coming in from mobile, please hold off on tagging them for deletion for missing author/source – the fix should be deployed around 1pm PST tomorrow (20:00 4 April UTC). Obviously this doesn't change the fact that blatant copyvio and other inappropriate files coming in from mobile should still be tagged and deleted just like desktop uploads!

Big thanks to XenonX3 for catching this, even though I originally had no idea why images that were my own work were being tagged for deletion :) If you have any questions, please let me know on my talk page or feel free to jump into the mobile channel on IRC (#wikimedia-mobile on freenode). Thanks, Maryana (WMF) (talk) 00:58, 4 April 2013 (UTC)[reply]

I just deleted two pics where people photographed movie posters/albums and posted them. Could you perhaps disable the upload buttons on pages in categories like movies, albums, and books on the Wikipedias where these come from? —Mono 01:05, 4 April 2013 (UTC)[reply]

There are plenty of copyvios coming from those mobile uploads. I haven't used the feature myself but I believe it doesn't explain the importance of correct licensing enough, so that people just upload what they think would fit into articles. I would suggest something like a popup before uploading where the uploader is being warned what he isn't allowed to upload. Otherwise we are flooded with copyvios... XenonX3 (talk) 01:09, 4 April 2013 (UTC)[reply]

I dont know how to test this way of uploading with my mobile device. I observed german users uploading stuff that is clearly unfree such as movie posters, cd covers or music video screenshots. I dont know why, but for some reason In my whole Commons time I only had a very, very few german users uploading such stuff with their first contribs, maybe because german Wikipedia gives them a basic idea what free content is. From this observation and my past experience on Commons I guess that there is zero instructions about "free content" or "own work" in this new way of uploading. This requires improvement. --Martin H. (talk) 01:14, 4 April 2013 (UTC)[reply]

It is a known problem that there is currently no licensing tutorial. On the other hand, a licensing tutorial that will actually be read and understood is reaaaaaaaaaaaally hard to do. Currently we have none at all, which is... also sub-ideal. Suggestions on something that's only two or three screens long, easy to understand, and easy to localize, would be very welcome. This is something we want to fix! --brion (talk) 21:19, 4 April 2013 (UTC)[reply]

Copyright and licensing is hard. It requires reading. It requires time. You can't change it. You just can ensure that all information is easily accessible. -- Rillke^(q?) 21:54, 4 April 2013 (UTC)[reply]

I would be tempted to forget trying to teach users on mobile about copyright as part of the upload process; that's just not going to happen. I mean by all means provide links to Commons' resources on copyright, but don't expect most users to read it, even if you put "are you sure you know what copyright is" type warnings. What you want is a wizard that walks users through the key issues by asking them questions, and based on those questions, upload with appropriate "check-me" templates. For instance, questions would be "what's this a photo of?" with various options and if appropriate follow-up questions about "who made it, when"; "are there any people in it?", with follow-up questions about consent and public/private place, etc. Rd232 (talk) 22:36, 4 April 2013 (UTC)[reply]

An interactive license-wizard. You really believe the WMF is able to create one? If they would be, they would have chosen to do so in Upload Wizard. But instead they created a static comic as a "tutorial step". -- Rillke^(q?) 15:24, 5 April 2013 (UTC)[reply]

• Comment: Suggestions for how to educate new users given the contraints of mobile would be much appreciated! It's not an easy problem. We do have some educational messaging already in place: see the gallery below. Keep in mind that the text has to be very short and very precise, both because it's being displayed on a tiny mobile screen and because these messages have to be localized into the 280+ languages of all Wikimedia projects. The mobile team works iteratively, pushing out small changes every week, and the upload features are still fairly green and will definitely undergo tweaks/improvement. Take a look and tell me what you think:

• 
  Step one: on any mobile Wikimedia site (e.g., en.wikipedia.org, it.wikivoyage.org) you can access login and features from the top left navigation menu. Once logged in, you can donate an image to Commons via the Uploads menu, as well as upload and add an image to articles that have no lead image.
• 
  Step two: new user with no Commons uploads taps on Uploads and sees a brief three-step uploading tutorial. Replace "Wikipedia" with whatever project the user is on – Wikimedia Commons, Wikivoyage, etc.
• 
  Second screen of the tutorial.
• 
  Last screen. User will keep seeing this tutorial until they upload their first file.
• 
  Step three: user taps "donate image" button in the Uploads view or the "add an image" button on articles missing images. She selects an image from her phone gallery or takes an image with her phone. This is the image preview screen once an image is selected.
• 
  Step four: new user taps on "what does this mean?" under "I, $USERNAME, created this image" and see some more instruction.

Maryana (WMF) (talk) 18:19, 4 April 2013 (UTC)[reply]

It's a good start, but doesn't really explain that you can't just take photographs of things that are copyrighted, which folks here are saying seems to be an issue. --brion (talk) 21:21, 4 April 2013 (UTC)[reply]

As an admin often doing recent-uploads-patroling, in my experience we would fare be better without this mobile-upload-facility. Besides of the eventually solvable problem with missing source/author/etc. entries, the main problem is what content is uploaded via this way, it's mostly trash, followed by copyvios, followed by attack images (for example: File:Hermaphrodite 2013-04-04 14-28.jpg). To get an idea look into Category:Uploaded with Mobile/Web. I see this as a systemic error, which cannot be solved. And the price for this ill-considered feature/bug has to be paid by our patroler/admin force. --Túrelio (talk) 18:39, 4 April 2013 (UTC)[reply]

+1. I'm sorry to see WMF resources going into this at this time, when we have so many more pressing development needs. I can understand mobile apps targeted at specific things (like Wiki Loves Monuments), because you can have a little blurb that's specific to that and it's also in a context of some organisation. But a generic mobile upload app? It should be obvious that this needs a lot of guidance to walk users through copyright and COM:PEOPLE issues, and for the love of God, we can't even manage that for the Upload Wizard (which ought to be an easier task, not being targeted at small screens). Since the chance of this getting pulled is approximately zero, we can only hope that development of a proper copyright/COM:PEOPLE upload wizard for the mobile web app will actually happen. But far more likely is that we'll get something just as half-arsed and uneditable as the Upload Wizard. :( Well, just to finish on a positive note: how about setting up an onwiki development page that provides a sort of rough drafting area for the app content (maybe in the style of en:WP:WIZ). Then it'll be easier to suggest changes. Rd232 (talk) 20:40, 4 April 2013 (UTC)[reply]

I am in full agreement: Most of our good pictures are created with huge efforts. Most of the mobile uploads aren't and we can't expect this to happen. The only possible benefit I see is that all uploads going to Commons must be free so if something exceptional is captured by the uploader, it will be free and not exclusively sold to press agencies.

Was there a careful check against the Wikimedia Foundation's mission, a list of use cases to check against before starting the development? -- Rillke^(q?) 22:04, 4 April 2013 (UTC)[reply]

The Wikimedia Foundation's mission is to bring more contributors in to all of our projects, to nurture and support the growth of the sum of all human knowledge. Getting new users involved is particularly important, because the existing community has a hard time keeping up with the influx of new content, as mentioned above. It's important to remember, however, that new users are going to make mistakes, whether that's getting markup wrong when editing Wikipedia or not understanding what/how to upload to Commons. We try to minimize their ability to make mistakes by including appropriate messaging and a good, intuitive UI in new features, but taking away the ability of an entire class of users to contribute just because some people will upload bad files seems extreme. Keep in mind that there are many places in the world where mobile devices are the primary if not sole connection to the Internet; should we restrict those users from participating in the Wikimedia movement altogether? Also, if you look at sales data, smartphone cameras have overtaken "real" cameras years ago, and mobile camera technology continues to improve exponentially, making it possible to take some really high quality photos on a phone.

I do have to disagree with the characterization that these uploads are all useless "trash." Yes, there's some copyvio and blurry test shots, but there are quite a few examples of articles that had no images whatsoever and were illustrated by mobile uploaders who were brand new to Wikimedia projects and would almost certainly never have contributed to Commons/Wikipedia otherwise: Spitz on English Wikipedia, Matanza en los penales del Perú on Spanish Wikipedia, Palestinian Security Forces on Arabic Wikipedia, The Normandy on English Wikipedia. There are more perfectly acceptable files in that category if you care to look. A glib interpretation of recent changes to Commons might suggest that the majority of uploads to Commons are pretty low quality in general... Obviously, not every new file is going to be Featured quality. If they were, we'd run out of days in the year to feature them all :) Maryana (WMF) (talk) 01:19, 5 April 2013 (UTC)[reply]

@Maryana, sorry, but your posting reads as a PR text to defend this feature/bug. That doesn't change the facts. It's not "some copyvio". The copyvio-rate is far higher than in non-Mobile/Web-uploads. What you see in Category:Uploaded with Mobile/Web is only what survived the first-line of recent-upload-patrol, i.e. most blatant copyvios and attack images are already removed. At least for the next days I will completely refrain from patroling these uploads. If WMF wants to get Commons trashed, then be it so. --Túrelio (talk) 06:05, 5 April 2013 (UTC)[reply]

Adding entropy to Wikimedia Commons will definitely not support the growth of the sum of all human knowledge. Most people are simply unable to serve good quality (of categorization, description, file name, image quality) with mobile devices. Fingers are too large to type sophisticated descriptions in multiple languages, folk is distracted when using these devices, …

Personally, I am happy to welcome new users and of course new users make mistakes. But the ability to educate them after they made a mistake is essential. With the mobile feature, I have the bad feeling they will never read messages, I am writing on their talk page; our internationalized templates will surely look poor on small displays, …

Furthermore you seem to have completely lost the ability for self-criticism: You call your own product good and intuitive despite the issues raised here. I understand that you've put a lot of efforts into its development but the result is currently unsatisfactory.

We are not talking just about some copyvio and blurry test shots, we are talking about > 50 % of the uploads! More than a half of them are not really useful or educative or are copyright violations. I will prove this with statistics as soon as enough are collected at Commons:Mobile app/deletion request tracking, Category:MobileUpload-related deletion requests and Commons:Deletion requests/mobile tracking.

The fact that more cell phones with cameras are sold than digital cameras led you to the ill-considered conclusion that people buy them to take good photos and contribute good content. Perhaps they will in future and they will learn to. But as for now, they brought them for reading and for communication.

Even the quality of the sample image you gave is arguable: It is of high resolution but with the two legs in the foreground, it will look really strange in a Wikipedia article. Quality is not just a matter of image resolution.

I hope you're going to improve the App(s). You could for example show a text like the Welcome to Commons brochure, create some questions about it and before users are able to create an account using a mobile device, they must answer a question about what Commons is (or is not). -- Rillke^(q?) 10:50, 6 April 2013 (UTC)[reply]

_at least_ something like this should be included in the mobile upload wizard, the sentence "Please only donate photos that you took yourself." is completely misleading regarding copyrights. Rbrausse (talk) 12:25, 5 April 2013 (UTC)[reply]

@Maryana. I have to agree with Turelio. Are you planning to determine the ratio of useful/useless uploads? I say that because it would show to the commons community that you're really interested in our project and not in your salary. I have to say that unless a significant ratio of useful contents is obtained, the Mobile upload feature should be blocked. --Ecemaml ^{talk to me/habla conmigo} 13:40, 5 April 2013 (UTC)[reply]

Ecemaml, absolutely. Below is some preliminary work I've done looking at the nature and quality of mobile uploads. What you're seeing is a sample of desktop uploads from November 2012 (a non Wiki Loves Monuments month) compared to a sample of mobile web uploads. The red bits are files reuploaded from elsewhere on the web. The rate of copyvio does appear to be higher for mobile web uploads, but it's nowhere near what some users appear to be claiming here.

It's also important to note that the volume of mobile uploads is still quite low as compared to desktop uploads: there are currently about 200-300 uploads coming in per day coming from mobile, whereas there are about 12,000-13,000 total uploads on Commons per day – that makes mobile only 1-2% of desktop uploads. I'm currently working on comparing the deletion rate of mobile and desktop; however, this is going to be difficult to do objectively if the Commons community decides to mass delete all of these files, not just copyvio :-/ Maryana (WMF) (talk) 17:56, 5 April 2013 (UTC)[reply]

Category:Uploaded with Mobile/Web does seem to have more than a few pictures of pets. The Spitz example is interesting - someone stuck a photo of their pet on the Wikipedia page instead of choosing one of the existing photos which would be a better illustration (one that shows the distinctive tail would be better). More generally, none of them were categorised, some lacked Info templates, most lacked descriptions... Whether the quality of mobile uploads is really lower than "normal" uploads I don't know, but it's undoubtedly a route for more, and I'm not crazy about widening the firehose of incoming content that needs review for quality, copyright violation, and scope. I'm not saying that mobile should never happen, I would just strongly prefer to develop the Upload Wizard to a higher standard and then using that as a model for a mobile version. Anyway, if there's actual development effort that'll really develop something useful, taking concerns here on board, which can then serve as a model for an improved Upload Wizard - fine, we can do it back to front. Rd232 (talk) 02:13, 5 April 2013 (UTC)[reply]

PS Mobile Web doesn't necessarily mean photo taken by the user, as may be tempting to assume. Example: copyvio from the web File:An amusement ride 2013-04-04 16-03.jpg. Rd232 (talk) 02:20, 5 April 2013 (UTC)[reply]

The problem isn't with the quality of the images, or with a 'few' copyright violations. The last day of deletions makes any attempt to put a positive spin on this seem rather glib. Being generous and saying that for every 2 of those, someone added a picture to an article which didn't have one, it still doesn't add up for me in terms of effort for gain. I can guess we've already deleted twice as much as is actually in the category. Users are not getting told anything about what is acceptable, by all appearances. Edit: in the scheme of things this is not a huge number, but if it were on the same scale as the whole project, it'd be time to unplug it and go home. –⁠moogsi (blah) 03:22, 5 April 2013 (UTC)[reply]

Looking at the rationale for mobile development

• here, To avoid forcing new/less experienced users to deal with this complexity on a mobile device, and to leverage the most popular existing type of upload [...Original images taken by the uploader...], we are currently focusing only on uploads to Commons under one license, CC-By-SA 3.0, on the mobile web.
• here, Galadriel is an experienced Commons user who already has uploaded many files to Commons using the UploadWizard. She is taking a nice evening stroll when she comes across a scene that would make a wonderful addition to Commons. She has a phone with a nice camera, so takes a picture with the inbuilt camera app. Instead of going home, remembering to transfer the image, and then uploading it, she wants to be able to upload it then and there - and then move on. She is a good Commons citizen, so wants to make sure that the title is descriptive and appropriate categories are added. This is Use Case 1 of... 1.

I feel there is a desperate naivete here. And did any prior consultation with experienced Commons users pass me by? Rd232 (talk) 13:20, 5 April 2013 (UTC)[reply]

As Maryana notes below, the mobile app and mobile web are completely different. The Apps have a completely different reach, different workflow, different codebase, and different deletion ratios. Mobile Web != Mobile App. While the app use case might be written to be a bit... flowery, it is reasonably accurate. The app encourages you to add an appropriate title and description, and (since the latest release) categorize the images you upload. I have been talking to people on IRC at the #wikimedia-commons channel for a while now, and been implementing feedback that I've gotten from there. Ragesoss has been particularly helpful both in terms of ideas and testing, and I've also poked other people to bounce ideas off. I had also started mailing out to commons-l every time I make a release (since the last release). I could post on VP but that could possibly be considered spammy. If there's any other location where I can hang out and talk to users I'll be happy to frequent those too. YuviPanda (WMF) (talk) 02:55, 6 April 2013 (UTC)[reply]

The {{Information}} tag seems to be missing in several files − 107 according to CatScan, the more recent being File:Image of Motoactv SmartWatch- 2013-04-04 15-33.jpg or File:Knut- 2013-04-04 21-26.jpg. Jean-Fred (talk) 20:14, 4 April 2013 (UTC)[reply]

I propose a rule of thumb for admins and others to quickly manage mass deletions in the light of a flood of unacceptable images that now creates a serious threat to the sustainability of Wikimedia Commons, and damages the continued good faith of our community of volunteers. This will remove any requirement for a volunteer to individually confirm problems with images and instead judge a source to be too unreliable for images to be accepted, until such a time as an appeal demonstrates that acceptable quality constraints have been placed at the source, rather than using limited resources of the unpaid volunteer Commons community.

Where a clearly identified source of images has a measurable rate of poor images (i.e. serious enough for deletion) of higher than 33%, then all images may be automatically deleted from this source, without individual image review, by an administrator for an indefinite period, unless otherwise categorized as in Project scope and compliant with Licensing requirements, or there is a successful appeal on AN for the specific source.

Thanks --Fæ (talk) 06:24, 5 April 2013 (UTC)[reply]

• As for now, the problem is less with single mass-uploaders of the MUApp-kind, but with the mass of MUApp-uploaders, who upload 1-4 files. However, that may change if the App becomes even more popular. --Túrelio (talk) 09:21, 5 April 2013 (UTC)[reply]

  Yes, this proposal is aimed at all uploads using the same problematic application, rather than individual persons or accounts. The policy has in mind not just current mobile apps, but the likely future of multiple types of mobile interfaces on multiple platforms, plus their forks, all of which may be counted as different identifiable "sources". --Fæ (talk) 09:33, 5 April 2013 (UTC)[reply]

• I do see that there is a serious problem with low quality images that seem to be coming from mobile app. However, I also see that there's a problem with delete-happiness of some admins and for some subjects. I would agree that copyvio mass uploaders can be stopped with such a "nuclear" regulations, but to apply the same logic for "out of scope" or "poor quality" images will do a lot more harm than good. Sinnamon Girl (talk) 07:02, 5 April 2013 (UTC)[reply]

  Sure, I'm concerned about "delete-happiness". However this proposal cannot be read as encouraging any sort of questionable deletion-happiness spree–it is limited to sources where there is a measurable failure rate of 33% or above and there should be an easy appeal process once quality problems are addressed. By anyone's viewpoint, such a high failure rate is seriously damaging, and poses a direct threat to the sustainability and credibility of this project. Thanks --Fæ (talk) 07:08, 5 April 2013 (UTC)[reply]

  I do understand and sympathise with you to an extent. However, there is a problem that after the image is deleted only admins can see it (even in cases where the image was not a copyright violation). What I see happening is something like this: A person uploads 3 images: a penis, a fictional flag, and a personal drawing of Muhammad; it would be very easy to see how at least two of these would be deleted, making the percentage 66%. After that every upload would be speedily nuked, even in cases where those uploads would be able to stand on their own merit, and each deletion would up the deleted percentage. An appeal would be an uphill battle, because most people would not see the deleted images, but only the deletion logs saying things like "don't need any more of these" or simply "cleaning up". In a perfect world what you are proposing would work, and work perfectly. One third of uploads falling out of scope is really a lot, but not when scope is getting redefined to "Having an associated article on English Wikipedia (except for any sexuality, fictional, or non-Islamic media for which 2 images is already 1 too many)"; and I have no hope to see many admins to actually state how they read the phrase "broad meaning" from COM:SCOPE#Aim_of_Wikimedia_Commons Sinnamon Girl (talk) 07:44, 5 April 2013 (UTC)[reply]

  Thanks for explaining further, I understand a bit better. Perhaps it should be clearer that by "source", this proposal is not intended to address individual accounts or IP addresses of contributors, problems such as this would be covered by current policies. This proposal is directed at "sources" such as mobile upload applications which may include many uploaders. As for seeing uploads, I agree there should be an open process. I suggest that (a) any problematic source should be discussed in a general Deletion request for at least 7 days, as good practice currently establishes for deletions, and (b) we should be talking of a sample of at least 100 images which are seen as problematic, this would ensure that the nature of licence problems or serious scope issues are well established by a meaningful statistical sample. Thanks --Fæ (talk) 07:51, 5 April 2013 (UTC)[reply]

  Thanks for trying to see my point and for taking a step towards consensus. Sample of around 100 files that already went through the normal DR process would be enough, in my opinion, to be able to see real patterns emerging. I am a little concerned with slippery slope, but if people will remain vigilant against vigilantes it may just work. So as I understand the process: Somebody creates an application for easily uploading files, this application becomes reasonably popular with the wrong crowd, we have 100 files uploaded with that application nominated for deletion via regular DR and then deleted, another DR gets started showing that we have disproportionate abuse of this particular application and that files uploaded via this tool are ... (I'm unsure about this point, do we delete all of them, even if they have already closed as keep elsewhere, do we only delete future uploads?). To establish the percentage that is "too high", is it possible to have a statistic about the proportions of all deleted images uploaded via Special:Upload and Upload Wizzard. Sinnamon Girl (talk) 08:57, 5 April 2013 (UTC)[reply]

  I would expect any shiny new mobile app to have a rush of usage on day 1, so in practice I would expect a problem to be quite quickly apparent, and for a keen Commonsist to create a bundle Deletion request for 100+ images. There could then be the usual minimum seven days of discussion about the example cases and whether this is statistically significant, whether the licensing problems are serious or fixable, for example just by changing the default licence to a correct one, and whether the mobile app (or other software) developer has fixed or has committed to a firm date for fixing the quality issue. Consequently I would not expect several or a hundred separate DRs to be a prerequisite to creating the bundle DR, however I would expect there to be plenty of time for discussion based on real current cases, and good faith attempts to negotiate with the developer, before a final decision would be made to delete all further uploads from that source. Thanks --Fæ (talk) 09:06, 5 April 2013 (UTC)[reply]

  I didn't mean that every file should have its own DR, but at least a reason should. For example in the list like this all the copyvios may be deleted speedily or may have a discussion if they are not apparent (from the titles of some of the files in this case I feel that they are clear cases). So in this particular case we already do have sufficient files to make a judgement, even though I would still say that "used for vandalism" and other such reasons should have had their DR, even as a unified discussion. Sinnamon Girl (talk) 09:17, 5 April 2013 (UTC)[reply]

Scope hardly comes into it: read the breakdown at the top of this (linking this again because.. well, it's insane). The deletion rationales are also less cryptic than you imagine they are –⁠moogsi (blah) 08:48, 5 April 2013 (UTC)[reply]

This actually highlights my point, all "V", "S", and even possibly "D" should have been normal deletion requests, not a single-handed action. Sinnamon Girl (talk) 09:02, 5 April 2013 (UTC)[reply]

So, File:Hermaphrodite 2013-04-04 14-28.jpg, defaming a fully identifiable girl, should have gone through a 1-2 week DR? Ever heard of Amanda Todd? --Túrelio (talk) 09:19, 5 April 2013 (UTC)[reply]

All of it was done within process. V and S are sometimes also © I guess. I'm not perfect. Even a speedy deletion is rarely a single-handed action. The ones which are.. we're talking noise, blank pictures, blatant adverts, attack images, etc. Probably nothing less than taking you through them one by one would be satisfactory –⁠moogsi (blah) 09:24, 5 April 2013 (UTC)[reply]

Just to clarify, this proposal, with the suggested bundle DR and 7 days plus of discussion, in no way circumvents current policies. If there are identified issues against Photographs of identifiable people or Licensing that have realistic potential to cause harm, financial loss, damage, privacy issues or distress to models or copyright holders, then the normal processes apply and prompt action would be supported. Thanks --Fæ (talk) 09:30, 5 April 2013 (UTC)[reply]

my last comment wasn't directed at your proposal, but to Sinnamon. --Túrelio (talk) 09:35, 5 April 2013 (UTC)[reply]

yep, but a good point about our collective duty of care - always worth re-iterating. Fæ (talk) 09:38, 5 April 2013 (UTC)[reply]

I have already stated that 100+ copyvio uploads out of from what I can see around 400 is enough to start a Deletion Discussion for all the uploads. So, Fæ, you don't need to convince me any further, I have agreed with you. To answer Túrelio, I can only say that I don't see the image and it is not this particular image that I was talking about, but the reason itself. In fact if an admin will delete Commons:Deletion requests/File:This hoe suffers from the dirty Hoe A-K-A- Thot disese 2013-04-04 22-58.jpg speedily, I think that few people will mind. Sinnamon Girl (talk) 09:48, 5 April 2013 (UTC)[reply]

Speedied, as they were already used for vandalism/defamation on :en[8]. Thanks for notifying. The Hermaphrodite-file was of the same kind, not the image itself was offensive (though likely a personaliry rights violation), but the intentionally defamatory description/filename. --Túrelio (talk) 09:59, 5 April 2013 (UTC)[reply]

By the way, we now have Category:MobileUpload-related deletion requests. --09:35, 5 April 2013 (UTC)

I don't know that the proposed "rule of thumb" is going to get anywhere - how would it be implemented? I think we either need to start a petition asking WMF to just turn it off (after collecting enough evidence to justify it), or create a new speedy deletion criterion. Since clashing with the WMF is generally unproductive, I'll suggest the following new speedy criterion:

• Files not in use for a legitimate educational purpose, uploaded from a mobile device within the last 7 days, may be deleted immediately if the file appears to meet any of the usual deletion criteria (eg probable copyright violation, lack of scope, inadequate sourcing, probable privacy violation, etc). Note the "may": deleting admins are expected to exercise discretion and send potentially valuable files to DR if appropriate..

Rd232 (talk) 11:26, 5 April 2013 (UTC)[reply]

• It's a bit vague and still leaves the overstretched volunteer admins that help with deletions taking an indefinite burden, rather than finding a way of automatically deleting files. In the above proposal the specific source would need to be discussed and assessed each time, and not just this one app from the WMF. We are not dealing with a future limited to the odd mobile app launched slowly by the WMF, but an open source environment where any kid in their bedroom might knock out a quick app as a fun Commons related project, and suddenly find it being adopted as an internet meme. We would want to encourage this sort of innovation, but we are likely to see narrowly targeted apps that may range from "publish your pet" (which we would probably want) through to "happy-slapping" (which we would have immediate problems with). Thanks --Fæ (talk) 11:37, 5 April 2013 (UTC)[reply]
  • Automatically deleting files? Well in theory you could have a deletion bot, but I don't know how you could make that secure enough and reliable enough to actually use. (Maybe that idea of a "staging server" is relevant again - where everything not in use gets deleted after a while unless someone other than the uploader chooses to copy it across to the main system...) And it's all very well disapproving apps, but what can you actually do to implement that disapproval? Rd232 (talk) 13:07, 5 April 2013 (UTC)[reply]
    1. Deletion bot - a bot just immediately marks anything matching the upload tool as the upload device for a speedy deletion with some standard blurb as the rationale and puts them in a category which can be cleaned out by an admin the same day.
    2. Staging server - yes, always a good idea, why hasn't it happened yet?
    3. implementing disapproval - just start running the incredibly simple bot, possibly using an on-wiki public disapproved list. I'll happily add it to Faebot unless someone wants to standardize it on an alternative. --Fæ (talk) 13:28, 5 April 2013 (UTC)[reply]
• Sounds vague. For example, if I upload an image by going to Special:Upload using the web browser on my phone, should any such file be subject to speedy deletion? I think that it is better to use the normal deletion criteria. Of course, obvious copyright violations such as photos of posters can get a standard {{Copyvio}}. --Stefan4 (talk) 14:25, 8 April 2013 (UTC)[reply]
  • The aim of the proposal was exactly that the normal deletion criteria could be applied to mobile uploads directly, without going through DR, if it's pretty obvious that the file meets one or more of the criteria. This would be a stop-gap until better solutions like the "staging server" or "sandbox upload" approach (see TheDJ's post some way down this thread) can be implemented. Rd232 (talk) 22:08, 8 April 2013 (UTC)[reply]

Thanks, everyone, for weighing in on all this. When we started building these features, we didn’t know what the problem areas were going to be in this completely new contribution workflow. Would new users not understand why they should donate images? Would new users donate inappropriate images? Would it be a combination of both?

I want to lay out some concrete steps for moving forward. The previous proposals are ones based on what is possible for Commons editors and admins to do after the fact, but I'd like to describe what we on the WMF mobile team can do to improve the output of mobile uploading.

Here's a list of the things we can work on to improve the quality of photos coming out of the mobile Web upload interface:

1. Make the upload process more focused on soliciting original, encyclopedic material. We know now that new users will donate images, but they won’t donate the kind of images that Commons needs unless we explicitly guide them to do so. We’re working on a Nearby view for readers, letting them see articles near them – giving users who are on a phone with a camera a list of things near them to take a picture of (similar to the WLM campaign) is one example of a targeted call to action that may produce better content, rather than a generic upload workflow that leaves room for test shots and selfies.
2. Reinforce much more strongly the concept of original work and make sure new users understand it. This will mean different wording in the tutorial, focusing specifically on educating users about original work and encyclopedic content.
3. Make changes to the first-time uploader user experience. An explicit opt-in via a popup message is one way to go about this. Some form of an interactive upload wizard is another. Any other suggestions?
4. Figure out if we can disable the upload feature on categories of articles that are inappropriate for mobile uploading. There are a lot of challenges here, since we’re supporting 280+ language projects and categories work very differently in all of them, but it’s something we’re going to look into nonetheless.
5. Continue to monitor the rate of copyvio, test images, inappropriate images, etc. If the rate of inappropriate uploads is very high, we can scale back the visibility of the features. There are ways to make the upload call to action less prominent and more likely for only experienced users to see/use. We don’t have to turn it off entirely.
6. Reevaluate and change focus. Perhaps mobile web uploading doesn’t make sense, and the sensible thing is to focus on mobile applications. We won’t know for sure until we put more work into the mobile web features, but we’re also working on Commons apps for experienced users, and they may be a better fit for generating high quality content.

Apropos to this, just a couple more thing I should stress:

Mobile web and mobile apps are not the same thing.

I want to make it clear that the issue here is with uploads coming from the mobile version of Wikimedia projects (en.m.wikipedia.org, it.m.wikivoyage.org, etc.), not uploads coming from apps. The mobile team is also working on native apps for Android and iOS, and if you look at the category of images coming from those apps, you’ll see that a) they’re mostly uploads from experienced Commons users, and b) they’re high quality encyclopedic content. In contrast, mobile web uploads are mostly coming from brand new people who have just signed up for accounts. I want to make sure everyone understands this distinction, because it explains the difference in quality.

Mobile devices are not going away.

More and more of the traffic on Wikimedia projects is coming from smartphones and tablets, and both new and experienced users are going to want to contribute to Commons on these devices. Third-party developers have already created upload features: there is a volunteer-created Commons upload app and a wiki editing app with uploading functionality for iPhones and iPads.

Unlike third-party developers, however, Wikimedia Foundation developers are not just interested in creating one-off proprietary apps that only reach a niche market of Apple users. We want to build sustainable upload workflows that anyone on any device can use. Initiatives like Wiki Loves Monuments have shown that we can engage smartphone users to contribute quality material via mobile. It’s something we have to do more work to figure out, or we risk losing a huge and dramatically growing population of users.

It’s a big, hairy problem, and we’re learning as we go. You can help us; the other nice thing about not relying on third-party developers to build these features is that we actually read the Commons Village Pump and hear and respond to your feedback :) Maryana (WMF) (talk) 20:53, 5 April 2013 (UTC)[reply]

Thanks for listening Maryana. Could you please listen carefully again to the section above and below what you have written, and immediately get the development team to disable the uploads from these damaging mobile sources until a system for testing is properly agreed, with the community, possibly including staging areas, rather than breaking Commons so badly that we are actively losing our most productive administrators out of frustration at the actions of the WMF? Commons is the only flagship truly international, multilingual and popular project the Wikimedia brand can claim. I love it, it is the grandest embodiment we have of global open knowledge. Let us not throw it away in a "mobile marketing" drive, just because the WMF happens to think this is important for its brand growth and funding strategy. Something will replace Commons, eventually, don't hasten that day by driving our community of leading volunteers into forking and doing our own free media open knowledge hippy thing by leaving the Wikimedia "brand" behind us and emptying this project of our future freely given content, experience, innovation and value. Thanks --Fæ (talk) 22:23, 5 April 2013 (UTC)[reply]

By the way, as an expression of solidarity with the section below by Ecemaml, I have now halted my uploads and my Geograph work as of this moment, until action is seen to be taken and a way forward properly agreed. My fellow volunteers may want to consider the power in their hands to control this project. I am sure you are aware that I have made over 2,000,000 edits to this project and uploaded over 70,000 photographs - I hope that means that my actions make a difference here. Thanks --Fæ (talk) 22:29, 5 April 2013 (UTC)[reply]

Fæ, as someone who is both a Commons contributor/admin and an engineering staff member, I too love Commons and think it should be treated as a flagship project. But your comments are hyperbolic (breaking Commons? Really?), and your incitement to more drama by trying to stir up some kind of unnecessary showdown ("My fellow volunteers may want to consider the power in their hands to control this project.") between WMF and Commons admins is not helping. Maryana is posting here precisely in an attempt to be constructive and treat Commons contributors as peers who should be heard. She's asking whether the ideas above may or may not help from the perspective of Commons contributors. It seems your answer is that nothing but turning off the feature will satisfy you, which is of course on topic, but basically throwing up your hands and quitting unless you get what you want is not moving the conversation forward. Steven Walling (WMF) • talk 23:09, 5 April 2013 (UTC)[reply]

Hi again Steven, I am pleased that you are trying to be constructive, and I am prepared to take your criticism of me in good faith, perhaps more good faith than the last time you criticised me whilst performing your duties as a representative of the WMF. Rd232 has a sensible approach to consensus building below, and this is the sort of community control I was referring to in my comment, and that you appear to be taking as a 'showdown'. Certainly, if little else works promptly in addressing the quality problem, then saving the time of our handful of overworked active administrators, should be a priority for our community, and it would not be unreasonable to arrange for all files from an unacceptably low quality source (such as a specific mobile-web source) to be routinely mass deleted, rather than administrators spending significant time being diverted to reviewing and making decisions about every individual image. Have a good weekend. Thanks --Fæ (talk) 03:19, 6 April 2013 (UTC)[reply]

Thank you for this comment. I don't see anyone actually opposed to the concept of uploading mobile devices - there are only concerns about the current implementation. Uploads from mobile devices are generally considered A Good Thing (someone please pipe up if I've got this wrong).

In my opinion the mockup at right is the most important thing we can tell mobile web users, or users of the Android/iOS app. Commons does of course host very many files which are not self-made, but their public domain status depends on a complex set of rules which are not easily communicated. The simplest way to ensure that users upload acceptable files is to try to restrict them to their own work. Currently the Mobile Web doesn't do this, but it will be implemented.

The cause of the alarm is the huge proportion of bad uploads, which are taxing the current deletion processes, and extrapolating that to what will happen when Mobile web/apps are popular. There will be other problems, but I don't think that constantly deleting copyvios is a permanent one –⁠moogsi (blah) 22:53, 5 April 2013 (UTC)[reply]

Good feedback all around. One related idea brought up in casual conversation to me today: we could potentially use EXIF data to try and make sure the photo was actually generated by the same device, and if not, throw a warning or error of some kind. This idea came from an engineer in another group, so it would be need to be checked for difficult/plausibility from a technical member of the mobile team. But it does sound like one step toward ensuring original work is being uploaded. Steven Walling (WMF) • talk 23:14, 5 April 2013 (UTC)[reply]

That seems like a really good, practical idea that would immediately cut out many of the problems -- all of the mobile/web problem uploads I saw the other day were of course random files from the web and therefore of course had no EXIF. We could either check for it and if there's no EXIF, either throw up a big splash screen (is this from the web? Stop!) or just not allow the upload and explain why - photos on commons have to be your own work (this should be limited to mobile uploads, as there are other legitimate files with no EXIF, but I doubt too many other public domain use cases of scanned documents or whatever will be coming via mobile). -- Phoebe (talk) 02:55, 6 April 2013 (UTC)[reply]

We can run a bot from this end too, for example adding a no-EXIF (or partial EXIF for files that, say, have EXIF data showing edits in Photoshop, but lack original camera details) hidden category to all mobile originating uploads. It's a simple API call plus a bit of parsing, and might be an easy way of gathering files for which mass deletion would be relatively uncontroversial and save some administrator effort. --Fæ (talk) 03:51, 6 April 2013 (UTC)[reply]

 Done Faebot is now populating Category:Mobile uploads lacking EXIF data with images lacking the Make of camera in the EXIF data, or with no EXIF data at all. There may be some devices which fail to write usable EXIF data, we may want to decide how to handle those. In the meantime, being a newly uploaded file and present in this category, is probably a good indicator that these are troubling files and a significant, probably the majority, of those included need deletion due to significant doubt as to source and copyright.

If folks can work out failure cases where a bot can identify with a 90%+ accuracy which of these images are going to be licensing problems and policy failures, for example by screening out those that used the WLM mobile app as these were probably reviewed at some point, then it would be great to refine this categorization with a 'definitely delete' sub-category.

Update added my own filter of only checking for files uploaded from March 2013, on the basis that as other files have been around for more than 30 days, they are less of an immediate issue. I am limiting the bot to checking Category:Uploaded with Mobile/Android, Category:Uploaded with Mobile/iOS, Category:Uploaded with Mobile/Web. This will run around every hour. Happy to adapt the routine and keep running as an interim measure. --Fæ (talk) 12:15, 6 April 2013 (UTC)[reply]

You're going to need to adjust the bot, while my photograph lacks "Camera Model" it does have "Facebook Camera for iPhone" in the "Software used" section. Bidgee (talk) 12:31, 6 April 2013 (UTC)[reply]

 Done Faebot now checks the EXIF for 'Software used' and skips it when a match for 'Facebook Camera' is found. Leave a note on my user talk page if it gets categorized again. --Fæ (talk) 12:39, 6 April 2013 (UTC)[reply]

Thanks Fae! I wonder if it makes sense to separate 'no EXIF' from 'incomplete EXIF' into different categories. A lot of photo apps have just limited EXIF data. On my phone, for instance, even the native photo app leaves out Make when I use panorama mode, like this photo. Unfortunately, other apps (notably, Instagram, for Android at least) don't use any EXIF at all. But I suspect overall that the 'some EXIF' photos are more likely to be self-taken than the 'no EXIF' ones.--ragesoss (talk) 13:27, 6 April 2013 (UTC)[reply]

Sounds sensible.  Done. Category:Mobile uploads lacking EXIF data will show files with none or trivial EXIF data, and Category:Mobile uploads lacking EXIF data for camera has non-trivial EXIF data but lacks a camera Make, or the EXIF Software field does not have the word "Camera" in it. --Fæ (talk) 16:14, 6 April 2013 (UTC)[reply]

Minor addendum I have made Faebot a bit more intelligent, and he now considers the number of visible categories on an image. If rather than deleting an image, a user adds 3 or more categories to it, Faebot will take it out of the 'no EXIF' category. As someone must have thought about it, and found it a useful photo, by definition it must be a lower risk than the majority of uncategorized newly uploaded mobile created photos. Thanks --Fæ (talk) 22:56, 6 April 2013 (UTC)[reply]

sounds good as an aid to helping with this, though I do think (once we get the exact parameters right) that it would be better to alert uploaders on the upload end, rather than letting them upload with no problems and then deleting their stuff, which is confusing. -- Phoebe (talk) 16:29, 6 April 2013 (UTC)[reply]

That's the intention, this is just an interim to help make life a bit less frustrating for our administrators. Hopefully Faebot can get back to other stuff soon. Thanks --Fæ (talk) 16:34, 6 April 2013 (UTC)[reply]

This is great! A sincere thank you, Fae :)

Since the bad upload volume remains unacceptable, we're going to temporarily disable the login/signup call to action for this feature, only making it show up for users who are already logged in with a Wikimedia account. This should significantly reduce the number of mobile uploads, bringing it back down to pre-April 4 levels (e.g., only a few dozen files a day) and hopefully improving the quality, since only existing users will be able to make use of it. This will happen during our regular deployment window, Tuesday afternoon PST. Until then, I'll ask some of the Commons admins in the office to help with triaging and deleting copyvio. Thanks again for your work on the bot – we'll investigate ways to do EXIF verification pre-upload, as Phoebe and Steven suggested. Maryana (WMF) (talk) 18:02, 6 April 2013 (UTC)[reply]

Apologies to all the Commons admins who have been effected by this feature and special thanks to Fae for the bot. I hope that you trust us that we all want the best for Commons! Obviously we haven't quite got the software right first time but I hope you can see the great opportunity that we have here. We should focus on the positives - a lot of the users who uploaded copyrighted material probably had good intentions but we obviously failed them on educating them to not do this there are also useful photos such as https://commons.wikimedia.org/wiki/File:Agwa_bomb_at_a_bar_in_Itaewon,_Seoul_2013-04-08_01-26.jpg. Also the fact lots of people bothered to create accounts to do this is a positive We also now know the sort of things that mobile phone users will do when presented with the chance to upload a photo using their phone and we can iterate on this. As Maryana points out we are working in a territory we have never explored before so there are bound to be disruption. We have a deployment Tuesday where we can reduce the upload volume to a more acceptable rate but I really hope you can help us make this feature better rather than killing an idea before it has been fully born Jdlrobson (talk) 19:16, 7 April 2013 (UTC)[reply]

The volume of uploads should now decrease dramatically. As of today we only show the lead photo upload button to logged in users. Jdlrobson (talk) 02:41, 10 April 2013 (UTC)[reply]

For long I've been pleased to donate my time to the project. I believe in the free content. However, I don't believe in the way the WMF (comprising a growing number of paid staff) is managed nor in the way it cooperates with the projects (where a lot of volunteers do the hard work without getting anything but personal satisfaction).

In last hours, I've been dealing with the uploads that our fantastic management has dumped on us. I've opened 26 deletion requests for pictures obviously out of scope. I've delete about 40 pictures as they were copyright violations. I haven't reviewed the whole category (a more or less constant amount of pictures regardless of the number of deleted pictures) but I can assess that no more than 20% of the pictures in the category are useful (considering the number of deleted pictures, the amount is no greater than 10%). I've decided that I won't contribute any more to the effort of sorting out that mess. I've always thought that the community is able to self-organize. But now it seems that there is an alien element that cannot be organized. It does not belong to the community but can supersede any agreement that the community can arrange. I won't play that way. Many thanks --Ecemaml ^{talk to me/habla conmigo} 21:44, 5 April 2013 (UTC)[reply]

Thanks for giving your hands-on experience. I would suggest that rather than a counsel of despair, we try two things:

1. get individual admins to look at the mobile input stream, so they get a feel for what the content is like
2. have a petition that admins can sign, declaring that they won't process mobile uploads made after a certain date, by which they expect mobile uploads to be turned off. This partial strike would be rescinded once, in conjunction with Commons editors, the mobile tools are developed to a point where Commons editors are happy to put them live to the world again.

I'm off to bed now and probably won't be available at the weekend, but that's my 2 cents for now. Rd232 (talk) 22:57, 5 April 2013 (UTC)[reply]

Maryana says: “about 200-300 uploads coming in per day coming from mobile”. Yes, and a only a small part of it is useful (according to COM:SCOPE) + correctly licensed + has a good quality. I assume we can delete > 200 images more a day. They are blatant copyright violations which get a bot created information template (“own work”). Remember: “If the uploader is the author, this should be stated explicitly. (e.g. "Created by uploader", "Self-made", "Own work", etc.) (…) A generic license template which implies that the uploader is the copyright holder (e.g. PD-self) is no substitution for this requirement.“

I deleted about 100 files over the last days, maybe 80 percent were copyvios from the Category:Uploaded_with_Mobile/Web. There is a problem and we don't need more experience with these uploads but an upload stop and fixes to the software and the user interface. Copyright violations have been a problem for years and all the (limited) solutions we got were user created. --Polarlys (talk) 10:41, 6 April 2013 (UTC)[reply]

PS: The “work” of 15 minutes. So far I deleted/tagged 207 247 images from the category as copyvios/out of project scope/without source/without permission. --Polarlys (talk) 11:04, 6 April 2013 (UTC)[reply]

You not mentioned the ~40 screenshots and other copyvios that I deleted on 4 April 2013 when I first saw this category. Informing users that they are only allowed to upload free content or content they created themself and that they want to publish under a free license is the minimum. DO not upload screenshots or photos of someone elses copyrighted work needs to be added, otherwise for me the screenshots posted by Maryana (WMF) 18:19, 4 April 2013 (UTC) look ok... BUT even with that instructions we still have a larger percentage of copyvios in the uploads? This means we have to disable mobile services, learning the basics of free content or doing acts of legal significance regarding your own copyright (publishing under cc-by-sa etc) is nothing you should do on the fly from mobile.... if you not know what you do or never heard of it before. --Martin H. (talk) 15:24, 6 April 2013 (UTC)[reply]

Since the volume of inappropriate uploads is taxing the Commons community, the mobile team will hide the upload feature for new users – we are currently showing the upload button to logged out users and then asking them to log in or sign up for a Wikimedia account in order to upload, and this appears to be driving the vast majority of the upload traffic. Not showing the upload feature at all to logged out users should lower the number of new mobile uploads to pre-April 4 levels (e.g., a few dozen a day) and increase quality, since only existing logged in users will see the feature. We'll do this during our next deployment window, April 9th. Until then, I'll ask the Commons admins among the WMF staff help out with triaging and deleting inappropriate uploads.

Thanks to everyone who flagged the issue and offered ideas for improving the educational UI – we'll explore many of them to ensure there are proper checks in place before increasing the visibility of any mobile web upload feature. Maryana (WMF) (talk) 18:42, 6 April 2013 (UTC)[reply]

It is 3 p.m. in central Europe right now and since midnight we had over 120 new entries for deletion on the logging page (which doesn’t count them all). Something isn’t working. Please stop the tool entirely for now, because we have a huge problem that is stealing our time. --Polarlys (talk) 12:55, 7 April 2013 (UTC)[reply]

Maryana said they are disabling it during their next deployment window, on April 9.--ragesoss (talk) 13:19, 7 April 2013 (UTC)[reply]

Ok. --Polarlys (talk) 13:40, 7 April 2013 (UTC)[reply]

I just like to add, that the general quality of new users contribs is not better then those of the mobile uploads. Im checking the user creation log. I now did so for 3 consecutive weeks. From the 10% of users that contributed (90% is SUL visitors) 60% upload copyvios, 30% upload trash and 10% make good contributions, e.g. adding one category or translating one description. I say "one" because the rarely do more edits. From the thousand of new users I checked there where a hand full of users making good uploads - but only for one day, they never came back. I cant remind any valuable contributions e.g. of outstanding quality or of rarely illustrated subject. So asking the general public to upload something here is not an important lever for improving the project, its the opposite regretably. --Martin H. (talk) 15:10, 7 April 2013 (UTC)[reply]

Some open questions that I'd like to have answered

• Is the WMF thinking of talking to the involved parties before and not after a new feature impacting so deeply into an established community is implemented? It's really shocking to see that no proper dialogue with the ones that really know commons was conducted before this new feature was implemented.

Mobile uploading had previously been announced on the Commons Village Pump back in late February. There were also two blog posts about our continuing work on the feature, one in January of last year, and one in March.

• Has the WMF provided the means for knowing what's going on? I mean, most of the new uploads are either copyvios, useless personal images or out of scope pictures. Do they know how many images have been uploaded and how many have been already deleted?

If you're interested in following the stats, they're here. We'll be adding the deletion stats to those dashboards soon, as well. Before last week, the feature wasn't fully released on the mobile web; we were working on it in the beta version of the site. There were only a handful of users uploading, and it was hard to say what the quality output of the "real" feature would be, given that beta users are a somewhat different crowd (and a much smaller audience) from regular mobile users. Since last week's deployment, there were a total of 1,663 files uploaded, bringing the total mobile web upload number to about 2,200 (obviously, the majority came in after April 4, when we promoted the feature from beta to stable). As of yesterday, 557 of these were kept, meaning 73% were deleted. However, that number is somewhat misleading, since the {{Information}} tag not coming through meant that a chunk of uploads were deleted for missing author/source, not necessarily confirmed copyvio/other issues. I'm also not aware of what the current baseline actually is for new users uploading to Commons on desktop (it takes a bit of work to dig this out of the database); I imagine their rate of deletion is probably quite high, too. I'm working on figuring that out.

• Has the WMF thought of running trials with reduced set of users in order to get some conclusions before the new features go life?

As I mentioned above, we did in fact release this feature to the beta version of the mobile web, which is a population of somewhere around 100,000-150,000 users, less than half a percent of our total mobile web traffic. It was enabled since November while we worked on upload functionality and UI and, to my knowledge, was not noticed/discussed by the Commons community.

• Has the WML conducted any "market research" in order to anticipate which the behaviour of users using the new features would be?

Yes, it's here. I believe you or someone else referenced the (somewhat outdated) apps user research? Just a friendly reminder, again, that apps != mobile web. A total of 979 files have been uploaded with the official WMF Commons app for Android, which is currently being used almost exclusively by existing Commons users, and only 15% of those files (mostly test images, I imagine) were deleted :)

• Are they planning to do any of the above before activating new features with a so big impact?

All of the above, it appears, was already done :) But all that aside, I do very much agree with what I think is your main point here – that there is quite a bit of room for improvement in terms of how Foundation staff reaches out to and communicates with local wiki contributors (and vice versa). Our current strategy of sporadically dumping things out on blogs and Village Pumps is less than stellar; we do not connect with the vast majority of users, those who just came here to edit/upload/patrol, etc., who aren't active enough to catch every thread on every wiki, or who don't care to follow most big meta discussions. On Commons, we also (quite unfortunately) miss everyone who isn't fluent in English. I'm not sure what the best way is to proceed. There are other, more far-reaching tools like watchlist notices or newsletters delivered via bot that we could make use of, though I worry about banner blindness and spamming our users. I'm sincerely open to suggestions.

Best regards --Ecemaml ^{talk to me/habla conmigo} 22:01, 6 April 2013 (UTC)[reply]

• Answers to your questions, inline, above ^ Maryana (WMF) (talk) 01:01, 10 April 2013 (UTC)[reply]

The problem that needs to be solved is the following:

1. Allow quick and easy uploading (from mobile)
2. Educate users
3. Cleanup contributions of users

The problem is that part 1 is targeted at noobs but is causing too much of problem 3 for community. And problem 2 for noobs causes this to be a problem that cannot be corrected by the community in the longer run.

So what about this: Make it super easy to upload, tag the upload with 'sandbox' state. Use accounts + registered email to follow up after 'simple' contributions. "We would like to ask you to follow up your contribution with a few more details. bla bla". Then have a dedicated 'edit page' that helps provide the user more and better information on his own time schedule and when he is near a real computer, which is more suited for these kinds of contributions. Of course a few more things are needed to assist in making this workable

• Have the option to disable the notification
• Have the option to send notifications of deletion discussions per email (Using echo ?) (per push would be even more brilliant of course)
• Possibly even making email registration required for mobile contributors ?
• Dedicated tools for the community to 'clean' the sandbox for the community.
  • Automatic expiry for the files that no one marked as interesting (these non 'interesting' files would be saved for just one week or so) (deletion with user email-notification)
  • Files that were marked as 'interesting' by community members would be saved for a longer period and the community can hunt down information that it needs. Some hover control in Special:NewFiles gallery to mark files as interesting seems like a nice way to create this functionality)
  • Simple 'Restore to sandbox/edit/publish' option for uploaders that had their files automatically deleted from the the sandbox
• A mobile version of this tooling, that would allow the same for mobile users, though likely a bit less flexible than the full web page.

We cannot solve problem 1, while turning a blind eye to addressing problem 2 and problem 3. They are much more connected than people often assume. So dear WMF, combine mobile and editor engagement teams on this front to create a common strategy, before starting to built 'insular' tooling to fix small technical parts of the problem. Without improving the community experience, your newly developed tooling, although working and possibly brilliantly engineered, will likely be useless for the next couple of months (and possibly outdated by the time the community tooling problem is fixed).

And the community needs to learn that we cannot go forward if we stand still. Different types of contributors will come in. Deal with it and give people the time to adapt and change and test future strategies. It takes about 4 attempts for every working solution with a community as complex as ours I suspect. We therefore need to be open to try more in order to advance. It's the only way to find better future solutions. Is it annoying sometimes ? sure, we would all love to be able to succeed the first time round. However it's not the end of the world as long as everybody keeps listening to eachother and understands that changing things the right way takes time, a lot of time, if you cannot just throw 50 engineers at these three problems. We should strive to reach each others goals as much as striving to reach our own. TheDJ (talk) 11:46, 8 April 2013 (UTC)[reply]

That "sandbox" idea sounds like a more developed version of the "staging server" approach that's been mentioned before. I'd like to see that moved forward, I think it makes a lot of sense. So does trying to improve communication with new users. Rd232 (talk) 15:15, 8 April 2013 (UTC)[reply]

Yes, agreed that having staging be part of the process is a potential obvious path to addressing the signal/noise issue. IMO the main question is whether that's overall worth it, or whether other strategies to invite contribution have a much better signal/noise ratio. Keep in mind the mobile team is also building dedicated upload apps for Android/iOS, with built-in campaign features that will make it possible for the community to organize mini-contests and such. The mobile web team is also experimenting with an "Articles near me that need photos" feature. And there are many other potential ways to bring in new contributors. In a nutshell, at this point we're experimenting, and we need to continue to be open to change course completely as we learn things before we decide to sink too much effort into any one path.--Eloquence (talk) 23:21, 8 April 2013 (UTC)[reply]

Yes, more targeted approaches like that are likely to have better signal/noise ratios. I would recommend the staging approach for all uploads though (at least for new users); mobile seems like a good place to test the approach, but I think it makes sense more generally. Rd232 (talk) 14:55, 9 April 2013 (UTC)[reply]

 Comment This discussion is getting quite big and unwieldy for the Village Pump, and after some to-ing-and-fro-ing, it seems like the move to have some limitations from 9 April will keep a lid on things during further development. So I'd suggest we move discussion elsewhere, since this will be ongoing. What would be the best place? Somewhere on Mediawiki.org? Commons talk:Mobile access? A Commons WikiProject specifically for the development of these mobile tools? Something else? Rd232 (talk) 15:15, 8 April 2013 (UTC)[reply]

I think that's a great place to continue this conversation.--Eloquence (talk) 23:21, 8 April 2013 (UTC)[reply]

You mean Commons talk:Mobile access? (I made several suggestions, so "that" is ambiguous.) BTW Before I forget I want to mention Commons:Photographs of identifiable people/checklist as something I worked on for helping with COM:PEOPLE aspects of uploads. Rd232 (talk) 14:55, 9 April 2013 (UTC)[reply]

I emailed the Publications Manager of the Australian War Memorial regarding using one of their images. They replied that Wikipedia was free to use any of their copyrighted images for free as long as the original caption and AWM catalogue number was used in the summary description. This is their copyright page. What copyright license should be used for this? WLRoss (talk) 08:02, 4 April 2013 (UTC)[reply]

Did they say that only Wikipedia is free to use them? For Commons this is not enough. Ruslik (talk) 08:05, 4 April 2013 (UTC)[reply]

Although I enquired about a specific image for a specific article, he simply said that all their images can be freely used in Wikipedia articles. I have changed my email address since I got the reply so no longer have it but I can always email again for specifics. WLRoss (talk) 08:14, 4 April 2013 (UTC)[reply]

I've just noticed that the copyright page has been greatly expanded since I last saw it. We may be covered by "fair use." Someone with copyright experience needs to read the page to see what we can do. WLRoss (talk) 08:28, 4 April 2013 (UTC)[reply]

Fair use is not allowed on Commons. Under "Australian War Memorial Copyright", they state that "[u]nless otherwise noted, the versions of the images made available on this website which are Australian War Memorial copyright are provided under a Creative Commons Attribution-NonCommercial 3.0 Australia (CC BY-NC 3.0) license", which is not a free license. You could ask them for permission by email. — Ralgis ^[mantis_religiosa]  —@ 13:20, 4 April 2013 (UTC)[reply]

See: File:Aile mobile Luc Viatour.jpg. The phtographer is claiming copyright and demanding (not asking) for mentioning of his name. In his template he even warns against "illegal use" of this reproduction. Shouldn't this be simply marked up as {{PD-Art|1=PD-old-auto|deathyear=1519|country=Italy}} and then mention/credit Lviatour as the photographer (without assigning any new copyright to him)? Whaledad (talk) 13:46, 4 April 2013 (UTC)[reply]

• The opinion of the foundation lawyers is that a faithful 2D reproduction of a 2D public domain work is itself 2D. However, if ever they will change their mind (due to some case, for example), then we will need to track down and see if a new copyright is in order. Putting image under a free licence in such a case is a good thing to do. Also there's a slight 3D element here, as I can see it the paper isn't exactly 2D in this case, and since the community is crazy enough to even allow cave paintings to be condisdered 3D, I think that once again nobody knows how this one would play out. I find nothing bad about this case. It's clear that on the description page there's a note about Da Vinci's work being in public domain. Sinnamon Girl (talk) 14:15, 4 April 2013 (UTC)[reply]

I applied {{Art Photo}} template, which should clarify the situation. Other option is to use {{Licensed-PD-Art}} so reusers from countries like US can assume PD, and reusers from countries with different laws can choose photographer's license. --Jarekt (talk) 15:02, 4 April 2013 (UTC)[reply]

Of course "a faithful 2D reproduction of a 2D public domain work is itself 2D," but I presume you meant to say, "a faithful 2D reproduction of a 2D public domain work is itself public domain." - Jmabel ! talk 16:08, 4 April 2013 (UTC)[reply]

Yes, I meant that it it also PD. Sorry. Sinnamon Girl (talk) 23:00, 4 April 2013 (UTC)[reply]

It's a slavish reproduction of a 2D piece of artwork. The author is not Luc Viatour, the author is da Vinci. Luc Viatour has a copyright on this image like I have a copyright on the Mona Lisa. His copyright tags should be removed and the work properly attributed, though he can be noted as the photographer of this public domain piece of art. He may be the photographer, but he has no "copyright" claims whatsoever on this image. The file should also be renamed to something more appropriate. – JBarta (talk) 21:20, 4 April 2013 (UTC)[reply]

In the US it's that simple. Elsewhere it's not - see Commons:Reuse_of_PD-Art_photographs#Belgium. Rd232 (talk) 21:40, 4 April 2013 (UTC)[reply]

Understood. Does any such exception apply in this case? – JBarta (talk) 21:58, 4 April 2013 (UTC)[reply]

Nevermind. I was thinking the painting was in Italy (therefore the photo was taken in Italy), but if the guy is in Belgium and he first "published" it on his Belgian web site, then the rule you mention applies. Thanks for slapping me in the head with yet more copyright nuances. – JBarta (talk) 22:04, 4 April 2013 (UTC)[reply]

There's not been much input into Commons:Requests for comment/Files For Upload (proposing a facility to allow users to request someone do an upload on their behalf). I've suggested integrating such a request facility into Commons:Upload help. Some additional comments at the RFC would be nice. Rd232 (talk) 22:17, 4 April 2013 (UTC)[reply]

After extensive testing last year, Faebot (talk · contribs) has been quietly busy going through UK Geograph photographs in the following locations. We believe the location within the County boundary is highly accurate, better than any automated use of geo-coordinates in the past, being based on the latest Ordnance Survey Open Data. Something in the order of ½ a million photographs have been categorized, and I welcome feedback on any errors or other problems before sending Faebot off to finish the rest of the UK over the next few months (around another 1.5 million). Example regions done include:

• Wales (yes, every Geograph image in Wales has been done)
• South West and South East England along with most of the photographs in London (London needs a re-run to complete, but is down to the Borough level)
• Dumfries and Galloway, the Shetland Islands and the Orkney Islands (the rest of Scotland to follow soon!)

These categories are particularly useful for spotting photographs with the wrong location categories, or to assist in correctly identifying locations with similar (or identical) names. They are also a lot of fun to browse if you know the area well. Credit is due to Nilfanion for support and advice during testing. Feel free to raise any issues you spot on my talk page. Thanks --Fæ (talk) 23:25, 4 April 2013 (UTC)[reply]

I'm quite happy to hear that someone finally picked this up. Could you please publish your source code under a free license so others can improve on this? Multichill (talk) 17:50, 8 April 2013 (UTC)[reply]

I'll think about it. I'm holding out for a teensy bit of gratitude from certain people 'in authority' after certain unfortunate events. Give it at least another month. Thanks --Fæ (talk) 17:57, 8 April 2013 (UTC)[reply]

The issue of uploaded JPGs containing embedded password protected archives has come up. I proposed adding this as a criteria for speedy deletion. Comments on that talk page welcome. – JBarta (talk) 09:47, 5 April 2013 (UTC)[reply]

I've noticed that some people are deleting {{PD-Art}} files which don't have a source (example, for admins: File:'The Lonely Monk', oil on canvas painting by Enoch Wood Perry, Jr.jpg). Question: normally sourcing is critical for determining copyright status; but logically, as long as it is a PD-Art case, the sourcing of the photo doesn't matter for the copyright status. So shouldn't we just keep these files? Either way, it would be helpful to clarify this and add a note to Commons:When to use the PD-Art tag, because it does come up occasionally. Rd232 (talk) 09:55, 5 April 2013 (UTC)[reply]

I think people get way too much happiness by deleting stuff in general for the thinnest of reasons. Sorry, maybe not the most constructive comment, but I think an accurate observation nonetheless. – JBarta (talk) 10:03, 5 April 2013 (UTC)[reply]

I always leave them alone. I don't think the source is essential if the license is PD-Art –⁠moogsi (blah) 10:09, 5 April 2013 (UTC)[reply]

 Keep and offer to undelete all that have been deleted by over-eager admins. --Fæ (talk) 10:29, 5 April 2013 (UTC)[reply]

Provided the image and artist are as the description says. Dankarl (talk) 14:19, 5 April 2013 (UTC)[reply]

Source does often help with that. For example if I say that source is "http://img.wikinut.com/img/-z7k04at_dgc9609/jpeg/700x1000/the-lonely-monk.jpeg" I am not sure if you can verify artist from it. --Jarekt (talk) 14:32, 5 April 2013 (UTC)[reply]

 Keep Many types of license does not require source to verify license status: {{PD-old-100}}, {{PD-text}}, {{PD-shape}}, {{PD-medical}}, {{PD-US-patent-no notice}}, {{PD-1923}}, etc. I restored that one file, but that is very troubling, since a lot of work goes into curating proper metadata for the artworks, so mistaken deletions of files waists everybody's time. Even after images are undeleted, they are not automatically re-inserted to articles. We do have over 41k files in Category:Images without source but that is not a reason to delete them. For PD old artworks we usually add {{Unknown|source}} to such files. Is there a way to search for deleted "no source" PD-old files? --Jarekt (talk) 14:32, 5 April 2013 (UTC)[reply]

• The point of the source in cases of PD-Art is to provide evidence of the author/date which corroborates that license. This is per COM:EVID. Adding a no source tag (without first making a rudimentary search) is lazy, and linking directly to an image file is inappropriate (again, per COM:EVID). This is how you do it. We simply need a third-party connection of the image to the author. Эlcobbola _talk 14:53, 5 April 2013 (UTC)[reply]
  • The point of the source in cases of PD-Art is to provide evidence of the author/date - but it's not necessary (and the source doesn't always say, either). For PD-Art cases it is often possible to find the same content from other sources, so you can confirm the author/date, without being able to say what the source of the digital file is. Rd232 (talk) 15:29, 5 April 2013 (UTC)[reply]
    • "In all cases the uploader must provide appropriate evidence to demonstrate either that the file is in the public domain." I didn't say the file had to be sourced; what needs to be sourced is the evidence (authorship/date) information. Эlcobbola _talk 15:39, 5 April 2013 (UTC)[reply]
      • But it almost never is. If the user just says "own work", and "this is an image of the following painting by artist So-and-So", we don't demand sourcing for that. Rd232 (talk) 16:09, 5 April 2013 (UTC)[reply]
        • Well, COM:L, COM:EI, COM:EVID, etc. do actually demand it, we just aren't particularly good at enforcing that demand. Эlcobbola _talk 16:17, 5 April 2013 (UTC)[reply]
          • Yes, but enforcing that demand is a separate issue. I'm happy to discuss that too, but as I've tried to clarify in a new subsection, it's an issue that's beyond the scope of what I intended this thread to be. Feel free to start a new thread - I can already think of some ideas on the topic :) Rd232 (talk) 17:01, 5 April 2013 (UTC)[reply]

•  Comment What should be required is a cleyar statement about why the image qualifies as {{PD-Art}}. It could be so simple as the name of the file (for instance File:Las Meninas - Velázquez.jpg, even if with no further information, could any reviewer to determine that Velázquez was a famous painter and he died more than 80 ago, and that Las Meninas is one of his works. However, if the name is sort of File:Rubbish name.jpg without further information, then it could be argued that it could be deleted on the grounds of lack of source information. --Ecemaml ^{talk to me/habla conmigo} 15:03, 5 April 2013 (UTC)[reply]
  • You're basically right but slightly confusing sourcing and description. A source is primarily a source for the digital file, and only secondarily a source for the content. You can very easily end up with having a file where it's clear what the content is, but not where the digital file came from. Rd232 (talk) 15:29, 5 April 2013 (UTC)[reply]
    • @Ecemaml: it isn't really that simple. For example, I've not heard of Velázquez, so that name has no particular meaning to me. Similarly, Caspar David Friedrich is very well known to me and most Germans, but I doubt the average American, for example, would be familiar with him. Эlcobbola _talk 15:43, 5 April 2013 (UTC)[reply]
      • Normally the description should contain enough information to identify the subject. The issue is the level of proof needed that the identification is correct. Rd232 (talk) 16:09, 5 April 2013 (UTC)[reply]

Why exactly would an uploader not provide source information? Surely they know which website they copied the file com, or from which book they scanned it? Not providing source information is sloppy work that should not be encouraged. --Rosenzweig τ 16:39, 5 April 2013 (UTC)[reply]

That's true. But the question is whether if an uploader has been sloppy, and it's not a recent upload where we can try asking them to fix it, a missing source is grounds for deletion, in PD-Art cases. Rd232 (talk) 16:56, 5 April 2013 (UTC)[reply]

We have a lot of sloppy uploads sometimes with minimal matadata. But sometimes there are legitimate reasons: Like downloads from databases that do not offer stable links Category:Images from the United States Holocaust Memorial Museum come to mind, images from ebay are another example. Also images might be no longer available as websites blink in and out of existence. I had cases where source website was on some black-list for spamming and it was not possible to save file with it's URL. In all of those cases it would still be good to provide the source URL, but it would take a lot of effort.--Jarekt (talk) 17:45, 5 April 2013 (UTC)[reply]

To recap: there are always two sourcing issues with a PD-Art file (sometimes more, but never mind that...):

1. Source of the content - eg the painting. Who made it, when, and where? This is normally provided as part of the description. Evidence for it is usually lacking if the file hasn't been copied from the web, where the source website will often provide documentation and usually (not always, eg if it's Flickr) constitute a good source.
2. Source of the digital file. Who made it, when, and where? Often there's an "own work" claim, which has its own issues. Often it's taken from the web, so there's a URL to check. Sometimes a printed source is given, as the user has scanned it. Sometimes no source for the digital file is given at all.

The issue that prompted me to start this thread was that sometimes we have files with no source for the digital file (failing 2.), but a clear description of the content, often verifiable by looking online (meeting 1.). Sometimes 2. is also fixable by searching online - aha! that's where it came from!. Other times, it's not.

There are of course a range of issues around the level of evidence needed for both 1. and 2.; but my question here is really limited to what to do in this specific case, where we accept 1. is OK but 2. is not. Normally for this we'd have to delete, but because 2. doesn't matter for PD-Art copyright status (in the US...) it seems logical to keep these cases, tagged as unknown-source (maybe with a custom tag to help clarify that some effort has been made to find the source). Rd232 (talk) 16:56, 5 April 2013 (UTC)[reply]

Ideally all PD-old files by notable artists will also have one (or more) of creator templates which would make verification of license requirements easy. In such a case source of the binary file is not necessary. Same with lets say books, if you can prove that is was printed in US prior to 1923 than you can use {{PD-1923}} without providing exact URL link for the website you downloaded it from (however it would be great if you do). --Jarekt (talk) 17:32, 5 April 2013 (UTC)[reply]

Conclusion: Well, this thread seems to give a clear answer to my question: yes, PD-Art files should be kept as long as the PD-ness of the art can be verified to a reasonable standard, even if the origin of the digital file is unclear. Rd232 (talk) 21:52, 8 April 2013 (UTC)[reply]

Added to Commons:Verifying permissions (a draft proposal that will hopefully go somewhere at some point). Rd232 (talk) 01:17, 10 April 2013 (UTC)[reply]

The discussion, about an issue which is sadly not new, is going on here: Talk:BSicon/Categorization#Axpde's single-tree idea. -- Tuválkin ✉ 19:50, 5 April 2013 (UTC)[reply]

Please be aware that I have executed a takedown under the DMCA. The takedown is recorded at Commons:Office_actions/DMCA_notices#El_caballero_de_la_armadura_oxidada. Thank you. Philippe Beaudette, Wikimedia Foundation (talk) 07:29, 6 April 2013 (UTC)[reply]

Thank you for the notification here. It seems about es:El caballero de la armadura oxidada by Robert Fisher. Given it was a PDF (File:El caballero de la armadura oxidada.pdf), I think the uploader, (who was active at Commons only and did only upload this pdf,) uploaded the whole novel. -- Rillke^(q?) 09:01, 6 April 2013 (UTC)[reply]

There is a discussion about a bot running over all SVGs at Wikimedia Commons. SVGs are not attempted to be rendered during the bot-run. Only errors that can be detected by accessing DOM nodes and attributes can be detected and fixed. -- Rillke^(q?) 11:34, 6 April 2013 (UTC)[reply]

I posted a request for non interaction, which was deleted. In the history it point to the administrator´s noticeboard, but it is not there. Or shoud I start a new diiscussion there? --Tomascastelazo (talk) 21:18, 6 April 2013 (UTC)[reply]

Really, isn't that evident from the name Commons:Administrators' noticeboard/User problems (COM:ANU)? --Túrelio (talk) 21:21, 6 April 2013 (UTC)[reply]

The post was deleted and NOT moved. Check it yourself. At a minimun then, a note should have alerted of the deletion and a request to post in COM:AN --Tomascastelazo (talk) 21:44, 6 April 2013 (UTC)[reply]

well the second part is, the first part is contrary. But it doesn't belong here according to our policy. Penyulap ☏ 21:34, 6 April 2013 (UTC)[reply]

Two posts were deleted, with the intention being (I assume) that you would repost them at COM:AN/U (it's better to avoid reposting on others' behalf, it easily causes confusion). You can still do that reposting now. Rd232 (talk) 21:52, 6 April 2013 (UTC)[reply]

Need some help with fixing the broken Template:Distinguish. It is not working when there are only 2 parameters used. It seems like it's missing some code, see Category:Simeon for an example at the top. Thanks, Funandtrvl (talk) 21:53, 6 April 2013 (UTC)[reply]

It seems to work if you replace "2" with "4". More generally, it seems to work if the 2nd category is numbered "4", the 3rd category "3" and the 4th category "2". It's not obvious. It could indeed use some modification to make it be more intuitive. -- Asclepias (talk) 22:26, 6 April 2013 (UTC)[reply]

Yes, and I don't know enough code to fix it, somewhat like the coding at w:Template:Distinguish, but with using categories, instead of article names. Funandtrvl (talk) 22:50, 6 April 2013 (UTC)[reply]

I think that this edit should fix it. --Redrose64 (talk; at English Wikipedia) 18:45, 8 April 2013 (UTC)[reply]

Wonderful, thanks much!! --Funandtrvl (talk) 18:50, 8 April 2013 (UTC)[reply]

How do I make the lines in the description field look like that in the image? The most important tasks are that I need a fat line for "Östergötlands län" and "Samtliga medtagna län (översta kurvan)" and a thin - but short - line for "Jönköpings län". --Årvasbåo (talk) 17:06, 7 April 2013 (UTC)[reply]

You can copy from that description. Ruslik (talk) 07:43, 8 April 2013 (UTC)[reply]

A recent minor incident prompted me to review guidance on user pages. This incident is easily explained if I link to User:Bebop7 (this version, if it changes) without warning visitors that it's "Not Safe For Work", which I don't think is a warning that should ever apply to a user page. But I wouldn't do that, so you have been warned.

Anyway, this prompted me to draft Commons:User pages as a proposed guideline, which offers some generally useful advice I think, as well as a part (Commons:User_pages#Galleries) which specifically arises from that incident. Before taking it any further, I'd like to see some initial comments or improvements. Thanks. Rd232 (talk) 14:00, 8 April 2013 (UTC)[reply]

Well, we still have no COM:Locker room policy as that fell flat where I raised it here a year ago, or any common understanding of what NSFW means in the Commons context. I would prefer any guideline to take account of the potential for administrator action in response to complaints being raised and that there is a documented consensus for the particular issue. For example if someone wants to pick their favourite top ten topless under-18 girls to make a gallery on their user page, then I suggest that (a) if nobody cares enough to raise a formal complaint, then it should be ignored, (b) a consensus is required if no prior consensus exists for the particular topic (in this case 'user galleries of nude under-18s' or similar) for an administrator to take action and delete the page, or to block the user if they persist in recreating the galleries. In the case of (b), anyone would be free to attempt to create a new consensus, though one might expect that reasonable time limits would apply. --Fæ (talk) 14:18, 8 April 2013 (UTC)[reply]

I considered putting in a section about enforcement, but I thought it might be simpler to just leave it. But if we were to have such a section, I'd put something like "Content should be moved on request by the user, if anyone asks them to. If the user declines, content may be moved to a subpage by any administrator, and may not be moved back unless there is a consensus following discussion at COM:AN that the content is in fact acceptable for a userpage; non-admins may request any admin to act, or post at COM:AN.". That, plus maybe some examples as we get them from practice, would cover it without making a whole Thing about definitional issues of this and that. Rd232 (talk) 15:01, 8 April 2013 (UTC)[reply]

 Comment I've just noticed a partial overlap with some of COM:PSP policy - Commons:Project scope/Pages, galleries and categories#User_pages.2C_galleries_and_categories. It's a rather odd little spin-off of COM:SCOPE, I think (what's the P even stand for?). If we make Commons:User pages a guideline and finally approve COM:CSD, then it'll be pretty well redundant. Rd232 (talk) 15:06, 8 April 2013 (UTC)[reply]

Serious question - Does this not apply Commons:NOTCENSORED Kiltpin (talk) 15:19, 8 April 2013 (UTC)[reply]

Serious answer - no, COM:NOTCENSORED is about hosting educationally useful files despite those files being offensive to some. It is an obvious and transparent abuse of the meaning of the policy to try to use it to claim that we must tolerate graphic sexual images anywhere and everywhere on Commons, including user pages, and I can only hope no-one is so foolish as to try to make that claim. Rd232 (talk) 15:22, 8 April 2013 (UTC)[reply]

I asked the question, because I did not know the answer. Now I do. Thank you for your swift reply. Kiltpin (talk) 15:45, 8 April 2013 (UTC)[reply]

Thanks for asking - it was bound to come up, I suppose. Rd232 (talk) 16:08, 8 April 2013 (UTC)[reply]

I agree. The level of jackassedness around here in general is astounding. Sometimes I'm almost embarassed to be a part of this community. – JBarta (talk) 15:47, 8 April 2013 (UTC)[reply]

The suggestion to limit the size of people's galleries would never gain support but would be directly on track for a head-on collision with the best contributors the project has. Penyulap ☏ 15:52, 8 April 2013 (UTC)[reply]

I think the best contributors are likely to be among those more amenable to argument. In this case, as the WMF move to developing mobile access should remind us, not everyone always accesses Commons via broadband. Large galleries can impede user pages from loading, and since user pages are something that you should be able to take a quick look at (to find out key details that are hopefully there like language skills and user rights), that is a problem. Fortunately, it's an easily solvable problem, with userspace galleries on a user subpage, linked (can be very prominent!) from the user page. Rd232 (talk) 15:56, 8 April 2013 (UTC)[reply]

This part of the proposal has my wholehearted approval (it is a real pain to have your browser freeze because of some ridiculously large user page), but I am afraid I have to agreee with Penyulap on that one − this is going to be a mess to enforce. Jean-Fred (talk) 17:08, 8 April 2013 (UTC)[reply]

A concrete example has been brought to my attention: User:Heralder is over 20mb on disk when saved in Firefox as a webpage. Which may actually be a fairly simple way of enforcing this: set a guideline of X megabytes for "large", it's not hard to measure that way (I've not found any good online way to measure it). Rd232 (talk) 17:10, 8 April 2013 (UTC)[reply]

I don't think enforcement need be a huge mess. We can simply politely notify those with humongous user pages of the discussion, then if the policy is agreed, give them another polite notice of 30 days to meet the policy/guidelines, after which any admin is free to move their huge browser-breaking user page to a sensible sub-page and leave a link with a suitable note. This may have to happen for users that are inactive and may be uninterested in making any changes, rather than due to any philosophical objection. --Fæ (talk) 17:27, 8 April 2013 (UTC)[reply]

Well, it's a failure of an idea which can only get as far as it is rolled out at a creeping slow pace, you'll only be able to start idiotic arguments with good contributors at a rate that doesn't exceed the number of people who like to argue in favour of the proposed 'policy'. If you bite off more than you can chew at one time, they'll just crap all over your policy. Pretty simple equation. If these users didn't want to display their work on their userpages it wouldn't be there in the first place. If you don't want to view someone's userpage, then hey, don't view it. If there is a problem loading a user's talkpage because that user does mostly high bandwidth work, then they can have an alternate account just for that stuff and a regular account for ordinary chat. I recall researching that at a time I did a lot of 4 meg gif's for people, but it didn't appeal to me. Gif's load automatically unlike videos, so they choke bandwidth, My en.wiki talkpage archive is a great example of a large talkpage. the 2012 archive in particular is a browser killer. As a conlimited point to argue with a small number of people it's a goer, as a widely acceptable policy it's a flop. Penyulap ☏ 18:35, 8 April 2013 (UTC)[reply]

If these users didn't want to display their work on their userpages it wouldn't be there in the first place. - most people do it because they've seen others do it, and would go along with a guideline saying otherwise if they understand the rationale and are pointed to a good alternative (user subpage). Muddying the waters with other issues like auto-loading GIFs and user talk pages isn't helpful: this discussion is about user pages. (I created User:MiszaBot/usertalksetup for user talk pages, and I think that works pretty well.) Rd232 (talk) 18:53, 8 April 2013 (UTC)[reply]

Advice like "If you don't want to view someone's userpage, then hey, don't view it" seems to be a popular refrain in these types of discussions. The trouble is that a person has to visit the userpage in order to know that they don't want to see it. And knowing that any userpage on Commons might contain whatever it is that the person does no wish to view is likely to discourage them from looking at any userpages. That probably won't make them feel welcome or want to contribute their time here. Delicious carbuncle (talk) 19:01, 8 April 2013 (UTC)[reply]

"If you don't want to view someone's userpage, then hey, don't view it" - no, absolutely not. That's perfectly reasonable for something which is optional to look at, like a userspace gallery, especially with appropriate warnings; but user pages are an intrinsic part of Commons' communication infrastructure, it is normal to view them in many contexts when users want to find out more about a user, and they are linked from every signature. No, no, thrice no. Rd232 (talk) 19:23, 8 April 2013 (UTC)[reply]

I don't really see the need for galleries of user uploads, but I generally have no objection to them. The userpage that prompted this discussion was a gallery of genitalia. Some of the images had been originally uploaded by the user and others were images that the user had edited. The questions here isn't "Is it ok for users to have galleries on their userpage?", it is "Is it ok to put a gallery of dicks on your userpage?". Talk of "warnings" is really beside the point, since they will only be seen if an unsuspecting user loads the page. Anything other than a guideliney which means that any user can blank such a gallery and point to the guideline is a waste of words here. Delicious carbuncle (talk) 19:09, 8 April 2013 (UTC)[reply]

No, it's not necessary that any user can blank anything they deem too graphic, and even suggesting that makes it less likely that a guideline will be approved. So thanks for that counter-productive comment, DC. In the first place, a guideline is needed to establish the community disapproves of certain things; enforcement is a secondary issue, and only if pointing to the guideline proves not to be enough do we absolutely need to pin down a specific enforcement process. (We could choose to build one into the guideline pre-emptively, but I'm inclined not to.) Rd232 (talk) 19:18, 8 April 2013 (UTC)[reply]

Commons has a nice clear guideline about why we don't accept any more images of white dicks (COM:PENIS), but it is ignored almost all of the time. Sorry if I seem to keep going on about penises again, but lends itself to being used as an example here. If you want to write guidelines that people will ignore, I think you're on the right track. If you want to deal with the issue, you're wasting your time. Again. Delicious carbuncle (talk) 20:06, 8 April 2013 (UTC)[reply]

Those are totally different enforcement challenges. Most userpage galleries are from long-term Commons contributors, who to some degree are aware of and care about sticking to policy, and interact with others who do too (who will raise issues one way or another). By contrast, most files covered by COM:PENIS are uploaded by new users who are unaware of policy. Rd232 (talk) 21:49, 8 April 2013 (UTC)[reply]

It isn't the ignorant uploaders who I am blaming for ignoring COM:PENIS, it's the very experienced, long-term contributors and admins who vote to keep those images (and those who close DRs as keep in spite of COM:PENIS). How would your proposed guideline address the situation at hand? If it doesn't result in the removal of that gallery of genitalia, it is pointless. Is it ok to have a gallery of dicks on your userpage? If it can't be used to determine an answer to that question, it is not going to be useful in dealing with the type of people who are likely to put up a gallery of dicks on their userpage. If "it's only a guideline" is a valid reason for not removing such a gallery, you've wasted your time. Delicious carbuncle (talk) 22:27, 8 April 2013 (UTC)[reply]

Have you read the wording of the draft? It would be more useful to comment on that than to vaguely worry that it might not succeed. Rd232 (talk) 22:39, 8 April 2013 (UTC)[reply]

Yes, I have. A user could make use of any of these three loopholes to justify keeping a gallery such as the one that I removed: "It's only a guideline, not a policy"; "These are educational"; "I put a warning on the page". A reasonable person might remove a gallery when the guideline is pointed out, but I don't think that's what we're dealing with here. Delicious carbuncle (talk) 23:17, 8 April 2013 (UTC)[reply]

The first one is weak tea; anyone using that is liable to lose the argument once more people get involved. (It's also the sort of silly wikilawyering which is thankfully less common on Commons than English Wikipedia.) The other two are non-arguments; you have to badly misread the draft text to think the text permits them as loopholes. (User pages are quite obviously not a "specific educational context (such as a Wikipedia article)", and once that is conceded, those two loopholes disappear.) Rd232 (talk) 23:24, 8 April 2013 (UTC)[reply]

Wait and see, I guess. Delicious carbuncle (talk) 03:00, 9 April 2013 (UTC)[reply]

 Oppose Any "safe for work" requirement. Per Penyulap. People are too busy trying to protect those who can't see a picture of a vagina, but yet what about somebody (like myself) who is honestly offended by the proposals such as this one. You people claim that you want everybody to "feel welcome" but what you actually do is the creation of the culture of harassment, where it'll be easier to troll somebody by forcing that person to place some warnings on one's user page or to remove one's own uploads from there. Please stop being so one-sided. Sinnamon Girl (talk) 22:33, 9 April 2013 (UTC)[reply]

There is no voting here; this is initial discussion. People are too busy trying to protect those who can't see a picture of a vagina - I fully expect that most of those supporting the proposal are perfectly happy to look at pictures of nudity in an appropriate context (be it educational, like a Wikipedia article, or decidedly non-educational... which is none of our business here). Showing some consideration of others is something some people are oddly allergic to; it's not an attitude I understand. Also, making this purely about graphic sexual images misses that not all images that merit warnings when not shown in an educational context are graphic sexual ones. Images of graphic violence may also merit warnings when shown outside an educational context where users will expect it. Rd232 (talk) 22:51, 9 April 2013 (UTC)[reply]

I  Support voting it's fun, especially since this is as close to any kind of policy that this obvious tool of harassment will ever get. Which I  Oppose btw. So let's  Keep the harmless and fun voting ! It's the best part of this discussion. Penyulap ☏ 23:14, 9 April 2013 (UTC)[reply]

I know this is slightly off of the original topic of this thread but so is much of the above. I have what some would probably consider a relatively large user page. It shows a gallery of what I consider some of my best work, almost certainly under 1% of what I have uploaded to Commons, but I've uploaded a lot. While perhaps I flatter myself, I would think I a considered a good contributor to the Commons. If I were told that I could not display these samples of my work, I would object strenuously. Having an image-heavy page does not significantly slow down the time for the HTML to load in a browser, and I would think that in any decent browser you can view a page while images continue load in the background, and can kill the load if you don't want them to continue downloading. What modern browser won't do this? And if one does, why use it? - Jmabel ! talk 01:17, 9 April 2013 (UTC)[reply]

It is precisely on the topic of this thread Jmabel. And I agree with you 150%. User:Bebop7 is the reason that Rd232 is on this crusade -- the guy creates a few sexuality related images which are in use on various projects; he displays them on his userpage, Delicious carbuncle comes along and removes the images, Bebop7 reverts, Rd232 then comes along and moves the entire userpage to a subpage and is now trying to push through a poorly thought out guideline that will obviously affect editors such as yourself who contribute content to the project. It's sad. russavia (talk) 01:42, 9 April 2013 (UTC)[reply]

Russavia, how do you suggest we accommodate users ike Jmabel while still dealing with users who want a userpage full of genitalia images? Delicious carbuncle (talk) 03:00, 9 April 2013 (UTC)[reply]

I have a solution... an age requirement. Editors must be at least 9 years old. And while we're at it, admins must be at least 12. Probably solve a good number of problems all the way around. – JBarta (talk) 03:22, 9 April 2013 (UTC)[reply]

I've personally, even on broadband, found that large userpages give a momentary loading "blip" during which I can't scroll the page. (To pre-empt the nearly inevitable: that's a minor irritation that in no way factors in the proposal.) But it makes it easy to believe that on slower connections, or older machines, the delay before the page is usable is more substantial. And some contributors have reported exactly that, up to and including browser-crashing. Your comparison with a category page is interesting, and could be a reasonable benchmark. Some testing suggests categories with 200+ files are about 2.3mb on disk (eg Category:PD-Art (PD-old default)); your userpage is 5.85mb. But particularly when we're thinking about mobile (which is the future, right?), then we may have people uploading images, but not doing much browsing; but then needing to do some interaction around the upload, which might involve looking at userpages (especially of deleting admins...).

In short, moving these sorts of galleries off userpages doesn't seem a lot to ask. We do have Category:User galleries and {{User gallery}}, which could be expanded and developed to make it easier to navigate such galleries. Userpages are not the perfect solution for presenting user galleries, even from the point of view of the galleries! Let's try and be a bit more flexible and open to change here, folks. Reducing galleries on userpages to at most the equivalent of 200 category thumbnails is not a lot to ask, when it comes down to it. Rd232 (talk) 20:00, 9 April 2013 (UTC)[reply]

That has nothing to do with internet speed, that's your computer allocating memory for the browser to build the page. The blip will be the same length for a given machine regardless of the speed of the net. Penyulap ☏ 20:14, 9 April 2013 (UTC)[reply]

Possibly (but FYI my machine has 6GB ram). I'm not sure what difference it makes for the proposal... but in the back of my mind is not just people on slow connections or mobile, but also (and Wikimedia is keen to encourage such users) people from the developing world who may have older machines. Rd232 (talk) 20:34, 9 April 2013 (UTC)[reply]

Doesn't matter how many bottles of coke the store has, you still have to spend the time to go there and get one regardless of how many there are. Same with ram, it still has to be allocated. If it runs short, then it takes even (painfully) longer as it uses the swap space to empty ram first.

If you're using windoze and Internet Explorer all is not lost, you can speed up the process using a bucket of water {Penyulap smiles and starts nodding} Penyulap ☏ 21:04, 9 April 2013 (UTC)[reply]

• There's not much point in turning user pages into a child-safe zone while the rest of the site is uncensored. I don't think many people come here with the intention of only browsing user pages.

There may be some possibility of using meta tags to help users of filtering software, as described at [11] and [12]. As described at those pages, inaccurately using the tag can cause problems. If this is done, I think it would make sense to do it on the whole site, not only user pages. If it's done for user pages, I would hope that, if it's done, it would be in a way that isn't burdensome for contributors who want to have a user page.

A disclaimer like "this site contains user-contributed media that some people may find offensive" could be added to Commons:General_disclaimer. The closest I see there is "nothing found here has necessarily been reviewed by professionals with the expertise necessary to provide you with complete, accurate or reliable information."

Making a multimedia site like this accessible to modem users isn't impossible, but I think a better place to start, rather than user pages, would be the regular category and gallery pages. The example that was given was a user page that had thumbnails of 9 images, whereas category pages show 200 thumbnails at a time by default. I think it's fair to expect low-bandwidth users to selectively load images. NCSA Mosaic (first browser to show images alongside text) had this feature and so do modern browsers. Another commonplace browser feature, as Jmabel said, is the ability to interrupt loading of a page by using the stop button or the use of the escape key.

About Bebop7's user page, it seems like valid content for a user page: it just lists some nine of the user's contributed or edited images, with thumbnails and captions, essentially saying "this is the stuff I've made" or "this is stuff I keep track of." I would expect that filtering software would recognize from the captions on the images that they are about human anatomy and procreation. If a contributor improves Commons' collection of images of genitalia and wants to be recognized for that, I don't see a problem in it. Most of the contributors to Commons don't get paid; recognition is an incentive to continue working. Rybec (talk) 08:44, 9 April 2013 (UTC)[reply]

Jmabel, Rybec, and I would think Russ already knows, don't worry about it, it will not have success. This idea is exactly like a cartoon vampire, one of those ones that turns to ash the instant sunlight falls upon it. It could be raised up from the dead somewhere secluded, some quiet talkpage and a few people working evil magic can animate it and use it to annoy a few unsuspecting victims, but as soon as it is exposed to the communities' attention, Fffthhh and it's history.

There is another aspect to this idea that I won't talk about in public, but am happy to discuss with most people via email. At the end of the day, the only thing it needs is a wooden stake with RfC written on it driven through it's cold, dead heart. Penyulap ☏ 10:24, 9 April 2013 (UTC)[reply]

a child-safe zone - sorry, but who mentioned children? The wording is images of a graphic violent or sexual nature, or other images which users are likely to not wish to encounter outside of a specific educational context (such as a Wikipedia article) without any warning. Those kinds of media, if they are educational, we should certainly host, but not present to people without context or warning. Unless you're the sort of person who goes around with the goatse image on your T-shirt, you can probably concede that such images exist. All we're asking is that such images not be displayed on userpages. Is that so much to ask? Rd232 (talk) 20:07, 9 April 2013 (UTC)[reply]

Hi, allow me to rephrase: the value and practicality of ensuring that user pages are safe for a general audience, including children and adults with delicate sensibilities, while the rest of the site remains uncensored, is not apparent to me.

I used the term "child-safe" partly for the sake of brevity and partly because the example chosen shows clinical-looking images of human anatomy, of the sort that older children might see in sex education or biology instruction (at least, in the parts of the world where such things are taught). In most Western cultures, I think there would be a concern about small children seeing such photos and diagrams; not so much adults. This kind of imagery abounds on the site, and there are images that even the typical Florida adult may find disturbing, often with little to no context or warning (see the earlier discussion about File:Scrotum.JPG). If the goatse.cx image were released under a free license, I believe it could be hosted here under current policies.

If anything, of the various pages on the site, user pages are among the least likely to be viewed by casual visitors to the site, and more likely to be viewed by regular contributors who should be aware of COM:NOTCENSORED. Contributors and administrators who have delicate sensibilities, or whose career would be ruined by accidentally opening "a gallery of dicks" would be well-advised to browse with automatic image loading off, use filtering software, talk it over with the boss, avoid browsing from work, avoid viewing random user pages or recently uploaded files or uncategorized media, etc. Or the whole site can be censored so they can participate fully without doing these things...suppose while looking through the recent uploads I noticed a blurry photo of a penis. Before reading this thread, I might have requested its deletion with a remark like "out of scope and poor quality" without explicitly warning people that it may be NSFW. I think it is proper for administrators to view images before deleting it: awkward conversation with manager or IT staff ensues?

As an example of the lack of context, file names on this site often don't clearly identify the subject. Some of the following are NSFW or may be disturbing to adults: can you tell which ones without viewing them?

File:Kirloskar Group.jpg

File:Ai Group.jpg

File:Local Group.JPG

File:Group.jpg

File:Girl's best friend.jpg

File:Girl 28.jpg

File:Biker girl.jpg

File:Street Girl's End.jpg

File:Sukumizu Girl.jpg

File:Lead_Photo_For_DonateImage0-5751051791012287.jpg

File:Lead Photo For DonateImage0-9753871150314808.jpg

File:Lead Photo For DonateImage0-33781672385521233.jpg

File:Lead Photo For DonateImage0-7562751534860581.jpg

File:Lead Photo For Special-DonateImage0-5715908450074494.jpg

File:Lead Photo For DonateImage0-7204441225621849.jpg

File:Lead Photo For DonateImage0-029924112604930997.jpg

File:Lead Photo For DonateImage0-9899163385853171.jpg

File:Lead Photo For DonateImage0-6938995397649705.JPG

File:Lead Photo For DonateImage0-4173831020016223.jpg

File:Deveria11.jpg

File:Achille Devéria Les petits jeux innocens.jpg

File:Balls.jpg

File:Márcia Imperator.jpg

File:Marcia Imperator back.jpg

File:Marcia Imperator 2.jpg

File:Marcia Imperator.jpg

File:Аккумуляторы_eneloop_второго_поколения_в_упаковке_2013-03-30_11-23.jpg

File:Saline-03.jpg

File:Saline 3.JPG

File:Saline Ball.jpg

File:Akibachan5a.jpg

File:Akiba Tolim.jpg

File:Yodobashi-Akiba.jpg

File:Akiba jinja 16.jpg

File:Johnny sack.jpg Rybec (talk) 00:49, 10 April 2013 (UTC)[reply]

First, you mention In most Western cultures which is interesting, since we are of course trying to encourage contributions from other cultures. Wikimedia outreach might have something to say on the matter. Second, userpages have a particular purpose - namely to identify users and provide information about them that supports communication with them. No amount of whataboutery can justify subverting that purpose, which is ultimately what you're arguing for. And yes, casual visitors may not look at userpages, but new users may well do, particularly if they upload a file and run into problems. If a user tags a file for a problem, or deletes it, a fair proportion of users trying to investigate will end up on a userpage. Many users won't get that far; confronting them with entirely unexpected graphic images is unlikely to contribute to the retention ratio, is it? Finally, I don't know what your point is about the filenames, unless it's a "I'm not doing the washing up, people are starving in Africa" sort of non-argument. Rd232 (talk) 01:00, 10 April 2013 (UTC)[reply]

Does commons allow images of complete nudity? Because there are some. And it's not appropriate, and not helpful for encouraging people to release their own work on here.--عبد المؤمن (talk) 17:22, 8 April 2013 (UTC)[reply]

The answer is 'yes', but bearing in mind that 'COM:Project scope: the aim of Wikimedia Commons is to provide media realistically useful for an educational purpose', how is a picture of a nude pornstar useful for an educational purpose?--عبد المؤمن (talk) 17:24, 8 April 2013 (UTC)[reply]

I am glad you answered your first question with a good answer.

Many images featuring "complete nudity" of the human body are educational based on their medical, sex educational, cultural or historical value. I agree that there are some organizations and people that have concerns about putting their own work on this website where nudity and sex education media exist, but the majority of users believe that censoring all nudity, or just complete nudity, would reduce the overall value of this project. Media without educational value do get routinely and regularly deleted. You are free to raise any image you believe has no educational value, up for deletion review against the scope policy. Thanks --Fæ (talk) 17:37, 8 April 2013 (UTC)[reply]

To echo what Fæ says above, there are many, many images of "complete" nudity here. Commons is a project where images of ejaculating penises are of equal value to images of historical treasures. Although there are probably more images of penises. Delicious carbuncle (talk) 17:50, 8 April 2013 (UTC)[reply]

The site was invented by Jimbo wales, who as far as I know is a US citizen, it appealed mostly to US citizens and US cultural colonies around the world. It won't ever be able to penetrate as well into other cultures across the world because of it's limitations created by it's structure and scope.

Other websites and projects will flourish as a result of the efforts to 'keep the status Quo'. There are countless editors who try it and find it doesn't suit them. They find that 'what's written on the box' isn't what they find when they get down to trying to contribute. There are already hundreds of other wiki's created by editors who weren't encompassed and included in the wiki community and scope.

Other more successful models will emerge with better structures and some of them will take more seriously the idea of putting knowledge into the hands of everyone across the planet, including the many countries and cultures that don't consider full nudity to be essential to a child's education. I don't bother to assist the id.wiki project much if at all, for exactly that reason, it's a failure from the start and can't penetrate the society with such an absurd model (from the indo culture point of view, or indian point of view and so on). I see very few Indian editors, Japanese editors, basically anyone with a 'polite' background is positively repelled from this place. Penyulap ☏ 18:09, 8 April 2013 (UTC)[reply]

I think it's important to use qualifiers here: Some of the nudity on Commons was uploaded with a legitimate educational purpose and use in mind. Some of the nudity was uploaded without a specific use in mind, but is of high technical quality and does have educational value. The vast majority of the nudity on this project was uploaded with no specific use in mind and is not of high technical quality. These files are uploaded by 1) exhibitionists, and 2) people who upload every piece of nudity that they can find as a social/political statement. How many of this last group are doing this as a political statement specifically against the way that nudity is handled by Commons editors is impossible to know, but undoubtedly that exists. Commons would be much better off if we could encourage the first two groups (specific purpose and no specific purpose but high technical quality), and get rid of the people that fall into the last group (uploading for the sake of uploading). Now, lest you think that I'm a prude, I take much the same attitude towards all types of uploads here. If you replace "nudity" with "cat photos" my statement holds up equally well.— Preceding unsigned comment added by Sven Manguard (talk • contribs)

Penyulap, if this were run by people with a polite background, you would be bounced from it in a second. The fact that you would say such things and upload the first coprophilia file to Commons is quite a bit hypocritical.

I don't know how you can have an image repository for all the Wikipedias that supports the part of the world that accepts that humans should taught what their own species looks like and doesn't make such files available.--Prosfilaes (talk) 06:08, 9 April 2013 (UTC)[reply]

I can't possibly agree, the most competent and hard-working contributors here all seem quite tolerant to my idiotic antics and art, who was it said 'there are no good and evil people, just charming and tedious'.

crap-to-fill-it-up-what ? is this about the hysteria caused by the exposure of Jimbo's bellybutton ? we have pics of jimbo wearing lipstick that don't cause as much concern. I think it's because there too many rocky-horror-picture-show fans. They don't like babies or toddlers or men and women living together and doing what is natural, they prefer that toy made in the lab of the rocky horror show that had no belly-button at all. Ban the belly button ! Now there is a cause I can get behind, it'd work, and the no nudity fans would be like 'meh' or slightly positive about it too. Penyulap ☏ 10:41, 9 April 2013 (UTC)[reply]

I see my nude wife almost every day, such things does not disturb me. I saw naked people even more often when I was a child, that did not disturbe me even then. Belive it or not, sometimes I even have sex with my wife, such things does not disturb me either, I enjoy it. But pictures like those in sv:Nanjingmassakern disturb me, they give me nigthmares! I have blocked them, but there are others... -- Lavallen 07:45, 9 April 2013 (UTC)[reply]

Oh that is shocking ! I wear a scuba-diving wetsuit in the shower and haven't seen my naked body, or anyone else's since I was 5. Plus, I never accept links or candy from strangers. There is some site called rotten.com which had a pic of someone whose face was torn up in a motorcycle accident, looked like mincemeat, they survived apparently. Best to learn not to follow links. There are things you can't un-see. Penyulap ☏ 10:41, 9 April 2013 (UTC)[reply]

 Comment - I don't see this thread going anywhere. Can I suggest that the question of what to include and what not to include in Commons, and how to police it, is exactly the topic of the current Commons:Requests for comment/scope? Rd232 (talk) 14:23, 9 April 2013 (UTC)[reply]

Today, on the Wikimedia Foundation blog: “Breaking through walls of text: How we will create a richer Wikimedia experience”.

An interesting read about some future Multimedia projects the Wikimedia Foundation will undertake − and it is always nice to know our awesome project will get more love :)

Jean-Fred (talk) 20:09, 8 April 2013 (UTC)[reply]

I have a (minor) problem with gecoding. See for example this image where a warning Error: Invalid parameters! appears. I can not find the source of this error. Also clicking on the Google Maps link takes me to the right location (while no mark for the image appears there as it usually should). Is it something with the 'heading' parameter? It works just like that on other images, like this one. Any hint would be appreciated. --Tsui (talk) 20:36, 8 April 2013 (UTC)[reply]

 Done Parameter 9 has its elements separated by underscores rather than pipe symbols. Hardly the easiest looking format to use. --Fæ (talk) 20:47, 8 April 2013 (UTC)[reply]

Thank you! --Tsui (talk) 20:48, 8 April 2013 (UTC)[reply]