Commons:Village pump/Proposals

From Wikimedia Commons, the free media repository
Jump to: navigation, search

Shortcut: COM:VP/P· COM:VPP

  Welcome   Community portal   Help desk
Upload help
  Village pump
copyright • proposals
  Administrators' noticeboard
vandalism • user problems • blocks and protections
 
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?


 

Blog[edit]

I was thinking whether the Commons should have dedicated blog similar to one run by Flickr — blog.flickr.net. I know we already have Wikimedia blog but that one is focused on Wikimedia movement and occasionally feature Commons-realted stuff whereas Commons blog will be focussed solely on images. These days many image repositories run blogs to showcase their interesting stuff then why not Commons blog? --Saqib (talk) 14:08, 4 May 2015 (UTC)

We have Commons:The Commoner (inactive). --Steinsplitter (talk) 14:30, 4 May 2015 (UTC)
(For internal news/archives, we kind of have COM:LOG but no-one really maintains it :-( )
Relatedly, there are several Twitter accounts showcasing material: WikiCommons Sports, CommonsAviation, my very own CommonsCat, WikimediaSTEM (not only Commons) and maybe others. Jean-Fred (talk) 09:28, 3 June 2015 (UTC)

Raise awareness of OTRS by including it in the Upload Wizard[edit]

This entry at the help desk (permalink) made me aware that there are currently no instructions whatsoever in the Upload Wizard on how to proceed if a) permission to upload a file was given by a third party and b) if the uploader holds the copyright but permission is required nevertheless (e.g. copyrighted material from a company website). How can we expect people to file a permission via COM:OTRS if there's no way for them to know something like this even exists? I suppose we could avoid a huge pile of DRs, {{no permission}}s and frustration among users if we would make this more clear to the typical newbie uploader. At least a) could be handled quite easily by modifying the Upload Wizard. There was already a bug filed for this phab:T36332, but is was closed as "invalid" because of community consensus was not demonstrated. There, it was proposed to change the current wording in the Release rights step of the wizard (when This file is not my own work. is chosen) from

The copyright holder published this work with the right Creative Commons license
Not all Creative Commons licenses are good for this site. Make sure the copyright holder used one of these licenses.
[license options]

to something like

The copyright holder published or wants to publish this work under a Creative Commons license
   If the work is already published under that license online add URLs and short quotation of the permission text to the source field above. Also add the tag {{LicenseReview}}.
   If the work is not already published under that license online please follow the steps described at COM:OTRS (the copyright holder has to send an email) and add {{subst:OP}} to the source field above.
Not all Creative Commons licenses are good for this site. Make sure the copyright holder used or wants to use one of the following licenses:
[license options]

