Wikipedia:Requests for comment/Partial blocks

File:MediaWiki's Special-Block interface, taken February 21, 2019.png

Screenshot of the new Special:Block interface with partial blocks enabled

Currently, administrators are only technically able to prevent users from editing the entire site via a block. In 2018 and early 2019, the Wikimedia Foundation's Anti-Harassment Tools team worked on implementing partial blocks. Rather than the entire site, this functionality would allow administrators to prevent a user from:

1. Editing one or more specific page(s)
2. Editing all pages within one or more namespace(s)
3. Emailing other users

As of December 2019, this functionality has been deployed on most large- and medium-size wikis—specifically the Arabic, Bengali, Chinese, Dutch, Finnish, French, German, Hebrew, Hungarian, Italian, Japanese, Korean, Persian, Polish, Portuguese, Russian, Serbian, Spanish, and Telugu Wikipedias, as well as on Meta Wiki, MediaWiki, and all Wiktionary, Wikivoyage, and Wikisource wikis. There are plans to deploy the functionality to more projects in the future as well. More information on partial blocks can be read at Wikipedia:Community health initiative on English Wikipedia/Partial blocks. An example of a partial blocks policy modeled off of other wikis can be found at Meta:Partial block model policy.

The purpose of this request for comment is to determine whether partial blocks should be enabled on the English Wikipedia. 05:45, 12 December 2019 (UTC)

Survey

Should partial blocks be enabled on the English Wikipedia?

If needed, a follow-up RfC could be held to determine whether restrictions should be imposed on the use of partial blocks beyond those which the blocking policy already imposes on blocks.

Support

1. Support with follow-up RfC to develop policy. I think partial blocks would be a useful tool to add to the toolbox. I've listed a few possible use cases below at #Possible use cases. I think the most effective use case would be to counter edit warring. Currently to stop edit warring administrators can either fully block editors or fully protect the article in question from all editing. Both of these are challenging to implement in practice because blocking prevents an editor from participating in discussions (which is what we want to encourage over edit warring) and page protection stops all development on an article completely. A partial block would be a less WP:BITEy and harsh sanction that achieves the same preventative goal of forcing editors to discuss the change on a talk page.
   I also think the other possible use cases have merit. There have been a few cases in the past where I wished I could partially block a particular IP address or IP range because they were targeting a very specific article for vandalism, but to block the whole range would have meant too much collateral damage. An example of this was on the Giant Tiger article with the following IP: Special:Contributions/199.198.223.109. This editor was inserting an irrelevant person's name into an article that had nothing to do with subject—however, it was only doing this once every month or so, and the IP address is shared among unrelated users. The vandalism was also targeted specifically to this article in a way that made it unlikely to spread to other articles. As an alternative to indefinite semi-protection on the article (the solution that was implemented) I think it would have been useful to implement a long partial block on the IP address with respect to this article.
   I think it would be useful to hold a follow-up RfC to discuss how we're going to implement this. For example, I would be unopposed to an implementation for edit warring only. Mz7 (talk) 05:45, 12 December 2019 (UTC)

   Edit: I've been convinced by my colleagues on the other side that a follow-up RfC would not only be useful, but necessary to avoid rushing into this without a plan. I've added this to my bolded !vote above. The idea for a trial phase sounds like a reasonable implementation step, but I think we should discuss it in a follow-up RfC instead of rushing into it at this RfC. Mz7 (talk) 22:23, 12 December 2019 (UTC)

   Mz7, I think this RfC is going to get better attendance than subsequent RfC. As such, considering we're talking about a trial on Day 1 of this RfC (and like I floated it two minutes after it opened so it's out there for discussion for the entire length of the RfC) that this would be the best time to ascertain if the community feels a trial is worthwhile. I obviously do. If the bulk of the community doesn't, fair enough, but I do think we can get consensus on that view here and don't need to punt on it. Best, Barkeep49 (talk) 22:28, 12 December 2019 (UTC)

