*{{cmt}} 28 support (counting the proposal and {{ping|-revi}} as support votes), 4 oppose votes so far. (87.5% support) - [[User talk:Alexis Jazz|Alexis Jazz]] <sup><small>ping plz</small></sup> 20:04, 8 September 2018 (UTC)
*{{cmt}} 28 support (counting the proposal and {{ping|-revi}} as support votes), 4 oppose votes so far. (87.5% support) - [[User talk:Alexis Jazz|Alexis Jazz]] <sup><small>ping plz</small></sup> 20:04, 8 September 2018 (UTC)
*{{s}} I would go further and disallow homebrew licenses. I support limitations on licensing for Wikimedia Commons, and think that files in Commons must have community-approved licenses. In the past it was not certain whether Creative Commons licenses would be popular and so we wanted to leave options open for other organizations to establish licenses. Also we wanted to be open to many individual organizations making their own licenses. As it happened, Creative Commons became a market leader and has defined the thought on free and open licenses for media. I do not mind files having additional licenses tagged just so long as those licenses can be overlaid with a Creative Commons license. Licenses which are less free than the standard Wikimedia Commons choice of Creative Commons license are a problem and we ought to discourage them now and prohibit them soon. We get great advantages from having a body of compatible licenses. GFDL is not intended for media. Various other homebrew licenses are often applied in error or to the confusion of users. Wikimedia Commons does not benefit from permitting endless odd experiments in licensing. [[User:Bluerasberry|<span style="background:#cedff2;color:#11e">''' Blue Rasberry '''</span>]][[User talk:Bluerasberry|<span style="background:#cedff2;color:#11e">(talk)</span>]] 21:20, 10 September 2018 (UTC)
*{{s}} I would go further and disallow homebrew licenses. I support limitations on licensing for Wikimedia Commons, and think that files in Commons must have community-approved licenses. In the past it was not certain whether Creative Commons licenses would be popular and so we wanted to leave options open for other organizations to establish licenses. Also we wanted to be open to many individual organizations making their own licenses. As it happened, Creative Commons became a market leader and has defined the thought on free and open licenses for media. I do not mind files having additional licenses tagged just so long as those licenses can be overlaid with a Creative Commons license. Licenses which are less free than the standard Wikimedia Commons choice of Creative Commons license are a problem and we ought to discourage them now and prohibit them soon. We get great advantages from having a body of compatible licenses. GFDL is not intended for media. Various other homebrew licenses are often applied in error or to the confusion of users. Wikimedia Commons does not benefit from permitting endless odd experiments in licensing. [[User:Bluerasberry|<span style="background:#cedff2;color:#11e">''' Blue Rasberry '''</span>]][[User talk:Bluerasberry|<span style="background:#cedff2;color:#11e">(talk)</span>]] 21:20, 10 September 2018 (UTC)
{{section resolved|1=The proposal has wide support, and there is no active debate on the core proposal. I am closing this as successful, and I have updated [[Commons:Licensing]] to include the new rule, effective 15 October. [[User:Guanaco|Guanaco]] ([[User talk:Guanaco|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 07:56, 14 September 2018 (UTC)
{{section resolved|1=The proposal has wide support, and there is no active debate on the core proposal. I am closing this as successful, and I have updated [[Commons:Licensing]] to include the new rule, effective 15 October. [[User:Guanaco|Guanaco]] ([[User talk:Guanaco|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 07:56, 14 September 2018 (UTC)}}
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; the latest archive is Commons:Village pump/Proposals/Archive/2024/03.
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.
SpBotarchives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose most recent comment is older than 30 days.
Proposal to add additional language to existing block templates
Proposal has almost unanimous support, so I'm closing this as successful. I've updated the English version of the templates, but other languages will need to be updated as well. Please help with this if you can, by editing the various language subpages (e.g. Template:Blocked/ca). Guanaco (talk) 09:09, 1 September 2018 (UTC)[reply]
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
The current templates, such as the {{Blocked}} template, do not provide information about how to appeal a block. In addition, the {{Blocked user}} and the {{Indefblockeduser}} templates look as if they are written for administrators, rather than users. So, the following versions of the templates have been revised to be more user-friendly and provide information about how to request an unblock, should they believe they were blocked in error. The indef block also provides an email address, should the user's talk page also be blocked. This is an alternative to the above proposal for a universal block template. CaroleHenson (talk) 00:40, 13 July 2018 (UTC)[reply]
1. {{Blocked}}: You have been blocked for a duration of {{{1}}} heading
You have been blocked from editing Commons for a duration of {{{1}}} for the following reason: {{{2}}}. If you wish to make useful contributions, you may do so after the block expires. If you believe this block is unjustified, you may add {{Unblock}} below this message explaining clearly why you should be unblocked. See block log. For more information, see Appealing a block.
Azərbaycanca - Български - বাংলা - Català - Česky - Dansk - Deutsch - Deutsch (Sie-Form) - Zazaki - Ελληνικά - English - Esperanto - Español - Euskara - فارسی - Suomi - Français - Gaeilge - Galego - עברית - हिन्दी - Hrvatski - Magyar - Italiano - 日本語 - 한국어 - Македонски - മലയാളം - မြန်မာဘာသာ - Plattdüütsch - Nederlands - Norsk bokmål - Occitan - Polski - Português - Română - Русский - Simple English - Slovenščina - Svenska - ไทย - Türkçe - Українська - 中文（简体） - 中文（繁體） - +/−
You have been blocked from editing Commons. The reason for the block is available in the block log as is the name of the administrator who blocked you. If you believe this block is unjustified, you may add {{Unblock}} below this message explaining clearly why you should be unblocked. For more information, see Appealing a block.
You have been blocked indefinitely from editing Commons. See the block log for the reason that you have been blocked and the name of the administrator who blocked you. If you believe this block is unjustified, you may add {{Unblock}} below this message explaining clearly why you should be unblocked. For more information, see Appealing a block.
Azərbaycanca - Български - বাংলা - Català - Česky - Dansk - Deutsch - Deutsch (Sie-Form) - Zazaki - Ελληνικά - English - Esperanto - Español - Euskara - فارسی - Suomi - Français - Gaeilge - Galego - עברית - हिन्दी - Hrvatski - Magyar - Italiano - 日本語 - 한국어 - Македонски - മലയാളം - မြန်မာဘာသာ - Plattdüütsch - Nederlands - Norsk bokmål - Occitan - Polski - Português - Română - Русский - Simple English - Slovenščina - Svenska - ไทย - Türkçe - Українська - 中文（简体） - 中文（繁體） - +/−
Support This means, however, that the numerous subpages with translations will have to be updated too. This may take some time. De728631 (talk) 09:57, 13 July 2018 (UTC)[reply]
Support per above and my previous comments on the subject. This is a good step towards making the blocking and appeal process clearer to blocked users. clpo13(talk)15:33, 13 July 2018 (UTC)[reply]
Support the first two. Strongly oppose the last one due to the use of OTRS for this purpose. The use of OTRS for standard unblock requests is out of the remit for the volunteer response team. The only unblock requests we generally handle are those that could potentially involve personally identifiable information (such as impersonation of a real person blocks). I see no indication whatsoever that the OTRS team was even aware of this request to drastically change our remit posted to Commons:OTRS/Noticeboard or anywhere else that would allow people whose job you are changing to comment. Second, while there are 96 agents with access to the info-commons queue there are relatively few admins who have access. This proposal would invariable inundate that queue with requests that the majority of agents there would simply not be able to answer leaving actual requests they can answer buried amongst the others. Third, UTRS access is granted without question to all enwiki sysops automatically via OAuth. No request required. OTRS not only requires a request but the signing of a confidentiality agreement that I could very much imagine admins here that would otherwise process unblock requests would not want to do. If you are requesting that all admins get this access for processing these requests that would require a whole additional process and a changing of the very foundation upon which OTRS runs. Fourth, the revocation of talk page access and email that would require another method should be extremely rare anyways. Here, it is used for LTAs and (should be used only for) confirmed socks. At least in my opinion. The way forward here should not be to shove all the work for probable bad actors on the unsuspecting volunteers of OTRS who are probably not even aware of this discussion to begin with but to change the way Commons applies these blocks so that the revocation of normal unblock channels is done much more rarely. --Majora (talk) 20:24, 13 July 2018 (UTC)[reply]
The email is included in the standard block text but only mentions appealing an autoblock. Again, this is a rare occurrence and would involve private information such as IP addresses. Using OTRS for standard unblock appeals is out of our remit. --Majora (talk) 20:32, 13 July 2018 (UTC)[reply]
The support team is able to contact the blocking admin or to post a notice at one of the administrative boards. Of course, the support team does not handle the appeal itself but it can serve as messenger. --AFBorchert (talk) 13:04, 14 July 2018 (UTC)[reply]
And say what exactly? You have an unblock request but sorry we can't tell you anything about it? The confidentially agreement is a legally binding document that forbids agents from discussing the details of private conversations held inside of OTRS. Unless that admin is also OTRS with the proper access, which again see point two above, they can't be told any details. This is the way OTRS is set up to run. Any changes to this would require changing that. It is not our job to act as a messenger or a go between. That is putting an unnecessary extra burden on volunteers who give their time to answering these tickets in the first place. --Majora (talk) 13:19, 14 July 2018 (UTC)[reply]
@Majora: Again, the member of the OTRS support team can notify one of the administrative boards or the blocking admin. This is common practice at de:wp where indef'd accounts are closed and have no option to appeal on-wiki. In the reply, the OTRS member can provide a link to the opened discussion. Then we have at Commons the option to review the decision to remove talk page access. --AFBorchert (talk) 13:47, 15 July 2018 (UTC)[reply]
What is far more likely to happen, to be honest, is that these tickets will fall into a black hole never to be answered or looked at except by the few agents in that queue who actually want to deal with the extra steps that are being forced upon them. Or to deal with the screaming LTAs that are now aware of and encouraged to appeal towards that method (which we have no way to block their email addresses unless we get an OTRS admin involved). For working the permission queues I can tell you that the moment even the smallest amount of challenge arises in a ticket it goes dormant. Never to be looked at for months. If you are so concerned with getting these problems resolved in a timely manner and you picked OTRS to do that you don't know OTRS. --Majora (talk) 13:48, 14 July 2018 (UTC)[reply]
@Jeff G.: It seems to be in the blockedtext template only for the purpose of autoblocks, which is described there as a block of an IP address, not a user specifically. Could including it here be considered as expanding the scope of that avenue of appeal to all sorts of blocks, not just autoblocks? I share the concerns about OTRS not being the best avenue for this sort of thing, though if it's the only alternative, then possibly it's OK for now. But the email address was not in the templates being updated, nor the direct links from those templates, unless I'm missing something. They mention emails to administrators, but not OTRS. I'm not sure it's a good idea to include that address here. Carl Lindberg (talk) 16:16, 14 July 2018 (UTC)[reply]
(Edit conflict) In my opinion? Yes, at this time. If you really want to allow for email communications as an alternate there are potential alternative methods. Either create a private mailing list such as those that are used by Enwiki's Arbcom or Commons's oversight team. Or ask for a separate queue to be created inside of OTRS to handle these requests and change the rules so that that queue access is granted automatically to all Commons sysops. This would be equal to Enwiki's UTRS and would segregate the tasks from the info-commons due to the problems I outlined above to a different queue that is more regimented as to its purpose. --Majora (talk) 14:26, 14 July 2018 (UTC)[reply]
I don't have a problem with that, since the appealing a block link is on the template. If that's ok with others, too, do I just strike it out of the mock-up above?CaroleHenson (talk) 14:35, 14 July 2018 (UTC)[reply]
I mean, I'm apparently in the minority here so you can do whatever you wish. But I can foresee the numerous problems with doing this. OTRS is not the proper method to deal with standard unblock appeals like this and it doesn't, and won't, improve communication as has been alluded to by other people. OTRS is a black hole for any problematic tickets. All unblock requests are problematic tickets. This is the opposite of improved communication. --Majora (talk) 14:40, 14 July 2018 (UTC)[reply]
@Majora: I agree with what you're saying about permissions-commons, but info-commons tickets are answered quickly and effectively. I'm confident we can handle an increase in volume on this queue. Guanaco (talk) 00:57, 16 July 2018 (UTC)[reply]
I have my doubts as I've worked with OTRS for long enough to know what happens there. But like I said, I'm clearly in the minority here so if you wish to reinstate the email address that is completely up to you. I'm perfectly ok with the first two. I'm even ok with MediaWiki:Blockedtext having the email address for appealing specific circumstances (like autoblock). I just don't think that OTRS should be used for a standard unblock appeal process. --Majora (talk) 01:27, 16 July 2018 (UTC)[reply]
Support the first two. oppose the last one with the reference to OTRS (like Majora basically). OTRS is there to provide information about the block and its reasons, not a way to unblock. The actual wording is ambiguous. Maybe the Commons ML is the correct place to contact sysops and/or the community. However, it's ok to me if we rewrite the OTRS part, saying that further information –if needed– can be obtained there (where an agent will probably tell the user to write to the sysop that performed the block). --Ruthven(msg)08:22, 15 July 2018 (UTC)[reply]
Comment I removed the email address from the third template due to the expressed concerns. As long as the steps for appealing a block remains, I don't think it is necessary and I understand the process issues.CaroleHenson (talk) 13:22, 15 July 2018 (UTC)[reply]
Thank you CaroleHenson. I struck out my oppose above. As mentioned previously there are alternatives to using OTRS for this purpose. Mailing lists, private queues, even IRC can be logged if need be and there are bots that do just that for certain wikimedia channels right now (that seemed to be the major complaint of using IRC above). There are alternatives here that I truly believe would make for a far better alternative method to appealing blocks. --Majora (talk) 00:35, 16 July 2018 (UTC)[reply]
Comment Giving blocked users information on unblock options seems like a good thing, but on en. what often happens is that a new user responds rapidly with an unblock template that is perfectly reasonably worded from a typical angry-customer point of view (i.e. "X is an asshole and here's why") and the whole thing is on to an indef with no talk page access before the user even has a clue what the rules are. I think a better block template should make it clearer the user should calm down, read the rules first, be suitably obsequious and contrite, and only then try to make use of what may well be their one unblock opportunity before the whole thing turns into a hammer of humiliations from a jaded audience. Wnt (talk) 17:42, 15 July 2018 (UTC)[reply]
Comment The proposed updated text for {{Indefblockeduser}} includes "...you may add {{unblock}} below this message explaining....". However, the documentation for {{Indefblockeduser}} says this variant is only used on the User: page, not the User_talk: page. It should be directing any unblock request to the the user's talk page, not to their main user page. —RP88 (talk) 02:55, 17 July 2018 (UTC)[reply]
Support - I'm very surprised this was done years ago, Giving blocked users the chance to unblock themselves (under certain conditions) is obviously the right step in the right direction. Easy support. –Davey2010Talk13:09, 22 July 2018 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
This section is resolved and can be archived. If you disagree, replace this template with your comment. Guanaco (talk) 00:59, 14 September 2018 (UTC)
I've seen the Flickr2Commons tool abused fairly often lately, where users upload large numbers of files without categorizing them and without checking for Flickr washing and derivative works. The tool is also unmaintained and uploads many duplicates. I propose that we restrict the rate of uploads via edit filter 207. Extended uploaders, license reviewers, and admins would be exempt from this. If someone has a good reason to rapidly upload using this tool, they can request extended uploader status, and we can then revoke it if it's abused. Guanaco (talk) 12:00, 1 August 2018 (UTC)[reply]
Oppose Low rate limits, like 5 files a minute, for accounts with under 2,000 pre-existing uploads would be a good idea. Restriction of full use defined by other rights and groups seems too like a club membership model of governance. --Fæ (talk) 12:17, 1 August 2018 (UTC)[reply]
Oppose Why deny those (new or even long term contributors) who have valid reasons to use it, just because a small minority abuse or misuse it? Bidgee (talk) 12:56, 1 August 2018 (UTC)[reply]
Comment To be clear, everyone who has commented here would be unaffected by this. Extended uploader is almost always granted upon request, and it does not have a particularly high standard: "Extended uploaders are supposed to be familiar with the project scope, and especially with the file license policy." When it's been denied, it was because the user had recent copyvios, had almost no edits, or didn't actually need the rights for anything. I expect anyone hindered by this would ask to be an extended uploader, and we'd summarily grant their request in most cases. Guanaco (talk) 13:21, 1 August 2018 (UTC)[reply]
Last time I looked, I only had "Image reviewer", it was something I had to ask for and those who have been on Commons for awhile may not even have the "standards" (rights) you're proposing and again why treat all new contributors as evil? Bidgee (talk) 13:46, 1 August 2018 (UTC)[reply]
Image reviewer and license reviewer are the same thing, and "extended uploaders, license reviewers, and admins would be exempt from this." I don't think this would be treating them as evil, but rather asking them to check with someone before running a potentially disruptive script. Guanaco (talk) 15:04, 1 August 2018 (UTC)[reply]
@Guanaco: Would you agree that a minimum of 1,000 or 2,000 pre-existing uploads would be a fair way of constraining use of the tool, with users below this count expected to put in a request for an exception? --Fæ (talk) 14:14, 1 August 2018 (UTC)[reply]
@Fæ: I don't see a problem with enabling it for users with that many uploads. Unfortunately upload count doesn't seem to be an edit filter variable, so we'd have to develop an updated tool. This could be the best solution overall, as a new tool could provide better guidance in the interface and also check for duplicates and incomplete uploads. Guanaco (talk) 15:04, 1 August 2018 (UTC)[reply]
Oppose This is a very bad idea. Every time somebody makes the proposal to do something in the name of stopping abuse there needs to be a question "How will this impact those users, who do not abuse the tool?" clearly such a question was not asked here. "[T]hey can request extended uploader status" is not a sufficient solution. Wiki was originally the place that "everybody can edit", but we are becoming more and more like English "Wiki"pedia. Restricting good users to punish a few that happen to abuse the tool (or maybe not even abuse, but simply make a mistake, let's not forget AGF) is counterproductive endeavour. ℺ Gone Postal (〠✉✍⏿) 13:50, 1 August 2018 (UTC)[reply]
I think everyone can and should be able to edit and upload to Commons, and I see many problems with bureaucracy and instruction creep at English Wikipedia. However, high-speed bot-like uploading is something that should be regulated to some degree. I don't want to punish anyone, but the reality is that one clueless user's good-faith mistake means someone has to sort through dozens of files, create DRs, then someone else has to close them. This cleanup can waste many hours of volunteer time. Guanaco (talk) 15:04, 1 August 2018 (UTC)[reply]
Weak support But only if we find some sensible limits. I do agree that bot uploads can and should be monitored more closely than personal uploads because they have the potential to do more damage, but they also can improve something (there was a reason why such tools were created in the first place). ℺ Gone Postal (〠✉✍⏿) 19:12, 1 August 2018 (UTC)[reply]
I might be able to figure stuffs out if it wasn't the intersection of bitbucket, php, and complexity. I wonder, if this change will be implemented, should F2C be aware of it and operate just on the margin of the rate limit? --Zhuyifei1999 (talk) 19:00, 2 August 2018 (UTC)[reply]
Oppose the proposed limit of 3 files per minute (if I understand correctly), Support something like a limit of 200 files per hour. That would allow a user to import a whole shoot, then categorize it before moving on to the next. @Guanaco: "To be clear, everyone who has commented here would be unaffected by this." I would be affected by a limit of 3 files per minute. - Alexis Jazzping plz17:22, 1 August 2018 (UTC)[reply]
@Alexis Jazz: I meant everyone who had commented here at the time. If you want extended uploader, let me know because I think you are qualified. Anyway, 200 files per hour is problematic because it's likely to break in the middle of a large batch upload, and 100 unchecked images per hour from one user is still disruptive. Guanaco (talk) 23:04, 1 August 2018 (UTC)[reply]
Support If updating the tool was possible that would be best as it would allow us to update and patch the tool since that seems to be an obvious issue. If not I still support. It isn't hard to be added to the extended uploaders group. That is what I believe is meant by anyone here wouldn't be affected. -- Sixflashphoto (talk) 17:39, 1 August 2018 (UTC)[reply]
Comment, restricting the bot won't solve the duplicate issue (which is very annoying, how could we fix this???). Since its a really useful tool for uploading from flickr it would be a shame to limit its usage. (and a filter which blocks uploads of sunsets and sunrises would be great /s) Amada44talk to me21:10, 1 August 2018 (UTC)[reply]
Support I have spent far too much time cleaning up mass uploads from numerous users too lazy to name, describe, and categorize their uploads. F2C is an extremely powerful tool - it's essentially a bot - and using it for unchecked mass uploads is abuse. It is exactly the kind of tool that should require advanced permissions - if users cannot show that they apply useful filenames, useful categorization, and useful descriptions on small upload runs when they have plenty of time to do so, why the hell should we allow them to do sloppy uploads en masse? Pi.1415926535 (talk) 22:27, 1 August 2018 (UTC)[reply]
Support I did one crappy F2C run and spent a week and a half cleaning up my mess. We should at least be able to vet users to the point where we know they're the type of people who will clean up the mess if they leave one, and not leave it for someone else to do. GMGtalk22:55, 1 August 2018 (UTC)[reply]
Comment we should wait for the filter to generate a few more hits, but it looks like only a handful of users are going to be seriously affected by this. (and many occasional uploaders of a few dozen images that never caused any problem anyway) Some of those will be granted an extended uploader flag, leaving even fewer users. Wouldn't it better to educate (or block..) those users instead instead of creating an abuse filter? - Alexis Jazzping plz00:29, 2 August 2018 (UTC)[reply]
Users that refuse to properly clean up their mass uploads generally have no interest in putting in the effort, no matter how much they are reminded. (That includes some otherwise very respected editors, but I digress.) It is better to prevent them from accessing extremely powerful upload tools until they demonstrate that they will use them properly, than face a nasty choice between blocking them or continuing to allow them to abuse those tools. Pi.1415926535 (talk) 00:39, 2 August 2018 (UTC)[reply]
We could try keeping the filter as is (log only), and grant extended uploader to those who often use the tool correctly. Those who abuse it could have it disabled by username with a different filter. Guanaco (talk) 01:02, 2 August 2018 (UTC)[reply]
Guanaco, this is what I wrote before reading your reply: "Since we seemingly have no control over Flickr2Commons, how about using the abuse filter to target those problematic users instead of everyone? And maybe target uncategorized Flickr2Commons uploads from anyone else." I have no issues with using the filter to find problematic users.
DSC 4536, this is a bird.
DSC 4535, this is another bird.
Pi.1415926535, I think it just won't work. Look at these birds for example: uploaded by @Rudolphous: . Photo: quite poor, not really likely to be used in an article unless there really is nothing better. Filename: useless. Description: useless. Categories: Category:Birds in Artis (Artis is a Dutch zoo). The photos don't show anything really typical for that zoo, so the only useful information here is "birds". That's very nice, I'll surely find them next time I search for "birds". This abuse filter will be of no help for this because Rudolphous is an administrator. You are probably thinking "well surely this is an exception". You be the judge: User:Alexis Jazz/Great images with captions. - Alexis Jazzping plz04:15, 2 August 2018 (UTC)[reply]
Support F2C is a useful tool but Flickr is not a problem-free repository. In addition to Flickrwashing, there are other recurrent problems such as uploads with only PD Mark 1.0 (but no explanation of why a file is in the public domain). The concerns expressed by some users above and below are understandable but we need to see some progress on this issue. Green Giant (talk) 11:23, 13 August 2018 (UTC)[reply]
@Green Giant: but this filter (if it would actually limit actions, tagging is fine) won't solve the problems. One problem is that Flickr2commons doesn't check for duplicates properly. While the uploader has some responsiblity here as well, it's a bug. If there is a hole in the street, you don't fine people for falling into it, you close the hole. The fact that this is seemingly impossible should really worry everyone around here. If for whatever reason Flickr2commons breaks entirely, there simply will no longer be Flickr2commons because there is nobody who can fix it and Magnus Manske is on permanent holiday or something. Magnus is allowed to do that, but with nobody to take his place we have an issue that nobody seems to be getting the gravity of.
The other is that problems are not exactly limited to newbies. Even some admins are not using the tool properly. I'll analyze some of the filter hits below, it's clear this filter should not limit actions. - Alexis Jazzping plz15:35, 13 August 2018 (UTC)[reply]
@Alexis Jazz: Whether or not an upload tool has bugs, the responsibility for checking and fixing uploads lies entirely with the uploader. However, some people seem to think their only responsibility is to upload huge numbers of files, leaving clean-up to others. I don’t particularly like real-world analogies for wiki-problems but let’s say we think of F2C as a knife. If someone new to knives accidentally cuts their finger, we don’t blame the knife manufacturer. Instead we take safety measures to try to reduce accidents. The filter is a safety measure to reduce the number of poorly-managed uploads. To be honest, I believe other powerful tools like Cat-a-lot and VFC should also be limited-access because there is potential for large numbers of bad edits. Green Giant (talk) 16:17, 13 August 2018 (UTC)[reply]
@Green Giant: I agree in part with you, but when the knife manufacturer refuses to fix problems with their knives, we shouldn't ban knives. The filter isn't sufficiently selective for bad uploads. Too bad the knife manufacturer more or less has a monopoly.. - Alexis Jazzping plz16:21, 13 August 2018 (UTC)[reply]
Oppose, although Flickr2Commons could get abused it's one of the handiest import tools we have at Wikimedia Commons, otherwise we would have to revive batch requests for Flickr for only a small amount of trusted users but as the current Batch uploading list has a 5 (year) year backlog all this would do is create a lot of problems we currently don't have. Don't get me wrong we should find ways to stop abuse, maybe prevent uploads without categories, but Flickr2Commons is too valuable to restrict. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:27, 20 August 2018 (UTC)[reply]
Oppose per above. Would seriously hamper legitimate users, not to mention being outright process creep. Editors who abuse the tool can simply be blocked and their uploads can be mass-deleted. -FASTILY07:04, 30 August 2018 (UTC)[reply]
Neutral Probably some kind of restriction of Flickr2Commons would be a good idea, but not necessarily the proposed solution. I do think that we're getting quite a lot of problematic files from flickr. Gestumblindi (talk) 00:41, 11 September 2018 (UTC)[reply]
The example of 600 photographs of Highway 401 highlighted by BevinKacon is a good one. A justification for considering the value of uploading lots of photographs of the same object that a casual viewer may think boring or redundant. The highway is over 500 miles long and the most widely used reference set for viewing highways remains Google streetview. The photographs we have in this collection on Commons provide a valuable alternative collective view of the highway over different years and are guaranteed to be freely reusable, unlike Google streetview images which can only be justified under Fair Use. Over time, such collections have increasing archive value, see Category:John Margolies Roadside America Photograph Archive, a historic collection of 9,000 photographs of American roadside buildings and places. --Fæ (talk) 19:56, 12 August 2018 (UTC)[reply]
Snow track photo is a bit dark but fine if someone is looking to illustrate driving in snow. The dramatic sky is exactly what is says and is atmospheric. The Commuting Warp is arguable, but it is not an accidental blur but a deliberate effect by using long exposure, could be used to illustrate heavy nighttime highway driving. The back of a sign may seem bizarre, but it does tell us who has the contract for the signage on this part of the highway, the town the sign is placed within and confirms the year of construction. If these are the worst examples, it's quite an interesting set. --Fæ (talk) 16:28, 13 August 2018 (UTC)[reply]
If you look at my editing history, you'll find that:
I perform batch uploads, applying the most sensible top-level category for that upload (ie - one most applicable to all files being uploaded)
Shortly thereafter (sometimes the same day, sometimes later) I inspect that category to more carefully sort the files into sub-categories
I nominate for deletion the files that should have been filtered out during the Flickr2Commons upload, but that I didn't catch at the time (for example, File:Commuting Warp (6088536421).jpg mentioned above); although Flickr2Commons is useful, it has its failings (it doesn't state file size, whether the pic is a screenshot of a video, whether the file exists on Commons with a different name - it does catch same name uploads, ...)
Also note that files do not need to be geotagged in order to be more precisely sorted. I've refined the category for most files in Category:400-series highways (Ontario) by inspecting the signage on the pics, and correlating similar files by timestamp; you can see this in Category:Ontario Highway 400, such as on File:400 North (4394817913).jpg. The fact that I have not yet processed this current batch is immaterial, as there are no deadlines on Commons. (BTW: Highway 401 is over 800 km long, and I uploaded these files because they represent segments of the highway with no coverage on Commons; it shouldn't just be pics of the highway passing through a few major cities). As a final note, I'd appreciate being invited to a discussion about me, instead of having to find it on my own. Mindmatrix13:40, 16 August 2018 (UTC)[reply]
Given the concerns above, my opinion now is we should attempt a less restrictive measure. I've changed edit filter 207 to simply tag all flickr2commons uploads as such, and I created edit filter 208. This new filter allows users to be blocked from using the tool in response to disruption or misuse. When placing a restriction, an admin must always notify the user of the action on their talk page, and they should also log the date and reason for the action in the edit filter description.
This isn't as clean or as pretty as the upcoming partial block feature, but these two filters should let us easily observe and address misuse without resorting to a full site-block. Is there support for allowing admins to restrict individual users in this fashion? Guanaco (talk) 06:49, 2 August 2018 (UTC)[reply]
My concern about this is that it creates some potential nasty conflicts between experienced users. Based on Alexis's comments above, I would probably block Rudolphus from this tool, as well as several other admins. And while that would stop the disruptive use, I've now pissed off an admin. So any restrictions on F2C, while extremely necessary, need to be implemented in a way that allows admins and other otherwise-well-regarded and well-connected users to be blocked from the tool without resulting in wheel-warring or other arguments. Pi.1415926535 (talk) 23:06, 2 August 2018 (UTC)[reply]
I think we have to handle this in the same way as blocks and other sanctions. If it's likely to be controversial, a noticeboard discussion should happen first, or immediately after if the problem is urgent. Also, we should be able to trust admins to respect consensus. If several people say "Stop what you're doing," an admin should be willing to listen. On the other hand, poorly categorized but in-scope files are arguably a net gain. It's similar to the old inclusionist vs. deletionist divide, and there aren't any easy, catch-all solutions. But in general when dealing with long-term good faith editors, discussion solves more problems than hostile admin actions. Guanaco (talk) 03:14, 3 August 2018 (UTC)[reply]
Analyzing some filter hits (it's more amusing than it sounds, trust me)
It looks like the Guanaco altered the filter to tag all Flickr2commons uploads, so one admin also ended up in this list.
User:B dash got tagged File:Barack Obama inspects new china 2015 (16703088723).jpg and others. No, that link is just a redirect. The upload was a dupe. But enough has been written about B dash already and this filter isn't going to make that go away. I'm already happy B dash didn't mark the original upload as duplicate.
I didn't know how to name the file while uploading it with Flickr2commons, so what I could do was requesting for renaming afterwards. --Howard61313 (talk) 15:47, 13 August 2018 (UTC)[reply]
This section is resolved and can be archived. If you disagree, replace this template with your comment. This has revealed some interesting information, but there's clearly no consensus for my original proposal. We clearly must develop better tools, including duplicate detection and a reworked and properly maintained flickr2commons. Structured data and partial blocks may help with this issue. For cases where a particular user must be stopped from using flickr2commons, Special:AbuseFilter/208 is available. Guanaco (talk) 01:03, 14 September 2018 (UTC)
No longer allow GFDL for some new uploads
I'm aware of the odds for this proposal. I'm proposing it anyway, perhaps it'll pass, otherwise we may at least get some idea of where the community stands on this today. Any further restrictions as well as dealing with GPL may be done with other proposals as those things are more complicated. Last time When this was proposed in 2013, it resulted in too many words, so I'll try to limit the scope. If some people want to scream at me for this, I expect nothing less.
For those who are not aware, the GNU Free Documentation License is the license Wikipedia used before 2009. It was designed for software documentation. But Commons still allows uploads with nothing but a GFDL license today.
The main issue with GFDL is that it requires re-users to include 7 pages of text, which is generally not practical for individual pictures, video or audio. Because of this, this lead to the existence of {{GFDL 1.2 or cc-by-nc-3.0}} which is, in its very essence, a backdoor Creative Commons Attribution-NonCommercial license. After all, nobody is going to include 7 pages of text.
The proposal: GFDL alone will no longer be a valid license for uploads that meet the following requirements.
Licensed as GFDL one month after this proposal, if passed, becomes policy with the option to extend this to two months if problems arise. This gives existing projects and users a little bit of time to decide on a new license. Anything licensed as GFDL before is not affected by this proposal. What counts is the license date, not the upload or creation date.
Main or only content is a photograph, painting, drawing, audio or video.
Is not a software logo, diagram or screenshot that is extracted from a GFDL software manual.
So uploading a GFDL software manual will remain acceptable, anything already licensed as GFDL is not affected, software logos, diagrams and screenshots extracted from manuals are not affected. And a dual license like CC BY+GFDL is also no problem. What will be affected are files like File:Wedge tail eagle flight Jan13.jpg, File:19870300-skoda-100-bw-011.jpg and File:National March on the NRA 8045524.jpgif they weren't already licensed as GFDL before this proposal comes into effect. So the eagle, Skoda and national march will stay, but this practice would no longer be allowed for licensors in the future. - Alexis Jazzping plz07:34, 7 August 2018 (UTC)[reply]
Support By Foundation:Resolution:Licensing policy, we are expected to judge the freedom of licenses/works against the Definition of Free Cultural Works 1.0. This states that the four freedoms "should not be restricted by the context in which the work is used". When applied to a photograph, the GFDL prevents the photograph from being used in any context where including the whole license text is impossible, such as on postcards, t-shirts, billboards; so that GFDL can't properly be considered free for photographs. These requirements were designed and make sense for books, so continuing to upload genuinely GFDL books is fine. BethNaught (talk) 08:31, 7 August 2018 (UTC)[reply]
Take a look at something like this: File:Gzilla icon.png this is a 51x51 icon that requires attribution. I don't know how it is for you, but for me the author field currently is significantly larger than the image itself. This restricts the use of this file. It really does. I would not put it on a coin right now for example, it would fit, but the attribution wouldn't. If your thing is about finding something that is useful then read this same proposal of 5 years ago. I saw people saying there that what we need is the ability to easily filter content by licences. However, it is much easier to just say "I don't like it, so others must stop doing it" then to find a way to make something better. The way I see it we could have something like a current cat-a-lot javascript window, where you have "All licences" selected by default, but you can simply select or unselect some fields: "Requires attribution", "Viral", "Requires licence text", then "Forward compatible with ..." and "Backwards compatible with ...", as well as simply selecting a specific licence. This would make it possible for people to find files that are licenced as they need. ℺ Gone Postal (〠✉✍⏿) 14:54, 21 August 2018 (UTC)[reply]
You are unable to see the forest because of all of those blasted trees that get in your way. The exact image was an example. All the Attribution licences require you to list all the authors, what if the work was constantly improved that the list of the authors is now longer than GFDL licence. Does this mean that the work is now unfree? Of course not. The fact that it is somewhat inconvenient for some specific purpose does not invalidate the "freeness" (freenity, freeousity?) of some licence in general or file specifically. ℺ Gone Postal (〠✉✍⏿) 01:34, 22 August 2018 (UTC)[reply]
Support The GFDL was always a problematic license, and cannot be considered free in spirit for photos and similar stand-alone files. Sebari– aka Srittau (talk) 11:59, 7 August 2018 (UTC)[reply]
Support per this well-written article by Notafish. I particularly object to the use of GFDL 1.2 alone or in connection with non-free CC licenses for the purpose of discouraging commercial use of images, which runs contrary to the purpose of Wikimedia Commons as a repository of material freely usable by anyone for any reason. clpo13(talk)17:19, 7 August 2018 (UTC)[reply]
Support - If you don't want your images used anywhere then don't upload here, Simple as that, I fully support Alexis's proposal. –Davey2010Talk17:58, 7 August 2018 (UTC)[reply]
That's one viewpoint, but nothing involving Gnu is ever "as simple as that".
You can also interpret this as, "If there's a valuable resource which is published under GFDL, no, you can no longer use it on Commons (or maybe even a Wikipedia)". That's quite restrictive. Commons is not merely a source of content, it's also a consumer of content. Should we limit its ability to consume GFDL material? Andy Dingley (talk) 11:21, 9 August 2018 (UTC)[reply]
If you want an example for that scenario: I could obtain a permission from the somewhat unwilling photographer of the then (2007) only photography of murdered Theo van Gogh, File:TheoVanGogh.jpg, only by offering the somewhat "unsuitable" GFDL license. --Túrelio (talk) 12:31, 9 August 2018 (UTC)[reply]
Túrelio, Andy Dingley your arguments aren't valid. We don't accept licences on the basis of "oh but we will miss out on X possible content". We accept the licences because we are a free content project that offers free content with as few strings attached as possible. There is plenty content with -NC and -ND restrictions, plenty where the photographer would wish for some mythical "Educational use only" licence or a "Wikipedia use only" licence. I've even known a photographer who wished to prevent creationists and socialists from using their photos. If we allowed all those, we'd be overflowing with images to illustrate Wikipedia, but would no longer be a free content project. The "consumer of content" idea Andy suggests is not our mission, and a bit of an odd way of describing the transfer of free images to Commons. There are millions of educational photos, including by large organisations, with -NC and -ND restrictions, whereas there aren't really any off-Wiki websites where GFDL is used for photos. So we already impose a massive restriction on our educational content. The fact that you had to go back 11 years to 2007 to find one example vs all the photos in the British Museum collection with a -NC licence shows this is a bad argument. -- Colin (talk) 14:06, 9 August 2018 (UTC)[reply]
They're not invalid arguments, it's a judgement call. But nor is it an obvious or one-sided one.
I always warn people off using GFDL. But, there is content which has already been licensed as such, and isn't viable to change. A policy change like this would exclude Commons from using such content.
By all means, advise people against choosing GFDL as a new licence - but to forbid it on existing content is to exclude content with a very small tradeoff (unlike -NC or -ND, which are much greater). Andy Dingley (talk) 14:13, 9 August 2018 (UTC)[reply]
I think the tradeoff is actually smaller when comparing to -NC and -ND. For many photos, there is no point in creating derivatives. I think a crop doesn't even count as a derivative, but I'd have to look that up. And most files are never used commercially, so it's not hard to argue that should be accepted as well. But it's not what Commons does.
"but to forbid it on existing content is to exclude content with a very small tradeoff"
Content that is already licensed with the GFDL is not forbidden. To allow people to license existing content (like, old unpublished photos) as GFDL in the future would be arbitrary and create a loophole. - Alexis Jazzping plz15:24, 10 August 2018 (UTC)[reply]
Andy it is an invalid argument and you again make it. There are millions of files licensed -NC and aren't going to change. I don't see you jumping up and down demanding that we start accepting -NC. There are like 3 photos off-Commons licensed with GFDL and probably 2 of those were an accident. Basically nobody uses it for photos apart from a small handful of Austrian anti-free-content Wikipedians. But that doesn't stop trolls recommending to GLAMS that it is a really bright idea. You aren't making a "judgement call" you are setting up a totally false argument that we should keep this license in case Commons loses out on a few images. So please don't keep repeating "would exclude Commons from using such content" because that problem is a rounding error from 0. The real issue is existing Wikipedians who experience has shown will actually use CC licences when they need to (e.g. to get a Commons FP). They just prefer not to. So the effect I see of this is that actually there will be more free content on Commons and fewer users going "Why does this photo of a mountain have a licence that refers to a text computer software manual?" Please point me to the huge collection of GFDL photographs off-Commons that we would miss out on uploading? -- Colin (talk) 17:37, 10 August 2018 (UTC)[reply]
Oppose This makes no sense. Let's say we have two persons A and B, currently A can upload A's (own) work under GFDL and can upload B's work that is uploaded elsewhere and licenced under GFDL; B can similarly do the same. If this proposal passes, these two persons cannot upload their own work, but can still with no problem upload each other's work to the project as long as they first place it within a manual ("You can scan this picture (see pic 1) into Paint and save it with File->Save. The end.") The point is that there are free licences are that not useful for some purpose, what we need is the ability to search for content by the licence and the clear understanding that if the files are licenced differently they cannot be considered duplicates of one another, since for some purposes they cannot be substituted with the other. ℺ Gone Postal (〠✉✍⏿) 21:48, 7 August 2018 (UTC)[reply]
Can you give examples of this actually happening? Commons is probably the only place on the internet where anyone is still uploading images that are GFDL and somehow not CC-BY-(SA). The tiny potential for license incompatibility issues is a much smaller problem than the current abuse of GFDL. Pi.1415926535 (talk) 22:33, 7 August 2018 (UTC)[reply]
(Edit conflict) The manual exception is limited to software logos, diagrams, and screenshots. This wouldn't include photographs, which are the majority of our content. I do see a small loophole for logos and diagrams, but I doubt anyone would actually use it except to troll. We can deal with such rare nonsense case by case. With Commons:Structured data (and even now, with PetScan, though this tool can be hard to use), searching by license will be feasible, but it doesn't solve the problem. I believe if you see something here, you should be able to use it! This is our purpose, the thing that truly distinguishes us from other media-sharing sites. If someone wants to share their content under a license that doesn't allow free reuse, there are plenty of options. Guanaco (talk) 22:42, 7 August 2018 (UTC)[reply]
There are 4 freedoms that are necessary to consider a licence "free", all 4 are there when it comes to GFDL. In the contemporary world, where adding 7 pages is as simple as putting a QR code somewhere these arguments that are presented here are pure nonsense. Nowhere in the licence does it say that the licence must be printed on paper, just that it must be provided. QR would be a reasonable way to add it to something like a t-shirt or a coffee mug. Problem solved. But, of course, it's much easier to make a huge problem out of it and to demand that other people licence their work under different terms. I have had instances when I needed a free image of some cities and I had no way to provide the authorship info at all. If I were to come here ranting and raving and demanding that all the Attribution licences get banned, I would be (rightfully) told to get lost. ℺ Gone Postal (〠✉✍⏿) 04:54, 8 August 2018 (UTC)[reply]
@Gone Postal: the "reasonable attribution" thing from Creative Commons is not a part of the GFDL. It just says:
"You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies,"
In response to "QR would be a reasonable way to add it to something like a t-shirt or a coffee mug", just for kicks-and-giggles, I was going to upload the GFDL license in QR form. Turns out I can't! The GFDL license text isn't licensed as GFDL. Derivates are prohibited, so I can't upload the GFDL QR version to Commons because a license like CC BY-ND isn't allowed here. So I uploaded it to imgur: GFDL 1.2 license text in QR codes. That'll be a fun T-shirt. - Alexis Jazzping plz16:56, 8 August 2018 (UTC)[reply]
@Alexis Jazz: Let's take a look at the image that is actually used in starting this discussion: File:Wedge tail eagle flight Jan13.jpg. From there "[...] any reproduction of this image, in any medium, must appear with a copy of, or full (hyperlinked) URL of the GFDL license [...]" To me this doesn't say "the author is trying to pressure people into using non-commercial licence by making everybody else reproduce pages of text for no reason". The thing is that this boogieman is completely made up. It is possible that somebody somewhere will try to do that, but it is not the reason to stop everybody. ℺ Gone Postal (〠✉✍⏿) 20:22, 8 August 2018 (UTC)[reply]
@Gone Postal: that text is from User:Fir0002/credits. The statement is actually incompatible with the GFDL, I'm not sure this kind of thing is possible. It doesn't really matter, T-shirts and coffee mugs don't support hyperlinks, so even by the somewhat loosened requirements of Fir0002 you'll have to include a copy of the full license text. - Alexis Jazzping plz20:44, 8 August 2018 (UTC)[reply]
A URI linking to a copy of the license isn't itself a copy; it's just a pointer. Compare the full text of CC BY-SA 3.0, which specifically says in section 4(a) that you can either include a copy of the license or the URI for it. clpo13(talk)21:22, 8 August 2018 (UTC)[reply]
But a file name in a directory isn't really a full licence text either, it's just a pointer to something other place on your drive. I think that you are trying to find restrictions in the licence, that would be unenforceable in the contemporary court. I know that we are not talking about the Netherlands, but in there you have a thing called "giggle test", it means that if you can expect people to begin giggling in court room when explaining your argument, then probably it won't fly. You keep bringing up T-Shirts as if that were the main reuser of free images. I believe that it isn't, the main (over 98.37% I would say) reuser would be other websites, and there you have no argument that a link to a licence with the text isn't the text of the licence. Even when Wikipedia used GFDL, they didn't attach the text of the licence to the articles, but rather they had a separate page that was linked to from each article. So even if I grant you that it will be slightly difficult to print the t-shirt it is the very definition of the edge case. Let's imagine that we will have a licence that says that you must provide a full name of the licence, and the licence name will consist of 90 characters and somebody will say "But you cannot fit that neatly into a Tweet", will we have to abandon the licence just because of that? Free licences can and do have restrictions, and if the restrictions are not to your liking, then you select a different work, but you do not make a false claim that the licence isn't free. ℺ Gone Postal (〠✉✍⏿) 04:50, 9 August 2018 (UTC)[reply]
Ok, this issue is steamrolling to succeed. Fair enough, the community does have the right to set limitations. But can we at least agree that this limitation should only apply to images because transmission of the licence is too difficult for them. Video, for example, can first of all just use a few frames to display the licence text, or if that is too difficult it is trivial to place text inside the file itself (in the tags of OGG or as an attachment of WEBM since it is just a slightly changed MKV). ℺ Gone Postal (〠✉✍⏿) 15:09, 13 August 2018 (UTC)[reply]
Video is an even more stupid format. If you broadcast it, you'd have to include all 7 pages of GFDL in your end credits. Embedding the licence as metadata is also unlikely to satisfy anyone since you can't ensure everyone will be able to see it. Honestly, has anyone, in the history of humankind, outside of Wikipedia, ever created a GFDL-licensed video? Other than if extracted from a GFDL software manual, there is zero good faith reason for anyone to use GFDL on Commons for any media. The only people using it are doing so in order to try to restrict usage outside of Wikipedia. And that's not really what we're about. -- Colin (talk) 15:23, 13 August 2018 (UTC)[reply]
And here's another thing. You cannot say on one hand that GFDL is a non-free licence and then argue for grandfathering old images. If GFDL is not free and we cannot find the author to get them to relicence, then we must delete those images. Commons is a repository of Free Content and the licence either falls within that category or not, and it matters not what date of the publication was. ℺ Gone Postal (〠✉✍⏿) 18:08, 20 August 2018 (UTC)[reply]
Support GFDL is fundamentally unsuited for the vast, vast majority of images on Commons. Those who are using it to upload their own photos are going against the spirit of Commons. Pi.1415926535 (talk) 22:33, 7 August 2018 (UTC)[reply]
Support I think that GFDL is actually unfavorable for even use on Wikipedia articles. If I want to legally print and distribute a single article with a GFDL image, I have to print seven more pages per copy. This increases my printing costs and can make my small pamphlet excessively bulky. The basic principle of COM:L is "Wikimedia Commons only accepts free content, that is, images and other media files that are not subject to copyright restrictions which would prevent them being used by anyone, anytime, for any purpose." I understand there are nuances and technicalities always, but if copyright restrictions make something unsuitable for most purposes, how can we call it free? Guanaco (talk) 22:42, 7 August 2018 (UTC)[reply]
I agree with the spirit of this proposal but I have to ask. If as you say "The main issue with GFDL is that it requires re-users to include 7 pages of text, which is generally not practical for individual pictures, video or audio. Because of this, this lead to the existence of ... a backdoor Creative Commons Attribution-NonCommercial license. After all, nobody is going to include 7 pages of text." With the way FAL (Free Art License) is written "You can make reproductions and distribute this license verbatim (without any changes)." How is an FAL license any different from a GFDL in this problem? -- Sixflashphoto (talk) 23:52, 7 August 2018 (UTC)[reply]
@Sixflashphoto: That quote is from the end of the license, authorizing verbatim copies of the license itself. For FAL-licensed works, a link to the license text will meet the requirement. See Section 2.2 and the user guide. Guanaco (talk) 00:01, 8 August 2018 (UTC)[reply]
Support Ah. I originally saw that as applicable to the work under the license not necessarily the license text. 2.2 cleared that up, "...or indicate precisely where the license can be found". Thanks, easy support -- Sixflashphoto (talk) 00:17, 8 August 2018 (UTC)[reply]
Oppose. It makes no sense to oppose a particular license by name when it meets the requirements of Commons:Licensing. Anyone can just rename the GFDL to something else and carry on as before, or create a similar license of their own devising. Instead, Commons:Licensing would need to be changed to reject all licenses that have the aspects considered undesirable. --ghouston (talk) 06:17, 9 August 2018 (UTC)[reply]
@Ghouston: you can't rename the GFDL. The license text is protected by copyright and derivatives are forbidden. (the GFDL license text is not licensed as GFDL) As far as I know, you also can't just create valid licenses yourself on Commons. - Alexis Jazzping plz06:35, 9 August 2018 (UTC)[reply]
You may be right about renaming the GFDL. But Commons accepts any license that meets Commons:Licensing, as far as I know. There are various custom templates for particular wordings used by institutions. --ghouston (talk) 06:37, 9 August 2018 (UTC)[reply]
Commons:Licensing will be changed anyway as it's currently discouraging using GFDL for images. As far as I know (but I'm not 100% sure because I never tried to create a license), a new license needs to be marked as such by an administrator before the system will recognize it as a valid license. This proposal also doesn't rule out making changes to Commons:Licensing, but let's try to do one thing at a time. - Alexis Jazzping plz06:53, 9 August 2018 (UTC)[reply]
Commons:Licensing just mentions the need to be a free license, in line with http://freedomdefined.org . By this logic, we should disallow GPL works too, but we often find useful images in software packages in the wild which are licensed that way, and allow those. If we find something GFDL out there, we could still allow uploads. And yes technically, someone could create their own license, and if meets the "free" requirements, we would allow it. The GFDL, and GPL, are and would remain free licenses. It would be interesting to see if a court would upload the must-include-license-text requirement if a possible infringement came down to that issue -- probably not a guarantee. But, it is aggravating that people do upload works based on that particular provision of making it hard to re-use -- it is against the spirit of the site and the "free" concept. I won't vote either way on this, as unsure if this is a good idea. On the other hand, would prefer to still be able to upload GFDL/GPL works if they occur naturally elsewhere, as they are still free licenses. Carl Lindberg (talk) 01:16, 15 August 2018 (UTC)[reply]
Indeed. GFDL was never intended for use with images. Instead, FSF "designed this License in order to use it for manuals for free software, because free software needs free documentation... But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference." (v. 1.1 and later) De728631 (talk) 07:24, 9 August 2018 (UTC)[reply]
Please note, that this proposal is not about recommending that somebody uses Free Art License, I use this licence myself and I advice most people to use it for their photographs or other images. I don't think that you would get any arguments against recommending such a thing. Unfortunately this proposal attempts to make it impossible to upload a subset of free images here because the licence is not recommended. Imagine that for anything else and you will see how ridiculous it is. ℺ Gone Postal (〠✉✍⏿) 14:34, 21 August 2018 (UTC)[reply]
Support but wish this had been discussed before a poll opened. Commons:Requests for comment/AppropriatelyLicensed tried to avoid the issue Ghouston raised about other licences (though, truly, nobody is going to rename GFDL to avoid policy, and if they did, I reckon that would be fairly clear grounds for a block, on a website dedicated to free content). The GFDL explicitly licenses "textual works" and not appropriate due to the embedded license text condition. There is a risk someone might turn to GPL, which is even less suitable for images as it refers to "executable code". It is worth noting that the only people using "GFDL only" licences for photographs are those who deliberately wish to prevent their images being used off of Wikipedia. For what it is worth, User:Eloquence who helped found Commons and write The Definition of Free Cultural Works, also supported the earlier attempt to restrict GFDL: "GFDL is a silly license to use for a media file". A question was made about about "Are multiple wiki communities aware". They don't need to be. This is a decision for Commons. English Wikipedia, say, could continue to accept images with such licences if it wishes to do so. -- Colin (talk) 07:47, 9 August 2018 (UTC)[reply]
Comment Thank you to clpo13 and De728631 for referencing my blogpost, written a long long time ago and still very much portraying the opinion I hold today. I just wanted to point out that the title of this poll may be a bit misleading, as the proposal is much more focused than No longer allow GFDL for some new uploads and really is about No longer allow GFDL ONLY for new uploads, if I understand it well. -- notafish}<';>09:58, 9 August 2018 (UTC)[reply]
If there had been a discussion, we could have ironed out these wrinkles. All that is needed is to say that GFDL is no longer a valid licence for X kinds of images. Users have always been able to add as many invalid licences as they wish but must include at least one valid licence. So focusing on "alone" or "only" is potentially confusing if a user uploads with "GFDL & CC BY-SA-NC-ND". Also don't see any need for a one month grace period, which would just give those affected by the decision a month in which to moan about it. They know what they are doing, and don't need any help transitioning. -- Colin (talk) 10:08, 9 August 2018 (UTC)[reply]
@Notafish: I initially misread what you said: "No longer allow GFDL ONLY for new uploads" as "No longer allow GFDL, but ONLY for new uploads" but you probably meant "No longer allow GFDL ONLY-licensed files for new uploads". Either way, it's not correct. Uploading/licensing software manuals and textbooks with only a GFDL license will still be allowed. So you could read the title as "No longer allow GFDL [as a valid license] for some [only files that meet the requirements] new [existing files are not affected] uploads". But the more you turn such things into a legal document, the harder they get to read.
@Colin: so let them moan. At least on enwiki the bot(s) that automatically tag(s) files to be moved to Commons will need some adjustment. (or alternatively, they need to pass a similar proposal) The grace period doesn't really hurt but does address some worries that might exist otherwise. Better to have and not need than to need and not have. - Alexis Jazzping plz16:52, 9 August 2018 (UTC)[reply]
Oppose As for Carl Lindberg. This proposal has strong bias. If the GFDL shall be banned, we need to change Commons:Licensing. Btw: the GFDL license text does not need seven pages printed, it fits perfectly readable to one page A4. The conditions for mobile phone contracts are generally much less readable and will be accepted at any time. We can not ban a license from commons which is considered "free" according to commons:licensing only because it is somewhat unhandy. CC-BY-SA and FAL are also rather unhandy (at another level), because they are viral. Are these to be banned in a next step, because someone feels they are unwieldy? You will already find many voices among professional (re)users who strongly advise against using images from Commons. But this has nothing to do with the licenses used, whether GFDL or any other licenses permitted here, but with contributors who use the platform "commons" for their business. But these contributors will continue to do so also with cc-by-sa et al. GFDL is a perfectly free license, and this proposal is simply not the right place and right way to tackle a problem that is social in nature. --Smial (talk) 10:43, 15 August 2018 (UTC)[reply]
First: this proposal is not "banning GFDL" by a long shot. Text, existing files and some other things are not affected. Changes to the wording of COM:L may be considered in a future proposal. CC BY-SA and FAL are not being discussed here, that is a slippery slope argument. Limiting the use of BY-SA and FAL would require another proposal, which would have a snowball's chance in hell of being passed. This proposal is merely dealing with a license that is actively being abused as a CC BY-NC backdoor. For the number of pages I simply clicked "Printable version" on this page. You could print the entire license on a postage stamp if you had a really good printer, but that's not the point. - Alexis Jazzping plz05:23, 21 August 2018 (UTC)[reply]
But what is the point of this proposal. It first starts by saying "GFDL is not a free licence in some cases", but then it says "but we should still allow old files". But if it is not a free licence, then we shouldn't. Before CC-BY-SA there were things like CC-SAMPLING for short clips of audio from copyrighted music. We wouldn't allow even a very old file under that licence, because it is not free. So the question is: Is GFDL free or not. Not even the original proposer can answer that simple question. If we determine that it is not free, then we cannot keep old files, because that goes against the very spirit of the project. But the truth of the matter is that no matter how much somebody doesn't like GFDL and how much it is not suitable for some people, it is non-the-less a free licence. Do I use it for my uploads? No, of course I do not. Would I ever use it? Maybe if it were a document or if I were to write a book or something like that. You are saying that limiting FAL (that I do use) would "have a snowball's change in hell of being passed", but when I read the discussion about GFDL banning just 5 years ago it is clear that it had no chance of being passed then either... look at what is happening today. People are saying "I don't use it, I don't like it, so nobody should be using it". ℺ Gone Postal (〠✉✍⏿) 06:55, 21 August 2018 (UTC)[reply]
That's my point, thank you. In fact, if you consider future uploads with the GFDL as only free license as illegal, you must consider existing files with this licensing also illegal. Btw: I use "GFDL 1.2 only" as an additional option to offer compatibility with old works or documents that use this old GFDL. None of the other licenses allowed on commons supports this. --Smial (talk) 13:23, 21 August 2018 (UTC)[reply]
That "illegal" argument seems to confuse community policies with laws. Besides, grandfathering is a thing in legal situations too. And per the below, offering "GFDL 1.2 only" as an additional option will remain possible. Regards, HaeB (talk) 23:35, 26 August 2018 (UTC)[reply]
If I understand correctly, dual-licensing (i.e. {{Self|GFDL|CC-BY-SA-3.0}}) will be fine (after the turnover), right? If yes, this proposal is fine to me. — regards, Revi15:09, 15 August 2018 (UTC)[reply]
Yes. In fact, multi-licensing Copyleft licenses with other non-compatible Copyleft licenses including non-commercial license is good and encouraged as it will give more adaptation opportunities. Otherwise works with different non-compatible Copyleft licenses (like CC BY-SA and GFDL) can't be mixed in adaptions. Jee02:53, 16 August 2018 (UTC)[reply]
@-revi: Correct: "And a dual license like CC BY+GFDL is also no problem". Jkadavoor is also correct, you can add any number of nonfree licenses to your files, provided you offer at least one free license. GFDL is now often combined with CC BY-NC which is not free either. You could also combine, for example, CC BY-SA (free) with GFDL and CC BY-NC. Non-commercial derivatives wouldn't have to be shared alike in that case. - Alexis Jazzping plz05:23, 21 August 2018 (UTC)[reply]
Oppose per Smial. Also where do we stop with removing licenses that are considered as "restrictive" by some in the community, there has been a lot of FUD regarding GFDL over the years. Bidgee (talk) 01:48, 22 August 2018 (UTC)[reply]
Even though the question wasn't for me, I can answer this. Anything that says that GFDL is not a free licence is FUD by definition. You could say that it's not the best licence for some cases, and you would be correct, but anybody who compares it to non-commercial or other proprietary licences is either seriously mistaken or is lying. In order for the licence to be considered free, it must insist allow 4 general freedoms (and hopefully insist on keeping those 4 freedoms down the line): Freedom to use, Freedom to adopt, Freedom to copy, Freedom to distribute altered versions. Nothing there says that there cannot be any restrictions on those freedoms (otherwise only CC0, CC-PD, WTFPL would be "free"), and GFDL places restrictions reasonable within most contexts. ℺ Gone Postal (〠✉✍⏿) 11:35, 11 September 2018 (UTC)[reply]
Are you suggesting that people uploading work that they created under a free licence is a "longstanding problem"? ℺ Gone Postal (〠✉✍⏿) 11:37, 11 September 2018 (UTC)[reply]
Support Nobody that wants to use the free content should have to deal with the GFDL License terms. They are hopelessly outdated for free content. Best regards --Neozoon (talk) 19:51, 27 August 2018 (UTC)[reply]
Support I would go further and disallow homebrew licenses. I support limitations on licensing for Wikimedia Commons, and think that files in Commons must have community-approved licenses. In the past it was not certain whether Creative Commons licenses would be popular and so we wanted to leave options open for other organizations to establish licenses. Also we wanted to be open to many individual organizations making their own licenses. As it happened, Creative Commons became a market leader and has defined the thought on free and open licenses for media. I do not mind files having additional licenses tagged just so long as those licenses can be overlaid with a Creative Commons license. Licenses which are less free than the standard Wikimedia Commons choice of Creative Commons license are a problem and we ought to discourage them now and prohibit them soon. We get great advantages from having a body of compatible licenses. GFDL is not intended for media. Various other homebrew licenses are often applied in error or to the confusion of users. Wikimedia Commons does not benefit from permitting endless odd experiments in licensing. Blue Rasberry (talk)21:20, 10 September 2018 (UTC)[reply]
This section is resolved and can be archived. If you disagree, replace this template with your comment. The proposal has wide support, and there is no active debate on the core proposal. I am closing this as successful, and I have updated Commons:Licensing to include the new rule, effective 15 October. Guanaco (talk) 07:56, 14 September 2018 (UTC)
Upload Wizard feedback
I have just uploaded 70 or so shots using Upload Wizard. The tech boys have done a great job- with respect can I add a few thoughts for improvements.
On the select images to upload button- could we also just drag and drop selected images on the button as well as directory select.
on a shakey line- the tab crashed while I was adding description- Firefox asked did I want to reload the tab?- obviously yes- and I am thrown back to the adding images page (where I was 40 minutes earlier)! Could we tweak the code so I am thrown back to where I was on the description page. It was a bad line. I made the same mistake by attempting to refresh the page to display some images that weren't thumb nailing.
now a bigger one- I use shotwell as an image editor- could we add the facility to add simple image editing facilities to the wizard- crop, straighten principally or a link out to our favourite editor.
Watch the blocked user's user talk page and ensure that requests for unblock are attended to.
”
I propose an amendment that these points are not mandatory for any account of a known or evident serial abuser where this account has no positive contributions on Commons. “Accounts of a serial abuser” include (but are not limited to) those globally lockable by stewards as LTA (long-term abuse) or similar reasons.
Many sysops don’t follow these procedures wrt sock puppets for many years. For block-evading vandals I deem {{Indefblockeduser}} or similar unnecessary, since such worthless accounts only clutter categories, hindering possible review or research. Incnis Mrsi (talk) 07:43, 12 August 2018 (UTC)[reply]
I support the general point made, that all blocked accounts should receive a user block template which advises why the block has happened and how to appeal. It is less important that an administrator is required to watch the user page, however there has to be a system to ensure that appeals are not overlooked by accident. I disagree that accounts which are thought to be run by a LTA may opt out of having a formal notice or an appeal process, regardless of who is doing the blocking or the evidence, there are many years of evidence showing that accidents and misunderstandings have often lead to wrong accounts being caught up in an anti-spam or anti-sock campaign. --Fæ (talk) 08:17, 13 August 2018 (UTC)[reply]
First of all, it is indeed important that “an administrator is required to watch the user page” – it discourages some of them from hiding behind others’ backs. Misidentifying an account as a “known or evident” LTA must be qualified as a sysop error. Where your data about frequency of this kind of error come from? If a sysop has too bad judgement wrt blocks, then is it not a problem specific to user_talk. Of course, you can pick several purely accidental mishaps off myriads of LTA blocks, but would it be a significant problem in the context of where this account has no positive contributions on Commons? This and this are excluded by a huge margin. It is a very low-probability misfortune for a good-faith user to have his/her account identified as LTA before any positive contributions appear. And even in this case an appeal is still possible (Meta-wiki, posting as an IP, Email…). Incnis Mrsi (talk) 11:09, 13 August 2018 (UTC)[reply]
A long time ago I was on a forum and I got angry and wrote whole bunch of mean things repeatedly, in the morning I realised that I probably have overreacted, but was not able to even contact anybody to tell them that I apologise for this occurrence. I know that here you are distinguishing a single act of anger from the "long-term" abuse, but often these things tend to be left to interpretation. Sometimes I see that people equate abuse to uploading media to a category that others consider well saturated (categories of sunrises, roads, body organs... especially sexualised ones, etc). So a person who is honestly trying to contribute may easily be first threatened with the block, and after that individual (quite rightly, in my opinion) will decide to just move on and not engage is flame war and simply continues uploading content can be blocked with no way to even demand the explanation or ask how to upload educational media differently. Now with sockpuppets or throw-away accounts the issue is quite different, but then again, is there really no way somebody can be mislabeled as a sock? ℺ Gone Postal (〠✉✍⏿) 09:37, 13 August 2018 (UTC)[reply]
I don’t understand how this forum memoir is relevant. Again, the amendment is not about “abusers” in general, but about 1) serial abusers, 2) accounts thereof having no positive contributions. Also see my comment above. Incnis Mrsi (talk) 11:09, 13 August 2018 (UTC)[reply]
Did you read past the first sentence? Because you have simply written the first part of my second sentence in different words. ℺ Gone Postal (〠✉✍⏿) 15:54, 13 August 2018 (UTC)[reply]
Oppose, the term "long-term abuse" has no actual meaning and every user (except for those banned by the Wikimedia Foundation) should be able to appeal or at least understand why they're blocked and how and where they can appeal. I agree with Gone Postal 📯 about the mislabeling, in fact a good faith user who uploads aviation related images could be mislabeled as a Russavia sock (something INeverCry did a lot in their day). Maybe we should split the categories and create "Category:Commons sockpuppets blocked in August 2018" for example to make sure that "main account" categories don't get overpopulated. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 20:44, 20 August 2018 (UTC)[reply]
@Donald Trung: indeed, the bulk of blocked accounts—on Commons or elsewhere—pertains to sock puppeteering (including a common block evasion). Again, the proposal is not about puppets in general, but serially manufactured vandalistic filth. Incnis Mrsi (talk) 07:38, 31 August 2018 (UTC)[reply]
No longer allow OFL as the only option for symbol-only uploads
While the community is bending backwards trying to prove to itself that GFDL is unfree we apparently have absolutely no problems allowing Open Font Licence (text here). This licence in its preamble clearly states "The OFL allows the licensed fonts to be used, studied, modified and
redistributed freely as long as they are not sold by themselves" and then the condition section repeats that limitation "Neither the Font Software nor any of its individual components, in Original or Modified Versions, may be sold by itself." As such it is a non-commercial licence when used for font elements (which it often is).
Now I do not argue that the images should be outright deleted. Some of them (for example File:Libertine sample.svg and File:Blason ville fr Laurac-en-Vivarais (Ardèche).svg]) are also available under the free licence. Some of them are quite complex images simply utilising elements of the font and licencing the font as a part of the whole, in such case it becomes the same argument as COM:DM or COM:Stamps, where some of the individual elements maybe non-free but the work as the whole is non-the-less free. However, images like File:Font Awesome 4.7.0 icons.svg where the only licence is {{OFL}} and the only content is actually the presentation of the font would be disallowed.
I propose to add the following text to the licence template: "Note: This licence is for the font within the work and does not apply to the work as the whole. OFL is a non-commercial licence and you are not allowed to extract the elements of the font for the purposes of using them if you intend to use them commercially. The work as the whole must also provide its own licence."
You can sell a software package that includes the font according to OFL's FAQ.
Why won't the OFL let me sell the fonts alone? Because "the only people who ought to profit directly from the fonts should be the original authors" according to OFL's FAQ.
Some people consider that GPL'd software itself cannot be sold, either. In this article, the author thinks "you can charge as much as you want for distributing, supporting, or documenting the software, but you cannot sell the software itself". --Tomchen1989 (talk) 10:01, 19 August 2015 (UTC)[reply]
Do we even allow direct uploads of fonts? Pretty sure we would only have usages of those fonts in other works, so not sure those usages would matter either way for that clause of the license. And if that many other organizations think the license is free, not sure we should be different. Carl Lindberg (talk) 17:20, 2 September 2018 (UTC)[reply]
There is a big difference between a working font and a collection of glyphs extracted therefrom. Selling a graphic that uses a font, or even a complete specimen, is not selling the font: none of the ‘machinery’ is included that selects & positions the characters, and would optimize their rendering on a device in which the font is installed. Fonts are generally considered a form of software, which I would argue is out of scope here. (But it would be great if the WMF had better font support on the SVG-rendering servers, in both breadth and depth, so to speak.) Even commercial fonts usually allow embedding of their output in other works, such as PDF documents. At any rate, I think a limitation that applies solely to ‘live’ fonts is irrelevant here.—Odysseus1479 (talk) 04:04, 9 September 2018 (UTC)[reply]
This template takes one parameter - the page that has been re-uploaded. In general, most of the time I find that the uploader will change the file name (obviously in the hope that it will be missed...). I would like to suggest that it be changed to have a second (optional) parameter (the original file name), so to remind the user what the page was called, and suggest he requests undeletion of the original. So for example one would post {{subst:dont recreate|File:Martin Poch.jpg|File:Martin Poch (2017, foto Jana Plavec).jpg}} to the user's talk page Ronhjones (Talk)19:51, 28 August 2018 (UTC)[reply]
Based on that discussion, I think the only reason empty categories should be speedily deleted is if they (a) were created by mistake; (b) they are abusive; (c) are obviously and unquestionably incorrect; (d) are vandalism or used only for vandalism; or (e) the sole author requests deletion and the category hasn't been used by others. These situations are all covered by other criteria (a) is G1, (b) is G3 (c) is C2, (d) is G3 and (e) is G7, so there isn't a need for a separate criterion. What is and is not an "Unuseful" category in other circumstances can only be determined by a discussion. So repeal speedy deletion criterion C3 entirely. Thryduulf (talk) 12:12, 12 September 2018 (UTC)[reply]
Oppose: a) It's not a hard job to re-create a deleted category if it is needed. b) An unuseful category had to be defined exactly and that would take a long time I think. c) It's an illusion to discuss the deletion of an empty cat, look at the CfD and DR backlogs. My 2 cents --Achim (talk) 19:50, 12 September 2018 (UTC)[reply]
Allowing cross-namespace redirects from (Gallery)/(Main) to Category
I've been informed that cross-namespace redirects are not allowed on Commons (tho I can't seem to find the documentation). Even if we want to have that as a rule generally, I think a big exception should be from the main/gallery namespace to the category namespace. Since we mostly use categories here and have only a fraction of images as galleries, it will be very useful for incoming links and search until such time as we really populate that namespace in earnest. I think this has high value and I don't see any immediate downsides. What does everyone else think? —Justin (koavf)❤T☮C☺M☯03:21, 9 September 2018 (UTC)[reply]
Support, I actually wanted to propose this myself a couple of months ago but got distracted by other projects. It would be very handy if mainspace pages could direct to categories as it would make searching a lot easier, and this would also allow for names in different languages to be redirected to the same subject. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 12:22, 10 September 2018 (UTC)[reply]
Comment If you ask me: move all galleries to a dedicated Gallery: namespace and automatically redirect the "main" namespace to Category:. --El Grafo (talk) 11:53, 12 September 2018 (UTC)[reply]
Support per nominator. In addition cross-namespace redirects between Commons: and Help: namespaces should be freely permitted as there is overlap between them (see for example the location of pages in Category:Commons help). Thryduulf (talk) 23:34, 12 September 2018 (UTC)[reply]
Support per nominator. There are times that a simple gallery is best replaced with a category, but we should possibly still prefer incoming links go to the gallery page until such time that a better curated gallery is made. Carl Lindberg (talk) 01:28, 13 September 2018 (UTC)[reply]
Oppose - it gives the false impression that a gallery page exists. Also, allowing this would cause a situation in which random pages redirected to categories. If we want non existing gallery pages to link to the category, we should request a software change instead. Either all non existing gallery pages should redirect to the category or none. Jcb (talk) 15:54, 13 September 2018 (UTC)[reply]
Comment My first choice is to redirect all non-existent galleries to the category, if the category exists, per Jcb. If the developers tell us this isn't feasible, I'll support this proposal to allow redirects. Guanaco (talk) 00:52, 14 September 2018 (UTC)[reply]
It's my belief that categories are there to assist users in finding media we host. So it should be a given that users should find media where they expect to. However, we seems to have inherited a system from en:WP of default sorting churches and pubs by location first, then name. So "St Bernard's church, Sometown" is defsorted so that it appears under "S" rather than "B" (obviously sorting under "St" is unhelpful because most would then sort under "S", which would be overwhelmed and thus useless). Similarly, "The King's Arms, Anytown" appears under "A" rather than where a user would expect to see it, i.e. under "K" (Again, "The" is redundant). There is one user who persists in perpetuating this error, as I see it, claiming that "it's the way it's always been done" is a taxonomically valid reason for the current system. So my proposal is this:
Churches and public houses in the United Kingdom should be sorted by name first, then location, except where the name is part of the category, in which case sorting by location is used..
I realise it may take some time to correct this error, but I don't see that as a reason for not doing it, as I'd prefer to get things right than confound our users, and I invite all to participate in a straw poll to determine consensus. Rodhullandemu (talk) 08:32, 10 September 2018 (UTC)[reply]
Technical proofment from Wiki Commons Category (used as url) to Wikipedia
I suggest that a categegory should be checked in Wikipedia automatically before someone (admins) edit or erase the category in Wiki Commons.
Picture galleries in Wikipedia (|Commonscat=) needs a category, other possibility seems to generate special category (maybee hidden) or marks
the commonscat (with colour) to seperate them from only text based material. Otherwise nexus and the function will get broken.--Hans-Jürgen Neubert 12:20, 12 September 2018 (UTC)(talk)
Hans-Jürgen, I'm sorry but I didn't get it. Question: Meinst du, dass überprüft werden sollte, ob eine Commons-Kategorie von Wikipedia aus verlinkt ist, bevor sie auf Commons gelöscht bzw. umbenannt wird? --Achim (talk) 19:58, 12 September 2018 (UTC)[reply]
Exactlyǃ Genau das... siehe hier als ID-Beispiel "D-5-73-134-60"
Die meisten Anwender suchen in Wikipedia (Reader, read only), nicht Commons. In Commons werden hingegen die Zusammenhänge von den Bilderlieferanten (Quelle und Ziel) erstellt (Writer). Ein admin kann auf wikicommons anscheinend bisher nicht erkennen ob der Inhalt in wikipedia bereits genutzt wird.
Er müsste bei Änderungen beide Seiten bearbeiten, erst die auf commons, dann in Wikipedia und zumindestens die Material-Galerien snchronisieren.Es geht hier nicht um "leere" Kategorien (was ja gar nicht möglich ist) und auch der Hinweis "the only contributor" macht logisch keinen Sinn, einer muss ja anfangen. --Hans-Jürgen Neubert 20:19, 12 September 2018 (UTC)(talk)
This section is resolved and can be archived. If you disagree, replace this template with your comment. Guanaco (talk) 00:59, 14 September 2018 (UTC)
Support as I propose these templates. Thanks to De728631, Maile66, and Clpo13 for your help with approach, content input, and formatting. CaroleHenson (talk) 00:40, 13 July 2018 (UTC)
Comment The actual blocking text, not the template that is slapped on the talk page, can be found here: MediaWiki:Blockedtext. In case anyone also wants to take a look at that. --Majora (talk) 00:51, 13 July 2018 (UTC)
Oppose I see no need at all to change the current templates. Status quo is perfectly fine. --Steinsplitter (talk) 10:43, 13 July 2018 (UTC)
Strongly oppose
Weak support But only if we find some sensible limits. I do agree that bot uploads can and should be monitored more closely than personal uploads because they have the potential to do more damage, but they also can improve something (there was a reason why such tools were created in the first place). ℺ Gone Postal (〠 ✉ ✍ ⏿) 19:12, 1 August 2018 (UTC).jpg)
.jpg)
Neutral Probably some kind of restriction of Flickr2Commons would be a good idea, but not necessarily the proposed solution. I do think that we're getting quite a lot of problematic files from flickr. Gestumblindi (talk) 00:41, 11 September 2018 (UTC).jpg)
.jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.jpg&diff=next&oldid=314619165){kind=link}
.jpg){kind=link}
.jpg){kind=link}
.jpg&action=edit&redlink=1){kind=link}
.jpg){kind=link}
.jpg){kind=link}
Info FWIW, there was a similar proposal, 2 years ago --Zhuyifei1999 (talk) 09:25, 7 August 2018 (UTC)
.svg){kind=link}
Question: Meinst du, dass überprüft werden sollte, ob eine Commons-Kategorie von Wikipedia aus verlinkt ist, bevor sie auf Commons gelöscht bzw. umbenannt wird? --Achim (talk) 19:58, 12 September 2018 (UTC)