Talk:Community health initiative/Partial blocks/Archive2

Criticizing the "one block per user" idea

Imagine a user is indef blocked from editing in Wikipedia namespace, because of a history of disruptive edits in that namespace. Then that user insults someone else on their talk page, so I decide to block them everywhere for 1 week. I go ahead and change the block settings accordingly. At the end of the one week, the user will be unblocked everywhere.

This is an important side effect of the "one block per user" idea, which is part of this proposal. Instead, we should allow for multiple blocks per user. That way, I would add a *new* one-week block for all namespaces, and at the end of it only that block will expire, while the other namespace-specific indef block will continue to exist. Huji (talk) 19:52, 5 August 2018 (UTC)

+1 IKhitron (talk) 21:14, 5 August 2018 (UTC)

+1 This something that we are aware of and know it needs to be addressed. Because blocking is an important tool on all wikis we plan to do testing on one or a few volunteer wikis with the major phases phases. This is first before introduced on all wiki. So, it will developed and introduced in phases. Soon, Trevor or me will post with the steps or phases of development. SPoore (WMF) (talk) , Trust and Safety Specialist, Community health initiative (talk) 18:01, 7 August 2018 (UTC)

Hi everyone, I’m Trevor, the product manager on this Partial Blocks feature. It appears that most feedback we’re receiving at this stage in the project is about one hypothetical — yet entirely likely — workaround a malicious user could exploit to their advantage: a user using a temporary sitewide block to erase (and therefore evade) an indefinite partial block. This could be resolved with manual solutions (e.g. calendars and reminders to reinstate the partial block) but this is inconvenient and interruptive to your workflows and prone to human error. It’s clear that we need to determine a solution to prevent this abuse before Partial Blocks releases to most wikis. There are a few ways to do this and this can get pretty complicated, please help me determine which system we should build:

Option 1 - Re-blocks

Description: If an admin escalates a partial block to a sitewide block and the expiration date for the sitewide block is shorter than the previous partial block, the admin should have an option for the block to revert to the previous partial block parameters when the sitewide block expires.

Example: An admin blocks User:Apples from editing the page Argentina for 9 months. The same day, an admin modifies the block to Argentina and Bahamas for 8 months. The same day an admin blocks the user from the entire site for 7 months. After 7 months, User:Apples would be blocked from Argentina and Bahamas for 1 more month, after which the partial block would be entirely expired.

This change would only require adding one additional option into the Special:Block UI when a block is being modified.

Option 2 - Multi-blocks

Description: Admins should be able to set different expirations for different elements of a block.

Example: An admin could block User:Bananas from editing Argon for 9 months, Boron for 8 months, and sitewide for 7 months. After 7 months, the user would be blocked from Argon and Boron and after 1 more month the user would be blocked only from Argon. After 1 more month the partial block would be entirely expired.

This change would require a more significant change to how blocks are currently logged and managed on Special:Block, Special:BlockList, Special:Contributions, and Special:Unblock. Users can be partially blocked from an unlimited number of pages, meaning every page could hypothetically have a different expiration, which could lead to some complicated situations.

Option 3 - Something else!

We’d love to hear more alternate proposals. Please discuss below.

For all options it should be possible for an admin to clear all blocks from an account, leaving it entirely unblocked. This will most likely be a change to Special:Unblock.

At the moment, I think the best route forward is Option 1: Re-blocks because this closes the evasion loophole in the simplest way. Option 2 adds a tremendous more complexity in the Special:Block, Special:BlockList, Special:Contributions, Special:Unblock, and logging interfaces. I’m scheduling some time for my team’s interaction designer to work on this but I’d appreciate more comments and input before we put pen to paper. Thank you! — Trevor Bolliger, WMF Product Manager 🗨 23:54, 7 August 2018 (UTC)

Hi @TBolliger (WMF): and thank you for your suggestions. As we have discussed on Wikimania, I will give the same near-real-life example:

• User is indefinitely banned from editing a specific page
• User is banned for one year from moving pages
• User is fully blocked for one week for harassment

Will Option 1 be enough for that? — NickK (talk) 15:01, 8 August 2018 (UTC)

