| Revision as of 22:10, 8 March 2010 editChildofMidnight (talk | contribs)43,041 edits →Civility blocks: reply← Previous edit | Latest revision as of 19:06, 1 November 2024 edit undoYamla (talk | contribs)Autopatrolled, Checkusers, Administrators147,843 editsm Reverted edits by 103.120.71.5 (talk) to last version by Annh07Tag: Rollback | ||
| Line 1: | Line 1: | ||
| {{shortcut|WT:BP|WT:BLOCK}} | |||
| {{Policy-talk}} | {{Policy-talk}} | ||
| {{Talk header|noarchive=yes|WT:BP|WT:BLOCK}} | |||
| {{talkpage}} | |||
| {{tmbox|type=content|text={{center|{{large|'''This is not the page to report problems to administrators<br/>or request blocks.'''}}}} | |||
| {| class="messagebox standard-talk" style="padding: 6px"> | |||
| |- | |||
| | colspan="2" style="font-size: 150%; line-height: 1.25em; text-align: center; height: 2em" | '''This is not the page to report problems to administrators<br/>or request blocks.''' | |||
| |- | |||
| | ] | |||
| | This page is for discussion of the ] itself. | |||
| This page is for discussion of the ] itself. | |||
| * Report incidents such as block evasion at ''']'''. | * Report incidents such as block evasion at ''']'''. | ||
| * Report violations of the ] at ''']'''. | * Report violations of the ] at ''']'''. | ||
| * Report active, persistent vandals at ''']'''. | * Report active, persistent vandals at ''']'''. | ||
| * Report violations of arbitration remedies at ''']'''. | |||
| |} | |||
| }} | |||
| {{WikiProject Policy}} | |||
| {{merged-from|Misplaced Pages:GlobalBlocking|18 October 2012}} | |||
| {{merged-from|Misplaced Pages:Block on demand|25 July 2016}} | |||
| {{archives|auto=short|search=yes|bot=MiszaBot II|age=4|units=months|index=/Archive index}} | |||
| {{User:MiszaBot/config | |||
| |archiveheader = {{talkarchivenav}} | |||
| |maxarchivesize = 250K | |||
| |counter = 24 | |||
| |minthreadsleft = 4 | |||
| |algo = old(60d) | |||
| |archive = Misplaced Pages talk:Blocking policy/Archive %(counter)d | |||
| }} | |||
| {{User:HBC Archive Indexerbot/OptIn | |||
| |target=/Archive index | |||
| |mask=/Archive <#> | |||
| |leading_zeros=0 | |||
| |indexhere=yes}} | |||
| == Block policy adding request == | |||
| {{archives}} | |||
| I request add this in policy: | |||
| == Discussion before unblocking not always needed == | |||
| Unblock request should be review by another administrator (not the blocker). | |||
| I hesitate to even post this because it seems lately every time I initiate one of these threads it goes off in some direction I never intended, but here we go anyway: Currently some of the blocking templates say that you should not lift a block without discussing with the blocking admin first, and this policy page says it is "strongly discouraged" to undo a block without discussion, I think this is somewhat out of step with current practice. In some cases, such as username-only blocks, there is no need whatsoever to discuss. If the user agrees to change their name, and that was the only reason for the block, there's nothing to discuss. In many other cases where the user demonstrates that they understand why they were blocked and are will avoid the problematic behavior in the future, making them sit there and remain blocked more or less for the sake of process seems unneeded. Of course in more complicated or controversial cases discussion is still needed, but I think we should soften the language up to indicate that it is not ''always'' necessary and in practice is often not done. Blocking templates based on checkuser evidence should retain the stipulation that you should discuss with a CU before lifting the block. ] (]) 21:34, 31 December 2009 (UTC) | |||
| :I've gone ahead and made a small change to the policy page , and will begin reviewing the templates. ] (]) 22:10, 2 January 2010 (UTC) | |||
| ::Sorry, I disagree and have undone this. The proposed language is inconsistent with longstanding policy and practice, and also with ], which says: "except for clear and obvious mistakes, administrative actions should not be reversed without good cause, careful thought and (if likely to be objected) usually some kind of courtesy discussion." As a matter of collegial courtesy, and also to prevent the circumvention of sanctions through admin-shopping, discussion should be obligatory in all but the most exceptional circumstances. <small><span style="border:1px solid black;padding:1px;">]</span></small> 22:17, 2 January 2010 (UTC) | |||
| :::You got to at least concede the point about username-only blocks. If the username is the only reason for the block, and the user agrees to change it to something that does not violate policy, what is the point of having a discussion? It's process for the sake of process in such a case. ] (]) 22:23, 2 January 2010 (UTC) | |||
| ::::Yes, I don't oppose a clarification for this particular case. <small><span style="border:1px solid black;padding:1px;">]</span></small> 22:29, 2 January 2010 (UTC) | |||
| It may help for the unjust administrator to make malice block and block the appear. ] (]) 07:04, 27 June 2024 (UTC) | |||
| I think the all to often failure to consult and gain agreement with the blocking admin and failing that to seek consensus for the unblock is one our more significant problems. In situations where someone has clearly made a good faith error, or when the situation has significantly changed I agree that admins should just be able to unblock(ie a user retracts a legal threat, or requests a rename to something more appropriate). What I don't think should be allowed is one admin interpreting policy differently and then just undoing another admins block. I think we can loosen up the wording regarding unambiguous errors and changed circumstances while making more clear the prohibition against undoing a block merely because you disagree with it. The requirement of communication with the blocking admin or the gaining of a larger consensus is particularly important when the admin who wishes to unblock is not in possession of all of the facts. ]<small> <sup>(Need help? ])</sup></small> 22:42, 2 January 2010 (UTC) | |||
| :It's already there: "]" This is the policy on the English Misplaced Pages; the Chinese Misplaced Pages may have different rules. ] (]) 07:26, 27 June 2024 (UTC) | |||
| :Entirely agreed. <small><span style="border:1px solid black;padding:1px;">]</span></small> 23:30, 2 January 2010 (UTC) | |||
| == PBLOCK community consensus == | |||
| ==Propose new section for WP:INDEF== | |||
| ''Partial blocks may be used at the discretion of any administrator in accord with the rest of the blocking policy, or community consensus.'' | |||
| I would like to propose a new section for INDEF blocked Users, the proposed name is WP:Parole. The goal? To offer a system similar to the common law Parole system where indef blocked Users e.g Users that cannot edit there talk page can have minimal privileges to prove wether or not they can be 'reintroduced' into the wikipeida community. Good idea, bad idea or something in the middle? P.S I may not be online untill tomorrow so if this becomes a talking point please be patient if you expect a reply from me. ] (]) 17:29, 22 January 2010 (UTC) | |||
| :I take it this discussion has failed to get of the ground by the looks of things. ] (]) 14:12, 23 January 2010 (UTC) | |||
| ::] and ] exist as essays, there's the unblock request template and the {{tl|2ndchance}} template mentioned in the block review section, and, when the user cannot edit their talk page, they also have the option of emailing the blocking admin, another admin, or Arbcom. I don't really see what else you can offer. -- ] <sup>]</sup> 16:25, 23 January 2010 (UTC) | |||
| :No User:zzuuzz there is not. I guess you are right. ] (]) 11:20, 24 January 2010 (UTC) | |||
| What does this mean? Is it simply saying that a community discussion can result in a PBLOCK, or is something further intended? If the latter, I'd like to amend the sentence to ''Partial blocks may be imposed at the discretion...blocking policy, or may be imposed by community consensus.'' ] (]) 13:21, 9 July 2024 (UTC) | |||
| == essay == | |||
| :I've always understood it to mean that partial blocks may be placed in any way that a full block can be - i.e. in circumstances articulated in the blocking policy or in any other circumstances if there is a community consensus to do so. That would mean your proposed change would not alter the meaning but may clarify it. ] (]) 13:27, 9 July 2024 (UTC) | |||
| Just knocked together an essay about a certain type of unblock request. Any feedback appreciated. See ]. ] (]) 21:25, 31 January 2010 (UTC) | |||
| ::When partial blocks were the new hotness there was much fear of the unknown which got hashed out at ]. One of the questions was "Should partial blocks be limited to community consensus only?" That got voted down nearly unanimously, and the "discretion of any administrator" language came out of that RFC close. ] ] 14:40, 9 July 2024 (UTC) | |||
| :::PS, I can't think of any reason a discussion at ] or ] couldn't end with "There is broad consensus by the community to ban User:Foo from Some Namespace (or from some specific list of articles)". The community passes bans like that all the time. Bans state the will of the community. Blocks are just a way to technical way to enforce a ban. If the community banned somebody from (for example) a namespace and that user violated that ban, I suppose an admin could then impose the corresponding pblock to enforce the ban, but I think it's more likely they would just block the user completely; that's usually what happens when users disregard community-imposed restrictions. ] ] 14:46, 9 July 2024 (UTC) | |||
| ::::I don't see anything needing changing; admins can make unilateral partial blocks (e.g. in cases of edit warring) or at the close of a discussion where consensus is achieved (e.g. an article subject who can't be neutral on their article). ] (]) 22:46, 9 July 2024 (UTC) | |||
| == |
== Unblocks of a global block == | ||
| Reading the most recent ], do we feel like current blocking policy covers the situations where we would unblock someone on enwiki who is blocked globally or do we need to hash out new language for it? I genuinely don't know how I would handle such a request which maybe reflects that this isn't the normal area I work or maybe reflects something that needs clarifying. Best, ] (]) 16:13, 6 August 2024 (UTC) | |||
| I've noticed that there is a page at ] that allows you to quickly block users, but there is no ] page for quickly unblocking users. ] (]) 05:10, 4 March 2010 (UTC) | |||
| :Yeah, I saw that. To be honest, I'm hard pressed to think of a situation where we'd want to locally unblock somebody who is globally blocked. Accounts don't get globally blocked without a good reason. ] ] 16:23, 6 August 2024 (UTC) | |||
| == Civility blocks == | |||
| ::Given how new global blocking is, I'm not sure I have a sense of what people will get globally blocked for and thus not sure how often enwiki might reach a different conclusion about it. Best, ] (]) 16:34, 6 August 2024 (UTC) | |||
| :::One thing I am sure about is that having two different features named "global block" and "global lock" is guaranteed to create confusion. ] ] 16:38, 6 August 2024 (UTC) | |||
| ::::There is a plan to merge global locking into global blocking (though the name may still remain on-wiki) at {{phab|T373388}}. Not planned for the short term though. ] <sup>'']'' | '']''</sup> 17:32, 15 September 2024 (UTC) | |||
| :::One thing to note is that global blocking for accounts was developed so that there would be a way to prevent ] from editing on all wikis. If you lock a temporary account it just allows the user to get a new temporary account on their next edit. ] <sup>'']'' | '']''</sup> 17:34, 15 September 2024 (UTC) | |||
| :Of course not for en.wp at this time, but I think about cases like Malnadach and Slowking as perhaps illustrative. There may be less difficult cases also, perhaps global blocks will come first for VOAs or other not-difficult cases instead of locks and they'll be able to appeal on particular projects. ]] (]) 17:10, 6 August 2024 (UTC) | |||
| :I just want to mention that we already locally unblock global IP blocks with existing policy. ], and admittedly has a different flavour. Personally I think we should cross whatever bridge when it happens. And it should by default go in front of the community on a noticeboard (do we need to actually write that? I don't know). The only thing we shouldn't be doing (and I don't know how relevant that is here) is to undo an office action, but I think that's probably adequately documented under the office policy. -- ] <sup>]</sup> 17:24, 6 August 2024 (UTC) | |||
| ::I wonder what should happen with the "request glock" feature of ]? The SPI templates support flags for this, and User:GeneralNotability/spihelper.js (which I guess is orphaned at this point) has functionality to make the requests on meta. Should we switch that over to using gblock instead of glock, or expose both options? ] ] 17:46, 6 August 2024 (UTC) | |||
| :::Or maybe ]! ] ] 17:48, 6 August 2024 (UTC) | |||
| :::We will need to consider this for temporary accounts, as global blocks is the only method to prevent them editing cross-wiki (global locks don't work as I've mentioned above). ] <sup>'']'' | '']''</sup> 17:35, 15 September 2024 (UTC) | |||
| ::I generally agree with Zzuuzz that this should be handled on a case by case basis. However I would say that rather than {{tpq|by default go in front of the community on a noticeboard}} that local unblocks should only happen as a result of a consensus at a community noticeboard (I don't have a strong feeling about which board), and I do think it worth explicitly saying this. When there have been enough of both global blocks and local appeals of global blocks that we have a reasonable feel about why they get applied, what grounds people appeal them on and what the response to the appeals is, we can amend the policy to reflect what is and is not controversial in practice. To that end it might (or might not) be worth explicitly marking it as a temporary policy that will only apply to the first say 10 appeals with a mandatory discussion to keep, remove or amend at that point (such a discussion need not be more heavyweight than a "This seems to be working well, we'll mark it as permanent unless anybody objects in the next week" or "in practice these are uncontroversial, does anyone object to just replacing the policy with a note saying whether to accept, decline or discuss is an individual admin's discretion?"). ] (]) 19:56, 6 August 2024 (UTC) | |||
| :::Here's the thing. As Roy mentions above, global blocks are different than global locks. So I agree with what @] and @] are saying about global locks - they need either community input or ArbCom concurrance. Global blocks are a whole different new thing and my gut tells me they should be handled more like a normal unblock - given that the user might have done nothing wrong on enwiki before being globally blocked even - than an unlock where sometimes they need community input but normally not. Best, ] (]) 20:37, 6 August 2024 (UTC) | |||
| ::::If it turns out some or all local appeals ''are'' uncontroversial then we can remove the consensus required provision when we know that, but until we do know who is getting blocked, who is appealing and what the community attitude to those appeals is, I'm not confident that individual admins will know enough to know what is and isn't going to be controversial, what is a reasonable grounds for appeal and what isn't. If some appeals are uncontroversial then consensus to unblock will develop quickly (I'm not proposing a quorum, minimum discussion length or anything like that) and nobody loses. ] (]) 20:50, 6 August 2024 (UTC) | |||
| :::::I think if we start with the highest cost option - everything must be community reviewed - it's unlikely we would ever go back to a lower cost option. I appreciate the work Izno and Roy are doing below in getting this onwiki so we don't have to talk hypothetically. Best, ] (]) 00:49, 7 August 2024 (UTC) | |||
| :I put a request in the ear of a steward to move onwiki the discussion stewards are having about global blocks, so perhaps we won't have to just "come up with something" without considering the dimensions they'll be thinking about. :) That feels like the primary blocker to thinking about the problem. ] (]) 22:57, 6 August 2024 (UTC) | |||
| ::I've also been interfacing with some steward ear today. From what I can tell, they're as unsure about all this as we are. ] ] 00:38, 7 August 2024 (UTC) | |||
| == Blocking IP addresses == | |||
| The policy currently states that, under the heading of "disruption", "A user may be blocked when his or her conduct severely ]; that is, when his or her conduct is inconsistent with a ] and interferes with the process of editors working together harmoniously to create an encyclopedia."... i.e. users may be blocked for "persistent ];" | |||
| I have come across an indefinite rangeblock which has not been cancelled although 16 years old. The range is 66.197.128.0/17. Can it be removed? ] (]) 16:07, 21 September 2024 (UTC) | |||
| I propose that this be amended, by adding at the end of that list (after "persistently violating policies or guidelines") | |||
| :That IP address belongs to Netflix. Nobody should be editing from there. I'm not seeing any reason to lift the block, would you mind elaborating why you think this is necessary? --] (]) 16:10, 21 September 2024 (UTC) | |||
| <blockquote> | |||
| ::The IP is unable to reply, as it was used by ] to evade their ban. ] (]) 16:24, 21 September 2024 (UTC) | |||
| Established users should not normally be blocked for mere civility by an administrator acting alone; such decisions are too frequently highly contentious. Instead blocks which may be merited for ''patterns'' of incivility amounting to disruption should be proposed at an appropriate ] venue. It will generally be expected that prior methods of dispute resolution such as ] and ] will have been employed before the community is willing to support such a block. | |||
| == "]" listed at ] == | |||
| </blockquote> | |||
| ] | |||
| The redirect <span class="plainlinks"></span> has been listed at ] to determine whether its use and function meets the ]. Readers of this page are welcome to comment on this redirect at '''{{slink|Misplaced Pages:Redirects for discussion/Log/2024 October 12#Blocking policy}}''' until a consensus is reached. <!-- Template:RFDNote --> <span style=white-space:nowrap;>] <span style="background-color:#e6e6fa;padding:2px 5px;border-radius:5px;font-family:Arial black">]</span></span> 20:38, 12 October 2024 (UTC) | |||
| Related policies might not also need amending, if this is agreed. (One of the issues with civility enforcement is the grey line between ] and ]; merging might possibly be helpful.) | |||
| ] <sup>]</sup> 22:08, 7 March 2010 (UTC) | |||
| :I don't agree. In practice, such blocks are only contentious when applied to the relatively few vested contributors who are habitually incivil. We ought not to enshrine in policy this systemic failure of our community to deal with disruption. Compare also ]: "Strong or even exceptional contributions to the encyclopedia do not excuse repeated violations of basic policy, not even from highly experienced, knowledgeable editors who produce quality content." <small><span style="border:1px solid black;padding:1px;">]</span></small> 22:14, 7 March 2010 (UTC) | |||
| ::Well that's why I said "Established users" - it's here that problems seem to arise when such blocks aren't discussed beforehand. (Though arbitrariness in relation to civility enforcement seems a more general problem, it's only established users who have the clout and determination to raise a stink.) In any case, these problems come up often enough that any suggestions for improvement should be worth discussing. ] <sup>]</sup> 22:18, 7 March 2010 (UTC) | |||
| ::I agree with ]. That a few problem editors are teflon-coated and can get away with wanton abuse of anyone they dislike, is no reason to do away with the few tools we have to prevent descending into complete anarchy. ] (]) 22:23, 7 March 2010 (UTC) | |||
| :::I fail to understand how requiring prior discussion is such an issue. By definition, "persistent incivility amounting to disruption" is - for established users at least - a gradual process, and blocks for it typically have a "straw that broke the camel's back" character. This makes them contentious even when merited, which makes people not use them when they should, which allows people to get away with murder. More clearly laying out a WQA -> RFCU -> civility block discussion path should be helpful in combating civility, not merely in combating drama around civility blocks. Basically, civility enforcement is currently broken - do you have a better idea to fix it? ] <sup>]</sup> 22:35, 7 March 2010 (UTC) | |||
| ::::The fundamental problem is that there is no way to make a 24-hour block stick on a well-known editor with valuable contributions. If such an editor were to receive and serve even one civility block, their behavior would be extremely likely to change; because that does not happen, the behavior does not change. If the editor were taken to WQA or whatever, their supporters would overwhelm the stodgy "tolerated incivility will damage the project" messages, and people would start saying "let's close this now; waste of time; people shouldn't be so sensitive". With the current system, there will inevitably be an admin who reverses a civility block, and that provides those wanting to enforce reasonable civility with a herculean task. I suppose it's unachievable, but something like the following might help: agree on a new arrangement whereby an admin can issue a warning to a user (with no more than one warning per four-hour period to allow some cooling off); a second warning could then be given; on a third incident the user can be 24-hour blocked with a template that declares that no unblock can occur except by arbcom or a strong consensus at ANI. The warnings are live for three months, and are kept alive by another warning. An admin who abuses the warning system would be discussed at ANI. ] (]) 01:14, 8 March 2010 (UTC) | |||
| *'''Oppose''' the proposed change. Sandstein is exactly correct. We should not enshrine a few manifest failures of the community to deal with incivility into policy. ] (]) 01:31, 8 March 2010 (UTC) | |||
| *No, no, a thousand times no. We want people to go forth and use their reason. If someone makes a mistake, follow dispute resolution. Rules cannot be a substitute for dialogue. ] (]) 01:36, 8 March 2010 (UTC) | |||
| * No. This is absolutely not the right way to resolve the experienced but abusive user block/unblock blowups. ] (]) 02:15, 8 March 2010 (UTC) | |||
| *The current wording is adequate because the approach works with 99% of editors. Most people draw upon a limited reservoir of very blunt expressions when they mean to be rude. Usually a civility block has the effect of persuading the editor to join the majority of the community with civility. Exceptions exist where this approach fails because the skills and talents that yield really innovative rudeness are closely related to the skills and talents that yield superlative article writing. Many of Misplaced Pages's best content contributors are very polite people; those who choose not to be polite can generate types of incivility which are alternately maddening or witty (depending on one's perspective) and which are basically unblockable. The existence of exceptions is not sufficient reason to change policy; it is reason to exercise rational discretion and decide which problems are better to address through dispute resolution. <font face="Verdana">]</font><sup>'']''</sup> 04:02, 8 March 2010 (UTC) | |||
| Why do these responses make me feel like people didn't read beyond the first sentence of the proposed text? The problem is, as stated, that currently ''patterns'' of incivility are handled in an ad hoc way, which makes enforcement unpredictable and ineffective. If you don't like the prescription to use dispute resolution (to help establish a pattern) and pre-block community discussion (to establish if the pattern is agreed to amount to disruption), what do you suggest? The status quo is the best we can manage? ] <sup>]</sup> 09:27, 8 March 2010 (UTC) | |||
| :I did read the entire text of the proposal, and I just don't agree with it. Admins should have the unfettered power to block users for substantial incivility (whether particularly egregious individual instances or for patterns of incivility). Requiring "dispute resolution" in incivility cases is like telling a bullying victim to "discuss their differences" with a bully. There is nothing that currently prevents anyone from opening an AN/I thread about a particular user in cases of sustained incivility or any other pattern of disruptive behaviour. However, changing the language of the policy to ''require'' dispute resolution in cases of sustained incivility is will needlessly hamstrung admins dealing with disruptive behaviour. Established editor or not, '''editors involved in gross incivility should be blockable on sight'''. Yes, some of these blocks may be contentious, but this is better than giving "established editors" the appearance of a license to be incivil. ] (]) 15:01, 8 March 2010 (UTC) | |||
| :For my part, I also read the proposal, but the exact content isn't much an issue for me. The problem is what I read to be a ] approach to problem solving. I want administrators to be able to use their common sense and judgment in the field, and I want people to talk it out in cases where there is disagreement about an individual case. I don't want rules to be a substitute for dialogue in any case whatsoever. People ought to figure out what to do on a case-by-case basis with policy informing their decisions, not dictating them. | |||
| :But perhaps even more importantly, this is not a good way to draft policy. Policy should reflect what is already being done. Ad-hoc discussions by whoever might be watching this policy talk page is ''not'' the way to effect these kinds of prescriptive rules. --] (]) 19:03, 8 March 2010 (UTC) | |||
| ::Then what do you suggest? I was hoping at least for a little debate about the problem the proposal seeks to address. In my view, generally the civility blocks that stick on established users are those that have sufficient prior dispute resolution and established patterns of incivility to back them up, along with substantial community agreement. That suggests to me a policy conclusion to discourage bad practice. The wording was intended not to ''disable'' civility blocks by individual admins, but to discourage them; hence qualifiers like "normally" and hedging like "generally expected". This could be tweaked of course, but I think the principle is sound. Nobody is talking about giving a "license to be incivil" - quite the opposite. The repeated and public failure to make civility enforcement stick encourages people to think they can get away with murder (and generally they can). As I alluded to above, changing the blocking policy in this way ought to be accompanied by some attempt to make dispute resolution on civility clearer and more effective. Part of the reason it hasn't been is because in principle simple blocking is supposed to be enforcement enough; but since it rarely is enough in practice, something ought to change. ] <sup>]</sup> 19:15, 8 March 2010 (UTC) | |||
| ::::Actually, no. If anything, the language of the policy should be made ''stronger'' not weaker. Incivility is a big problem, particularly when coming from "established users" since such incivility, when left unchecked or when tolerated and de facto condoned, drives away other established users and newbies and in general makes productive discussion impossible. Chronic incivility by established users is a form of bullying and it should be treated as such. The real issue here is that in a few particularly bad cases a chronically incivil established users is protected by a group of admin friends who are willing to wheel-war and to lift the civility blocks whenever such blocks are imposed . However, the solution cannot and should not be to codify instances of such irresponsible admin behaviour into policy. On the contrary, the policy needs to be very clear that gross incivility, whether by newbies or by established users, is completely unacceptable and can lead to a block. Whenever a particular admin lifts a justified civility block for his/her pal, the admin should be reminded of the policy and, if necessary, the case should be referred to arbcom. Some admins will still continue the irresponsible practice of protecting their friends from civility blocks, but they should not be able to hide behind policy. Both the status quo and strengthening the policy language are better than the change that you propose. ] (]) 21:46, 8 March 2010 (UTC) | |||
| :::::Fine, propose something concrete that makes it "stronger". I'm not trying to make it weaker. ] <sup>]</sup> 22:05, 8 March 2010 (UTC) | |||
| :::We actually have begun resolving this by the simple if slow expedient of these people causing sufficient admin headache that they get taken to Arbcom for a permaban. | |||
| :::Reality is that apparently we both have sufficient disagreement in the community to stymie effective per-incident admin responses, and yet enough to generate successful arbcom cases against those same users. This seems like it should be wrong - but it's working out that way. | |||
| :::The problem with your approach is that (as I see it) it's attempting to insert an intermediate step which will *both* stymie per-incident admin responses and to some degree interfere with when we'd normally initiate an arbcom case. ] (]) 21:11, 8 March 2010 (UTC) | |||
| ::::The real problem is that highly uncivil, belligerent, and aggressive behavior by admins. The expression of frustrations by common editors isn't a big deal at all. They are human. It's the regular abuses of policies to after and antagonize that is corrosive. For example Sandstein just made a false accusation on an arbiration report page and Georgewilliamherbert regularly targets editors he doesn't care for, but when an admin calls a good faith editor a "drama lovign troll" he doesn't say or do anything about it. An environment that is so political and hypocritical will always engender resentment and frustration. But if the community chooses to encourage respect and colelgial cooperation instead, and weeds out the corrupt and dishonest hypocrisy then progress can be made. ] (]) 21:25, 8 March 2010 (UTC) | |||
| :::::With all due respect, you are one administrator "close" vote from being banned from Misplaced Pages for the next 12 months. No administrator has voted against either remedy. | |||
| :::::Your opinion has been noted repeatedly, but the community disagrees. | |||
| :::::] (]) 21:43, 8 March 2010 (UTC) | |||
| ::::::The community or the arbitration committee? | |||
| ::::::The hearing you cite was directed by Coren who I have called out in the past for his inappropriate bullying of a good faith editor. If he had any integrity he would have recused, and if the Arbcom body had even a shred of credibility they would have chosen someone else to direct the hearing. But that he actually led the Arbcon hearing speaks volumes about how political this place has become. | |||
| ::::::And you Georgewilliamherbert and others who use the civility policy to go after those they disagree with should not be tolerated. Your behavior is very damaging to the encyclopedia building effort and I hope you will consider changing your ways going forward. One need only review the panic among admins in their opposition to a deadminship procedure to understand that there needs to be a means of review available to the community. No credible enforcement body can be trusted to review itself, let alone the gaggle of politicians leading on this site. ] (]) 22:10, 8 March 2010 (UTC) | |||
Latest revision as of 19:06, 1 November 2024
 | The project page associated with this talk page is an official policy on Misplaced Pages. Policies have wide acceptance among editors and are considered a standard for all users to follow. Please review policy editing recommendations before making any substantive change to this page. Always remember to keep cool when editing, and don't panic. |
| This is the talk page for discussing improvements to the Blocking policy page. |
|
 | This is not the page to report problems to administrators or request blocks. This page is for discussion of the Misplaced Pages blocking policy itself.
|
 | See WP:PROPOSAL for Misplaced Pages's procedural policy on the creation of new guidelines and policies. See how to contribute to Misplaced Pages guidance for recommendations regarding the creation and updating of policy and guideline pages. |
 | The contents of the Misplaced Pages:GlobalBlocking page were merged into Misplaced Pages:Blocking policy on 18 October 2012. For the contribution history and old versions of the redirected page, please see its history; for the discussion at that location, see its talk page. |
| The contents of the Misplaced Pages:Block on demand page were merged into Misplaced Pages:Blocking policy on 25 July 2016. For the contribution history and old versions of the redirected page, please see its history; for the discussion at that location, see its talk page. |
 Archives |
|
Index 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 |
|
This page has archives. Sections older than 60 days may be automatically archived by Lowercase sigmabot III when more than 4 sections are present. |
Block policy adding request
I request add this in policy:
Unblock request should be review by another administrator (not the blocker).
It may help for the unjust administrator to make malice block and block the appear. Gongxiang01 (talk) 07:04, 27 June 2024 (UTC)
- It's already there: "Since the purpose of an unblock request is to obtain review from a third party, the blocking administrators should not decline unblock requests from users when they performed the block." This is the policy on the English Misplaced Pages; the Chinese Misplaced Pages may have different rules. Extraordinary Writ (talk) 07:26, 27 June 2024 (UTC)
PBLOCK community consensus
Partial blocks may be used at the discretion of any administrator in accord with the rest of the blocking policy, or community consensus.
What does this mean? Is it simply saying that a community discussion can result in a PBLOCK, or is something further intended? If the latter, I'd like to amend the sentence to Partial blocks may be imposed at the discretion...blocking policy, or may be imposed by community consensus. Nyttend (talk) 13:21, 9 July 2024 (UTC)
- I've always understood it to mean that partial blocks may be placed in any way that a full block can be - i.e. in circumstances articulated in the blocking policy or in any other circumstances if there is a community consensus to do so. That would mean your proposed change would not alter the meaning but may clarify it. Thryduulf (talk) 13:27, 9 July 2024 (UTC)
- When partial blocks were the new hotness there was much fear of the unknown which got hashed out at WP:PARBLOCK2019. One of the questions was "Should partial blocks be limited to community consensus only?" That got voted down nearly unanimously, and the "discretion of any administrator" language came out of that RFC close. RoySmith (talk) 14:40, 9 July 2024 (UTC)
- PS, I can't think of any reason a discussion at WP:AN or WP:ANI couldn't end with "There is broad consensus by the community to ban User:Foo from Some Namespace (or from some specific list of articles)". The community passes bans like that all the time. Bans state the will of the community. Blocks are just a way to technical way to enforce a ban. If the community banned somebody from (for example) a namespace and that user violated that ban, I suppose an admin could then impose the corresponding pblock to enforce the ban, but I think it's more likely they would just block the user completely; that's usually what happens when users disregard community-imposed restrictions. RoySmith (talk) 14:46, 9 July 2024 (UTC)
- I don't see anything needing changing; admins can make unilateral partial blocks (e.g. in cases of edit warring) or at the close of a discussion where consensus is achieved (e.g. an article subject who can't be neutral on their article). Primefac (talk) 22:46, 9 July 2024 (UTC)
- PS, I can't think of any reason a discussion at WP:AN or WP:ANI couldn't end with "There is broad consensus by the community to ban User:Foo from Some Namespace (or from some specific list of articles)". The community passes bans like that all the time. Bans state the will of the community. Blocks are just a way to technical way to enforce a ban. If the community banned somebody from (for example) a namespace and that user violated that ban, I suppose an admin could then impose the corresponding pblock to enforce the ban, but I think it's more likely they would just block the user completely; that's usually what happens when users disregard community-imposed restrictions. RoySmith (talk) 14:46, 9 July 2024 (UTC)
- When partial blocks were the new hotness there was much fear of the unknown which got hashed out at WP:PARBLOCK2019. One of the questions was "Should partial blocks be limited to community consensus only?" That got voted down nearly unanimously, and the "discretion of any administrator" language came out of that RFC close. RoySmith (talk) 14:40, 9 July 2024 (UTC)
Unblocks of a global block
Reading the most recent admin newsletter, do we feel like current blocking policy covers the situations where we would unblock someone on enwiki who is blocked globally or do we need to hash out new language for it? I genuinely don't know how I would handle such a request which maybe reflects that this isn't the normal area I work or maybe reflects something that needs clarifying. Best, Barkeep49 (talk) 16:13, 6 August 2024 (UTC)
- Yeah, I saw that. To be honest, I'm hard pressed to think of a situation where we'd want to locally unblock somebody who is globally blocked. Accounts don't get globally blocked without a good reason. RoySmith (talk) 16:23, 6 August 2024 (UTC)
- Given how new global blocking is, I'm not sure I have a sense of what people will get globally blocked for and thus not sure how often enwiki might reach a different conclusion about it. Best, Barkeep49 (talk) 16:34, 6 August 2024 (UTC)
- One thing I am sure about is that having two different features named "global block" and "global lock" is guaranteed to create confusion. RoySmith (talk) 16:38, 6 August 2024 (UTC)
- There is a plan to merge global locking into global blocking (though the name may still remain on-wiki) at T373388. Not planned for the short term though. Dreamy Jazz 17:32, 15 September 2024 (UTC)
- One thing to note is that global blocking for accounts was developed so that there would be a way to prevent temporary accounts from editing on all wikis. If you lock a temporary account it just allows the user to get a new temporary account on their next edit. Dreamy Jazz 17:34, 15 September 2024 (UTC)
- One thing I am sure about is that having two different features named "global block" and "global lock" is guaranteed to create confusion. RoySmith (talk) 16:38, 6 August 2024 (UTC)
- Given how new global blocking is, I'm not sure I have a sense of what people will get globally blocked for and thus not sure how often enwiki might reach a different conclusion about it. Best, Barkeep49 (talk) 16:34, 6 August 2024 (UTC)
- Of course not for en.wp at this time, but I think about cases like Malnadach and Slowking as perhaps illustrative. There may be less difficult cases also, perhaps global blocks will come first for VOAs or other not-difficult cases instead of locks and they'll be able to appeal on particular projects. IznoPublic (talk) 17:10, 6 August 2024 (UTC)
- I just want to mention that we already locally unblock global IP blocks with existing policy. It's not common, and admittedly has a different flavour. Personally I think we should cross whatever bridge when it happens. And it should by default go in front of the community on a noticeboard (do we need to actually write that? I don't know). The only thing we shouldn't be doing (and I don't know how relevant that is here) is to undo an office action, but I think that's probably adequately documented under the office policy. -- zzuuzz 17:24, 6 August 2024 (UTC)
- I wonder what should happen with the "request glock" feature of WP:SPI? The SPI templates support flags for this, and User:GeneralNotability/spihelper.js (which I guess is orphaned at this point) has functionality to make the requests on meta. Should we switch that over to using gblock instead of glock, or expose both options? RoySmith (talk) 17:46, 6 August 2024 (UTC)
- Or maybe not orphaned after all! RoySmith (talk) 17:48, 6 August 2024 (UTC)
- We will need to consider this for temporary accounts, as global blocks is the only method to prevent them editing cross-wiki (global locks don't work as I've mentioned above). Dreamy Jazz 17:35, 15 September 2024 (UTC)
- I generally agree with Zzuuzz that this should be handled on a case by case basis. However I would say that rather than
by default go in front of the community on a noticeboard
that local unblocks should only happen as a result of a consensus at a community noticeboard (I don't have a strong feeling about which board), and I do think it worth explicitly saying this. When there have been enough of both global blocks and local appeals of global blocks that we have a reasonable feel about why they get applied, what grounds people appeal them on and what the response to the appeals is, we can amend the policy to reflect what is and is not controversial in practice. To that end it might (or might not) be worth explicitly marking it as a temporary policy that will only apply to the first say 10 appeals with a mandatory discussion to keep, remove or amend at that point (such a discussion need not be more heavyweight than a "This seems to be working well, we'll mark it as permanent unless anybody objects in the next week" or "in practice these are uncontroversial, does anyone object to just replacing the policy with a note saying whether to accept, decline or discuss is an individual admin's discretion?"). Thryduulf (talk) 19:56, 6 August 2024 (UTC)- Here's the thing. As Roy mentions above, global blocks are different than global locks. So I agree with what @Thryduulf and @Zzuuzz are saying about global locks - they need either community input or ArbCom concurrance. Global blocks are a whole different new thing and my gut tells me they should be handled more like a normal unblock - given that the user might have done nothing wrong on enwiki before being globally blocked even - than an unlock where sometimes they need community input but normally not. Best, Barkeep49 (talk) 20:37, 6 August 2024 (UTC)
- If it turns out some or all local appeals are uncontroversial then we can remove the consensus required provision when we know that, but until we do know who is getting blocked, who is appealing and what the community attitude to those appeals is, I'm not confident that individual admins will know enough to know what is and isn't going to be controversial, what is a reasonable grounds for appeal and what isn't. If some appeals are uncontroversial then consensus to unblock will develop quickly (I'm not proposing a quorum, minimum discussion length or anything like that) and nobody loses. Thryduulf (talk) 20:50, 6 August 2024 (UTC)
- I think if we start with the highest cost option - everything must be community reviewed - it's unlikely we would ever go back to a lower cost option. I appreciate the work Izno and Roy are doing below in getting this onwiki so we don't have to talk hypothetically. Best, Barkeep49 (talk) 00:49, 7 August 2024 (UTC)
- If it turns out some or all local appeals are uncontroversial then we can remove the consensus required provision when we know that, but until we do know who is getting blocked, who is appealing and what the community attitude to those appeals is, I'm not confident that individual admins will know enough to know what is and isn't going to be controversial, what is a reasonable grounds for appeal and what isn't. If some appeals are uncontroversial then consensus to unblock will develop quickly (I'm not proposing a quorum, minimum discussion length or anything like that) and nobody loses. Thryduulf (talk) 20:50, 6 August 2024 (UTC)
- Here's the thing. As Roy mentions above, global blocks are different than global locks. So I agree with what @Thryduulf and @Zzuuzz are saying about global locks - they need either community input or ArbCom concurrance. Global blocks are a whole different new thing and my gut tells me they should be handled more like a normal unblock - given that the user might have done nothing wrong on enwiki before being globally blocked even - than an unlock where sometimes they need community input but normally not. Best, Barkeep49 (talk) 20:37, 6 August 2024 (UTC)
- I wonder what should happen with the "request glock" feature of WP:SPI? The SPI templates support flags for this, and User:GeneralNotability/spihelper.js (which I guess is orphaned at this point) has functionality to make the requests on meta. Should we switch that over to using gblock instead of glock, or expose both options? RoySmith (talk) 17:46, 6 August 2024 (UTC)
- I put a request in the ear of a steward to move onwiki the discussion stewards are having about global blocks, so perhaps we won't have to just "come up with something" without considering the dimensions they'll be thinking about. :) That feels like the primary blocker to thinking about the problem. Izno (talk) 22:57, 6 August 2024 (UTC)
- I've also been interfacing with some steward ear today. From what I can tell, they're as unsure about all this as we are. RoySmith (talk) 00:38, 7 August 2024 (UTC)
Blocking IP addresses
I have come across an indefinite rangeblock which has not been cancelled although 16 years old. The range is 66.197.128.0/17. Can it be removed? 82.0.216.119 (talk) 16:07, 21 September 2024 (UTC)
- That IP address belongs to Netflix. Nobody should be editing from there. I'm not seeing any reason to lift the block, would you mind elaborating why you think this is necessary? --Yamla (talk) 16:10, 21 September 2024 (UTC)
- The IP is unable to reply, as it was used by WP:LTA/VXFC to evade their ban. Favonian (talk) 16:24, 21 September 2024 (UTC)
"Blocking policy" listed at Redirects for discussion
The redirect Blocking policy has been listed at redirects for discussion to determine whether its use and function meets the redirect guidelines. Readers of this page are welcome to comment on this redirect at Misplaced Pages:Redirects for discussion/Log/2024 October 12 § Blocking policy until a consensus is reached. C F A 💬 20:38, 12 October 2024 (UTC)