Commons talk:Blocking policy/Archive 1

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


Report all blocking?

Should all blocking be reported at Commons:Administrators' noticeboard? I would say this is better, since then other admins could review the block. / Fred Chess 13:33, 28 August 2006 (UTC)

We've had fifty blocks or unblocks in the last eighteen days [1]. That would be a lot of traffic for AN. I'm not really against the idea of reporting each one, but I'm not sure I see the value in it, as I doubt very few will get any extra attention. Jkelly 16:31, 28 August 2006 (UTC)
ACK. Not necessary unless it's likely to be contentious. pfctdayelise (translate?) 05:12, 29 August 2006 (UTC)
It's probably easier to stay updated by looking at the block log or the List of blocked IP addresses and usernames. As pfctdayelise says, if it's likely to be contentious, a notice might be a good idea, but just for checking up on what others are doing, the log is better since it's guaranteed to be complete and accurate. Cnyborg 22:54, 29 August 2006 (UTC)

Comments

  • Put {{Blocked User}} on the user page of indefinitely blocked users.
    • There should also be a comment for users who have been blocked for a shorter time. I created Template:Blocked, before redirecting it to the other one. It would otherwise look like this [2] (a Spanish version is also available).
  • Blocks of people adding {{Speedy delete}} tags. This should perhaps be added.

Fred Chess 11:02, 31 August 2006 (UTC)

non-cooperation

There should definetly be a blocking policy added for users who are immune to advise and are disruptive in their activities, such as deletion of articles or categories, etc. See this RFC for example [3] Gryffindor 21:57, 26 September 2006 (UTC)

This is a good idea, i suggest adding "disruptive behaviour, such as refusing to talk, edit warring, revert warring and harassment other users" as a block reason. -- Bryan (talk to me) 17:50, 1 January 2007 (UTC)

Usernames

A section should be added to this policy for usernames. With the advent of SUL, let's not fall into the same pit that en:wp did, I suggest that we not restrict to just the ASCII alphabet. Also I think a rather permissive policy is best, unless it is a clear attack in a major language, let it go. Thoughts? ++Lar: t/c 02:25, 20 February 2007 (UTC)

Might have been inspired by a posting of mine! I think some guidance would be useful (& I spend some time on RC so see them quite quickly). The obviously obscene/racist/offensive I guess are clear but it would be good to know what others think --Herby talk thyme 08:13, 20 February 2007 (UTC)

Recommended block times?

I just removed this: "Suggested block lengths:

  • 1st time: 1 day/3 days
  • 2nd time: 3 days/1 week
  • 3rd time: 1 week/1 month
  • 4th time: indefinite"

...as it is not representative of what we actually do, and could confuse users. If we need something like this, we should discuss it further. Jkelly 22:12, 18 March 2007 (UTC)

Agreed. To me it also relates to the nature of the offense (Vandalism being my specialist subject!). Playful vandalism (1st time) really may only need a 2 hour block to ensure they realise such things are possible. Repeated blanking/abusive language may lead me to block for longer and possibly very quickly. However I also look at the Wikipedia record most of the time these days - we seem to receive the attention of those with long blocks on WP and I tend to up the block based on that record (I do the same on Wikibooks). I also keep an eye on vandalism reports on Meta.
I suggest it is very hard to be at all precise on this (& almost every admin will have somewhat differing views) --Herby talk thyme 08:13, 19 March 2007 (UTC)
Sure, blocks should be placed according to the faith and severity of the misuse of the user, and I think that every admin can determine that for themselves. -- Bryan (talk to me) 18:42, 19 March 2007 (UTC)

Policy change

I think we should possibly change our policy when it comes to the blocking part. Some admins tend to give an indef block at first time, I disagree with any admins doing that unless it's a severe case where the user really have uploaded a lot of copyvios & any other kind of block doesn't stop them. I think we should possibly show this in the block policy to determinate how long a user should be block, as Common sense isn't always working for all admins. --Kanonkas(talk) 19:57, 23 September 2008 (UTC)

Short blocks make no sense on Commons.
Short blocks are a tradition from Wikipedia, where they serve as a punishment.
On Commons, someone upload copyvios in batches can be of two sorts:
  • someone who does not know copyright laws -- typically because he does not understand how seriously we take it
  • someone being deliberately disruptive.
The tactics of short, increasing blocks culminating in a ban is clearly a waste of time on the second sort: he could be banned from the start if we could detect him. On the second sort, I contend that it is counter-productive: the user might not notice the first block if he does not come on the site for over 24 hours; or he might see the block as a temporary nuisance and not think further of it.
I have been using an entirely different tactics of blocking indefinitely when dialog cannot be undertaken with a copyvio uploader, even as a first block. It is not a ban, but a truly indefinite block -- a block for which the duration is not explicitly set. I also put a template on the user's talk page explaining him why he is being blocked, and offering automatic unblocking if the user writes that he has read and accepted our policy; I also offer assistance, and point to the page that lists admins by language.
The advantages of this approach is no time is wasted on "vandals", and that ill-informed users will always understand how serious the matter is. It is far more efficient than the iterative method, because the block is used as a safety for the user (preventing him from doing something harmful) rather than a punishment. Whether the user comes back 6 hours later or 5 days later, he will see the block, and be unblocked immediately after reading the documentation. This is much more flexible and better adapted to educating newcomers than the hard "24-hour, 48-hours, ..." system. Rama (talk) 20:10, 23 September 2008 (UTC)

Block log

I came to a job interview. It went very well, and I was about to be offered a job. Then hiring supervisor asked: "What is your hobby?" "I like taking pictures and uploading them to Commons." - I said. The supervisor asked me to show few of my images. I logged in to commons, hit "My contributions " and... The supervisor said: "Let's see your block log". I was refused employment. OK it never happened, but it could have. When a person gets traffic ticket, his records are erased in 3 years, and very few people could see them. If a person gets blocked on Commons everybody could see it.If a blocked user sees his own block log, it is like a constant reminder, if the whole world see it, it is like a constant punishment. I'm not talking about myself here. I'll live with this, but IMO it might be a good idea to make block logs available to Commons administrators only. Thank you.--Mbz1 (talk) 20:53, 23 January 2009 (UTC)

Rewriting

Kanonkas has proposed to rewrite this page. The general meaning will be retained, but wording and structure will be altered to clarify the policy and improve the readability. Anyone is free to chip in. —Anonymous DissidentTalk 10:46, 22 May 2009 (UTC)

Legal threats

Making legal threats is explicitly defined as grounds for indefinite blocking on several Wikimedia projects – most notably on English Wikipedia. Meta also makes reference to this in meta:Banned user. However, it seems to be poorly documented here on Commons. I'm proposing an addition to Commons:Blocking policy. Under the Use heading, add the following point:

  • Legal threats. Users are encouraged to attempt to resolve disputes on Commons. If that fails, we cannot prevent anyone from taking legal action. However, if a user takes legal action or threatens to do so, they are prohibited from editing Commons (including their own talk page) until the legal matter has been resolved. This is to ensure that only proper legal channels are used and to avoid exacerbating the dispute.

