Commons talk:Blocking policy

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

Open proxies[edit]

I just noticed that this policy contains no provision for blocking open proxies. Such blocks are accepted as standard practice. The typical duration is one year. The reason for not going with indefinite is to allow for IP address reassignments, fixing of loopholes, etc. See meta:No open proxies for the Wikimedia-wide policy. Specific block settings seem to vary, so it would be good if we could agree on some standard principles and spell them out. LX (talk, contribs) 14:34, 28 September 2011 (UTC)

No reason not to make this explicit. One year duration seems good to me. Perhaps you might propose words to this effect. With no objection, it may be added. Walter Siegmund (talk) 18:41, 30 October 2011 (UTC)
For better or worse various folk do various things. --Herby talk thyme 18:50, 30 October 2011 (UTC)
Added. LX (talk, contribs) 10:33, 1 June 2013 (UTC)
I don't know if anyone is monitoring this page, but I've opened up a proposal related to this topic at Commons:Village pump/Proposals#Indefinitely blocked IPs. Please comment there when you have the chance. TeleComNasSprVen (talk) 03:25, 10 March 2014 (UTC)
OK, done. LX (talk, contribs) 11:51, 10 March 2014 (UTC)

Socks?[edit]

I don't see any mention of blocking sockpuppets here. Obviously we do it fairly routinely. Most socks are vandals, copyright violators, block evaders or other problems that are listed here, but we also block socks that simply use two or more usernames to cast multiple votes or generally mislead. As I understand the rule, a sock may be blocked on sight if it is used to "mislead, deceive, or disrupt; to create the illusion of greater support for a position; to stir up controversy; or to circumvent a block, ban, or sanction" (from Sock puppetry).

While such actions probably won't result in an immediate indefinite blocking, they are certainly reasons that we block accounts.

     Jim . . . . Jameslwoodward (talk to me) 13:24, 17 March 2012 (UTC)

en.wp has an entire, lengthy policy for it: en:Wikipedia:Sock puppetry. We could at least mention it as an issue (bearing in mind there are legitimate uses of multiple accounts too - en:Wikipedia:Sock puppetry#Legitimate_uses). The nutshell summary of the en.wp policy might work as a basis:
The general rule is one editor, one account. Do not use multiple accounts to mislead, deceive, or disrupt; to create the illusion of greater support for a position; to stir up controversy; or to circumvent a block, ban, or sanction. Do not ask your friends to create accounts to support you. Do not revive old unused accounts and use them as different users, or use another person's account.
Well, I guess you already quoted the key bit :) Rd232 (talk) 17:02, 17 March 2012 (UTC)
I agree. Rewording that as an item in our list: "Abusing multiple accounts to mislead, deceive, disrupt, distort consensus or to evade blocks or other sanctions. Secondary accounts are typically blocked indefinitely. The primary account may or may not be subject to new or extended blocks depending on the circumstances." LX (talk, contribs) 10:54, 1 June 2013 (UTC)
Added. LX (talk, contribs) 08:13, 15 July 2013 (UTC)

Instructions for administrators section[edit]

This section has remained largely unchanged since it was added in 2006, and it shows. It does not reflect how administrators work these days, and it deals only with copyright violators. Commons has much higher traffic and is much more multilingual today than it was then. Today, administrators block about 30 users per day on average. Rather than recommending writing "strongly-worded" custom warnings to each and every one of them and trying to find administrators who speak Tagalog, Catalan or Vietnamese (all while the user continues to upload copyright violations in batches of 50 at a time), we use multilingual talk page templates these days, and giving such warnings is not restricted to administrators. The essence of the section seems to be that users should generally be duly warned before being blocked.

I'd like to propose the following rewrite, which also incorporates the "When in doubt" section:

Before blocking
  • For blocks based on disruptive behavior, such as vandalism, repeated copyright violations and manual promotional activities, ensure that the user has been appropriately warned, preferably using a block warning template. No warning is necessary when blocking open proxies and users with inappropriate usernames. Accounts and IP addresses used solely for severely disruptive purposes such as automated spamming, serious vandalism or harassment may also be blocked without prior warning.
  • Controversial blocks may be discussed at the blocks and protections noticeboard, preferably before they are applied if at all possible. As a rule of thumb, when in doubt, do not block.
When blocking
  • Blocks can be applied to registered users, IP addresses or address ranges. Range blocks are especially powerful tools, and discussion of these is particularly encouraged.
  • As blocks are preventative rather than punitive, use a block duration that is proportional to the time likely needed for the user to familiarize themselves with relevant policies and adjust their behavior. Also consider the user's past behavior and the severity of the disruption. When blocking IP addresses, keep in mind that innocent third parties sharing the same addresses may be affected.
  • Provide a reason for the block. The rationale should preferably use links to relevant policies to help the blocked user understand why they have been blocked. Where appropriate, diffs or permanent links documenting the reason for the block are also helpful.
  • Account creation should be prevented in most cases, but may be allowed when blocking an inappropriate user name to allow creation of a different name.
  • Autoblocking of IP addresses used by the blocked user should typically be disabled when blocking bots and enabled in most other cases.
  • Only prevent the blocked user from using their talk page or sending e-mail if they are likely to abuse these privileges.
