Commons:Village pump/Proposals

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search
Community portal
introduction
Help deskVillage pump
copyrightproposalstechnical
Administrators' noticeboard
vandalismuser problemsblocks and protections

Shortcut: COM:VP/P · COM:VPP

Welcome to the Village pump proposals section

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

COMMONS DISCUSSION PAGES (index)


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

 

Give autopatrolled users more upload options[edit]

PROPOSAL PASSES:

The extended uploader right will be depreciated and all those with that right will be granted autopatrolled (if they do not already have it). The autopatrolled user group will gain the upload_by_url flag and the filter will be updated to allow autopatrolled users to upload .MP3 files. --Majora (talk) 02:58, 17 January 2019 (UTC)

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.

Note: this proposal depends on phab:T89131 (implement server side Flickr reviewing). If accepted, it will not be implemented before {{FlickrVerifiedByUploadWizard}} has been replaced/complimented by {{flickrreview}} and/or MediaWiki is given the ability to perform server side reviewing. They are, in a way, waiting for us. If we accept this, T89131 won't take long.

The actual proposal is below the intro, you can skip the intro if you already know what this is about.

Intro/background[edit]

Extended uploaders is a user group for users who are trusted with the following:

  • Uploading files from a URL (limited to this whitelist)
  • Uploading MP3 files (regular users need to convert their MP3 files to Vorbis, Opus or FLAC before uploading, a process in which quality is lost for Vorbis and Opus)
  • Uploading files from Flickr using UploadWizard (nothing you couldn't do without Extended Uploader, it's just more convenient.. not to mention Flickr2Commons)

There are currently 67 extended uploaders. From those, only 3 (three) have ever uploaded more than 6 (six) files from Flickr using Upload Wizard: Koavf (39 files), GreenMeansGo (45 files) and Ixocactus (79 files). You will understand in a moment why that's important.

But first, let's think about autopatrolled users. Autopatrolled users (we have 5953 of them right now) would be deemed smart enough not to upload albums from Madonna and Robbie Williams. Else they wouldn't be autopatrolled. So allowing autopatrolled users to upload MP3 files, I don't see why not. Uploading files from a URL, with the whitelist restriction which is already in place, has minimal potential for abuse. Even less so for autopatrolled users.

Leaving one thing: uploading files from Flickr using UploadWizard. There has been some controversy around Flickr2Commons with some users suggesting to put a ratelimit on Flickr2Commons. Which didn't happen. But for Flickr import using UploadWizard, I will include an option for that. This is why I had to tell you about the three users: if we decide to do this with a ratelimit, only three users will be somewhat affected. And even they probably won't notice if we don't pick some extremely low number.

On to the votes. If there are not enough supporters for this proposal without ratelimit, we will see if there is enough support with a ratelimit. - Alexis Jazz ping plz 10:31, 9 December 2018 (UTC)

The actual proposal[edit]

Allow all autopatrolled users to upload files in MP3 format, upload files from a whitelisted URL and upload files from Flickr using UploadWizard.

Support, with or without UploadWizard-Flickr-specific ratelimit[edit]

Support, with UploadWizard-Flickr-specific ratelimit, don't forget to include a maximum number of UploadWizard-Flickr uploads per minute![edit]

  • (none yet)

Leave everything as it is (oppose)[edit]

  • (none yet)

Discussion[edit]

Umm...Not particularly fond of the idea of extending the Flickr url upload until its fixed. Did we ever figure out why you have to button mash the upload button and get 9000 license review errors when you do? It was still broken as of 6 December. GMGtalk 12:12, 9 December 2018 (UTC)

Or maybe opening it up to lots of people will give an incentive to actually fix it? GMGtalk 12:14, 9 December 2018 (UTC)
@GreenMeansGo: the abuse filter has been fixed for extended uploaders by Kaldari on 6 December. Replacing/complimenting {{FlickrVerifiedByUploadWizard}} with {{flickrreview}} is not technically complicated, and if this proposal is accepted there will be a clear incentive to patch it. - Alexis Jazz ping plz 16:49, 9 December 2018 (UTC)
Okay. Well, as long as we're not getting a zillion files that need fixing, or a zillion comments from people who haven't figured out yet that if you just button mash you can bypass the initial error you get. (I now realize why no one on wiki or on IRC knew the answer to the problem, because only three of us have ever actually used this feature apparently.)
I'm still a little wary about MP3s though. From the perspective of monitoring latest files...yeah...if someone uploads Aaron Copland...obviously that a copyright violation. If someone uploads whatever is on Tamil or Mandarin radio, there ain't no google image search for that. GMGtalk 17:28, 9 December 2018 (UTC)
When UploadWizard adds {{flickrreview}}, nobody will get any error. And there are actually more people who use the feature, but they are license reviewers and administrators. So they never got any error. As for MP3s: it's still only autopatrolled users. And any user (even without autopatrol) can upload .ogg, .opus, .wav and .flac. We just use the description, license, source and have people who understand the language look at it. If somehow huge problems arise (which I don't believe) that can't be solved by taking the autopatrol status for problem users away, another proposal to take MP3 away again will be here soon enough, I'm sure. - Alexis Jazz ping plz 18:27, 9 December 2018 (UTC)

Not sure how you got your stats. I am convinced I have used the upload wizard to upload from Flickr albums. -- (talk) 13:34, 11 December 2018 (UTC)

@: so have several administrators. You are not listed as an extended uploader, therefore you are not in the stats. - Alexis Jazz ping plz 23:41, 11 December 2018 (UTC)
Oh, I vaguely remember the discussion where this was created, but I no longer remember the logic of why I am not an extended uploader and presumed I was one. Can't keep in all in my head. :-) -- (talk) 00:01, 12 December 2018 (UTC)

So just to be clear on what is being proposed here. The following flag is going to be added to the autopatrolled user group, upload_by_url as well as modifying the abuse filter to include autopatrolled. Just so you know, flickr is already included on the upload_by_url whitelist so granting that flag should allow that ability via the upload wizard. If this passes, what then would be the point of the extended uploader group? Really the only specific flag that is granted by that group is the upload_by_url and the abuse filter exemption. Both of which are being proposed here to be added to the autopatrolled group. Therefore, this proposal would make extended uploaders obsolete. Correct? --Majora (talk) 22:39, 13 December 2018 (UTC)

