The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

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) reply

   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) reply

   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) reply

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) reply

   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) reply

   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) reply

   @ 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) reply

   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) reply

   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) reply

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) reply

   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) reply

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) reply
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) reply
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) reply
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) reply

   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) reply

   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) reply

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) reply
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. -- Jayron 32 14:24, 12 December 2019 (UTC) reply
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) reply

    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. -- Jayron 32 15:06, 12 December 2019 (UTC) reply

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) reply
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) reply
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) reply
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) reply

    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) reply

15. Support per above, with a followup RfC to determine the associated policy. - FASTILY 20:20, 12 December 2019 (UTC) reply
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) reply
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) reply
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) reply
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) reply
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) reply
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) reply
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) reply
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) reply
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) reply
25. – Leviv ich 03:37, 14 December 2019 (UTC) reply
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) reply
27. Support – They work very well in the German Wikipedia. -- Count Count ( talk) 19:53, 14 December 2019 (UTC) reply
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) reply
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) reply
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) reply
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) reply
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) reply

    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) reply

33. Support A long overdue useful tool that would make blocking less punitive and more preventative of disruption.-- Deep fried okra 05:11, 17 December 2019 (UTC) reply
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) reply
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) reply
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) reply
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) reply
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. – Tera tix ₵ 05:49, 28 December 2019 (UTC) reply
39. Support. Partial blocks are a necessity for enforcement of topic and namespace bans. | abequinn ^fourteen 23:01, 28 December 2019 (UTC) reply
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) reply
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) reply
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) reply
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) reply
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) reply
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) reply
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) reply
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) reply
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) reply
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) reply
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) reply
51. Support, more tools are better than fewer tools. Stifle ( talk) 10:07, 6 January 2020 (UTC) reply
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) reply
53. Support feel that Partial block is definately a better option than a full block which is a last resort .Now it is tenored editors who have contributed constructively we are dealing with with a partial block they cab constructively contribute elsewhere. Pharaoh of the Wizards ( talk) 11:46, 10 January 2020 (UTC) reply
54. Support I find the support reasons more convincing than the oppose arguments. — Ched ( talk) 04:29, 11 January 2020 (UTC) reply

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) reply

   @ 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) reply

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) reply
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) reply
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) reply

   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. -- Jayron 32 19:11, 12 December 2019 (UTC) reply

   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) reply

   @ 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) reply

   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) reply

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) reply

   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. -- Jayron 32 19:14, 12 December 2019 (UTC) reply

   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) reply

   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) reply

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

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) reply
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) reply
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) reply
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) reply
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) reply
11. Oppose, basically as per Tony and Galobtter. GAB ^gab 16:12, 17 December 2019 (UTC) reply
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) reply
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) reply
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) reply
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) reply
16. Oppose--see User_talk:Oldstone_James#Notice_that_you_are_now_subject_to_a_community_editing_restriction as an example of how such blocks are used for censorship. Even the user who blocked this person, when confronted with the fact this was censorship, stated "that I don't necessarily reject" in response. Moreover, for context, the editor being blocked identifies as a "Jewish atheist" rather than a religious fundamentalist. He was blocked after asking for very minor changes on a religious topic article which would help represent the religious side's position.-- Epiphyllumlover ( talk) 01:29, 11 January 2020 (UTC) reply

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) reply
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) reply

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) reply

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

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) reply
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) reply
3. Of course, per above. SQL ^{Query me!} 16:58, 13 December 2019 (UTC) reply
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) reply
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) reply
6. Support as second choice. epicgenius ( talk) 18:28, 24 December 2019 (UTC) reply
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) reply
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) reply
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) reply
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) reply

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) reply
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) reply
3. What Ivanvector said. Galobtter ( pingó mió) 04:26, 13 December 2019 (UTC) reply
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) reply
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) reply

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

6. Oppose per my comment above. We need policies for their use first. Vanamonde ( Talk) 06:19, 13 December 2019 (UTC) reply
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) reply

   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) reply

   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) reply

8. I do not really see a need for a trial. -- Dolotta ( talk) 18:34, 13 December 2019 (UTC) reply
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) reply
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) reply
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) reply
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) reply
13. Oppose I don’t see the need. -- Malcolmxl5 ( talk) 20:10, 15 December 2019 (UTC) reply
14. Oppose per my "very strong oppose" in the above section. Ivanvector ( ^Talk/ _Edits) 16:24, 26 December 2019 (UTC) reply
15. Oppose - Too low stakes to warrant a trial. ~Swarm~ ^{sting} 02:19, 30 December 2019 (UTC) reply
16. Oppose per Mz7. -- TheSandDoctor ^Talk 03:42, 5 January 2020 (UTC) reply
17. Oppose, just get on with it. Stifle ( talk) 10:07, 6 January 2020 (UTC) reply

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) reply

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

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) reply
2. Per Pppery. ~ ToBeFree ( talk) 20:52, 14 December 2019 (UTC) reply
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) reply
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) reply
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) reply
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. -- Jayron 32 16:13, 16 December 2019 (UTC) reply
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) reply
8. For simple blocks. And not to be used ex post facto. Captain Eek ^{Edits Ho Cap'n!} ⚓ 07:47, 20 December 2019 (UTC) reply
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) reply
10. Support per my answer to the first question. epicgenius ( talk) 18:28, 24 December 2019 (UTC) reply
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) reply
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) reply
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) reply
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) reply
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) reply
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) reply
17. Limited support. I echo what has been previously written by DESiegel, Jayron32, and SQL. -- TheSandDoctor ^Talk 03:41, 5 January 2020 (UTC) reply
18. Support per Pippery. Stifle ( talk) 10:08, 6 January 2020 (UTC) reply
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) reply

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) reply

   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) reply

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) reply

