Talk:Community health initiative/Per-user page, namespace, and upload blocking

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search

Second designs[edit]

Hello everyone, we've continued to make adjustments to the designs based on your input. Most notably we've moved the actions checkboxes to be closer to the sitewide/partial radio buttons. This way admins will be able to set a block against users from just uploading files, moving pages, or sending email. I personally think 'account creation' and 'editing their own talk page' should only be active if 'Sitewide' is selected, as they make little sense by themselves. We've still yet to decide. Please note that we still need to decide what the default values will be for the checkboxes when you navigate straight to Special:Block.

You can also see designs for the type-ahead suggestions, how the box will handle a long list of page blocks, and the radio button and button combination options for block duration. The reason dropdown will appear narrow when collapsed, but on click it will display as wide as necessary. We believe this will keep it just as easy to use the dropdown but it will take only one row.

We also have a design for how this will appear on Special:BlockList, in which the details will be loaded when 'view details' is clicked.

Here are the latest wireframe designs:

What do you think? — Trevor Bolliger, WMF Product Manager 🗨 19:50, 28 June 2018 (UTC)

@TBolliger (WMF): Thank you for this update. I still have doubts on how it will work in practice.
The biggest issue is that is not clear what "editing" includes: does this include uploading files and moving pages or should these be included separately? I reiterate my support to having this as separate pages, but if this option is definitely impossible please at least try to regroup this into "default" block (e.g. I want to prevent a vandal from doing any actions) and "limited" ban (I don't want to block a person but just impose some restrictions).
Furthermore, I would like to check how the following workflows will work:
  1. I have to add a temporary full block on the top of a ban on editing specific articles, I want a user to keep a specific ban once the block expires
  2. I want to find all users banned from editing a specific articles (say, it is renamed and I need to update bans, or to expand them to another article on this topic)
  3. I want to check a log of all blocks (and/or specific bans) of a specific user
These workflows are quite common, thus I would like to make sure they work well. Thanks — NickK (talk) 13:00, 1 July 2018 (UTC)
@NickK: Trevor is away until next week so I'll give you my understanding of the points that you raise. The short answer is that the Anti-Harassment Tools team is thinking through how to do all of these and to set the order prioritization of when they will be added.
  1. AHT identified the ability to do multiple blocks (simultaneous blocks with different expiration dates) as an important feature. As it stands now, the very first version will add the ability to partially block an user from one or more pages as an alternative type of block but will not support "multiple blocks" - a partial block (one expiration date) with a full site blocked added (different expiration date). But "multiple blocks" will be prioritized to be added soon after.
  2. | A log which is searchable (filters) of which users are partially blocked is something AHT discussed. The first priority will probably be to have it searchable by user name to see the type of block they have. I agree that there is also value in adding a way to look at who is currently and previously blocked from a particular page.
As to the which actions will separated out, it is still up for discussion but we've thought about "uploading files", "editing in mainspace", "moving a page" "editing a template" "adding categories"" as distinct types of actions that could be be separated out. Additionally a specific type of namespaces could be restricted (Wikipedia, User talk, etc.)
Keep your questions and ideas coming. It is really helpful to have experienced users describing their workflows. SPoore (WMF) (talk) , Trust and Safety Specialist, Community health initiative (talk) 01:49, 6 July 2018 (UTC)
@SPoore (WMF): Thank you for your answers. I would say that the first point is critical. Looking at block logs in my home wiki, at least three users having specific bans (currently done via AbuseFilter) were fully blocked for a short time over the previous week or two. Having to set a specific ban again after a short-term block expires will probably prevent us from using this system — NickK (talk) 07:20, 6 July 2018 (UTC)
@TBolliger (WMF): it looks nice. I'd suggest not to hide the "reason explanation" edit box when a predefined block reason is chosen, because sometimes admin would want to explain briefly more about how was that reason. If admin chooses "Other reason", then should be mandatory to fill "reason explanation" edit box, otherwise it would be optional. --Zerabat (discusión) 13:50, 18 July 2018 (UTC)
@Zerabat: Thank you for the feedback! The text field for 'reason' will still remain visible and editable if an option is selected from the dropdown, and will postpend whatever is in the text field after the dropdown. I like the idea to make selecting a reason obligatory but I wonder if this should be customizable per-wiki. — Trevor Bolliger, WMF Product Manager 🗨 15:23, 18 July 2018 (UTC)

On hr.wp we have conditional page/theme blocks, which are controlled by sysops. If user breaks block, meaning, if user edits the page (s)he is warned (s)he is not allowed to, resulting action is lengthy block. Better solution would be possibility of actual page/set of pages/namespace per user blocks. No solution is perfect, but more possibilities/more granularity gives more options to choose from. In hands of experienced sysops, having more tools is better than less. Verbal pressure, partial and total punishment is better than just verbal pressure and total punishment.
Actual design of block page is irrelevant, important is only - getting more options for users when they struggle with understanding of rules.
Regarding comments to leave current options as they are - well, not every situation need to be sanctioned by (total) block. There are users which are capable of editing correctly some articles/themes, and in some, they are repeatedly getting in conflicts. If user is new, easy way out is block. If user is old, meaning, having long list of good edits and long time around, per page or theme block could be more appropriate solution. From my experience, IMNSHO. SpeedyGonsales (talk) 23:45, 30 July 2018 (UTC)

Thank you for the details, @SpeedyGonsales:. It seems like our Partial Block additions may be helpful on hr.wp. It will be available in the coming months. — Trevor Bolliger, WMF Product Manager 🗨 18:00, 6 August 2018 (UTC)

Will cookies be used to enforce "partial blocks" as well? — xaosflux Talk 03:02, 5 August 2018 (UTC)

@Xaosflux: Yes, because this is an extension of Block. The cookie dropping & blocking logic will not change, just what the blocked user can access. — Trevor Bolliger, WMF Product Manager 🗨 18:00, 6 August 2018 (UTC)
  • Comment The power of the "Default effect" cannot be understated. When given the opportunity to change options, most common users would not be changing the options. So we should definitely not have "indefinite" block as the default, given that most infractions incur only a temporary block. As far as other options, individual wikis need to address their policies and guidelines. For example, if someone is edit warring on a certain page, would it be more acceptable to block them for a certain amount of time from editing that specific page, or from the entire wiki? This happens a lot on the English Wikipedia, where users have had issues in the past with certain pages, but are just fine with others. So this would be excellent for those users. "Sitewide" should be the default until wikis adjust their rules and policies to accommodate this tool. Perhaps different wikis will default to "partial" and others with "sitewide". Tutelary (talk) 03:42, 5 August 2018 (UTC)
    • IMO the defaults should be: 31h, block last used IP, prevent account creation, watch talk page. JzG (talk) 15:06, 5 August 2018 (UTC)
      • @Tutelary: You raise a very good point — that making 'Indefinite' the default will both encourage its use and result in some accidental lengthy blocks. That's not a desired outcome at all. JzG suggests making the default 31h (and likely configurable per wiki) but I might prefer how it works now, requiring a manual selection. Curious to hear other thoughts.
      • @JzG: Currently only 'block account creation' and 'autoblock IP' are selected by default, and we are not planning on changing that behavior. I'd be in support of selecting 'watchlist user page' by default too if there is support to do so. Alternatively: I hate to suggest a new preference but we could add a checkbox to the 'Watchlist' tab of Special:Preferences to control the default value of the box (or even piggyback off an existing preference.) — Trevor Bolliger, WMF Product Manager 🗨 18:00, 6 August 2018 (UTC)

When a block expires, it must be possible, and easy, to return to the status quo ante. for example if a long term block is in place for some aspect, and a short term block is imposed for a different aspect, removal or expiry of the short term block must either return the pre-existing longer term block to the same status as it had before, or there must be a way to annotate and warn the admin responsible to reinstate the previous block status urgently. Automatic reset is by a huge margin preferable. Manual reset will be a large burden on admins and is likely to cause big problems, but is still better than no obvious record of the previous status, which will disrupt the project to the extent that it will probably cause more harm than good.· · · Peter (Southwood) (talk): 05:01, 5 August 2018 (UTC)

NickK and others have raised excellent points about the wider workflow but purely in terms of user interface design, I think the wireframes are really good. It looks very intuitive to use and I can see it being a really useful feature. I agree with Nick and Peter that the ability to return to a previous block status, rather than no block, is an essential feature to develop. However I wouldn't say that's a prerequisite to partial block functionality being released, as long as it's clearly communicated how it's going to work. If wiki administrators know that we need to remember to manually re-implement a previous partial block after a sitewide block expires, that's not an insurmountable obstacle. Waggers (talk) 11:13, 6 August 2018 (UTC)
I agree that automatic re-block is a better solution (one of our aspirations with this feature is to reduce the amount of time admins spend on setting and managing blocks, so a manual system fails to accomplish this.) Our team plans to complete re-blocks (or 'multi-blocks' tracked in phab:T194697) after the initial "minimal" functionality is built, tested, and released to a volunteering test wiki. I agree this is not appropriate to release to all wikis without being addressed. Our rationale is that: before we invest in re-blocks we want to make sure we get the basic functionality correct, as to minimize potential wasted effort.
There are some unique design questions that we'll need to address for that feature, and we'll be sure to post our first mockups here as soon as they're ready and I'll be sure to ping you to participate in the design. Thank you. — Trevor Bolliger, WMF Product Manager 🗨 18:00, 6 August 2018 (UTC)
Bear in mind that whatever you do, it will come as a surprise to some people, and if it is an unpleasant surprise there will be pushback. Messing with people's workflow is almost always an unpleasant experience and is generally strongly resented and highly disruptive to the Wikipedia. It also increases general mistrust of WMF. Refer to VE introduction for a recent example. While this feature is experimental make it opt-in. It will take a bit longer to get feedback, but there will almost certainly be less strong negative feedback.· · · Peter (Southwood) (talk): 05:47, 7 August 2018 (UTC)
I've already had a quick chat with the team that built the new filters for Recent Changes and Watchlist about how they managed their rollouts to make their new features opt-in for a beta period. I've created phab:T201469 to follow through on this idea. — Trevor Bolliger, WMF Product Manager 🗨 21:44, 7 August 2018 (UTC)

Maybe add a way to stop users from adding something like 2000 pages to the block list? --Terra  (talk) 08:01, 8 August 2018 (UTC)

@TerraCodes: Even there there is no technical need to have a limit I agree it would be useful from a usability perspective to place a limit on the page list. Is there any reason you chose 2,000? Why so high? — Trevor Bolliger, WMF Product Manager 🗨 17:45, 8 August 2018 (UTC)
@TBolliger (WMF): Nah, it was just a random number I came up with. --Terra  (talk) 12:22, 9 August 2018 (UTC)

option to disable sitenotice banner[edit]

It is nice to be invited to take part in a discussion on possible improvements. However, I will decline the invitation because it solves problems we are not experiencing. Ironically, on my screen the banner takes up so much space that the necessary information about earlier blocks becomes invisible. Which requires me to perform extra scrolling for each spammer (about 20 times a day). Would it be possible to have a toggle to switch off this banner if you do not want to see it anymore. For me that would improve blocking. --MarcoSwart (talk) 17:24, 19 July 2018 (UTC)

Hi @MarcoSwart: The banner will be disabled in 4 days on Monday, July 23 but if it is in your way you can add .specialblock-feedback-request {display: none;} to your personal CSS, such as Special:MyPage/vector.css. I apologize about the intrusion, but we want to make sure our changes to Special:Block do not come as a major surprise to anyone who uses the current blocking tool. — Trevor Bolliger, WMF Product Manager 🗨 19:47, 19 July 2018 (UTC)
Thanks for the code, it solves my problem. It is great you inform everyone, it's just the repetition that was annoying.--MarcoSwart (talk) 20:06, 19 July 2018 (UTC)
Quick update to our timetable: we've disabled the banner after only 12 hours and plan to re-run it from July 30-August 3. The same CSS class will be used, so keep it in your personal style sheet if you do not want to see it. Best, — Trevor Bolliger, WMF Product Manager 🗨 08:56, 20 July 2018 (UTC)

I've not seen the banner, but I hope you didn't link an English-only untranslatable page to users in languages other than English, because that would be against the CentralNotice usage guidelines. --Nemo 07:14, 21 July 2018 (UTC)


When is this coming live?--Tiven2240 (talk) 12:39, 1 August 2018 (UTC)

Hello Tiven2240, this is currently in the initial stages of development. We hope to have a very minimal version of this ready for one or two test wikis by the end of August. Would your wiki be interested in being an early beta tester? — Trevor Bolliger, WMF Product Manager 🗨 20:46, 1 August 2018 (UTC)
@TBolliger (WMF): The Wiki that I am a admin has very small editing community . We would like to test it on Beta but blocking/banning someone unnecessarily for testing won't be acceptable by the community. --Tiven2240 (talk) 00:01, 2 August 2018 (UTC)
@Tiven2240: We wouldn't want to encourage you to block someone unnecessarily — this tool should only be used when absolutely necessary. When it's ready to test in beta I'll announce it here and wikis can sign up to have it, just in case an opportunity arises where it would be useful. — Trevor Bolliger, WMF Product Manager 🗨 18:01, 2 August 2018 (UTC)

Yeah first release it in Beta than we can move forward with it. --Tiven2240 (talk) 17:15, 11 August 2018 (UTC)

More about logs[edit]

Hi. I'd like to talk some more about logs. You spoke about limits and scrollable locks. So, here are my thoughts:

  1. What will be the limit? 10 pages, 100 pages?
  2. The page name can be very long, sometimes five pages take more than 100 others.
  3. Will the page link wiki address be the part of tbe length? If it will, maybe it's better not to create wikilinks at all, giving only page names? Otherwise, maybe it's better to give page id as a text of the link?
  4. Will the page lists be granular (one concatenated string vs strings array). For example, could I iterate on pages field in MySQL?
  5. Will the log length limit be big enough to include all namespaces besides one in any language, including namespaces locally defined in wikis?
  6. Will the log (and so the partial block) be incremental? I mean, can I block a user from editing on 10 pages, and a second after on 10 others, and they will be blocked on 20? Or just the last block is relevant?
  7. In the same way, can I block on some namespace, and in other block on some pages in another namespace? These both questions allow to split a long block to two or more.
  8. Could I open some page (Special:Logs, Blocked Users, Page history, Page logs, or something else), and query a list of all users that are partial blocked on this particular page? And what about namespace?
  9. What about API and MySQL, will they allow getting all relevant information about partial blocks?

Thank you and good luck with this. IKhitron (talk) 13:02, 4 August 2018 (UTC)

And thank you for all of the insightful questions and comments. I truly appreciate you thinking about there different aspects of the function and design. We'll give you a more informative response soon. SPoore (WMF) (talk) , Trust and Safety Specialist, Community health initiative (talk) 17:50, 7 August 2018 (UTC)

Hi User:IKhitron and thank you for your questions. I'll answer in the same order you asked:

  1. We propose no limit to the pages and namespaces that a user can be blocked from.
  2. If a page name is too long to appear on one line inside the text box it will be truncated with an ellipsis (...) and hovering over it with a mouse will display a browser tooltip with the full name. We do not have a solution for touchscreen devices.
  3. Blocks are local, so only page names will be required. For example, on the French Wikipedia would display as Bono and would display as Portail:Accueil
  4. We are storing the pages via page IDs in case they are renamed. They will be stored in the database as separate rows. Our database schema changes can be seen at phab:T193449
  5. In theory there is no limit to the log entry lengths. I expect we will find a "human understandable" limit when users begin receiving complex partial blocks. I'm working on writing up some examples of splitting log entries, and will post those questions on this page in the coming weeks. All local namespaces will be blockable.
  6. We are discussing this in the section below! Re-blocks vs. multi-blocks vs. other ideas.
  7. See the discussion below.
  8. We are planning on adding a search field to Special:BlockList. phab:T191549 is tracking this idea.
  9. We're updating API:Blocks and API:Userinfo in phab:T197141.

Let me know if any of these answers are unclear or if you'd like more information! — Trevor Bolliger, WMF Product Manager 🗨 00:13, 8 August 2018 (UTC)

It's all clear. Thank you very much for your answers. But from all this, I have two more question. If some admin will block on all namespaces minus one, or on 100 pages, will special:log have enough space in its fields, and will MySQL have enough space on its fields - the string there should have maximal length, nevermind how big it is? And also, is there a way to block on page and all its subpages, nevermind what are they and when will they be created? IKhitron (talk) 12:24, 8 August 2018 (UTC)
@IKhitron: We are still undecided about logs, and I'm hoping to write up some discussion questions for this talk page. In brief, we will either bundle the parameters of the block into: 1) a single detailed log entry including every page, namespace, and/or action the user is blocked from (which we still do not know is possible from a length perspective) — or 2) a single abridged log entry that only indicates if the block was sitewide or partial — or 3) separate log entries for every page, namespace, and/or action the user is blocked from. Each of these have their drawbacks.
Our current plan is to not automatically block subpages. You'd have to manually insert every subpage. In the future we may add an checkbox for admins to select "also block corresponding talk pages and subpages". — Trevor Bolliger, WMF Product Manager 🗨 17:56, 8 August 2018 (UTC)

Criticizing the "one block per user" idea[edit]

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)


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)