@NickK: No it would not, that would have to be manually tracked. Option 2 would allow for that. — Trevor Bolliger, WMF Product Manager 🗨 18:25, 8 August 2018 (UTC)

@TBolliger (WMF): What would be the best outcome we can achieve with Option 1 then? — NickK (talk) 14:15, 9 August 2018 (UTC)

@NickK: If the primary problem to solve is "indefinite partial block gets lost after short-term sitewide block" then Option 1 would suffice. Option 2 definitely brings other beneficial functionality (but also makes the Block tool even more complicated) so I am trying to suss out in this on-wiki discussion if multi-blocks are a "nice to have" or a "need to have". I feel that I can safely assume you consider this "need to have". :) — Trevor Bolliger, WMF Product Manager 🗨 16:35, 9 August 2018 (UTC)

@TBolliger (WMF): So, the best thing we can reach with Option 1 is:

• User is indefinitely banned from editing a specific page
• User is indefinitely banned from moving pages (an admin have to add a note somewhere to remove this block in one year)
• User is fully blocked for one week for harassment

Do I understand it correctly?

Regarding "need to have"... if this delays everything by a year and creates a system that would be difficult to maintain, I might probably opt for "nice to have" — NickK (talk) 17:10, 9 August 2018 (UTC)

@NickK: Correct, the 'page move' block would have to manually be altered by an admin. The technical maintenance for both systems would be the same, the storage in the database would likely be identical with the difference being in the Interface and API. Design, development & QA will take slightly longer, but certainly not a year. — Trevor Bolliger, WMF Product Manager 🗨 17:59, 9 August 2018 (UTC)

I vote for option one. Same like all other admin actions, I semiprotected a page indefinitly because of long term vandalism. Then, I decide to protect it only for trusted users, because it is about a politican and there will be elections, so to prevent propagation and I protect the page for one month. Then, two trusted users are edit warring, so I fully protect the page because of an edit war for a week. I must remember to reprotect it after previous protections expires (and even more, to replace icons that are inserted by on wiki templates). I think there should be effort to make all admin action *to be applied on the same time and not bind it to this initiative, because it is not relevant to partial blocks. --Martin Urbanec (talk) 23:14, 10 August 2018 (UTC)

• I love this concept! Even if nothing changes partial blocking would be very helpful for the project where I'm a sysop (ru-wiki). But having multi-blocks would help even more. Le Loy 00:15, 11 August 2018 (UTC)

Update, August 22 — We are going to proceed with Option 2, Multi-blocks. Both options would require the same database changes, but multi-blocks allows for much more sophisticated uses (such as User:NickK mentions above or allowing an admin to submit both a partial block and a sitewideblock in one sitting.) We are working on another round of designs to take these new complexities into account and we will post them here on this talk page when they're ready. Thank you! — Trevor Bolliger, WMF Product Manager 🗨 20:55, 22 August 2018 (UTC)

Comment

As I've said before somewhere, this entire redesign of the blocking system makes everything far too complicated for admins, and I don't recall it ever being asked for by the community (I may be wrong). I for sure will continue to simply use standard 'indef' or timed blocks. In my opinion,development time would be better spent on on helping to keep unwanted content out of Wikipedia - particularly by bringing Curation/New Pages Feed up to date with today's requirements. That would reduce the need to use blocking tools of any kind. Kudpung (talk) 21:35, 6 August 2018 (UTC)

On first look, I have the same thought - it doesn't seem like the additional complications would be worth the occasional benefit. Audacity (talk) 09:16, 10 August 2018 (UTC)

• On opposite: it's very useful. Maybe English wiki admins feel OK, but smaller wikis have their own problems which can be resolved with this upgrade. And yes - Wikipedia is getting complicated to manage, so as any other form of human activity. --Brunei (talk) 09:35, 10 August 2018 (UTC)

Kudpung, 2015_Community_Wishlist_Survey/Moderation_and_admin_tools#Enhanced_per-user.2C_per-article_protection_.2F_blocking. Ekips39 (talk) 00:45, 21 August 2018 (UTC)