@Majora: absolutely 100% correct. The original title (which I changed before publishing) was something like "Make all autopatrolled users extended uploaders". But stating it so bluntly directly in the title without any nuance didn't seem quite right. And there is the option of supporting this proposal with a ratelimit, that could technically be a difference for extended uploaders who wouldn't have that limit. Although only three users (Koavf, GMG and Ixocactus) would realistically be somewhat affected.. and two of them have already supported the proposal.
Another thing (well, related): does what you say mean that anyone who has upload_by_url has the "Share images from Flickr" button? Who else (that isn't a license reviewer) has upload_by_url? Gwtoolset I guess? - Alexis Jazz ping plz 01:57, 14 December 2018 (UTC)
@Alexis Jazz: It is my understanding from a cursory look at the extension that yes, anyone with the upload_by_url flag should have the "share images from Flickr" button. Per Special:ListGroupRights, image reviewers, bots, extended uploaders, GWToolset users, and administrators have that flag. If this proposal comes to pass I really don't see the need to have two user groups that have the same basic function so retiring extended uploaders would probably be for the best. --Majora (talk) 19:32, 14 December 2018 (UTC)
@Majora: I noticed you didn't vote. You don't have to, obviously, but I'm curious how you feel about this proposal. If you see any particular issues, I could perhaps work on that. - Alexis Jazz ping plz 17:51, 10 January 2019 (UTC)
I'm pretty neutral on the idea to be honest, Alexis Jazz. I don't see any problems with this but I also really don't see the need to collapse user groups either. Sorry, I just don't really have an opinion on this one either way. --Majora (talk) 21:43, 10 January 2019 (UTC)
@Majora: a major issue (that keeps popping up) is the state of Flickr2Commons and its lack of maintenance. I think this is the third time it has recently been proposed to disable Flickr2Commons. We really should have alternatives and UploadWizard's Flickr import feature is the most feasible, but out of reach for most users. - Alexis Jazz ping plz 23:36, 10 January 2019 (UTC)
Like I said, I don't really see any problems with this proposal. Seeing as the upload_by_url right is restricted anyways to URLs that have been whitelisted I don't see issue with granting it to more individuals. If the community wants to do that via expanding autopatrolled so be it. --Majora (talk) 21:23, 11 January 2019 (UTC)

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.

Better handling of file copyright releases with source linkrot[edit]

After this deletion request raised by a Commons Bureaucrat, I have been nudged to reconsider that our norms need better formalization into guideline, so that administrators and others interested in deletion requests can act consistently when sources are suffering from linkrot, so there is a practical presumption of good faith, for files where there is no prior pattern of related challenge or demonstrated copyright violations.

It is a statement of fact that every website on the internet has a limited life, and the scope of this project should include the preservation of useful educational content that might otherwise vanish or become much harder to access. It has to be accepted that independent license reviews are not expected or enforced for all Commons uploads.

Proposal: For an in scope file where the uploading account has a reasonable history of good uploads, but the source is no longer available, or the release at source has changed to a non-free license:

  • A file which is part of an upload project of more than 1,000 files and where there is consistency of licensing, will be presumed to have been uploaded with a valid release.
  • A file which has been automatically license checked, and this can be verified in the upload code, or confirmed via a project page explanation, will be presumed to have been uploaded with a valid release.
  • Uploaded files that have been hosted for more than 2 years, where the uploader account has made significant contributions and there is no related pattern of deliberate copyright violation from the source, or by the uploader account, will be presumed to have been uploaded with a valid release. This will apply regardless of the uploading account having since retired.

These guidelines can be added to Commons:License review, unless there is a better place for them to be added.

Please vote on the principle of having this guideline. The numbers (1,000 files, 2 years) may be adapted depending on comments or evidence raised, or even later copyvio related case evidence. -- (talk) 12:54, 11 December 2018 (UTC)

  • Symbol support vote.svg Support as proposer. -- (talk) 12:54, 11 December 2018 (UTC)
  • Could we not simply have a discussion rather than a vote? Currently the issue and criteria seems to be narrow to the point of involving one user: Fae. Are there other cases? It seems to be saying simply that your uploads should all be trusted and never speedy deleted and default keep at DR unless demonstrated otherwise. I'm sure you do take care but are only human and the source organisations/people are also only human too. We have had cases where apparently trusted organisations uploaded and tagged-as-free images they shouldn't. I recall one notable example where NASA on Flickr uploaded an Annie Leibovitz photo to their PD stream, which was uploaded by an "account [that] has a reasonable history of good uploads". Wouldn't it be better to have ensured the images were reviewed four years ago? Do we have a means to bulk-review a batch of images from one source? If we don't have a means to review images as quickly as some users upload them, shouldn't we fix that, rather than just create exceptions at DR? This seems to be a tail-wagging-the-dog solution. -- Colin (talk) 15:20, 11 December 2018 (UTC)
  • Pictogram voting comment.svg Comment I have suggested that these files should be license reviewed. Fae opposed that. So not surprised that this comes up here... Yann (talk) 15:31, 11 December 2018 (UTC)
    Please provide a link to that discussion. Thanks -- (talk) 16:09, 11 December 2018 (UTC)
  • Pictogram-voting-question.svg Question Why were these not marked for license review when they were uploaded? If you are that concerned about it they should have been checked by another person. This is an image uploaded from an external site by someone who was not the photographer. That pretty much screams either LR or OTRS. Requesting such a thing would have solved all the issues. To presume anything is to throw out COM:EVID and I'm not really all that comfortable with that. I've found copyvios that have been here for 10 years (using archive sites to verify that they were indeed a copyvio at the time of upload). Putting a year limit on it in the guise of COM:GOF is also not a good idea in my opinion. I'm not entirely familiar with "automatic license checks" as stated in your second bullet. So if you could explain how that works I'd appreciate it. --Majora (talk) 22:36, 11 December 2018 (UTC)
The example DR is such an automatically license checked batch upload, the metadata of the file was checked as having a specific free license ("ATTRIBUTION_SHARE_ALIKE") and if it did not match it was skipped. You can imagine this is the same sort of check that we get with the automatic flickr reviews. There are many example projects that do exactly this type of specific automatic license checking at User:Fæ/Project_list (most recent example). In these cases, investing programming time writing a unique bot script customized for each batch upload, to do exactly the same check, adds zero value, and, even worse, marking literally millions of files for manual checks would be a bizarre waste of volunteer effort.
If it were policy, I could backdate my uploads with {{LicenseReview}} where they do not have one. This would probably mean more than two million files needing manual review as there are no automated bots to handle these, further I would not be allowed to write a bot to do the reviews, even where I have code available, as this would not be independent. This number is large enough to pretty much guarantee the backlog would never be resolved, yet I am hardly the only uploader on this project, and if we add LicenseReview to all our previously uploaded and not-independently-reviewed files, the backlog would be a magnitude or two larger than that. -- (talk) 23:02, 11 December 2018 (UTC)
Hmm...I'd be interested to learn more about this automated checking process. If something is going to come from this your second bullet is the best way forward in my opinion. Where in the metadata is this information stored? I did a more in depth search of the metadata using a third-party viewer and I'm not seeing it. I'm guessing by "file metadata" you really mean page source? That appears to be what User:Fæ/Project list/OpenBenches is working off of as well but please verify. Also, what does the checking? Is it part of the GWToolset? Is it coding that you do yourself when you create one of your projects? Obviously when we are talking about millions of images there has to be some give and take and I'm ok with that. But I just want to make sure all avenues are being explored here and that I fully understand what is going on during these uploads to make an informed comment. --Majora (talk) 23:20, 11 December 2018 (UTC)
The OpenBenches project has metadata available as JSON queries, see the project page. The way the site works is completely unique to that project and the uploads are via a customized Pywikibot script. Were someone to try to use GWT, it would mean extracting the source data from Github (where it happens to be published) and converting it to XML, which would be more complex (in my view) than writing a custom script. The license verification looks at the JSON data for the photograph and does exactly the license string check as explained on the Commons project page. The OpenBenches programmer made the image license data available this way, specifically because I discussed the Commons upload project with him. BTW, in terms of my projects, this is a rather small one, compare with User:Fæ/Project_list/PAS which is "similar" because the metadata is in JSON format, but is fifty times larger. However in the same way as OpenBenches, there is no Commons bot that can be easily tailored to include it to automate independent license reviews. -- (talk) 23:29, 11 December 2018 (UTC)
(Edit conflict) Let me first just apologize for all these questions. Obviously what you are doing is above my level of knowledge so I appreciate you bearing with me while I wrap my head around this. If I'm understanding the above correctly, you write unique queries that pull information off of sites based on how that information is stored (JSON for OpenBenches, etc.). If this is true would it be possible to publish this query so that it can be part of the public record on these images? I see part of the code you used on the OpenBenches information page but not the whole thing. If the entire thing is available it allows others to check your work that way. I feel like that would be a massive step in the right direction towards some sort of verification process. --Majora (talk) 23:41, 11 December 2018 (UTC)
I am prepared to publish the license checking part of my code, but that pretty much is exactly what is on the example project page, it's a cut & paste of a couple of lines from 800 lines of code, and I could continue to do that with future projects, but not retrospective projects especially as in some cases I have probably lost the original code. I do not publish all of my code, that is not a criteria for contributing to this project, nor would it be genuinely useful (in 8 years, there are probably 2 people than have used my code already published on Github for anything, and they did not simply reuse my code; the Github link is even published at the top of my user talk page). However, keep in mind you are only addressing me, there are many other uploaders with customized batch upload projects, and there are no criteria on them for how to do it. -- (talk) 23:50, 11 December 2018 (UTC)
Obviously this is an exploratory proposal that would not just apply to you. Unless the suggestion above made by Colin that this is really a narrow proposal for one was fact. In any case, I really only care about the way licenses are checked. The rest of the code is rather useless in terms of this discussion. As for github, digging through there should not be a requirement. If you could publish the license checking part of your code so that it can be verified that would be preferable in my opinion. This goes for others as well. The way I see this is, essentially, these batch uploads are close enough to bots without actually being bots. Most bots have some sort of code published that can be reviewed to make sure it is doing what it says it is doing. I could see, and probably support, a policy that allows for blanket acknowledgement of acceptable licensing of batch uploaded images provided source code for checking said licenses is published and retained in an easily seen format (such as a project subpage like you have listed above). I'd support this going forward and as for older images we can talk about some sort of grandfathering. --Majora (talk) 00:00, 12 December 2018 (UTC)
  • @Majora: it's not only Fæ. Category:Images from lasvegasvegas.com for example is also complicated. Most probably all the photos in that category are fine, but very few were tagged for license review. - Alexis Jazz ping plz 23:37, 11 December 2018 (UTC)
  • @: this kind of sounds like license-review-assumed?
  1. "A file which is part of an upload project of more than 1,000 files" is such a large number not many uploads will be able to apply for that. It also seems arbitrary. Why not 2,000? Or 500? And what does "where there is consistency of licensing" mean? If none of the files were reviewed and all the source links are dead, but there are more than 1,000 files we keep?
  2. "A file which has been automatically license checked, and this can be verified in the upload code, or confirmed via a project page explanation, will be presumed to have been uploaded with a valid release." should be better defined (like you're now explaining it a bit more above). I would suggest splitting this proposal and make it more clear what each bullet point stands for. - Alexis Jazz ping plz 23:37, 11 December 2018 (UTC)
The vote is for the principle, the criteria can be hammered out. With regard to "1,000", the point is really "the uploading account has a reasonable history of good uploads", so yes if the source vanished for all 1,000 uploads, the debate would still be why do we presume bad faith for the demonstrably good uploader. Deletion in those cases should require some real evidence of a copyright problem, rather than a theoretical concern because someone realized that the source website has been knocked offline, or as has already happened with the very large PAS project, the links no longer function as the database has had a redesign. -- (talk) 23:41, 11 December 2018 (UTC)
  • I'm not sure if we can have a clear-cut guideline on this. It would involve different factors - how mature the semi-automation system/procedure was at that time of the upload in question (earlier uploads may be more prone to mistakes and bugs), how standardized the markup across pages at the source web site were, etc, beyond the general trustworthiness of the uploader. It seems taht the discussion here focuses on sources that already suffer from linkrot, but going forward, I'd encourage mass uploaders to archive evidence before linkrot happens (ideally, before every upload). Services like web.archive.org and archive.is can be used to store evidence semi-automatically. whym (talk) 14:10, 14 December 2018 (UTC)
I believe this is unrealistic, unless the IABot starts including Commons. If you can show/demonstrate how I can add, say, all of finds.org.uk images to IA, currently 440,000 images on Commons, and return those archive links so they can be added on Commons image pages, I would be grateful. Thanks -- (talk) 14:24, 14 December 2018 (UTC)
Here is a quick and dirty code to call web.archive.org in Ruby:
require 'open-uri'
require 'uri'

def run_web_archive_org(uri)
  open("https://web.archive.org/save/#{URI.escape(uri)}") do |f|
    if f.meta['content-location'] then
      puts "<https://web.archive.org#{f.meta['content-location']}>" # location of the archived page which can be fed to an file-page editing script
    else
      puts "Error? #{f.meta.inspect}"
    end
  end
end
Does this help? (You will somehow have to throttle the HTTP requests if you have thousands of pages to be archived, though.) --whym (talk) 14:50, 14 December 2018 (UTC)
I could do something similar in Python, but extending IABot makes a lot more sense as I can piggyback on whatever error traps exist there, rather than reinventing the wheel, plus it can act retrospectively on my past millions of uploaded files and that housekeeping can be run by anyone not just me. I'll think about it, it's very close to Christmas to do anything right now. Anyway this proposal was generic, not just me solving how to do my own Library of Congress or Finds uploads a bit better. -- (talk) 14:56, 14 December 2018 (UTC)
Update A test run has started on trainpix uploads, adding Wayback templates and requesting InternetArchive archives the source page where it does not already have it (which seems most of these). If this works well, and I do not get blocked for mass processing, this may be turned into a more general housekeeping task, and I may incorporate it as a task that happens just before the file is uploaded to Commons. Doing this, clearly, makes any question of license review redundant. -- (talk) 21:00, 4 January 2019 (UTC)
, I am confused why much of your activity on Commons does not fall into Commons:Bots and thus require specific community approval and a separate bot account. I cannot see why adding Wayback templates, for example, is not a bot activity. My guess that is often you are reprocessing your own uploads so nobody cares but that itself isn't something our policy seems to permit. If you don't respond to this reasonable question, I shall have to make an admin request to block your main account, so could you be reasonable about this and explain why our bot policy does not apply to you? -- Colin (talk) 12:16, 5 January 2019 (UTC)
There are quite a lot of images uploaded every day with no request for a license review. I've been running User:RonBot Task 1 every day, and then adding "no permission" tags to lots of images. Which is why I posted the suggestion above for a new bot Commons:Village_pump/Proposals#Proposal_for_Bot, to slowly expand on that Task, and putting the results in a sensible category for license review to be done. I think the idea of allowing a time limit on review will result in copyright images being accepted - I too have found bad images way more than two years old. Ronhjones  (Talk) 00:40, 17 December 2018 (UTC)
  • I would generally Symbol support vote.svg Support this proposal, but to me this could leave room for mistakes to happen and although this policy will only apply to otherwise highly trusted users (users such as Fæ), however there should be a better system where external links are automatically archived, a couple of months ago I suggested that the InternetArchiveBot or a similar bot would run on Wikimedia Commons as it preserves web pages on Wikipedia's however the discussion lead to nowhere and while the operator of the InternetArchiveBot showed that they weren’t interested in this, another user was interested but eventually no action was taken. Originally I was also planning at proposing the archiving of web links at the 2018 Community Wishlist but as I wasn't unblocked on the Meta-Wiki that clearly also didn't happen, as the Community Tech Bot actually runs efficiently for these kinds of tasks it's a shame. As Wikimedia Commons doesn't really have any direct support from the Wikimedia Foundation it's clear that the ageing software on this platform rarely gets updated and very few new features (if ever) get implemented, Fæ’s proposal isn't perfect but in the current environment it's the best we have, unless “the Technical community” would actually start to provide tools for the maintenance of files on Wikimedia Commons rather then just let everyone take both Wikimedia Commons and its files for granted then nothing will change, in fact the only time the Wikimedia Foundation seems to openly operate here is to delete things, not create them. I agree with the principle that these files should be preserved indefinitely and that we should actively try to discourage the deletion of files solely on the precautionary principle if the license from the historical website can’t be found. To give a recent example “Commons:Deletion requests/File:TrueSmart Beach (10).jpg” is a deletion request where a user (presumably) uploaded a free file from a website five (5) years ago but today no evidence of this license exists, yes this could've also been simply solved if the file’s license had been reviewed when it was uploaded, but if an archive of the website existed today of how it looked half a decade ago any license reviewer would've been able to debunk/confirm the license today. It would probably be best to try and solve the underlying (technical) issues rather then try and play these policy gymnastics, it seems to be a common trend among Wikimedians to build policy based on the limitations of the system rather than try to improve the system itself, let’s say the cycle works like this “The Wikimedia Foundation implements a half-baked feature (there may or may not have been a demand from “the community” for this), a better more complete feature is “promised for the future” but seemingly never comes to fruition, the users of the website start using this half-baked feature and starts creating (mostly unwritten) rules around this feature, these rules seem to be inconsistently applied by only the admins who believe in them and remain largely a secret for the out-group unless they would seek out the pattern, votes on solidifying these rules rarely seem to work and the preference for these vague unwritten rules seems to prevail” (this is probably because it gives admins more leeway, but this will inevitably confuse new users and makes the system looks unfriendly, there’s always an unwritten rule somewhere waiting for you to bite you in your hindquarters). It would also be wise if the state of these unwritten rules would be brought for scrutiny by the community rather then be dependent on the whim of the admin. Free within scope files get deleted everyday because the uploader didn't know how to do something properly, I would also suggest adding more manual links to the Internet Archive however the Internet Archive website won't load on my device anymore so this could too negatively impact users if such a rule was implemented. The best solution would still be to automatically archive links, and this is something that should be done ASAP but there doesn't seem to be any support for actually fighting the linkrot that’s so rampant on this project. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 13:26, 18 December 2018 (UTC)
  • Symbol oppose vote.svg Oppose the proposal. We need better ways to quickly carry out independent licence review on images that are being bulk uploaded. Several users, either with home-grown closed-source unauthorised pseudo-bots or using flickr2commons and variants, are vastly exceeding the capability of the site's volunteers to monitor input. In think we need more emphasis on users to ensure they are helping to avoid simply creating a huge backlog, rather than making proposals that sweep the backlog under the carpet. -- Colin (talk) 11:17, 29 December 2018 (UTC)

Split up Freedom of Panorama country list[edit]

Commons:Freedom of panorama contains a list of FoP rules for specific countries, now transcluded from sections in recently-created articles giving the copyright rules for each country, such as COM:CRT/Algeria#Freedom of panorama. The page is large, with a post‐expand include size of 1,290,255, and may load slowly. During clean-up of the country-specific articles I have been adding FoP information to country articles where it was missing, but have held off on adding the countries to the Commons:Freedom of panorama countries list, which may get close to the breaking point.

This is to propose dropping the list from COM:FOP, leaving links to smaller lists for Africa, Americas, Asia, Europe and Oceania. The smaller lists will have entries for all countries, so will pick up new ==Freedom of panorama== sections in the country pages automatically. See Commons:Freedom of panorama/Africa for an example.

Inbound link issue[edit]

The main issue seems to be the many links, mainly from archived deletion discussions but also from files etc, to sections in the present FOP country list, often using shortcuts. E.g. 1,314 occurences of links to "COM:FOP#France". One way to resolve this would be to replace the country list with a multi-column list of anchors and new shortcuts with entries like

* {{Anchor|Australia}}[[COM:FOP Australia]]

which would display like

Shortcuts to country-specific rules

COM:FOP#Australia, would jump to Australia's entry in this list (click on COM:FOP#Japan to see the effect), and over time people would learn to use the new shortcut. It is not a particularly elegant solution, but the problem is creeping up on us, so will need some sort of solution sooner or later. Aymatth2 (talk) 19:46, 17 December 2018 (UTC)

Comments[edit]

  • Symbol support vote.svg Support, this is both easier to maintain and update and also easier to link to, idiosyncracies of the copyright laws of a certain territory could be much better contained within these specific articles rather than creating one huge page which is difficult to load. If only the software would support the option to allow people to watch edits made to transcluded sections without having to individually watch all of them, but I've been observing these proposed changes for a while now and can say that I'm a big fan of them. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 23:30, 17 December 2018 (UTC)
  • Symbol support vote.svg Support, good idea.   — Jeff G. please ping or talk to me 07:02, 19 December 2018 (UTC)
  • Symbol support vote.svg Support. Vulphere 08:46, 23 December 2018 (UTC)
  • Symbol support vote.svg Support. Alternatively, one could use AWB or run a bot to change "COM:FOP#Japan" (and its variants) to "COM:FOP Japan" so that all those old links would be fixed. 4nn1l2 (talk) 01:53, 25 December 2018 (UTC)
    I have tried to fix most of the active shortcut links. One of my changes was reverted, because the user (with reason) did not like my changing their comment. It may take a while for people to get used to the new convention. So I think a list of the new shortcuts at the end of the FOP page will be useful, at least for a transitional period. Aymatth2 (talk) 13:28, 25 December 2018 (UTC)

Done. Since there were no objections, I have implemented the change. So COM:FOP#France, for example, leads to the COM:FOP France entry in the shortcut list, which in turn leads to the rules for France. There are no broken links, and it should be easy enough to get used to the new shortcut convention. Aymatth2 (talk) 13:38, 4 January 2019 (UTC)

Update padlock icons that Wikimedia Commons use to the ones that the English Wikipedia uses[edit]

The pad lock icons that Wikipedia uses are actually somewhat more descriptive on the image itself of what type of protection has been put into place. Even a user that does not know the meaning behind a particular protection name, the Wikipedia padlock icon gives away somewhat of a hint. The current old style(what Wikipedia used to use), only differentiates the padlock icons of different types of protection by color. Not only is that not much descriptive, it could also be deceiving to a color blind person. The updated Wikipedia padlock design has somewhat little bit taken care of this issue as well, a majority of the low level padlocks are black in color (thus causing no issues to color blind people).Aceing Winter Snows Harsh Cold (talk) 06:45, 19 December 2018 (UTC)

It's not clear at all to me what exactly what you are proposing here. Please give links and/or examples: Which set of files should be used instead of which other set of files for which purpose? Thanks, --El Grafo (talk) 09:25, 19 December 2018 (UTC)
The English Wikipedia changed to use the icons in Category:Page Protection Padlock Redesign (2018) to denote levels of page protection. GMGtalk 11:51, 19 December 2018 (UTC)
Wikipedia:Wikipedia:Village_pump_(proposals)/Archive_155#Proposal/RFC:_Redesigning_page-protection_padlock_icons_to_be_more_accessible.--BevinKacon (talk) 00:01, 20 December 2018 (UTC)
Thanks for the clarificatiopns, GreenMeansGo and BevinKacon. TBH, I never even noticed we had different padlock icons for different purposes cat Commons. I guess I wouldn't mind if somebody wanted to implement the new ones here. --El Grafo (talk) 09:27, 20 December 2018 (UTC)
Well we can't really implement these exact ones. We could adapt them, but using letters derived from English meanings is problematic on an multi-lingual project where many users don't even speak a language in a Latin script. GMGtalk 11:24, 20 December 2018 (UTC)
Is it possible that they would only appear if a user has set their standard language to "English"? And even though people say that Wikimedia Commons is "a multilingual project" for all intents and purposes it's still primarily an English language project, even if you change your settings to "Vietnamese" or "Chinese (Traditional - Taiwan)" you would still see "Category:" And "File:" Rather than "Thể loại:" Or "Tập tin:" As they would appear at "w:vi:Tập tin:Bao-Dai-Thong-Bao.png" but if you were to click on the blue part of "Tập tin này từ Wikimedia Commons. Trang miêu tả nó ở đấy" it will bring you to "File:" yes, you can add multilingual descriptions and things like the MediaWiki Upload Wizard are in more than one language but the de facto language of Wikimedia Commons is still in English and if these padlocks are more descriptive for us English speakers (who make up the majority of this project as all policy conversation is conducted in this language) then it would be beneficial to the largest demographic on the project, what harm would that cause? Sure, it's chauvinistic, but it's still beneficial at large. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:03, 21 December 2018 (UTC)
Well, I'm not sure it makes sense to make a change intended to increase accessibility for the visually impaired, and in doing so, make the site less accessible for anyone who doesn't speak English. Having said that, only four of them are based on letters, so it shouldn't be too difficult to find more culturally universal symbols to replace them. GMGtalk 11:32, 21 December 2018 (UTC)
I agree 100% (one-hundred percent), and those padlocks could also be used on Wikidata and other multilingual Wikimedia projects, maybe someone here reading this could create them. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 12:02, 21 December 2018 (UTC)
We definitely need to get rid of the letter initials if these locks are used in multilingual environments. XYZtSpace (talk) 23:23, 29 December 2018 (UTC)
  • Symbol support vote.svg Support, good idea.   — Jeff G. please ping or talk to me 14:32, 22 December 2018 (UTC)
  • Symbol support vote.svg Support. Vulphere 08:47, 23 December 2018 (UTC)
  • Symbol support vote.svg Support - Alexis Jazz ping plz 12:13, 29 December 2018 (UTC)
  • Symbol support vote.svg Support - I could be wrong but I believe EN was the first to update theres with everyone else following after (I remember participating in the discussion and also remember discussing the colours), I prefer the new ones over the old ones and would've supported this regardless of EN. –Davey2010Talk 14:51, 29 December 2018 (UTC)
  • Symbol support vote.svg Support Full-protection-shackle-block.svg, Semi-protection-shackle.svg, Move-protection-shackle.svg, Cascade-protection-shackle-double-chain-link.svg, Upload-protection-shackle.svg, (for the future: Template-protection-shackle-brackets.svg, Pending-protection-shackle-double-ticks.svg, Create-protection-shackle.svg, Extended-protection-shackle-check-mark.svg, Office-protection-shackle-WMFlogo.svg). I don't support those with Latin letters, as they are almost meaningless for most users. 4nn1l2 (talk) 20:24, 31 December 2018 (UTC)
  • Symbol support vote.svg Support same as 4nn1l2, no preference on icon used, just no letters.--BevinKacon (talk) 23:01, 7 January 2019 (UTC)
  • Symbol support vote.svg Support, nice but I preferred the "Proposed design" below. --B dash (talk) 10:41, 10 January 2019 (UTC)
  • Symbol support vote.svg Support; I would prefer the proposed designs except for the full protection padlock, for which I'm not sure and don't really mind either way. Jc86035 (talk) 08:48, 13 January 2019 (UTC)
  • Symbol oppose vote.svg Oppose I prefer the current ones, less cluttered and more expressive. Some of the suggested alternatives below do offer some (multilingual) advantage. (I've also changed the header to say "English Wikipedia", because Wikipedia overall hasn't settled on the proposed icons.) Nemo 15:31, 13 January 2019 (UTC)
@Nemo bis: you mean the current ones from English Wikipedia or..? Because the current ones here are just the exact same lock with different colors. (nearly useless for the color blind I imagine..) I wouldn't call that "expressive". - Alexis Jazz ping plz 01:28, 14 January 2019 (UTC)

Update padlock discussion[edit]

Type of protection Current design Proposed design Suggested alternatives
Full protection
Fully protected
A symbolic representation of a padlock, gold in color with a grey shackle. On the body is a white capital letter F.

A symbolic representation of a double padlock, gold and silver in color with a grey shackle.  A symbolic representation of a padlock, gold in color with a grey shackle. On the body is a white 🚫 sign.

Semi protection
Silver padlock
A symbolic representation of a padlock, dark grey in color with a grey shackle.
A symbolic representation of a padlock, dark grey in two colors with a grey shackle. A symbolic representation of a padlock, dark grey in two colors with a grey shackle. A symbolic representation of a padlock, dark grey in two colors with an account icon in two shades and a grey shackle.
Move protection
Green padlock
A symbolic representation of a padlock, green in color with a grey shackle. On the body is a black right arrow.
Cascading protection
Turquoise padlock
A symbolic representation of a padlock, turquoise in color with a grey shackle. On the body is a white symbol representing a chain link.
A symbolic representation of a padlock, turquoise in color with a grey shackle. On the body is a white symbol representing a chain link with two links.
Upload protection
Purple padlock
A symbolic representation of a padlock, purple in color with a grey shackle. On the body is a white up arrow above a horizontal line.
The following icons are not used on Commons but included in the table in case other wikis want to adopt them/harmonize padlock icons:
Template protection
Template-protected
A symbolic representation of a padlock, magenta in color with a grey shackle. On the body is a white capital letter T.
A symbolic representation of a padlock, magenta in color with a grey shackle. On the body are curly brackets. A symbolic representation of a padlock, magenta in color with a grey shackle. On the body is a puzzle piece. A symbolic representation of a padlock, magenta in color with a grey shackle. On the body is a tilted puzzle piece. A symbolic representation of a padlock, magenta in color with a grey shackle. On the body is a puzzle piece.
Creation protection
Blue padlock
A symbolic representation of a padlock, light blue in color with a grey shackle. On the body is a white plus sign.
Pending changes protection
White padlock
A symbolic representation of a padlock, blue-grey in color with a grey shackle. On the body is a white check mark.
A symbolic representation of a padlock, blue-grey in color with a grey shackle. On the body are double ticks.
Extended confirmed protection
Dark blue padlock
A symbolic representation of a padlock, medium blue in color with a grey shackle. On the body is a white capital letter E.
A symbolic representation of a padlock, medium blue in color with a grey shackle. On the body is a check mark. A symbolic representation of a padlock, medium blue in color with a grey shackle. On the body is an account icon.
Protection by office action
Black padlock
A symbolic representation of a padlock, black in color with a grey shackle. On the body is a white circle.
A symbolic representation of a padlock, black in color with a grey shackle. On the body is the WMF logo.
  • @GreenMeansGo, Donald Trung: Added office action padlock with WMF logo. The T for template could perhaps be replaced with {{? For full maybe two locks that overlap. Even with just the letters though it's an improvement. - Alexis Jazz ping plz 12:13, 29 December 2018 (UTC)
  • Added double padlock for full protection. - Alexis Jazz ping plz 13:20, 29 December 2018 (UTC)
  • Oh that looks really nice actually. For free we also have en:File:Generic-protected-shackle.svg and File:Semilock.png. Looks like they were designed but never used. I think it was suggested at one point to use the "no" sign, as in like...the red (/) on a no-smoking sign for full. Not sure what we could use for ECP. GMGtalk 13:23, 29 December 2018 (UTC)
  • @GreenMeansGo: maybe two arrows pointing in opposite directions? (to symbolize wide, extended) Or a little clock or stopwatch, but I'm not sure that would fit. - Alexis Jazz ping plz 13:32, 29 December 2018 (UTC)
  • I really don't know. Arrows might be confusing vis a vis the arrow on the move protection. It'd be a lot easier if we could use numbers, but we run into the same problem as letters. GMGtalk 14:05, 29 December 2018 (UTC)
  • @GreenMeansGo: this is the one you are referring to. I'll make an updated version and put it in the table. XYZtSpace (talk) 23:28, 29 December 2018 (UTC)
  • Ah ha! Yes, bingo. I wasn't crazy. I could've swore I'd seen it before. Thanks a bunch. GMGtalk 01:03, 30 December 2018 (UTC)
  • Added some template alternatives that were already here. - Alexis Jazz ping plz 15:09, 29 December 2018 (UTC)
  • Nice. I like any of the grey shackles puzzle pieces. I assume jigsaw puzzles are fairly cross cultural in meaning. So we really only need a clever idea for ECP. GMGtalk 15:37, 29 December 2018 (UTC)
  • @GreenMeansGo, Donald Trung: added more alternatives (removed File:Template Protection (Redesign2).svg which looks out of place). What do you think about the double tick for pending changes so the single tick could be used for extended confirmed? For template protection, I prefer the curly brackets but any of the puzzle pieces also work for me. - Alexis Jazz ping plz 15:56, 29 December 2018 (UTC)
  • @GreenMeansGo: added a padlock inspired by File:Semilock.png. I think the "account" icon in the semi-protection lock is rather unclear. I had no idea what it was until I read the upload comment. - Alexis Jazz ping plz 16:45, 29 December 2018 (UTC)
  • I personally like the slash semi too. GMGtalk 02:11, 30 December 2018 (UTC)

Pictogram-voting-question.svg Question We don’t have extended-confirmed here, do we?—Odysseus1479 (talk) 01:05, 30 December 2018 (UTC)

  • Well crap, it's not in Commons policy. I guess I just assumed it was turned on by default in media wiki. GMGtalk 02:11, 30 December 2018 (UTC)
  • Umm...embarrassing question: Nick or Yann, is extended confirmed protection even enabled on Commons? GMGtalk 03:00, 30 December 2018 (UTC)

Reckon that all of the padlocks are now made both language and script neutral, right? I don't see anything which could be seen as exclusively Anglophone in the new proposed designs. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 09:28, 31 December 2018 (UTC)

  • Umm...Wait. Can a local project opt out of office actions? That doesn't seem right, even if it isn't included in local policy. Office actions aren't subject to local consensus. GMGtalk 11:48, 31 December 2018 (UTC)
  • @GreenMeansGo: Of course, we can not opt out. I guess the reason it is in the not used on Commons section of the table is mainly that we do not have an equivalent of en:Template:Pp-office. Not sure we would need one though, as even the one on en.wp is completely practically unused. --El Grafo (talk) 09:35, 1 January 2019 (UTC)

Exhibitionist uploads[edit]

I regularly see uploads low quality amateur porn which doesn't serve any educational purpose. It is usually a man masturbating and uploading a video of it, with no contributions to other projects. It seems plausible that there is some offsite collusion, although I don't know where. This has been an ongoing issue for a while. See these accounts in just the past couple of days:

Don't get me wrong. I believe sexual content is necessary. But these uploads are disruptive; Commons is not an amateur porn site, and it drives users away when they see their uploads in the same place as useless amateur porn.

As such, I believe we should add a CSD category for amateur porn with no educational value from non-contributors. Just like COM:CSD#F10, the keywords are non-contributors and low to medium quality. Magog the Ogre (talk) (contribs) 22:06, 24 December 2018 (UTC)

Spam is a worse problem, especially as several pron warriors lurk on this project. Amateur glamour stuff should go through deletion like any other file. The problem with "no educational value" is that every week I see perfectly valid files, including in scope nudity and sexuality related material, having speedy tags, wrongly, with this claim.
PS Christmas is not the right time to raise policy proposals. -- (talk) 23:03, 24 December 2018 (UTC)
We have deletion requests for a reason, but what constitutes "spam" because my impression is that everyone seems to have their own opinion on it, someone who imports a lot from the same website is "a spammer" then you would be considered one too as you're bombarding Commons with external links and Wikipedia doesn't care if that link is to a GLAM so why would Commons? I think that "spam" is too vague of a term to actually enforce here because anything less than negative of something could be seen as "promotional". Anyhow the deletion request system is the best option because I can see people abuse {{Speedy}} for basically anything, in fact regarding porn deletion requests there seems to be a user who just writes "{{vd}} Worthless, poor quality, redundant and out of scope." At every DR that contains a penis even if it is in use or of high quality, now imagine if people like this had a policy they could abuse. DR's are also more transparent than speedy deletions ans though I agree that most of the bad quality images of porn aren't fit for this project, allowing careless deletion could do more harm than good. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 08:01, 25 December 2018 (UTC)
  • I would support this for images that might be "revenge porn", such as the images discussed in "Commons:Deletion requests/Files uploaded by Hakunamatata12345678" where both files seem to have been sent through WhatsApp-Messenger half a decade ago, I highly doubt that anyone would send photographs of their own penis through WhatsApp-Messenger and then post them to the Internet, if it's likely that a nude or dickpic is uploaded by someone who isn't the author then this could be a form of cyberharassment and this should be speedy'd as the content is potentially harmful for the depicted individual. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 10:22, 25 December 2018 (UTC)
  • Pictogram voting comment.svg Comment Deleted. Such files can always be speedy deleted as copyvios and/or vandalism. I am not sure a new deletion reason is necessary. Regards, Yann (talk) 12:05, 25 December 2018 (UTC)
  • @Yann:, I agree that no new rules would have to be established for this, but it could be an expansion of harassment rules as according to Cybercivilrights.org "w:en:Revenge porn" does have special legal ramifications other than merely a copyright violation, and I think that we should treat people who post revenge porns/pornography (such as unauthorised dickpics) to Wikimedia Commons should be treated as people who post legal threats. A couple of years ago someone I know went through a divorce and his ex-wife posted his nudes online, let's just say that he now has full custody over their children and she has a restraining order against her so "revenge porn" can have legal effects. I just hope that the poor man whose penis was uploaded wasn't harmed by those images. But Wikimedia Commons fals under the safe harbour provision of the DMCA anyhow so I don't think that "revenge porn" constitutes a special threat to the project other than "regular copyright violations", but we should be weary of it. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 12:18, 25 December 2018 (UTC)
  • IMO, "revenge porn" falls into the same attack images category like racist or other harmful intent, but in this case, it is a bit less obvious to recognize, compared to mere exhibitionism. Regards, Yann (talk) 12:24, 25 December 2018 (UTC)

Pointing your camera 45 degrees down, from your face to your crotch is a nude selfie, so should be should be speedy deleted as F10.--BevinKacon (talk) 16:49, 28 December 2018 (UTC)

No, that's not a nude selfie. That's just a dickpic (or a..vagpic?). - Alexis Jazz ping plz 10:49, 29 December 2018 (UTC)
  • Symbol oppose vote.svg Oppose with an exception for confirmed socks (which you suggest is the problem here). Send it to DR the first time. If a video of the same masturbating man is uploaded the day after deletion, even if it is a new (but similar in terms of content and quality) video, use G4. - Alexis Jazz ping plz 10:49, 29 December 2018 (UTC)

Lift the delinker ban of: No replacement of images in other formats with SVGs[edit]

One of Delinkers rules is: No replacement of images in other formats with SVGs. To avoid World War III, CommonsDelinker will ignore a command to replace an image if the new image is in an SVG format and the original is not.

I don't think we would enter WW III anymore and sometimes its really inconvenient not being able to replace a file with an svg. Amada44  talk to me 20:53, 28 December 2018 (UTC)

GA candidate.svg Weak support, but should be used with care (assuming there was a sound reason for this restriction when it was put in place). - Alexis Jazz ping plz 10:52, 29 December 2018 (UTC)
The heavily used, optimized png icons? Would it be sufficient to state that in the rules? e.g. Do NOT replace optimized png images with svg images. Amada44  talk to me 12:15, 29 December 2018 (UTC)
@Amada44: make it something like "do not replace raster images with svg images in templates and do not replace optimized raster icons in general". - Alexis Jazz ping plz 12:57, 29 December 2018 (UTC)
Actually, add "without consensus" to that. With consensus you could do those things too. - Alexis Jazz ping plz 14:56, 31 December 2018 (UTC)

Amada44 -- the restriction was applied because there have been some people on Commons in the past who were extremely zealous and rigidly inflexible in replacing all usages of a non-SVG file and trying to get it deleted whenever a claimed SVG equivalent was first uploaded, regardless of whether the SVG file had problems or was not truly equivalent... AnonMoos (talk) 15:50, 14 January 2019 (UTC)

@Amada44, AnonMoos: that's a valid point, I've changed my support to weak. This is actually not a problem with image replacement but a problem with deletionists. In fact, I know who this is about. I just noticed them at it again. (though there are probably multiple people who do this) - Alexis Jazz ping plz 19:14, 14 January 2019 (UTC)

Use of Eurostat tag[edit]

Hi, I have been trying to fix the links to the {{Attribution-Eurostat}} licensing tag, and am finding that there are lots of files on Wikicommons that are really sourced from Eurostat, but where editors have edited the Eurostat data so that they can attribute the material under their own license (however, they still list Eurostat in the name or description or even source). I wonder if editors are aware that Eurostat material is not copyrighted (per the Eurostat tag), and that they can use it directly (with the tag)?

It would be better to have material that is sourced from Eurostat (higher quality), rather than a material from Eurostat that has been edited in some way and lost its Eurostat sourcing. Eurostat is a massive database. This issue occurs with other EU Commission material, most of which is not copyrighted (per Eurostat tag). My proposal is that the Upload template should have an EU Commission section (as it does for the US Government and for Flickr), that would remind editors that most of the EU Commission's material is not copyrighted? thanks. Britishfinance (talk) 15:56, 30 December 2018 (UTC)

@Britishfinance: isn't it possible that a lot of those uploaders were simply unaware of the existence of the {{Attribution-Eurostat}} license tag? --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 11:49, 31 December 2018 (UTC)
@Donald Trung: that is my proposal, I don't think people are aware of the {{Attribution-Eurostat}} license tag, and that we should, therefore, incorporate it into the upload wizard (as we do for U.S. Government and Flickr). Eurostat is a massive database (and it applies to almost all other EU Commission media). thanks. Britishfinance (talk) 11:52, 31 December 2018 (UTC)
In addition, I do believe that more of the license tags list should be incorporated into the upload wizard interface. There has been a lot of good work done on these tags and I think that editors are uploading material as own work (by editing source data), whereas with knowledge of the right tags, they could use the source data, and it would have more integrity/weight (i.e. is it not better to have Eurostat's original graphic of an item, then a random editor's re-edit of the data)?. Britishfinance (talk) 12:06, 31 December 2018 (UTC)
That does sound lime a good idea, Flickr as a website has been on the decline so if a new website would fill its void I think that we'd incorporate that into the MeediaWiki UploadWizard too, so it would make sense for something a bit less "trend-dependent" as a government (or intergovernment) website to also be on that list. You could also propose it at "Commons:Upload Wizard feedback", but I highly doubt that that page is still active. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 12:36, 31 December 2018 (UTC)

Wikimedia Commons sitelinks on Wikidata (external RfC)[edit]

In case the above link doesn't work well, I've started a request for comment regarding Wikimedia Commons site links on Wikidata at "Wikidata:Wikidata:Requests for comment/Proposal to create a separate section for "Commonswiki" links". I don't know where to properly announce it so I'll place a link here and at the regular village pump. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 15:52, 15 January 2019 (UTC)

Make the "more upload options" proposal apply to all user accounts with autopatrol flag[edit]

Pinging everyone who responded to the original proposal: Pinging @Koavf, GreenMeansGo, Yann, Donald Trung, .

Also see phab:T214003 and User talk:Alexis Jazz#upload by url.

Due to an interpretation of words that I personally don't really see in the original proposal, only users in the autopatrolled user group are now getting the extra options. Patrollers and bots, who also have the autopatrolled flag and are thus autopatrolled users, are not getting the additional options. An admin could simply add them -all 687 of them- to the autopatrolled group, but that'll probably cause some muscle strain. Don't ask me to explain this, because I hardly understand it. But it's easier to nod and say yes in this case. - Alexis Jazz ping plz 17:12, 20 January 2019 (UTC)

Proposal: more upload options for autopatrolled things[edit]

Proposal: make the previous proposal apply to all users and all user accounts and all people and in fact all beings who have, carry, possess, own and/or are the legal guardian of a working autopatrolled flag, autopatrol bit, autopatrol user right or are autopatrolled by magical intervention. (sorry, gotta cover my bases this time..) Offer void in Nebraska outside Wikimedia Commons.

  • Symbol support vote.svg Support - Alexis Jazz ping plz 17:12, 20 January 2019 (UTC)
  • Symbol support vote.svg Support, didn't we just vote on this before? Why is the "Autopatrolled" user group removed from "Patrollers" anyhow if they're not the same? Because I can remember a Village pump discussion a few years ago that resulted in all "Patrollers" and other "higher user groups" having the "Autopatrolled" user group removed from them, maybe it's time to stop removing it. --Donald Trung 『徵國單』 (No Fake News 💬) (WikiProject Numismatics 💴) (Articles 📚) 17:52, 20 January 2019 (UTC)
  • Symbol support vote.svg Support Wut? GMGtalk 18:39, 20 January 2019 (UTC)
  • Symbol support vote.svg Support Obviously. Yann (talk) 18:52, 20 January 2019 (UTC)
  • Symbol support vote.svg Support Just common sense Abzeronow (talk) 21:50, 20 January 2019 (UTC)
  • Symbol support vote.svg Support, of course.   — Jeff G. please ping or talk to me 22:11, 20 January 2019 (UTC)

Discussion: more upload options for autopatrolled things[edit]

@Donald Trung: the autopatrolled flag was added to the patroller group, making the autopatroller group redundant for patrollers. Admins, for example, are not in the autopatrolled group either. We voted on autopatrolled users, which I take as anyone with the autopatrolled flag, but in this case was interpreted to mean the autopatrolled user group.

I told you not to ask me to explain it, I suck at this. - Alexis Jazz ping plz 18:02, 20 January 2019 (UTC)

We did and we didn't just have a RfC on this. You must separate user groups from user rights. User rights are assigned to groups and then the group is granted to individual editors. Technically any right can be assigned to any group and there are a lot of rights as can be seen in the interface for some of the global groups which can actually be manipulated by stewards instead of having to get the devs involved. There was obviously a slight confusion between the difference between groups and rights and in the last RfC the question that appeared to have been raised was to add the upload_by_url right to the autopatroller group. That is the way I read the proposal, that is the way I closed it, and that is the way the devs are implementing it. I did not read it as add upload_by_url to any and all accounts that have the autopatrol flag. Since the current implementation of the original RfC is proceeding as I originally interpreted it we would need to verify consensus to add any additional flags to any additional groups. Bureaucratic red tape, I know. But this way the devs know exactly what we are asking for when it comes to user rights. --Majora (talk) 18:19, 20 January 2019 (UTC)
And before anyone asks why I didn't ask what the "correct" interpretation of the original RfC should have been before I closed it, I did. I was told my interpretation was correct, although that might have been due to the confusion between groups and rights again. --Majora (talk) 18:48, 20 January 2019 (UTC)
Yes, I either read or assumed (doesn't matter, can't remember) you meant all users with an autopatrol flag. I was unaware you were differentiating there between users with the flag and users in the group. I thought your only question was if the proposal meant the extended uploader group would become obsolete, to that I answered "correct", unaware you meant more. - Alexis Jazz ping plz 19:55, 20 January 2019 (UTC)