2. Support The admin's toolbox could certainly use more precise tools, which will cut down and disruption, and reduce BITEy actions. It will also take some of the bureaucracy of topic bansediting restrictions off the community (less bureaucracy is a good thing!!). I think this should be trialed per Barkeep's suggestion. Should this pass, an RfC to work out the specifics should immediately follow, and should be allowed to run its course before the system is implemented. Clearly, new systems and policies will have to be implemented to make this work. Captain Eek ^{Edits Ho Cap'n!}⚓ 06:33, 12 December 2019 (UTC)

   Topic bans actually couldn't be enforced via this since category blocks are not under discussion, and if they were, they'd likely be opposed since it would effectively give non-admins the right to block just by adding a category. I'd have to find the thread, but at one point I believe even the WMF team working on this said that it would not be useful for topic ban enforcement for a variety of reasons. TonyBallioni (talk) 06:44, 12 December 2019 (UTC)

   Ah, thank you for pointing that out. I was careless with wordchoice, editing restrictions is a more precise definition of what I meant. Captain Eek ^{Edits Ho Cap'n!}⚓ 07:09, 12 December 2019 (UTC)

   @CaptainEek and TonyBallioni: Pagebans on the other hand are enforceable with this. I just wanted to throw that out there. –MJL ‐Talk‐^☖ 13:26, 12 December 2019 (UTC)

   Yes, because giving admins the unmitigated ability to ban people from pages without any practical means of review is somehow a good thing... TonyBallioni (talk) 13:39, 12 December 2019 (UTC)

   Arguably, pageblocks would be more prone to review than an indef block because the user could appeal directly to WP:AN. –MJL ‐Talk‐^☖ 14:18, 12 December 2019 (UTC)

3. Support. I think this adds to the range of measures available to deal with disruption. By having some less severe measures, a lot of the tension + wasted time (with appeals, acrimony, lasting bitterness etc.) associated with complete site blocks can be reduced. I hope it also encourages editors to solve specific disputes; provides more time for editors to prove their worth in other areas of the encyclopedia whilst remaining active; potentially expanding our pool of editors by retaining some enthusiastic but misguided editors; and allows for a more finessed approach, which might also help drive a more nuanced approach to dealing with problems (rather than an all or nothing block). Strong support. --Tom (LT) (talk) 07:26, 12 December 2019 (UTC)

   Addit. I agree there will be teething problems ("bureaucratic nightmare") as we work out how to implement this, but I think the benefits in the short and long term highly outweigh the inconvenience of working out how we will use this here.--Tom (LT) (talk) 07:28, 12 December 2019 (UTC)

4. Support Esp. if this can be used against IP ranges within a group of sub-cats. I suffered from a editor stalking me, and once they were blocked, they ignored the block and went to IP edits. Sadly, they IP range hop every few hours or so. The IP range is so big it would block out half of the Western world. However, it's a fairly niche area of edits, and a block of the range at a category level would fix this in one fell swoop. Lugnuts ^{Fire Walk with Me} 09:24, 12 December 2019 (UTC)
5. Support only with trial, and procedural fail with RfC format - it needs both a trial period, with an automatic revert at the end (a new consensus must be generated for it to retained). It also needs a follow-up RFC, with a consensus for any authorised use case/target group. It adds an extra toolkit, but it also adds problems. The former must outweigh the latter. Nosebagbear (talk) 10:02, 12 December 2019 (UTC) (Addition) - it still needs a trial, and the specific use-case options should have been added part-way through the general yes/no RfC. I feel the other options should be cancelled unless it can be guaranteed that every participant to part 1 has reviewed, as people can look like they are agreeing to things they were not in play to start with Nosebagbear (talk) 18:22, 26 December 2019 (UTC)
6. Support unconditionally. These tools were carefully designed to fill a specific need. If they misfire, their use can be curtailed. We don't need to assume the worst case scenario for new options meeting an obvious need. EllenCT (talk) 10:23, 12 December 2019 (UTC)
7. Support A 3-month trial of the implementation (a specific use-case/target group is fine). First thing to note is that a lot of other Wikipedias implemented this as well, and I'm sure they hit roadblocks here and there, but nothing bad enough to cause a crosswiki effort to remove it permanently, which leads me to think this idea has a good amount of potential. This tool is most effective in editors who simply cannot adhere to a ban and removing their technical ability to not touch their problem areas is a pretty good fix, the current solution of you have the options, you better hope you don't get caught just results in a lot of the same things over and over again. --qedk (t 桜 c) 11:38, 12 December 2019 (UTC)

   I'm actually a little wary of the potential use case of enforcing topic bans, and I'm glad that we are discussing it here. From a technical standpoint, due to the limitations of the tool, we can only partially block editors from specific pages—it would be infeasible, for example, to use a partial block to enforce a topic ban over all BLPs. Technical issues aside, I think we should be careful not to present partial blocks as a replacement for a site-block in response to violations of topic bans. If an editor violates a clearly established topic ban, then I would encourage administrators to site-block the user, not partial-block. The main reasoning for this is a trust issue: if you decide to disrespect the conditions of a clearly established topic ban, then can we really trust you to respect the conditions of any social norm on Wikipedia (i.e. our policies and guidelines)? A site-block would also act as a better deterrent (c.f. WP:BLOCKDETERRENT); if editors knew that they would only be sanctioned with a partial block or a warning for topic ban violations, then they may be more inclined to violate their topic ban. Mz7 (talk) 12:11, 12 December 2019 (UTC)

   Implenting topic bans is probably unfeasible, but implementing page bans are and implementing enforcement partial bans as a response to trespassing topic bans is alright as well, as multiple sanctions will lead to a siteban anyway. --qedk (t 桜 c) 14:25, 12 December 2019 (UTC)

8. Unreserved support. This is feature is practically a Godsend. Scots Wikipedia already has it implemented. It's a wonderful thing. –MJL ‐Talk‐^☖ 13:24, 12 December 2019 (UTC)
9. Support and long overdue. The ability to partially block editors is a necessary and useful way to enforce partial bans such as topic bans and interaction bans. I could possibly think of a few technical improvements, but that's a post-implementation process and I am in total support of putting this concept into action. --Jayron32 14:24, 12 December 2019 (UTC)
10. Support I like the idea, but there are several issues (when to use it, replacing editing restrictions, etc) that need to be addressed before the tool goes into the regular toolbox. I do not believe that once the tool is enabled all current editing restrictions should be automatically or robotically converted over. If an editor feels that a current editing restriction should be converted over, a discussion should happen to determine if there is a consensus for the conversion. Hasteur (talk) 15:04, 12 December 2019 (UTC)

    I do agree with Hasteur's point on not using the tool in an ex post facto manner. The addition of a page block or namespace block to any existing restrictions would need to be explicitly authorized on a case-by-case basis, even if we decide to allow its use broadly going forward. --Jayron32 15:06, 12 December 2019 (UTC)

11. Support Always nice to have one additional tool in the tool kit. I agree this needs some sort of trial run followed by centralized discussion to set up proper policy for use once the community has a better feel for it. 2604:2000:8FC0:4:617F:E9A7:AF1C:4546 (talk) 16:03, 12 December 2019 (UTC)
12. Support Until such time that registration is required to edit, which is ultimately the only way out of the unsustainable and worsening problem that's happening WRT anonymous editors, this is a good temporary patch. It will also be useful even after required-registration is ultimately implemented. -Jordgette [talk] 19:02, 12 December 2019 (UTC)
13. Support for a trial. This new tool has clear theoretical benefits, especially when developed to its full potential (good luck in getting the WMF to do that). But we need to figure out how to use it first, which is what the trial period is for. MER-C 19:15, 12 December 2019 (UTC)
14. Support a trial, let's say 6 months or so. I could see this being useful. We would need a rfc as well as to the specific policy that would apply to partial blocks. SQL^{Query me!} 19:43, 12 December 2019 (UTC)

    Discussion on trials was opened below, as is some rough policy discussions. Changed to regular support. SQL^{Query me!} 18:02, 15 December 2019 (UTC)

15. Support per above, with a followup RfC to determine the associated policy. -FASTILY 20:20, 12 December 2019 (UTC)
16. Support We need something between sitewide block and no-block. Sitewide block is not always the optimum solution, it's only used because there's nothing less restrictive. Partial block will surely help in providing that missing options. – Ammarpad (talk) 23:12, 12 December 2019 (UTC)
17. Support conditionally, mostly sympathize with the edit warring issue. If a consensus is determined to accept the proposal of this RfC, a follow-up workshop/discussion RfC phase should be held to determine the limits of the partial block. Partial blocks should then be implemented during a trial period, as suggested by others. UnnamedUser (talk) 04:33, 13 December 2019 (UTC)
18. Support, for pretty much every proposed reason. I've long thought we needed this, if the technical ability to do it could be made to happen. We have an enormous WP:DRAMA problem surrounding blocks, and it costs us way too much productivity: in the sense of denying productive editors any ability to contribute just because they've crossed a line in some highly localized topical dispute that really doesn't mean they cannot be useful anywhere on the project at all; and in the sense of all the time the community spends hand-wringing over blocks and their consequences; and in the sense of disruption being allowed to continue, often for many rounds of WP:DRAMA, because it is localized to a topic most people don't care about and we don't want to lose the contributor's input elsewhere. Secondarily, it drives me nuts that we're totally blocking massive ranges of IP addresses just to deal with very localized problems. Sometimes I have to try a dozen of my VPN's endpoints before I can find one through which I can edit. Same goes for when I'm editing remotely via a mobile device and going through library or cafe WiFi. And, yes, our current topic-banning system is rather farcical, and just another DRAMA factory; how many thousands of times has someone been T-banned only to have the community have to deal with them yet again for violating the T-ban (or having to argue at length at one DRAMA process or another where such a breach occurred)? Just block them from an entired category and from some specific relevant pages not in the category, and most of that problem just goes away.  — SMcCandlish ☏ ¢ 😼  04:50, 13 December 2019 (UTC)
19. Support the concept. However, there needs to be a policy backing up the tool before it is enabled. -- Dolotta (talk) 15:26, 13 December 2019 (UTC)
20. Support adds useful and potentially less disruptive options. Flexibility and options are almost always good things. Reading the opposes, I don't think serious problems are likely - and if issues were to arise we can alter policy on it or simply decide not to use it. There is little inherent threat in something we can decline to use. The worst case is it would be a worthwhile failed experiment, and we just stop using it and leisurely ask for it to be disabled. Alsee (talk) 17:27, 13 December 2019 (UTC)
21. Support the idea definitely makes sense for people who are causing disruption on a single page or a group of pages, e.g. edit warring on one article or breaching a topic ban on some page. As long as the disruption is limited there's no particular reason to prevent them editing the rest of the encyclopedia as well. Hut 8.5 17:51, 13 December 2019 (UTC)
22. Support Seems like a pretty nice and awesome idea, considering that full block is sometimes not really necessary for some cases. Partial blocks should probably be a new way to go. NNADIGOODLUCK (Talk|Contribs) 17:52, 13 December 2019 (UTC)
23. Support trial period per Beeblebrox with a follow-up RfC to determine the scope of the best way to apply it. OhKayeSierra (talk) 20:12, 13 December 2019 (UTC)
24. I am generally in favor of keeping this as simple as possible. Since I am not entirely opposed to the underlying concept, I say we turn it on, use the meta policy, and modify it over time as needed to better fit our project's needs. That includes modifying to say we don't use it all should that be the consensus view in the future All policies change over time, trying to develop a perfect policy before we've even used it is putting the cart before the horse if you ask me.Beeblebrox (talk) 00:08, 14 December 2019 (UTC)
25. – Levivich 03:37, 14 December 2019 (UTC)
26. Suppprt - without any arguments. Pretty useful. Besides we are not losing any options, site-wide block would remain the same. Masum Reza^📞 16:26, 14 December 2019 (UTC)
27. Support – They work very well in the German Wikipedia. --Count Count (talk) 19:53, 14 December 2019 (UTC)
28. Support unconditionally – I have long waited for this RfC, and for the feature in general. Ideal alternative to a full edit-warring block. ~ ToBeFree (talk) 20:50, 14 December 2019 (UTC)
29. Support. Like some others, I have been waiting for this feature to come to English Wikipedia since I first read about it being in use elsewhere. Of course we need to establish guidelines for how it should be used, but the arguments that it cannot be used beneficially do not hold water. The all-or-nothing attitude that editors should either be totally blocked or not is undercut by the fact that we already have many cases of partial restrictions, including topic bans, revert limits, and various other restrictions that are only applicable to some pages. The main difference between those and a partial block is they are social restrictions rather than technological (just as site bans are social and site blocks are technological). These existing practices around partial restriction reflect the reality that sometimes an editor is beneficial and productive in some areas, but unable to maintain good behavior in others. If editors really couldn't behave well in some areas despite their misbehavior in others, then we might as well have global blocks or nothing, which is not what we do and not something anyone is asking for. Partial blocking is just one more tool to help manage those not-all-or-nothing situations. Will there be drama and wikilawyering related to partial blocks? Of course there will; people are going to cook up drama and wikilawyering over any kind of sanction or restriction. That doesn't mean we shouldn't have the tools to restrict them. --RL0919 (talk) 21:49, 14 December 2019 (UTC)
30. Support with a follow-up RfC - Sometimes a site-wide block just isn't needed, and could be seen as being WP:BITE-y. If it has worked on other wikis, then it should be enabled here. BEANS X2 (talk) 12:03, 15 December 2019 (UTC)
31. Support This will, I think, allow for a more nuanced approach to protecting the encyclopedia rather than the binary choice of blocking or not blocking editors from the entire site though clearly some guidance would be welcome. --Malcolmxl5 (talk) 20:03, 15 December 2019 (UTC)
32. Support I think that partial blocks should only be used in certain circumstances, for example helping to reduce the disruption to IPs editing and giving blocked editors a chance to show that they have learnt their lesson without allowing them to jump straight back into their old trouble spots. I think that jumping straight into using partial blocks with an agreed policy (or an agreement that no policy / the meta policy is the way to go) will help. As this is already happening below, I give my support. Dreamy Jazz 🎷 ^{talk to me | my contributions} 12:36, 16 December 2019 (UTC)

    Although I do like the idea of having specific circumstances where partial blocks can be used, my support for the enabling of partial blocks is not dependent on this. Dreamy Jazz 🎷 ^{talk to me | my contributions} 12:39, 16 December 2019 (UTC)

33. Support A long overdue useful tool that would make blocking less punitive and more preventative of disruption.-- Deepfriedokra 05:11, 17 December 2019 (UTC)
34. Support. The reality is that we already do this (via topic bans), we just have to go through lots of extra steps to enforce them and there's a constant risk that the subject will screw up and get themselves banned. Obviously a technical solution cannot entirely replace our topic ban system, since sometimes someone will need to eg. avoid one specific section or dispute on a page that falls under their topic ban while being allowed to edit other parts freely; but this would at least make them simpler, and it's hard to see how it could lead to any great problems. --Aquillion (talk) 10:09, 22 December 2019 (UTC)
35. Support conditionally This is a a great idea as a less severe alternative to a site-wide ban. But we need a RfC to put limits on the scope of these tools. This seems very useful in some particular circumstances, but only after warnings, and not as a fallback option when full-site ban can't be justified. Forbes72 (talk) 21:31, 22 December 2019 (UTC)
36. Support Any tool that can give sysops more flexibility is a good thing. Obviously, if a tool could lead to abusive misuse that wouldn't apply, but this is not an example of that. Allowing sysops to partially block users allows them to be functionally blocked in that the purposes of the block will be fulfilled, without completely removing their right to edit constructively. Worst case scenario, if the user vandalizes after that, they can always be fully blocked. Best case, we give blocked users the opportunity to demonstrate intent to edit constructively, potentially making the rather inefficient and ineffective standard offer obsolete. --Puzzledvegetable^{Is it teatime already?} 23:42, 22 December 2019 (UTC)
37. Support strongly. It has many potential uses for limiting disruption by editors who are constructive work in other areas but have problems in specific pages/namespaces. It may be a good way to block someone for edit warring but also allow them to edit other non-contentious areas. It can also be used to enforce topic bans or other editing restrictions. I think this must be used judiciously, however. epicgenius (talk) 18:28, 24 December 2019 (UTC)
38. Support lots of potential to be a suitable measure in situations where a full block is too crude. We may need a trial and/or follow-up RfC to determine policy specifics, but this feature is undeniably useful and should be enabled in some form, however broad or narrow this form is determined to be. – Teratix ₵ 05:49, 28 December 2019 (UTC)
39. Support. Partial blocks are a necessity for enforcement of topic and namespace bans. | abequinn^fourteen 23:01, 28 December 2019 (UTC)
40. Conditional support I think this will be a good tool to have in the tool box, but only after a policy on the use of it has consensus, and then only with a trial period. I oppose turning this on without such a policy, or without a trial with an explicit end-date after which it will be turned off again pading a further RfC. DES ^(talk)_{DESiegel Contribs} 01:59, 29 December 2019 (UTC)
41. Support - This is a less-draconian alternative to current tools which are already utilized discretionarily. Attempts to suggest that new policies are needed for what is simply the option to have lower-stakes blocking is a red herring. Any problems can be addressed as they come up, but honestly, I don't see the potential for these esoteric, faceless "problems" that the opposition thinks are looming. ~Swarm~ ^{sting} 02:18, 30 December 2019 (UTC)
42. Yes. If anything, this feature is too limited in functionality, and I would like to see it allowing blocks to prevent editing pages in a particular category or with a particular feature. feminist (talk) 03:12, 30 December 2019 (UTC)
43. Support - partial blocks simply allow more flexibility. They don't have to be used in cases where they aren't deemed suitable. In cases where they are suitable, they provide a much less dramatic alternative to full blocks. - Alexis Jazz 20:17, 1 January 2020 (UTC)
44. Conditional support - Seems to be a very promising tool, due to its ability to limit disruption while not being as BITEy. However, we need consensus on a well-defined policy around partial blocks to prevent any abuse. --Rlin8 (☎·✎·📧) 06:11, 2 January 2020 (UTC)
45. Support There are many justifications in my opinion for partial blocks. Users could have issues with some pages but not others, it would be a good failsafe for topic bans too. DrewieStewie (talk) 20:11, 4 January 2020 (UTC)
46. Support this could be a useful tool in cases where disruption is limited to a particular area. Good alternative to blocking completely, whic may lead to editors staying with the project and learning from their errors rather than leaving after being blocked. Mjroots (talk) 20:13, 4 January 2020 (UTC)
47. Support with follow-up RfC to develop policy I echo Mz7, Swarm, and Beeblebrox on this. --TheSandDoctor ^Talk 20:43, 4 January 2020 (UTC)
48. Support: What is a block, ban or sanction for? Prevention of damage, not punishment is the answer we claim to adopt. From the preventative model, it logically follows that sanctions should be minimal in all facets—length, scope etc.—whilst preventing the harm that they are intended to stop. Partial blocks are very desirable for limiting scope and I've seen lots of discussions beforehand where the aim is equivalent to a partial block, but the hammer of a full block has had to be used for technical reasons. I've also come across lots of issues where I thought to myself that a partial block would have come in handy. The IP use cases mentioned below are a brilliant example. The issues people mention in the "Oppose" section are reasons for limiting the use cases of partial blocks, making sure that there is sufficient oversight and ensuring that our policies allow for common sense. For instance, a topic ban should never only apply to pages where a user is technically restricted from editing, but to the full scope of the topic ban, as is the case currently. A partial block should still be seen as a serious measure to take and obviously be subject to WP:INVOLVED. And lastly, it wouldn't be an RfC without some users commenting that the process should have been done in a different order or that the RfC should have been simpler or more complicated: we need to take a first step and this seems like a sensible one to me. Any admin who takes this as a mandate to go around partially blocking enemies at will should still be accountable to all of our normal behavioural sanction processes. — Bilorv (talk) 00:14, 5 January 2020 (UTC)
49. Support: A partial block is still psychologically a block, both in terms of the editor and the administrator doing it - administrators making bad blocks can and have been desysopped. I for one would very much appreciate the option; a partial block is inherently a less severe sanction, and I can recall multiple situations where simply forcing an editor to disengage from a particular page is all that is needed. Any threats of misuse of partial blocks, it seems to me, already apply to normal blocks. ~ mazca ^talk 02:12, 5 January 2020 (UTC)
50. Suppprt After the long lead up, it's about time. Flexibility to tailor to the situation. Admins can already made a block choice based on duration, so status quo hasn't been all-or-nothing blocks.—Bagumba (talk) 02:20, 5 January 2020 (UTC)
51. Support, more tools are better than fewer tools. Stifle (talk) 10:07, 6 January 2020 (UTC)
52. Support, but the initial rollout should be 1) for a test period (see below) and/or 2a) with a policy that allows it only in cases that clearly have a consensus here or 2b) after a follow-up RfC to determine policy. For example, if there is a clear consensus here to implement this but no individual "use case scenario" has consensus, then either go with a trial period and/or a follow-up RfC. If there are some "use case scenarios" that have a clear consensus, they can be implemented immediately but a trial period is also okay, with a possible future RfC to update the usage policy. davidwr/(talk)/(contribs) 20:19, 8 January 2020 (UTC)

