Talk:Community health initiative/Partial blocks/Archive3

Second designs

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:

• 
  This is the default view for Special:Block
• 
  A partial block configured.
• 
  A partial block with several pages set
• 
  Type-ahead suggestions for namespaces
• 
  Type-ahead suggestions for pages
• 
  How a partial block will look and function on Special:BlockList

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.

Tracked in Phabricator:
Task T194697 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.

Tracked in Phabricator:
Task T191549| 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

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)

Inquiry

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

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 https://fr.wikipedia.org/wiki/Bono would display as Bono and https://fr.wikipedia.org/wiki/Portail:Accueil 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)

Non-Wikimedia wikis

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

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

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

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

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)

Feedback summary, August 22

Hello everyone! We’ve just met with our UI designer to get started on a third round of designs. The biggest change will be that we’re adding in support for multi-block functionality (more on that below.) Here is a summary of all the feedback we’ve received since posting the second designs back in June, with some of my notes/responses:

• It is necessary to support multiple simultaneous blocks against the same user/IP with different expiration dates. — Our team agrees. We will be adding in support for ‘multi-blocks’ to allow admins to set multiple independent blocks against the same account with overlapping parameters and expiration dates. The next round of designs will highlight the changes to Special:Block, Special:BlockList, Special:Unblock, and Special:Contributions that will be required to support this functionality.

• It is not clear what the "editing" checkbox includes. — If the ‘Sitewide’ radio button is selected the checkboxes for ‘uploading files’ and ‘moving pages’ will be marked as selected and inactive. (In other words, sitewide blocks will be exactly the same as they are today.) If the ‘Partial’ radio button is selected, then the target user will only be blocked from editing specified pages or all actions (editing, moving, and creating) inside the listed namespaces.

• There was a request to change our designs to leave the ‘default’ sitewide block options as they are on wiki today and to add all new functionality in a different section. — Because there are so many overlapping pieces (target, expiration, reason, etc.) this design direction would be overcomplicated. The default selections will still be for a sitewide block, as they are today.

• How will you find all users blocked from a specific article? — We will add a search box to Special:BlockList to allow for filtering to just display blocks against a certain page. (phab:T191549)

• What happens when pages are renamed? — Page blocks will be stored by page ID and will automatically follow the page moves. This will be automatically updated (assuming there are no cacheing issues) on Special:Block, BlockList, and Contributions.

• There was a request to block a user from a non-existent page (i.e. a redlink page) — Because we are storing pageIDs and not page names, this will require additional database changes. This idea is not prioritized but is tracked in phab:T201853. We are planning to build the much-easier functionality to allow an admin to block a user from creating any page in phab:T199918.

• I want to check a log of all blocks (and/or specific bans) of a specific user — This will still be possible on Special:Log, Special:Block, and Special:BlockList. All three locations will display more detailed information about the block if it is partial.

• The ‘reason’ textbox should always be visible. — 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.

• The ‘reason’ dropdown and/or textbox should be mandatory. — This is easy to build but potentially interruptive. We will not change this immediately but are open to in the future. We’d likely make this customizable per-wiki. (phab:T202576)

• Do not make ‘indefinite’ the default block length. — Good points. We will correct this in the next iteration of designs. No length will be selected so the admin will have to manually choose a length. In the future we can give individual wikis the ability to customize a default block length. (phab:T202578)

• The 'watchlist user page' checkbox should be checked by default. — This is easy to do, but should probably be a per-user preference. We will not change this immediately but are open to in the future.

• Make this feature opt-in for a period of time to get feedback. — Because this is a per-wiki feature and not a per-user feature, when Partial Blocks is enabled on a wiki it will be available to all admins. However, we are considering making the UI changes to Special:Block opt-in for a period of time to help with the transition. (phab:T201469)

• Set a limit to the amount of pages a user can be blocked from. — The first length will be 10. In theory it can be unlimited. We should define an appropriate limit together.

• There was a discussion about logs. — This topic is still unresolved, we will need to discuss further how partial logs should be appropriately logged.

• There was a request to build this as an extension. — Unfortunately blocking is part of core MediaWiki, so our changes will be made to core.

• There was a request to allow admins to block a user from the entire wiki except for a whitelist of certain pages, such as an admin’s talk page or ArbCom. — This is outside the scope of this project, but the idea has been captured in phab:T27400. A workaround would be to block a user from editing all namespaces except the project namespace.

• This project has been criticized for its potential effectiveness because it will be easy for users to create new accounts or edit while logged out. — Partial Blocks will work for IP address and IP ranges, so the parameters could be applied to users who are logged-out. Our team believes Partial Blocks will be most effective for users who care about keeping their same user account for their social reputation and edit count.

• How will this support an interaction ban? — Admins can ban two users from editing each others’ talk page but would have to otherwise manually create lists of pages for the users to be blocked from. We’re open to other ideas, but this area is fraught with complexities.

Please let me know if I missed anything from the past few months. We aim to have new designs ready for posting here on-wiki next week. Thanks for reading! — Trevor Bolliger, WMF Product Manager 🗨 20:52, 22 August 2018 (UTC)

Summary of it.wp discussion about partial blocks

Hello all, Here is a summary of a discussion about the possibility of introducing partial blocks on it.wp.

Started on 9 Aug 2018 and ended on 15 Aug 2018 (when the discussion naturally stopped)

Main points mentioned:

• Allows more specificity to address user conduct issues such as a pov pusher on a few pages or someone who uploads a copyright violation.
• Allows for Mediawiki software to enforce measures already being enacted by the community like topic bans.
• The people doing partial blocks should be administrators.
• The community can update policy as needed to reflect the use of partial blocks.
• That some users should be site blocked blocked because they are not suitable for collaboration.
• Concern that without benefit of ArbCom or similar group like other wikis have have, itwp will not be able to manage these type of cases well. Might pull itwp towards having a group like arbcom.
• Consensus has always been the way that topic bans are decided and will continue to done this way with partial blocks. *All 111 admins are available to monitor the enforcement with partial blocks.
• Points out that cases that could benefit from a partial block can be discussed at Wikipedia:Utenti problematici
• Technical tools are superior to pedagogical remedies.
• The community will retain the right to decide when and how to use partial blocks.
• Partial blocks will be useful but classic blocks will be the most common.
• Partial blocks used for edit-war we could also reduce the need for protection.
• Concern expressed about the timing of the discussion on itwp and suggests to have it at a later time.
• Discussion of examples cases.
• As a new feature partial blocks should be used with caution and moderation.

Corrections or clarification of the summary are welcome. SPoore (WMF) (talk) , Trust and Safety Specialist, Community health initiative (talk) 17:52, 11 September 2018 (UTC)

How should partial blocks be logged

Hi all! Our next round of designs is delayed until next Wednesday, September 5. Until then let’s talk about how should partial blocks be logged. Block log entries keep a historical record of every time a block is set, modified, or removed and are used both to answer simple questions (e.g. when does my block expire?) as well as to determine a sequential history of actions (e.g. why was a user blocked 5 years ago? Which admins participated in the blocking procedure?)

