Wikipedia talk:Requests for comment/Partial blocks

Hello all, Development of partial blocks is at a stable place now and is deployed on most large and medium size wikis, all Wikivoyage, all Wikisource, and all Wiktionary with plans to deploy to most small wikis over the next few weeks. So, I want to circle back around to English Wikipedia to see if there is interest in starting the Rfc now.

There is now a Partial block model policy on Meta adapted from the policies written by a few local language wikis. Of note, Dutch Wikipedia has an arbcom and they have partial block as one additional method to enforce an arbcom sanction in their policy.

I know that adding partial blocks to English Wikipedia is complicated since it already has the Editing Restrictions that are commonly used. But there are common ways that pb are being used on most other wikis now that could be a place to start. @Ruthven: added some ways that partial blocks is used on Italian Wikipedia to the Partial blocks use case examples page on Meta.

Let me know if you want more information. SPoore (WMF), Strategist, Community health initiative (talk) 17:20, 9 December 2019 (UTC)[reply]

Certainly I'd be game to progress with it. A straight RfC with all the things that might want to be considered is asking for chaos, however. As mentioned in the discussions on this, something similar to how EC was handled is perhaps best. @SPoore (WMF):, do you have any feedback on how non-technical execution has gone for those wikis that were early adopters? E.g. Do people feel it's reduced their overall indef blocks, or are they doing as many indefs, along with a bunch of partials? Nosebagbear (talk) 18:36, 9 December 2019 (UTC)[reply]

@Nosebagbear: It is hard to say. My observation is that it is being used in different way by different admins with different results depending on the use. And some admins are using it to stop collateral damage that is more likely to happen with a full site block. With those the length of the block can be longer so that muddies the water when evaluating the length of blocks. The volume of pb on enwp has the potential to be much larger and the results will be more obvious, too. SPoore (WMF), Strategist, Community health initiative (talk) 20:49, 9 December 2019 (UTC)[reply]

@Nosebagbear and SPoore (WMF): Yes, it has been long enough. I think the best way to do this would be to approach it in three options: support, follow-up RfC, and oppose. I've updated the main RfC page with my idea. Mz7 (talk) 19:48, 9 December 2019 (UTC)[reply]

@Mz7: - your support definition is a bit ambiguous. It sort of makes it sound like Admins can use partial blocks as they wish (or at least DS-style) - whereas logically, at a minimum they should be under the same limitations as indefs are. You then allude more to that viewpoint by the phrasing of the follow-up RfC option, but I'd say it's worth clarifying Nosebagbear (talk) 20:22, 9 December 2019 (UTC)[reply]

@Nosebagbear: Hmm, do you have any suggestions for how specifically to reword that part? Mz7 (talk) 20:25, 9 December 2019 (UTC)[reply]

@Mz7:, how about We should enable partial blocks immediately. They may be both applied and appealed in the same fashion as other blocks/limited bans may be (whether that be under the standard Blocking Policy, Community Bans, Discretionary Sanctions, or as an ARBCOM remedy, as appropriate), to the maximum capabilities enabled by the tool.? Nosebagbear (talk) 20:50, 9 December 2019 (UTC)[reply]

I am more confused by this alternative wording than the original statement that's presently there (They may be applied by administrators and appealed similar to full-site blocks under the blocking policy.) Best, Barkeep49 (talk) 02:32, 10 December 2019 (UTC)[reply]

Full disclosure that I'm opposed to this: I think option 2 should be removed. I've done follow-up RfCs as options before, and they're best used when there's likely a pre-existing consensus on something, but past proposals have failed because the specifics can never get hashed out. It's a way to gauge the principles and then establish policy.
Here, that wouldn't be the case. We already have a blocking policy in place that the new tools would have to follow. It is long established and has principles, and we wouldn't be starting from scratch. Any changes could be proposed as changes to that policy. The question really is: do we want partial blocks, yes or no. If the answer is yes, any changes needed to policy would require an RfC anyway so option 2 is redundant. If the answer is no, then we shouldn't even be having a second RfC.
Having a middle option for something that would be as massively culture changing (in a negative way, in my view) as partial blocks on en.wiki should have a neutral up or down question which would allow people to think about the possible impacts of this policy directly without supporting something that likely will result in many proposals for a policy that won't address the concerns they may have had. TonyBallioni (talk) 04:12, 12 December 2019 (UTC)[reply]