Oppose

1. I can think of no use case where partial blocks would not create more disruption than they are attempting to block. The most common argument for them is edit warring, but here that's unlikely to be the case: we currently are very generous on edit waring, and almost always unblock automatically the first time, that's unlikely to happen here, and if anything I think arguing on the talk page while unable to actually edit is just likely to make people more angry.
   Let's talk about the real problems, however: this is a massive expansion of the scope of administrator power in a way that can only backfire and destabilize the project. Currently, except in very defined circumstances, administrators cannot impose sanctions on individual editors and otherwise, they need to establish justification for a block. That would go away here. While this is billed as a less intrusive means of preventing disruption, what it instead is is a way to expand the scope of the limited mandate of admins far beyond what discretionary sanctions are. That is not healthy for the project, and is a reason to oppose in itself.
   Even if it were limited to DS areas, using it as a technical means to enforce discretionary sanctions would lead to wikilawyering and extreme drama in an area that needs no more. Topic ban enforcement this way would be a nightmare, and we do not need it.
   Finally, there's the elephant in the room: en.wiki already has a culture that privileges long-term disruption and where sanctions against people with friends are next to impossible. This would make that worse.  Blocks would be infinitely contested under the principle that the admin should have used a lesser option, and Wikilawyering will abound.
   Ultimately, all my points above come down to this: either someone is disruptive enough to be blocked, or they shouldn't be blocked. Anything else should be enforced via social means such as limited bans. A trial or second RfC are not solutions, because those are just ways to win support for something that could not pass on its own and that will not be reversed if implemented, regardless of how miserable a failure it is. We have the means to do that already. We don't need to create more disruption by allowing this unneeded bad idea on en.wiki. TonyBallioni (talk) 05:46, 12 December 2019 (UTC)

   @TonyBallioni: We can discuss this more at length somewhere else, but I do want to address just a single one of those concerns. Currently, the way we deal with an unblockable is to apply a time-limited block on the account. People are going to likely wikilawyer over whether a less severe measure was a possibility regardless if partials blocks are a possibility (get rid of timelimited blocks and people will somehow argue that a twenty-second warning would have sufficed). I would say that, in a vacuum, an indef partial block targeted to certain problem areas is much more productive than a temporary time-limited block because it will have lasting staying power.
   To your other points, I shall not dispute them since it's something admins would be able to more effectively discuss. –MJL ‐Talk‐^☖ 14:16, 12 December 2019 (UTC)

2. I do not feel they would be useful or effective, and will likely lead to angry discussion. With good reason, if you ask me.--Wehwalt (talk) 06:18, 12 December 2019 (UTC)
3. What Tony said. Not to mention that it's likely to become a bureaucratic nightmare. Pivotally, now every admin is going to effectively have a DS-like mandate, for everything? That does not seem like something that is aligned with the English Wikipedia's long-held convention about what the the scope of administrative intervention ought to be. This is, fundamentally, an overarching change on the level of policy. This is not merely a technical change, per se. El_C 06:32, 12 December 2019 (UTC)
4. Very strong oppose - cart before the horse. We have no policy or even a hint at a start of development of one governing the use of partial blocks. It's absolute bonkers foolishness to enable such a powerful feature with no rules whatsoever. Tony also makes very good points. Personally I look forward to the implementation of this feature, but it's WAY too soon to be at this stage. Ivanvector (^Talk/_Edits) 16:44, 12 December 2019 (UTC)

   Policy is vital, but I disagree that we need to establish a policy before we decide it should be enabled. Look at it from the other direction: Maybe we spend a month crafting and writing a policy for implementation; how and when it is to be used, we hold long discussions and votes and the like, and create a good policy we can all agree to, and then the community rejects the use of the tool outright. What is the point of crafting a policy for a tool the community has no plans to use? We should both establish that the tool should be used, and under what conditions it should be used, but I would find it disappointingly pointless to develop policy unless we know the community wants the tool in the first place. --Jayron32 19:11, 12 December 2019 (UTC)

   Fair points, but this question is not "should we enable this tool in tandem with developing policy governing its use?" The question is "should we turn this on?" And the answer is no. A different way of looking at this is another instance of "here's a tool, now figure out what problem it solves". Or yet one more way: giving admins a new tool with no accompanying guidance as to how the community expects it to be used is inviting inconsistency and a hell of a lot of drama, for reasons which might be good but nobody really knows what those reasons are. Ivanvector (^Talk/_Edits) 19:55, 12 December 2019 (UTC)

   @Ivanvector: That actually is the question: If needed, a follow-up RfC could be held to determine whether restrictions should be imposed on the use of partial blocks beyond those which the blocking policy already imposes on blocks. –MJL ‐Talk‐^☖ 04:49, 13 December 2019 (UTC)

   No, that's not the question. "If needed ..." no, it is needed, before the tool is turned on. "Restrictions ... beyond those ... already impose[d] on blocks" suggests we're going to enable this new tool and expect that it will be used exactly like "full" blocks until we discover whether there is any use case for more granular blocking, suggesting it's not expected to be a useful answer to any actual problem at all, or we're going to use it to go looking for one. I recall in an earlier phase of this project it was discovered that partial blocks cannot stack, so you can block someone from exactly one page, or exactly every page, but nothing in between, and if that has not been resolved then what use would this be for (e.g.) discretionary sanctions enforcement? This is going a lot like pending changes level 2, where a tool was developed but we couldn't figure out what problem it solved, and after years of heated discussions we decided not to use it. Just because a tool is available doesn't mean it's useful. Ivanvector (^Talk/_Edits) 16:36, 13 December 2019 (UTC)

5. Will probably support later, but I think enabling this without first working out what the usage expectations are will cause more drama then it solves. There could be lots of ways this could help, but careful consideration is also important (e.g. Do we make a new "escalating" block type, maybe we don't full-block anon users on proxies anymore, who knows until it is discussed.... If you are an admin here and want to test the feature out on testwiki to learn more about it, feel free to drop me a note at testwiki:User talk:Xaosflux and I'll add temporary admin access for you there. — xaosflux ^Talk 17:10, 12 December 2019 (UTC)

   See above: I think we can establish that we should enable it first. We don't actually have to enable it right away, we just need to know that the community does actually want something like this, so we can press ahead with the policy framework. Why write policy ahead of time for a tool the community doesn't want at all? Lets establish that we want this first, then lets write the policy, THEN lets enable it. --Jayron32 19:14, 12 December 2019 (UTC)

   I think we should only enable it if we have some usage guidelines. I don't support enabling it with a "just don't use it" rule while that gets sorted. — xaosflux ^Talk 20:21, 12 December 2019 (UTC)

   Would it help if we had a separate discussion below in the context of proposed/possible use cases about which use cases make sense for us? That would give some initial direction to a) the followup RFC/trial and b) might persuade some opposers/supporters to consider the followup seriously. --Izno (talk) 20:43, 12 December 2019 (UTC)

   Good idea. I've added a few brainstorming ideas below in #Brainstorming policies. Mz7 (talk) 22:56, 12 December 2019 (UTC)