(Adding stuff to the source field was proposed as a workaround, since UploadWizard doesn't offer a permission field.) So: let's discuss this, find a consensus, re-open the bug and hand it back over to the developers. --El Grafo (talk) 09:05, 3 June 2015 (UTC)

  • Symbol oppose vote.svg Oppose We already use OTRS far too much, the vast majority of declarations could be published with the benefit that any reuser could verify the details. The current default for secrecy just encourages information hoarding and cover ups when errors are made (which are far more often than is made public). -- (talk) 10:40, 3 June 2015 (UTC)
    • If someone uploads a photo and the copyright to that photo obviously belongs to photographer Bob Jones (it's published on Mr. Jones' photography website, as are a host of other photos clearly taken by the same person), how would you suggest that the uploader authenticate the permission from Mr. Jones, if not via email? If the uploader says he is Mr. Jones, how are we to know that he is telling the truth? I could write out the COM:CONSENT form on a file description page claiming to be Barack Obama but that doesn't make it true. I don't see a good way to verify identity other than an email system where we can see that the email was sent from bob@awesomephotographsbybobbyjones.com. --B (talk) 22:01, 5 June 2015 (UTC)
    • Currently, OTRS is the only option we have and until someone comes up with a working alternative we better make the best out of it. Letting people upload stuff and telling them about OTRS afterwards is both very bad style (newbie uploaders get pissed) and a waste of resources (people need to tag files and calm down rightfully pissed uploaders, admins need to delete files that were uploaded because people didn't know the rules). --El Grafo (talk) 09:03, 7 June 2015 (UTC)
  • Symbol support vote.svg Support It seems a sane idea. Yann (talk) 04:03, 6 June 2015 (UTC)
  • Symbol support vote.svg Support Seems very helpful along with the automated responses. Jee 11:17, 6 June 2015 (UTC)
  • Symbol support vote.svg Support good idea! Natuur12 (talk) 14:10, 6 June 2015 (UTC)
  • Symbol support vote.svg Support Excellent idea. Thibaut120094 (talk) 14:29, 6 June 2015 (UTC)
  • Symbol support vote.svg Support - I understand Fae's concerns but until there is a realistic alternative... Green Giant (talk) 18:06, 6 June 2015 (UTC)
  • Symbol support vote.svg Support – glad to see that it only takes more than 3 years to implement such simple improvements. I don't understand Fæ's concerns at all, as currently uploaders are only being made aware of OTRS while the suggested wording also prominently refers them to our LR process. (Harmonised punctuation with the other options.)    FDMS  4    02:57, 7 June 2015 (UTC)
  • Symbol support vote.svg Support makes sense. --Steinsplitter (talk) 10:32, 7 June 2015 (UTC)
  • Symbol support vote.svg Support. Very good idea. -- Geagea (talk) 00:18, 8 June 2015 (UTC)
  • Symbol support vote.svg Support I like it too. The more information we provide up front the better. A lot of people are very confused about it. --Jarekt (talk) 02:52, 8 June 2015 (UTC)
  • Symbol support vote.svg Support Seems a good idea to me. ColonialGrid (talk) 14:29, 8 June 2015 (UTC)
  • Symbol support vote.svg Support It seems a good idea. -- Christian Ferrer 18:07, 8 June 2015 (UTC)
  • Symbol support vote.svg Support Sounds like a sound idea, as it is long overdue. Kevin Rutherford (talk) 12:24, 9 June 2015 (UTC)
  • Symbol support vote.svg Support Not including the OTRS option is unnecessarily opaque, it seems to me. Walter Siegmund (talk) 14:53, 9 June 2015 (UTC)
  • Symbol oppose vote.svg Oppose: My 1st idea, just by reading the edit summary in my watchlist, was to oppose. Now I read everybody’s input so far and I amm still against. Of course the fundamental issue here is the Upload Wizard, which needs to be improved (or removed…?) in so many ways — I am all for that. However OTRS seems to me better be kept as a last resort option, for the reasons given above by User:Fæ; the concerns expressed by others could be addressed by adding suitable instructions to the Upload Wizard, instead of presenting OTRS upfront as the one-stop all-purpose solution for remote license verification.
Frankly it is much simpler for everybody if our uploader asks WhatsHisName S. Photographer to upload a public permission somewhere in his website WhatsHisName.net than have him send an e-mail with the same permission to OTRS from an address @WhatsHisName.net. (This replies User:B’s question above.) Anyone can see the said webpage, linked in the permissions fields and subjected to {{License Review}}, while an e-mail to OTRS takes longer and is (in most cases, needlessly) secret.
-- Tuválkin 19:30, 9 June 2015 (UTC)
Simpler for everybody? Even using a CMS, creating a web page or uploading a permission statement to a private web server is hardly "simpler" than sending an eMail.    FDMS  4    21:35, 9 June 2015 (UTC)
Let’s put it this way: «If your image/file is already available online under an unsuitable license or otherwise you need to confirm its permission, you can either
  • send to OTRS an e-mail from a legitimate address stating your permission terms, and then wait 60 days, or
  • upload the same permission text somewhere in a legitimate website address, and then wait 3 days for {{License Review}}
And let them decide which is preferable. -- Tuválkin 23:12, 9 June 2015 (UTC)
Sure, but all this proposal is saying is that OTRS should be mentioned during the upload process as an option. I don't see there to be a valid reason not to mention a valid avenue for licencing images. Also, mentioning OTRS pulls the wizard in line with the upload form, which does mention OTRS. ColonialGrid (talk) 13:42, 10 June 2015 (UTC)
@Tuvalkin: I totally agree that {{License Review}} often is much quicker and more comfortable to use. In those cases where it's appropriate to use it, it should be preferred, of course. Maybe you've missed it, but the proposal actually does include this path and it comes right before the OTRS path. If that's not clear enough, we can still change the wording – you ideas would be very much welcome. --El Grafo (talk) 08:25, 17 June 2015 (UTC)
  • Symbol support vote.svg Support Although I do agree this makes sense and seems like a good idea I also agree with Fae that OTRS already has pretty heavy workload and lengthy backlogs are common. Additionally I am not a huge fan of the lack of visibility of what goes on in OTRS with the excuse of "privacy". Reguyla (talk) 00:31, 10 June 2015 (UTC)
  • Pictogram voting comment.svg Comment: "the copyright holder has to send an email" is incorrect. The copyright holder may just need to add the license statement to their website or wherever the files are published. I'd make the sentences less verbose, to reduce chances of errors and other mismatches with the actual instructions. --Nemo 23:56, 13 June 2015 (UTC)
    • @Nemo bis:Well, in that case you would wait until the license has been added to that website and proceed as described in the first option ("already published under that license"). Nevertheless, we can make the second one shorter. How about this:
If the copyright holder wants to release the work under that license via e-mail please follow the steps described at COM:OTRS and add {{subst:OP}} to the source field above.
--El Grafo (talk) 08:00, 17 June 2015 (UTC)

There should be a "Convert to JPEG" template[edit]

For images like: File:Spanking Bench.png & File:Spanking on Bondage Furniture.png —User000name 09:04, 6 June 2015 (UTC)

Are there particular technical problems with files in the (open) .png format that would be solved by conversion to jpeg? --MichaelMaggs (talk) 09:19, 6 June 2015 (UTC)
If you consider higher bandwidth use and file size than required a particular problem, you could solve one by conversion to JPEG. -- Rillke(q?) 18:04, 6 June 2015 (UTC)

Searching by text, not by category[edit]

Could you please, please, please provide a way to search the collection by textual contents (title, author, description etc.) rather than by category? The category classification may be useful to some users, but it is a haphazard maze that is far more effective at hiding images than at helping the user to find them.

The world is not a tree, and trying to chop it into the shape of one is a self-frustrating project. Cateories are not real; they are a figment of our minds, and what may seem a logical classification to one person will make no sense for another. Even a large full-time editorial board with strict coordination would find it difficult to classify images in a natural category system; there is no hope that that an uncoordinated and understaffed bunch of volunteers, no matter how well-meaning and devoted, will succeed at that task. At best, categories should be treated as keywords, meant to ensure that searches for some term relevant to an image will find it, even if the term does not appear in the title or description.

The default search should be a full-text search, sorted by matches in the title first, then by matches in the description, then by categories. Please... --Jorge Stolfi (talk) 22:54, 7 June 2015 (UTC)

If you prefix the search term with 'insource:' (without the quotes) the search will be applied to the actual wikitext, instead of to file and category names. See https://www.mediawiki.org/wiki/Help:CirrusSearch for more options. Revent (talk) 23:22, 7 June 2015 (UTC)
Er, as far as I know, the default search is a full-text search (random example), albeit one where category title matches rank fairly high (rightfully so IMO) − the only caveat is that *if* (and only if) there is an exact match in a category name, then you get redirect to that category. Jean-Fred (talk) 11:09, 8 June 2015 (UTC)
  • In the search page you can select only 'Multimedia' or select specific 'spaces' through the 'Advanced' tab. I hope this helps. ColonialGrid (talk) 14:33, 8 June 2015 (UTC)

Idea: Website where I can upload not-free-yet pictures, and they get upload to Commons when copyright expires[edit]

I took many pictures of modern art paintings at a museum. I uploaded the public domain ones to Commons, and wonder to what website I could upload the others.

I got the idea of such a website, please tell me if that exists already:

  • The website should keep the uploaded images, and provide visitors with as much as what the copyright laws allow (for instance only metadata, and in some cases a small thumbnail)
  • The website should upload images to Commons as soon as they become public domain (the website should make calculations and keep track of that)
  • The website should allow visitors to provide metadata, such as title, author, year, description. This metadata should be semantic/searchable, for instance one could query all paintings painted in 1925.
  • Pictures that are reusable except for commercial use (like pictures of sculptures in Japan) should be available for download with a specific license excluding commercial use.

Illustration: http://i.stack.imgur.com/UYAb9.png Thumbnail of my picture of a 1925 painting realized in France by Catalan painter Joan Miró (1893-1983), owned by MOMAT and kept in Japan, will become public domain in 2053 if my calculations are correct and if laws do not change

My goal is that:

  • Wikimedia Commons receives the images as soon as legally possible.
  • Copyright length calculations are double-checked and organized, I don't have to keep track of all laws by myself.
  • If the painting is bought by a collector and kept private forever, at least we have a picture that will eventually be released.
  • If the museum burns, at least we know that a picture exists.
  • Have my pictures go to the greater good even if I die before 2053. And even if my backup disks fail before 2053, which is probable as well.

Has anyone heard about such a website? If not, anyone willing to create it or help? :-) Cheers! Syced (talk) 03:45, 9 June 2015 (UTC)

If they are things that would obviously be in scope once expired, a workaround would be to upload them, then immediately DR them with the "Undelete in XXXX" category added to the DR page, and a note as to why. It's not ideal, but works... if doing so, I'd suggest you ping an active admin to speedy close the DR. Revent (talk) 03:52, 9 June 2015 (UTC)
Interesting hack! Not for the common contributor though I guess. contains a few dozens files for each year, suggesting that it is mostly for files uploaded by mistake, rather than a concerted effort to build a future collection. Lengths calculations are done case-by-case manually, which is error-prone. Also, such files lack metadata, so if this way of doing things becomes popular, it will become difficult to find out whether a given painting is already present or not. Thanks for the tip! I am still hoping there is (or will be) a dedicated tool for this though :-) Syced (talk) 06:15, 9 June 2015 (UTC)
It is, indeed, not a elegant (or really recommended) solution. We shouldn't really be intentionally storing things that way on any kind of scale, but for particular cases where there is a reason to suspect the work might not be permanently available, or (as I have done before) where you've done work cleaning up a book scan that's PD in the home country, but under the URAA, and want to make sure the clean version is not lost, it works. Revent (talk) 06:55, 9 June 2015 (UTC)
As a 'second thought', glancing back at this, I should clarify for the record... something like this should really only be done in a case where the content is both 'legal in the US' and 'legal to upload', and simply not yet allowable by Commons policy (typically, still copyrighted in the source country due to a term based on date of death instead of publication date). Still not really recommended, but possibly 'reasonable' in specific cases. Revent (talk) 18:32, 10 June 2015 (UTC)
If the pictures are in the public domain in Canada (50 pma only), you can upload then on Wikilivres. Regards, Yann (talk) 07:00, 9 June 2015 (UTC)
Depending on the country of publication, you could upload at least some of them to specific Wikimedia projects that have an exemption doctrine policy but such files would have to meet strict criteria. The alternative is a hypothetical non-free wiki which is what I think you're suggesting but that idea is stuck in the pipeline somewhere. Green Giant (talk) 08:20, 9 June 2015 (UTC)