Logs currently appear on Special:RecentChanges, Special:Log, Special:Contributions (if a user is currently blocked), and Special:Block. With partial blocks we’re slightly changing how the block notice on Special:Contributions appears (see this mockup) so for the sake of this discussion let’s only talk about how block logs should work on Special:Log, Special:RecentChanges, and Special:Block. We anticipate most partial blocks to only contain a small amount of pages but we want to find a solution that will work if a user is either blocked from just one page or one hundred. Here are our four ideas:

Idea 1 - One log entry per item blocked

• If an admin blocks a user from multiple pages and/or namespaces, a log entry would be created for each item.
• For example:
  • TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing the page Carbon with an expiration time of N (reason) (unblock | change block)
  • TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing the page Nitrogen with an expiration time of N (reason) (unblock | change block)
  • TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing the namespace Template with an expiration time of N (reason) (unblock | change block)
• All active blocks would then appear on Special:Log (filterable to the user), which would be how a user would see what pages they are prohibited from seeing
• Pros:
  • Builds off existing structure and behaviors
  • Simple format
  • Works well for simple blocks (around 1-10 pages, namespaces, and/or actions)
• Cons:
  • Repetitive
  • Potentially spammy if a user is blocked from a lot of pages at once
  • Unlikely to be necessary to see this level of granularity on Special:Log and RecentChanges.

Idea 2 - One log entry per block action, simplified

• If an admin sets a granular block, the log could be generic and point to another page that lists the full details of the block
• Example:
  • TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing certain parts of the wiki with an expiration time of N (reason) (unblock | change block)
• “certain parts of the wiki” could be a link, or a “see details” could be added to the last parenthesis
• We could create a new Special page (or expand a current Special page) to show a history of the pages/cats/namespaces a user is blocked from
• Pros:
  • Saves space, one log entry per block
• Cons:
  • Partial block log entries will not be comparable to other block log entries (e.g. to determine when/who/why a certain page was added to a block.) This problem is addressed in Idea 4.

Idea 3 - One log entry per block action, detailed

• Log every log action as a single log entry
• For example:
  • TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing the page(s) Carbon, Nitrogren, Potassium, and Argon and the namespace(s) Template with an expiration time of N (reason) (unblock | change block)
  • TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing the page(s) Antidisestablishmentarianism, Pneumonoultramicroscopicsilicovolcanoconiosis, Winchester-on-the-Severn, Maryland, Saint-Remy-en-Bouzemont-Saint-Genest-et-Isson, Supercalifragilisticexpialidocious, The Name of This Band Is Talking Heads, My Best Friend, General Vasili, Son of Joseph Stalin, United States v. Article Consisting of 50,000 Cardboard Boxes More or Less, Each Containing One Pair of Clacker Balls, Fourteenth Amendment to the United States Constitution, and 1995–96 Courage League Division 4 and the namespace(s) Template, Template talk:, Wikipedia, Wikipedia talk:, MediaWiki, MediaWiki talk:, File, File talk, Category, Category talk, Draft, Draft talk and User with an expiration time of N (upload block, This user has abused a lot of things and needs this very specific block.) (unblock | change block)
• Pros:
  • Single log entry
  • Contains all information about the block, is traceable for changes
  • Works well for simple blocks (around 1-10 pages, namespaces, and/or actions)
• Cons:
  • A single log entry could become unreadable in complex situations
  • "Clogs" up Special:Log and other places
  • Might not be technically possible in big blocks (e.g. user is blocked from 100 pages at once or certain length of pagenames)

Idea 4 - Two logs

• Keep the existing block log as-is, but mark if a block is sitewide or partial
• For example:
  • TIMESTAMP Admin-who-blocked (t|c|b) sitewide blocked BadApples (t|c) with an expiration time of N (account creation blocked, email disabled, cannot edit own talk page) (reason) (unblock | change block)
  • TIMESTAMP Admin-who-blocked (t|c|b) partially blocked BadApples (t|c) with an expiration time of N (account creation blocked, email disabled, cannot edit own talk page) (reason) (unblock | change block)
• Introduce a new ‘partial block log’ that only logs each individual item (page, namespace, action) blocked.
• For example:
  • TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing the page Carbon with an expiration time of N (reason) (unblock | change block)
  • TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing the page Nitrogen with an expiration time of N (reason) (unblock | change block)
  • TIMESTAMP Admin-who-blocked (t|c|b) blocked BadApples (t|c) from editing the namespace Template with an expiration time of N (reason) (unblock | change block)
• The partial block log could be hidden from the primary view of Special:Log, RecentChanges, and Special:Block, so it wouldn't matter if it was unwieldy
• Could potentially cross-link between the two, maybe showing the block ID.
• Pros:
  • Allows Special:Log, RecentChanges, and Block to be readable, but also allows for the granularity needed to understand the exact contents of a block.
  • Because Special:BlockList and Special:Contributions will show a table view of what a user is currently blocked from, the lengthy nature of the partial block log is acceptable.
• Cons:
  • The partial log could become very lengthy and unwieldy.
  • Are two logs really necessary? Potentially overkill for small partial blocks.

We can also explore other ways of logging, such as how enhanced Recent Changes handles groups of similar actions. Please comment on which would work best or suggest something new. Thank you! — Trevor Bolliger, WMF Product Manager 🗨 23:28, 29 August 2018 (UTC) Hi and thank you. Oppose 1 and 2, need to think about 3 and 4. IKhitron (talk) 12:43, 30 August 2018 (UTC)

@IKhitron: If you have time, I'd appreciate to hear some details of why you think Options 1 and 2 are off the table but 3 and 4 hold potential. Thank you! — Trevor Bolliger, WMF Product Manager 🗨 22:06, 30 August 2018 (UTC)

Of course. 1 is too long. The logs list should be as short as possible. 2 has not enough information. IKhitron (talk) 22:18, 30 August 2018 (UTC)

Supporting 2. I think we should mark which actions were blocked (editing, editing own talk page, uploading, account creation etc.) as we do now and include a flag "partial block". We can also include a link to a special page (maybe Special:BlockDetail) describing all the details, including diffs. So the log can look like TIMESTAMP Admin (t|c|b) blocked BadApples (t|c) blocked BadApples (t|c) with an expiration time of N (account creation blocked, email disabled, cannot edit own talkpage, partial block) (reason) (unblock | change block | see details). I think this will be more clear and easier to understand. In case this won't be accepted, I can accept idea 4. --Martin Urbanec (talk) 18:18, 2 September 2018 (UTC)

I think the biggest difference between Special:BlockDetail and a new, secondary 'partial block log' would be that the log would show a historical record of every time the partial block was modified, which I think is an important use for Logs. The current status of a block will already be visible on Special:BlockList. — Trevor Bolliger, WMF Product Manager 🗨 00:26, 5 September 2018 (UTC)