After blocking
  • Notify the blocked user, preferably using a user block template.
  • Watch the blocked user's user talk page and ensure that requests for unblock are attended to.
  • Blocks based on disruptive behavior should be lifted if there is reason to believe that the disruptive behavior will not resume.
  • Controversial blocks may also be discussed at the blocks and protections noticeboard after they have been applied. To avoid wheel warring, they should only be lifted another administrator if there is consensus to do so, even if there is no clear consensus in favor of the original block.

LX (talk, contribs) 13:40, 1 June 2013 (UTC)

I've always felt that rangeblocks should usually be done after reference to project CUs. As stated they are powerful and for anything other than 24 hours say the impact should be assessed by CUs IMO. --Herby talk thyme 13:45, 1 June 2013 (UTC)
Seems fair enough. What's the preferred venue or procedure for requesting this? Commons:Requests for checkuser doesn't seem particularly appropriate. Maybe there should be a Commons:Checkusers' noticeboard? LX (talk, contribs) 14:03, 1 June 2013 (UTC)
I've updated this part of the policy now, taking into account Herbythyme's comments above. LX (talk, contribs) 10:47, 19 July 2013 (UTC)

Username policy[edit]

This was discussed once before: https://commons.wikimedia.org/wiki/Commons_talk:Blocking_policy/Archive_1#Username_Policy

But I'd like to add that it's problematic for users who don't know if the account name they're aiming for might possible be blocked, or not. I'll take "rule of law" over what constitutes as a single person's "common sense" at a specific time and place. For example, I want to create an account titled myCompanyName.com to contribute pictures I want to be attributed in that way (in according to the creative commons BY-license: "[you must identy] the creator(s) of the Licensed Material and any others designated to receive attribution, in any reasonable manner requested by the Licensor (including by pseudonym if designated);"). But I'm not sure I'll be banned or not for doing it as there's no actual policy for it.

See also here for an explanation WHY I think it should be in my right to create an account with what could be called a "promotional" name. TempUser213 (talk) 05:38, 16 February 2014 (UTC)

This discussion should take place at Commons_talk:Username_policy#Ban on company names doesn't make sense. Starting discussions in more than one place just wastes editor time. .     Jim . . . . (Jameslwoodward) (talk to me) 15:29, 16 February 2014 (UTC)

RFC: Commons:Blocking policy#Use criterion 2[edit]

Proposal to slightly expand the wording of "edit warring" to also include "upload warring", at Commons:Overwriting existing files#Controversial or contested changes (also known as "COM:UPLOADWAR"). My suggested version for the official wording:

  • Edit warring. This also includes "upload warring" wherein users continuously revert each other to their preferred versions of a file within a limited timespan, causing disruption to file usage across Wikimedia projects and for other reusers.

No hard limits like Wikipedia:3RR though, that should be up to admin discretion. TeleComNasSprVen (talk) 09:31, 20 April 2014 (UTC)

Support[edit]

Oppose[edit]

Discussion[edit]

  • Good idea, it wouldn't hurt to make it clear here that upload wars are included. I think "continuously revert [...] within a limited timespan" wouldn't cover all upload wars, though. COM:UPLOADWAR puts it better, referring to users who "repeatedly upload different versions [...] to have their version be the visible one". The subclause about "causing disruption" seems to invite wikilawyering too. Maybe that would be be better as a separate sentence, explaining why upload wars are problematic, but perhaps we should just leave such detail to the COM:UPLOADWAR guideline. --Avenue (talk) 00:43, 21 April 2014 (UTC)
    • Avenue: thanks for the review. I agree "causing disruption..." might be superfluous; I inserted that clause merely as a brief justification for a block (upload warring has negative consequences, and blocks are supposed to prevent negative consequences). COM:UPLOADWAR has enough space to include that as further explanation. The "limited timespan" restriction is to prevent administrators from broadly interpreting upload wars, which may give them too much power and prevent this proposal from passing. For example, User:A overwrites Image:Foo and User:B reverts to the original version. After a few years, because of some new information coming to light or a negotiation with User:B or other reasons, User:A reverts to his version. Would it then be considered an upload war, if disruption is not apparent to the other projects? I fear if admins have power to interpret as such, this proposal might not pass. Whereas reverts within a few hours/days might be considered "within a limited timespan". TeleComNasSprVen (talk) 01:04, 21 April 2014 (UTC)