Commons:Village pump/Proposals

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) Commons Help desk Community-wide general discussion Copyright Proposals Graphics and photography discussion Image improvement Photography critiques Categories for discussion Deletion requests OTRS noticeboard Translators' noticeboard Work requests for bots Contact administrators Vandalism User problems (Dispute resolution) Blocks and protections Bureaucrats' noticeboard CheckUser requests #wikimedia-commons webchat Commons mailing list (archive) Commons' bugs on Phabricator Please note One of Wikimedia Commons' basic principles is: "Only free content is allowed." Please do not ask why unfree material is not allowed on Wikimedia Commons or suggest that allowing it would be a good thing. Have you read the FAQ?   Start a new discussion

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day and sections whose oldest comment is older than 30 days.

Giving OTRS members the ability view deleted files

through a request for right

I'm suggesting to give OTRS members the ability view deleted content which (all content especialy the file itself), I believe, essential for handling tickets by non-admins. They can not see the photo that they discussing about, they can not see if there is a FoP problem there, personality rights issue etc. In fact, the restoring admin (which have to be also OTRS member) have to double the work of the non-admin volunteer.

We had a previous discussion about a similar suggestion back in 2014. but now I am not talking about giving them the ability to restore files. Only to view. OTRS members trusted users and they already signed on stringent privacy policy.

I understand that deletedhistory rights are only allows "viewing the list of deleted history items including author and summary of each item unless they are hidden or suppressed". So we need to ask for a new group title for that. -- Geagea (talk) 09:23, 27 February 2017 (UTC)

Clarification: We will creat new user right group on Commons OTRS user have to request in COM:RFR and only approved users may accept the right. -- Geagea (talk) 13:18, 7 March 2017 (UTC)

Voting

1.  Support if technically feasible. Sebari – aka Srittau (talk) 11:00, 27 February 2017 (UTC)
2.  Support Good idea. Yann (talk) 11:52, 27 February 2017 (UTC)
3.  Support This is something that will help me a lot as aN OTRS volonteer. Some times picture are selleted before we receive the OTRS permission. Hanay (talk) 15:58, 27 February 2017 (UTC)
4.  Support would be helpful in my work as an OTRS agent. Ijon (talk) 22:32, 6 March 2017 (UTC)
5.  Support The OTRS members I know in person are trustworthy and this right would help them in their work. -- 32X (talk) 10:28, 7 March 2017 (UTC)
6.  Oppose I cannot support giving editors who have not been approved by the Commons community for advanced permissions the ability to view material that the community has decided to delete. If anything, we should create a new userright on Commons, that the community can grant to OTRS members upon request at COM:RFR. Otherwise, we create the possibility of allowing editors who are OTRS members for other projects, with no access to Commons queues, and who have possibly never even edited Commons, the ability to view deleted material. - Revent^talk 10:45, 7 March 2017 (UTC)

   I would support the proposal, as clarified by Geagea after my initial 'vote', that specific OTRS members may request that the Commons community grant them the right to view deleted files, and that a new user group be created for that purpose. - Revent^talk 07:15, 14 March 2017 (UTC)

7.  Support After the clarification regarding a request for rights [1], furthermore this kind of permission for really active trusted Commons users with OTRS access will be likely much more usefull for the community than this de facto right for the (large numbers of) administrators who are not really active. In summary if we give these rights to non-active administrators, I don't see the issue to give these rights to active trusted users who will use really those rights and in a good way for to help the community and the Wikimedia projects. Insofar as we keep here in Wikimedia Commons the power to allocate or take over these rights of course. Christian Ferrer ^(talk) 18:14, 7 March 2017 (UTC)
8.  Oppose With all due respect to the proposer and his work, this proposal appears not very well prepared to me.
   • Getting an opinion on a deleted file or getting it restored to apply an OTRS ticket can always be done in several ways, not least via IRC.
   • The Commons admin giving an opinion or restoring the file doesn't have to be an OTRS agent because the OTRS part of the work is still be done by the OTRS volunteer.
   • OTRS members are not trusted users regarding to Commons point of view as they are not appointed by the Commons community.
   • I'm still uncomfortable to broaden the view to deleted material to so many more users without actual need.
   • I everything else fails or becomes unmanageable, the OTRS user can request adminship on Commons, which likely will help the community in many more places, and is the easiest solution.

   --Krd 17:48, 8 March 2017 (UTC)

9.  Oppose Per Krd's. In particular: OTRS members are not trusted users regarding to Commons point of view as they are not appointed by the Commons community. --Discasto _talk 16:27, 9 March 2017 (UTC)
10.  Oppose per Krd, et al. OTRS membership is not granted by or in consultation with the Commons community; it is highly inappropriate to grant a trusted right (view deleted) to users who have not had that trust confirmed by the community in which the right will be deployed. This also opens a perverse asymmetry. For example, a Commons admin and OTRS member could not view deleted on, say, the Estonian Wikipedia; yet an Estonian OTRS member--who may or may not have ever even used the Commons--could view deleted images here. Obviously that would be true of all other projects. That is a nonsensical (and dangerous) position, as is this proposal. Эlcobbola _talk 23:13, 9 March 2017 (UTC)
11.  Oppose as per the arguments of Revent, Krd and Elcobbola. Daphne Lantier 01:18, 10 March 2017 (UTC)
12.  Oppose mostly because the WMF has repeatedly stated over at enwiki that they will shut down any attempt to grant editors the ability to view deleted files unless it stems from a community process. Even if this got approved, the WMF would just shut it down. ~ Rob₁₃^Talk 02:20, 10 March 2017 (UTC)
    • This vote right here is the community process they wanted.   — Jeff G. ツ 04:21, 31 March 2017 (UTC)
      • That misses the point: the community process has to approve each individual user to show the community's trust in their viewing deleted material. --Rschen7754 17:35, 29 May 2017 (UTC)