I would be more in favour of option 4. I am in favour of making partial blocks less visible on Special:Contributions due to different perception from community point of view: having same display for full (user cannot edit now) and partial (user can edit now something like 99% of all pages) blocks is not a good option for me — NickK (talk) 18:39, 2 September 2018 (UTC)

I'm of two minds if partial blocks should show on Special:Contributions or not. Perhaps only to the user themself and admins? Or nobody, and only on Special:BlockList? — Trevor Bolliger, WMF Product Manager 🗨 00:26, 5 September 2018 (UTC)

For the message text, it presumably wouldn't actually need to say "page(s)" or "namespace(s)", as the software could just pass a number to {{PLURAL:}} like for other messages... --Yair rand (talk) 03:05, 5 September 2018 (UTC)

September 21 Update

Hello all;

Our team is nearly ready to release the first feature set of partial blocks — the ability to block a user from ≤10 pages — on the beta environment then test.wikipedia by mid-October. We are talking with some early opt-in wikis to test the functionality, please let us know if your wiki would be interested in utilizing this functionality, which also gives you a great opportunity to dictate the future of this project!

In other news, due to technical complexity, we have decided to de-prioritize multiple blocks (phab:T194697) and remove it from this project. I've moved the documentation here. This small amount of functionality would take a very large amount of time to build and we first want to make sure page, namespace, and upload blocking work as expected and actually produce meaningful impact. I've archived the talk page discussions about this here. We'll have another round of designs soon and we look forward to delivering a great partial blocks feature in the coming months! — Trevor Bolliger, WMF Product Manager 🗨 17:16, 21 September 2018 (UTC)

Update: Here are the latest designs:

• 
  What Special:Block will look like after this change.
• 
  A partial block configured.

— Trevor Bolliger, WMF Product Manager 🗨 00:07, 25 September 2018 (UTC)

As I am not an admin, I can't comment on some aspects of the proposal as I won't be having to use these tools. But I think the idea of partial blocks is useful for the scenarios identified in the use cases (essentially dealing with problems involving an otherwise productive contributor who is having a localised meltdown where it is hoped some cool-off time around the "problem area" may resolve the situation). I take the point made by others that partial blocks like total blocks can be relatively easily evaded by sockpuppeting. I realise it is not feasible to use tools to examine every edit on a project to assess its likelihood of being an arbitrary sockpuppet edit, but is it possible to do so on a list of "high-risk" pages likely to attract sockpuppeting due to partial blocks? Could the checkuser methods (and/or other sockpuppet detection techniques like fingerprinting, edit pattern analysis) be used to automatically analyse (post hoc) any edit that occurs on partial blocked pages and alert the sockpuppet investigation team and the admin who imposed the block if the tools assess an individual edit (or a cumulative stream of edits) as exceeding some threshold of "sockpuppetiness". This seems computationally feasible as the assessment is highly localised around a small number of pages looking for sockpuppets of one (or at most a few) specific partially-blocked users over a limited period of time (the duration of the ban). (Aside, as a lot of problematic behaviour arises through interaction with other users, I might be tempted to suggest checking for past and as well as ongoing sockpuppet activity on those pages for sockpuppet-like behaviour similar to the partially-blocked user AND any other users who have been recently active on those pages, just in case the partially-blocked user was actually the good guy fighting the good fight against a group of sockpuppets who were "controlling the consensus". I think this should also be computionally feasible but obviously more work than my first proposal.) Kerry Raymond (talk) 21:16, 1 October 2018 (UTC)

@Kerry Raymond: this is a super solid idea, thanks for sharing! We've been focused on building Partial Blocks as a response to problems and haven't really thought of how they can be data or warning signs for sockpuppets, page protection, or other forms of user/site management.

We're building Partial Blocks on top of the existing Blocks APIs and it will be straightforward to build solutions such as you mentioned, or to cross-reference partial blocks against suspected sockpuppets, or to build an automated warning system if a bunch of IPs begin editing a highly-partially-blocked page, or even to hook into the Edit Filter feature. I can't commit my team to this work quite yet (first things first — make sure Partial Blocks are effective) but we're optimistic and would love to collaborate with anyone else who wants to expand on our work in the immediate term or longer term. — Trevor Bolliger, WMF Product Manager 🗨 23:38, 1 October 2018 (UTC)

The block UI on test.wikipedia looks the same as the old one, except for the added "Partial" option, and not like in the two images above. Are there any estimates of when the new design is going to be tested? -kyykaarme (talk) 14:27, 4 November 2018 (UTC)

@Kyykaarme: Good question, thank you for asking. We released this first iteration of partial blocks to test wiki with an extremely minimal change to the UI. We consider the above designs good-to-go and will make these changes in the coming weeks, as soon as we've fixed all the bugs and defects we're finding. Hopefully soon! — Trevor Bolliger, WMF Product Manager 🗨 22:09, 5 November 2018 (UTC)

Suggestion: Block creating pages only

Hi, from time to time, I see users who create a lot of articles of poor quality. Blocking page creation for them is better than blocking everything, as they cannot fix their articles when blocked. I know we can define a group that have privileges revoked, but this would be simplier. Can you consider this? --Martin Urbanec (talk) 13:57, 2 November 2018 (UTC)

@Martin Urbanec: Yes, I think this is a perfect example of when partial blocks can be useful. We plan to build this in November/December in phab:T199918. This would prohibit them from creating pages in all namespaces. We still need to determine if this block would also prohibit the user from creating subpages of their username or pages in the Draft namespace (if available.) Do you have opinions about that? — Trevor Bolliger, WMF Product Manager 🗨 16:37, 2 November 2018 (UTC)

The best thing would be to have a way how to choose what it would do per block. It can be sitewide page creation block or per namespace page creation block. If you think this will complicate the form too much, we can stick to "block all"/"allow drafts". --Martin Urbanec (talk) 16:43, 2 November 2018 (UTC)

Because we're also building namespace blocking, which also prevents a user from creating pages within that namespace, the checkbox for 'creating pages' could allow for drafts, and if a user is so troublesome they could also receive a namespace block. Thank you for your two cents! — Trevor Bolliger, WMF Product Manager 🗨 17:22, 2 November 2018 (UTC)

Would the namespace checkbox allow page edit and forbid page create? If not, I still think it should be configurable (at least something like "block only articles"/"allow only personal space and drafts"/"block all page creations"). I can imagine user abusing capabality of editing personal space, for example, by creating a lot of useless drafts. Even it is acceptable by community to block them sitewide, even they correct mistakes at the same time, in this case, block would be slightly punitive and not only preventing. Also, it will make my work easier, as I won't have to weight "typo fixes with nonsense drafts or no nonsense drafts without typo fixes" or give shorter block than I would give to user who don't do constructive edits. Maybe adding checkbox "Prevent page creations only" to the namespace checkbox (and calling this "Prevent article creation only") would be enough. --Martin Urbanec (talk) 17:34, 2 November 2018 (UTC)