Third designs

Hi all! This round of designs is a slight departure from the second round because we've added a new functionality which makes things more complicated: multi-blocks. The idea behind multi-blocks is that one user (or IP address or IP range) can have multiple independent, overlapping blocks. This should make it easier for admins to set separate restrictions on one user. Potential scenarios include:

• User:Apples has been indefinitely blocked from editing Neptune. They then receive a 24 hour full-site block. When the full site block expires, they should continue to be blocked from Neptune.
• User:Bananas is indefinitely blocked from editing Mars and from editing Venus until 2025. An admin wants to block them from Saturn for one month.
• After User:Carrots has violated a wiki policy, an admin wants to set both an indefinite block against Pluto and a 24-hour sitewide block at the same time, without having to write a self-reminder to update the block.

Because of this change we need to introduce a new piece of information during the blocking process. This led us to the idea of a block modal window, which can theoretically appear on any page — a diff page, recent changes, a profile, etc. This would allow an admin to block a user without having to navigate to another page. Here is how it would work:

Workflow 1 — Set a sitewide block against a vandal

• 
  Step 1. An admin identified a vandal, clicks 'block'
• 
  Step 2. The block modal opens on the same page.
• 
  Step 3. The form can be filled out on this page and closed directly on this page.
• 
  Step 4. When the block is successfully saved, the modal will close and a confirmation message will appear

Workflow 2 — An admin wants to see a user's other blocks

• 
  Step 1. An admin identified a vandal, clicks 'block'
• 
  Step 2. The block modal opens on the same page. The admin can click 'View block details' to view information about the users' currently active and previous blocks.
• 
  Step 3. The admin is taken to Special:Block, which lists all the active blocks and also allows the admin to create a new block. The admin can click ✏️ to modify or 🗑 to remove any of the existing blocks.

Workflow 3 — An admin wants to set a new block by going directly to Special-Block

• 
  Step 1. The admin would navigate to Special:Block. The page would be empty except for the username input box.
• 
  Step 2. After typing in the username the other current blocks (if any) would automatically appear. The admin can click the 'New block' button.
• 
  Step 3. The modal would open directly on the page.
• 
  Step 4. The admin could set the block parameters. (In this case, the admin is setting a partial block.)
• 
  Step 5. When the admin completes setting the block, the modal would close and the 'current block list' would be updated to include the new block and a confirmation message would appear.

What does everyone think about this new direction? Is the modal a good idea? Thank you for your help! — Trevor Bolliger, WMF Product Manager 🗨 01:18, 5 September 2018 (UTC)

I hope that the text in the last example is a human error ;) _{Hint: End date of the new block}

It looks like a good plan, with a lot of flexibility. Blocking accounts should not be made to much fun.

I'm not sure mods should be working from mobile devices, but have these flows and options been tested on these devices? Normal editing is quite error prone, blocking is something that should be done with a minimal possibility to do it wrong.

Automatic locking of the last used IP and of any new IP should only be available when a sitewide block is given, otherwise any log in from this user will block the used IP. For what period is this IP blocked?

'Creating account' is more in line with the other three options, all showing the verb in front.

Thanks for sharing this and go for the final details. RonnieV (talk) 23:48, 11 September 2018 (UTC)

@RonnieV: Haha, good catch! Yes, the '2019' is just a minor typo. We will do a full found of mobile web QA on both the desktop skin and mobile skin to make sure these tools work properly, thank you for reminding us about this importance.

Autoblocks are 24 hours long or shorter, depending on the block expiration. The IP will not be exposed in the log because it is obscured as a hashed ID instead of the IP address. We believe this will be useful in cases where a user/IP is vandalizing one page. — Trevor Bolliger, WMF Product Manager 🗨 21:37, 12 September 2018 (UTC)

Looks workable. I am sure I have missed some things, but I like the basic principle. · · · Peter (Southwood) ^(talk): 09:28, 12 September 2018 (UTC)

Thank you, Peter. We hope to have a testable version of this ready in the coming weeks to demonstrate how this actually works in the wild on the website! — Trevor Bolliger, WMF Product Manager 🗨