Wikimedia Commons

Commons:Village pump/Proposals/Archive/2014/10

< Commons:Village pump‎ | Proposals

Translation administrators

The following discussion is closed, and will be archived soon. I see clear consensus in favor of this, so this proposal is passed. — revi^ 09:28, 6 October 2014 (UTC)

In my opinion, the current translation admin approval system is not the best because there is no policy how to deal with it. Translation admin is a powerful tool (if you break pages, a lot of time is needed to fix the broken/wrong marked page). I suggest to make the following lines a policy:

  • Commons administrators are able to add (and remove) themselves to the group if they are willing to help. (status quo)
  • Bureaucrats can assign this right upon request on COM:BN. The request should remain open for at lest two days to allow community input. The Bureaucrat determines whether there are no severe objections to the candidate, if there are not, the 'crat will close the request and add the candidate to the group of translation admins. (Similar to Commons:License review/requests)
  • The right will be removed if the user does not use this tool for one year.

Regards --Steinsplitter (talk) 15:45, 1 September 2014 (UTC)

Support

  1.   Support --Steinsplitter (talk) 15:45, 1 September 2014 (UTC)
  2.   Support Jianhui67 talk★contribs 16:15, 1 September 2014 (UTC)
  3.   Support Yann (talk) 05:32, 2 September 2014 (UTC)
  4.   Support The inactivity-point is new. -- Rillke(q?) 12:21, 2 September 2014 (UTC)
  5.   Support Natuur12 (talk) 12:22, 2 September 2014 (UTC)
  6.   Support --Jarekt (talk) 12:59, 5 September 2014 (UTC)
  7.   Support --Motopark (talk) 13:10, 5 September 2014 (UTC)
  8.   Support — Revicomplaint? 13:53, 11 September 2014 (UTC)
  9.   Support JurgenNL (talk) 16:21, 15 September 2014 (UTC)

Oppose

Comments

Activity statistic --Steinsplitter (talk) 15:46, 1 September 2014 (UTC)

From time to time -- maybe once a month -- while doing NewPagePatrol, I come across a page that needs to be deleted that has the translation tag. Since I am not a Translation Administrator, I simply edit the page to remove the tag, then wait a few minutes for that to propagate through the system, and go ahead and delete the page. I'm not at all certain why we have the TA role at all -- it really protects nothing since anyone can remove the tag and thereby convert the page into an ordinary page, free from the restriction.

I certainly understand that edits or deletions of translated pages can cause major trouble, but we have many other pages to which that applies -- many templates, for example. Do we need to create the new role of Template Administrator? Or should we just rely on the good judgement of our Admins and our ability to restore anything done in error and not have these special roles? .     Jim . . . . (Jameslwoodward) (talk to me) 14:00, 15 September 2014 (UTC)

@Jameslwoodward: See, Commons:Requests for comment/Translate extension. Admins can selfadd to this group. The extension is not a protection, but a tool to help users translating pages. --Steinsplitter (talk) 15:44, 15 September 2014 (UTC)
I understand the tool, but it seems to me that requiring Admins to be TAs in order to delete or protect such a page is just erecting a fence that has a big hole in it, as I described above. .     Jim . . . . (Jameslwoodward) (talk to me) 16:55, 15 September 2014 (UTC)
See also this. --Steinsplitter (talk) 17:40, 15 September 2014 (UTC)

Note: This has been archived by bot, but unarchived to close. — revi^ 09:28, 6 October 2014 (UTC)

The above discussion is closed, and will be archived soon.

Request for community input on IEG proposal: editor interaction data sets and visualizations

As you may have heard, Editor Interaction Data Extraction and Visualization is an individual engagement grant proposal. I am working on this proposal with volunteer assistance and advice from Aaron Halfaker (WMF), Haitham Shammaa (WMF), and Fabian Flöck (Karlsruhe Institute of Technology).

We would greatly appreciate your comments on whether you support or oppose the general concept of this project, and any suggestions about how to refine the proposal.

Additionally, we would like to hear from you about which sets of editor interaction data, and what visualizations of editor interaction data, would be most relevant to your interests. We intend to prioritize our outputs with your comments in mind.

Please comment on the proposal talk page. Questions and feedback, both positive and critical, are helpful to us as the proposers, and also help the Individual Engagement Grants Committee [1] to assess the proposal.