Namespace blocks will prohibit a user from 1) editing any existing page in that namespace 2) creating a new page or restoring a previously deleted page in that namespace 4) moving a page within, into, or out of that namespace and 6) deleting or protecting a page within that namespace, if the user hold admin permissions. I suggested a simple checkbox but I'm growing to like your idea of a dropdown better to allow for more specific control. I think we will want to keep the 'Namespace' block comprehensive (all 6 actions I mentioned previously) as the complexity could grow quite quickly. — Trevor Bolliger, WMF Product Manager 🗨 17:49, 2 November 2018 (UTC)

Bug "non-editing actions"

I've opened phab:T208645 regarding dealing with the condition when partial block is selected with no pages. The log reports the editor would have a general block against all 'non-editing actions' but they do not. See notes on the phab ticket. — xaosflux ^Talk 15:10, 3 November 2018 (UTC)

Hi @Xaosflux: I left a response on the ticket, but I'll paste my comment verbatim here, too:

#1 — The concept of "non-editing actions" — We want to make it possible for admins to configure a block so the user can edit all pages but not perform certain actions, such as uploading files, creating new pages, or emailing other users. Currently the only pieces of this functionality that work are sending email and creating accounts (both of which are minimally used by logged-in users, but were 'free' because they were already part of Special:Block.) Our team is working on bugfixes to page blocks and then adding in namespace blocks. We'll get to the upload and page creation blocks after that.

#2 — The UI of Special:Block — The final designs will better explain this. We released this first iteration of partial blocks to test wiki with an extremely minimal change to the UI. Our wireframes for the final design can be found here: phab:M255 and we will take phab:T202773 into a near-future sprint for development.

#3 — The log entry text of "non-editing actions" — The current phrasing of the log entry is proving to be confusing. We want to add the word specified to make it more clear: phab:T208806.

Hope this answers what this functionality is attempting to accomplish. — Trevor Bolliger, WMF Product Manager 🗨 22:07, 5 November 2018 (UTC)

Replied at phab, looks like there is a logic check missing still. — xaosflux ^Talk 22:54, 5 November 2018 (UTC)

Not sure why this obvious logic-checking bug has been listed as "new feature development". — xaosflux ^Talk 18:40, 4 March 2019 (UTC)

I classify this defect as a user-error type defect, and it's straightforward to go back to Special:Block to correct the block. Therefore, I see this as low priority and low risk and not worth the time investment to address until we gain better understanding if there are more fundamental changes we need to make first. — Trevor Bolliger, WMF Product Manager 🗨 18:57, 4 March 2019 (UTC)

A request to test

Hi, TBolliger. You said that an admin on other wiki (and I am indeed, on hewiki), can ask to test the partial block mechanism. Thank you. IKhitron (talk) 12:50, 9 November 2018 (UTC)

Hi, IKhitron, I added admin rights for you on testwiki. I have an account, Lexingtonisforwiki on test wiki that you can test with (add blocks and unblocks, etc.) if you want. And happy to answer questions. SPoore (WMF) , Trust and Safety Specialist, Community health initiative (talk) 13:35, 9 November 2018 (UTC)

Thanks a lot. For now, I'm blocking my poor bot. IKhitron (talk) 13:38, 9 November 2018 (UTC)

Well, SPoore, the first issue: I can't insert a name of a red page. IKhitron (talk) 13:41, 9 November 2018 (UTC)

IKhitron, I think that the situation that you are describing is in phab ticket T201853. Because of the amount of work needed to add it, it has been put on hold until the MVP is built and deployed. At a later date, AHT team will evaluate which features, including this one, are feasible to add. SPoore (WMF) , Trust and Safety Specialist, Community health initiative (talk) 14:20, 9 November 2018 (UTC)

Indeed. I thought it already works... IKhitron (talk) 14:22, 9 November 2018 (UTC)

Possible to test on beta wmflabs? --Wargo (talk) 21:40, 16 January 2019 (UTC)

@Wargo: This should already be enabled on beta Wikipedia, but a more stable version is on http://test.wikipedia.org/wiki/Special:Block. If you're an admin on another Wikimedia wiki, Sydney can get you admin access on test wiki. — Trevor Bolliger, WMF Product Manager 🗨 00:46, 17 January 2019 (UTC)

@Wargo: I've added sysop access for you on testwiki, don't blow up the test wiki please :D — xaosflux ^Talk 03:20, 17 January 2019 (UTC)

Thank you, -Wargo for volunteering and User:Xaosflux for adding admin access. SPoore (WMF) , Trust and Safety Specialist, Community health initiative (talk) 20:28, 17 January 2019 (UTC)

Could I please get sysop rights on Testwiki? I had it for a week in November and I'd like to test the block feature again. -kyykaarme (talk) 06:57, 17 April 2019 (UTC)

kyykaarme, Done. Thanks for testing. SPoore (WMF) Strategist, Community health initiative (talk) 14:11, 17 April 2019 (UTC)

Hello, @SPoore (WMF):: Please add testwiki sysop rights for testing, thank you! — Aron M (talk) 07:19, 20 September 2019 (UTC)

Hello — Aron M, we are only giving admin access to tryout partial blocks to people that are already an admin on another wiki. I checked and didn't see that you have any admin rights so I won't be able to. Thanks for your interest in the new feature. SPoore (WMF) Strategist, Community health initiative (talk) 12:35, 20 September 2019 (UTC)

@SPoore (WMF): That's right, but unimportant. You might get more efficient feedback from developers, who have more experience in UI design, but don't intend to become admins. Furthermore, non-admins are affected by the implementation of the tool as well: the easier and more intuitive to use partial blocks, the more likely admins will use it, instead of the simpler project-wide block. Therefore it is counter-productive to make that distinction, and have only current admins to test this feature. I hope you reconsider. — Aron M (talk) 22:00, 20 September 2019 (UTC)

Hello, @SPoore (WMF):, it's been a month, and it seems this was lost in the long list of pings you might be receiving, but I'm still hoping to receive a response to the above request. Thank you. — Aron M (talk) 01:41, 25 October 2019 (UTC)

Hi Aron Manning, At this time AHT is not working on feature enhancements related to partial blocks. Our primary interest in giving test wiki access to admins is for them to check out the new features and point out any way that it could interfere with using Special:Block on their wiki. For that reason, I'm going to again decline your offer at least for now. Regards, SPoore (WMF) Strategist, Community health initiative (talk) 15:37, 25 October 2019 (UTC)

Arabic Wikipedia

Tracked in Phabricator:
Task T217283 resolved

Hello (per TBolliger edit) I happy to say that Arabic Wikipedia will be interested in partial blocks. Do you need a community consensus (I can open a discussion on arwiki for 7 days)? --Alaa :)..! 02:16, 14 February 2019 (UTC)

Hello Alaa , We are pleased to learn that Arabic Wikipedia is interested in partial blocks. I will work with you to get good information for the arwiki community about what to expect when partial blocks is introduced (deployed). I can share with you a description of Special:Block with partial block function that you can translate. I can also share with you the pages that Italian Wikipedia created about partial blocks so you can see if they would be useful to add to arwiki (with modifications as needed.)