Non-Wikimedia wikis[edit]

I hope this isn't another feature that becomes part of default MediaWiki and thus gets forced onto non-Wikimedia wikis without their consent. As an editor and administrator of a wiki that receives semi-regular software updates, I for one do not want it. It seems designed to cater to sites like English Wikipedia with complex bureaucratic processes (e.g. "interaction bans") and not appropriate for general use. I know regular sitewide blocks will still be possible, but I imagine most wikis do not need this level of complication and would be better served by a simpler block form. Ekips39 (talk) 02:33, 10 August 2018 (UTC)

Another comment from me on a different aspect. Not sure if this one has already been raised, but you do know a lot of this can be done with mw:$wgRevokePermissions, right? Uploading files and moving and creating pages can be revoked by creating new user groups that have the permission disallowed. Namespaces could also be handled this way by first introducing separate rights for separate namespaces, as with interface pages and some others. Something to consider. This would make it easier to keep it out of core and to set multiple restrictions at once. Ekips39 (talk) 16:57, 10 August 2018 (UTC)

Hello User:Ekips39, and thank you for your comments. In our technical investigations for this feature we determined that we would either need to make Partial Blocks part of core or extract all Block functionality into its own extension. We opted for the first tactic for technical simplicity and ease of implementation. While the UI and API changes will be present, the functionality will be optional for all wikis — third party or Wikimedia. The defaults will not change from what they are today, so no workflows should be interrupted.
As for $wgRevokePermissions, that is still possible to use but we are building this functionality into Blocking as a means of keeping Groups simpler and to consolidate all routine permission revoking into one tool and one log. — Trevor Bolliger, WMF Product Manager 🗨 17:30, 10 August 2018 (UTC)
So my suspicion was correct. Yes, I'm aware that "the functionality will be optional". I acknowledged this. What I'm saying is it will make Special:Block more complicated and thus potentially harder and less intuitive to use. I don't know why I was thanked for my comments if they won't be taken into account. I'm getting the feeling the WMF doesn't care about third-party wikis. Why would they? Ekips39 (talk) 21:49, 10 August 2018 (UTC)
We have designs for the changes to Special:Block on the canonical project page and above in § Second designs if you have concerns about the usability implications of our changes. In the coming weeks our UX designer will be making a third round of designs. — Trevor Bolliger, WMF Product Manager 🗨 22:01, 10 August 2018 (UTC)