Regards, --Pine✉ 18:31, 19 October 2014 (UTC)

[1] I am a member of the Individual Engagement Grants Committee. I am recusing from reviewing proposals in this funding round.

Global deleted image review

Back in 2008, it was proposed that commons admins be able to see deleted files on other projects. There was even a vote with 80% support [1] (And most of the objections raised at that vote seem to relate to a problem with oversight which is no longer true). Fast forward to today, there is now a user right named 'viewdeletedfile', which would allow a user to just view deleted pages in the file and file talk namespaces (They would be able to view both the deleted image, and the associated deleted description page. Viewing of revdeleted things (but obviously not oversighted things) in the File namespace is also included).

So, from what I understand, if the commons admins still want this ability, what is needed is:

  1. Consensus that commons still wants this
  2. A formal request to the stewards to create global group having the viewdeletedfile right.

Thoughts everyone? Bawolff (talk) 03:56, 23 October 2014 (UTC)

  • This only seems to check whether Commons want it. I don't think other projects (like EN) agree with this as many COM:Admins are in their black list. :) Jee 16:10, 23 October 2014 (UTC)
  • Probably should be. I have no idea what the procedure is for creating new global groups. My first thought was that there would have to be local consensus that its still wanted, followed by a larger global vote of if the larger wikimedia community is ok with it (?). I don't really know. Note that wikis would still be able to opt-out on a per wiki basis for those that don't want it. Bawolff (talk) 19:49, 23 October 2014 (UTC)
I started meta:Wikimedia_Forum#Implement_Global_deleted_image_review. Bawolff (talk) 20:05, 23 October 2014 (UTC)

Alright, its clear there is at least still interest from the commons community in doing this, lets move the discussion over to the meta RFC I just started at meta:Requests for comment/Global deletion review. Bawolff (talk) 23:28, 24 October 2014 (UTC)

Upload by URL also on Special:Upload

Tracked in Phabricator
Task T73897

Minor uncontroversial change, this change adds only an interface to Special:Upload to enable uploading from URLs. Change affects only users with upload by url right (sysops, LR, GWT). No oppose for a while therefore this proposal is successful. --Steinsplitter (talk) 16:52, 26 October 2014 (UTC)

Hi there, we do allow uploading by URL via the API - for GWToolset and Upload Wizard/Flikr. This is a very important feature for users who want to upload files > 100 MB as chunked upload doesn't work for many people (actually all people I know who tried didn't succeed). In the past this meant that you had to put the file on an external server, file a bug, paste the URLs there and wait for developer to do the job. Today we can use the API for that, thanks to this proposal: Commons:Village pump/Proposals/Archive/2012/11#Upload_by_URL. Uploading via API makes sense when I do a batch upload with a script but often I just have one file, made while travelling and just want to quickly upload it, without having my scripts and libraries available to me (or no time to write a script just for one file upload). Therefore I think it makes sense to activate the URL upload feature for Special:Upload. Uploading by URL is only allowed for a restricted group of users (Admins, Image Reviewers and GWToolset Users) and only the experts use Special:Upload still today. So I see no harm here. Technically it only means to set a simple variable in the Commons Wiki. --Manuel Schneider(bla) 12:50, 10 October 2014 (UTC)

I support that. —DerHexer (Talk) 13:08, 10 October 2014 (UTC)
Me too! Manuel knows exactly, what he want to do. Marcus Cyron (talk) 16:36, 10 October 2014 (UTC)
Me too. I just suffered through serveral attempts to use chunked upload, all of which failed. If we want to increase the number of people contributing video we need a solution, and this looks like a feasible way to go. --Vgrass (talk) 13:25, 10 October 2014 (UTC)
See Commons:Village_pump/Proposals/Archive/2014/09#Activate_Flickr_option_in_current_UploadWizard_to_all_users, Therefore:   Support in general but   Oppose for technical reasons. --Steinsplitter (talk) 13:36, 10 October 2014 (UTC)
Which technical reasons? Please note
  • I am talking about old Special:Upload, not about Upload Wizard
  • I am NOT talking about activating this for everyone - it will remain available only to the restricted groups Image Reviewers, GWToolset Users and Admins
  • the URL whitelist (as used by the API) is still in place - we only talk about setting $wgCopyUploadsFromSpecialUpload = true; everything else is already in place and active via API.