I can give you these pages and you can open a community consensus discussion. Thank you for your offer to help! SPoore (WMF) Strategist, Community health initiative (talk) 17:53, 14 February 2019 (UTC)

@SPoore (WMF): Thanks. Yes, please share this pages with me as soon as possible Best --Alaa :)..! 17:59, 14 February 2019 (UTC)

T217283 --Alaa :)..! 15:38, 14 March 2019 (UTC)

autoblocks

Hi all, so when "Automatically block the last IP address used by this user, and any subsequent IP addresses they try to edit from" is used - what blocking parameters are applied to those autoblocks if the initial block is a partial block? — xaosflux ^Talk 17:02, 28 February 2019 (UTC)

• The autoblock's parameters will exactly match the parameters of the parent block, for both sitewide or partial. For example, if I partially block a user from the page 'Mars' with the "Automatically block [...]" checkbox checked, the autoblock would be a partial block for the page 'Mars' only. The only exception is length — autoblocks are never longer than 24 hours. — Trevor Bolliger, WMF Product Manager 🗨 19:31, 28 February 2019 (UTC)

If a given user is blocked from editing a category, how would that work in practice?

Would it prevent the user from adding/removing articles to a given category, and does that block filter down to the articles therein (perhaps even admin-configurable)? Dax Bane (talk) 11:31, 3 March 2019 (UTC)

Editing category pages. Blocking editing pages belonging to category is planned but for the future - there are some issues including depth configuration and possibility to remove from category. --Wargo (talk) 11:37, 3 March 2019 (UTC)

How about a dropdown or radio option when partially blocking categories: category only, immediate pages only (only pages directly referencing the category would be affected), recursive/cascading (all pages, including those in subcategories) Dax Bane (talk) 00:29, 4 March 2019 (UTC)

@Dax Bane: If a category page (e.g. Category:Weather) is provided in the Pages field, only the page Category:Weather will be uneditable. The pages and sub-categories within the category will still be editable.

As Wargo mentioned, category blocks have been put on hold for the time being, and most likely will never be built due to the problems of depth and the social issues with users being able to weaponize categorization against each other. We have considered a tool that would allow an admin to bulk add the current pages within a category to a page block, but that idea is also on hold given the infancy of partial blocks. (phab:T201102). — Trevor Bolliger, WMF Product Manager 🗨 16:53, 4 March 2019 (UTC)

Pre-enabling

Polish

I started this thread --Wargo (talk) 09:48, 14 March 2019 (UTC)

Thanks, Wargo. Let me know if there are any questions that I can answer. SPoore (WMF) Strategist, Community health initiative (talk) 15:06, 14 March 2019 (UTC)

@Wargo:, I looked through the discussion and it seems that some people have questions about being one of the first wikis and whether that it is going to have too many bugs. I can let you know that there are not significant bugs that we know about and we are almost finished working on partial block. Some decisions still need to be made around how many pages can be added to a partial block. And then to consider any changes about the way that they are logged. We can make better decisions if more people are using partial block and can give us feedback about that it is being used. So, that's why we will be happy of Polish Wikipedia decides to deploy it now. Also, if it is helpful, I can share with you the pages that Italian Wikipedia made that explains its use. These probably could be adapted for use on plwp. SPoore (WMF) Strategist, Community health initiative (talk)

No, not about bugs. Just asked when will be for all wikis by default. There are concerns about what if someone is blocked on talk pages (because harsh language) but need to consult changes in article. Idea is to use only this user's talk page. --Wargo (talk) 16:16, 14 March 2019 (UTC)

Thanks for clarifying. I appreciate it. SPoore (WMF) Strategist, Community health initiative (talk) 16:20, 14 March 2019 (UTC)

Hello Wargo, it looks like the discussion on plwp is still attracting a few comments. Does the discussion need to stay open for longer or do you think that plwp is ready for me to schedule a time for developers to SWAT deploy it? FYI: AHT is tracking test deploys in this phabricator ticket. Let me know if I can answer any questions for the you or plwp community. SPoore (WMF) Strategist, Community health initiative (talk) 16:53, 25 March 2019 (UTC)

I think that we do not need more time for discussion and Polish community is ready to try it out. Gdarin | talk 16:17, 26 March 2019 (UTC)

Done, phab:T219327. --Wargo (talk) 07:56, 5 April 2019 (UTC)

Let me know if you have any questions that I can answer. SPoore (WMF) Strategist, Community health initiative (talk) 16:53, 5 April 2019 (UTC)

My proposals