13.  Support it would make COM:UDR acting on OTRS agents requests simpler. Ankry (talk) 08:23, 11 March 2017 (UTC)
14.  Weak support iff the approval process is on COM:BN, with a criteria of OTRS agents that are also active commons users, and have a similar trustworthiness requirement as an LR. --Zhuyifei1999 (talk) 08:46, 11 March 2017 (UTC)
15.  Support If the user right process will be done on COM:BN, provided that the requesting user are very active on COM:UDR (the definition of "very active" may vary, this will depend on the reviewing bureaucrat). The request will be reviewed by a bureaucrat, and will be open for 72 hours. Otherwise  Oppose, per Krd, Revent, and Elcobbola, since they are not elected by the community, hence they aren't trusted to view deleted files, which is a very sensitive privilege. --★ Poké⁹⁵ 11:57, 16 March 2017 (UTC)

Changed my mind; full  Oppose regardless if there would be a user right process or not. Storkk has a point. ★Poyekhali 11:32, 2 July 2017 (UTC)

1.  Support – the level of trust required for deletedhistory certainly shouldn't be any higher than the one required for permission verifications. If "OTRS members are not trusted users regarding to Commons point of view", how can Commons trust their copyright status assessment? FDMS 4 12:43, 18 March 2017 (UTC)
2.  Support Natuur12 (talk) 16:31, 23 March 2017 (UTC)
3.  Support, maybe call it a viewdeleted right.   — Jeff G. ツ 04:15, 31 March 2017 (UTC)
4.  Neutral - I'm on the fence here. On one hand, giving OTRS the right to view deleted files is a good thing. On the other hand, currently OTRS is understaffed and backlogged, and I'm unsure whether its volunteers are skilled enough and trusted to be granted with such. --George Ho (talk) 10:04, 29 April 2017 (UTC)
5.  Neutral absolutely sensible. But I've to much respect to the opinion of very experienced admins here, so I made my vote neutral. -- User: Perhelion 23:33, 6 May 2017 (UTC)
6.  Support Agree. Mlpearc (open channel) 19:59, 30 May 2017 (UTC)
7.  Oppose, per Krd. Érico (talk) 22:35, 30 May 2017 (UTC)
8.  Oppose purely because the Commons community does not choose its OTRS members. It is entirely a Meta process, and while Commons members are welcome to comment on requests for OTRS access on Meta, the rights granting and revoking process remains one that the Commons community has no direct access to. Last time I looked, there was no process that I could find to recall or remove an OTRS member. And I did have to go looking for the recall process, more than once. Storkk (talk) 14:56, 10 June 2017 (UTC)
9.  Oppose Per Storkk & if a competent OTRS volunteer with access to the Commons queue wants to examine deleted files, they can go through RFA, it's supposed to be no big deal. --Fæ (talk) 07:38, 23 June 2017 (UTC)
10.  Support if technically feasible. While I can respect the stance that they are not elected, we *are* trusting them already to make the call that a file is validly licensed, so not trusting them to simply view deleted files does not make much sense to me. The ability to see a file would often help in making their determination, I'm sure. From the sounds of it, the ability would not let them actually modify anything at Commons, which is the point where I would prefer to have a community-approved member. There is a substantial OTRS backlog, so OTRS volunteer time is relatively scarce and quite valuable, and anything reasonable we can do to speed up their work would be extremely helpful. To me, this seems like a very reasonable proposal along those lines. Carl Lindberg (talk) 11:56, 2 July 2017 (UTC)

    Sorry Carl, it is more correct to say that "we" have no control over who has access to the Commons queue, so literally "we" do not trust whoever has access as the Commons community no longer is any direct part of that decision. If the Commons community had an open and transparent way to decide who we trust to have access to the Commons queue, effectively acting for the community when they correspond about cases, then my viewpoint would be completely different.

    Reading above, Krd put it more simply than me, "OTRS members are not trusted users regarding to Commons point of view as they are not appointed by the Commons community." --Fæ (talk) 12:02, 2 July 2017 (UTC)

    Right -- I just don't see the ability to view deleted files as requiring that level of trust. They can't actually undelete the files, etc. Carl Lindberg (talk) 12:17, 2 July 2017 (UTC)

    It's possible to over simplify the things that can go wrong. The trust being required is that unelected OTRS volunteers, using identities that may be both secret and separate from any Commons identity, will be able to examine (and copy) deleted files of any type. They will then make decisions about whether the image should remain deleted or not, based on information that may remain secret, without any reference to a Commons administrator. For a file to be undeleted, we should then in theory have an UNDEL request that says "trust me, I'm from OTRS", without necessarily having any other information that the OTRS volunteer saying it's okay to undelete a file. For a file that remains deleted, no Commons administrator may ever know about the secret correspondence that was rejected.

    Now, Commons administrators are publicly accountable to the Commons community for their actions and have been elected. This proposed change significantly chips away at that trusted status by devolving access to deleted material to appointed but unelected OTRS volunteers that pass no specific competency test. Unlike some other trusted roles outside of Commons, OTRS volunteers have had a difficult history, including some globally banned users having been OTRS volunteers with access to the Commons queue, yet there may never be any retrospective public accountability for their OTRS decisions, especially for material where there was no visible public action on Commons. I could provide more detail and scenarios, to question how serious the "level of trust" is for these Commons rights, but this feels like it's becoming too much of a tangent. Thanks --Fæ (talk) 12:49, 2 July 2017 (UTC)

    You mean exactly the way they have access to the OTRS-sent information now but Commons admins don't, and they request undeletion now on that basis, and we are supposed to trust them (and do)? Generally in the undeletion requests, if the identity/licensing of the owner was the only thing in doubt, our admins trust the OTRS folks based on that information they can't see. But if there is some aspect the admin is concerned about that wasn't addressed, they can question the OTRS person in that discussion. Giving them the ability to see the deleted files doesn't stop that process at all -- it just gives the OTRS folks some (needed) information. In fact, admins and OTRS could discuss elements of the image on the undeletion discussion this way without it needing to be (temporarily) undeleted for everyone else as well. It's possible the OTRS member setup/vetting in the first place may not be the best -- but if WMF is trusting them with the private contact details and communication related to the images here, I don't see the danger in allowing them to *see* deleted media (which was once visible to all anyways) -- deleted mainly because we should not make it generally available). I do not think it would be a good idea to give them undeletion (or any other modification type) privileges -- just that they can see the content to more accurately identify it, better discuss it, etc. OTRS is part of the licensing system on Commons, and it sure seems like they should have the information needed to do their job. Like anyone else, they should be able to justify the undeletion reason when asking for it -- that becomes a public record of that activity. If they add an OTRS tag before a file is deleted, well, everyone can still see the content at that point and that can happen now. I confess I really don't see the danger of *seeing* the deleted content; they already have access to the private OTRS communications. Carl Lindberg (talk) 15:42, 2 July 2017 (UTC)

