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

Indefinitely blocked IPs

This was buried underneath the Village Pump archives without any response so I guess I should post here again before pushing the proposal to the administrators' noticeboard:

Hi, this RFC is meant to facilitate discussion as part of an ongoing cross-wiki trend of various discussions and discussion boards I've noticed recently opened concerning the issue of indefinitely blocked IP addresses. Specifically the purpose of RFC is twofold, namely:

1. The unblocking of currently indefinitely blocked IP addresses at Special:BlockList.
2. Amending Commons:Blocking policy to discourage future indefinite blocks, with proposed language changes like adding "Administrators are strongly discouraged/prohibited/advised against indefinitely blocking IP addresses.

As I have explained elsewhere on other wikis, my reasons for doing so are thus:

1. IP addresses should never be indefinitely blocked as they can change hands pretty quickly.
2. In the event that any single IP address does need an indefinite block, such as for open proxies, the Meta Stewards have already implemented an indefinite global block for it.

Please add your comments to the discussion below. Thanks!

I probably wasn't very clear when I made this thread on the English Wikipedia that, as a reminder, this is actually two different requests in one proposal: the first calls for a review of and eventual removal of current indefinitely blocked IP editors (whose list is very small as pointed out by MultiChill) while the second calls for prohibiting administrators from administering future indefinite blocks against IP editors. The reason it is separated like this, is that I can imagine the case that someone supports reporting future indefinite blocks only to the Meta Stewards, but to leave the current indefinite blocks in place on Commons as it is perceived as a "problem looking for a solution" (a very annoying and oft-quoted adage that tries to stifle the freeform nature of wikis from undergoing any sort of change, one that I have thankfully had only rare occasions to invoke myself, but I digress).

Oh, do note that I've found a recently inactive database report on this issue. Wonder if that should be deleted, in favor of Special:BlockList as mentioned above?

TeleComNasSprVen (talk) 06:12, 15 February 2014 (UTC)

Can I take this as the community's silent agreement on unblocking indeffed IPs? TeleComNasSprVen (talk) 07:33, 8 March 2014 (UTC)

No. I would support a process of reviewing and managing indef blocks, but zero interest in a proposal is not evidence of a consensus. This does not stop you from taking an initiative, however it may be wise to explain your plan on AN. --Fæ (talk) 08:33, 10 March 2014 (UTC)

Right, my mistake. I've asked for further input at Commons:Administrators' noticeboard#Review of indefinitely blocked IP addresses. TeleComNasSprVen (talk) 06:59, 11 March 2014 (UTC)

Oh, one other thing I'll probably add is to ask any user who suspect an IP of being an open proxy to report the IP to Meta stewards at Steward requests/Global so they can get the information to make proper judgment of globally blocking the IP addresses. TeleComNasSprVen (talk) 07:28, 11 March 2014 (UTC)

I agree that IP addresses should not be blocked indefinitely. IP addresses may be reassigned; individuals may move on to different schools, employers or ISPs; and open proxy servers tend not to be left open forever. Commons:Blocking policy currently advises a one-year duration for open proxy blocks, which seems reasonable for other types of serious disruption from anonymous users as well. However, if any IP addresses have been indefinitely blocked within the last year, they should probably remained blocked for at least a year. —LX (talk, contribs) 11:50, 10 March 2014 (UTC)

Naming convention for road sign files.

I would like to propose the following naming convention for road sign files on Commons, both current and future uploads.

• "Country Name road sign D-15"

This convention would only apply where we know the official designations for a country's set of signs (ie: "D-15"). Such a convention would greatly simplify the use of these files by reducing file name discrepancies to a minimum, especially where different countries' signs are being used together such as on Comparison of European road signs.

This convention would exclude where we do not know a country's internal designations and we have to use generic file names (ie: "warning steep hill"), and would also exclude road signs in the United States which already follow the ideal of this convention but with "MUTCD D-15" instead of "United States road sign D-15".

Any user with file mover rights would have the authority to rename road sign files based on this convention, however to avoid the mess that would come from immediately enforcing this across the board, the renaming process should be voluntary. Fry1989 ^eh? 20:57, 20 February 2014 (UTC)