Allow admins to block non existing pages[edit]

Hello, I'd like to be able to block user from editing non existing pages. Imagine an user repetatively propagating himself on his page but editing other pages usefully. Why block him sitewide? Yes, I can (and do) protect the page, but this will affect everyone, not just the user. --Martin Urbanec (talk) 23:20, 10 August 2018 (UTC)

Hello @Martin Urbanec: and thank you for your suggestion. We've thought about this a bit and decided to initially only allow for blocking of existing pages because we will store the block by the page ID to allow for page renames (example: if a user is blocked from "Michael Jackson" and the page is renamed to "Michael Jackson (singer)" they should still be blocked from editing.) We are also planning on adding in support for blocking a user from creating any page (phab:T199918) which would still allow the user to edit existing pages.
A workaround in this system would be to create the page you want to block the user from, partially block that user, then delete the page. This is cumbersome so I've created phab:T201853 to allow for blocking for specific non-existent page names. This may be more complicated than it seems (since we'll need to store the potentially-lengthy pagename instead of the numeric page IDs.) — Trevor Bolliger, WMF Product Manager 🗨 16:24, 13 August 2018 (UTC)
Hello @TBolliger (WMF):, thank you for explanation why only existing pages are considered. Just allowing admins to block from any page creation seems like reasonable thing to do and also relatively easy thing to do. Of course, having a way to choose between sidewide page creation block and only some pages creation block will be even more powerful. --Martin Urbanec (talk) 16:29, 13 August 2018 (UTC)