I'm hoping that's enough and that we can do without a special guideline or policy. Your thoughts? —LX (talk, contribs) 16:03, 19 March 2011 (UTC)

I disagree. A copyright owner must not be blocked just because he is announcing legal action. /Pieter Kuiper (talk) 16:34, 19 March 2011 (UTC)
(ec)It would depend how it was phrased for me. "Legal threats" should probably be dealt with off wiki anyway. --Herby talk thyme 16:47, 19 March 2011 (UTC)
I'm not sure I can see a plausible scenario where a copyright holder participating in Commons cannot use Commons' procedures to resolve a copyright problem but instead finds it necessary to take legal action whilst still having a need to edit here. Perhaps you could elaborate? Keep in mind that copyright problems are no less likely here than on English Wikipedia, and they make no exceptions for copyright-related legal threats in en:WP:NLT. —LX (talk, contribs) 16:46, 19 March 2011 (UTC)
I can. If a DR ends as keep because it has a PD-art, because we think it is de minimis, because we think it is PD-ineligible etc. In that case it is not unlikely that "the copyright holder" does not agree and would like to take a trial to see if a judge agrees that Commons can host the file. If they inform us in a nice way do you think we should always block? --MGA73 (talk) 16:59, 19 March 2011 (UTC)
I agree. And let me add that I am here with my own name, so I am more likely to have to deal with this than anonymous Joe. And in fact I have received a letter in the mail with legal threats. But I would not regard threats with legal action as a reason to block. Maybe I would feel different if I lived in the US, where it is more likely to get costly. /Pieter Kuiper (talk) 17:07, 19 March 2011 (UTC)
Yes, I think we should. I think en:WP:NLT explains the reasons quite well. —LX (talk, contribs) 17:34, 19 March 2011 (UTC)
This suggestion is probably related to the discussion here here. Personally I think we should block users that is disruptive. Not just ordinary users but also administrators. Legal threats could be one of the things we chould block for. I do not mind that that is added to page to illustrate what could be blocked for.
If someone is talking about legal assistance in a case it could simply just mean that the user wants some legal expert to help prove that a photo is not a copyvio. It seems that it is also accepted that users get upset and say/write things that they should not have done without getting blocked. So I do not think that all talk about legal assistance should result in a block. It depends... --MGA73 (talk) 16:51, 19 March 2011 (UTC)
Yes, it was because of that discussion that I found that we seem to have no explicit statement to discourage legal threats. I've tried not to focus on a single instance when writing the proposal, though, and it's not intended to have any impact on this particular case. Seeking legal advice is different from taking or threatening legal action; I think that's pretty clear. —LX (talk, contribs) 17:41, 19 March 2011 (UTC)
Why not just transwiki WP:NLT? -mattbuck (Talk) 12:40, 21 March 2011 (UTC)
I agree with Alex, although I think it should be a universal Wikimedia policy, but we should include it in our policy too, so users be aware about it, the policy is pretty clear on enwiki, perhaps as Mattbuck suggested we could copy from enwiki.   ■ MMXX  talk  18:25, 29 May 2011 (UTC)
I support adding NLT either explicitly or by reference to WP:NLT. Most of the major sister projects have NLT policies. Providing links may be helpful to those who are not fluent in English. --Walter Siegmund (talk) 23:12, 29 May 2011 (UTC)

I feel a bit uneasy here. Obviously we should block troublemakers, and spurious legal threats is one way people have made trouble. But I've also seen this policy misapplied, e.g. I've seen cases where a user said "I'm going to do this awful and unlawful thing to you!" and someone replied with "If you do that I will be calling the police or hauling your butt into court!", only to be bludgeoned by someone with the WP:NLT. Thats stupid. The purpose of a no legal threat policy is to prevent trouble makers from intimidating people in the project with spurious threats, not to prevent people from presenting the reasonable defense against other kinds of spurious threats. I would rather say that coercive behavior is prohibited in general than to focus on "legal threats", except for the fact that we use coercive behavior all the time ("if you don't stop doing X you will be blocked") and I don't quite know how to separate the permissible and non-permissable coersion with simple language. --Gmaxwell (talk) 03:42, 30 May 2011 (UTC) .

  • When a person uses the phrase "my lawyer...." these are a clear threat to which a user cannot reasonibly respond, any such threats(legal, physical, or phsycological) where a person cant reasonibly respond or be protected within the community should be result in a block as harassment. Where a person implies that other users could be subject to such actions these people should be indefinitely blocked until the Commons community can be satisifed that the person is no longer theatening Users. IMHO it should also carry a no repeat clause, do it once well ok you were upset you've calmed down, do it twice bye-bye. Gnangarra 04:55, 30 May 2011 (UTC)
    • Of course, if they withdraw the threat and make it clear that they won't continue the behavior they should be unblocked. But "two strikes you're out" is silly and overall legalistic. You're out when no one who can unblock you believes that you will stop or that you're not more valuable than the trouble you cause. No other standard will actually work, regardless of what the rule says. --Gmaxwell (talk) 06:30, 30 May 2011 (UTC)

I think that we need to draw a distinction between

  • a threat of having a lawyer issue a takedown notice to Commons or of suing WMF to force the takedown of an image and
  • a threat of suing an individual editor or Admin for any reason.

Although I hope we don't see too many of the first, it is possible to disagree about an image. I have seen DR closures where if I were the copyright holder and I cared enough, I might have taken action. The second, however, is pure intimidation and can be scary, particularly for those of us who are not anonymous. Since all of us work within the framework of community consensus, there is never a single individual who might appropriately be the target of a lawsuit. Therefore, I advocate promptly blocking anyone who issued such a threat. As a limited check against abuse, I would add to the policy that the block could not be imposed by the person threatened.      Jim . . . . Jameslwoodward (talk to me) 22:43, 1 April 2012 (UTC)

Of course there are always individual persons responsible. That is primarily the uploader. The Foundation has made that very clear, it accepts no responsibility. Blocking and cutting communication might very well increase the risk for the uploader of getting sued. /Pieter Kuiper (talk) 22:52, 1 April 2012 (UTC)
I am opposed to the adoption of this. Trolling, harassment or intimidation should be dealt appropiately; but blocking users that issue valid legal claims only scalates the problem and the liability for the project and the blocking person. --Marco Aurelio (disputatio) 21:09, 2 April 2012 (UTC)
No, legal threats should be dealt with by lawyers. We can comment on copyright issues, but once someone actually issues a proper legal threat, rather than just a "hi, this is my image and is not used with my permission", it is for the WMF to deal with, and further comments here may be prejudicial. -mattbuck (Talk) 21:15, 2 April 2012 (UTC)
"it is for the WMF to deal with" - no, with the notable exception of DMCA takedowns, it's not for the WMF to deal with, because they're not responsible for the content. Also, what is a "proper" legal threat? Rd232 (talk) 21:33, 2 April 2012 (UTC)

Personal attacks