If anyone thinks this is not worthy of a new policy or is wondering why I'm proposing this instead of just "doing it myself", it's because there may be users who don't understand or don't like the rename process and I would like some sort of weight behind this before moving forward. Fry1989 ^eh? 19:27, 23 February 2014 (UTC)

Fry, while I don’t disagree with the basic principle, i’m afraid there would be, as you predict, a lot of resistance from some users, defending imcompatible naming schemes of their own. This has only a chance to pass if it is approved as a guideline, to be adopted by whoever seeks a naming scheme, not as a policy to be imposed on those who are deadset on a different one.

I also think it would be simpler if this nomenclature were implemented via categories, one for each separate sign, instead of file renaming. Having one category for each for each separate sign would allow to bag in the same folder both flat idealized SVG images of it, JPGs or PDFs of the relevant legislation and technical papers, and photos of its useage in real life — example: File:FloodedTrafficLightsSign.jpg in Category:MUTCD W3-3, along with File:MUTCD W3-3.svg and File:MUTCD W3-3 (temporary).svg.

-- Tuválkin ✉ 08:39, 24 February 2014 (UTC)

We already categorize images based on their types (example), I've been working on that heavily as well. But the direct benefit of having a common naming convention with the country name followed by "road sign" and the designation as I proposed would outweigh any detractions that I can foresee. I fail to see how this can be called incompatible, when we have common naming conventions for other types of images. The stated goal is always so that only one part of the name differs from the rest so there is the least differences between files and easiest sorting and use. Perhaps it's my own fault by saying "policy" instead of "guideline" but I don't really see a difference between the terms when my goal is the same. I ask you to try and edit a section of Comparison of European road signs as I have been working on, and you will see how difficult it is to edit a list of countries together with all different naming styles and how much easier it would be if they followed one common style of naming. Yes, different countries have different internal designations for their sign, what Ukraine calls "1.39" Ireland calls "W 170", but the benefit is both files follow the convention of "Country road sign designation". It should also be noted quite a few countries we have do already follow this convention, so we're hardly starting from scratch but rather bringing the other in line. I do have file mover rights and will be working on this in the future either way, but I am seeking some sort of backing first because that will at least ease the process as much as possible. I understand this is hardly a prolific topic, I'm even sure some users are laughing at me bringing this up, but surely you can see the benefit gained from this proposal. Fry1989 ^eh? 17:21, 24 February 2014 (UTC)

I’d like to stress that I personally have nothing against Fry’s proposal as it is expressed, theough, and that I hope it goes ahead. -- Tuválkin ✉ 03:24, 26 February 2014 (UTC)

As for Category:W3-3 - Signals Ahead it included in USA road subcategories but has within it an Australian subcategory. For SVG/PNG type files as in that category I so no issue in having a guideline because once created they are fairly static and any updates or changes would result in a new file being created, to that end at the very least they would need a date or some other identifier as well otherwise we loose content when updates occur. For actual photographs of the signs in place I disagree as the many times the sign isnt the primary purpose of the shot, so to rename these image or expect people to follow a convention that doesnt match the purpose is just going to create issues. It'll guarantee a lot of drama if images are renamed under such circumstances. Gnan

garra 05:16, 25 February 2014 (UTC)

I do not propose renaming any photographic files, only PNG/SVG diagrams of the signs themselves. Fry1989 ^eh? 16:32, 25 February 2014 (UTC)

Thats not clear in your proposal, please clarify it Gnangarra 00:02, 26 February 2014 (UTC)

I hope I can do so to everyone's satisfaction. My proposal only applies to diagrams of actual signs, no photographs. My proposal only applies where we know a country's internal designations for their signage, an example of this would be that if I found an Italian document on their road signs and it included sign-specific designations, File:Italian traffic signs - altri pericoli - provvisorio.svg would be renamed to "Italy road sign 8876" or whatever the Italian Transport Ministry's designation is for that sign. Several countries already follow this convention, namely the Ukrainian and Irish signs which I have uploaded personally. My proposal excludes the American, British and Dutch road signs which already follow the ideal of this convention and are already uniform in their naming, but will apply to other countries (both current and future uploads) where the signs include overly complicated names (that Italian file as an example) or are not uniformly named (the French signs being an example of that). The ideal is so that there is one common naming convention and a reliable uniformity for all road signs, the only difference being the name of the country and the sign designation which is dependent on whether we can find such information (some countries have these documents freely available, others do not). Below is are two examples of why I feel this is necessary.

