Commons:Village pump/Proposals

From Wikimedia Commons, the free media repository
Jump to: navigation, search

Shortcut: COM:VP/P · COM:VPP

Community portal
introduction		 Help desk Village pump
copyright • proposals		 Administrators' noticeboard
vandalism • user problems • blocks and protections
Welcome to the Village pump proposals section

This page is used for proposals relating to the operations, technical issues, and policies of Wikimedia Commons; it is distinguished from the main Village pump, which handles community-wide discussion of all kinds. The page may also be used to advertise significant discussions taking place elsewhere, such as on the talk page of a Commons policy. Recent sections with no replies for 30 days and sections tagged with {{section resolved|1=~~~~}} may be archived; for old discussions, see the archives.

Commons discussion pages (index)
Please note
  • One of Wikimedia Commons' basic principles is: "Only free content is allowed." Please do not ask why unfree material is not allowed on Wikimedia Commons or suggest that allowing it would be a good thing.
  • Have you read the FAQ?

 

Start a new discussion

Rfc: Should we request a configuration change to shut down cross-wiki uploads?[edit]

RFC An editor has requested comment from other editors for this discussion.
If you have an opinion regarding this issue, feel free to comment below.
Tracked in Phabricator
Task T120867

OK, seems like somebody has to do this … Cross-wiki uploads (description), the possibility to uploads files to Commons directly while writing an article on one of our sister projects, has now been enabled for a while. While certainly a good idea in terms of user experience, it turned out to be a magnet for copyright violations and otherwise useless files. It's basically the mobile uploads disaster all over again. People have been trying to find solutions, but so far nothing has worked. Gunnex has done some pretty elaborate analysis for cross-wiki uploads from different language versions of Wikipedia and found that the percentage of "bad" uploads usually ranged between 50 and 100%.

Commons volunteers are already struggling to thoroughly review all the files coming in through the "normal" channels. We still haven't finished cleaning up the mess mobile uploads caused. Let's face it: We're seriously under-staffed in this department and we can't handle more of that. Hence, it has been proposed several times to declare the experiment failed and pull the plug on cross-wiki uploads, just like it was done for the mobile/web upload interface. This would require us to request a configuration change, and per meta:Requesting wiki configuration changes we need community consensus for that.

So here I'm asking you: Do you want to continue the experiment or do you want the cross-wiki uploads feature to be turned off? --El Grafo (talk) 11:37, 4 August 2016 (UTC)

Note: This is only the first step, intended to get feedback from the Commons community alone. Depending on the outcome, a consultation of the global Wikimedia community on meta may follow. --El Grafo (talk) 12:23, 4 August 2016 (UTC)

