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
uploading
Village pump
copyrightproposals
Administrators' noticeboard
vandalismuser problemsblocks 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?

 

List of used photos: "USED UPLOADS"[edit]

It would be very nice if there was a point "List of used photos" ("USED UPLOADS") on the menu. (I have uploaded hundreds of photos. I am happy to know, see what use. (No matter where))

for example:

English | USER | 0 | 0 | Talk | Preferences | Beta | Watchlist | Uploads | "USED UPLOADS" | Contributions | Log out

--Molgreen (talk) 12:27, 2 July 2016 (UTC)

https://tools.wmflabs.org/glamtools/glamorous.php
In Preferences under Gadgets, you can turn on that tool for categories, so you have a link to see usage for all images in that category. I don't know of a way to get a link added for a user's uploads, but you can do that once you go to the tool page. Carl Lindberg (talk) 06:35, 3 July 2016 (UTC)
Fine. Thank you very much. That is very helpful.
Something I would additionally wish: a link to the corresponding to the images. (So I can learn which images / motives for others are interesting. So my wish for the menu item "USED UPLOADS".)
--Molgreen (talk) 14:23, 3 July 2016 (UTC)
When you are using the tool, click the "Show limited details" -- that will show you a breakdown by image. "Show details" gives you links to the individual articles (though you can also just go to the image page on the individual project to see those as well). I agree it might be nice to have a per-user link to the tool in the sidebar if turned on in preferences, much like categories. Carl Lindberg (talk) 15:42, 3 July 2016 (UTC)
Many Thanks. That's what I was looking for. And yes, it would be very nice if this would be preset. --Molgreen (talk) 16:20, 3 July 2016 (UTC)
@Molgreen: Another thing to try... go to Special:Preferences#mw-prefsection-gadgets and turn on "Global Usage Badges". The tool works on COM:MyGallery, and will indicate global usage count for an editor's uploads (It's 'my gallery', but you can change the targeted editor once the tool is actually loaded). Reventtalk 23:46, 21 July 2016 (UTC)
@Revent:Hello Revent, thank you for this tip. I was inactive for some time and could test it only now. Works great. Thank you. --Molgreen (talk) 04:45, 4 August 2016 (UTC)

New criteria for speedy deletion[edit]

Hi. I notice lately that Wikimedia Commons has been flooded with personal photos that are out of scope. Should we amend the speedy deletion policy as follows?: The following media will now be nominated for speedy deletion: Personal photos(unless the person was notable) Do you like my idea?--100.36.171.168 16:34, 18 July 2016 (UTC)

Personal photos are allowed if used on user pages. We also have no notability guidelines, and using Wikipedia's is not always the best (wikibooks may still have use for some things, Wikinews, etc.) Those type of things are really still a judgement call that likely needs a DR. Speedy deletes don't really give uploaders a chance to defend their stuff. Carl Lindberg (talk) 16:50, 18 July 2016 (UTC)
Very bad idea, IMO. Speedy deletions are for images where there is obviously no particular need for admin discretion... cases where either there is an obvious legal need for deletion, or the community consensus is so well established that debate would just be a waste of time.... things like copyright violations, re-uploads of previously deleted files, and duplicates. "Scope" is always a judgement call... it's a matter of opinion, and so should be open to discussion.
There are 'personal photos' of unremarkable people that are in scope, because they usefully illustrate something like a behavior, ethic group, mode of dress, medical condition, whatever.. Even if a image is simply 'uploaded' as spam does not directly imply that it might not fill a unique gap in our collection. Sometimes they simply end up being used to make the examples used in an article like 'selfie' more diverse. Reventtalk 23:40, 21 July 2016 (UTC)
Exactly: User:Revent tells it like it is. -- Tuválkin 03:43, 23 July 2016 (UTC)

Proposed mass deletion of Latin-named coats of arms uploaded by Ssolbergj[edit]

Ssolbergj (talk · contribs) has uploaded many SVG images of coats of arms with Latin filenames which Ssolbergj says they have created themselves. This is a proposal to mass-delete all of these because of serious concerns that they do not accurately represent the coats of arms (or rather, its blazon, or heraldic description) they purport to depict.