Here are three common "No U-turn" signs that are not named uniformly:

• File:U-käännös kielletty 334.svg
• File:CH-Vorschriftssignal-Wenden verboten.svg
• File:Mauritius Road Signs - Prohibitory Sign - No U-Turn.svg

And here's the same 3 "No U-turn" signs from counrties' where our files are named uniformly:

• File:Ireland road sign RUS 017.svg
• File:Hong Kong road sign 123.svg
• File:Argentina road sign R5.svg

They all represent the same thing for the ease of this proposal, but the first three have all different styles of naming, and the other three all follow the uniform convention I'm proposing. Fry1989 ^eh? 04:11, 26 February 2014 (UTC)

Well I've yet to face any opposition. I don't exactly have the backing I was looking for, but I'll take this as a yes. Fry1989 ^eh? 02:20, 5 March 2014 (UTC)

Category:Possibly unfree images

A user created this category presumably for handling the cases of images that might have copyright issues, but the person who put the images into this category has uncertainty about that and implicitly searches for a second opinion. Commons apparently has not a specified procedure to follow or tool to use in cases like the above-mentioned. I think this sort of shared watchlist would be made known and improved, unless someone proposes an alternative procedure. Jespinos (talk) 02:21, 17 February 2014 (UTC)

We already have {{check categories}}, {{wrong license}}, and {{LicenseReview}}; I tested the latter recently, worked like a charm. FWIW I've fixed the missing parent cat to License review needed, but I still think this new cat is a kind of dupe actually asking for a far better documentation of what already exists and works. –Be..anyone (talk) 04:03, 18 February 2014 (UTC)

Fixing cats turned out to be a good idea, Copyright statuses already has Possibly unfree license images, there's one cat too much for this job. –Be..anyone (talk) 05:08, 18 February 2014 (UTC)

Among the mentioned templates, only "wrong license" appears to be suitable for the intended purpose, but there are images that have been within its associated category for years and the images are not necessarily suspected copyvios. On top of that, it appears to me that manually tag an image is a bit more complicated than categorize it using HotCat, though the ideal thing would be a one-click tool. With respect to dupe categories, certainly would have no more than one category for the same purpose. Jespinos (talk) 19:18, 18 February 2014 (UTC)

Has a one-click tool ever been suggested? That would be really useful. --CyberXRef^☎ 05:30, 17 March 2014 (UTC)

I've never used a tool for categories so far, but if something works for you: The surviving "possibly unfree" category (of the two a month ago) should be good enough, using a template for this job isn't required. If there are still two categories better stick to the template(s) until folks sorted it out. –Be..anyone (talk) 21:00, 26 March 2014 (UTC)

Out of Scope/Private images should be speedy deleted.

Why do we allow random images which people upload to wikimedia to stay on wikimedia for atleast a week?. I propose we be allowed to tag all images for speedy deletion which we feel should not have been uploaded to commons in the first place....I feel atleast 90% of images that are currently awaiting deletion at Commons:Deletion requests should have been deleted the moment they were found...... I won't be surprised if commons has atleast a million images which should not be here in the first place, especially those out of scope or those which are private in nature. We should not be allowing users to treat commons like a dumping ground for their "social" images and i feel its about time images, especially those which are private in nature (self shots etc) be deleted on sight....just like Copyright violation images...Some may need discussing, but its usually up to the person who tags the image to decide if it should be added to "DR" or tagged for speedy deletion....I propose we change our stance in relation to this and this will also allow admins to focus on images that really deserve discussion...--Stemoc (talk) 06:29, 6 March 2014 (UTC)

What’s obviously off-scope for one admin is obviously in scope for another. Because there are disagreements of what the scope of Commons is, regardless of COM:SCOPE. Too many DRs are closed through a coin-toss outcome: If the closing admin is a “deletionist”, it will be deleted, regardless of any discussion. And that is the problem about scope evaluation. (Also, some times DR nominations and closings are used as a weapon to attack users, incl. even by, and against, some admins. But that is not just a problem of scope, that’s a wider problem.)