Perhaps we should also make it more clear that personal attacks is also a reason to block users (and admins). At the moment we have "Harassment" but I think that harassment is something that goes over several edits. I think that comments like "moron", "freak" etc. should also be a valid reason to block users. --MGA73 (talk) 16:51, 19 March 2011 (UTC)

Agreed - always been a reason for me. plus anything racist, sexist, religious etc. --Herby talk thyme 16:53, 19 March 2011 (UTC)
Yes that too. Good examples. --MGA73 (talk) 17:01, 19 March 2011 (UTC)
I would say that both personal attacks and harassment are instances of "gross incivility," as English Wikipedia calls it, and I think that this is what we should target. This also includes attacks which are not personal, such as statements which are sexist, racist, ethnically prejudiced and other sweeping attacks. "Everyone here is a freak and a moron" is only marginally less damaging to a collaborative atmosphere than "(some user) is a freak and a moron."
Blocking of admins is a separate question, and should not be emphasised more or less for any particular blocking reason. I agree, however, that we should have information on blocking of administrators. This should include an assertion that the standards should not be different for administrators, an explanation of how an administrator should act if blocked and the importance of avoiding wheel wars, and a discussion of the impact on the ability to continue as an administrator. —LX (talk, contribs) 17:17, 19 March 2011 (UTC)
Why is the blocking of an admin "separate"? They are only users. --Herby talk thyme 17:48, 19 March 2011 (UTC)
By saying that it's a separate question, I meant that it is a separate question from whether or not we should have a point about personal attacks or similar. The reasons we may need to have additional information about blocking of administrators are that there are sometimes perceived doubts about whether or not administrators are actually regarded as regular users, that administrators are technically able to unblock themselves, and that there may be uncertainties about whether one or more blocks in and of itself indicates that a user is unsuitable as an administrator. —LX (talk, contribs) 18:28, 19 March 2011 (UTC)
Just my opinion
They are regular users
For me they should have a higher standard of behaviour than "ordinary" users. --Herby talk thyme 18:50, 19 March 2011 (UTC)
Oh - and unblocking themselves should mean immediate de-sysop. --Herby talk thyme 18:50, 19 March 2011 (UTC)
This whole NPA craze leads to nowhere. It may work in an environment of peers, within a single culture, but commons is even more diverse than the main wikipedia. The recent Cecil case may be borderline - I suspect that some may be actually offended by those words (adressed to someone else, not themselves). Yet others will be offended by a fart two blocks away or an all-caps response. I've heard that some will even object to being called "racist" (believe it or not). There's just too many personal likes and dislikes in the equation, you can't suit everyone. NVO (talk) 10:37, 20 March 2011 (UTC)
@LX: Currently "gross incivility" is not on the list so if that is a better way of saying it than "personal attacks" it is fine with me (but perhaps with the addition “for example personal attacks, harassment etc.”). As long as we agree that we should not accept such behavior.
@NVO: Yes it is possible that some may be not offended but I think that we should not conclude that we should therefore allow any behavior. Instead it would be better if we agreed that personal attacks are not ok because they may offend some or most users. That does not mean that we should be over sensitive and yell "personal attack!" every time we disagree on something. I'm sure that most users will be able to judge if it is ok to say "you fucking moron" or "stupid pedophile" or whatever. --MGA73 (talk) 18:41, 20 March 2011 (UTC)
en:WP:PA is even more widely disseminated among the major sister projects than NLT. "Comment on content, not on the contributor. Personal attacks do not help make a point; they only hurt the Wikipedia community and deter users from helping to create a good encyclopedia. Derogatory comments about another contributor may be removed by any editor. Repeated or egregious personal attacks may lead to blocks." I support including PA either explicitly or by reference. --Walter Siegmund (talk) 23:20, 29 May 2011 (UTC)

Username Policy

Shouldn't the inappropriate usernames point be removed from the "Common reasons to block" section? It's kind of misleading, since I filed a username block request and then was told that the policy was still only a proposal and blocks were therefore not being made on that basis. Regards, MacMed (talk) 20:05, 6 July 2011 (UTC)

There are cases where a username would clearly be inappropriate and should be blocked based on that - but that's going to need common sense from the admin at the moment. I've just delinked the proposed username policy to avoid creating the confusion that it is a proper guideline/policy... Mike Peel (talk) 15:52, 19 August 2011 (UTC)
I linked it back up again before seeing this post -- thinking that that was only a minor edit. Although it is only proposed policy, it has had no significant changes in two and a half years and is de facto policy. Since we say that we will block inappropriate usernames, I think we should link to our best discussion of what that means.      Jim . . . . Jameslwoodward (talk to me) 13:04, 17 March 2012 (UTC)

Open proxies

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?

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

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

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)
The following discussion is archived. Please do not modify it. Subsequent comments should be made in a new section.

RFC: Commons:Blocking policy#Use criterion 2

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

  1. Good idea. Green Giant supports NonFreeWiki (talk) 03:00, 1 May 2014 (UTC)

Oppose

  1.  Weakly We need to be cautious about feeling we need to dot the i's and cross the t's in every policy. The BP requires administrators to have sufficient experience and good judgement to be able to identify disruptive behaviour that requires a block after other remedies such as dispute resolution or warnings and repeated calm explanation has failed. Rather than attempting to cover all scenarios in BP, it may be more useful to be able to point to an exemplar case book of past blocks and actions. --Fæ (talk) 07:49, 3 May 2014 (UTC)
  2.  Weak oppose, leaning neutral A long time ago I got sucked into cleaning up after a series of upload wars by a half dozen people who were going back and forth on whether the little football kit images used in infoboxes on Wikipedia should have the sponsor and manufacturer logos on them or not. Some of the files wound up with 20, 30 uploads. I told all of the participants, essentially "stop this right now or I will block you for disruption". I think other admins said much the same thing. We didn't need an upload warring provision to justify the block, as it was very clearly disruptive behavior that was already blockable. TLDR: Admins can already block for upload wars, so this isn't needed. Sven Manguard Wha? 18:14, 21 May 2014 (UTC)

Discussion

  • 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)
  • I object slightly to the addition because I think it has a limiting effect rather than the broadening effect intended. I would have no hesitation about blocking (as "edit warring") two or more editors who repeatedly uploaded different images to the same file name or who repeatedly reverted the other. Anyone who makes any change to Commons is "editing", so the current wording covers upload and reversion behavior. Adding subsets of "editing" to the rule can have the effect of limiting its generality. .     Jim . . . . (Jameslwoodward) (talk to me) 11:01, 1 May 2014 (UTC)

No consensus to change. Also, the discussion has already been archived.    FDMS  4    11:06, 6 September 2014 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Handling a user and his/her edit during the block

Our policy says "A blocked user is restricted from editing and uploading files, among other things." But it doesn't says anything on what to do if the user override these restrictions during the block. I had seen some arguments that we need to keep the edits/uploads if they are in COM:SCOPE and with good intentions. Jee 13:03, 22 January 2016 (UTC)

