Commons:Village pump/Proposals

Shortcuts: COM:VP/P • COM:VPP

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)[reply]

I support that. —DerHexer (Talk) 13:08, 10 October 2014 (UTC)[reply]

Me too! Manuel knows exactly, what he want to do. Marcus Cyron (talk) 16:36, 10 October 2014 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

Oh, okay. Then support. Useful function. --Steinsplitter (talk) 14:08, 10 October 2014 (UTC)[reply]

 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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

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)[reply]

 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)[reply]

bugzilla:71897 --Glaisher (talk) 09:21, 16 October 2014 (UTC)[reply]

• Sounds good to me. You may want to notify Lupo beforehand to check whether MediaWiki:UploadForm.js will suffer from incompatibilities. -- Rillke^(q?) 11:25, 16 October 2014 (UTC)[reply]

  That ancient JavaScript will probably just roll over and die. I would have to take a close look, but I have no time for this. If it crashes or otherwise misbehaves, just disable it completely if that URL field is present on the page. This is intended for power users anyway who should know how to fill in an {{Information}} template. Lupo 14:27, 17 October 2014 (UTC)[reply]

•  Support (as a GWT- flagged user). Andy Mabbett (talk) 17:27, 22 October 2014 (UTC)[reply]

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)[reply]

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

An editor has requested comment from other editors for this discussion. If you have an opinion regarding this issue, feel free to comment below.

Wikidata Phase 2 would allow templates to draw information from Wikidata, though only from the unique Wikidata item that was directly 1:1 sitelinked with the page.

(For a short introduction to Wikidata, see Commons:Structured data/Short introduction to Wikidata)

In practice, the effect of this would be limited, because really only gallery pages would be able to access wikidata items with very much useful information. But it would mean we could try out gallery headers that come with an automatic link to the Commons category, an automatic link to any language-localised Wikipedia entry, an automatic language-localised description, and automatic links to corresponding pages (if any) on Wikisource, Wikiquote, and the corresponding page on Wikidata, and Reasonator. A very basic prototype for such a template can be seen tested at d:Template:SimpleCommonsGalleryHeader/test -- obviously, it could be made a lot more polished.

I think this is something it would be valuable to be able to start to play with. User:Lydia Pintscher (WMDE) has said she is happy to activate Phase 2 whenever we decide we want it.

So: should we give it a try? Jheald (talk) 14:35, 22 October 2014 (UTC)[reply]

•  Support Jheald (talk) 14:35, 22 October 2014 (UTC)[reply]
•  Support Limited use, but it can't harm. The really useful change will be when we can use WD in any template (Creator, Artwork, etc.). Regards, Yann (talk) 14:58, 22 October 2014 (UTC)[reply]
•  Support --Dschwen (talk) 16:50, 22 October 2014 (UTC)[reply]
•  Support per above. A "trial (galleryspace) run" is better than no run at all.    FDMS  4    17:13, 22 October 2014 (UTC)[reply]
•  Support - Andy Mabbett (talk) 17:26, 22 October 2014 (UTC)[reply]
•  Support Meh, why not -FASTILY 19:41, 22 October 2014 (UTC)[reply]
•  Support Maybe I would oppose this on Wikipedia, but it seems sensible here. Gestumblindi (talk) 21:53, 22 October 2014 (UTC)[reply]
•  Support--Oursana (talk) 23:58, 22 October 2014 (UTC)[reply]
•  Support,but I am confused. I was assuming that the reason Wikidata Phase 2 was not activated on Commons was that it was not ready to work in Commons environment, not because nobody thought about activating it. --Jarekt (talk) 03:12, 23 October 2014 (UTC)[reply]
•  Support --Atlasowa (talk) 08:23, 23 October 2014 (UTC)[reply]
•  Support as a necessary step towards COM:Structured data. --El Grafo (talk) 11:04, 23 October 2014 (UTC)[reply]
•  Support in principle, but we should be careful about transferring data to Wikidata where they stay outside our control and can in principle be vandalized. Some mechanism should be designed which alerts the page when the local data is not the same ones as stored on Wikidata.--Ymblanter (talk) 13:49, 23 October 2014 (UTC)[reply]