1. Collapsing partial block options when set to full block so form will not be long.
2. Wildcards, for example for subpages: Wikipedia:Talk/*

Wargo (talk) 16:33, 14 March 2019 (UTC)

@Wargo: Thank you for the proposals. The first has been suggested on phab:T217363. I'll not that you share the space concern, but please feel free to leave a comment if you have a Phabricator account.

Unfortunately, wildcards cannot be supported with the current implementation (nor 'redlink' pages that don't exist, such as Fifa World Cup 2090) because partial blocks are stored as page IDs in our database. If the need for redlink or wildcard blocks becomes apparent, the WMF could build it but we'd like to see how these current options work first before committing to more months of development. — Trevor Bolliger, WMF Product Manager 🗨 17:05, 14 March 2019 (UTC)

I think all banned user should give a second chance to show how they can be trusted with their edit. Failing to be trusted to edit can result in a block. I suggested you to add a feature which disallowed administration and steward to block innocent users while the block system detect their diffs is correct or not. Signed Benjaminzyg

Enable on zhwiki

Per local discussion. Please enable the partial blocks on zhwiki. --Xiplus (talk) 13:34, 29 March 2019 (UTC)

Thank you Xiplus for letting us know that zhwp is ready to enable partial blocks. We'll schedule a time to deploy it; probably in the next week or so. This page Description_for_use_in_local_wiki_communities can be translated to communicate to administrators and other users about the way that the new feature works. The page also explains the types of feedback we would appreciate learning from users on admins and users about the functionality and design of partial block. SPoore (WMF) Strategist, Community health initiative (talk)

@SPoore (WMF): Ok. I will translate it and notify the community. --Xiplus (talk) 01:40, 31 March 2019 (UTC)

@SPoore (WMF): The page was already translated into Chinese and shared to the community. Please advise if there still anything we need to do before the deployment of partial blocks to zhwiki. Thank you. --J.Wong 05:10, 6 April 2019 (UTC)

Hi Xiplus and J.Wong, Partial block will be deployed to zhwp in approximately 24 hours. The SWAT deploy is scheduled for 16:00–17:00 UTC. SPoore (WMF) Strategist, Community health initiative (talk) 18:26, 16 April 2019 (UTC)

Xiplus and J.Wong, it is live now. If zhwiki experiences any issues you can contact me or comment on the phabricator task. SPoore (WMF) Strategist, Community health initiative (talk) 16:49, 17 April 2019 (UTC)

Enable in Telugu Wikipedia

Hello,
I am an admin in Telugu Wikipedia. I believe this tool would be very helpful and started discussion in Village pump to enable this tool in Telugu Wikipedia on March 2019. Many admins and users came forward to support the idea and got consensus. I request technical team behind this initiative to enable this tool in Telugu Wikipedia. --Pavan santhosh.s (talk) 07:45, 21 April 2019 (UTC)

Hello Pavan santhosh.s, thank you for starting the discussion on Telugu Wikipedia. Here is the Phabricator task where Anti-Harassment Tools team will set up and track deploying on Telugu Wikipedia. I'll also announce it here. Additionally, this page on Meta describes how partial blocks works and some of decisions that Anti-Harassment Tools is still making as we finish developing it. if you are interested, I can also share some policy and help pages other wikis wrote about using it on their wiki. SPoore (WMF) Strategist, Community health initiative (talk) 20:19, 30 April 2019 (UTC)

Nonexistent page

How it is handled when blocked page is deleted after userblock refering them? --Wargo (talk) 23:12, 22 April 2019 (UTC)

Enable on Japanese Wikipedia

Hello there - I am an adminstrator of Japanese Wikipedia and would like to request for the enablement of partial blocks in Japanese Wikipedia, as per the discussion in Village Pump. At present we are under discussion regarding how partial blocks/unblocks should be done and how the related policies and guidelines should be changed, but have reached a concensus that (technically) enabling the feature can be done in parallel. Thank you very much for your help.--ネイ (talk) 14:27, 6 May 2019 (UTC)

Hello ネイ , thank you for letting me know. I'll let the developers know and will let you know the date when it will be enabled. SPoore (WMF) Strategist, Community health initiative (talk) 16:29, 6 May 2019 (UTC)

Hello - just wonder if there is a tentative date of when it can be enabled?--ネイ (talk) 02:47, 14 May 2019 (UTC)

@ネイ: Sorry for the late reply. Partial blocks should now be available on Japanese wikipedia. I'd be happy to hear any feedback you may have for us! Thank you. -- NKohli (WMF) (talk) 17:57, 5 June 2019 (UTC)

Why different default settings for sitewide and partial blocks

The current setting in TestWiki is that for a sitewide block the "Account creation" is checked by default, meaning that the blocked user can't create an account. But in the partial block it is not checked. I don't understand the logic in this, why are the default settings different? Why would a partially blocked user have the right to create another account? Also, in the partial block settings the admin can't choose to block the user from editing their own talk page. Why? -kyykaarme (talk) 09:20, 6 July 2019 (UTC)

@Kyykaarme: partial blocks may be used for "content" type enforcement of a user (e.g. you may not edit this content page for a while only) so it makes sense that it doesn't include "extra" things along with it; as for the user-talk part, this is likely due to the special mechanics used in the existing blocking program. It is possible to partial-block someone that includes removing TPA, but it is not done by overriding the normal override against total blocks, it is done using the new blocking parameters (i.e. you can explicitly list their own talk page as a "page" they are blocked from). — xaosflux ^Talk 13:44, 6 July 2019 (UTC)

I did some more testing and found out that if you choose "user talk" in the blocked namespaces list, then you are also able to remove TPA. -kyykaarme (talk) 09:04, 17 July 2019 (UTC)

Not that removes their ability to use the entire user_talk namespace, not just their "own". — xaosflux ^Talk 17:34, 18 July 2019 (UTC)

It works the same way as it does with the sitewide block: you can remove TPA by checking the box, but it's not checked by default so that leaves the user with the ability to edit their own talk page. It's not very logical but maybe there is a technical reason. Like you mentioned, in the sitewide block everything is blocked by default except the user's own talk page, and in the partial block if you choose "user talk", every user talk page is blocked except the user's own. *shrug* -kyykaarme (talk) 20:40, 21 July 2019 (UTC)

@Kyykaarme: perhaps you have someone that you want to block from editing other user's talk pages, you can block the "user talk" namespace - then you can override that block with the checkbox setting to let them edit only their own user_talk page if you wanted to. — xaosflux ^Talk 00:33, 22 July 2019 (UTC)

Users being blocked partially by mistake

Hi, I have noticed that many times users are being blocked partially by mistake. For example itwiki (the user can still edit), mediawiki, meta-wiki. Should there be some kind of error message when blocking user partially and when the setting is block only sending email or when everything is empty? Stryn (talk) 11:21, 16 July 2019 (UTC)

It sure doesn't help that this feature made Special:Block even more bloated and messy. For every step we do in the direction of usability, we do two steps back. :( Nemo 13:40, 16 July 2019 (UTC)

@Stryn: I note that when blocking someone, the default block is Sitewide. Perhaps one way we could solve this is if the user selects Partial then we pre-fill the namespace field with something sensible? Or perhaps show a warning to user that they haven't selected a namespace/page name before they save? -- NKohli (WMF) (talk) 17:10, 16 July 2019 (UTC)

@NKohli (WMF): I think a warning message like "please choose a page or a namespace for a block" should be shown instead. Stryn (talk) 17:20, 16 July 2019 (UTC)

But what if we don't want to block any page or namespace, and we actually just want to prevent the user from sending emails, for example. I guess it could ask to confirm that you really don't want to choose any page or namespace, and then do the block. -kyykaarme (talk) 22:46, 16 July 2019 (UTC)

Partial blocks currently allow for completely useless (phab:T208645) blocks, as well as ones that are useless in coordination with our other parameters (such as blocking email access from ip addresses, which we don't allow to send email in the first place). — xaosflux ^Talk 17:36, 18 July 2019 (UTC)

Tagging partial blocks in the block log

Could a tag be made for the partial blocks to be tagged in the log Special:Logs/block? It would be beneficial to be able to search partial blocks easily, especially in the beginning, to see how they work and how admins are using them. Another option would be to add a new "sub log" for the block log (now there is Block, Block modification and Unblock), but maybe that's too complicated to make. -kyykaarme (talk) 23:23, 30 July 2019 (UTC)

Starting discussion on Dutch Wikipedia

Hi there, we are planning to start the discussion about enabling the partial blocks function. In some of the posts above this section some people where talking about example policy's and stuff. I would like to receive some text I can translate and use on Dutch Wikipedia. I've created the first page about partial blocks but I don't know what to write about is now. If you like to check it out, you can find it here. We are planning to make some rules and then start a voting about it. I think we can have the results in about a month. Anyway, I think it is a very nice function :) thank you very much for improving the software in a way we can do more for and with our community. With this function we can finaly keep pages open and editable when other users are fighting and reverting. It also would make it more easy for our Arbitration Committee to enable restriction for users who may not edit in specific namespaces. I can't wait to see it getting enabled. DutchTom (talk) 00:44, 20 September 2019 (UTC)

Hi DutchTom, I'm glad to learn that Dutch Wikipedia is interested in enabling partial blocks. I looked at the page that you started and it looks good. The pages on different wikis will looks somewhat different because wikis document policies and help pages differently. For example, since you have an Arbitration Committee you mention that on the page and that seems right.I'll share a few pages that show what other people have done.

• There is the page on MediaWiki that describes blocks. We changed it to saw that the there are now two kinds of blocks.
• Italian Wikipedia was the first wikis to use partial blocks and created this [help page.

I'm also happy to answer questions. SPoore (WMF) Strategist, Community health initiative (talk) 15:52, 20 September 2019 (UTC)

The discussion moved to nl:Overleg Wikipedia:Deelblokkade if you are interested in following it (I bet you need Google Translate) DutchTom (talk) 20:46, 23 September 2019 (UTC)

Enabling partial blocks on nl.wikipedia.org

Per this page I would like to request early enabling for nl.wikipedia.org so we can test this feature and start writing rules and policies. Thanks in advance, DutchTom (talk) 23:30, 30 September 2019 (UTC)

Sorry for the slow reply, I've been off on vacation for a few days. Pinging @NKohli (WMF): so we can get it scheduled. Let me know if I can answer any questions. SPoore (WMF) Strategist, Community health initiative (talk) 14:12, 2 October 2019 (UTC)

Thank you! We will start testing when the function is available, when everything works as expected I hope we can start using it in December 2019. I will post a update here when there is something to share. If there are any questions from the community or the administrators I will write them down here. Thank you so much for your help! DutchTom (talk) 13:40, 3 October 2019 (UTC)

I created a taks (my first one so I hope I've done it right): T234685. Greetings, DutchTom (talk) 19:00, 4 October 2019 (UTC)

Done the feature has been enabled, the testing period is about to begin. DutchTom (talk) 12:43, 7 October 2019 (UTC)

I saw that partial blocks deployed. Let me know if you have any questions about how the feature work. You can report any bugs here or on phabricator. SPoore (WMF) Strategist, Community health initiative (talk) 12:52, 7 October 2019 (UTC)

Portuguese Wikipedia

Hi! I'm here only to inform that Portuguese Wikipedia decided, by unanimous consensus, adopt partial blocks. A task in Phabricator have already been open. Érico (talk) 02:02, 25 September 2019 (UTC)

Hello User:Érico, Partial blocks are deployed now on Portuguese Wikipedia. You can let me know if you have follow up questions, bugs to report, or want to know more about the policies that other wikis are using. Also bugs can be reported on Phabricator. General feedback also can be left on this feedback page or emailed to me or NKohli (WMF).

Abuse Filter

¿Will abuse filters enabled to block be able to make partial blocks?--SRuizR 16:29, 14 November 2019 (UTC)

@SRuizR: this is being considered, it is not currently available. You can track progress on the effort by subscribing to phab:T201815. — xaosflux ^Talk 20:00, 14 November 2019 (UTC)

Feature suggestions

Partial Blocks are a highly anticipated development, practically missing from the project since the community explosion around 2005. Site-wide blocks were designed for vandalism-only accounts in the early days of wikipedia, when contentious topics and disagreement between editors was not as common as nowadays. I've suggested partial blocks in the recent community discussions, unaware that it was already in development.

The purpose of blocking is to stop disruption, that usually happens in a specific area (an article / a topic / between specific users / etc.). A site-wide block unnecessarily removes the ability of a user to contribute to other, non-problematic areas, and removes the ability to communicate on-wiki, such as to participate in their own case on noticeboards, or in arbitration. This just causes problems and unnecessary bureaucratism, as seen in some of the comments in the well-known Fram case on enwiki.

Site-wide blocks are also unnecessarily punishing in non-trivial cases, when two good-faith editors disagree, and the dispute escalates. Because of this, the threat/fear of being blocked is often present in purely content disputes, negatively influencing the neutrality of the outcome. Partial blocks are a less harmful solution to minimize disruption.

—Aron Man.🍂 edits🌾 06:37, 10 December 2019 (UTC)

Design screenshots: phab:M255, Partial blocks#Second designs

• Design suggestion: list of articles recently edited. It would ease the task of admins selecting the blocked pages, if a list of articles recently edited by the partially blocked user were shown in a drop-down list, when that input field is selected.
• Design suggestion: white-list of pages that can be edited. In the case of site-wide blocks, the list of pages should serve as a white-list of pages that can be edited. The default value could be the noticeboards and arbitration pages (different per project), where the user can participate in, or appeal their case. In case of a non-appealable ban, or abuse of these pages, these can be removed from the list.

Related phabricator ticket, and another similar ticket (closed, although the "duplicate" ticket does not cover this use-case). — Aron M (talk) 23:17, 19 September 2019 (UTC)

Also requested on talk page.

• Design suggestion: pop-up editor for long lists of pages. To use partial blocks for topic bans that aren't covered by a single category, one has to add a great number of pages to the list, preferably in batch. This is not the primary use-case, therefore the UI necessary to do this should not be part of the basic blocking page, but rather a pop-up, that has 2 columns: the added pages on the left side, a search field and found pages on the right side. Adding pages is done by double-clicking them on the right side, or by selecting more pages (with shift-, ctrl-click, or with a selection box while the mouse button is pushed), then clicking an left-pointing arrow button between the two columns. Removing pages is done similarly on the left side.
• Multiple blocks with different expiration times will become necessary to allow long-term topic bans and short-term page blocks for the same user at the same time. Sample design: Community health initiative/Partial blocks/Multi-blocks
• Category blocks are necessary to implement topic bans.

—Aron Man.🍂 edits🌾 06:37, 10 December 2019 (UTC)

• Suggestion - is it possible to implement a block feature like what FB uses that allows one user to block (not see) comments by another user they tend to conflict with, the latter of which is probably what leads up to most iBans. Perhaps it will help cut down on disputes on an article TP as well as a user TP. They can see the edit history and contents of an article in order to avoid violating PAGs or DS but they cannot see each other's comments on TPs - it's the sticks and stones effect ...but words will never hurt me, especially when I can't see them. Atsme^📞📧 13:50, 17 December 2019 (UTC)

  @Atsme: once the revision is saved the only possible way this could currently work would be to "mute" the entire revision - there is no concept of "your comment" vs "my comment" on a saved page of wikitext. May be possible to develop an additional "mute" function for FLOW. — xaosflux ^Talk 16:45, 17 December 2019 (UTC)

specialblock-partialblock-banner

Tracked in Phabricator:
Task T240300

So is specialblock-partialblock-banner going to stay on forever? We have already customized our Special:Block page significantly on enwiki and don't really need another banner. — xaosflux ^Talk 15:57, 20 January 2020 (UTC)

We also have a local description page and it doesn't look like the "Learn more" target is adjustable locally? — xaosflux ^Talk 15:59, 20 January 2020 (UTC)

@SPoore (WMF): any information on this? — xaosflux ^Talk 16:00, 20 January 2020 (UTC)

Appears to be related to phab:T240300 - User:NKohli (WMF) do you have more information? The task description there says "Also it will not be displayed on enwiki"? We shouldn't send all of our admins to meta to discuss any of our issues. — xaosflux ^Talk 16:03, 20 January 2020 (UTC)

@Xaosflux: We have taken off the banner now. It was supposed to be on for two weeks to make sure people have a way to learn about the new feature and provide feedback if they want to. Thanks and sorry about the delay in my response. -- NKohli (WMF) (talk) 19:50, 22 January 2020 (UTC)

Two blocks at the same time

I think I have reached a limitation of this partial blocks tool. I just happened to come to the case where I have no solution. A specific user should have two partial blocks:

• One from editing a specific page for 1 month, starting 8 February, for edit wars
• One from editing Template namespace for 3 days, starting 14 February, per ArbCom decision.

Looks like there is no way to do it. I can either block from both with the same reason for the same duration or none at all. In both cases this needs a manual action: either setting both blocks at 3 days and restarting the first one manually 3 days later, or setting both blocks at 1 month and going back to remove the second one 3 days later.

This is very suboptimal, and it was managed better with old good Abuse filters.

Is having two blocks simultaneously possible now? Is such feature possible in the near future? Thanks — NickK (talk) 03:08, 14 February 2020 (UTC)

@NickK: This is a known limitation and feature request. I've informed the devs and T&S in December that this feature will be needed (see my comment above). It seems to me the devs are currently occupied with CheckUser 2.0 and this feature is not scheduled yet. That might mean months or even a year before it's developed. It is possible though. —AronM🍂 edits🌾 17:58, 16 February 2020 (UTC)

Seems a bit silly that an arbitration committee is getting involved with a 3 day remedy somewhere, but I guess that is up to them - if someone wants to create creative blocks overlaps, they can handle it manually for now. You can always just forget pblocks and use a site block too.. — xaosflux ^Talk 23:21, 16 February 2020 (UTC)

Seeking input on two features for partial blocks

Hi all! Our team has set aside some time this quarter to do some maintenance work on partial blocks. We are considering working on two key features that we have heard a lot about from the communities. These are:

1. Block user from creating pages: This task would allow a block to specifically block a user from creating non-existent pages. This would not apply to converting existing redirects to full pages. That is a lot harder to do technically, unfortunately.

2. Block user from uploading files: This task would allow a block to specifically block a user from uploading files on a wiki.

What are your thoughts, concerns, ideas about these proposed features? Your comments here will help us decide what we end up working on so please take a moment to express your support/opposition.

Apart from that, I want to take moment to thank DannyS712 who has been consistently offering a helping hand with this project. I want to acknowledge his contributions which might go unnoticed by those who don't hangout on phabricator. :)

Thanks for your time. -- NKohli (WMF) (talk) 21:51, 2 May 2020 (UTC)

• Thanks for these features!
  • Regarding upload blocks, I guess on most wikis, blocking a user from the "File:" namespace almost achieves the same result, but may be unnecessarily restrictive. Especially for file-centered communities like Wikimedia Commons, the difference may be significant and helpful.
  • Regarding page creation blocks, if I understand correctly, they can not be limited to specific namespaces, such as the main namespace. Else, in combination with a pagemove block, they could be used to enforce a draft review process such as en:WP:AFC.
  • Do I correctly understand that a page creation block also implies a block from uploading new images, while still allowing the replacement of existing images?
  ToBeFree (talk) 23:37, 2 May 2020 (UTC)

  @ToBeFree: Thanks for the feedback. Regarding restricting page creation blocks to a specific namespace, I am not certain if it's doable. Same for your second question regarding page creation block restricting image uploads. I will check with the engineering team and get back to you on both fronts soon. -- NKohli (WMF) (talk) 05:04, 5 May 2020 (UTC)

  @NKohli (WMF): I think most administrators would prefer a multi-block feature primarily. I remember a TechCom RfC on this but I don't think there was a conclusion? Both these features can be implemented with the edit filter if we really wanted it, but having the option is good, definitely. --QEDK (talk 桜 enwiki) 07:10, 3 May 2020 (UTC)

  @QEDK: I have been following the multiblocks requests but my understanding on the engineering front is that it is very difficult to implement. I feel it would be better to focus on features that are easier to deliver and would still be useful to our users. For my information though, can you tell me more about what your prominent use cases from multi blocks would be? It would help improve my understanding for why it's important for administrators. -- NKohli (WMF) (talk) 05:04, 5 May 2020 (UTC)

  @NKohli (WMF): Hmm, that's unfortunate, it would be a great feature. Two use-cases that immediately come to mind: the Arbitration Committee might place sanctions of variable length, site-banned for one year and indefinitely banned from editing the Portal namespace and secondly, administrators imposing blocks can be more specific, sockmasters can be banned from editing for one week and banned from creating other accounts indefinitely. --QEDK (talk 桜 enwiki) 08:07, 11 May 2020 (UTC)

On fiwiki we have a problematic user (who is blocked) using IP addresses always from the same range (a popular range, thus we can't block the whole range), but I think phab:T199918 will help us, then we can prevent all new page creations from IP addresses in this range and ask useful editors to create an account if they want to create new articles. Stryn (talk) 05:47, 5 May 2020 (UTC)

How will you keep track of the lost legit article creations? Nemo 06:26, 5 May 2020 (UTC)

Nemo_bis, contrary to an edit filter action, a block would prevent the editing interface from appearing in the first place, wouldn't it? ToBeFree (talk) 13:15, 5 May 2020 (UTC)

It would, and anyway, if it's the only way to prevent new page creations as it seems that they can't make the red article titles work in partial blocks. There's not often new page creations from this range anyway. Plus we also globally block IP ranges that prevents many anonymous users from editing; they can always create an account. Stryn (talk) 17:36, 5 May 2020 (UTC)

@Stryn and ToBeFree: Given a choice between blocking a user from creating specific articles versus blocking a user from creating new articles in a specific namespace -- do you think one would be more beneficial than the other? I am not sure if we can do both but it would be helpful to know what's more ideal for the community. -- NKohli (WMF) (talk) 21:11, 7 May 2020 (UTC)

Thank you very much, NKohli (WMF). As page protection ("salting") can already be used to prevent the creation of specific unwanted articles, I think a block from creating articles in a specific namespace is a more important feature. ToBeFree (talk) 21:56, 7 May 2020 (UTC)

• As a new page patroller, a block on creating new articles might be helpful to preventing undisclosed paid editing and other forms of COI, along with possibly forcing new, accidentally problematic, non-communicative users to actually communicate. I fully support that feature. I have no strong opinion on partial blocks for file uploads. --I dream of horses (talk) 08:05, 11 May 2020 (UTC)
• @ToBeFree, Stryn, Nemo bis, and I dream of horses: Hello all. It's been a year since this conversation and I want to heartily apologize for not getting this work through. Our team's priorities and resourcing changed and we were unable to deliver on our goals. This was outside of our control. However we are now getting back to delivering on this, and more. I have created a post on the Blocking tools and improvements talk page. Your feedback will be welcome. Thank you, and sorry again. -- NKohli (WMF) (talk) 12:41, 7 April 2021 (UTC)

  Thank you very much for the notification and the continued work on this; absolutely no worries from my side. ToBeFree (talk) 13:09, 7 April 2021 (UTC)