Although I disagree with TonyBallioni on the merits, I've been thinking over this and have been feeling that the yes/no structure might be the better way forward after all, so I've switched back to it. I don't think option 2 as I had it before is "redundant"—it is there as an option for editors who don't agree that partial blocks should be applied under the same degree of discretion that the blocking policy currently affords site-wide blocks. However, in a yes/no structure, I think we could simplify the question by focusing on whether we want partial blocks. I've included a note in the RfC question saying, If needed, a follow-up RfC could be held ..., the idea being that the eventual closer of the RfC could recommend one at their discretion. Mz7 (talk) 04:28, 12 December 2019 (UTC)[reply]

I think even suggesting a follow-up RfC in the question isn't neutral: that pre-suggests it should be held, and shapes the question towards implementation rather than whether or not people support this. My reason for thinking the question of a follow-up RfC is redundant is that if people want to change it from the blocking policy as is, we'd have to have an RfC anyway. If the answer here is "yes" there likely will be a second RfC, so it's better to just focus on the question of whether people are fine with this extension. TonyBallioni (talk) 04:33, 12 December 2019 (UTC)[reply]

I'd say that would inappropriately polarize the issue. If there are editors who would support partial blocks, but only in a restricted form (e.g. against edit warring only), then I want to make clear that that is possible and it's not all or nothing. Mz7 (talk) 05:42, 12 December 2019 (UTC)[reply]

No, that's misleading editors who would otherwise oppose over a solution that would not solve their problems. The only benefit is it is designed to get more support, which is why it is inappropriate in my view. TonyBallioni (talk) 05:53, 12 December 2019 (UTC)[reply]

Admins vs non-admins

Okay, this is going to keep bothering me if I don't say anything.

Current Tally for Question 1
	Support	Neutral	Oppose
Non-admins	11	2	0
Admins	6	1	7

Thus far, the only individuals seriously suggesting this will lead to a massive expansion of the scope of administrator power have been... well admins. You would think the group of people who are most vulnerable in that event would express the same concern, so why haven't they?
Things just seemed really reversed. –MJL ‐Talk‐^☖ 04:58, 13 December 2019 (UTC)[reply]

I'm not asking to argue. I'm genuinely asking. Has this kind of thing happened before with previous discussions concerning the role of admins on the project? –MJL ‐Talk‐^☖ 05:00, 13 December 2019 (UTC)[reply]

It is rather interesting that every opposer so far is an admin. Certainly undercuts the notion of admins being power hungry. Or maybe people think partial blocks will mean less "full" blocks from admins? Galobtter (pingó mió) 05:52, 13 December 2019 (UTC)[reply]

It's almost as if stereotypes are usually wrong... Jo-Jo Eumerus (talk) 07:09, 13 December 2019 (UTC)[reply]

There was a similar divide between sysops and non-sysops at Wikipedia:DESYSOP2019 and RESYSOP2019 part 1. I think this provides an interesting data point in contrast to those suggesting new possible interpretations for why there is such a divide between the two groups. Best, Barkeep49 (talk) 15:57, 13 December 2019 (UTC)[reply]

Just some good old-fashioned dialectics here. –MJL ‐Talk‐^☖ 16:11, 13 December 2019 (UTC)[reply]

MJL, It's probably a little too early for numbers to be terribly meaningful. FWIW. the average edit count for supporters is 99294, oppose is 68468, and neutral is 18206. SQL ^{Query me!} 17:12, 13 December 2019 (UTC)[reply]

SQL, that isn't a great metric to go by. The avg edit count for supporters is so high because of Lugnuts' million+ edits. If you leave out Lugnuts, the avg edit count for supporters comes down drastically to 44,204 (at the moment). SD0001 (talk) 16:28, 14 December 2019 (UTC)[reply]

SD0001, Neither is admin vs non-admin here, especially so very early. It's interesting, but that's about it. SQL ^{Query me!} 16:33, 14 December 2019 (UTC)[reply]

Median is probably more useful of a measure Galobtter (pingó mió) 18:35, 14 December 2019 (UTC)[reply]

I almost said this, but removing an obvious and extreme outlier is also a valid approach. --Izno (talk) 18:49, 14 December 2019 (UTC)[reply]

Tally as of 09/01/20 for Question 1
	Support	Neutral	Oppose
Non-admins	33	1	4
Admins	19	2	11

So the admins are definitely more unsure about it - interestingly, it seems it's a case of lots of For and Against think it could/will come with some problems in implementation, but more Admins want to see more evidence, use-cases, policy etc etc before it's introduced. Nosebagbear (talk) 16:01, 9 January 2020 (UTC)[reply]

Discussion prompt added to WT:Blocking policy