6. I would support only for IPs/IP ranges, for which it would be extremely useful to block them from specific pages/namespaces, which can currently only be done with edit filters. Edit filters are only accessible to technically competent admins and even as someone who knows how to use them, they are kind of a pain to create for just one IP/IP range. I don't really see any drawbacks to partial blocks for IPs/IP ranges.
   But I agree with TonyBallioni on his points regarding the other uses, so I do not support other use cases. at this point. For edit warring I could definitely see a two-tier system whereby long-term users get a "slap-on-the-wrist" of just getting blocked from the page they are edit warring on, which has no WP:BLOCKDETERRENT for any future edit warring and essentially tells those users they can edit war as much as they want without any real consequences (not that they aren't issues already but they would likely worsen with partial blocks). Partial blocks also do represent quite an expansion of admin power and if enabled certainly should be carefully considered with a draft policy first - my preferred approach towards any enabling of partial blocks would be to only allow it in certain use cases (specified beforehand). Galobtter (pingó mió) 22:04, 12 December 2019 (UTC)
7. Oppose If an editor is unable to abide by a topic ban or the edit warring policy, they should not be editing, and they should not be wasting unsanctioned editors time by continuing disputes on talk pages. Further, this proposal would promote wikilawyering by reversing the normal broadly construed of a topic ban—instead of the editor needing to think about whether they should pursue their favorite topic while a sanction is in place, an admin would have to technically block them from every possible page where they could continue. Johnuniq (talk) 02:52, 13 December 2019 (UTC)
8. Oppose until such a time as we have policies for the use of partial blocks that have community approval. Enabling these before creating policies for their use seems backwards. There are uses I could get behind (to replace some topic bans, ie imposed with community backing; or as discretionary sanctions) and others I cannot. But without policy this represents a huge increase in admin discretion, and so we need to delineate appropriate and inappropriate use first. Vanamonde (Talk) 06:18, 13 December 2019 (UTC)
9. There is no urgency. Let's see how this works for the other wikis, some of which have only recently enabled this, then re-evaluate based on their experiences. --valereee (talk) 20:10, 13 December 2019 (UTC)
10. While I supported usage of partial blocks in one specific case below, that case is rare enough that, as a whole, enabling the feature will primarily serve to expand Admins' technical power even further from their social power, a set-up that very rarely works. (I agree with Galobtter above about edit warring partial blocks being unwise, and feel that trying to enforce editing restrictions that cannot be defined by a computer, such as topic bans, by partial block is not feasible). * Pppery * _{it has begun...} 02:44, 15 December 2019 (UTC)
11. Oppose, basically as per Tony and Galobtter. GAB^gab 16:12, 17 December 2019 (UTC)
12. Opposed for now. It seems a trial is unlikely, but the possibility of a trial is one of the main reasons I withheld opposition. Given how the policy seems to be shaping up below, I don't have a ton of faith that we're walking into this with a clear understanding of what collateral damage may occur. This process feels rushed and despite two weeks of thinking I still don't have firm opinions on pretty much any of the suggestions below. I agree with valereee, we should see how it works out on other wikis rather than walking into this without much of an idea of the consequences such a radical change to our blocking policy and technology could cause. I would be very glad to change my mind down the road, but for now, without a time-limited trial period, I do not believe we should enable this extension. — Wug·a·po·des​ 20:18, 31 December 2019 (UTC)
13. Oppose for now. I would prefer that we have a policy for it before we turn the option on. ThePlatypusofDoom (talk) 05:25, 2 January 2020 (UTC)
14. Oppose for now. TonyBallioni and Ivanvector make some good points here; it feels a bit like a "hammer looking for a nail"? I have not seen a strong desire for such a tool as a solution to an existing perceived problem in Wikipedia? Are we saying that you can be a highly disruptive editor in one area (and thus blocked), but are free to edit elsewhere? Are we, therefore, going to end up with constant appeals such that problem editors need an extended matrix of individual blocks across a whole range of topics that they have been disruptive on (rather than a general block). I am not saying that this tool might never be used, but, as a first pass, it might better be restricted to being used as a "technology upgrade" for topic bans/AE-type situations. My impression is that DS-type admin sanctions are alredy stressful, time-consuming, and bureaucratic processes for admins (and thus, many stay away from it); won't this only exacerbate this situation? Britishfinance (talk) 15:40, 2 January 2020 (UTC)
15. No way. We should not be blocking them in certain areas just to allow them to go continue their disruption elsewhere as soon as that urge hits them again? Thats what topic bans and arbcom sanctions are for anyways, we already have a solution for this. Doing this feels like watching a bank robber rob a bank but then only preventing them from robbing other banks while letting them run rampant on the streets to do what they please, just as long as they dont rob banks. -- œ^™ 10:46, 5 January 2020 (UTC)

Neutral

1. Support a trial period for partial blocks, reverting to no blocks after trial period. Support a second RfC to decide under what conditions to implement this. Oppose without those two conditions. Neutral if those two conditions are met. Best, Barkeep49 (talk) 05:47, 12 December 2019 (UTC)
2. As soon as you enable a tool, people will find ways to use it in unexpected ways. It took many years to properly regulate revision deletion, for instance, but we still have controversies on admins deleting small pieces of information with possibly improper reasons. The English Wikipedia is arguably the only Wikimedia project for which partial blocks make sense, because of the vast usage of topic bans here, but even if the community decides to adopt them we must be aware it will take many many years of discussion before they are operated smoothly, if ever. The costs will be immense; it's important to make sure the benefits are too. Nemo 06:41, 12 =December 2019 (UTC)

   Moved to oppose I subscribe to Barkeep49's conditions. TonyBallioni's oppose explains my reservations well. The main positive I see is that partial blocks would help meatball:LimitDamage where the problems are specific: good faith but disruptive template editing, or unproductive comments in project space for example. However, I would like a trial period because I can see partial blocks ironically leading to more damage: people rarely take blocks well, and that frustration may lead to WP:POINTy disruption in areas the user can still edit. If we were to have a trial period, I would want to see that partial blocks do not correlate with full blocks. I would also prefer that they not be used as the default method of enforcing topic bans. Wug·a·po·des​ 18:01, 12 December 2019 (UTC)

3. I support the general idea on the grounds of Mz7's proposed case where IPs, or IP ranges, could be blocked from editing particular articles while allowing constructive contribs in other areas from other users of the IPs. I'm not sure about the other cases - I'm struggling to imagine another situation where we would be motivated not to block an inveterate edit warrior who refused to reform in the face of community approbation - but in any case, the RfC on defining usage should precede the RfC for switching on the tool.GirthSummit _(blether) 23:40, 16 December 2019 (UTC)

Should partial blocks be enabled on the English Wikipedia for a trial period?

At the end of the trial period, new partial blocks are placed under moratorium and a RfC should be held to conclusively determine the permanent usage of partial blocks (or an extension of the trial period). The follow-up RfC will also determine a partial blocking policy, if one has not been formed via consensus till then.

Support (trial)

1. Support Per my comment in the above proposal, I support a 3-month trial period. --qedk (t 桜 c) 22:07, 12 December 2019 (UTC)
2. Support I view a trial period of whatever requirements we come up with at a second rfc to be important. The trial isn't about experimenting with limited blocks the trial is about experimenting with our criteria for limited blocks and what that tells us about limited blocks usefulness on enwiki. We commit in advance, now, to nothing but trying out some criteria for limited blocks. If it turns out to be as dire as those opposing this tool fear, we will not have consensus to go forward permanently. Best, Barkeep49 (talk) 01:41, 13 December 2019 (UTC)
3. Of course, per above. SQL^{Query me!} 16:58, 13 December 2019 (UTC)
4. Second choice after no trial period. I get the feeling that the unscrupulous might adopt different standards of behavior during a trial period than they would otherwise, but I can't put my finger on why. EllenCT (talk) 00:08, 14 December 2019 (UTC)
5. per my statement in the previous section. Also can I recommend we not use "partial blocking policy" because my first thought was we would only develop part of the policy, when it's the full policy for partial blocks. Wug·a·po·des​ 05:41, 14 December 2019 (UTC)
6. Support as second choice. epicgenius (talk) 18:28, 24 December 2019 (UTC)
7. Support if we're going down this road - if we must create a full use-case option list in the middle of a busy RfC, then I need to reorder. If if runs without a trial then consensus to stop it has to be acquired. There is a standing pressure on wiki to stick with things even if they don't quite work. That should be avoided where possible, hence a trial Nosebagbear (talk) 18:25, 26 December 2019 (UTC)
8. Support but only if policy is at least rough-ed out first, otherwise oppose. DES ^(talk)_{DESiegel Contribs} 02:02, 29 December 2019 (UTC)
9. Support for same reasons as my general support, but it would be smart to see if it would actually work out in a trial period first before full rollout. DrewieStewie (talk) 20:13, 4 January 2020 (UTC)
10. Qualified support I prefer a trial period but do not think it is absolutely necessary. I also said "support" in the general question above. davidwr/(talk)/(contribs) 20:20, 8 January 2020 (UTC)

Oppose (trial)

1. Wait for follow-up RfC. I think a trial phase will probably be a good idea to bring up when we talk about implementing partial blocks in policy. However, my colleagues on the other side have brought up legitimate concerns, and I think we should do a follow-up RfC to craft a separate policy for partial blocks before we implement them. Rushing straight into a trial phase feels like a bad idea to me. Mz7 (talk) 22:26, 12 December 2019 (UTC)
2. No - we shouldn't experiment with new tools where the result of their use is preventing people from editing. Figure out how the tool is expected to be used first. After that happens then a trial most likely will be warranted, but "let's just see what happens" is a really bad approach to blocking editors. Ivanvector (^Talk/_Edits) 01:32, 13 December 2019 (UTC)
3. What Ivanvector said. Galobtter (pingó mió) 04:26, 13 December 2019 (UTC)
4. Oppose in part through Ivanvector. A trial period should be held to test the partial block, but after a follow-up RfC determines the rough framework for the limits of partial blocks. Administrators should not be given dangerous tools that affect many areas without guiding principles, especially for long periods of time – an effective trial period would take at least a month. UnnamedUser (talk) 04:38, 13 December 2019 (UTC)
5. Trial is code for “get people behind this and then we’ll be too lazy to work out the details and we’ll just bring it back because we got used to it without thinking about the details.” With WP:ACTRIAL we had actual, measurable statistics, a decade of support, and incontestable benefits. Even on projects where this has been implemented, it’s hardly received rave reviews and opposition still exists. A trial is just a way to get this through permanently without calling it that. TonyBallioni (talk) 05:07, 13 December 2019 (UTC)

   Remember WP:AFT? :) --Izno (talk) 05:29, 13 December 2019 (UTC)

