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

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

Second designs[edit]

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

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

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

Here are the latest wireframe designs:

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

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

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

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

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

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

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

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

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

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

option to disable sitenotice banner[edit]

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

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

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

Inquiry[edit]

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

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

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

More about logs[edit]

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

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

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

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

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

  1. We propose no limit to the pages and namespaces that a user can be blocked from.
  2. If a page name is too long to appear on one line inside the text box it will be truncated with an ellipsis (...) and hovering over it with a mouse will display a browser tooltip with the full name. We do not have a solution for touchscreen devices.
  3. Blocks are local, so only page names will be required. For example, on the French Wikipedia 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[edit]

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

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

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

Allow admins to block non existing pages[edit]

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

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

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

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

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

User specific blocks won't work alone[edit]

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

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

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

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

Interaction ban[edit]

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

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

Feedback summary, August 22[edit]

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[edit]

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[edit]

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[edit]

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)