--Manuel Schneider(bla) 13:57, 10 October 2014 (UTC)
Oh, okay. Then support. Useful function. --Steinsplitter (talk) 14:08, 10 October 2014 (UTC)
  Comment Manuel, chunked upload works for me on single files and has worked quite well (so you now know "all - 1" ;-) ). I like the idea of a user right for URL uploads, but it would need a plain English explanation of how it ought to be managed and whether we would need a whitelist in the same way that the GWT works. I think that having the GWT would probably be an easy solution for users needing to do this, in almost all circumstances I can think of. Probably any user that would be trusted with URL uploads would also be trusted to use the GWT anyway. P.S. though you need to create a trivial XML file right now, you can use GWT to upload very small numbers of files. --Fæ (talk) 13:44, 10 October 2014 (UTC)
Hi Fæ, good that it chunked uploads work for you - you are the first saying that to me.
Re whitelist: The restrictions etc. are exactly the same as what we currently have. Only a restricted group of users, only whitelisted URLs. So to keep it short: We only discuss whether we switch on the URL form field in the old upload form or not. Technically and concerning security nothing changes. --Manuel Schneider(bla) 13:55, 10 October 2014 (UTC)
Search out and play with User:Rillke/bigChunkedUpload.js, it's a nice work-around.
I feel there are risks here in letting everyone have at URL uploads (even if restricted to the whitelist) and I do not know whether I ought to worry about them or not. Perhaps someone could explain the security side a little? If the risk is limited (pretty much) to what can happen with mass uploading from Flickr, then that would seem entirely managable... and if something went bizarrely wrong, such as 100,000 copyright violations in a week, then we could switch it off again and fairly easily mass delete if the files are nicely tracked by upload type. --Fæ (talk) 14:04, 10 October 2014 (UTC)
Looks like nobody reads neither my original proposal, nor the multiple comments I made on this:
THIS IS NOT TO ALLOW URL UPLOADS TO EVERYONE! Only those who already can do this today will be able to use this feature. This proposal simply asks to make a feature which is already switched on available via Special:Upload, to use it without special tools. That's all. --Manuel Schneider(bla) 14:13, 10 October 2014 (UTC)
Probably an issue with plain English, I did not quite read your proposal that way and it makes more sense in upper-case  . I do not understand why there would be an objection if there is no new security issue. --Fæ (talk) 14:55, 10 October 2014 (UTC)
You are actually the only person having an objection here - after my clarification even Steinsplitter agreed with this proposal (see above). --Manuel Schneider(bla) 16:37, 10 October 2014 (UTC)
Wouldn't you still have to request whitelisting for every non-Flickr upload then, if we keep the whitelist? Someone could close and open a bug for Commons:Requests for comment/Allow transferring files from other Wikimedia Wikis server side …    FDMS  4    15:36, 10 October 2014 (UTC)
This is right but for the video project we do have a servers that have been whitelisted (Wikimedia CH GLAM upload server, upload-glam.wikimedia.ch, my own video server upload-80686.wikimedia.ch). There are many servers that are whitelisted, for regular contributor it can be easily done. --Manuel Schneider(bla) 16:37, 10 October 2014 (UTC)
Basically everyone who had to do with the GLAM Wiki Toolset can use this feature and for some things it simply makes things easier because it can be used without using a script that does the API magic. It is a minor feature we are discussing here, so actually I hope that we just wave it through because there is no need to discuss a lot here. That doesn't mean that we shouldn't improve the overall upload processes and tools. But for now this little setting will help with certain usecases. --Manuel Schneider(bla) 16:40, 10 October 2014 (UTC)
Ah … Well,   Support, but please include a warning message saying that using Special:Upload, a {{FlickrReview}} template has to be added manually.    FDMS  4    16:42, 10 October 2014 (UTC)
  Comment if i remember correctly, the UI for this feature isn't exactly a usability masterpiece. I believe it doesnt state up front that only urls on the whitelist can be used. Bawolff (talk) 00:52, 16 October 2014 (UTC)
bugzilla:71897 --Glaisher (talk) 09:21, 16 October 2014 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals/Archive/2014/10&oldid=139161679"