Collections of/by institution[edit]

Wouldn't it make more sense to have a category tree like the following, instead of a piecemeal one divided by arbitrary institution type (library, museum, etc.)?:

  • Collections of institutions
    • [other subcats]
      • Collections by institution
        • Collections of type by institution
          • etc.

The distinctions between types of institutions blur (the special collections of libraries basically are museums, and plenty of museums have libraries), there are other types of institutions, e.g. archives, private foundations, religious centers (Vatican, LDS), it may take unnecessary research to figure out if something 'really is" a museum vs. a library, the distinction seems questionably meaningful in our context, and we'd have a richer array of extant categories in which to organize. — SMcCandlish [talk] [cont] ‹(-¿-)› 00:23, 17 June 2015 (UTC)

I'm not quite following why it is necessary to have a parent category called "Collections of institutions", and then a subcategory "Collections by institution". What's the difference between the two? Can we flatten the category tree by trying not to have both of these categories? Also, what are the "[other subcats]" of "Collections of institutions" that you envisage? — SMUconlaw (talk) 02:02, 1 July 2015 (UTC)

Add Template:Commons upload tools or a link to Commons:Upload tools to Special:UploadWizard[edit]

Let's face it: In its current state the UploadWizard can be a major pita. We've been told that the developers are working on a major overhaul of the Wizard's back-end, but as far as I'm aware that may still take quite a while. We have several other methods for uploading content, but they are completely hidden from the casual user. Whenever you ask a frustrated user something like "have you tried turning it off and on again using Vicuna/Commonist instead" you get an answer similar to "I didn't even know something like this existed". In fact, I got that answer from rather experienced uploaders as well. I therefore propose to include Template:Commons upload tools at the bottom of the Special:UploadWizard starting page, or at the very least include a link to Commons:Upload tools (entitled alternative upload methods or something similar) right next to the "back to the old form" at the top of that page. --El Grafo (talk) 13:51, 17 June 2015 (UTC)