Neutral (enforcement)

• Only if practical (see also phab:T202673 for limitations).-- GZWDer ( talk) 21:40, 14 December 2019 (UTC) reply
• 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) reply
• 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) reply

  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) reply

• 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) reply

  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) reply

• I agree, more nuance is needed than this blanket yes/no. Case-by-case. – Leviv ich 20:46, 19 December 2019 (UTC) reply
• 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) reply

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) reply

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) reply

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) reply

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

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) reply

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) reply
2. Oppose – no need for partial blocks if all they are is enforcing community-authorized sanctions. UnnamedUser ( talk) 21:59, 14 December 2019 (UTC) reply
3. Oppose -- qedk ( t 桜 c) 08:36, 15 December 2019 (UTC) reply
4. No, but that doesn't mean there should be unbounded discretion either. — xaosflux ^Talk 17:03, 15 December 2019 (UTC) reply
5. Oppose Community consensus should arrive at guidelines and not be required for each individual case. -- Malcolmxl5 ( talk) 20:51, 15 December 2019 (UTC) reply
6. Oppose the need to litigate every use of admin tools is not useful or needed. -- Jayron 32 16:13, 16 December 2019 (UTC) reply
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) reply
8. Per above. – Leviv ich 20:47, 19 December 2019 (UTC) reply
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) reply
10. Oppose - more bureaucracy than it's worth. epicgenius ( talk) 18:28, 24 December 2019 (UTC) reply
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) reply
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) reply
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) reply
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) reply
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) reply
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) reply
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) reply

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) reply

   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) reply

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

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) reply
2. Per my comment above on the usefulness of this for IPs. Galobtter ( pingó mió) 17:41, 15 December 2019 (UTC) reply
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) reply

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) reply
2. Oppose – edit warring partial blocks will be useful for registered users. UnnamedUser ( talk) 00:17, 15 December 2019 (UTC) reply
3. Oppose -- qedk ( t 桜 c) 08:35, 15 December 2019 (UTC) reply
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) reply
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) reply
6. Oppose We don’t treat unregistered editors any differently to registered editors. -- Malcolmxl5 ( talk) 20:53, 15 December 2019 (UTC) reply
7. Why should this be the case? * Pppery * _{it has begun...} 21:01, 15 December 2019 (UTC) reply
8. Nope, I believe this would defeat one of the purposes. EllenCT ( talk) 23:24, 15 December 2019 (UTC) reply
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) reply
10. Oppose Why? -- Jayron 32 16:14, 16 December 2019 (UTC) reply
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) reply
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) reply
13. Useful for both IPs and registered editors. – Leviv ich 20:48, 19 December 2019 (UTC) reply
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) reply
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) reply
16. Oppose - IPs are accounts too. Ivanvector ( ^Talk/ _Edits) 16:30, 26 December 2019 (UTC) reply
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) reply
18. Oppose I am personally opposed to discrimination against IP users. ~Swarm~ ^{sting} 02:22, 30 December 2019 (UTC) reply
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) reply
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) reply
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) reply

Neutral (IP addresses)

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

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) reply
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) reply
3. Per xaosflux. -- Malcolmxl5 ( talk) 20:55, 15 December 2019 (UTC) reply
4. -- qedk ( t 桜 c) 21:22, 15 December 2019 (UTC) reply
5. Support this seems like one of the best possible uses. EllenCT ( talk) 20:18, 16 December 2019 (UTC) reply
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) reply

7. Support This seems a reasonable use. -- Jayron 32 16:15, 16 December 2019 (UTC) reply
8. Support: Realistic, positive use-case. ~ ToBeFree ( talk) 13:23, 17 December 2019 (UTC) reply
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. – Leviv ich 20:51, 19 December 2019 (UTC) reply
10. Support Seems reasonable to me. Puddleglum ^2.0 16:15, 22 December 2019 (UTC) reply
11. Support as reasonable. epicgenius ( talk) 18:28, 24 December 2019 (UTC) reply
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) reply
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) reply
14. Support a perfect tool to enforce conditional unblocks. ~Swarm~ ^{sting} 02:22, 30 December 2019 (UTC) reply
15. Support - Reasonable use that will help reduce disruption. ThePlatypusofDoom (talk) 05:20, 2 January 2020 (UTC) reply
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) reply
17. Support per xaosflux and Swarm. -- TheSandDoctor ^Talk 03:35, 5 January 2020 (UTC) reply
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) reply
19. Support feel that Partial block is definately a better option than a full block which is a last resort .Now it is tenored editors who have contributed constructively we are dealing with with a partial block they cab constructively contribute elsewhere. Pharaoh of the Wizards ( talk) 11:50, 10 January 2020 (UTC) reply

Oppose (conditional unblocks)

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

   @ 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) reply

   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) reply

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

   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) reply

   @ 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) reply

Neutral (conditional unblocks)