Blocking users from all pages except some specific pages/namespaces[edit]

There're some use cases in enwiki.--GZWDer (talk) 11:42, 14 August 2018 (UTC)

@GZWDer: Yes, I like this idea - it has been brought up before in phab:T27400. However, we decided on page, namespace, and upload blocking because our team feels they will provide the most valuable functionality for the most wikis. A simple workaround would be to block a user from the major namespace (main, talk, user, file, template, category, etc.) because allow them to edit within the project namespace. — Trevor Bolliger, WMF Product Manager 🗨 22:05, 14 August 2018 (UTC)

User specific blocks won't work alone[edit]

When the cost of acquiring a new account is low, and the capital gained by keeping that account is non-existing, then attaching blocks to specific user accounts will not work. It will simply trigger the user to acquire a new account.

The opposite; allowing good behaving users to edit a specific article works, but it is awkward to implement as all those good behaving users must be tracked somehow. Actually this is just whats done by blocking new and anonymous users.

If a user specific block is used, then new and anonymous users must also be blocked, otherwise it won't work. — Jeblad 11:48, 14 August 2018 (UTC)

@Jeblad: It will be possible to Partially Block an IP address or IP range, as well as autoblocking the last IPs from a username. Page protection will still work in cases where users circumvrent a block. We expect partial blocks to be most effective in situations where two users want to keep their Wikimedia identity. — Trevor Bolliger, WMF Product Manager 🗨 22:30, 14 August 2018 (UTC)
At least in Norway the IP-addresses is not stable unless you pay additional fees, surf from a school, a business, or similar. Autoblocking on IPs from an username will not work if the user knows about it, especially if the user has a cellphone and creates a hot spot. Mobile high-volume data connections are quite common in Norway, while static IPs are not. It is more or less the same in all countries outside the US. Autoblocking on cookies are more or less defunc, there are a whole bunch of browser extensions that wipe the cookies regularly, and even sandboxing that has unique cookie stores.
One admin at nowiki regularly blocks whole mobile networks (usually the second larges cell network in Norway) to stop a single vandal, and I strongly doubt that this is a kind of behavior that should be accepted as normal admin work.
What could work is to allow users to edit if they has already edited an article when the user specific block is instantiated. Also logged in users that has no previous history of editing from the same IPs as the blocked user. The keyword here is "previous history", as anything you detect after the block is instantiated might be falsified. This will although leak information, and it will create a pretty harsh block typically favoring one side in an edit dispute.
One option could be to try to fingerprint the user, but the usual text fragments entered on Wikipedia is way to short to give good identification. Forcing the user to type additional dummy text is a bad idea, as fingerprinting of users works by identifying a cooperative user, and fails badly when the user refuse to cooperate. That is the user intentionally change his typing behavior, like using only a single hand for typing the dummy text.
If the purpose of this is to stop edit wars, then a better solution is to detect the reverts and enforcing progress for each edit. This can even be set up to block users with tightening limits for each attempt to create an edit war, and it can even work across several user accounts. If a 3RR model is used, then if user A adds a text, and user B rewrites the text, then user A changes it back, and user B rewrites the text once more, then user B will be flagged as starting an edit war even if the text is different. Likewise if user A adds a text, and user B rewrites the text, then user A changes it back, and user C rewrites the text once more, then user C will be flagged as starting an edit war. Thus it will not help changing user accounts. Blocking in this refers to stopping a save even if it is somewhat different from a clean revert. Because the users has to make real changes to be able to save, they can't just revert each other, but must reformulate the text, thus it will enforce progress for each edit.
But of course, there is no explicit banning of any user in this solution, so it isn't so fun for the admins. — Jeblad 00:11, 15 August 2018 (UTC)
Hi @Jeblad:, I see that you were also active during our December 2017 consultation about Community health initiative/Blocking tools and improvements. Some of the problems you're describing would be more appropriately handled by more tactical blocks, such as fingerprinting or User Agent blocking. Our team decided to focus on Partial Blocks to solve a different set of problems, such as these potential use cases. Our team has prepared work for User Agent + IP blocking but we feel Partial Blocks will deliver more value in the realm of Anti-Harassment at this point in time. — Trevor Bolliger, WMF Product Manager 🗨 20:34, 15 August 2018 (UTC)
How you chose to do this is up to you, and your team, but locking users out of some realm is a pretty well-defined and well-known problem, and the given solution simply will not work. But newer mind my complaints, do implement it! Or perhaps go investigate the problem more thoroughly. — Jeblad 21:10, 15 August 2018 (UTC)