Comment: This is being raised directly from Jcb's actions on suspected Russavia uploads as discussed at User_talk:Denniss#Files_being_deleted_by_Jcb. As Russavia is locked by Office action for reasons that are not shared with the community, and their account has not been blocked in line with Commons policies which require a higher level of transparency, changes to this policy would not apply to Jcb's actions as a sysop. --Fæ (talk) 13:37, 22 January 2016 (UTC)

  • Please don't bring R. case everywhere. (BTW, you can see R. is under block since 18 July 2015 and no appeal placed so far. So he is still a blocked user just like PK.) Jee 13:46, 22 January 2016 (UTC)
I am not. You publicly linked it from discussion about Jcb's actions on Russavia's uploads, so must intend it to be relevant. Please remove your link on Dennis' page if it is irrelevant. As you have now linked another new discussion on the Oversight noticeboard, this will appear to be a simple forum shopping exercise relating to Russavia, and odder due to his comments about Jcb's actions on Russavia's uploads which you are taking exception to. I do not understand who "PK" is. --Fæ (talk) 13:58, 22 January 2016 (UTC)
No comments as not "required". Jee 14:11, 22 January 2016 (UTC)
Consensus in Commons talk:Criteria for speedy deletion/Archive 1#Content added while evading a block or ban was that such content may not be speedily deleted. —LX (talk, contribs) 14:29, 22 January 2016 (UTC)
Thanks for the link. I don't see a big consensus for it as been withdrawn. Anyway it is not amended in this policy. It should be. Jee 14:50, 22 January 2016 (UTC)
That makes no sense, could you please clarify. Nick (talk) 17:52, 22 January 2016 (UTC)
(I was away; so the late comment) Because I had seen many socks blocked for the only reason "block evasion"and (sometime) their edits reverted. So our "blocking policy" should state what an admin should do when he encounter a sock. "Do not delete edits" may allow a blocked user to sock as far as his edits are good. This may even kill the purpose of the block. But current consensus seems favoring to it. Jee 14:25, 27 January 2016 (UTC)
Using common sense schould be enough. If OK keep if copyvios nuke. --Steinsplitter (talk) 15:21, 27 January 2016 (UTC)
This is not just about copyvios or uploads. Uploads are not the only area a blocked user can participate. He can "help us" by making valid deletion requests. He can "help us" by making good advice to inexperienced users in Village Pump or Help Desk. A subject expert like Biopics can "help us" to identify a lot of unidentified organisms. If we've only problems with "bad edits", then why blocking a user, whatever may be the reason. We must be STUPID to make unavailable those resources. :) Jee 15:48, 27 January 2016 (UTC)
Maybe I gave up too soon, maybe it wasn't announced broadly enough, and maybe it's time to re-evaluate the consensus. I'll leave it up to others, though. Personally, I still feel like the importance of enforcing the "block means blocked" principle outweighs the risk of overzealous deletion/reverting (keeping in mind that a candidate for speedy deletion does not mean that is must be deleted). —LX (talk, contribs) 18:50, 27 January 2016 (UTC)
It is exactly my thoughts too. Otherwise blocking policy will end up as a toothless sword as anyone can sock freely as far as their intention is good. Jee 02:01, 28 January 2016 (UTC)
Hi, By default, a block means no edit is allowed. Now, as Steinsplitter says, using common sense should be used. Any non-trivial or non-consensual edit should reverted. Regards, Yann (talk) 17:55, 27 January 2016 (UTC)

Confidential evidence

In a discussion, I came to know that a Checkuser or Oversighter is allowed to block a user without revealing confidential evidence. It is a prevailing practice here; but not mentioned anywhere. We even have a template for it. So I suggest to add "Administrators holding Checkuser or Oversight privileges may block/sanction users based on non-public information revealed through the checkuser tool, or on edits that have been suppressed ("oversighted") and are inaccessible to administrators. Such sanctions (or other related sanctions) must be marked properly using Template:Checkuserblock or Template:Oversighterblock." under the subhead Commons:Blocking_policy#Use. Jee 02:57, 29 January 2016 (UTC)

Appeals

We've had mechanisms for appealing blocks since the Pleistocene, and this is mentioned in MediaWiki:Blockedtext, but it's not documented at all in this policy, which I think it should be. One thing that needs clarification is whether unblock requests may be reviewed by the same administrator that initially placed the block. A penny for your thoughts? (Offer does not include actual pennies.) —LX (talk, contribs) 21:32, 14 December 2015 (UTC)

So I guess none of the 75 watchers of this page watch their watchlists. Either that, or you were already too busy drinking glögg/Glühwein/eggnog to comment. ;-)
Let's see if I can get a reaction with a more concrete proposal. This is a suggested wording for a section under the new level 2 heading "Appealing a block", to be placed before the "See also" section:

Blocked users are informed that they may request unblocking. They may do this by adding {{unblock|reason for the request}} to their own user talk page. Alternatively, they may request unblocking with an appropriate reason via e-mail to the blocking administrator or another administrator.

An appropriate reason will almost always include one of the following:

  • An acknowledgement that the block was appropriate and a credible promise that the behaviour that led to the block will not be repeated
  • An explanation of why the block is technically misapplied or not appropriate based on this and other relevant policies and guidelines

An unblock request may be granted or declined. Before granting a request to lift a block placed by another administrator, the reviewing administrator should consult with the blocking administrator, except in obvious, uncontroversial cases. Requests made on user talk pages may only be declined by an uninvolved administrator. Unblock requests for blocks marked with {{checkuserblock}} will be reviewed by a checkuser.

Making repeated unblocking requests without appropriate reasons may be considered abusive. As noted above, users who have abused or are likely to abuse the ability to edit their own user talk page and/or send e-mail in this or any other way may have either or both of these privileges revoked, which also prevents these privileges from being used for unblocking requests.

Any comments now? Silence is acceptance! ;-) —LX (talk, contribs) 21:58, 13 January 2016 (UTC)
 Support Looks sensible to me. --Herby talk thyme 10:28, 20 January 2016 (UTC)
 Support Idem. Yann (talk) 10:40, 20 January 2016 (UTC)
Can we get a synonym for "technically misapplied"? I assume you are referring to accidental blocks or blocks that were placed with the wrong settings, but the phrase can imply "getting off on a technicality". – Philosopher Let us reason together. 00:14, 21 January 2016 (UTC)
Your assumption is correct. How about "likely to be a mistake or an unintended side effect"? I'm open to other suggestions. —LX (talk, contribs) 00:35, 21 January 2016 (UTC)
 Support --Steinsplitter (talk) 17:17, 21 January 2016 (UTC)
Temporary  Oppose current wording. It should be more elaborate, explaining do's and don'ts under a heading "Instructions for blocked users". Jee 13:06, 22 January 2016 (UTC)
So it's better to have no wording at all? I'm sorry, but I firmly disagree. Instructions for blocked users should go in MediaWiki:Blockedtext, which they're far more likely to read. If necessary, that could link to something longer, which might be similar to en:Wikipedia:Guide to appealing blocks and en:Wikipedia:Appealing a block. This, however, not a howto but a policy; it should be concise. —LX (talk, contribs) 14:23, 22 January 2016 (UTC)
No; that's why I added "Temporary". We already have a sub-head "Instructions for administrators". So I think a matching sub-head is better. And "appeal" is not the only door in front of a blocked user. He can wait or take break if the block is for a small duration. He can leave if he wish. But he should not sock even for good things (like continue pending uploads). This is applicable even if he believes the block is inappropriate. He should not use talk page for other purposes than appeal. Those also need to be mentioned. Jee 14:45, 22 January 2016 (UTC)
Okay, so "temporary oppose" really means no objections to this being added for now, even if you think it should be expanded? —LX (talk, contribs) 15:11, 22 January 2016 (UTC)
Yup! :) Jee 15:13, 22 January 2016 (UTC)