Some of these images purport to be coats of arms of countries that do not actually have coats of arms in the heraldic sense. Two good examples are File:Insigne Civitatum Foederatarum.svg, claimed to be the coat of arms of the United States, and File:Insigne Francum.svg, claimed to be that of France. However, these countries use an emblem in the place of a coat of arms (Great Seal of the United States and National emblem of France). A similar case are Hawaii and Italy. The "coats of arms" uploaded by Ssolbergj are not based on any blazon or source, and seem to be Ssolbergj's own invention. They do not have any purpose within the scope of Commons.

Others are simply incorrect representations of the blazon. For example, File:Insigne Helveticum.svg, which originally drew my attention, in its original version depicted the Swiss cross as composed of four squares, whereas the official blazon states that the arms are slightly longer than wide. (Ssolbergj has corrected this error after I nominated the file for deletion.) Another example found at random is File:Insigne Papuae.svg, claimed to represent the Indonesian province of Papua, but which lacks elements found in the official coat of arms as e.g. correctly represented in File:Papua COA.svg; or File:Insigne Africae australis.svg, which lacks the "waist and knee bands Argent" found in the actual coat of arms. Because I have limited knowledge of heraldry, I am not able to determine whether other files are similarly erroneous, but the original research exhibited by Ssolbergj in their invented coats of arms above should lead us to assume that many others might be similarly deficient.

All of this wouldn't be a big deal if Ssolbergj wouldn't aggressively push these files into use in the English Wikipedia. E.g., they engaged in a sustained edit-war to have them included in en:Template:Coat of arms, despite an ongoing RfC which has now closed with an unanimous consensus (apart from Ssolbergj themselves) to not use Ssolbergj's images, and Ssolbergj has swamped that RfC with walls of difficult-to-understand text. This confrontative conduct is another indication that Ssolbergj is not in line with the aims of Commons and Wikipedia to create accurate, sourced and collaborative educational materials. I therefore think that it is appropriate to mass-delete all of these images to improve the project's quality. Should this discussion not get consensus for that, we'd need to start individual deletion discussions, which would take an inordinate amount of time and effort for all. Sandstein (talk) 09:09, 1 August 2016 (UTC)

Opinions[edit]

  • Delete all, as proposer. Sandstein (talk) 09:09, 1 August 2016 (UTC)
  • Keep - It is not a sufficient reason for mass deletion. There are different versions of COA and one being different version is not valid grounds for deletion. Some files may need to be renamed and have their description updated, but I don't support mass deletion. The images can always be improved by the OP or even a 3rd party, but if you remove the images the information is gone and can not be improved on and can not be adapted for other uses. If what you say about the edit war is true then this is unfortunate, but that is a issue that needs to be sorted on that wiki by the administrators there.Offnfopt(talk) 21:58, 2 August 2016 (UTC)
  • Keep These are not reasons to delete, let alone mass delete. Having escutcheon-only versions of some COAs can make sense, and at first glance they seem OK. They are potentially useful in an educational context, and they seem to be freely licensed. While it is possible for a particular SVG to be derivative of an existing graphic version, it's probably relatively rare, and would come down to outlines which are exactly copied from existing non-free versions (and identifiable as being specifically from that version, and not others). For the US, I'm not sure what you are saying -- they do indeed have a coat of arms in the heraldic sense. In general, the entire obverse of the Great Seal is considered the coat of arms, although if you go strictly by the letter of the original law, the crest would be omitted (but the COA would include the escutcheon, the eagle, the scroll, the arrows, and the olive branch). For files which are incorrect emblazonments, we have the {{disputed coat of arms}} template. We do not delete -- even for bad versions, components could be re-usable on other COAs, and they can always be fixed (by other users too, not just the original uploader). Any mistakes should be noted and marked, but they are almost always salvageable and should not be deleted. It is pretty easy to miss a small detail; mistakes happen. If COAs are completely invented and fictional, while purporting to be real, that could be an issue, but not ones where an attempt was made to follow the blazon. The Latin names are a bit odd, but again, not a deletion issue.