Interaction ban[edit]

Either I am missing something in the explanations, or there is currently no explanation how an interaction ban is planned to be imposed. There are cases when two editors keep coming to pages (not only articles) important to the other side, leaving unwelcome comments or making controversial (but not necessarily harmful and thus justifying a block of a regular kind) edits. Right now the only way that I can see in the proposal is to administer partial blocks on long lists of pages "owned"/frequented by the second side, but this seems rather cumbersome and ineffectual. --Deinocheirus (talk) 23:26, 18 August 2018 (UTC)

@Deinocheirus: This feature is not currently designed to support interaction bans perfectly. It would be easy to block two users from the other's User: and User_talk: pages as well as a list of pages "owned"/frequented like you mentioned. Productizing a hard block interaction ban would open the potential to cause more harm than good, as the dynamacy required in order to support a true interaction ban (User:Apples cannot edit any pages recently edited by User:Bananas and vice versa) would give both users the abilities to troll the other by making minor or inconsequential edits on pages that the other would likely edit. (For example if User:Apples knows that User:Bananas is a big sports fan, Apples could make lots of small copyedits to important sports pages, which would prohibit Bananas from making legitimate content edits. Yes, this is schoolyard politics but we've seen worse on wiki.)
We're definitely open to other ideas if you have any on how to enforce interaction bans! The best we can think of would be 'pages where one user already has significant contribution patterns' but this still leaves lots of gaps. We've even considered just a warning system (such as "Warning, User:Bananas edited this page 4 days ago, with 2 intermediate edits. Edits in conflict with their work will be in violation of your interaction ban.") — Trevor Bolliger, WMF Product Manager 🗨 00:25, 21 August 2018 (UTC)