Alrighty, I added the proposed wording, with a slight tweak to the "technically misapplied" point. Thanks to those of you who weighed in! —LX (talk, contribs) 18:59, 27 January 2016 (UTC)

Typo "MyLanuage" in "no open proxies" wikilink breaks link to MetaWiki

{{Edit request}}

In Commons:Blocking policy#Use: 

   * Open or anonymizing proxies are typically blocked upon detection in accordance with Wikimedia-wide policy. The normal duration of such blocks is one year.

should be: 

   * Open or anonymizing proxies are typically blocked upon detection in accordance with Wikimedia-wide policy. The normal duration of such blocks is one year.

80.221.159.67 18:46, 25 September 2016 (UTC)

✓ Done --jdx Re: 18:55, 25 September 2016 (UTC)

Proposal to amend blocking policy

Please see Commons:Village pump/Proposals#Proposal to amend blocking policy. --MichaelMaggs (talk) 14:07, 12 April 2017 (UTC)

Amendment for § After blocking

See Commons:Village pump/Proposals #After blocking. Incnis Mrsi (talk) 07:51, 12 August 2018 (UTC)

Proposal to remove interwiki links

In 2015 Lotje added several interwiki links (diff). Without digressing into technical details of sysop related processes, this potentially adds a layer of invalid complexity and potential block-related dispute of interpretation. Unless there are good reasons to keep these unqualified interwiki links, I propose to remove them on the basis that they are not suitable "definitions" of these terms for Wikimedia Commons, especially when those definitions may result in, or support, long or indefinite blocks. --Fæ (talk) 10:32, 5 April 2019 (UTC)

Agree that the “w:Wikipedia:Banning policy” link was inappropriate. Few (if any) users were ever explicitly banned from Commons (without all-Wikimedia ban), and anyway Commons currently has no banning policy. Incnis Mrsi (talk) 10:57, 5 April 2019 (UTC)
Thanks, per the diff also to be trimmed are:
Wikipedia:Harassment
Wikipedia:Sock puppetry
Though these are useful to examine, it would be better to include them as 'see also' material or explicitly qualify them to make it clear that administrators are not bound by the procedures described and the associated links to noticeboards and help pages are unlikely to be correct for incidents of harassment and sock puppetry on Commons. --Fæ (talk) 11:06, 5 April 2019 (UTC)
I support bringing the policy in line with our best current practices, and explaining how that differs from interwiki linked policies on English Wikipedia. However, once we iron out the language, COM:VPP is the way to go, as this policy can affect all users.   — Jeff G. ツ please ping or talk to me 12:08, 5 April 2019 (UTC)

@Steinsplitter: as the admin that protected the page from non-sysops, can you review the above and implement the changes, or remove protection so that I can make them for the community. Thanks --Fæ (talk) 10:13, 7 April 2019 (UTC)

The page is only semi-protected, you should be able to edit it. --Steinsplitter (talk) 10:37, 7 April 2019 (UTC)
Not used to this error type on edit saves. I had to attempt two saves for it to work, and the error message does not actually tell you that is what you are supposed to do, it should probably be worded more helpfully. Not sure if that system behaviour is the same for sysop accounts. --Fæ (talk) 13:07, 7 April 2019 (UTC)

Autoblock disabled when blocking for inappropriate username

I think autoblock should be disabled when the user is blocked for inappropriate username, because he/she should be able to sign out from his/her user account and continue editing as an IP address. Therefore, I propose the following change to the policy page:

  • Autoblocking of IP addresses used by the blocked user should typically be disabled when blocking bots and inappropriate usernames and but enabled in most other cases.

4nn1l2 (talk) 06:02, 25 April 2019 (UTC)

 Support --jdx Re: 08:56, 25 April 2019 (UTC)

There are usernames and other usernames. For users “Bantu Nation” and “UNESCO office” – yes, disable autoblocking. Not so for “4nn1l2 can't find his dick” and “Copyvio Flood on Abrasive Discs”. The sysop should execute an own judgement. Incnis Mrsi (talk) 14:03, 25 April 2019 (UTC)

Why do you think the word "typically" has been used? Most inappropriate usernames which get blocked are promotional. 4nn1l2 (talk) 21:19, 25 April 2019 (UTC)
Because of haste, perhaps? If the purpose of the block is compelling the user to use another username, then autoblocking of IP addresses used by the blocked user should be disabled. Incnis Mrsi (talk) 07:06, 26 April 2019 (UTC)
That's true and my proposal effectively says so. Most inappropriate usernames which get blocked are promotional. They get blocked to compel the user to use another username (or maybe continue contributing as an IP address). 4nn1l2 (talk) 07:18, 26 April 2019 (UTC)

I applied the change: Special:Diff/349037788. 4nn1l2 (talk) 23:13, 6 May 2019 (UTC)

@4nn1l2: what about "Autoblocking of IP addresses used by the blocked user should typically be enabled for users who were blocked for disruptive behavior. It should be disabled in most other cases, like blocking malfunctioning bots and usernames that don't follow the username policy." - Alexis Jazz ping plz 02:17, 10 May 2019 (UTC)
@Alexis Jazz: I agree with your wording. 4nn1l2 (talk) 01:12, 11 May 2019 (UTC)
No opposition after a week, so I applied your wording: Special:Diff/350833451. 4nn1l2 (talk) 12:20, 17 May 2019 (UTC)

Proposal to change wording for "unauthorized bot accounts"

Proposal

Current wording:

Unauthorized or non-responsive bot accounts. Bot accounts not authorized by the Commons community are not allowed to operate on Wikimedia Commons, and questionable bot-like editing that cannot be explained by the user should be blocked until discussion takes place. Bot proposals can be discussed at Commons:Bots or Commons:Village pump. Bots may not be operated on Commons without advance permission (which can be sought at Commons:Bots/Requests).

Proposed wording:

Unauthorized bot-like accounts and large scale automation. Disruptive large scale use of automation without a consensus or supporting discussion, including bot-like accounts without bot flags, or large scale changes using tools from main accounts or legitimate sock accounts, may be blocked until discussion takes place. Test runs, bot proposals and proposals for major automation projects can be discussed at Commons:Bots or Commons:Village pump.