I support switching off cross-wiki uploads[edit]

  1. The cross-wiki upload feature was a failure, although it was successful in making uploads easier cross-wiki, it has problems, which are mainly copyright violations. It failed to educate new users about copyright. Although I appreciate the effort by the WMF to make uploading on Commons easier (which is what we want), it became a pain to us, such as the increase in copyright violations (which is what we don't like). It would be better if we turn off this feature and focus first on how to make UploadWizard, which is good in educating users on copyright (although some users are uploading copyvios through UW), to be portable and a successor to this feature. ★ Poké95 12:22, 4 August 2016 (UTC)
    • Are you sure about that? I haven't looked at the latest numbers, but the last time I saw the numbers, a first-time uploader was equally as likely to have problems, regardless of which tool was being used. The main difference between UploadWizard and cross-wiki uploads is not that first-time editors fare better with the more elaborate and complex UW, but that more experienced editors choose UploadWizard – so the "average" upload by cross-wiki is a first-timer, and the "average" upload by UW is an experienced editor, but it's the editor, not the tool, that makes the difference. I'm pretty sure that it's possible to change the cross-wiki upload button to open the Upload Wizard in another tab, but I believe that will just move the problem to the other tool, and not actually solve it. (If you're curious, I don't use either of these tools; I use the basic form by preference). Whatamidoing (WMF) (talk) 12:41, 4 August 2016 (UTC)
      • @Whatamidoing (WMF): Do we have actual numbers on the good/bad ratio of new users using cross-wiki vs. new users using UploadWizard? --El Grafo (talk) 12:50, 4 August 2016 (UTC)
        • The Phabricator task has some data. If memory serves, the ratios are fairly similar. Jo-Jo Eumerus (talk) 13:09, 4 August 2016 (UTC)
          • Cross-wiki is almost all newbies (according to number of Commons' contributions; their accounts might be years old, and they might have dozens or hundreds of edits at their home wikis, but they've not usually uploaded very many files to Commons before).
            Here is a simple illustration: I went to Special:RecentChanges and looked at file uploads. There were six people who uploaded files using cross-wiki uploads in my list. Their total edit counts (each) are: 20, 1, 1, 1, 3, and 1. So that's four who have never done anything except upload this file, and two who have done almost nothing. I then looked for the most recent six editors who used Special:UploadWizard. Their total edit counts (each) are: 1, 389, 2,296, 1,214, 63,392, and 18,267. That's one newbie (who uploaded File:Muestra pedagógica 2016.jpg, and labeled it as being someone else's work), one fairly experienced person, and four contributors with thousands or tens of thousands of edits. Now, just considering the edit counts, would any reasonable person expect those two groups to have the same level of problems? Whatamidoing (WMF) (talk) 13:51, 4 August 2016 (UTC)
            • @Whatamidoing (WMF): You claimed that a first-time uploader was equally as likely to have problems, regardless of which tool was being used, so forget about experienced users for the moment. We have some numbers for inexperienced users using cross-wiki, showing that there is a high amount of bad uploads. But to see if the good/bad ratio of cross-wiki uploads by inexperienced users is similar for other tools, we need numbers for them as well. So once again: Do we have those numbers? And if no: who can provide them? --El Grafo (talk) 14:51, 4 August 2016 (UTC)
              • I don't have the numbers at hand, but they were basically the same. If memory serves, then for the first set of numbers that I saw, UploadWizard was worse, and for the next (better/more fully reviewed and larger sample) numbers, UploadWizard was a bit better. However, the difference was never better enough to matter in practice. Newbies' grasp of Commons' scope, copyright issues, and even identifying who had taken a photo was pretty abysmal no matter which tool they used. Giving it the best possible interpretation, it was the difference between "pretty bad" and "rather bad". Whatamidoing (WMF) (talk) 16:25, 4 August 2016 (UTC)
  2. Cross-wiki uploads shift the task of educating users about what may and may not be uploaded here to individual local projects. There are many Wikimedia projects with local uploads enabled that allow fair use content despite not having an EDP (or having one that contravenes the WMF's licensing resolution), or that allow uploads without any source, authorship or copyright information. The task of educating users on what they may and may not upload to this project cannot be outsourced to those projects. —LX (talk, contribs) 14:30, 4 August 2016 (UTC)
    • LX, I'm not sure how I can explain the relevance of your comments about local projects. You say that cross-wiki uplods "shifts the task of educating users to local projects" – but local projects get no real say in the educational information that the cross-wiki upload tool provides. You say that there are many projects that have EDP problems (feel free to drop a list on my talk page, BTW) – but the policies at local wikis don't affect cross-wiki uploads. And this particular tool is used almost exclusively by newbies, which means that the uploaders have no idea what the local wiki permits or doesn't permit, because w:en:WP:Nobody reads the directions – especially not directions that aren't linked anywhere within the uploader's view. So the problems with local policies and their enforcement sound, well, irrelevant. (I think I understand the "we want to control it ourselves" parts of your comments, just not the "local policies that the newbie is completely unaware of cause the newbie to screw up at Commons" parts.) Whatamidoing (WMF) (talk) 10:58, 8 August 2016 (UTC)
      Whatamidoing (WMF): I'm not saying that the policies of the local projects cause people to screw up; I'm saying that some projects breed a culture of carelessness when it comes to copyright. The first time a user logs in on Commons, they get a welcome message on their user talk page with information on what this project is about, including what they can and cannot upload here. True, a lot of people don't read that, or our policies, or the information in the Upload Wizard. But I'm not cynical enough to think that the information we provide makes no difference whatsoever for anybody. —LX (talk, contribs) 15:50, 8 August 2016 (UTC)
  3. Sadly, it is a failure. Yann (talk) 15:34, 4 August 2016 (UTC)
  4. As per User:LX. --AntanO 02:09, 5 August 2016 (UTC)
  5. Immediately. Horrible idea. When you upload to commons you have to do it from here. There are just too many reasons for that for anyone to even think it was a good idea when it was implemented. I first learned it even existed today. Yesterday though I was trying to track down an image that said it was posted from a wiki and I could not tell what that meant. Delphi234 (talk) 05:17, 5 August 2016 (UTC)
  6. Per Yann in the discussion and LX. --Zhuyifei1999 (talk) 06:35, 5 August 2016 (UTC)
  7. LX put it nicely. Additionally, this feature seems to be in a true "beta" state, which is unsuited for "productive" use by the broad wiki public. It may or it should come back if and when a solution for those copyright issues is found, whatever it may be (technical solutions? paid manpower? otherwise rewarded "special positions"? publicity to recruit more interested and knowledgeable people? Dunno...). Grand-Duc (talk) 18:50, 5 August 2016 (UTC)
  8. Sadly, yes, it has to stop. Rehman 10:47, 6 August 2016 (UTC)
  9. Per Yann in the discussion and LX, too.- Earth Saver (talk) at 14:45, 6 August 2016 (UTC)
  10. I think you should turn off cross-wiki uploads. I've had to sit through the cruft of out of scope media and copyright violations rather than being more productive.--RIP iPad 2 (talk) 19:51, 6 August 2016 (UTC)
  11. This experiment has failed. It leads to more copyright violations and less participation on Commons. It should be shut down. Regards, James(talk/contribs) 03:28, 7 August 2016 (UTC)
  12. This has resulted in me having to make far too many visits to commons in order to get copyright violations deleted. --AussieLegend (✉) 22:32, 7 August 2016 (UTC)
  13. WMF hasn't learned anything since the mobile upload stuff? Huh? — regards, Revi 16:18, 8 August 2016 (UTC)
  14. Switch it off, yeah. DS (talk) 21:43, 8 August 2016 (UTC)
  15. Get rid of it. This is just one example. I nominated a file for deletion recently here on Commons. It was uploaded to Commons by a guy who wanted to write an article about himself on en-wiki. The file was a picture of a brochure, with his name with a box around it. He then claimed the item as "his own work." It was clearly a commercial product with an immaterial alteration. Now, the guy didn't have a clue as to what he was doing - he was uploading stuff "to support his own notability." If the situation was not self-promotional, had he not been presented the option to upload to Commons, the file could have been OK on en-wiki under NFCC as "illustrative of the subject" receiving an award. Moreover, instead of being able to dump it off en-wiki directly, I had to go to the file page in enwiki, find out it was here, come over here, and DR it, whereas I could have Twinkle FFDed it on enwiki. Moreover, after a crosslinked file is deleted, the Commons Delinker bot has to go clean the links out of the other wikis. So a lot of extra cleanup work occurs because of a crosslink that shouldn't have happened. Having to do the extra work to set up the account here is also going to discourage a lot of vandal images and stupidity, because it's not just a button push away anymore. MSJapan (talk) 02:36, 9 August 2016 (UTC)
  16. I've just checked 20 cross-wiki uploads in a row. Most of them were copyright violations, the rest clearly out of scope. But none of them was useful. Didn't the WMF learn anything from mobile uploads? --Didym (talk) 02:53, 9 August 2016 (UTC)
  17. It was a good idea, but it does not work well in practice. We cannot handle this flow rate of bad uploads. Ariadacapo (talk) 10:17, 9 August 2016 (UTC)
  18. Though I would support investing in some community management and communication courses for Whatamidoing (WMF). Natuur12 (talk) 11:13, 9 August 2016 (UTC)
  19. Gunnex (talk) 01:51, 10 August 2016 (UTC) per Phabricator and comment below
  20. Symbol strong support vote.svg Strong support, it cause a lot of copyvio files.--Stang 05:11, 10 August 2016 (UTC)
  21. Symbol support vote.svg Support Without automatic reverse searching all the cross-wiki uploads, the system is fail. We are struggling to keep up with the increased volume of simple copyright violations due to this "feature". Cross-wiki uploads are mostly all copyvios because the people uploading the images have no understanding of the system (or no desire to understand the system). Please turn it off. Ellin Beltz (talk) 14:59, 11 August 2016 (UTC)
  22. Symbol support vote.svg Support --.js 02:52, 15 August 2016 (UTC)
  23. sad but switch it off. -- Simplicius (talk) 05:33, 15 August 2016 (UTC)
  24. Same problem as with mobile uploads before. Dear WMF, please do not add any more work to the Commons community without getting consensus first. Better user experience is great but not the only point which is to be considered here. Unfortunately, most newbies are not familiar with copyright, free licenses etc. Perhaps it would be a better idea to restrict cross-wiki uploads to a global user group which is only assigned to those who are already experienced with Commons and copyright issues. --AFBorchert (talk) 09:08, 15 August 2016 (UTC)
  25. Switch it off, more effort than benefit. --Achim (talk) 18:53, 16 August 2016 (UTC)
  26. Symbol strong support vote.svg Strong support --DCB (talk) 11:24, 17 August 2016 (UTC)
  27. Symbol support vote.svg Support turning off --Atlasowa (talk) 20:43, 20 August 2016 (UTC)
  28. Symbol support vote.svg Support This creates confusion as to what project the file has been uploaded to. MorganKevinJ(talk) 02:04, 21 August 2016 (UTC)
  29. Symbol support vote.svg Support I would like to support the tool in the future after it is more developed. This is another case of balancing the interests of staff developers and strategists versus the capacity of the volunteer time of the volunteer community. To save cost in staff development of the tool it is imagined that a huge burden of frustrating, boring labor can be put on the volunteers, and this is not the case. Send the tool back and return it after there has been development investment to prevent the burden of the problem from falling to the volunteer community. Having a tool which either harms the review community or lowers the quality of Wikipedia is not a viable solution for a new user recruitment strategy. If there is no money to invest in the tool then the time must not be right to introduce it. Blue Rasberry (talk) 13:39, 23 August 2016 (UTC)
  30. Symbol support vote.svg Support False good idea.--Archaeodontosaurus (talk) 14:06, 23 August 2016 (UTC)
  31. Symbol support vote.svg Support. More cons than pros. — ξxplicit 08:18, 24 August 2016 (UTC)
  32. Symbol support vote.svg Support Jianhui67 talk★contribs 07:10, 25 August 2016 (UTC)
  33. Symbol support vote.svg Support --Berthold Werner (talk) 08:49, 26 August 2016 (UTC)
  34. Symbol strong support vote.svg Strong support --Well-Informed Optimist (talk) 17:24, 27 August 2016 (UTC)
  35. Symbol strong support vote.svg Strong support --Priority is not to get new users, but to not increase workload/ burden and lose experienced editors. --Chris.urs-o (talk) 11:36, 2 September 2016 (UTC)
  36. Symbol support vote.svg Support When will this be closed? BethNaught (talk) 17:00, 14 September 2016 (UTC)
  37. Symbol support vote.svg Support ↔ User: Perhelion 16:07, 15 September 2016 (UTC)

I oppose switching off cross-wiki uploads[edit]

  1. Insofar as mw:Upload dialog to me implies that cross-wiki upload is a tool to facilitate the editing and creation of pages by having the upload function right by the editing ones, it has some value. But it needs a more flexible approach to what licenses to use. And perhaps a restriction to editors with some experience. Jo-Jo Eumerus (talk) 13:11, 5 August 2016 (UTC)
  2. many projects have uploads on their own site disabled, so all uploads are send to commons. Cross-wiki uploads are just one way to do that. And all uploads here are treated the same way. I can see no advantage of local uploads over cross wiki ones in the copyvio detection or any other handling. Commons is short on active amdins, I do not excluse myself on that. Be we simply have to deal with everything that comes our way, no matter what path it comes on. --h-stt !? 14:13, 15 August 2016 (UTC)
  3. Instead, we should invest in redesigning the UX for the cross-wiki uploader to discourage people from taking attribution for pics that do not belong to them. For instance, right now checking the "I own this work" checkbox enables the upload button, which will make people click on it. Instead, we should have a question like "Did you take this picture?" with 2 answers: Yes/No. Yes lets you upload cross-wiki, No takes you to the local upload page (which often takes you right back to Commons, depending on what you select there).--Strainu (talk) 21:58, 18 August 2016 (UTC)
    The WMF has already tested that, but they are not satisfied with the result. See their cross-wiki upload A/B test that was done on December 2015. ★ Poké95 05:36, 20 August 2016 (UTC)
    Yep, we didn't find a good solution in that test from the looks of it. But that's the problem we really need to solve. It's not going to be easy. Carl Lindberg (talk) 17:10, 20 August 2016 (UTC)
    Also, as shown in the phabricator item, limiting the uploads through the AbuseFilter has helped tremendously. No need to disable such an important feature now.--Strainu (talk) 13:19, 23 September 2016 (UTC)
  4. Symbol oppose vote.svg Oppose. Turning off a feature so as to bypass an issue is not really a solution. This feature is pretty useful to Wikipedia users, because they feel home.--Praveen:talk 02:21, 24 August 2016 (UTC)
  5. I'm not sure but I'll place myself here just for clarity. I've checked a sample of the most recent uploads and they look rather good on average, now that the filters have been made very strict. I suggest to archive the entire RfC and start from scratch with recent data. Nemo 15:25, 29 August 2016 (UTC)
    @Nemo bis: I wonder how we are supposed to explain this situation to users like this one. By keeping cross-wiki upload available-to-use yet won't-even-work (abuse filtered), we are losing contributers. --Zhuyifei1999 (talk) 05:19, 30 August 2016 (UTC)
  6. Symbol oppose vote.svg Oppose total removal. Prefered alternative would be to have it be a "user right" that anyone with an established, good history of contributing on the Commons could apply for and expect to be granted, subject to revocation if it is misused. Davidwr (talk) 18:34, 30 August 2016 (UTC)
    I don't think having a "cross-wiki upload user right" for established users makes any sense. It just gives more bureaucracy, and unestablished users can just upload their files through Upload Wizard and then link the file to the page they want. It makes it a bit harder for users to post copyright violations on pages, but doesn't prevents it. The cross-wiki upload tool is intended for everyone, not just established users. ★ Poké95 06:09, 15 September 2016 (UTC)
    It's far more circuitous and needs a lot more boxes. Which may seem like little to you but when writing an encyclopedia article - not a trivial thing - it can tire out people faster. Jo-Jo Eumerus (talk) 15:23, 15 September 2016 (UTC)
  7. Symbol oppose vote.svg Oppose Making it harder to upload files to Commons is no solution to Copy-right-Problems. If at all, disable it for IPs only! -- Michael F. Schönitzer 13:50, 31 August 2016 (UTC)
    Users who are not logged in do not and never have been able to upload files to Commons, through this or any other interface. Disabling what's already is disabled seems like an odd proposal. —LX (talk, contribs) 16:20, 31 August 2016 (UTC)

Discussion 2[edit]

  • @Josve05a: That's an excellent point. We might have to do that as well, but to be honest, meta is kind of confusing to me. As Commons is the community that has to deal with the fallout, I suppose it makes sense to get an opinion from here first. If there is strong support in this community to shut it off, this might make it easier to convince people from the local projects. If, on the other hand, the Commons community says "nevermind, we can deal with this", we can avoid the hassle of the machinery at meta: and just leave things as they are. I'll edit the description above regarding that, but if anyone wants to take this to meta now please go ahead. --El Grafo (talk) 12:20, 4 August 2016 (UTC)
  • This is the correct and only place to discuss it. This is the only wiki that is affected. Meta is not appropriate at all, though you can make a link to this discussion from there. The last thing you want is one wiki making decisions for another, or having a discussion scattered all over the place. Delphi234 (talk) 05:24, 5 August 2016 (UTC)
  • In my mind, the problem with cross-wiki uploads resembles a bit with the one enWiki is currently having with Content Translation and disputes concerning several other tools devised by the WMF whose general aim is to increase input into the projects (e.g new users, more article writing, more uploads) - all these things increase both good (in this case, sound uploads) and bad (in this case, COM:L violations) input and there is never work done on increasing the manpower and manhours that exist to manage the bad input. Jo-Jo Eumerus (talk) 12:47, 4 August 2016 (UTC)
  • For something completely different: the "technical issues" on mobile upload are just being fixed (see meta:Grants:IEG/Improve 'Upload to Commons' Android App), so there should be more mobile uploads soon.
  • I have no comments on this. I have said all that I felt like saying about it. —TheDJ (talk • contribs) 14:10, 4 August 2016 (UTC)
    • TheDJ: Your point there is interesting, mainly because almost nobody supports this point of view on Commons. I have always argued for pushing the accepted allowed works as far as possible, but it is quite difficult (read impossible) to ignore copyright law completely. Which is what quite a number of uploaders sadly do. If you have a sensible proposal for enlarging the range of allowed works, I am very eager to hear it. Regards, Yann (talk) 15:45, 4 August 2016 (UTC)
    • What stood out to me in the linked comment was the imbalance between Commonites willing to curate other people's uploads and the volume of uploads needing curation. So, since I'm already here (thank you, El Grafo), and since this discussion is likely to be more fun than anything else on my task list ;-) What could we do to fix this imbalance? Can we recruit a thousand new reviewers? Turn checking uploads for matches with Google Images and TinEye into a video game? Make a one-click system to transwiki album artwork and the like back to the Wikipedia where it's used (presumably with an automatic filter, so that it only goes to wikis that accept Fair Use images)? End every successful upload with a request to review the previous uploader's work? What could we do that might get some new people involved in reviewing things? Or maybe we should do it from the other direction: Can we make reviewing uploads quicker for the existing people? What ideas do you have? Whatamidoing (WMF) (talk) 17:05, 4 August 2016 (UTC)
      • Whatamidoing (WMF): First and foremost, we need more boots on the ground, so getting people to participate here for real rather than creating tools such as cross-wiki uploads, which only serve to decrease involvement. Then we need an upload process that really asks the right questions of uploaders with support for derivative works and PD decision trees. The problem domain is too complex to be dumbed down to the level of the current Wizard. Modeling proper decision trees require domain expertise, so should be possible for volunteers of this project to control, rather than being hardcoded. Then we could benefit from a whole bunch of little features like automatic categories based on metadata, searching metadata, searching by file type, file size and (where applicable) dimensions, better edit summaries for Upload Wizard uploads, sorting categories and search results by upload time, more informative and structured search results for media files... to name a few. —LX (talk, contribs) 20:00, 4 August 2016 (UTC)
      • So:
        1. More users here.
        2. Upload tools to be configurable locally (might be possible with the "building blocks" approach planned for Flow)
        3. Automatic (or at least suggested) categories
        4. Search improvements: metadata, file type, file size, dimensions (maybe aspect ratio?), more structured search results
        5. Better edit summaries for Upload Wizard uploads – phab:T142687
        6. Sorting categories and search results by upload time
      • LX, can you tell me more about how you would improve UploadWizard's edit summaries? It seems like that would be relatively quick. (An example or two is likely to be enough: For File:Example.jpg, it said "Foo" but it would be much more helpful if it had said "Foo in bar with baz and bat features".) Whatamidoing (WMF) (talk) 09:38, 8 August 2016 (UTC)
        Whatamidoing (WMF): Please see Commons:Upload Wizard feedback/Archive/2011/10#Blank edit summaries. —LX (talk, contribs) 16:04, 8 August 2016 (UTC)
      • Whatamidoing (WMF): At least, we get to the heart of the issue. I think we can't avoid using skilled manpower, even if we get more and better tools. So finally we need people not only uploading, and then runninggoing back to their pet project, but being more involved in Commons. There are certainly more Wikimedia volunteers who have the capabilities to review files than the ones already doing it. How do we motivate them to help, THAT is the question... Regards, Yann (talk) 22:03, 4 August 2016 (UTC)
        • Yann: That's another thing I'm worried about. With UploadWizard, people came to Commons, uploaded there file and most of them went back to where they came from. But at least they reached Commons once, so there was a chance they realized it existed. I fear that cross-wiki uploads may lead to even less people finding their way to Commons. --El Grafo (talk) 08:49, 5 August 2016 (UTC)
        • Any ideas on how to get people back here? Maybe a bot to deliver invitations to their talk pages on their home project? (There's good research from the Teahouse project on personalized automated messages, which work fairly well.) We could thank them for the file, suggest that they look at the file page to see whether it should be expanded or corrected, and maybe suggest some simple way to help out. (Any good ideas on a simple task that newbies are generally successful at?) Or we could set up a Teahouse, which seems to be a pretty positive thing on the Wikipedias. This could be done for any active non-Commons editor, regardless of which tool they use for uploads. Whatamidoing (WMF) (talk) 09:44, 8 August 2016 (UTC)
      • @Whatamidoing (WMF): Sorry for the bold here, but a tool for an administrator closing a deletion request to x-wiki the deleted file to the wikis where it is used, especially for cases where the file was fair use and incorrectly transferred to Commons.
        I don't think it's a good idea to enable doing so 'automatically' for editors (non-admins) who aren't already trusted with the right to delete files here, however... it's something that would be prone to abuse and burdensome on other wikis if abused. Reventtalk 11:56, 5 August 2016 (UTC)
        • Revent (and anyone else who's interested): I think you're right. Let's get some details organized and make a formal request for this. So here's a few things that I'd put in the list for an ideal tool:
          1. (critical) Restrict this to Commons' admins. The tool will not only copy the file to the project, but also delete it at the end.
          2. It should try to "guess" which wiki wants this file, based upon current file use, which wiki wants the file.
          3. (critical) It should "know" which wikis accept fair-use files, and only transwiki files to those wikis (e.g., a setting for the English Wikipedia, but not for the Haitian Creole Wikipedia).
          4. (important) It should know how to tag or categorize the images on each of those local wikis, so that the local editors and admins can process it. (Ideally, this would be configurable locally, so Commons admins can change it whenever they want – perhaps a system similar to w:en:MediaWiki:Citoid-template-type-map.json?)
          5. It should know who the uploader is, and leave a message (Twinkle-style) for the uploader at the target project (not at Commons, or at least not only at Commons) about the file being transwiki'd.
        • I'm picturing something like this: you click a 'transwiki this fair use file' button, and it says, depending upon the circumstance:
          • This was a cross-wiki upload from the English Wikipedia by WhatamIdoing. It is used at the English Wikipedia. Would you like to transwiki it to the English Wikipedia, tag it with {{subst:nrd}}, and leave a note on WhatamIdoing's talk page at the English Wikipedia?
          • This was a cross-wiki upload from Meta by WhatamIdoing. It is not used at any project that accepts fair use. Would you like to delete it now and leave a note on WhatamIdoing's talk page at Meta?
          • This was a cross-wiki upload from Meta by WhatamIdoing. It's used at two wikis that accept fair use. Would you like to transwiki to the English Wikipedia and French Wikipedia and leave a note on WhatamIdoing's talk page at both of those wikis?
        • Does that sound approximately right? What else would you add for either critical features or nice-to-have options? For example, do you want to be able to choose from a list of fair-use rationale templates at each wiki (e.g., this one is album artwork, that one is a corporate logo), or would you rather have a single message on all of them? Whatamidoing (WMF) (talk) 10:13, 8 August 2016 (UTC)
          @Whatamidoing (WMF): Sounds very solid to me. My thoughts...
          • It needs to be possible to override what user is notified, or specify more than one. Some of the methods and bots used, over time, to transfer files to Commons from other wikis have resulted in the actual upload not being by the human editor, and 'formats' for giving the history from the other wiki have varied widely. This might actually be used more, over time, for rejecting bad fair use moves more than actual crosswiki uploads.
          • I think it's essential, because of language issues, that such uploads to other wikis be clearly marked as having been uploaded by a script, by a Commons admin who may not know the language of the wiki, and in some way flagged for human review there. Not only do we not want 'bad' uploads to other wikis, but we don't want a Commons admin blocked on some other project because they transferred a file that someone was using to spam despite it being legitimate fair use in some contexts.
          • Being able to select the appropriate free use rationale would be very nice, but... I can see it being a huge amount of effort to implement... some fair use templates seem to be linked across wikis via wikidata, but it looks like most are not. Reventtalk 07:03, 9 August 2016 (UTC)
  • We can try to make Special:AbuseFilter/153 moor restrictive. Maybe replacing the user_age with an edit count check. --Steinsplitter (talk) 15:40, 4 August 2016 (UTC)
  • I take no comment on this position, but I would like there to be a method of speedy deletion for files clearly not matching Wikimedia Commons' purpose, like personal photos added to spam Wikipedia pages. At the moment there isn't a specific criterion for these if they're not copyright violations. Blythwood (talk) 22:41, 5 August 2016 (UTC)
  • Turning xwiki upload off would take away the possibility to do a fire and forget upload. One would have to go to Commons and do it here. That certainly will keep away a ton of selfies. There is the probability that a few users will not upload anything if we remove the convenient way. Frankly, turn it of. Nice idea tho. --Hedwig in Washington (mail?) 08:44, 6 August 2016 (UTC)
    • Cross-wiki uploads do not seem to be a significant source of selfies. I checked the last 50 a little while ago, and there were just three possible selfies, and only one that was likely to be a selfie. Because cross-wiki uploads happen in the context of editing an article, it's more likely that editors using the cross-wiki tool will upload something relevant to the article that they're working on – which is far more likely to be a copyrighted corporate logo or album artwork than a selfie. Whatamidoing (WMF) (talk) 10:29, 8 August 2016 (UTC)
      • @Whatamidoing (WMF): +31000 files has been blocked in less than a month. In first place, we need a automated copyvio detection tool (using the google image search as backend, for example). long overdue... --Steinsplitter (talk) 10:51, 8 August 2016 (UTC)
        • Does your abuse filter really just block all vertical images with a 5:3 aspect ratio? So if I went outside and took a picture of the pavement, cropped it to 5:3 vertical, and then uploaded it via the cross-wiki tool, you'd block that as a suspected selfie? Whatamidoing (WMF) (talk) 19:22, 8 August 2016 (UTC)
          • It blocks all small files by newbies and all png's. It is the outcome of a long community discussion on AN/U. I won't repeat myself because it would be too long to write here, you may find details in the AN archive. --Steinsplitter (talk) 11:04, 9 August 2016 (UTC)
      • @Whatamidoing (WMF): Can you do something to get a automated copyvio detection tool coded and deployed, contemporary? :) --Steinsplitter (talk) 11:05, 8 August 2016 (UTC)
        • Already been asked on phab:T31793 and probably elsewhere as well. From what I know Google does not offer an API for such things, and automated copyvio detection has a low reliability (both in terms of false negatives - seeing as not all common sources of copyvio are on GIS or other services - and false positives) in general. Jo-Jo Eumerus (talk) 18:16, 8 August 2016 (UTC)
          • @Jo-Jo Eumerus: then TinEye... , if configured correctly the false positive ratio would be low. The tool is makeable, whiteout any doubts. --Steinsplitter (talk) 18:27, 8 August 2016 (UTC)
            • I believe that Jo-Jo is correct about Google Image's API being unavailable, although some commercial service offers something similar. The coding end is feasible, especially if you're assuming that humans ultimately interpret the result (e.g., it flags but does not actually delete suspicious images). However, if we want this to happen "now" rather than "at least a year from now", then we have a budget problem: the service might cost about a million dollars, and that exceeds the allocations in the current (July 2016 to June 2017) WMF budget for such services. Whatamidoing (WMF) (talk) 19:22, 8 August 2016 (UTC)
              • @Whatamidoing (WMF): Scanning files by new users should be enough, unlikely that it costs a million. And there are other providers as well. I rather have the feeling that you are not intersted in such a scanner. --Steinsplitter (talk) 10:55, 9 August 2016 (UTC)
                • It looks like TinEye's paid service, at the larger-volume end, is $10,000 for 1 million queries over a year. It's not chump change, but it's not a million either. (It's $1,000 for 50,000 searches, which may be enough for a trial run.) If we restrict the upload functions to only newbies (fewer than X successful uploads), and make clear that only their own photographs are allowed (and ones not previously published), then any hit might qualify as a rejection, and ask users to go through a more regular upload process (photos previously published somewhere else needs to go through OTRS anyways). It would be far from foolproof (Tineye has many fewer hits than Google does), but maybe it could cut down on the problems, which really is the goal. We might also consider blocking files with "FBMD" metadata (meaning they are copied from Facebook). If that helps, maybe we could apply a similar approach to UploadWizard -- newbies can only upload their own photographs; to claim something is PD they should probably have a bit more experience. Carl Lindberg (talk) 04:13, 15 August 2016 (UTC)
  • I have not been involved in this, nor even used the upload wizard, but I had a couple of questions/points. First, copyright is a ridiculously complicated subject. Projects involving user-authored text have it much easier, since the typical situation is users supplying their own text which we automatically force a license. This is not the case with photos, where common usage is to find a photo on the Internet and just use it. I think asking newbies to identify reasons a work is PD is never going to work -- you have to learn some basics; no way around that. Is there any way this tool can be restricted to photographs actually *taken* by the uploader? Not simply just ask "own work" (which gets into copyright terminology and user may misunderstand as doing the work of finding/cropping/etc. for upload). If it's someone else's photo, they probably should use regular Commons upload tools, and perhaps learn some of the basics. In addition, I would probably mention that photos of themselves and friends (this includes selfies) are out of scope and will be deleted. If the tool was restricted (in wording) this way, we might even be able to make a TinEye or Google Images hit a reason to block the upload.
Second, is the problem more of many users uploading just 1-2 bad images, or a few certain users at projects who upload many? If the latter, maybe there could be a way to blacklist, from a central listing, certain users from using the tool. (I'm not sure if one exists or not.) If it's many users just uploading a couple images then not uploading again, not sure there is much that can be done on that score. It is indeed a bit of a problem that the tool increases the uploads, but does not increase actual Commons participation at all -- meaning users may never *learn* some of the details of copyright. Still, we do need to find ways to make uploads easier, which the tool has done -- but something that pumps two thirds copyvios into Commons will only degrade our reliability (there is no way humans can catch them all). We need to find a way to drastically reduce the problem files. Carl Lindberg (talk) 15:14, 8 August 2016 (UTC)
    • I believe that cross-wiki upload tool is responsible for just 5% of the uploads to Commons. It is, however, responsible for about half of the newbies (the other half are screwing up with using UploadWizard), because most of these editors upload the one or two images that they need for their Wikipedia article. The oversimplified rule of thumb for editor attrition rate is that 70% of registered Wikipedia editors never make even one edit, and, of those few who make one edit, 70% will never edit again. If Commons' numbers are similar, then you have a <1% chance of a one-time editor becoming a long-time contributor.
      As depressing as it sounds, two-thirds copvios seems to just be par for the course with newbies. The Multimedia team did controlled A/B tests with four different ways to phrase the copyright-related questions already in this tool, and it just didn't make a significant difference. Special:Contributions/newbies is discouraging for all of the tools, not just this one. Whatamidoing (WMF) (talk) 19:33, 8 August 2016 (UTC)
      • @Whatamidoing (WMF): I completely believe that we have that kind of rate among newbies -- the UploadWizard, while an improvement over earlier methods, probably could stand for a lot of improvement as well. We are definitely fighting prevailing usage, which is to simply copy images off the Internet and just use them. But, there must be a way to improve that rate -- and any solutions we find for UploadWizard would presumably also work for the cross-wiki tool. As you note, newbies are probably the biggest copyvio issue, and looking at your numbers a different way -- if it is supplying half the newbies -- means that it is doubling the copyvio uploads while supplying just 5% of the images overall. The probably is definitely one of educating users on an inherently complex subject -- very difficult to do, but that is the solution we really need. Turning off the cross-wiki tool is just turing off one spigot, reducing the scope of the problem, but is not a true solution -- the best would be to find different approaches for the newbie problem. If we can do that, then we would be much more free to experiment with ways to get new users here, such as the cross-wiki tool. Carl Lindberg (talk) 16:01, 11 August 2016 (UTC)
        • It's probably not doubling the newbies, because many of those who want images in their articles will find UploadWizard and use that instead. But on the overall point, we are certainly in full agreement that it would be great to find something that actually solves the problem of people uploading things that don't belong here. Whatamidoing (WMF) (talk) 21:33, 15 August 2016 (UTC)
  • I already lost tons of KB of text at Phabricator and tons of hours and MB's in Category:User:Gunnex, Quarry and elsewhere. I am exhausted. No, or short or long comment? Well...let's try a balance, I engaged in the last 5–6 month almost exclusively against cross-wiki uploads (see also my last 1.000 edits: 95 % related to this stuff) and... unable to find the words and probaldy also unable to find the "right" words: just turn the shit off. Imitating social-media via visual editor (or whatever) may work for text – but not for files... Go through the last 1000 hits of filter 153 and imagine what kind of works were uploaded mostly uncontrolled between 10.2015 – 14.07.2016, reaching (analysing a single day) bad ratios of 72,00 %. And yes: we have still thousands of undetected copyvios/PS/no-perm/etc. at Commons --> "degrade our reliability": it's already down, considering also the extreme low "Not-yet-tagged ratio" of e.g. User:Gunnex/Cross-wiki uploads from pt.wikipedia.org (overall bad ratio only from this wiki between 10.2015 — 04.2016 = +/- 85,00 %), where on certain periods around 50,00 % of all files remained untagged. Btw, forget Tineye as API. And... forget Google also... which is not a "Highest Wisdom" for photo research (ignoring or not able to index multiple sites) and not able to scan mayor social media sites like Facebook etc. (and even scanning Flickr often fails). For tagging a photo as copyvio I sometimes spent hours in research. I am probadly the only one on Commons who regularly scans no exif images, typical FB images 720xX/960xX/2048xX res pictures on Facebook – not to mentioned other characteristic resolution like 512xX for Instagram etc.). In times of modern smartphones and digicams, better worldwide internet infrastructure and (on the other hand) the increasing social media traffic, each "own work" upload of an actual photo below 2049 px with no exif must be considered as critical. Okay, exif can be manipulated... but anyway... we have ten of thousand of living files definitively grabbed (per exif: "FBMD") from Facebook. 17.622 from 2015 and 25.363 for 2016 (till 08.08.2016). See also my hundreds of related DR's. See also the confirmed FBMD DR's. Feel free to do the same for * – another typical indicator of a Facebook grab.
All this may be copyright paranoia but – considering the tens of thousands of deleted cross-wiki uploads: especially from this group we have the greatest ratio of copyright liars = internet grabbers/file croppers/watermark removers/photoshopper/social media grabbers/etc. I engaged also as a "lone-wolf" in User:Gunnex/Cross-wiki uploads 15.07.2016–18.07.2016 and the sequel User:Gunnex/Cross-wiki uploads 19.07.2016–27.07.2016 (after introducing the abuse filter 153) and – sorry to say – about +/- 50,00–70,00 % of all tagged files were probadly made only by me – again an indicator of the low "Not-yet-tagged ratio" in Commons = understaffed. All that leads to the question: why I am doing this: is WMF only sitting around, waiting for and processing some few DMCA-takedown and the rest... who cares? Hopefully not. Really? Definitively, Commons need a strong (technical/user) input strategy in the next years to keep it viable, as it is the central database for multimedia files for all wiki projects (and reusers outside). WMF's orientation on quantity strategy is failing also here --> isolated cases: Wikipedia Zero I + II + mobile uploads (already mentioned above) + XYZ. Try to understand: quality = reliability --> quantity = picload.or/directupload.net/imghoster.us etc. Or: make it harder, not easier.
In other words: an upload form which tries to simulate (especially for fresh users) a crash course in copyrights in seconds just clicking on some 2-3 options fields --> it fails + it doesn't work. They (the uploader) don't understand, they don't care, they ignore it. In most cases: they want the instant (Facebook like) result = the image of their preferred actor, hometown, football player, ego-spam and/or business/Youtube channel/company/blog/product spam, etc. stored in the wiki entry.
And please: turn it on off NOW: while we are debate on improvments (which will take weeks etc. to be eventually implemented [technically]), Commons is flooded in the meantime with related dubious files. Start from "0" – or just forget the whole social-media thing... a [now] pseudo-activism of WMF staff trying to save the floundering ship of the "cross-wiki" uploads-feature does not really help. The Phabricator-task was created in 12.2015 = 2 month after cross-wiki uploads was activated. Since then... trials & errors at the expense of Commons.
My spontaneous recommendation just to save the current situation: Cross-wiki uploads only for locally auto-confirmed users with at least +100 local edits + a campaign on local wikis (including technical improvements & instructions) how to report copyright violations on Commons. I am always surprised to see how a flood of [a] new photo[s] for a specific wiki entry (let's say: a city) is "accepted" by even experienced local user, marking then these edits as "patrolled" --> instead of re-checking the new photo[s] with a simple counter-search. Probadly because: what is on Commons, is probadly okay. No. Not anymore... Btw, did you ever tried to tag a local fawiki/arwiki/etc. uploaded copyvio? The implementation and monitoring of local uploads in scope of local image policies are... sometimes... ridiculous... Years later, a bot comes across and vomits the file into to Commons... but I am drifting away. And also probadly didn't find the "right words" for the whole stuff.
Gunnex (talk) 01:51, 10 August 2016 (UTC)
One question is how to attract valuable new contributors. Do we need people uploading just a few images for their first article (are they likely to continue contributing and learning as they go?) or could we get the equivalent images (where they are own works or free) through seasoned (Wikipedia) editors who had some chance to learn the rules? For these, some awkwardness in the upload tools and choosing licence templates is not a catastrophe: they will ask for and get help. I think projects like Wiki Loves Monuments are good ways to attract new non-wikipedia contributors (we need such contributors too): there is a problem with newbies, but there is a chance to educate them.
WMF has done a lot to attract new contributors. Do they have some research on what is important not to turn away potentially valuable contributors? Is the ability to illustrate one's article a strategic issue?
--LPfi (talk) 12:54, 17 August 2016 (UTC)
I think that's the critical problem (newbies uploading copyvios), and one that we have not solved I don't think, even for the UploadWizard. The cross-wiki tool merely exacerbates that existing problem, since it does a good job at getting new users to upload files, but is about equivalent on copyright education (which is lacking). Copyright is a very difficult subject, and fairly daunting for the uninitiated. (And Wiki Loves Monuments hits one of the really ugly cases, freedom of panorama, head on. There are many countries where uploads from that event will largely be deleted.) One potential approach, which I mentioned above, might be to restrict uploads to someone's own photographs until X number of uploads or X number of edits. I don't know how feasible that would be, but it may be possible. I would not use "own work" wording; I would explicitly say photographs actually *taken* by the uploader, and make that point clear. Anything else gets into hairier copyright situations which need some copyright understanding, but for true "own work" situations we can make a much simpler licensing situation -- just pick from one of the Creative Commons licenses, and maybe a couple of others. We could also deny the upload if we find *any* TinEye hit as well, if we wanted to go to those lengths. After that, maybe another level to allow U.S. works from before 1923, or other works from before say 1870 or 1880 (assuming PD-old), or if they can supply an explicit author's death year, allow those where that year is at least 70 years ago (though even that could run into issues for URAA-restored works). But we might have more luck starting with own-work-only (but use plainer non-legal language). The above discussion says they tried four different wordings on the UI and they didn't make much difference -- would be good to know what those were so we know what not to try. Carl Lindberg (talk) 19:50, 17 August 2016 (UTC)
I think allowing only own works is a big problem. If uploading requires making false claims, people will make false claims. Not being able to upload or being able, but having the image deleted soon after, are of course not that different, but in the latter case there is a chance to have a discussion. Perhaps the need of more information could be clarified at upload: "Upload succeeded, but more information is needed, please check the discussion at [your user talk page]", with a note added by the upload bot. Then it would not be a matter of checking the right boxes to be able to upload (to later have the copyvio noticed and deleted), but a matter of fulfilling the requirements. I do not know whether we have enough folks to answer questions, but better to handle the discussions when the uploader is there. --LPfi (talk) 09:38, 21 August 2016 (UTC)
That's a legitimate point too. People want to upload files, good or bad, and they'll find the path of least resistance. The idea is to make people stop and actually understand what "authorship" actually means, and the type of files we allow, and respect that -- it's entirely possible that allowing them to upload, then deleting it and having a discussion, may be the best course. In that situation, a regular deletion request (with a discussion page) may be better than speedy tags. I was sort of hoping for any sort of automated way to process the deletion though, and finding a TinEye hit (of any sort) may be one way to do that, if they were really "own works". We could also stand for more friendly novice deletion tags to explain things a bit more gently. Carl Lindberg (talk) 17:46, 22 August 2016 (UTC)
  • Can we archive this discussion? The recent uploads look quite good, since the abuse filter was made much stricter. We can discuss the matter again in some months, to see if the filter is good enough or some other action is needed. Of course, discussion and development in specific issues can continue e.g. on Phabricator. Nemo 09:30, 18 September 2016 (UTC)
    Are you suggesting that a community RfC with 84% support should just be shut down without action? This appears an attempt to end-run around the consensus, noting that you opposed the proposal. BethNaught (talk) 10:06, 18 September 2016 (UTC)
    You can archive it when the consensus demonstrated by it has been acted on. The abuse filter is a stopgap with a lot of false positives that are turning people away from Commons and Wikimedia projects in general – not a solution. The solution is to direct uploaders to the project where they'll be uploading where they can get information and support about the project they're about to contribute to. —LX (talk, contribs) 19:22, 18 September 2016 (UTC)
    The consensus is about a state of things which no longer exist. The consensus is that if state X then action Y. We are in state Z ≠ X. We can consider the consensus of this discussion valid, sure; but we still need a discussion to determined whether state Z is equivalent to state X. Nemo 17:50, 22 September 2016 (UTC)
    State this and state that... The state of the cross-wiki upload interface hasn't changed. The fact that we now have to lead good and bad uploaders alike into a dead end based on incredibly crude heuristics is not a sign of health. The root of the problem is that cross-wiki uploads shift the task of educating users about what may and may not be uploaded here to individual local projects, making the whole concept a fundamentally bad idea from start to finish. Those facts haven't changed just because we're masking the effects of the problem. —LX (talk, contribs) 18:48, 22 September 2016 (UTC)
    Users are largely being directed to use the standard upload interfaces (Special:Upload and Special:UploadWizard): that's not "masking" the problem. The filters "just" force the cross-wiki uploads to be mostly about the only case that was really considered in the software development, i.e. upload of self-shot photos. --Nemo 14:12, 23 September 2016 (UTC)
    Users are largely being led into a dead end and end up giving up and leaving, as evidenced by the number of red contributions links in the abuse log. —LX (talk, contribs) 15:53, 23 September 2016 (UTC)
    That's a good thing, since most of those uploads are not suitable for Commons either way (as is evident even from their filenames). Nemo 08:52, 29 September 2016 (UTC)

WikiSymbols[edit]

https://meta.m.wikimedia.org/wiki/WikiSymbols


This is the first and outdated version of WikiSymbols, find the most recent at the bottom or at https://meta.m.wikimedia.org/wiki/WikiSymbols Vision: The proposed WikiSymbols is about symbols/icons that can be understood by people from different cultures and different educational backgrounds as well as illiterate people. WikiSymbols enables (intercultural) communication without words. Contributors to the proposed WikiSymbols design symbols for all kinds of words and upload them with different tags so they can be found. Users worldwide can then download them and use them for websites, presentations, ... simply communication without words. The symbols could also be integrated into other wiki projects.

Public Domain and Creative Commons Licence: The contributors can choose whether their symbol/icon has a public domain licence or a creative common licence. The icon can driectly be downloaded in both cases. In the case of public domain, the creator of the icon/symbol has not to be credited. In the case of creative commons, the creator of the icon has either to be credited or a royalty fee has to be paid to the contributor. Payment information (Paypal account and price) of the contributor is shown in case the downloader wants to use the icon without giving credits to the creator. The fee goes 100% to the designer. WikiSymbols does not charge intermediaries and the contributor is free to set the price he/she wants.

Status Quo: There are already a couple of websites that aim to make icons more accessible. To name two successful/popular of them: The Noun Project (https://thenounproject.com/) and iconfinder.com

iconfinder.com recently has reached more than 1,000,000 icons. The most popular sites that sell icons have each 1-7 million unique visitors per month. Estimations are that there are tens of thousands if not hundred thousand contributors to these sites.

Background: One big problem though, is that there is no website which is not charging a high commission fee. Commission fees are between 30 and 70 percent. An average contributing designer earns 15-200 $ per month from uploading their work. Part of the vision of WikiSymbols is that designers earn 100% of what they upload. Many designers today donot upload their icons to these platforms, thus they are not publicly available not. Probably many good symbols are not created because of the commission fees for the intermediaries. — Preceding unsigned comment added by GabrielVogel (talk • contribs) 00:17, 13 September 2016 (UTC)

I was interested until you brought money into the equation. A Wikimedia project which was explicitly designed to help people raise money for themselves would run counter to longstanding tradition. If there is a need for such a project, it should happen independently of Wikimedia-foundation-managed projects. Davidwr (talk) 03:17, 13 September 2016 (UTC)

Thanks for the contribution Davidwr, see the new concept here:

WikiSymbols (most recent concept version)

Vision:↵The proposed WikiSymbols is about symbols/icons that can be understood by people from different cultures and different educational backgrounds as well as illiterate people. WikiSymbols enables (intercultural) communication without words. Contributors to the proposed WikiSymbols design symbols for all kinds of words and upload them with different tags so they can be found. Users worldwide can then download them and use them for websites, presentations, ... simply communication without words. The symbols could also be integrated into other wiki projects.

Public Domain and Creative Commons Licence:↵The contributors can choose whether their symbol/icon has a public domain licence or a creative common licence. The icon can driectly be downloaded in both cases. In the case of public domain, the creator of the icon/symbol has not to be credited. In the case of creative commons, the creator of the icon has to be credited.

Status Quo:↵There are already a couple of websites that aim to make icons more accessible. To name two successful/popular of them: The Noun Project (https://thenounproject.com/) and iconfinder.com

iconfinder.com recently has reached more than 1,000,000 icons. The most popular sites that sell icons have each 1-7 million unique visitors per month. Estimations are that there are tens of thousands if not hundred thousand contributors to these sites. They are marketplaces with high commission rates. For example, at The Noun Project (a company which started with donations from kickstarter) designers earn an average 0,03$ per sold icon. There are therefore many designers who would rather give them away for free than to sell them at these platforms.

There is already a lot of symbols/icons at Wikimedia Commons. (Maybe someone knows how many?) The symbols at Commons are not that easy to find though. To attract more designers who would contribute it is necessary to present the symbols/icons in a more prominent place. — Preceding unsigned comment added by GabrielVogel (talk • contribs) 08:25, 13 September 2016 (UTC)

We already have Category:Symbols. Will this meet your needs? Davidwr (talk) 04:01, 16 September 2016 (UTC)

Symbols-Logo contest: draft proposal[edit]

I want to propose for a rapid grant for a Wikimedia Commons Symbols contest. Read the draft proposal below. I kindly ask you for:

  • Discussion whether the symbol contest should be a logo-contest for Wikimedia Commons’ symbols? So that the winner symbol will be used to mark symbols at Wikimedia Commons and also at the Category:Symbols category page and subcategory pages.
  • If you oppose the logo-contest, what other symbol specific content should the winner symbol be used for? What should the symbols specific focus be and how could the symbol be used?
  • Discussion whether the symbol contest should be announced at the Category:Symbols category page aand subcategory pages?
  • Jury participation and organizational help

Draft Proposal:

What content will the contest focus on, and why is it important to your community?

Current situation regarding access to symbols/icons:

  • There is no central repository that allows free access to symbols/icons.
  • There is a high demand for icons.

https://www.quora.com/What-is-the-best-place-online-to-sell-icons “Iconfinder.com has 1.3 million unique monthly visitors. [...] I do know that GraphicRiver boasts several millions. [...] iStockPhoto and Shutterstock have been around for at least 2 decades so they have tens-of-millions of monthly users, if not more.”

  • The demand for icons is met by icon online market places that resell icons with high commission rates (30-70%)
  • Wikimedia Commons has already a lot of icons and contributing designers (over 1 000 registered vector graphics editors).
  • The number of icons on Wikimedia Commons is insuffiecient though. The number of icons is also small compared to icon online market places.
  • Wikimedia Commons already has Category:Symbols.
  • Category:Symbols could be better presented to attract more designers of vector graphics.

The contest will therefore focus on symbols/icons. The symbols/icons-contest is important to the Wikimedia Commons community as it will:

  • increase the number of symbols/icons
  • attract already active designers of vector graphics to contribute
  • attract designers who have not yet contributed to Category:Symbols
  • increase the identification with Category:Symbols

How will you let people know about the contest?

The contest will be announced at the Wikimedia Commons Village Pump, at the Wikimedia Forum, via Wikimedia-I mailing list, on the Category:Symbols category site and subcategory sites.

How will you judge the contest and award prizes?

An international Jury will choose the winners. Rules:

  • Be self created: All entries must be original symbols uploaded by their authors. Symbols uploaded by anyone else than author (even with permission) are not accepted.
  • Be self uploaded during the contest period (1st December 2016 - 28th February 2017): You are also welcome to submit symbols you may have taken in the past. What matters is that the symbols must be uploaded during the contest period.
  • Be under a free license;
  • Contain a logo for Wikimedia Commons symbols.
  • Have the format .svg
  • A participant should have an activated e-mail address via Preferences of his/her account.

For photo contests, what is the strategy to get images used on projects?

The symbol contest is a logo-contest for Wikimedia Commons’ symbols? So that the winner symbol will be used to mark symbols at Wikimedia Commons and also at the Category:Symbols category page and subcategory pages.

Is there anything else you want to tell us about this project?

  1. Prize: 300 $ and the logo being used for Wikimedia Commons symbols
  2. Prize: 150 $
  3. Prize: 75 $
—Preceding unsigned comment was added by 62.47.243.233 (talk) 15:01, 16 September 2016 (UTC)

Edited by GabrielVogel — Preceding unsigned comment added by GabrielVogel (talk • contribs) 15:04, 16 September 2016 (UTC)

Tool to find files with few categories[edit]

Hi, does somebody know how to find files within a category that are categorized in only 2 or 3 categories? There is some tool to do it? I think that some time ago I saw a sql script, but I can not find it. Thank you --JotaCartas (talk) 14:16, 22 September 2016 (UTC)

Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals&oldid=208569066"