6. Oppose per my comment above. We need policies for their use first. Vanamonde (Talk) 06:19, 13 December 2019 (UTC)
7. Above I supported deployment, here I Oppose automatic end / moratorium. Anyone can and should open any discussion or RFC without delay, as appropriate. There is no need to wait for a trial to end. On the other hand if serious issues do not arise then there is no point in an automatic moratorium. Alsee (talk) 17:45, 13 December 2019 (UTC)

   If it really turns out disastrous, then ending it would not be hard. Any RFC to that end would quickly garner consensus. If it fails to garner consensus, that means the community finds it useful, and is a valid reason for it to stay even if some don't want it. So there's no any burden shifting here. – Ammarpad (talk) 04:13, 14 December 2019 (UTC)

   The majority of supports (esp when factoring in neutrals) in the first proposal are opting for the 1) Use-case RfC, 2) Trial, 3) Permanent implementation RfC format. I'm not in favour of switching the first two. Nosebagbear (talk) 17:57, 13 December 2019 (UTC)

8. I do not really see a need for a trial. -- Dolotta (talk) 18:34, 13 December 2019 (UTC)
9. No. If you were around back then you may recall how trialing pending changes protection without firmly establishing (as this proposal also does not) exactly who is responsible for collecting, distributing, and evaluating the trial results led to literally like three years of drama. We can always have a second RFC if the tool seems not to work well for us, and turn it off then. Beeblebrox (talk) 00:04, 14 December 2019 (UTC)
10. Oppose I was originally in favor of a trial, but after thinking about it for a bit, the whole WP:ACTRIAL debacle is still far too fresh in my mind to support a trial for a tool that can be as contentious as Special:Block. If we're going to enable this tool, let's make sure that we get it right the first time. OhKayeSierra (talk) 00:18, 14 December 2019 (UTC)
11. No need for this, it'll do more harm that good. After partial blocks is enabled and actually put in use, then the community can assess that usage in a future RFC. This can happen whether there's a trial period or not. But it's even better if there's no trial period, as that's the timeframe we can see genuine issues and practical implications. In a trial period (much like a controlled condition; those who are going to abuse it, wikilawyer around and whatnot) will not to do that within the period since supposedly that period is being heavily monitored and that will mask the real issues. – Ammarpad (talk) 04:13, 14 December 2019 (UTC)
12. No, if they prove very problematic a new RfC to disable the function can be made - requiring another RfC to continue/move to permanent seems wasteful. — xaosflux ^Talk 17:08, 15 December 2019 (UTC)
13. Oppose I don’t see the need. --Malcolmxl5 (talk) 20:10, 15 December 2019 (UTC)
14. Oppose per my "very strong oppose" in the above section. Ivanvector (^Talk/_Edits) 16:24, 26 December 2019 (UTC)
15. Oppose - Too low stakes to warrant a trial. ~Swarm~ ^{sting} 02:19, 30 December 2019 (UTC)
16. Oppose per Mz7. --TheSandDoctor ^Talk 03:42, 5 January 2020 (UTC)
17. Oppose, just get on with it. Stifle (talk) 10:07, 6 January 2020 (UTC)

Neutral (trial)

You're right that if it fails majorly, then we don't need to wait out the trial, however automatic ends/moratoria are helpful because otherwise you need consensus to end it - it shifts the "burden of proof". Nosebagbear (talk) 17:56, 13 December 2019 (UTC)

Should partial blocks be used to enforce editing restrictions?

Consensus here will be a part of the new partial blocking policy.

Support (enforcement)