This removes the implication that Bureaucrats or any other group needs to "authorize" all non-trivial automation, this is not the current Wikimedia Commons community norm for automation, and it is not a realistic expectation. In particular there is no need to seek pre-authorization for the use of standard tools, or custom automation that does the same job, like cat-a-lot, VFC, AWB, or F2C, so long as the changes being made are not disruptive, but part of the normal housekeeping or other helpful maintenance tasks that may or may not be completed using bot accounts (i.e. accounts with a Bureaucrat approved bot flag). The current wording routinely leads to confusion and delays for high value content projects, with users requesting bot flags for noncontroversial tasks as simple as an upload project or limited and monitored housekeeping tasks, such as recategorizing files for a project with only a few thousand files as its scope.

The new wording introduces the consideration of "disruption", which in practice is the only thing that matters when questions are raised about large scale automation. A good faith user running their own automation projects will always avoid having their account(s) blocked so long as they are prepared to stop the automation while discussion about potential disruption takes place.

Note that malfunctioning bot accounts are under a separate paragraph of BP, so this paragraph only needs to address accounts without bot flags.

Preliminary discussion of this proposal from last month is available at Commons:Bots/Work_requests/Archive_15#Bot_account_misuse,_revisiting_COM:BP. I am quite happy to reword the specific change proposed based on further feedback.

Notifications have been posted at COM:BN and COM:VP. --Fæ (talk) 11:55, 15 May 2019 (UTC)

 Support I also agree it makes sense not to distinguish between bots and tool use. A bot that does good is no worse than someone with cat-a-lot who does good and someone who does bad with VFC is no better than a bot that does bad. - Alexis Jazz ping plz 12:06, 15 May 2019 (UTC)
 Oppose There is a difference between blocking a bot-account and a main account that uses automatization tools. The threshold to block a bot-account can be very low (as suggested by the old wording). The same threshold cannot be applied to main accounts that use automatization tools (as sugessted by the new wording, even if they seem disruptive on first glance). A block history on a main account is a different thing than on a separate bot-account. I would be personally offended if my main account ever got blocked (for whatever resason). My bot account got blocked several times already, which I consider a natural part of the bot improvement process. --Schlurcher (talk) 07:29, 16 May 2019 (UTC)
@Schlurcher: Fair enough comment. As there will probably be very few votes on this, so it's more a collegiate consensus rather than a vote, could you recommend a smallish change in the wording that you would prefer? Thanks --Fæ (talk) 16:15, 17 May 2019 (UTC)
Hi, Fæ. I understand these as two different concepts. I rather would like to have two separate statements, i.e. both:
  • Unauthorized or non-responsive bot accounts. Bot accounts not authorized by the Commons community are not allowed to operate on Wikimedia Commons, and questionable bot-like editing that cannot be explained by the user should be blocked until discussion takes place. Bot proposals can be discussed at Commons:Bots or Commons:Village pump. Bots may not be operated on Commons without advance permission (which can be sought at Commons:Bots/Requests).
  • Unauthorized bot-like accounts edits and large scale automation. Disruptive large scale use of automation without a consensus or supporting discussion, including bot-like accounts without bot flags, or large scale changes using tools from main accounts or legitimate sock accounts, may be blocked until discussion takes place. Test runs, bot proposals and proposals for Major automation projects can be discussed at Commons:Bots or Commons:Village pump.
I'm however not convinced that we need the second bullet at all. Disruptive edits (independent if large scale or not) should fall in the category of vandalism and that is already covered. It could be a sub-bullet of that "Disruptive large scale use of automation" --Schlurcher (talk) 07:45, 22 May 2019 (UTC)
Needs improvement. With all due respect to Fæ, “disruptive” edits should meet block before growing to become “large-scale”. Yes, I’d like to see administration acting like police. Incnis Mrsi (talk) 17:19, 18 May 2019 (UTC)
What is intended is to fill the gap. We do not block accounts from making annoying but not breaking changes, but if those annoying changes are apparently automated and done at scale, that is systemic disruption and needs to be explicitly blockable without the admin asking for a consensus to get on with it. If you can think of a short and better way of expressing that, please propose some words. Thanks --Fæ (talk) 18:22, 18 May 2019 (UTC)
“Disruptive use of automation at high rate without a consensus, or automated edits persisting after complaints…” Incnis Mrsi (talk) 19:06, 18 May 2019 (UTC)
Thanks, I'll look at integrating it when I'm back from travelling in a couple of days. --Fæ (talk) 19:38, 18 May 2019 (UTC)
Yeah, I could get on board with this. If you are doing a large amount of semi-automated edits, when you see a message on your talk page, you should immediately stop and make sure it isn't someone raising issue with your edits, not carry on for another half our and then see what the message was after 5,000 additional unhelpful edits. In this situation I can see that it would be reasonable to issue a block if the user is non-responsive. But I do still think we should have a general expectation of at least attempted communication prior to blocking, which isn't necessarily the same expectation when it comes to bots. GMGtalk 17:16, 27 May 2019 (UTC)

Legal threats (again)

In Commons talk:Blocking policy/Archive 1#Legal threats, my proposal to make legal threats grounds for blocking was rejected. Nevertheless, I see legal threats being used as a rationale for blocking users, e.g. here, here, here, here, here and here. Is it time to reconsider the previous community decision? —LX (talk, contribs) 14:30, 28 July 2019 (UTC)

Legal threats are already a grounds for blocking. Blocks are for "behaviour that has the potential to damage Commons or disrupt its collegial atmosphere"--the threat of litigation, especially as it is commonly used (as intimidation/bullying), is inherently a disruption to a collegial atmosphere. The explicitly bulleted reasons in the "Use" section are merely "The more common [reasons]"; it is not, and not meant to be, an exhaustive list. Эlcobbola talk 14:41, 28 July 2019 (UTC)
It would also behoove us to document the situations where opinions differ, so as to avoid confusion, arbitrary decisions, and criticism on the basis that admin decisions do appear arbitrary. As it stands, I see comments from experienced users saying that blocks for legal threats have no basis in policy on Commons just about as frequently as I see other experienced users proclaiming with equal conviction that legal threats are grounds for blocking. Likewise, I'm having a hard time reconciling your definitive assertion with the diverging opinions in Commons talk:Blocking policy/Archive 1#Legal threats, Commons:Village pump/Proposals/Archive/2011/09#Legal threats and Commons:Village pump/Proposals/Archive/2015/08#Legal threats and blocking. But since it does appear to be de facto practice, I think it should be documented in the policy. —LX (talk, contribs) 18:49, 28 July 2019 (UTC)
Other discussions are OTHERSTUFF. My assertion need not reconcile to the comments of others, it needs to reconcile to policy and, indeed, I've cited current policy as the basis; I don't see that you've actually offered a response to my points, and threads from 2011, 2012 and 2015 certainly don't either. If there is a policy-based argument that blocks for legal threats have no basis, then present it. Further, explicit addition is an unnecessary acquiescence to wiki-lawyering (i.e., it gives credence to the notion that an issue must be explicitly listed); admins should use judgment when blocking based on thoughtful consideration of prevention of disruption, whatever its form, not blind adherence to a list. Эlcobbola talk 21:33, 28 July 2019 (UTC)

"Oversight blocks and bans"

