Commons:Village pump/Proposals/Archive/2013/03

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

Cat-a-lot

After categorizing with Cat-a-lot, you have to click the button "Return to page". That seems unnecessay and is an extra move which is a bit annoying. Is it possible to make Cat-a-lot take you back to the page automatically?

Also, why not make Cat-a-lot available when you view a user's uploads? When you categorize images, it's often best to concentrate on one user at a time, since you can get information about images by knowing his other uploads. --Jonund (talk) 19:34, 10 March 2013 (UTC)

Import a gadget

I propose to import a gadget in Commons. It is a clock that shows the local time of user's computer. The gadget is this es:MediaWiki:Gadget-LocalLiveClock.js. I already know UTCLiveClock, but this gadget is better because use work with personal time of every user (UTC+1, UTC+6, UTC-5, ...) --Vivaelcelta {discussion  · contributions} 14:30, 14 March 2013 (UTC)

Proposal: Files for Upload on Commons

Commons:Requests for comment/Files For Upload -- 65.92.180.137 03:17, 14 March 2013 (UTC)

transclusion converted to link - it was confusing. Further comments at RFC please. Rd232 (talk) 21:42, 21 March 2013 (UTC)

Moratorium on COM:PEOPLE-affected Flickr imports

Many of the problems we run into with new uploads in relation to COM:PEOPLE seem to be with Flickr-imports. I suggest that we have a one-year moratorium on Flickr imports of files that are affected by COM:PEOPLE (i.e. which show images of identifiable people - broadly construed, since people may be identifiable from textual information or from other images in the same Flickr stream). We can come up with some reasonable exceptions (eg where it's proven to a reasonable standard that there is no COM:PEOPLE problem, as documented by use of {{Consent}} and use of OTRS if necessary). If the moratorium works, we'll have some time to improve how we handle COM:PEOPLE issues without continuing to suck in so many problematic images. Comments? Rd232 (talk) 20:30, 21 March 2013 (UTC)

Too vague. I have uploaded over 15,000 images from Flickr and several hundreds of those are of people at Gay Pride marches. Most photos have identifiable people in them, it is kind of the point of these Pride events, many photos contain shots of notable figures such as activists, community figures and politicians. In the UK and the US, there is no doubt that there are no personal rights issues, as these are taken in very public spaces where people expect (and want) to be seen, and I would consider it serious censorship of reasonable educational material to ban uploading similar images from Pride events this summer. If you were talking a better system of identifying mass uploaders from Flickr (perhaps all of us who upload more than 50 images from Flickr in the same day should be "on a list" automatically), ensuring all their uploads are easily find-able in a category and then having a system that ensured there are independent checks of how reliable they are as an uploader, then you might be moving towards a better managed community. Someone who regularly and unambiguously is causing violations of Photographs of identifiable people or Licensing can then be advised, warned and eventually have Flickr upload privileges suspended until they promise to behave. Those of us that can keep ourselves within the guidelines (say, within a 2% tolerance, so out of 1,000 uploads, we might allow a maximum of 20 mistakes in good faith?), could even be encouraged by having the right to display a "Trusted Flickr uploader" badge or similar. Now, the trick will be to have a bot doing all that running about. Thanks --Fæ (talk) 21:08, 21 March 2013 (UTC)
We should have different systems in place for users trusted to use scripts, and for users using the UploadWizard or upload form. I think one logical starting point would be limiting script-based imports to approved users, with approval dependent on some form of user-based tracking. My initial proposal was more directed at non-script-based imports, but we shouldn't forget the scripts of course. If we make script-based import subject to approval, then we can apply looser COM:PEOPLE rules for those imports, because we'll be trusting those users' judgement. Rd232 (talk) 21:39, 21 March 2013 (UTC)
Do I understand that you would object to the many images I've uploaded from the Seattle Municipal Archive's Flickr account because they are pictures of identifiable people? If so, that seems bizarre, to say the least. - Jmabel ! talk 23:53, 21 March 2013 (UTC)
Also: given that it is almost impossible for a picture taken in a public place in the U.S. to raise any COM:PEOPLE issues, why would just showing identifiable people be the bar? - Jmabel ! talk 23:56, 21 March 2013 (UTC)
Quoting my original comment: We can come up with some reasonable exceptions (eg where it's proven to a reasonable standard that there is no COM:PEOPLE problem, as documented by use of {{Consent}} and use of OTRS if necessary). - so you'd have the burden of tagging such Flickr imports with {{consent|status=public}} - which if you think the images are worth importing, I think you should be willing to do. Rd232 (talk) 19:03, 22 March 2013 (UTC)

Higher standards for "porn" images

Following some recent discussion, I'm going to throw out there some ideas mentioned by User:Conti [1]: Have higher standards for porn images, for starters. Don't allow brand new accounts to upload porn, period. Have all porn images with identifiable people on it go through OTRS. Make it mandatory to ask people on Flickr if they're okay with having their images on Commons before taking their porn images. Hell, make that a habit for every image coming from Flickr. Don't allow porn images with the sole source of "own work", ever.

So those are some ideas. We also have the draft of Commons:Sexual content from 2 years ago, here, which looks fairly sensible to me. Bearing in mind the way things have gone since then in terms of emphasising and developing COM:PEOPLE, maybe it's time to consider reviving that old proposal? Rd232 (talk) 21:35, 21 March 2013 (UTC)

This might be appropriate, as too often only late (not in the early phase) after upload such images are found to be copyvios or the Flickr account suddenly disappears, which makes their legitimacy questionable, or there are deletion requests allegedly from the depicted person. All this produces a lot of additional work for admins and a potential risk of litigation for re-users, not to mention the embarrassment of a depicted person, whose images have been distributed without her/his consent. --Túrelio (talk) 21:44, 21 March 2013 (UTC)
I would suggest to start as simple as possible, so we don't end up discussing the fine print for days and weeks on end without achieving anything. One rule that (in my opinion) is quite sensible, and that would cover a lot of questionable images would be: "Do not allow brand new, not yet established accounts to upload sexually explicit material of any kind." We could define "brand new" as every account with less than 100 (or 50) edits, and we could make exceptions when said account is linked to their home wiki and show that they are an established user on said wiki. --Conti|✉ 22:31, 21 March 2013 (UTC)
That sounds like a reasonable place to start. To start with, it's probably simplest to define "brand new" as "not autoconfirmed" (4 days, 10 edits). It makes sense to make exceptions for users who have good records on Wikimedia elsewhere - but making this easily checkable probably needs a new gadget (one that pulls the relevant data for every user and puts it somewhere visible). Such a gadget might be generally useful, of course. That leaves the big question: how to deal with uploads that fall foul of it. Speedy deletion as if they were obvious copyvios (with appropriate messages)? Rd232 (talk) 23:21, 21 March 2013 (UTC)
I thought about making the same suggestion, but I'm uncomfortable with using autoconfirmed status as a way to define "brand new". Just look at the example below: That user hat 9 uploads, as far as I can see. One more and he'd be autoconfirmed. And the age of the account shouldn't play a role, either. I'd rather have a higher number of edits, anything that indicates that a user did not just upload a batch of photos and then decided to never log in again, basically. As for what to do, I'd say make them speedily deletable, perhaps add a new criteria to Commons:Criteria for speedy deletion. --Conti|✉ 23:30, 21 March 2013 (UTC)
To be autoconfirmed an account needs 10 edits and 4 days. I think it's a reasonable starting point, and if we find in practice that there are too many cases that should be caught by the new approach but aren't, then we can change it. Otherwise we'll get bogged down arguing about the threshold - that's why I want to use the obvious existing one. COM:CSD is a rejected proposal; there is the rather vague Commons:D#Speedy_deletion. I guess if we make a template for the purpose, mentioning it in that COM:D section would be enough. Rd232 (talk) 23:48, 21 March 2013 (UTC)
Hmm, so what if I find those images after 5 days? When I skim through the myriads of porn images we have, I unsurprisingly only come across very old throwaway accounts. I'd rather have these fall under this rule, too. And that's curious. I just recently speedily nominated an image for deletion based on Commons:Criteria for speedy deletion, and it got deleted. Guess I got lucky. --Conti|✉ 00:05, 22 March 2013 (UTC)
what if I find those images after 5 days? - unless we make specific provision otherwise, it wouldn't matter how long it took to find files uploaded by non-autoconfirmed users. It would probably be reasonable to do that in some way; perhaps a 30-day cut-off would be a place to start. Rd232 (talk) 18:54, 22 March 2013 (UTC)

One counter-argument to banning porn uploads by new users occurs (a point I now recall from previous discussions): existing contributors may not want such uploads associated with their main account, and may use new/throwaway accounts for such uploads. ... I'm not sure what to do with that issue, but there it is. Rd232 (talk) 18:59, 22 March 2013 (UTC)

If you want to try a real and current case, see these uploads, in several of which the depicted person is identifiable per face. --Túrelio (talk) 22:34, 21 March 2013 (UTC)
Yeah I nuked those. COM:PEOPLE issues just too glaring; sue me. Rd232 (talk) 23:22, 21 March 2013 (UTC)
(1) What exactly is a "porn image"? Anything with nudity? Anything displaying sex acts? Confined to human activity or not (e.g. is an image of dogs engaged in intercourse "porn"?
(2) Re: "Don't allow porn images with the sole source of 'own work', ever." So, once we could agree what is "porn", are you saying that if a regular contributor with a broad variety of work takes such an image, we wouldn't accept it? - Jmabel ! talk 23:51, 21 March 2013 (UTC)
(1) I would use the term "sexually explicit image", which should be self explanatory. There's always a grey line, obviously, and I wouldn't count, say, medical images under this.
(2)If there is a regular contributor doing this, we can easily ask him to provide more information, through OTRS if he wants to keep things private. This is actually something I just did recently at User talk:Ohconfucius, only to find out that the user in question (a regular contributor) did not find it necessary to ask the subject for consent on having the image freely licensed and uploaded because she has her eyes closed in the image. Seriously. See Commons:Deletion requests/File:Woman in orgasm.jpg. This just shows that, yes, we do need more than just "own work" for such images. From everyone. --Conti|✉ 00:05, 22 March 2013 (UTC)

Make content added while evading a block or ban subject to speedy deletion

Please comment at Commons talk:Criteria for speedy deletion#Content added while evading a block or ban. —LX (talk, contribs) 15:50, 25 March 2013 (UTC)

Tweak Special:Upload

I'd like to tweak Special:Upload:

  1. move Additional Info to the bottom, because it comes with the Edittools which are quite big and distracting, and it anyway makes sense to leave it to the end.
  2. Have a smaller version of the Edittools for the form - most of it is irrelevant to the form. Maybe just the first line is enough.
  3. Whilst we're moving things about - move the Licensing dropdown to near the top of the form - maybe below "original source".

Thoughts? (NB I don't know how to do this; I'm guessing a bug for 1. and a Javascript tweak for 2.) Rd232 (talk) 00:32, 26 March 2013 (UTC)

Another thought: should we add an equivalent of Commons:Upload/screenshot for artworks? Photos of artwork are far more common than screenshots, surely. The equivalent could inject {{Artwork}} or {{Art photo}} into the Summary field of the upload form, and provide a custom artwork-related header. Rd232 (talk) 10:36, 26 March 2013 (UTC)

Report a file (feedback) tool

A few days ago, a Commons user contacted us via OTRS, reporting a couple of low quality, home-made (and possibly illegal) porn images; they also left some feedback on how hard it is for an outside person to report anything on Commons.

I wondered a bit about possible ways to improve this experience for anonymous users (readers, lurkers), and I remembered the script that the Polish Wikipedia has been using for the past couple of years, with much success — both for articles, and files.

In short, it is a simple JS-based pop-up window (similar to what we use for renaming files) that people can use to report stuff; the script creates a new section at a single page that is being watched by many users, and they respond to the reports on that page. You can check out the experience at a random article on pl.wiki by clicking on the „Zgłoś błąd” link in the left sidebar; please use „Anuluj” not to leave test reports on that page :)

Since the feedback left on the Polish Wikipedia seems pretty good, especially with regards to files — though there are, admittedly, some not very useful comments, too — I suggest that we give it a go here on Commons for a test period (say, 3 months or so) and decide whether we want to keep it after seeing how useful the users' reports are (or not).

In addition to a test run of this script, we could also change the sidebar for anonymous users, for instance by removing the "Upload file" link — which is useless since you need to be logged in to upload stuff here — and remove edit some other parts of the interface which are of little use for random people just surfing Commons: Stockphoto, which is the most prominent thing on a file page for anonymous viewers, would be my first guess. We could also rewrite the contact us page (there's way too much text there now) as well as offer Guided tours to people that took the effort to report images to us.

To make this proposal more constructive, I went ahead and created three imaginary screenshots of how such a script could look like, in three steps (apologies for the quality; I am no designer, but I hope you get the point):

Please note that in this proposal, the report link is visible both directly above the file and in the left sidebar, unlike on the Polish Wikipedia; I guess we could have it in one place only if people don't agree with having it so visible. On these screenshots, the sidebar is also edited to match the English Wikipedia more closely; these are just additional changes that can be scraped, of course.

I am aware of the cons of such a proposal — massive amounts of spam, useless comments, test edits, problems with lack of manpower to respond to messages left in languages other than English, etc. — but after seeing how well the tool seems to be used on the Polish Wikipedia, I believe it is worth a try. Please let me know what you think (and apologies for such a long post), odder (talk) 15:23, 26 March 2013 (UTC)

Thanks for this, but my first reaction from looking at the mockups is did you really have to use File:Woman masturbating with improvised vibrator.jpg in the mockups?!. You could at least have mentioned "NSFW"...!! Rd232 (talk) 16:55, 26 March 2013 (UTC)
Just added that to the first screenshot, the others are rather innocent. I though a bit about using a different picture, but since it is generally porn that is considered inappropriate and very often mentioned in discussions about Commons (as well as in that OTRS ticket I decribed above), and because this particular image was often brought up in the SafeSearch discussions before, I believe that it only enhances the message. odder (talk) 16:58, 26 March 2013 (UTC)
It doesn't enhance the message - it actually substantially detracts from it by narrowing the focus and giving the impression that the primary use will be people flagging sexual images they don't like. That may be one of the uses, but unless there's a concrete reason to remove such an image, that's not going to help anyone. Rd232 (talk) 17:05, 26 March 2013 (UTC)
I am afraid that whatever the original uses of the script would be, a significant portion of the reports will be related to sexual images that people don't like. This is, unfortunately, one of the cons of getting feedback from regular users (readers); if this solution gets implemented, we will be dealing with such reports on a daily basis, and I guess it would need to be discussed very thoroughly before. I have seen this picture tens of times while reading the SafeSearch discussion, so I don't find it distracting; apologies if you find it so. odder (talk) 17:14, 26 March 2013 (UTC)
Anyway - yes, let's talk about how to improve this situation; the script sounds good in principle for leading users through deletion nominations, OTRS requests, and other feedback. I would separate discussion of the reporting script from other issues though - eg removing the Upload file link for anons isn't good, because it flags that they can upload (they just need to log in, as they find out if they click it). Rd232 (talk) 17:05, 26 March 2013 (UTC)
Well, I have been under the impression that there was significant opposition to letting anonymous users nominate files for deletion, so we would need to mention it very clearly in the first pop-up window — and yes, we definitely can include OTRS and legal addresses for especially complicated or delicate reports (child pornography, etc.).

As far as the other modifications are concerned, I agree that we can discuss them separately; I removed them from the mockups merely to show how we can improve the navigation for anonymous users by simplifying things. I am not aware of the existence of any statistics on how often people click the "Upload file" button and subsequently register an account and upload a file, so I'll just assume this is your opinion. In any case, even if that link is left in the sidebar, there is a lot of room for improvement, for instance with the use of guided tours. odder (talk) 18:01, 26 March 2013 (UTC)

  • In principle, this is good idea, however, my memories from Russian Wikipedia two years ago, where the same or similar script was used, was that the problem are at the other end: There were an insufficient number of users willing to go through the feedback and react. Before installing this feature, we need to decide whether we have sufficient resources to handle it.--Ymblanter (talk) 19:26, 26 March 2013 (UTC)
    • It's a risk - but Commons is different from Wikipedia, and there's only one way to find out how it'll turn out here. Even if it is unmanageable to the point of having to be turned off, it should produce some valuable data on users' needs. Rd232 (talk) 19:40, 26 March 2013 (UTC)
  • Odder wrote this proposal after I pointed him to the ticket on OTRS. I discussed him before he wrote this and I certainly  Support something like this & the tool seems to work well on plwiki. On other websites there is always a link/way to flag inappropriate comments or images, but for some reason Commons doesn't have it. Trijnsteltalk 22:32, 26 March 2013 (UTC)
  • I like this idea, and definitely support experimenting with it. (I think it could work well alongside the "article feedback" box - this is more intended as a "report problems" button than a way to provide information. So there's no reason not to try both!) Andrew Gray (talk) 23:01, 26 March 2013 (UTC)
  • Good idea, but for the record, even with the NSFW warning, I think you're actually "slowing down" the comprehension of users viewing the first image. The focus is supposed to be the button above the image, which took me probably ten seconds to even notice because I'm suddenly staring at a pornographic image. Blur out the image or make the image funny like a cute kitten. – Kerαunoςcopia◁galaxies 23:47, 26 March 2013 (UTC)

Taller en Libre Graphics Meeting | Workshop at Libre Graphics Meeting

Hola, (English version below)

Quisiera compartir con uds una propuesta que hice para el próximo encuentro anual de Libre Graphics Meeting que este año se realiza en Madrid, del 10 al 13 de abril. Recibí para esto una beca de Fundación Wikimedia, y pueden encontrar mas información sobre la propuesta en: http://meta.wikimedia.org/wiki/Grants:Lila_Pagola/LibreGraphicsMeeting

En pocas palabras, se trata de un taller para presentar Commons a los diseñadores que asistirán al evento, usuarios de software libre, a través de una práctica real. La idea es también que los diseñadores puedan contribuir con ideas sobre como mejorar las dinámicas de trabajo con software libre para diseño o fotografía, entre otras sugerencias que puedan aparecer.

Sería genial si algunos de uds andan cerca de Madrid y pueden llegarse al evento, o en todo caso, si podemos encontrar un modo de que participen virtualmente.

Tengo además, una duda técnica: le he pedido a la gente interesada en el taller, que registre su usuario en Commons previamente, pero estoy segura que habrá personas sin usuario el día del taller. Ezarate me sugirió que creara varios usuarios al estilo de LGM1, LGM2, etc. pero yo me pregunto si no existe alguna forma mas prolija de hacer esto, especialmente para permitir a estos nuevos usuarios crear nuevas versiones de archivos existentes.

Toda sugerencia es muy bienvenida.

Saludos desde Argentina, --Lpagola (talk) 18:26, 26 March 2013 (UTC)

Hi,

I want to share with you the proposal I have presented for the next Libre Graphics Meeting in Madrid, on April 13. I have received a Personal Grant of Wikimedia Foundation, and more information could be found at: http://meta.wikimedia.org/wiki/Grants:Lila_Pagola/LibreGraphicsMeeting

In a few words, it will be a workshop for introducing Commons to libre graphics designers attending the event, through a real practice. The idea is also that this designers could contribute to Commons with ideas about how to improve the workflow with free software or other suggestions.

So, it will be great if you are around Madrid and you are able to participate, or if we can find a way to do it online. I have also a technical question: I have asked people interested in taking the workshop to previously register a user in Commons. But I know it will be people without user the final day. I can create some users like LGM1, LGM2, and so on... as Ezarate suggested to me, but I was wondering if there is a kind of more "tidy" method, specially for allowing people to do new editions of existing files.

I look forward to your comments. Best regards from Argentina, --Lpagola (talk) 18:26, 26 March 2013 (UTC)

Deletion requests

(translation from a proposal submitted in Spanish) The current deletion request process seems to be defined having in mind the commons community. However, there are plenty of wikipedias that have disabled local upload and therefore use commons as their only images repository. Thus, there are members of said communities that don't even know how to vote in a deletion request. For instance, they are currently using voting templates that don't even exist (see here, where the voter used the non-existing template {{Nokeep}}). My proposal is to include somehow in the deletion request template the different options the voter can use (see for instance an example in the Spanish Wikipedia: example) [translated on behalf of Jcfidy] Best regards --Ecemaml talk to me/habla conmigo 22:55, 28 March 2013 (UTC)

Familiarity with templates is less of a concern than familiarity with policies on which valid arguments (not votes!) may be based. But I'm all for creating a multilingual template with instructions and transcluding it in the editnotice for deletion discussions, provided that it links to Commons:Deletion policy and explains that deletion discussions are not votes. —LX (talk, contribs) 11:45, 29 March 2013 (UTC)
We can always use help in making commons content accessible to users not familiar with commons or not fluent in English. You have my support for any effort in that direction, unfortunately that often requires help of people familiar with both communities who are willing to help with the process. As with code development it is easier to find people willing to write the code than to document it. As for non-existing template {{Nokeep}} - I think that use of that template did not make much of a difference other than aesthetic, since the meaning is clear. --Jarekt (talk) 14:22, 29 March 2013 (UTC)
Sí, el significado de la plantilla nokeep es claro para cualquiera que entienda el idioma inglés, pero si el votante no lo entiende y quiere votar puede tener a su disposición una plantilla que le ayudará a escoge la palabra adecuada para emitir su voto.
Yes, the meaning of the template nokeep is clear to anyone who understands English, but if the voter does not understand and want to vote can have a template available that will help you choose the right word to vote. (written in Spanish and translated with google translator)--Jcfidy (talk) 14:38, 29 March 2013 (UTC)

I can help for the translation and any needed support for the Spanish language. Count on me. --Ecemaml talk to me/habla conmigo 16:28, 29 March 2013 (UTC)

Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals/Archive/2013/03&oldid=95216480"