This is technically not yet possible: 1 --Steinsplitter (talk) 14:15, 17 June 2015 (UTC)
Well, I wasn't assuming that anyone here could actually do anything to that page. But the stuff above has taught me that it's better to have documented community consensus before you file a feature request. So here I am, asking for opinions. --El Grafo (talk) 14:42, 17 June 2015 (UTC) Or can our local admins edit the target of (mwe-upwiz-subhead-alt-upload)? Then we could point that to Commons:Upload tools and add the old form there under "Integrated tools" (the latter should be done anyway).
This seems to be pretty trivial and does not need consensus. Technically i can atm edit only the header but not the footer. Filed phabricator:T104009. --Steinsplitter (talk) 16:52, 26 June 2015 (UTC)

Renaming categories that contain cfd templates[edit]

There is an issue that happens occasionally when moving categories to a new name. If a category page contains a {{category for discussion}} template, say {{category for discussion|1=|and-so-on...}} the shown template message provides a link that points to the appropriate cfd discussion page. Well, but if then the category gets a new name and the contained cfd template is of course also "moved", that link points to nothing. It looks like a newly generated incomplete cfd request (can be seen here for example). So one laboriously has to look for the previous name of the category (which could be deleted in the meantime) and figure out the link to the matching cfd page for to get there. The problem can be solved easily using the parameter 1= of the {{category for discussion}} template by entering the previous name of the category (as can be seen here). Summarized: If a category is renamed and if it contains a cfd template whose parameter 1= is empty, then the old name of the category should get added automatically to the template's parameter: 1=Category:Previouscatname . --Achim (talk) 18:00, 19 June 2015 (UTC)