As you say, the main issue (and only real problem) is the pushing of use of the images on English Wikipedia against consensus. While I sympathize, that is not a direct issue on Commons and is not a deletion reason. If files can be or are used on some projects, but then are misused on another project as part of an edit war, we do not delete from Commons just to resolve the edit war. While that is a real problem, it is better dealt with on English Wikipedia itself, I think. Carl Lindberg (talk) 04:09, 3 August 2016 (UTC)
  • Delete, all of the given examples contain minor and even mayor flaws. Some of the examples aren't even coat of arms of countries that use coat of arms. But by having that example (that is realy out of scope because it's a CoA that doesn't exist) people will think that CoA is for real. By just having a quick glance at the recent uploads by Ssolbergj I can tell you: every single one has errors. For example the CoA of the European Cybercrime Centre is missing a rim. It also appears to be more like a logo instead of a CoA. One other Euopean example: Coat of arms of the European Air Group should really look like THIS, those two are worlds apart. Commons should be concerned about depicting the truth, not just being a storage site for files. Dqfn13 (talk) 18:58, 3 August 2016 (UTC)
  • Keep I see no valid or consistent reason to delete these files, which, quite non-significantly are titled in the same non-English language. They do display heraldic escutheons, which are valuable in the presentation of coats of arms in wiki projects. These representations are valid, as they depict what the heraldic blazon describes, and even if they were in breach of the blazon that would not be a reason to delete images carelessly.
In line with heraldic convention, all elements of achievement except the indispensable escutcheon have been excluded. For example, the Belgian arms could be displayed as Royal Arms of Belgium.svg instead of more elaborate variants such as Great coat of arms of Belgium.svg or State Coat of Arms of Belgium.svg.
This proposed blanket deletion is groundless, in my view. - Ssolbergj (talk) 13:09, 2 August 2016 (UTC)
And, @Dqfn13, regarding " One other Euopean example: Coat of arms of the European Air Group should really look like THIS[...]. Commons should be concerned about depicting the truth": Heraldry should not be confused with logomaking, please read this template tag:
This representation of a coat of arms is potentially different from the one used by the armiger (municipality or organisation) in question.
Armoiries Brabant.svg = Royal Arms of Belgium.svg

“Sable, a lion
rampant or”
This coat of arms was drawn based on its blazon which – being a written description – is free from copyright. Any illustration conforming with the blazon of the arms is considered to be heraldically correct. Thus several different artistic interpretations of the same coat of arms can exist. The design officially used by the armiger is likely protected by copyright, in which case it cannot be used here.
Individual representations of a coat of arms, drawn from a blazon, may have a copyright belonging to the artist, but are not necessarily derivative works.
Further information: Commons:Coats of arms  and Template:Coa blazon

català | Deutsch | English | español | suomi | Lëtzebuergesch | македонски | Nederlands | русский | svenska | ไทย | українська | +/−

I.e. several different artistic interpretations of the same coat of arms (blazon) can exist. This is a principal heraldic convention that is commonly practiced which there can be found examples of across Wikimedia and in Wikipedia articles, in real-world usage of arms and throughout heraldic history. - Ssolbergj (talk) 06:25, 4 August 2016 (UTC)

@Ssolbergj: do you have the emblasonment (description) of the escutcheon? Because the bird is NOT an eagle, the wings are obviously of a seagal and the beak as well. You also forgot the text, which should be in your file. Sticking to the description is mendatory, as you sayd. Also about the lions in the template, if one of them would have two tails... it would be an entirly different story. Dqfn13 (talk) 18:33, 7 August 2016 (UTC)

Discussion[edit]

I do see where Ssolbergj gets most of his coats of arms, they do not seem to be invented ex nihilo. The design for Italy originates from the Civil Ensign of Italy, the design for France is based on the unofficial though prominent composition. You could make a stronger case for the escutcheon of the United States of America, since it’s actually part of the Great Seal. But when used on Wikipedia, it should preferably use the same shape of escutcheon as used in the Great Seal.

Still, all of that should be made clear in the file description. And obviously, for the other coats of arms, pushing non-official versions over the official ones is plainly wrong.