11.  Oppose per Krd. --Steinsplitter (talk) 12:08, 2 July 2017 (UTC)

Discussion

• Why are OTRS members trusted users? AFAIC trusted users are those elected by the community and OTRS members were never elected. In fact, a while ago a Russian Wikipedia user was banned by an ArbCom and remained banned for two years, but remained an OTRS member during the whole duration of the ban (and I believe still is an OTRS member).--Ymblanter (talk) 12:20, 28 February 2017 (UTC)

  Well, to avoid this kind of option we can add it as a request in COM:RFR and only approved users may accept the right. If the attitude of OTRS to let users be volunteers just because they asked to be so, this permission will be under Commons control (can be usfull also for local wikis). it will distinguished between OTRS volunteers withe the permission and who did not get one.-- Geagea (talk) 13:30, 28 February 2017 (UTC)

  As soon as they explicitly get a permission on Commons and do not get grandfathered in I do not have a problem with the proposal.--Ymblanter (talk) 13:33, 28 February 2017 (UTC)

  I want to emphasize that to be an OTRS member is not so easy. I know at least one user from Hebrew wiki that apply to be an OTRS volunteer and he was denied. Also I know another member that his permissions were removed because the way he handled the tickets. The application is reviewed by admins and other OTRS members. see here. Hanay (talk) 10:23, 1 March 2017 (UTC)

  This is a low risk permission as it is basically "read-only". What possible abuse could OTRS members cause by viewing deleted images? Sebari – aka Srittau (talk) 13:00, 1 March 2017 (UTC)

  This is not a good argument, since it implies anybody should be able to see deleted images. There are some good reasons why this option is not available to everyone.--Ymblanter (talk) 13:04, 1 March 2017 (UTC)

•  Comment That's seems to be a good idea and may be useful. But if the fact to give advanced permissions to users who have not been elected by our community is an issue. Then we can condition the access to this new group with 2 conditions 1/to be an OTRS member, 2/ to be elected in a kind of request for right within our community, with the possibility to remove this right if it is necessary while the user stay an OTRS member. In that case I tend to support. Christian Ferrer ^(talk) 12:06, 7 March 2017 (UTC)

I do agree with Christian Ferrer: it is necessary some sort of blessing from the Commons community, even if it's a quick check that the user has a clean recent contribution record. --Ruthven (msg) 13:35, 7 March 2017 (UTC)

•  Comment. I agree with all the comments her, it shouldn't be an advanced permissions. The permission should be added only per request in COM:RFR. But this kind of permission does not exist yet and should be created. I made a clarification above. Hopefully it's clear now. If you think something should be improved in the original suggestion feel free to do so.-- Geagea (talk) 14:40, 7 March 2017 (UTC)

• This has already been declined multiple times. Here's an email from krd:

This has already been discussed at Commons several times, and the fact is that these rights cannot be applied to OTRS agents but only to validly elected Commons admins. For the reason that deleted versions (copyright violations) may only be visible to as few persons as required, which are the Commons admins.

This is a requirement of WMF legal, and should not be discussed again and again. Please save community time and don't start public discussions on this topic.

DatGuy (talk) 16:56, 7 March 2017 (UTC)

To give advanced permissions to all OTRS members and to give, after a request for right with a vote, these permissions to carefully selected trusted users who have OTRS access is not exactly the same thing. Christian Ferrer ^(talk) 19:04, 7 March 2017 (UTC)

My email is at this pastebin. DatGuy (talk) 20:12, 7 March 2017 (UTC)

• Though every one is of course free to have it's own point of view, to read at least the 3 or 4 last oppose votes, I wonder if they have notified the proposal "request in COM:RFR and only approved users". That's said Krd's comment is not untrue, OTRS members can make a rfa... Christian Ferrer ^(talk) 08:51, 11 March 2017 (UTC)