Any idea where to drop this suggestion? --Achim (talk) 17:50, 25 June 2015 (UTC)
IMO the 1 parameter should be set by the AjaxQuickDelete gadget itself. That could be suggested here or by just pinging Rillke.    FDMS  4    19:05, 25 June 2015 (UTC)
Thanks. Thought about it: The other way round should work as well and might be easier to implement: If it were ensured that {{category for discussion}} always uses parameter 1 (per default pointing to the cat name if it's empty otherwise) the problem should be solved, too. Of course then it must not be replaced in case of a category move. --Achim (talk) 09:00, 27 June 2015 (UTC)

Marking Commons:Username policy as a policy[edit]

Please see Commons talk:Username policy#Making official for a RFC on making the proposed username policy official. Thank you, Tiptoety talk 00:12, 26 June 2015 (UTC)

looking for feedback[edit]

Saludos!

Im the coordinator for the Wiki Learning Tec de Monterrey User Group and Ive just put an idea in the Idea Lab at Meta Oral documentation of Mexican artisans Essentially, the idea is to videotape interviews with Mexican artisans and clips (perhaps more) of the creation of handcrafts such as pottery, basketmaking, etc for upload into Commons. The idea originated with comments during a presentation at Wikimania London, but we are now able to proceed with the idea not only because of the Museo de Arte Popular's long-standing support of Wikimedia but also because we have a dedicated group of students who have completed or are completing Wikimedia-related videos. Right now Im looking for feedback for the idea on Meta, and if you have an idea how to support us, Im all for that!Thelmadatter (talk) 18:52, 27 June 2015 (UTC)

Allow WebP upload[edit]

WebP is an open file format to store images in a lossy or lossless way. It supports transparency in both the lossy and lossless mode while providing smaller file sizes when compared with JPEG or PNG compression (even animation like in GIF is possible). Despite the technical advance, WebP could never gain substantial support other than by it's creator (google).

Below is a separate subsection where opinions about enabling WebP upload to the WMF cluster should be discussed as well as subsections for voting about the WebP upload. --McZusatz (talk) 16:36, 28 June 2015 (UTC)

Support[edit]

  • Symbol support vote.svg Support if and only if we get thumbnails in a format supported by Firefox and IE -- Rillke(q?) 19:50, 28 June 2015 (UTC)
Just for reference, the current implementation in MediaWiki is like SVG, in that when users upload a webp file, a PNG file is displayed to the user (I have no idea if in the long term we might do something more complex, but that's what is there now). Bawolff (talk) 20:42, 28 June 2015 (UTC)
  • Symbol support vote.svg Support (assuming Bawolff is correct, with the same thought as Rillke) ToBeFree (talk) 23:06, 28 June 2015 (UTC)
  • Symbol support vote.svg Support WebP has a lot going for it when it comes to usability in many scenarios. Image editor, image tool support seems to be fairly decent as well. Offnfopt(talk) 02:13, 29 June 2015 (UTC)
  • Symbol support vote.svg Support as long as we get thumbnails. --El Grafo (talk) 11:55, 29 June 2015 (UTC)
  • Symbol support vote.svg Support Can't think of a good reason not to assuming, as other supporters do, that thumbs work. Storkk (talk) 14:17, 30 June 2015 (UTC)

Oppose[edit]

  • Symbol oppose vote.svg Oppose Where is anybody using this format? Or is it going to be used only for JPEG and TIFF files that have been converted to WebP? Smaller size is nice, but it's hardly a killer feature.--Prosfilaes (talk) 21:19, 29 June 2015 (UTC)

Discussion[edit]

I believe in the technical superiority of WebP but many companies who enabled WebP had a response of bad user experience (e.g. facebook). Though, for all WebP files uploaded there would be thumbnails in the wider supported PNG format available for download. Still, user could normally not just download the full resolution and re-use it as is due to missing support (not to mention modify and upload an enhanced version). Furthermore, the Firefox web browser by Mozilla does not support WebP but Mozilla may take into account if WebP was enabled on the WMF cluster. (A comment in the bug tracker referring to it as the chicken-egg-problem) --McZusatz (talk) 16:36, 28 June 2015 (UTC)

COM:VPP may be a better place, if you want opinions of other language Wikimedians too. Jee 03:15, 29 June 2015 (UTC)

I agree with McZusatz, that it would be difficult for users who are offered a file in a format that their software doesn't support. There have been occasional complaints about Ogg formats I think, where there are good reasons for choosing the format. The problem could get worse over time, if WebP fails to take off and is abandoned by Google: it may be difficult to know what to do with these files in ten years. This would be offset on the other hand by a saving in storage space and network bandwidth, but since storage constraints are rarely if ever discussed on Commons, I have to assume it's not an issue. If WebP was widely supported, perhaps there'd be little reason not to convert existing files into that format and discard the originals, if no information was lost. --ghouston (talk) 04:03, 29 June 2015 (UTC)
WebM seems to have wider support than WebP, e.g., it's supported in Firefox. However it seems that Mozilla have decided not to support WebP in Firefox, on the grounds that they could get the same benefits by writing a better JPEG compressor. --ghouston (talk)