The sooner we can use this for creator templates, category pages, etc, the better. Andy Mabbett (talk) 17:26, 22 October 2014 (UTC)[reply]

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)[reply]

•  Support This would be very useful. -- King of ♥ ♦ ♣ ♠ 06:18, 23 October 2014 (UTC)[reply]
•  Support per King of Hearts. Green Giant (talk) 07:48, 23 October 2014 (UTC)[reply]
•  Support seems very useful. --Atlasowa (talk) 08:20, 23 October 2014 (UTC)[reply]
•  Support +1 --El Grafo (talk) 11:05, 23 October 2014 (UTC)[reply]
•  Support would be great especially if there are questions regarding original license at local wiki or GFDL license migration. --Denniss (talk) 11:25, 23 October 2014 (UTC)[reply]
•  Support I would support his but this is a meta issue, and the project users should be involved in the discussion.--Ymblanter (talk) 13:51, 23 October 2014 (UTC)[reply]
•  Support Could be helpful, like being autopatrolled/autoreviewed in the wiki if you reinstate an image into an article after undeletion at Commons. But per Ymblanter, this should be discussed directly at meta, and I don't think this will be successful. Broad viewdeleted is a big deal. --Krd 14:34, 23 October 2014 (UTC)[reply]
•  Support Useful. I suggest to move this proposals to meta because it is a "crosswiki proposal". --Steinsplitter (talk) 14:40, 23 October 2014 (UTC)[reply]

• 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)[reply]

• 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)[reply]

I started meta:Wikimedia_Forum#Implement_Global_deleted_image_review. Bawolff (talk) 20:05, 23 October 2014 (UTC)[reply]

•  Support Utterly powerful and useful. Useful especially when not all information were transferred or questions arise. -- Rillke^(q?) 17:38, 23 October 2014 (UTC)[reply]
•  Support Useful for correcting transwikis or checking deleted uploads from Commons uploaders with previous wp copyvios. --Martin H. (talk) 18:01, 23 October 2014 (UTC)[reply]
•  Support The restriction of this to the File: namespace means that this feature would add utility while avoiding many of the issues that a more general viewdeleted privilege would raise. – Philosopher ^{Let us reason together.} 18:18, 23 October 2014 (UTC)[reply]
•  Support Useful. Yann (talk) 20:14, 23 October 2014 (UTC)[reply]
• Presumably it's only me, but I found no viewdeletedfile on mw, what are you talking about? –Be..anyone (talk) 07:17, 24 October 2014 (UTC)[reply]
  • Take a page like m:Special:GlobalGroupPermissions/abusefilter and you'll see a right named viewdeletedfile, though it needs a MediaWiki message. @Bawolff: will you or did you already create a descriptive message? -- Rillke^(q?) 08:29, 24 October 2014 (UTC)[reply]
    • ill look into fixing that later today (update: gerrit:168692). @Be..anyone: note the right is Wikimedia specific and not part of mediawiki. Code is about mid way through [2]. Bawolff (talk) 12:04, 24 October 2014 (UTC)[reply]
  • Thanks for info, maybe this so far unanimous poll should be continued on meta, as it only affects other WikiMedia projects. –Be..anyone (talk) 12:19, 24 October 2014 (UTC)[reply]
    • I like the way Bawolff is going here: Without consensus or indication of usefulness on Commons it makes no sense to bother all the other projects. Apart from that, it does not really affect these projects; viewing as in viewdeletedfile is something passive, not changing anything, not even producing a log entry. Would there be any valid reservations by other projects? Which ones? -- Rillke^(q?) 14:25, 24 October 2014 (UTC)[reply]
  • Dunno, that's why I suggested to ask on meta. I didn't look into the code, (and presumably wouldn't understand it), but the name of the right sounds like "any deleted file", not only "files deleted after a transfer to commons". There could be issues, IANAL. –Be..anyone (talk) 18:30, 24 October 2014 (UTC)[reply]
    • That's correct, its any (non-oversighted) deleted file or file description page. Bawolff (talk) 20:41, 24 October 2014 (UTC)[reply]

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)[reply]