1. If an editing restriction is written in a way in which it can be 100% enforced by partial blocks (such as a page ban), then I see no reason not to do so pre-emptively. * Pppery * _{it has begun...} 18:25, 14 December 2019 (UTC)
2. Per Pppery. ~ ToBeFree (talk) 20:52, 14 December 2019 (UTC)
3. If the editing restriction has any ambit that can fall under partial blocks, it should be implemented using partial blocks (unless the consensus specifically requires otherwise) or else should stand as a ban. --qedk (t 桜 c) 21:18, 14 December 2019 (UTC)
4. For simpler / narrow editing restrictions. More complex / broad ones would be fairly difficult to manage with this tool. SQL^{Query me!} 18:05, 15 December 2019 (UTC)
5. Conditional support only after topic bans or voluntary agreements to abide by restrictions fail in a disruptive way; meaning, primarily only after previously agreed-to restrictions (imposed topic bans or voluntary agreements of the disputants) are violated in a way which actually has caused further complaints to admins or similar sorts of disruption. And like all such tools, preventative not punitive, which is to say, if someone threatens to violate their topic ban, let them bloviate all they want, but don't take restrictive action unless they actually do. And if they do, and their complainants don't care about the transgression, then by all means let it slide, as well within the spirit and letter of WP:IAR. EllenCT (talk) 23:12, 15 December 2019 (UTC)
6. Conditional support only if it is applied to future bans and restrictions, and not retroactively to old ones. Also, explicit language in the ban or restrictions outlining its use in the context of the ban would be useful. --Jayron32 16:13, 16 December 2019 (UTC)
7. A partial block may be preferable to a full block in some cases, e.g. someone persistently breaches editing restrictions on a particular page. --Malcolmxl5 (talk) 10:57, 19 December 2019 (UTC)
8. For simple blocks. And not to be used ex post facto. Captain Eek ^{Edits Ho Cap'n!}⚓ 07:47, 20 December 2019 (UTC)
9. Support, obviously. If we do enable them this is the most straightforward and obvious use-case, since it adds nothing beyond simpler mechanical enforcement for a form of restriction we already use. One small caveat is that we shouldn't change our existing editing restrictions policy just to suit the mechanics of partial blocks, at least not without much more discussion - they are one tool to enforce our current broader system of restrictions, not a replacement for it. --Aquillion (talk) 10:10, 22 December 2019 (UTC)
10. Support per my answer to the first question. epicgenius (talk) 18:28, 24 December 2019 (UTC)
11. Extremely conditional support - non-retroactive, not pre-emptive (overturning that would require a broader consensus), and only if the limited ban was written in such a way (e.g. a TBAN with the 5 pages actually disrupted page-banned). If a single one of those isn't viewed as inherent or supported by consensus, this should be viewed as a firm oppose. Nosebagbear (talk) 18:28, 26 December 2019 (UTC)
12. Limited support This should be an option, and be declared as part of the TBAN if it is to be used. Many TBANs are too broad to list all the pages involved, and would not be suited to this tool, and the community should always have the option not to use the tool. If a Tban is violated, a partial block might be sued on the page where this occurred, subject to policy yet to be agreed on. DES ^(talk)_{DESiegel Contribs} 02:07, 29 December 2019 (UTC)
13. Support - I don't see why partial blocks should not and could not be a tool in the toolbox for this straightforward purpose. ~Swarm~ ^{sting} 02:20, 30 December 2019 (UTC)
14. Support - Probably the most straightforward and uncontroversial uses of partial blocks that I can think of. Makes sense, although it won't work for all TBANS, and it's probably not a great idea to use them automatically whenever someone gets a TBAN. ThePlatypusofDoom (talk) 05:16, 2 January 2020 (UTC)
15. Conditional support - I think that partial blocks could be extremely useful to enforcing editing restrictions. However, I feel they should only be applied if the restrictions are specific to pages, not a topic (due to how broad topics can be), and they should not be used retroactively. --Rlin8 (☎·✎·📧) 06:15, 2 January 2020 (UTC)
16. Support Is a smart justification for partial blocks, if one has great contributions on one topic but is disruptive on another (not vandalism, that would be grounds for a full block), then a partial block is justifiable. DrewieStewie (talk) 20:15, 4 January 2020 (UTC)
17. Limited support. I echo what has been previously written by DESiegel, Jayron32, and SQL. --TheSandDoctor ^Talk 03:41, 5 January 2020 (UTC)
18. Support per Pippery. Stifle (talk) 10:08, 6 January 2020 (UTC)
19. Support but only on a case-by-case basis. In short, administrators should look for an alternative before using this tool for this purpose. Long version: If the tool enforced a ban without causing side-effects, it can be used but that doesn't mean it must be used or even that it should be used in a given case. If using the tool prevents a user from who would likely violate a ban from doing so, it probably should be used, otherwise it probably should not. This goes for existing blocks as well as this new proposed form of blocking. Also, remember that being blocked typically will cause unwanted side effects, such as changing a want-to-return-later-as-a-good-productive-editor into a to-heck-with-Wikipedia-I-will-find-another-hobby editor. davidwr/(talk)/(contribs) 20:33, 8 January 2020‎ (UTC)

Oppose (enforcement)

1. Worst use case. It will enable countless WikiLawyering, and the tool was not developed as a way of enforcing bans. TonyBallioni (talk) 22:22, 14 December 2019 (UTC)

   Also, if the wording really is as it is above, then I'm in opposed; I'm in the case-by-case neutral section above - however if this is going to be a "should be" rule, then I'm flat oppose because at the most I think this should be a "may be" rule. — xaosflux ^Talk 12:58, 26 December 2019 (UTC)

2. Oppose - highly impractical; users are very rarely banned from one individual page, which is all we can do with partial blocks. If multiblocks are implemented this may be worth revisiting, but in that case I don't see it being very practical to preemptively block someone from every conceivable page within a broader topic ban. Any block that relies on content or code on the page is an invitation for abuse. Ivanvector (^Talk/_Edits) 16:27, 26 December 2019 (UTC)

Neutral (enforcement)

• Only if practical (see also phab:T202673 for limitations).--GZWDer (talk) 21:40, 14 December 2019 (UTC)
• I think this needs to be described with more nuance than simply yes or no. We do not always premptively apply blocks to every editor with a site ban; a block might already be in place due to earlier disruption, or it might be held back as an option to enforce the ban if the editor violates it. I would want partial blocks to be used in a similar fashion. And as mentioned in other comments, not every case can practically be enforced with partial blocks. --RL0919 (talk) 22:03, 14 December 2019 (UTC)
• Doesn't seem very practical. Let's say an editor is topic banned from politics – there are too many pages, so we'd have to do this by category. Socks (including IPs) can easily remove categories, and we have no way of knowing the intent of an unexplained category removal. But I'd support if we'd find some way to fix this or it just doesn't become that much of a problem during the actual trial period. UnnamedUser (talk) 22:09, 14 December 2019 (UTC)

  UnnamedUser, Partial Blocks do not block by category. When the feature was in development, this was considered, but it was dropped due to overhead. SQL^{Query me!} 17:59, 15 December 2019 (UTC)

• Case-by-case, it really depends on the restriction. An example restriction against editing templates and modules could easily be enforced this way, but one on editing articles about orange things wouldn't be very useful. — xaosflux ^Talk 17:06, 15 December 2019 (UTC)

  Just to recap after reading more, I'm mostly in support of this if "should" were changed to "may". Should assumes that situations will best be handled this way, may leaves it open to more discretion. — xaosflux ^Talk 15:57, 9 January 2020 (UTC)

• I agree, more nuance is needed than this blanket yes/no. Case-by-case. – Levivich 20:46, 19 December 2019 (UTC)
• Should be left to discretion, but I'm generally opposed to it as a first line of resort. Wug·a·po·des​ 09:36, 24 December 2019 (UTC)

Discussion (enforcement)

While I agree that someone mouthing off shouldn't automatically be assumed to be ready to carry through with their stated intentions, note that waiting until someone has actually violated restrictions to impose a block is a reaction and thus actually a punitive action, albeit one that may also be a preventative one. I think if the editor's statement is credible, consideration for a preventative block is warranted. isaacl (talk) 23:39, 15 December 2019 (UTC)

If someone has already been topic banned and is making threats to violate that ban unless they are blocked, then I would agree. But not if they are just vowing to correct an alleged mistake on the topic at some point in the future. We hope that the dispute will resolve in the future, ideally alleviating the need for the topic ban, and we hope that happens before the hot-headed carry out their threats. If it is a new dispute without a topic ban in place, the admin should not assume that vowing to correct an alleged mistake will occur sooner than the dispute at the root of an agreement to abide by a voluntary restrictions has been resolved. I would prefer to give people making statements in the heat of an argument the benefit of the doubt that they will come to an amicable resolution with the other disputants before excluding them entirely. What are the costs and benefits? The costs are slight, and the benefits, psychologically, could be relatively enormous. EllenCT (talk) 00:31, 16 December 2019 (UTC)

As I said, I agree it shouldn't be assumed that editors will follow through on their statements, but I think the context should be considered, which includes past behaviour and the tenor of the statement. I don't think a block should necessarily be automatic even for credible statements, either, but I think it should be given consideration. isaacl (talk) 03:44, 16 December 2019 (UTC)

Should partial blocks be limited to community consensus only?

The alternative here is community consensus and administrator discretion. Consensus here will be a part of the new partial blocking policy.

Support (consensus required)

1. Community consensus is currently required to impose social editing restrictions equivalent to partial blocks. * Pppery * _{it has begun...} 21:02, 15 December 2019 (UTC)

Oppose (consensus required)

1. Partial blocks would be a nice alternative to full edit-warring blocks and should not require a large community discussion about the specific case. ~ ToBeFree (talk) 20:54, 14 December 2019 (UTC)
2. Oppose – no need for partial blocks if all they are is enforcing community-authorized sanctions. UnnamedUser (talk) 21:59, 14 December 2019 (UTC)
3. Oppose --qedk (t 桜 c) 08:36, 15 December 2019 (UTC)
4. No, but that doesn't mean there should be unbounded discretion either. — xaosflux ^Talk 17:03, 15 December 2019 (UTC)
5. Oppose Community consensus should arrive at guidelines and not be required for each individual case. --Malcolmxl5 (talk) 20:51, 15 December 2019 (UTC)
6. Oppose the need to litigate every use of admin tools is not useful or needed. --Jayron32 16:13, 16 December 2019 (UTC)
7. Oppose No different from any other block an admin might make. If an admin is mis-using the tools, for full or partial blocks, then that's a different issue althogether. Lugnuts ^{Fire Walk with Me} 18:41, 19 December 2019 (UTC)
8. Per above. – Levivich 20:47, 19 December 2019 (UTC)
9. Oppose This is a tool admins should be able to use like any other, and the point here is creating less community drama and bureaucracy, not more! Captain Eek ^{Edits Ho Cap'n!}⚓ 07:44, 20 December 2019 (UTC)
10. Oppose - more bureaucracy than it's worth. epicgenius (talk) 18:28, 24 December 2019 (UTC)
11. Oppose - don't muddy the waters between community sanctions and administrative tools. They're different beasts. Ivanvector (^Talk/_Edits) 16:30, 26 December 2019 (UTC)
12. Oppose No more than ordinary blocks are. If an admin sees someone continuing to editwar after warnings, or persisting in vandalism, that admin may now block withotu a noticeboard discussion. The same should apply for partial blocks. In thsoe cases where a community discussion would be required or expected before a full block, it should also be before a partial block. WP:ADMINACCT would apply. DES ^(talk)_{DESiegel Contribs} 02:12, 29 December 2019 (UTC)
13. Oppose - The community's discretion in issuing blocks is needed or warranted in probably less than .0001% of times blocking is applicable, and its mandate is unobtainable probably 50% of those times. A largely useless aspect in issuing blocks. ~Swarm~ ^{sting} 02:22, 30 December 2019 (UTC)
14. Oppose It should be at admin/policy discretion, informal consensus may even pop up before sanctions occur. Formal consensus isnt necessary, if problems arise it can then be peer reviewed. DrewieStewie (talk) 20:18, 4 January 2020 (UTC)
15. Oppose, when individual administrators are free to discretionally impose full blocks providing they can justify them, making partial blocks much harder to do just seems perverse. In a borderline situation, it simply means a disruptive user will just be full-blocked rather than the blocking admin jumping through a consensus hoop to partial-block them. ~ mazca ^talk 02:15, 5 January 2020 (UTC)
16. Oppose I have to agree with xaosflux and Swarm on this. My oppose is not to say that there should be unbounded discretion, but that this isn't the right way. --TheSandDoctor ^Talk 03:38, 5 January 2020 (UTC)
17. Oppose Piling on here. If we can trust administrators to have the discretion to put in a full block in accordance with policies we can trust them to do the same with partial blocks according to whatever policy we adopt. davidwr/(talk)/(contribs) 20:45, 8 January 2020 (UTC)

Neutral (consensus required)

1. Asking the community should not be required, but the community should certainly be able to overturn any such restrictions, and partially-blocked editors will be able to request such review whether on wiki or off. In the degenerate case where admins and the community disagree, the admins (the admin community, technically) has the authority; as should serve to prevent astroturfed filibustering from vetoing to preserve walled gardens such as homeopathy-related articles. EllenCT (talk) 23:19, 15 December 2019 (UTC)

   Community consensus supersedes in all cases, as is the case in normal blocks, as will be the case for partial blocks, don't see a particular distinction here. --qedk (t 桜 c) 21:20, 16 December 2019 (UTC)

Should partial blocks be applied to IP addresses only?

The alternative here is registered editors and IP addresses. Consensus here will be a part of the new partial blocking policy.

Support (IP addresses)

1. This should never be used on accounts if it happens. If you talk to people on other projects, the best use case is for IP blocks only. TonyBallioni (talk) 16:19, 15 December 2019 (UTC)
2. Per my comment above on the usefulness of this for IPs. Galobtter (pingó mió) 17:41, 15 December 2019 (UTC)
3. I'd be willing to accept this as a compromise solution. Due to the nature of IP addresses, a block on an IP address or IP address range may affect unrelated users, and partial blocks may be a way to reduce collateral damage in certain situations where disruption is not likely to spread to other articles. This view is unrelated to any sentiment about registered users being more valuable in some way than IP address contributions. Mz7 (talk) 01:38, 17 December 2019 (UTC)

Oppose (IP addresses)

1. Oppose. I cannot see any reason why we should limit the use of partial blocks in this way. --RL0919 (talk) 22:05, 14 December 2019 (UTC)
2. Oppose – edit warring partial blocks will be useful for registered users. UnnamedUser (talk) 00:17, 15 December 2019 (UTC)
3. Oppose --qedk (t 桜 c) 08:35, 15 December 2019 (UTC)
4. Oppose making a brightline rule here, though I think they would be most useful for IP's. — xaosflux ^Talk 17:01, 15 December 2019 (UTC)
5. I think the tool would be very useful for IP's, but I think it would also be useful for registered users. SQL^{Query me!} 18:06, 15 December 2019 (UTC)
6. Oppose We don’t treat unregistered editors any differently to registered editors. --Malcolmxl5 (talk) 20:53, 15 December 2019 (UTC)
7. Why should this be the case? * Pppery * _{it has begun...} 21:01, 15 December 2019 (UTC)
8. Nope, I believe this would defeat one of the purposes. EllenCT (talk) 23:24, 15 December 2019 (UTC)
9. Oppose although partial blocks will be useful to prevent disruption for IPs, I don't a reason why it has to be limited to IPs only. Dreamy Jazz 🎷 ^{talk to me | my contributions} 11:39, 16 December 2019 (UTC)
10. Oppose Why? --Jayron32 16:14, 16 December 2019 (UTC)
11. Oppose such limitation of a tool that may well be useful to stop registered users from edit-warring on one specific article. ~ ToBeFree (talk) 13:21, 17 December 2019 (UTC)
12. Oppose Right now it might be more focused on IP disruption, but should not be limited to IPs. Lugnuts ^{Fire Walk with Me} 18:42, 19 December 2019 (UTC)
13. Useful for both IPs and registered editors. – Levivich 20:48, 19 December 2019 (UTC)
14. Oppose Wikipedia is already unfriendly enough to IP's. No need to try to tip the balance further, by alienating and singling out a large group of editors. Plus, there are a lot of registered accounts I've run into where it could come in handy. Captain Eek ^{Edits Ho Cap'n!}⚓ 07:42, 20 December 2019 (UTC)
15. Oppose because then it wouldn't be very useful. Registered accounts can also cause localized disruption but be helpful elsewhere. epicgenius (talk) 18:28, 24 December 2019 (UTC)
16. Oppose - IPs are accounts too. Ivanvector (^Talk/_Edits) 16:30, 26 December 2019 (UTC)
17. Oppose I see no good reason for such a limitation. Indeed, I suspect this will be a more useful tool with registered accounts. DES ^(talk)_{DESiegel Contribs} 02:14, 29 December 2019 (UTC)
18. Oppose I am personally opposed to discrimination against IP users. ~Swarm~ ^{sting} 02:22, 30 December 2019 (UTC)
19. Oppose - A lot of edit warring comes from registered users, and restricting partial blocks to IPs will seriously hinder its usefulness. --Rlin8 (☎·✎·📧) 06:18, 2 January 2020 (UTC)
20. Oppose I can see many justifications to this policy being used on registered users and possibly admins too in extraordinary circumstances, they have every reason to be privy to that policy too. DrewieStewie (talk) 20:20, 4 January 2020 (UTC)
21. Oppose but as with any block, be aware of the "human/social" aspects of placing a block on someone, be it full or partial. See my comments elsewhere that basically discourage but allow the use of this proposed new tool. davidwr/(talk)/(contribs) 20:47, 8 January 2020 (UTC)

Can partial blocks be used for conditional unblocks against a full block?

Consensus here will be a part of the new partial blocking policy.

Support (conditional unblocks)

1. Sure, we usually let the blocked person "negotiate" all sorts of restrictions. — xaosflux ^Talk 17:02, 15 December 2019 (UTC)
2. I could see this being a useful tool at CAT:RFU in order to help return otherwise productive editors to the project. SQL^{Query me!} 18:03, 15 December 2019 (UTC)
3. Per xaosflux. --Malcolmxl5 (talk) 20:55, 15 December 2019 (UTC)
4. --qedk (t 桜 c) 21:22, 15 December 2019 (UTC)
5. Support this seems like one of the best possible uses. EllenCT (talk) 20:18, 16 December 2019 (UTC)
6. Support don't see a reason why not, it seems like a useful way of bringing back a user who was blocked for behaviour which warranted a long block (long enough that having unblock conditions, instead of just waiting for the block to expire, would make more sense) while helping to prevent the user from continuing the behaviour that lead to the block. Of course partial blocks may only be useful in certain circumstances, but if they help to bring back a otherwise helpful editor, then they are useful. I see that this as ramping down from a full block, which could be used to see if a full unblock is warranted. A partially blocked user can be easily fully blocked, and the issues which may have happened would not have affected the parts of the site which they were blocked from.

   One example I have is if an editor was blocked for serious issues occurring in mainspace, they could have a "trial period" using a partial block which blocks them from the mainspace. This allows them to still create and edit articles in the draft namespace and/or make suggestions on talk pages. Then after the "trial period" an administrator could review their contributions to see if the user can now be unpartially blocked. This would help to reduce the damage the user on trial could do as draft space and talk pages are viewed less by readers, and the user could still just be blocked again once the issues are noticed (as usual). It would still allow the user to show they have learnt their lesson (and so a block is no longer preventative). Dreamy Jazz 🎷 ^{talk to me | my contributions} 12:13, 16 December 2019 (UTC)

7. Support This seems a reasonable use. --Jayron32 16:15, 16 December 2019 (UTC)
8. Support: Realistic, positive use-case. ~ ToBeFree (talk) 13:23, 17 December 2019 (UTC)
9. You'd think this wouldn't be necessary, because anyone being unblocked would have taken feedback on board and thus could restrain themselves from violating a TBAN or ABAN condition without needing to be partially blocked. But I'm in favor of giving admin more tools in the toolkit to deal with disruption, so yes, it should be allowed in appropriate cases. – Levivich 20:51, 19 December 2019 (UTC)
10. Support Seems reasonable to me. Puddleglum ^2.0 16:15, 22 December 2019 (UTC)
11. Support as reasonable. epicgenius (talk) 18:28, 24 December 2019 (UTC)
12. Support - I can see cases where this is good, and would allow returning editors to dodge some of their accidental issues Nosebagbear (talk) 18:29, 26 December 2019 (UTC)
13. Support This nis a reasonable use case, a special case of editing restrictions. Like that case, specific policy should be devised before this is used. DES ^(talk)_{DESiegel Contribs} 02:15, 29 December 2019 (UTC)
14. Support a perfect tool to enforce conditional unblocks. ~Swarm~ ^{sting} 02:22, 30 December 2019 (UTC)
15. Support - Reasonable use that will help reduce disruption. ThePlatypusofDoom (talk) 05:20, 2 January 2020 (UTC)
16. Support it would be a great way of discontinuing disruption at a problematic topic while granting then the opportunity to constructively contribute elsewhere. Of course, this wouldnt be limited exclusively to article space and can be temporary or indefinite. DrewieStewie (talk) 20:22, 4 January 2020 (UTC)
17. Support per xaosflux and Swarm. --TheSandDoctor ^Talk 03:35, 5 January 2020 (UTC)
18. Support but I agree with Pppery in the "Oppose" section that this effectively duplicates "Enforcing editing restricitons" in the current policy. It also seems to be implied already in WP:CONDUNBLOCK should the main proposal pass. I am fine with this issue being reduced to nothing more than adding a statement to WP:CONDUNBLOCK that says that an unblock request may be conditioned on it being replaced with a different block that is strictly narrower in scope. Meaning, that one or more partial blocks can replace a full block, or one or more partial blocks can replace one or more partial blocks as long as the net result is that anything the editor could do before, he still can do. I would prefer to say that the duration of any resulting change cannot be longer than the existing duration but I see that this would be contrary to WP:UNBLOCK as it allows conditions to extend up to 1 year even if the block would expire sooner. I'll propose clarification on WT:Blocking policy. davidwr/(talk)/(contribs) 21:04, 8 January 2020 (UTC)

Oppose (conditional unblocks)

1. This effectively duplicates "Enforcing Editing restrictions" given current policy. * Pppery * _{it has begun...} 21:00, 15 December 2019 (UTC)

   @Pppery: Conditional unblocks are a subset of editing restrictions. Hence, hypothetically, if that proposal were to fail and this passes, that means only conditional unblocks would be eligible for partial blocks. --qedk (t 桜 c) 21:07, 15 December 2019 (UTC)

   I continue to oppose -- I see conditional unblocks as no different from other restrictions, so oppose them being special-cased. * Pppery * _{it has begun...} 21:09, 15 December 2019 (UTC)

2. Oppose per my comment under the enforcement straw poll. Ivanvector (^Talk/_Edits) 16:28, 26 December 2019 (UTC)

   Ivanvector, Commonly, at CAT:RFU, the issue we come across is User:BobsWidgets creating, or editing the page BobsWidgets. Often times, the way forward is to ask the editor what they plan to edit, and if it's just BobsWidgets, the answer to the unblock request is usually no. As someone that works the unblock queue, I could see this being a huge help for this type of unblock request, as well as simpler COI / UPE situations as well. SQL^{Query me!} 03:56, 27 December 2019 (UTC)

   @SQL: we can already solve that by create-protecting BobsWidgets, or semiprotect if it already exists. And from experience at SPI, whatever way you do it, if it's COI/UPE they'll just create Draft:BobsWidgets, or Bobs Widgets, Bob'sWidgets, Bob Widget Co, Bob Widget Company, Widgets (Bob), ... you get the idea. Partial blocks don't address this. The correct response, anyway, if all the editor wants to do is violate policy (by only editing contrary to conflict of interest or paid editing rules) is to leave them blocked. Ivanvector (^Talk/_Edits) 14:21, 27 December 2019 (UTC)

Possible use cases

During the lead up to this RfC, some of these potential use cases for partial blocks were suggested. If desired, we could host a follow-up RfC regarding whether to restrict the use of partial blocks solely to specific use cases like the ones suggested in this section.

• Edit warring: Allow administrators to apply partial blocks against users who are edit warring. Currently, if a user is edit warring, they may be site-blocked for at least 24 hours on a first offense. With partial blocks, a user could be blocked just from editing the specific article on which they were edit warring, which forces them to stop reverting and use other venues to resolve disputes. This is a less WP:BITEy and harsh sanction that achieves the same preventative goal.
• IPs/IP ranges: Allow partial blocks of IP addresses and IP address ranges for disruption that is targeted specifically at one article, where the disruption is not likely to spread to other articles. Many IP addresses and IP address ranges are shared by many people—as a result, blocking them from editing the entire site may result in collateral damage. With partial blocks, administrators could block shared IP addresses and IP address ranges from editing a specific article that is being targeted without affecting legitimate work from that IP on other articles.
• Recording and enforcing editing restrictions: Allow partial blocks as a means to record and enforce editing restrictions. Currently, the community can formally ban a user from editing specific topics and articles with sanctions like topic bans. These editing sanctions are typically recorded at Wikipedia:Editing restrictions, which is a large and rather unwieldy page to navigate. With partial blocks, administrators could have a means to record and enforce editing restrictions more easily. The key is that a partial block can act as a good record of the restriction—it would then be easy to check the logs to see if an editor is under sanctions or has been sanctioned before. For example, an editor topic-banned from editing BLPs may be partially blocked from the specific article(s) they were disrupting on, with a notation in the log that they are also banned from all BLPs. For another example, two editors that are interaction-banned could be partially blocked from editing each other's talk pages, with a notation in the log about the ban.

Please feel free to suggest other potential use cases you can imagine in this section. Mz7 (talk) 22:23, 1 August 2019 (UTC), last modified 20:37, 9 December 2019 (UTC)

• Namespace partial blocks can be temporarily used to stop an editor from editing in a specific namespace to enforce an editing restriction. For example, Main (Article) namespace pb can encourage a user to use talk pages to reach agreement instead of reverting. A pb of template namespace could restrict a user from making templates if that is a problem. A pb of Wikipedia namespace could encourage an editor to go back to editing articles instead of causing disruption on policy pages or noticeboards.

I added how Namespace partial blocks can be used to enforce an editing restriction. SPoore (WMF), Strategist, Community health initiative (talk) 00:59, 2 August 2019 (UTC)

• Enforcing topic bans and interaction bans: Currently, only full site bans can be enforced with a block; topic bans and interaction bans are only enforceable by trust. We can use the tool to enforce topic bans by blocking editing from groups of articles, thus preventing someone from skirting their ban, or sneaking around it, etc. It would require less active monitoring, and additional articles can be added as needed and when needed. --Jayron32 14:30, 12 December 2019 (UTC)
  • Currently the use of long-term partial block is limited because of phab:T202673.--GZWDer (talk) 21:42, 14 December 2019 (UTC)
    • That is a pretty serious restriction! But, I wonder if it doesn't address some of the Question 1 opposers' concerns. I'll have to think more. EllenCT (talk) 01:37, 16 December 2019 (UTC)
• Self requested (This suggestion was inspired by the long-forgotten Module:ATA, which I plan to TfD after this RfC is inevitably closed with consensus in favor). * Pppery * _{it has begun...} 01:39, 27 December 2019 (UTC)
• Enforcement of a request/demand by one editor that another editor not edit the first editor's user talk page. Thsi is already specifically permitted by policy, but could only be enforced now by a site-wide block. DES ^(talk)_{DESiegel Contribs} 02:18, 29 December 2019 (UTC)
• Looks like this has gone live on projects that didn't opt out (or aren't currently discussing the issue). Just linking to my comments elsewhere on the way it seems to work out after poking around a bit. GMG^talk 17:08, 7 January 2020 (UTC)

General discussion

Would it be possible to have a dedicated policy for partial blocks, rather than simply reusing the normal blocking policy? Some of the concerns laid out here could be addressed through a dedicated policy. Jo-Jo Eumerus (talk) 07:43, 12 December 2019 (UTC)

@Jo-Jo Eumerus: m:Partial block model policy. –MJL ‐Talk‐^☖ 13:28, 12 December 2019 (UTC)

In my view, that actually makes this already bad idea worse. We already have a blocking policy with clear principles. Additional bureaucracy and a policy that would likely be contradictory won’t help, especially as we know from other projects there are sysops who refuse to touch these for similar reasons to the ones I’ve expressed. There is a real danger that in normalizing this innovation if this passes beyond an extraordinary measure rarely used. TonyBallioni (talk) 13:45, 12 December 2019 (UTC)

We need to bear in mind that blocks are tools to attain objectives, and not an end goal in themselves. Blocks can be applied by administrators on their own initiative in order to prevent disruption. Editing restrictions (bans) can be placed by the community or by administrators for topic areas under discretionary sanctions, and blocks can be imposed to enforce these restrictions. Authorization to use partial blocks should serve these objectives. I think it would be better to integrate the choice of block into a unified policy. isaacl (talk) 22:28, 12 December 2019 (UTC)

• I do agree that, in addition to/at the same time as enacting the ability to enact partial blocks, we should add to the policy pages on blocks and bans to indicate how it is normally to be used. That may be no difference from existing policies on full blocks, or there may be some additional guidance needed restricting the use of the tool to certain situations, but regardless I can see many good uses for this tool, and we should have it. --Jayron32 14:27, 12 December 2019 (UTC)
• No rush, Work out how we plan to use it first, then decide if we want it, then turn it on (or not). It seems potentially useful, but everyone will have their own ideas about whether it should be used in any given case, so best approached cautiously. · · · Peter Southwood ^(talk): 06:31, 15 December 2019 (UTC)
• I started WP:PBN, the Partial Block Noticeboard to try to think through what it might look like. EllenCT (talk) 23:54, 15 December 2019 (UTC)

Brainstorming policies

Brainstorming some possible policy restrictions we could place on the use of partial blocks:

• Restrictions on type of disruptive behaviors to combat with the tool:
  • Edit warring only
  • IP/IP range blocks only
  • As a discretionary sanction in ArbCom-authorized DS topics only
  • By community consensus only against other behaviors
• Restrictions on who has authority to use the tool:
  • Any administrator at their discretion (i.e. current blocking policy)
  • Community consensus only (e.g. at WP:AN or WP:ANI)
• Advice on when a site-block would be better than a partial block:
  • A full site block is better for behavioral issues that have the potential to spread to other areas. For example, incivility should not be responded to with a partial block, even if it is confined to one topic area, because that speaks to a personal behavioral issue on the contributor's part that has the potential to spread to other areas. Another example is blatant vandalism for registered accounts or non-shared IP addresses.
  • In the same vein, a partial block is better for behavioral issues that are tied specifically to one article. An example I mentioned above is edit warring. Edit warring and breaking 3RR is sometimes done by accident, even by experienced users. Although we are already pretty lenient in unblocking edit warring users on promises not to continue reverting, a partial block is a more nuanced sanction that lets the user participate in talk page discussions without the need to get bogged down in the block appeal process.

Mz7 (talk) 22:48, 12 December 2019 (UTC)

Where applicable I suggest focusing on the restriction in question. For example, I would not say that partial blocks can be used as a discretionary sanction. Instead, I would say that partial blocks can be used to enforce page bans. isaacl (talk) 23:11, 12 December 2019 (UTC)

This discussion might more reasonably be in #Possible use cases as a subheader called #Discussion. Thanks for starting it. --Izno (talk) 00:29, 13 December 2019 (UTC)

---

If anyone wants to see partial blocks in action, let me know. As I said before, they're enabled on sco.wiki. I'll be happy to demonstrate for anyone. –MJL ‐Talk‐^☖ 16:15, 13 December 2019 (UTC)

MJL, I would. You said above they're 'a godsend.' I would like to hear more. --valereee (talk) 20:17, 13 December 2019 (UTC)

MJL, I'd be interested in seeing some success cases with partial blocks - e.g. when the editor is blocked from one article, but continues on productively on others. SQL^{Query me!} 21:24, 13 December 2019 (UTC)

@SQL: It's a smaller community, so that particular case has not come up yet. I am still looking at how I can apply it to combatting LTAs, but I wanted to discuss that with the other admins there first.
@Valereee: I may have been too hyperbolic because I'm really just excited about the options it has given me thus far. We have a single LTA (LTA 1) who uses an IP to spam nonsense on a set of titles. I plan on doing some wide-range of range blocks for some specific pages as a result. –MJL ‐Talk‐^☖ 23:18, 13 December 2019 (UTC)

• Just pointing out that while they're the same technical feature, the use on a project that does not really have an active user base vs. the use on a project as massive as en.wiki are going to be extremely different. TonyBallioni (talk) 13:06, 14 December 2019 (UTC)
• If you are an admin here and want to test the feature out on testwiki to learn more about it, feel free to drop me a note at testwiki:User talk:Xaosflux and I'll add temporary admin access for you there. — xaosflux ^Talk 13:16, 17 December 2019 (UTC)

Unintended consequences

Like any tool imagined by the thought police of Wikipedia, it WILL have unintended consequences. It WILL reduce the energy of activation to silence wrongthing. If an activist admin decides that a user like TRM is "not constructive" on a specific topic, the admin will silence the critical perspective of TRM to "allow discussion to advance". There doesn't seem to be any clear way to police the policemen that will use this tool, as current "unblock" avenues are already filled with cabal activists that pat eachother on their backs for eliminating what they themselves deem to be "hate". If you don't believe this scenario, just look at the outcome of wp:FRAM. Thoughtpolice ultimately won. 2601:602:9200:1310:F4DA:8BBE:77F8:A56E (talk) 20:16, 14 December 2019 (UTC)

Why can't an activist admin just normally block TRM, or any other user, for that reason? What's the difference in the risk? UnnamedUser (talk) 00:14, 15 December 2019 (UTC)

There are almost always unintended consequences to everything. Even to doing nothing. Life itself is an unintended consequence. · · · Peter Southwood ^(talk): 06:20, 15 December 2019 (UTC)

As such uses are logged, egregious examples can go through ordinary dispute resolution process, e.g. with the partially blocked complaining that the block was unjustified, and asking for community review. I've created WP:PBN, the Partial Blocks Noticeboard to help think about what that might look like. Frankly, I'm more in favor now than when I started it, but I still need to think about the one-block-at-a-time restriction of phab:T202673. EllenCT (talk) 23:32, 15 December 2019 (UTC)

@EllenCT: basically if you are partially blocked from one thing, another admin can add additional things you are also partially blocked from - but they will all have the same expiration date. See example log. — xaosflux ^Talk 03:49, 17 December 2019 (UTC)

Perfect, Xaosflux, then I'm fully in favor now as my !votes above, and hope you or someone starts the proposed policy page soon (or can this be done with WP:BP changes alone?) I predict it lowers drama by at least two deciANIs. EllenCT (talk) 20:03, 18 December 2019 (UTC)

WP:PB

Given the short size of Special:WhatLinksHere/Wikipedia:PB, can we please take WP:PB back from Wikiproject Bagpipes? WP:BAGPIPES is wide open and more appropriate for that level of usage. Plus those guys used to wake me up way too early. EllenCT (talk) 01:56, 16 December 2019 (UTC)

@EllenCT: If I recall correctly, JarrahTree was working on reviving it per MFD:WP:PB. JarrahTree, can we steal your WikiProject's shortcut? I'd be willing to offer WP:GHB for Great Highland Bagpipe as an alternative. –MJL ‐Talk‐^☖ 05:06, 17 December 2019 (UTC)

@EllenCT:  Done with special thanks to JarrahTree and WikiProject Bagpipes. –MJL ‐Talk‐^☖ 23:06, 19 December 2019 (UTC)

Yay! EllenCT (talk) 02:27, 26 December 2019 (UTC)

EllenCT / MJL, shouldn't this point to a policy or policy section, rather than the current RfC in the long term? ~ ToBeFree (talk) 21:56, 4 January 2020 (UTC)

@ToBeFree: Sometimes shortcuts used with the intention of changing the target. WP:MOSMAC2 is a good example of this; throughout its lifespan, it pointed to: here, here, and now here.
Basically, yes. ¯\_(ツ)_/¯ –MJL ‐Talk‐^☖ 22:19, 4 January 2020 (UTC)

MJL, okay; should we really advertise "WP:PB" in the header of this page if the intention is to change it later? That's my main concern then. ~ ToBeFree (talk) 22:26, 4 January 2020 (UTC)

@ToBeFree: If you have a concern with it, then I don't mind seeing it taken down for now. –MJL ‐Talk‐^☖ 22:29, 4 January 2020 (UTC)

I should have made more clear, perhaps even to myself, that this was my actual concern. Done, thanks for having obtained this perfect shortcut from the Bagpipes project. ~ ToBeFree (talk) 22:33, 4 January 2020 (UTC)

Moving forward

Hi. What happens with this RfC now, with it being open for about one month? I see a fair bit of support to do this, and it has been deployed on other wikis. I'm not too familar with the RfC process, so it's more a question about timescales. Thanks. Lugnuts ^{Fire Walk with Me} 09:01, 9 January 2020 (UTC)

Wikipedia:Requests for comment#Duration says there is no time limit. A "raw count" (Wikipedia is NOT a vote!) would seem to indicate that it's clear consensus has been reached or will not be reached for each issue. On the other hand, the fact that there are recent replies suggests that the discussion has not "run its course" so further time should be allowed. In any case, the closer should carefully read all comments since some of the "supports" are conditional and various supporters' conditions might mean there is only a consensus for a limited version of the stated proposal or if the conditions are mutually exclusive, there might not be a consensus at all yet. I say this NOT having read the comments yet. My recommendation: Wait until we have at least half a week with no discussion that is anything other than strengthening existing positions on each issue, then close it. No need to keep the discussion open if the only comments we are getting amount to "pile on support/oppose" comments. At the earliest, this would be 3 and a half days from 20:20, 8 January 2020 (I supported an item headed for defeat). If we get to 30 days and discussion is still going on, we can look at things like "is consensus or lack of it so clear that continuing to accept comments would just waste time or is it weak enough that further discussion is needed?" or other justifications to close off debate or relist the RfC. Again, this is just a recommendation. davidwr/(talk)/(contribs) 15:42, 9 January 2020 (UTC) striking and replacing with new comment below, but striking instead of replacing-in-place since someone replied to it. davidwr/(talk)/(contribs) 15:50, 9 January 2020 (UTC)

Well said by Davidwr - my watchlist keeps pinging pretty frequently, so it's not even a drip-active thread. I do feel for the closers - the changes in the format a week in mean that the number of conditionals sky-rocketed. Nosebagbear (talk) 15:45, 9 January 2020 (UTC)

I do not understand what you meant by "the changes in the format a week in". Please clarify. davidwr/(talk)/(contribs) 15:52, 9 January 2020 (UTC)

Wikipedia:Requests for comment#Duration says there is no time limit. A "raw count" (Wikipedia is NOT a vote!) would seem to indicate that it's clear consensus has been reached or will not be reached for each issue. On the other hand, the fact that there are recent replies suggests that the discussion has not "run its course" so further time should be allowed. In any case, the closer should carefully read all comments since some of the "supports" are conditional and various supporters' conditions might mean there is only a consensus for a limited version of the stated proposal or if the conditions are mutually exclusive, there might not be a consensus at all yet. I say this NOT having read the comments yet. We are getting very close to 30 days and I just made my comments yesterday, so there's no harm in waiting to 30 days. The first actual support/oppose was made on 05:45, 12 December 2019. davidwr/(talk)/(contribs) 15:50, 9 January 2020 (UTC)