I proposed to remove all mentions of the term "ban" in this section, as 1. there's no ban policy in Commons and 2. this section does not say anything different between block and "ban".--GZWDer (talk) 15:31, 26 November 2019 (UTC)

As this is not controversial based on past discussions and existing policy, I have boldly changed the wording see diff. --Fæ (talk) 15:37, 26 November 2019 (UTC)

Request for comment: Partial block

A request for comment relative to the blocking policy has been opened, please see Commons:Requests for comment/Partial blocks. ~riley (talk) 01:19, 10 December 2019 (UTC)

Rewording the CheckUser block part

On 23:19, 25 March 2020, one of our admins undid a CheckUser block, one of his rationale being that Unblock requests for blocks marked with {{Checkuserblock}} will be reviewed by a checkuser. says that it is not required de jure for a CheckUser block to be reviewed by a checkuser, because of the word will. Despite this however, it seems de facto that CheckUser blocks should only be undone by checkusers themselves. I think we should prevent this from happening again, therefore I propose to change "will" to "must". pandakekok9 03:13, 26 March 2020 (UTC)

To be honest, I'm somehow confused. The reason why CheckUsers should review CU blocks is that they have access to the same level of data their fellow CheckUsers do, and so they can decide whether the CU block was justified or not. But there are two unblock requests for CU blocks: 1) the blocked user claims that they have not created a sock account, and that there has been a mistake in the CU process. 2) The blocked user accepts that they had one or more socks/alternative accounts (they accept the result of CheckUser), but they request unblock because they think the block itself is unjustified, even if they have socked. I think there is a big difference between these two: the first one must be reviewed by a CheckUser; it's actually double checking the first CheckUser's action. The second one, however, is a rather administrative decision. In the first case, the CheckUser action is controversial. In the second case, the administrative action, the block, is challenged. The CheckUser tool can reveal many things (it's not only limited to IPs), but it doesn't say if you need to block a user because they have created one or more sockpuppets or not. It's like when a CheckUser checks two or more accounts, confirms that they are sockpuppets, but doesn't block them (e.g. asks administrators to take action). The blocking administrator doesn't necessarily have access to CheckUser data, they just decide if the use of alternative account(s) was in line with the policy or not. Ahmadtalk 23:06, 26 March 2020 (UTC)
  • As above, a CU block is supposed to be reviewed by a CU because it may be based on non-public information that others do not have access to. My procedural concern in setting a precedent is when this become construed as not "a block" only one made by someone with additional access to information, but rather when it becomes effectively a super block, one made based on publicly disclosed information, only rendered a CU block because the action was performed by a CU.
You cannot unblock this user. You cannot comment on an unblock request. This is not subject to any consensus or community review, and if you do try to discuss it we will block you too. We feel no need to explain our actions. Don't bother to ping us. We also claim exception to the deletion policy, the protection policy, and the ability to enact a banning policy ex nihilo.
That effectively renders the CU team as Commons:Arbitration Committee, a concept that has been repeatedly rejected by the community. GMGtalk 12:31, 27 March 2020 (UTC)
  • I echo what Ahmad252 and GreenMeansGo told. CUs should be held accountable. The policy should be amended to cover the second scenario explained by Ahmad252. 4nn1l2 (talk) 12:40, 27 March 2020 (UTC)
  • No, that doesn't quite work. Consider a scenario. I want to upload in-scope pictures of my home town, but I don't want to out myself. So I register an alt for privacy reasons. Suspicions are raised somehow and a CU is performed. They connect my two accounts, but what they also do is realize that I've developed a nasty meth addiction on the weekends and taken to vandalizing and harassing users as an IP. CUs can publicly connect the two accounts, but they can't connect me publicly with the IP for privacy reasons, which is the actual problem where I am violating policy. They can't confront me publicly even for me to confirm or deny.
What they can do however is indicate unequivocally (preferably in the block log) that there is additional pertinent non-public information. If the community doubts this, then they can go to the Ombudsman who can review the information and confirm. If they will not confirm this, then it is not a CU block in a meaningful sense. It's just a block done by a user who happens to be a checkuser, based on public information. GMGtalk 13:10, 27 March 2020 (UTC)
@GreenMeansGo: In this scenario, CUs can at least inform the community that some IPs are also involved, without mentioning the actual IP numbers. Communication in needed. 4nn1l2 (talk) 18:04, 27 March 2020 (UTC)
And no reason to think it will be forthcoming that I can see. GMGtalk 18:17, 27 March 2020 (UTC)
@4nn1l2: Communication is always good but in some ways the hands of the CU are tied by the CheckUser policy. I suspect it would need to be clarified because otherwise the failsafe will operate (if in doubt, don’t reveal). -Green Giant (talk) 18:03, 7 April 2020 (UTC)
I expect that most people who have been active with OTRS have dealt with the issue of community relations with regard to non-public information. Maybe I'm in the minority, but I don't really see that it's that difficult to maintain open good-faith communication with the community while respecting privileged information. Half of the problem with all of this has been an utter lack of communication. That is not merely a standard expected of CUs and administrators, but a standard expected of all users. GMGtalk 13:43, 8 April 2020 (UTC)
I agree with Jee. If we are going to update the wording (which is needed), we should have a full section so any ambiguities are removed. The Oversight section looks like a good example. —-Green Giant (talk) 17:52, 7 April 2020 (UTC)
  1. Policy needs clarification to be absoutely clear who may review a checkuser block.
  2. To remove complete ambiguity, a full section should be written.
  3. We want to clarify policy, but we have concerns about giving checkusers absolute power to review their blocks, and think there should be exceptions.
  4. A process for direct review and scrutiny needs to be developed.
  • Issues #1 and #2 are easy fixes. I have proposed a section below, please comment and wordsmith. For #3, I think it is dangerous territory to explore exceptions in which case a non-checkuser may review a checkuser block. It puts an administrator in a tight situation where they may easily find themselves operating in the dark while they think they know the whole story. Regardless of what the scenario is, we need to remove complete ambiguity - this will not be accomplished by saying if x is y, a non-checkuser can unblock. X and y are grey variables and we will find ourselves in this situation again where an administrator is called to the stand and questioned in front of the community. We cannot afford to lose more administrators whether by walking or removal of permissions. The root cause of why you are all proposing exceptions is because you do not trust in the system due to a lack of #4. I think we need to focus on #1 and #2 right now, recognize that #3 & 4 is an issue and separately tackle them. Let's not blur policy and put administrators at risk of losing their permissions rather than directly address a systematic issue of a lack of policy (we don't even have an SPI policy) and scrutiny. Those are two big issues that will take a lot of work. For now, I can only refer to Green Giant's suggestion to encourage more people to stand as candidates. It sounds to me like some fresh blood is needed to put some trust back in the system. ~riley (talk) 19:39, 8 April 2020 (UTC)
Proposed section

Checkuser blocks

Checkusers may need to block an editor, on the basis of technical checkuser evidence, due to disruption caused by abuse of multiple accounts or IP addresses. These blocks must be marked as a {{Checkuserblock}} in the block log summary and must not be reversed by non-checkusers.