• As a former OTRS member, I always desired to see the deleted files. But, as trust is an important part of this project, I think only selected OTRS members may have this "special" permission. This may be implemented as a second OTRS group like "Advanced OTRS members" (for users who're already OTRS members), elected by the community. --Amitie 10g (talk) 12:43, 11 March 2017 (UTC)

• Instead of giving deletedhistory right, maybe this should give viewdeletedfile instead. (It only lets you view deleted stuff in File and file_talk: namespaces). Bawolff (talk) 21:28, 31 March 2017 (UTC)
•  Comment

  @Counterargument: "OTRS members are not trusted users" This sounds absolutely implausible for me. In most cases on OTRS are much more sensible information visible as on files. An untrustworthy OTRS member would be much more hazardous as an untrustworthy "file viewer".

  @Official meta page: Volunteering for OTRS "confidential nature of the work" Willing to sign the OTRS users confidentiality agreement, considering the access to nonpublic information policy. -- User: Perhelion 23:33, 6 May 2017 (UTC)

Because OTRS members sign a confidentiality agreement, they are trusted by the WMF not to divulge confidential information. The trust we are talking about above is entirely different: OTRS rights are not granted or revoked by the Commons community so ipso facto they are not trusted by the Commons community. Storkk (talk) 15:02, 10 June 2017 (UTC)

•  Comment. As a matter a fact, the votes that based on the claim "OTRS volunteers are not trusted", simply indicate that we don't trust Commons admis judgment is good enough whether user is trusted or active in commons. -- Geagea (talk) 13:12, 2 July 2017 (UTC)

I may be missing something, I don't see how whether the Commons community is confident to agree that non-Commons-admin OTRS volunteers will be granted deleted file viewing rights without any vote process, has any bearing on whether the community trusts its own openly elected administrators. These two things seem unrelated. --Fæ (talk) 14:45, 2 July 2017 (UTC)

No, only Commons admins can grant the permission to OTRS volunteer that asked it in COM:RFR. Any community member can oppose. The suggestion speaking about giving permission to see deleted files, not to undelete them.-- Geagea (talk) 16:50, 2 July 2017 (UTC)

Allow all users to use Upload Wizard's flickr option

Upload Wizard screen with flickr option

I was recently coaching someone on how to use Upload Wizard's flickr option to speed up his work with uploading flickr images, when we realized that he does not work with the same Upload Wizard I use. Apparently only only administrators and image-reviewers can use Upload Wizard to upload flickr images and the rest of the people has to be using other tools, like Flickr2Commons, Flinfo, F2ComButton to accomplish the same task. The reason would be :

1. Fairness I see no reason to let all users to use one tool and only some users to use a different tool with the same capabilities.
2. Avoid confusion and waist of time of figuring out who can use what tool. That way we can simplify or expand the documentation of the tool.
3. We put a lot of thought into proper handling of many tricky cases related to flickr uploads. Most files should go through the "official" pipeline, which should be most up to date. If we allow everyone to use Upload Wizard than I assume demand for other tools will diminish.

--Jarekt (talk) 04:14, 10 June 2017 (UTC)

•  Support as proposer --Jarekt (talk) 04:14, 10 June 2017 (UTC)

•  Oppose until the issues mentioned in phab:T90004 are resolved. And we've been through this already. —LX (talk, contribs) 10:42, 10 June 2017 (UTC)

LX, My previous proposal (about which I already forgot about) was proposed 3 years ago. A lot can change in 3 years. As for phab:T90004 issues, I see

• "Remove Flickr checking from client side" issue mentioned. I assume it is related to "sever side flickr review". Can someone explain why is this important?
• There was also mention the need for "blacklist check". We seem to have it now. See Commons:Questionable_Flickr_images#Flickr_users and User:FlickreviewR/bad-authors. Is it working properly?

Also if people are not using Upload Wizard, then they are using Flickr2Commons and other tools. Are above issues handled better in those tools? --Jarekt (talk) 14:20, 10 June 2017 (UTC)

Jarekt, the Flickr checking is currently done on the client side, which is not robust at all, because it allows meddling from userscripts and other code that may be in a user's browser. I proposed doing the checks on the server side to increase the likelihood of preventing bad uploads. And while other tools are less robust in this sense, as the primary entry to our upload pipeline, I think UploadWizard needs to be better. If Commons decides that yet more complications to the review pipeline are desirable, then I suppose it is time for a change! --MarkTraceur (talk) 14:45, 10 June 2017 (UTC)

MarkTraceur, So it sounds like a bit like "a chicken and egg problem". phabricator:T100062 is low priority if the only users allowed to use the tool are admins and image-reviewers and at the same time it is blocking enabling it for all users. To me Upload Wizard still seems safer than other tools we are currently forcing regular users to use. --Jarekt (talk) 15:06, 10 June 2017 (UTC)

We can use the flickr reviewer bot until the issue is fixed. I proposed this a while ago (on phab or irc). --Steinsplitter (talk) 15:09, 10 June 2017 (UTC)

I think that is a good solution. --Jarekt (talk) 02:23, 11 June 2017 (UTC)

@Jarekt: What is meant by the review system being client side is that {{FlickrVerifiedByUploadWizard}} is still a trusted tag, and anyone with enough technical knowledge can fake that tag with UW (and one can imagine that the knowledge can spread via black market). --Zhuyifei1999 (talk) 16:24, 10 June 2017 (UTC)

•  Comment Getting on my soapbox for a moment here. I'm very wary of anything that's going to increase the number of flickr transfers by inexperienced users: flickrwashing issues aside, there is the less-noticed problem of identifying information. All Commons files should have three kinds of identifying information: a descriptive filename to make the contents of the image obvious, a clear and encyclopediac description of the file in the wikitext, and properly considered specific categories. Most flickr files have neither a Commons-style descriptive filename nor an encyclopediac description of the file, and flickr uses non-hierarchical tags rather than hierarchical categories. I have had several tense discussions with very experienced and trusted users (who are overall excellent contributors) because I felt their flickr transfers consistently failed to properly include one or more kinds of this crucial information; less-experienced users are less likely to understand the importance of good filenames and categories.

The existing non-admin tools (including Flickr2Commons, which I use even as an admin) also do not enforce any of these descriptive properties; however, they tend to lend themselves more towards experienced users. Any change to flickr transfers (including this proposal, which I think overall could be very helpful) really needs to guide users towards adding proper information. That should probably include steering them away from problematic information (users should have to input file names rather than using the flickr defaults), maybe some basic filters (minimum filename length, minimum description length, minimum number of categories) and a clear message of why the identifying information is required. Pi.1415926535 (talk) 18:35, 10 June 2017 (UTC)

Pi.1415926535 I share your concerns but we have the same issue with regular uploads, but nobody is proposing prohibiting new users from using it. A lot of problems with bad edits can be solved by allowing only experts to edit but that is not how wiki works. If we worry about bad categorization lets propose to delete unused and uncategorised files uploaded that way, or maybe it is better to have them than than not to have them. --Jarekt (talk) 18:50, 10 June 2017 (UTC)

•  Support except for non-autoconfirmed accounts. --Yann (talk) 09:54, 17 June 2017 (UTC)
•  Support with Yann's caveat. If it's a problem (like mobile uploads were), then we can turn it off--no reason to keep a useful feature from a great number of constructive editors without even seeing what happens in the wild. —Justin (koavf)❤T☮C☺M☯ 05:01, 21 June 2017 (UTC)
•  Support for autoconfirmed users. Regarding Pi.1415926535's objections above, UploadWizard does require a description (and even enforces a minimum description size), and if you don't provide a category, it gives you a warning. Obviously there is never going to be an upload tool that can force the user to write an encyclopedic description and "properly considered specific categories". The idea that we should only allow users to import from Flickr through tools that are hard to use seems counter-productive. If this leads to a flood of Flickr-washing, of course we should turn it off, but let's give it a shot and see what happens. Kaldari (talk) 02:21, 23 June 2017 (UTC)

Restrict Video Uploading

Wikipedia Zero abusers are uploading hundreds of files per week, hitting 1 terabyte of pirated content. With Embedded Data Bot running, the pirates have switched from JPEG+RAR to blatant copyright violations. I'm hopeful for disabling access to unpatrolled files for WP0 users, but it requires WMF engineering and thus likely only ready in 2018.

The following table shows the abusers are prolific video uploaders compared to normal accounts.

Non-Autoconfirmed Uploads (Last 6 months)

Medium	Files	Deleted	Del%	Deleted bytes	Not deleted	Users	Blocked	Block%
SVG	8,421	937	11%	0.2 GB	1 GB	1,637	51	3%
Images	498,895	127,599	26%	376 GB	997 GB	158,969	5,527	3%
PDF	6,927	6,484	94%	106 GB	4 GB	3,724	1,038	28%
AUDIO	3,222	2,089	65%	236 GB	2 GB	1,118	719	64%
VIDEO	3,961	3,611	91%	452 GB	15 GB	1,870	1,406	75%

Without anything in the pipeline for video we need to consider disabling video uploads from new accounts. This would be an edit filter that could take into account: account age, number of edits, autoconfirmed and confirmed (for edit-a-thon events) account groups, if an email address was registered, file size, dimensions of the video (YouTube only outputs muxed 360p.webm), and if added video duration. —Dispenser (talk) 13:52, 14 June 2017 (UTC)

•  Support--Steinsplitter (talk) 15:31, 14 June 2017 (UTC)
•  Support --Alaa :)..! 16:57, 14 June 2017 (UTC)
•  Support, unfortunately. Storkk (talk) 17:00, 14 June 2017 (UTC)
•  Neutral I would prefer to see a more specific proposal that can be tested for impact and has options for gradual roll out and roll back later. For example we could restrict video uploads to 10 edit+ accounts and gradually increase that if there is evidence it's being worked around, with agreement to roll back to a lower number after a planned period. As for Youtube, it's not that hard to take other webm sizes that Youtube makes available (such as 1280x720) and merge in an audio stream, so I'm unsure about technically unusual constraints. Video uploading remains pretty bad on Commons, putting up more barriers to entry, without any planned development to improve our front end or transcoding support, does not look good for the future of Commons. --Fæ (talk) 17:38, 14 June 2017 (UTC)
  • Its worded broadly as the pirates have been evading our efforts to stop them. Finding multiple ways to defeat the bot. We are running this because 5-10% (depending on how its sliced) of legitimate uploads will be blocked. —Dispenser (talk) 19:05, 14 June 2017 (UTC)
    • Sure, I would rather see a limited and specific proposal than giving indefinite carte blanche for a change that will create barriers for newbies, and possibly others, wishing to improve our rather indifferent and meagre collection of educational videos (compared to other hosts). Once introduced, I don't see how this change would ever roll back, making it a serious alteration in how we welcome users. My focus is on contributors rather than pirates, and while we want to ensure pirates do not disrupt this project in any way that starts to affect the wider community, it is a greater imperative to ensure supporting contributors and the experience for reusers remains our joint primary concern when assessing the value of changes. --Fæ (talk) 11:39, 15 June 2017 (UTC)