That said, I can only agree with you about the utter garbage that gets loaded every day into Commons, and how much those uploaders have no idea about, or interest in, or even respect for, the scope of Commons (regardless of a handful of those that turn out to be usable). The surest way to shut that down is to turn off mobile uploads and all the silly UI crap that comes with it («This article lacks a photo: Add one now!»), but there’s no likely chance that will happen.

I cannot see, though, what’s the rush. I have been going through 2012 uncategorized uploads and nominating the most egregious cases for deletion — the months those files were in Commons, forgotten by the uploader and noticed by nobody else, are no big deal, compared with the risks of what is being proposed here: Speedy deletion based on content/scope can be hijacked by narrow-minded deletionists and cause loss of valuable material, and can be misused for malicious attacks: Meanwhile, it is not necessary, nor sufficient, to avoid the creeping of crap.

-- Tuválkin ✉ 12:48, 6 March 2014 (UTC)

Stemoc -- Random personal snapshots without discernible general interest should certainly be deleted, but there are official zones of tolerance for some personal images (such as "userpage images") and de-facto tolerance in certain other areas (such as proposed flags / "special or fictional flags", unless hoaxing or hatemongering, etc.). I'm not sure that this is the highest priority area for a rigorous crackdown. AnonMoos (talk) 03:51, 8 March 2014 (UTC)

I'm aware of the user page images but generally, a person uploads a certain number of useless images as well..I generally report those that upload multiple images and ignore those that upload one or 2 pictures of themselves assuming they would use it on their userspace..probably not a high priority but at the end of the day, i would say over 80% of all the nonsense images on commons would probably be those private images..from time to time i come across images that would have been deleted earlier had the admins been able to keep a closer attention to them but with the influx of over 1000's of unnecessary images per day, it may just be hard to do so...I think a change or an upgrade to the system is very important..--Stemoc (talk) 04:34, 18 March 2014 (UTC)

Maybe a deterrent then? Not sure how many actually read the notice when uploading images, if they did, we wouldn't have to deal with so much cr*p everyday..Maybe changes to the uploading warning form or rewording of the Commons:Upload section, and yes most images do come via "mobile" platform. Most people assume uploading from other sites is OK, i remember monitoring twitter/facebook for the last 2 years and reading ridiculous comments regarding image uploads, even tagged one for deletion earlier today..Ignorance of Commons policy is one thing but to completely disregard the policy whence uploading is another..I don't have a number but i assume most "violation" uploads are by users who upload the image via "ownwork" option....this was a problem a few years back on enwiki until the sysadmins decided to move all uploads (except NFC) to commons..with so much "cra*" on commons now, its no wonder that some images that fail the copyvio licensing remain hidden on commons for more than a year..we definitely need some way to counter this, even if it means getting Skynet involved.. --Stemoc (talk) 12:18, 8 March 2014 (UTC)

One thing I agree on is that the {{Own work}} template is much abused; unfortunately it's also been used as a rationale in deletion debates for keeping images that might have otherwise appeared to be copyright violations. This shifts the burden of proof from the uploader merely asserting that it's "his own work" without any necessary evidence whatsoever to the one proposing deletion, when it should arguable be the other way around. I believe that oftentimes people only put the "own work" tag because they want to simply bypass the hassle of shutting off the glaring red warnings on either the Special:Upload or Special:UploadWizard forms, not because they truly believe it's their own work or even understand what the tag is used for. TeleComNasSprVen (talk) 22:25, 8 March 2014 (UTC)

Out of scope images are not the most serious problem. Blatant copyvios are. In one day only, I deleted over 400 obvious copyvios from Category:Media uploaded without a license as of 2014-03. 99% of images in this cat are not OK. More help welcome. Yann (talk) 04:15, 18 March 2014 (UTC)

For info: Meta RfC

On another page an editor posted a link to a Meta-RfC about the Creation of a Global Wikimedia Commons. Only for info, I missed it despite of editing on both wikis, and maybe it is not only me. –Be..anyone (talk) 11:40, 9 March 2014 (UTC)

Removing AddInformation.js from the gadgets

MediaWiki:Gadget-AddInformation.js is old and unmaintained and it its present form it does more harm than good when invoked. It should be removed from the gadgets until its numerous issues are fixed.--Underlying lk (talk) 23:10, 27 March 2014 (UTC)

Well, I still use it. I should be fixed rather than removed. Regards, Yann (talk) 05:57, 28 March 2014 (UTC)