As checkuser data cannot be shared publicly and a checkuser block may involve other pertinent non-public information, an unblock appeal for a {{Checkuserblock}} must only be reviewed by a checkuser. A reversal of a check user block by an administrator may result in the removal of permissions.

  • Well, there is still the issue of oversight. Any way you cut it, Commons doesn't have an arbitration committee and doesn't want one. m:OMB has a limited mandate, and at some point runs into the en:FISC paradox: you can't enforce oversight regarding non-public information when you require access to that non-public information in order to enforce oversight. At the same time, Commons doesn't have an ARBCOM and doesn't want one, but without some oversight mechanism, the functionary team is effectively an ARBCOM, empowered to issue sanctions which have no appeals process, with no policy-based standard compelling communication with the community, and not in any way subject to community consensus.
There is the possibility of forming a local OMB: a panel of community members who are temporarily granted CU access only in cases where the community requests review of CU actions. But that probably runs straight into the issue that comes up any time someone discusses unbundling of advanced permissions: if you could be elected to a local OMB, then you should just run for CU and skip the middle man all together.
I would much rather that this had all been handled a great deal better, with at least the appearance of consideration for the community, and this wasn't a problem we needed to talk about solving. GMGtalk 11:15, 9 April 2020 (UTC)
The local OMB sounds like a good idea to me. Just because you could be elected to a local OMB doesn't mean you automatically qualify for CU permanently. Quite the opposite I think. A local OMB watches the CUs if the latter can't watch themselves. If the local OMB becomes a CU and the issue is about CU abuse which happened during the time the local OMB is CU, there would be conflict of interest. A CU shouldn't be allowed to be a local OMB until 3 years have passed since they are no longer a CU. pandakekok9 05:56, 10 April 2020 (UTC)
@GreenMeansGo and Pandakekok9: This is great discussion and I like how you guys are going outside of the box here in trying to address this problem. I seriously like where this idea is going but I also have some concerns with how it could be made an effective system. That said.. Addressing the concern of scrutiny and a process for direct review is not going to be accomplished by this discussion; I fully agree it does need to be addressed though. That will take a lot of discussion, consensus building and a community RfC to figure out and implement. Can we steer this discussion back on track to improving the blocking policy? If we can keep this discussion focused on improving the policy, and building consensus here on the talk page, I think we can avoid a long-drawn out RfC for this policy. Where do you guys think we can take the discussion of building a direct review/scrutiny process? I think this needs a place of it's own where we can really dig into it. In the meantime, do you have any comment on the above-proposed revision? ~riley (talk) 19:36, 11 April 2020 (UTC)
Since I initiated this discussion to clarify the CU blocks and prevent future unfortunate incidents like an admin reversing a CheckUser block due to literally interpreting "may" as "may", I have no problems with your version, other than the possibility of abuse. But those issues should indeed be solved through another discussion first. I agree we have to address issues 1 and 2 immediately. Thank you for helping us improve this policy. pandakekok9 01:44, 12 April 2020 (UTC)
  •  Comment I think this proposal is a good attempt to make clarity on the CU Blocks. This will help the CUs to stand strong and to save further admins from running into the troubles as ~riley stated above. I understand the concerns raised by GreenMeansGo above and Natuur12 in some other places. I remember such concerns were there while we were setting up the "Oversight blocks" part too. Oversighters acted without any formal prior community approval first, and then repeated. Then one of the OS stepped in to initiate a discussion. Still there were a lot of resistance; but we ended up in a policy update. Now we need one for the "CU Blocks" too. It is better to have a policy to avoid the vagueness which will help the CU/OV teams to act firmly with confidence in a timely manner even if there may be some lack of transparency.Jee 05:37, 11 April 2020 (UTC)
  • I have some concerns regarding this. It's quite frequent for the functionary team to consult other members of the team before making a decision. That's why we have mailing lists, IRC channels, OTRS queues and private wikis for them (to my knowledge, there is a CheckUser wiki, and there are also wikis for ArbCom members). Because of this, sometimes the entire CU/OS team members decide to take an action based on the private data. There should be something that can review such blocks. In this recent case, an important factor was a misunderstanding where a comment was interpreted as a death threat (I used to think of it that way as well), and there are apparently other misunderstandings as well (e.g. death threats toward the CU team while there is apparently no evidence indicating that). There are two key differences between the English Wikipedia and Commons, in terms of CU blocks: 1) the English Wikipedia has an ArbCom; and 2) there are 43 CheckUsers on the English Wikipedia, while there are only 5 here on Commons. I'm not being specific about the current CU team. I support having more CheckUsers, but regardless of that, I think we need something that can review CU/OS blocks. Maybe, in special cases, administrators can consult at least one CheckUser and ask if there has been any significant private evidence (e.g. other socks) other than what that has already been revealed, and if there isn't such evidence, review the unblock request themselves (read more about this at my comment above). Maybe we need the "local OMB" as explained above, or maybe something totally different. My point is that we should have some means to review CU blocks. That being said, I think it doesn't actually make much difference if we change the "will" to "must" in the policy. I agree that, based on the current policy, CU blocks should always be reviewed by CheckUsers. Ahmadtalk 01:08, 12 April 2020 (UTC)
    • @Ahmad252: Did you read the above-proposed text? What are your thoughts on it? It is a considerable change as opposed to just changing "will" to must". I quite agree that we need a process in place for direct review and also need additional CUs. Where do you think is the best place to discuss this further? COM:VP? ~riley (talk) 07:29, 12 April 2020 (UTC)
      @~riley: Yes, and I support it, as it clarifies things. I think the spirit of the current policy is to forbid non-CUs from reviewing CU blocks. Therefore, I think it's a good idea to replace the old wording with this section to avoid possible confusion, at least for now. Thanks for proposing it, works for me.
      The best place would be the village pump, I guess. Policy talk pages would not be enough, and the administrators' noticeboard isn't that relevant. Ahmadtalk 13:26, 12 April 2020 (UTC)
Since nobody seems to oppose riley's proposal here, I will be taking this to VP/P. pandakekok9 06:50, 18 April 2020 (UTC)
Proposed at Commons:Village_pump/Proposals#Proposal:_Modify_block_policy. ~riley (talk) 07:18, 18 April 2020 (UTC)

Author of my own work, is me.

But, unfortunately, the name of author is added Christopher Duet. Please add author as PRADEEP KUMAR YADAV who is me, holding all rights of my Photo that I uploaded here. Waiting for your reply. Regards Pradeep Kumar Yadav PRADEEP KUMAR YADAV (talk) 06:13, 30 November 2020 (UTC)

@Prdp777: Please clarify. The "Author" in the EXIF metadata of all three of your uploads is "Christopher Quet". Is that the photographer? How did you acquire copyright?   — Jeff G. ツ please ping or talk to me 12:21, 30 November 2020 (UTC)

Disruptive editing

I think this part should be separated from vandalism so that it's clearer. The English Wikipedia made this clear on one of their guidelines that not all disruptive editing is vandalism. pandakekok9 11:40, 17 December 2020 (UTC)

Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons_talk:Blocking_policy/Archive_1&oldid=684302431"