I added a "think about this now, for discussion later" section Suggested changed to Blocking Policy Conditional unblock and Enforcing bans to Wikipedia Talk:Blocking policy, as a sub-section of Mz7's section Request for comment on partial blocks". Again, this is just so people start thinking about this now since it looks like Partial Blocks will be a reality in some form or another in the next few months or maybe even weeks. davidwr/(talk)/(contribs) 22:25, 8 January 2020 (UTC)[reply]

@Davidwr, SQL, Nosebagbear, MJL, Galobtter, Jo-Jo Eumerus, TonyBallioni, Mz7, Barkeep49, and Izno: Pinging talkpage contributors if anyone is interested to make suitable changes to the WP:Partial blocks draft proposal. I've tried to keep it as simple as possible since the new policy should supplement BLOCKPOL ideally. --qedk (t 桜 c) 17:28, 11 January 2020 (UTC)[reply]
@SD0001: --qedk (t 桜 c) 17:28, 11 January 2020 (UTC)[reply]
QEDK, I'm a big fan of referencing where authority for policy statements came from and did some changes around that so that when there are further modifications and additions/changes down the road we can look back to the source. Best, Barkeep49 (talk) 20:54, 11 January 2020 (UTC)[reply]

I don't think we need a Partial blocks policy unless there are differences between it and the policy for sitewide blocks. As far as I can tell, the current WP:Partial blocks page mostly repeats what is in WP:BLOCK, so all it creates is potential for discrepancies between policy pages. The small amount of info on the capabilities of partial blocks can be in a information page/incorporated into WP:BLOCK. Galobtter (pingó mió) 05:35, 12 January 2020 (UTC)[reply]
Although, a lot of WP:BLOCK would not apply to partial blocks which may call for a dedicated and supplemental policy, I suppose. I think the thing that needs the most thought is appealing. WP:ANI isn't really the place for appealing restrictions or things like that - WP:AN is - but bringing every partial block appeal to AN seems a bit much since no requirement of community consensus is needed to unblock. We might want to stick with {{unblock}} on user talk for partial blocks. Galobtter (pingó mió) 05:47, 12 January 2020 (UTC)[reply]

I agree; as I discussed in the RfC, I believe it is best to integrate the option of using partial blocks into the existing blocking policy. isaacl (talk) 06:58, 12 January 2020 (UTC)[reply]
@Galobtter: I mainly did it due to me stating the question as "consensus formed here will be part of the new partial blocking policy". Having a CREEP-less supplement to BLOCKPOL is more ideal than having minor additions to BLOCKPOL that may or may not be read by administrators (see current ArbCom case). Furthermore, the ANI thing is taken from BLOCKPOL itself, I do not want to make assertions as to the correct place when a de-facto option exists. --qedk (t 桜 c) 15:56, 12 January 2020 (UTC)[reply]
To me, it's like issuing release notes for a new software version without updating the main documentation to integrate the changes into the existing workflow help pages. As time moves on from the immediate adoption of partial blocks, new editors join the project, and memories fade from current editors, I think having the partial blocks information contained with the same umbrella set of principles in the blocking policy is highly desirable. isaacl (talk) 18:10, 12 January 2020 (UTC)[reply]
I agree with this. Best, Barkeep49 (talk) 21:27, 12 January 2020 (UTC)[reply]

If you ask me, we should say that partial blocks should only be used to enforce editing restrictions only when the problem is limited to an exact set of pages. Otherwise we'll see partially blocked editors making prohibited edits in nonblocked pages; a partial block cannot be "broadly construed" by the software. Jo-Jo Eumerus (talk) 12:04, 12 January 2020 (UTC)[reply]

With all due respect to QEDK and others, I think the best thing to do is to incorporate it into the existing blocking policy and put it all in one document. Granted, most of the changes should be in their own new section, #Partial blocks, but there will need to be some tweaks to existing sections. Why? Because they are so closely related that almost everyone reading the policy about full blocks should also be reading the policy about partial blocks. Having separate documents makes this less likely. I'm okay for having these changed drafted as a separate document, but the two documents will need to be merged once the draft stage is over. davidwr/(talk)/(contribs) 17:24, 13 January 2020 (UTC)[reply]

@Davidwr: I say, we should respect the consensus. The consensus asked for a new partial blocking policy, incorporating it into a CREEP-addled BLOCKPOL is not ideal, that is my opinion. The current BLOCKPOL is a 48 KB wall of text and most people aren't going to get to the policy they are looking for if all we add is partial blocking tid-bits to existing sections. It is already a mess as-is. --qedk (t 桜 c) 17:55, 13 January 2020 (UTC)[reply]

Header

Admins vs non-admins

Discussion prompt added to WT:Blocking policy