Armorial_of_the_European_Union#Member_states forms a fairly coherent roll of arms, a group of coats of arms rendered in the same style. The rest, while following the same naming conventions, seem to lack all coherence and are often missing their sources, which is a serious issue. File:Insigne Africae australis.svg might be a copyright violation if it closely follows the original, and it does seem to be a trace. Each of the Non-EU coats of arms should probably be checked individually to see if they correctly represent the full coat of arms, if the sources are mentioned, and if better alternatives exist already. Tom-L (talk) 10:49, 1 August 2016 (UTC)

Pictogram voting comment.svg Comment I have closed Commons:Deletion requests/File:Insigne Helveticum.svg, which is about one of these files, as having no clear consensus to delete after over a month, and being superseded by this. Reventtalk 07:22, 2 August 2016 (UTC)

Keep -

Private area: "Legacy - Safe" (in German: Privater Bereich: „Vermächtnis - Tresor“)[edit]

I have the following suggestion / request:

Very much I would like to upload photos in a ("private") protected area. I am thinking for example of photos of interiors, information boards, texts etc.

These photos are not currently of panoramic freedom and must be deleted immediately.

I want these photos but today Upload for later. My idea is that the controls are released 100 years after the upload.

Until then, they were only for administrators and myself visible itself.

At the same time I would want to insert already in categories. But they would not be visible to non-administrators.

(in German: Privater Bereich: „Vermächtnis- - Tresor“ Ich habe folgenden Vorschlag / Wunsch: Sehr gern würde ich Fotos in einen („privaten“) geschützten Bereich hochladen. Ich denke dabei zum Beispiel an Fotos von Innenräumen, Informationstafeln, Texten usw. Diese Fotos unterliegen aktuell nicht der Panoramafreiheit und müssen sofort gelöscht werden. Ich möchte diese Fotos aber heute für später hochladen. Meine Vorstellung ist, dass sie 100 Jahre nach dem Hochladen automatisch frei geschaltet werden. Bis dahin wären sie nur für Administratoren und mich selbst sichtbar. Gleichzeitig würde ich sie schon in Kategorie einfügen wollen. Sie wären aber für Nicht-Administratoren nicht sichtbar.) — Preceding unsigned comment added by Molgreen (talk • contribs)

@Molgreen: It's not exactly 'encouraged', but you can upload a work, and then immediately create a deletion request for it (as the uploader) requesting that it be undeleted at a future date. It's commonly done when someone 'inadvertently' uploads a valuable work that is not yet PD, and the DR pages are categorized at "Undelete in <year>"... there is usually a minor celebration about such undeletions on Public Domain Day. The uploader can no longer see the image or the file page as anything but a redlink, though (and administrators only 'see' deleted images by specifically looking at the particular revision of the file in the history of the deleted page... they do not even appear on the deleted file pages if you look at them).
If you were going to do something like this, I'd very strongly suggest that you do it on a very limited basis, and that you make sure to ping an active administrator right away and ask them to speedily close the DR (it has to be an actual DR to be categorized for future undeletion). It would probably be a good idea to ask on IRC, even, so that 'any' awake admin can go ahead and do it right away.... otherwise you might get in trouble for uploading copyvios. Reventtalk 10:50, 5 August 2016 (UTC)
@Revent:thanks for the feedback. The possibility of subsequent recovery I did not know. And yes, it only makes sense for individual images. I gladly would provide far more than 100 such files. (This need not be immediately.) - (in German: Hallo Revent, danke für die Rückmeldung. Die Möglichkeit der späteren Wiederherstellung kannte ich noch nicht. Und ja, es macht nur bei einzelnen Bildern Sinn. Gern würde ich weit mehr als 100 solcher Dateien bereitstellen. (Das muss auch nicht sofort sein.)) --Molgreen (talk) 04:34, 6 August 2016 (UTC)

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

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 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)

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)

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 (talkcontribs) 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)

Any special category under main wiki conference for aerial photography taken during to and fro journey of conference(specially who hv got scholarship)[edit]

Can we start a special category to collect all photographs of cities and places including aerial photography (uploaded to commons) from those who hv got scholarship to attain a wiki conference, under main category of conference as outcome of scholarship. This is only a suggestion. example are like this [1] and [2].
Regards.
Sumita Roy Dutta (talk) 16:04, 13 August 2016 (UTC)