•  Support, at least for multipage-PDFs, audio and video. Recent-upload patrolers have enough to do with regular copyvios. --Túrelio (talk) 18:42, 14 June 2017 (UTC)
  • The PDF, XCF, DjVu are high since programming the bot for them was tricky, so the pirates exploit them. For Audio, I have several solutions lined up. —Dispenser (talk) 19:05, 14 June 2017 (UTC)
•  Support Christian Ferrer ^(talk) 18:47, 14 June 2017 (UTC)
•  Support --jdx ^Re: 19:24, 14 June 2017 (UTC)
•  Support this is taking up precious time and effort which could be better directed elsewhere. The impact on good faith users will be virtually non existent (out of the hundreds of videos I've reviewed and deleted, I can only recall 2 legitimate videos which would have been prevented). Nick (talk) 21:39, 14 June 2017 (UTC)
•  Support Personally I would like to turn off uploads from Wikipedia Zero users because they are more of a problem than a benefit. But we can't do that because WMF. And the WMF would obviously not do that too. Those users are given the privilege to upload files when they registered an account, as long as they won't misuse the privilege. And because they abused it, the privilege given to them must be removed. --★Poyekhali 11:24, 16 June 2017 (UTC)
  • Range blocking Morocco (11 million IPs) where the abuse is coming from is still an option. —Dispenser (talk) 16:40, 16 June 2017 (UTC)
    • Seriously? -- Tuválkin ✉ ✇ 12:11, 23 June 2017 (UTC)
      • Yes, this has been discussed in a private discussion in Phabricator (I or someone joined in the discussion can add you to the discussion, if you are interested). See also phab:T167915, which is an alternative solution to range blocking Morocco. ★Poyekhali 02:30, 24 June 2017 (UTC)
        • I shouldn’t have asked, but it’s a brave new world indeed. I’ll peruse that link now, half fearing to find parallel subthreads about draining the swamp and locking her up. -- Tuválkin ✉ ✇ 19:57, 26 June 2017 (UTC)

•  Support --Discasto _talk 13:20, 16 June 2017 (UTC)
•  Support   — Jeff G. ツ 14:07, 16 June 2017 (UTC)
•  Support — Speravir – 22:08, 16 June 2017 (UTC)
•  Support For video, audio, and PDF. --Yann (talk) 09:51, 17 June 2017 (UTC)
•  Support +1 for video, audio & pdf. --Achim (talk) 14:28, 21 June 2017 (UTC)
•  Support +1 for video, audio, and PDF. -- Tuválkin ✉ ✇ 12:11, 23 June 2017 (UTC)
•  Support - noting Fae's reservations - nevertheless the evidence provided by dispenser needs to be acted upon JarrahTree (talk) 01:50, 24 June 2017 (UTC)

Filter

Okay, i think we have consensus here. @Dispenser:/@Jdx: can you propose a filter code? Maybe based on 180? --Steinsplitter (talk) 11:15, 24 June 2017 (UTC)

My availability is limited for the foreseeable future. Dispenser (talk) 14:03, 24 June 2017 (UTC)

Message from the Partnerships & Global Reach team about the Wikipedia Zero service

Hello everyone.

We, the Partnerships and Global Reach team, are responsible for the Wikipedia Zero program. We wanted to let you know that we have following this conversation and have heard the concerns raised by the community here on Commons.

Our team is aware that the Wikipedia Zero service has been subject to abuse. We understand that this situation is frustrating. We are saddened to see this happen and have been working on finding feasible solutions to address this issue over the past year.

When this issue was first flagged to us in early 2016, we worked with the engineering, security and community teams to determine the best course of action to take. As a result of this review, we determined that editors needed to have a way to identify and focus just on content uploaded by Wikipedia Zero users. We then created a filter action for AbuseFilter to do exactly that. But a year later, the core problem has escalated to the point where this tool alone is not enough to deal with it.

It looks like that you have come up with a potential way of addressing the issue here. We have also identified further potential solutions on our end, but unfortunately, none of them are ideal. There are many factors in play here, which makes it hard to find an effective and quick solution this problem. We want to make sure the program is not creating more work for copyright patrollers and editors in general. But, we also want to ensure that people using Wikipedia Zero can have access to the entire Wikimedia experience, which includes the ability to contribute to the projects.

In the next couple of days, we intend to share what these possible options are, and make a decision based on your inputs. In the meantime, rest assured we have heard you and are doing our best to solve the issue.

We are looking forward to opening a discussion on this subject next week. AVrana (WMF) (talk) 19:32, 26 June 2017 (UTC)

Follow-up from the Partnerships & Global Reach team about Wikipedia Zero abuse

Hi everyone, I’m with the Partnerships & Global reach team, and I am following up with our earlier message to discuss how we might address the Zero abuse situation. Here are the different options being considered. I’ll start with the options that are the furthest along.

• A Wikipedia Zero partner who is experiencing abuse is experimenting with a method to see if they can discourage very large downloads but still allow normal Wikipedia use. If successful, it could help curtail the overall abuse. But even if it’s effective, the effort required by each partner suggests that this will not be implemented universally.

• Based on the proposal here to restrict video uploading, we have arranged for engineering to implement a method to disable some types of uploads from specific Zero partners. We’ll need to make sure this is as targeted as possible in order to help avoid penalizing legitimate uses, particularly things like contributing to Wiki loves Monuments, valid images, etc.

Other suggestions we’re investigating right now:

• Disable serving unpatrolled new files to Wikipedia Zero users. Conceptually, this seems like a good approach, as it would discourage abusive uploads if Wikipedia Zero users could not download unpatrolled / pirated content for free. I’m investigating what kind of engineering commitment this would require to see if this is an option we can move ahead with or not.
• Enhancing TBayer's tool to detect and report abusive uploads. There may be some improvements we can make to his tool with some engineering work, and we are discussing the enhanced features and possible engineering support to implement them.
• File removal persistence. Not sure the status of this but will find out more.

Regarding these efforts, I expect to learn and share more details about the options we’re investigating soon.

The abuse issue is not simple, and I appreciate the work and thought that everyone has already put into this. We’d really like to help get the abuse situation under control, and any thoughts you have that might help with that are welcome. DFoy (WMF) (talk) 03:12, 6 July 2017 (UTC)

• • @DFoy (WMF): What does "File removal persistence" mean? Kaldari (talk) 23:31, 6 July 2017 (UTC)
  • @Kaldari: This refers to a comment in here about a webm file still being accessible after deletion. DFoy (WMF) (talk) 00:19, 8 July 2017 (UTC)

@Kaldari: A more detailed description of what appears to be the same issue is at phab:T109331. This appears to be a huge problem currently. E.g. among the files detected by the above mentioned tool that I'm currently running, all of the top 6 files for July 7 have this problem - admins had already found and deleted each file (in that case, on hewiki), but it remained accessible via the direct upload.wikimedia.org link for many hours afterwards and saw a lot of downloads. More detail in the internal discussion at [2]. This is likely a major reason why the uploads by that particular piracy site have not stopped on that project despite consistent admin intervention in recent days and weeks. (And obviously a concern not just in case of WP0 abuse.)

According to MaxSem there is a manual workaround: The file is gone once one purges the cache. Regards, Tbayer (WMF) (talk) 01:50, 8 July 2017 (UTC) Edit: Max clarified that this needs to be a server-side purge, which can only be initiated by developers. Regards, Tbayer (WMF) (talk) 02:10, 10 July 2017 (UTC)

@Tbayer (WMF): This purge should happen any time a Commons Admin deletes a file or revdels an instance of a file, and the capability to do such a purge should be incorporated into the Commons Admins' toolsets.   — Jeff G. ツ 04:29, 13 July 2017 (UTC)

Enabling Gadget deepcat activation via Special:Preferences#mw-prefsection-gadgets

Hi all, The gadget deepcat is an extremely useful tool to search entire categories (including up to 15 sub-categories deep). This is available on the German Wikipedia via the preferences page. I would like to propose that it be made available on Commons via Special:Preferences#mw-prefsection-gadgets > Gadgets > Tools for categories, enabling a simpler way to activate it (as for example, with Cat-a-lot). The present approach to activating deepcat is a bit cumbersome (see discussion). I know there is some overlap between the already-available FastCCI and deepcat, but they are not identical in several ways that are very significant for those searching for content on Commons:

• FastCCI only searches categories (intersections such as incategory:A and incategory:B; or, in A but not B and so on.) Deepcat searches down a category tree plus any other search term that is added. For instance, a FastCCI search on the Category:Fish page for incategory:Fish and incategory:Tuna yields no results, while a deepcat search (deepcat:Fish Tuna) picks a bunch of results including those where the word "Tuna" is in Description or filename (and not necessarily in a category).
• FastCCI only provides a gallery-type view of images; the results of a deepcat search is like that from a regular search, showing thumbnail, filename, description etc.
• FastCCI is available to all visitors to a category page, deepcat only to logged-in users (would be great if deepcat can be added as an option on at least 'Advanced' search for all visitors/users--but that perhaps should be a separate proposal?)

To summarise, deepcat is useful to search not just by category, but for a word in caption or filename, down a large category hierarchy and it would be helpful to enable its activation via Special:Preferences#mw-prefsection-gadgets. Thoughts? --Shankar Raman (talk) 02:07, 1 July 2017 (UTC)

 Support I don't see a significant downside --Zhuyifei1999 (talk) 03:10, 1 July 2017 (UTC)

 Support — Speravir – 03:56, 1 July 2017 (UTC)

 Support This will be very useful. Thanks for taking this initiative. --Jegan 06:30, 1 July 2017 (UTC)

 Support Why not? --★Poyekhali 11:29, 2 July 2017 (UTC)

How to upload a .pdf file

Moved to Commons talk:Abuse filter#WP0 filter preventing PDF upload. —LX (talk, contribs) 05:47, 4 July 2017 (UTC)

Remove automatic switch of language based on geolocation

When one views Wikimedia Commons from a non-English speaking country, they will see a notice saying "View Wikimedia Commons in (language)", where (language) is a language the software determines the reader likely to speak based on the country the reader is from. Even if one closes the notice, the language of the user interface will still automatically switch to that language without prompting when one views certain pages (such as the Search page). It is extremely difficult to find the English choice out of the many choices in the Language Select box in the sidebar in order to return to English, and the browser forgets my English preference typically in one week or less.

Many translations of the interface are of poor quality and often mix English with the target language. I personally is not from an English-speaking country but I strongly prefer using English to view all Wikimedia wikis. This may also affect users who view Commons while traveling to a foreign country. I believe that Wikimedia Commons should remove this feature of automatically switching languages, and change it only when explicitly requested using the Language Select box. Thank you.

Note: The same issue is also present in Wikidata, but not other multilingual Wikimedia wikis, such as Meta-Wiki, which apparently uses a different translation system. Any ideas? 211.100.57.174 06:58, 17 July 2017 (UTC)

The code is in MediaWiki:AnonymousI18N.js. It uses navigator.language (what your browser tells us), not geolocation. Dispenser (talk) 11:14, 17 July 2017 (UTC)

Thank you for mention that. Do you have any thoughts on whether the proposal should be implemented? 211.100.57.174 12:15, 17 July 2017 (UTC)

Do you mean ignore the user's browser settings when deciding which language to present to them? The way you described the problem, it seemed like the language selection was flaky, so that even after selecting English it would still revert to the other language sometimes. That could just be bugs to be fixed. --ghouston (talk) 12:28, 17 July 2017 (UTC)

@Perhelion: My analysis: the script changes the uri when wgUserLanguage != wgContentLanguage (i.e. uselang= is used), but changes the uselang= to that of the custom wgAnonUserLanguage, which prioritize the value set in cookie over that in uselang=, then browser settings. What do you think about having wgAnonUserLanguage prioritize uselang= over that set in the cookie, to keep the uselang= consistent over links? --Zhuyifei1999 (talk) 14:30, 17 July 2017 (UTC)

See also phab:T161517 --Steinsplitter (talk) 15:12, 17 July 2017 (UTC)

My intended proposal was to remove the script's use of navigator.language so that the "View Wikimedia Commons in (language)" notice is not displayed and that the language always remain English until requested explicitly by the user. That means preventing the script from creating the "View Wikimedia Commons in (language) notice. In addition, if neither the uselang parameter, the hook, nor the cookie is present, the script should unconditionally use English (or the fallback conf.wgUserLanguage, which I cannot understand but presumably refers to English on this wiki). This proposal does include ignoring the browser/operating system's language settings, but because currently, after manually reventing to English, the language does not automatically return to the browser's language again until the cookie resets (which explains the approx. one week delay), so it is not a bug. Thank you for your understanding. 211.100.57.174 00:32, 18 July 2017 (UTC)

Image versions: make it possible to use a specific version of an image and to set a default version for an image (File history)

This proposal is best explained with the help of a concrete example:
So for the Larsen Ice Shelf article I uploaded an image from ESA and created multiple modified version of it: see the "File history" under c:File:Larsen C breaks.jpg.
For instance one image is a cropped and rotated fullscreen version and one a fullscreen image only showing the region with the rift.

Now I'd like to be able to do 2 things:

• Setting the default version of the image which is shown at the top of the page and whenever [[File:Larsen C breaks.jpg]] is used. In particular I'd like to set the default image to the first or 2nd image (this could be decided upon on the talk page).
• Furthermore I'd like to (be able to) add any specific version of the image to articles. E.g. like [[File:Larsen C breaks_201707121747.jpg]] or [[File:Larsen C breaks_v2.jpg]] or [[File:Larsen C breaks.jpg?version=2]] or alike. If I choose the default image and not a specific non-default version then the image changes whenever the default image changes. When uploading a new version of a file there could be a checkbox saying "Replaces default image" (y/n).

This functionality would be useful for many things. It would truly open source commons images and make them conveniently modifiable (and attributable) etc. It would allow for more accurate, debatable, extendable, improvable image contents; better collaboration, better allows building upon others' work instead of having to start from scratch, more images, saved time, more dynamic and living graphic illustrations etc.

---

One potential issue I see that's not really relevant in my exemplary case but could be in others: new versions could warrant new/changed categories and descriptions. And sometimes they might build upon multiple images instead of just one. We probably need to come up with a good way to deal with this. For instance there could be some criteria for images to show in the file versions section of an image such as its conceptual relatedness/continuity and/or allowing for new versions to be "forked" to new images which in their file history/versions link back to that image via a single, first "origin" entry (including the possibility to manually set multiple such "origin" images).

This proposal also related to my phabricator issue "Allow the upload of .psd .pdn [...] files on Wikimedia projects" as image-editing program project filetypes allow for picking off any image-project wherever another left it - especially digital art and illustrations. Let's please make Wikimedia Commons the best it can be and, as a leader in the field, become one of the first to open source images. My proposal here wouldn't be too hard to implement (potentially a software development effort measured in days with some additional betatesting of the prototype) and would significantly advance this website and the project in general.

I hope this the right place to propose this and that I have explained my proposal well enough. Please let me know if there are any questions or if you have any complementary ideas.

--Fixuture (talk) 14:03, 17 July 2017 (UTC)

• I read your proposal and I can definitely see benefits, but I wanted to ask if uploading a new version of the file as a separate file currently has disadvantages that this method does not. COM:OVERWRITE as a policy currently recommends that for the most part, changes to a file need to be uploaded as a separate file. This is in essence already a method of "forking" an existing file. It does mean that there are often multiple files of the same work with similar names, but for the most part people have been using <gallery> and {{extracted from}} (and similar) templates to indicate to file page viewers which is which. Although these can be insufficient for larger numbers of alternate versions of a photo, there are organisational techniques that we could come up with to more appropriately bind the multiple versions together. One example that springs to mind is {{Mona Lisa versions}}, which contains a gallery that is easily updatable to maintain a link to all versions on each page's version. This current method of using separate files also appears to solve the potential issue you raised about categories changing for each version. If the new version is a separate file with its own file page, this is alleviated, they are already independent pages whose categories can be altered accordingly. seb26 (talk) 16:06, 17 July 2017 (UTC)

• I.m.h.o. Fixuture’s concerns should be addressed by “forking”, as suggested by seb26. Non-current items in a file’s history are there to enable forking and to document the file history, but should not be accessable from elsewhere, to the risk of grave instability, actually worsening the proposal’s original concern. -- Tuválkin ✉ ✇ 00:08, 18 July 2017 (UTC)