Please do not post any new comments on this page. This is a discussion archive first created on Error: Invalid time., although the comments contained were likely posted before and after this date. See current discussion.
in AbuseFilter already bans a user from editing a specific page. I do not think that developing one more feature to do this is a good idea — NickK (talk) 17:28, 4 October 2017 (UTC)
By the way, per category ban with depth 0 is also possible:
What would be really interesting is a per category ban with depth 1 or more, e.g. a ban from Category:Music should also result in a ban from Category:Musicians. This option is not available at the moment but would be very useful (say, banning from Category:Music with depth 3) — NickK (talk) 17:32, 4 October 2017 (UTC)
There is a limit to how many conditions all abuse filters of a wiki can contain ($wgAbuseFilterConditionLimit), and in some wikis, for instance in Russian Wikipedia, that limit is reached, so they are not able to add more conditions. Per-user clauses like the example are a luxury for them. --Base (talk) 18:30, 4 October 2017 (UTC)
@NickK: The idea of adapting AbuseFilter was suggested by a few other users, and I think it's a pretty solid idea. We haven't done any technical investigation — it may turn out to be a nightmare to actually adapt, but that's have the fun of web development! The biggest reason AbuseFilter is not currently used to address individual users (on most wikis) is condition capacity, exactly as User:Base mentioned. However, if we were to have an identical system that only ran for identified users, the rest of the editing population wouldn't be affected by the potentially slower performance of running additional filters. — Trevor Bolliger, WMF Product Manager🗨18:56, 4 October 2017 (UTC)
@TBolliger (WMF): Thank you for this comment. Perhaps in this case we can get an option to implement a filter only to a particular user or something like that (like, we wrote a filter but its condition apply only to <username> or <list of users>)? That way it does not affect this limit for anyone else and we would not have to create a completely new system — NickK (talk) 21:03, 4 October 2017 (UTC)
Latest comment: 7 years ago3 comments2 people in discussion
I have also found out that namespace bans are one of common bans, at least in Ukrainian Wikipedia. I could think of the following cases (all of which are real):
User talk namespace ban (except user's own talk page), for users harassing others with abusive messages on their talk pages.
Wikipedia namespace ban, for users harassing others in village pumps or discussions like deletion or page moves.
File namespace ban, for users repeatedly uploading copyright violations
Template namespace ban, for users causing edit wars in templates that affect multiple pages.
@NickK: Yes, this is definitely something that we will consider implementing. Thank you for providing these use cases — they were very helpful in understanding how this could be useful. Not all user conduct issues are alike, so one-size-fits-all responses are not always appropriate. Having a variety of blocking tools could help admins make fair, speedy decisions. — Trevor Bolliger, WMF Product Manager🗨18:20, 26 October 2017 (UTC)
Latest comment: 6 years ago2 comments1 person in discussion
Hi all, as I'm wrapping my head around the similarities between these four projects (page, namespace, category, upload, and block. Five if you include 'full site') I have made some back-of-napkin wireframes for what this tool could look like:
Setting a page block
Textarea disappears when a specific option is selected for expiration
Textarea disappears when a specific option is selected for reason
Setting a category block
Setting a namespace block
Setting a namespace block, if we want to support multiple namespaces at once.
Setting a file upload block
If we make this a part of regular Special:Block (and not a new tool) we can add the dropdown for 'Full site' block
The fields should have validation (e.g. a real user was provided and a real page name was provided). Are we missing any options for block parameters?
If a page is moved, the block should remain. (The block will be set by pageID which is permanent.)
We will need to decide how this all works for users without JavaScript enabled. We'll also need to decide about block logs and what the blocked user sees when they attempt to edit. We'll probably also have to figure out complicated logic about combined blocks (e.g. what if a user is blocked from both a specific page and a namespace containing that page — what messages do they see?) — Trevor Bolliger, WMF Product Manager🗨23:30, 21 March 2018 (UTC)
We discussed this a bit today and I've made a few other options. Our current thinking is that it will be best 1) if this is integrated with existing Special:Block and 2) that admins be able to set complex blocks in one go (e.g. block a user from a category and a few specific pages.) Here are some illustrations:
If we integrated with Special:Block, the granular options could live behind a tickbox or dropdown.
Admins can set different types of subsections to block — pages, categories, namespaces, and uploading files.
This is a slightly more advanced layout and would require some logic to identify what the user is typing, but keep the UI simple.
Latest comment: 6 years ago10 comments5 people in discussion
Hello everyone! The Anti-Harassment Tools team at the WMF will start building these granular blocking tools in a few weeks and we've asked WMF designer Alex Hollender to help us make some wireframes so the tools are intuitive to MediaWiki users.
I've written a first draft of how we think this tool should work. You can read the full proposed implementation here but here are the significant parts:
Granular blocks (page, category, namespace, and file uploading) will be built on top of Special:Block. These blocks will function as if they were regular blocks and allow for the same options, but only take effect on specific pages.
We will add a new checkbox for "Block this user from the whole site" which will be checked by default. When it is unchecked the admin will be able to specify which pages, categories, and/or namespaces the user should be blocked from editing.
Granular blocks can be combined and/or overlap. (For example, a user could be simultaneously blocked from editing the articles Rain, Thunder, Lightning, and all pages inside the Category:Weather.)
Only one block is set at a time, to adjust what the user is blocked from the administrator would have to modify the existing block.
Block logs should display information about the granular block
When a blocked user attempts to edit an applicable page, they should see a block warning message which include information on their block (reason, expiration, what they are blocked from, etc.)
If a category is provided, the blocked user cannot edit either the category page itself and all pages within the category.
If the File: namespace is blocked, the user should not be allowed to upload files
We like this direction because it builds on top of the existing block system, both a technical and usability wise. Before we get too far along with designs and development we'd like to hear from you about our prosposal:
What do you think of the proposed implementation?
We believe this should be an expansion of Special:Block, but it has been suggested that this be a new special page. What are your thoughts?
Should uploading files be combined with a File namespace block, or as a separate option? (For example, if combined, when a user is blocked from the File namespace, they would neither be able to edit any existing pages in the File namespace nor upload new files.)
Should there be a maximum number of things to be blocked from? Or should we leave it up to admin discretion?
What if a person has multiple topic bans? Or gets blocked for say, 6 months, with an indefinite topic ban? One topic ban/block == one software based restriction == one entry in a DB table. Don't make things too complicated or difficult to understand, both from an admin and a coding perspective.
Should uploading files be combined with a File namespace block, or as a separate option?
We currently separate edit and upload protections. A file page can be edit but not upload protected and vice versa.
We believe this should be an expansion of Special:Block
You already know my thoughts on the issue. What would the database schema look like? Is shoving at least three more columns into the ipblock table a good idea from a DBA perspective? If you need another table, you should favor another special page (otherwise you increase the complexity of Special:Block itself). MER-C (talk) 13:07, 4 May 2018 (UTC)
@MER-C: The plan we've discussed so far has included introducing new tables. We're drafting the proposal during our current development sprint and proposing it to the WMF Database Administrators in phab:T193449. From a user interaction perspective, the database table schema should have no effect on if it is part of Special:Block or a new tool.
I acknowledge there are some benefits to creating this as its own tool, and we certainly discussed it last Friday as we were discussing the database schema and our implementation plan — but our design and feedback predominantly point to building as part of Special:Block. We are still open to allowing different nomenclature on a wiki-by-wiki basis if the need arises. — Trevor Bolliger, WMF Product Manager🗨22:54, 14 May 2018 (UTC)
A few comments and questions :
If a user is blocked from editing pages in a specific category, will they also be blocked from adding that category to a page? I think this would make sense, because otherwise, they could easily modify pages in such a way that they cannot edit them again (for instance, they see that they cannot edit a page, so they copy to code to a draft... and get blocked from editing it). This also applies to other kinds of blocks in case of a page move, but this should be less common.
How is it going to be possible to see the details of current and previous blocks? If it is possible to block a user on 50 pages, this may not fit in a log comment. It should be possible to see the parameters of previous blocks and copy them in case the user needs to be blocked again.
Information about the block: I am not sure if there is a already notification for blocks, but if not, I suggest to add one, rather than only telling the user about the block if they cannot edit a specific page (if user X is blocked on page P because of an edit war, and then continue the edit war on page Q, a sysop may consider to apply a full block... but what if X did not know about the first block?).
Several special pages cannot be used by blocked users. Users with a granular block should still be able to use them, at least in some cases (e.g. Special:Import).
Limits: Hopefully, there will be an API to control these granular blocks bot owner speaking ;-). It would be simpler if this is limited in such a way that it remains possible to read block parameters in a single API query (typically no more than 500 distinct values, which is still pretty high).
@Orlodrim: Thank you for your comments! Good question about adding the category to a page. I would say it makes logical sense, but we'd likely have to implement it in a different manner. I've created phab:T194694 to capture this idea. Does anyone else have thoughts on this point?
Our current proposal will be to add all the pages, categories, and namespaces in the block log. We asked about placing a limit on the number of items because we think it will become unmanageable for users to be blacklisted from so many articles. While we can technically build this in a manner where an unlimited number of pages can be set, we suggested adding a limit of items (pages + categories + namespaces) that a user can be blocked from, as we do not believe granular blocks should be overused. At some point, an editor that requires with this short a leash should be siteblocked. Do you agree with such a limit? or should we pursue a different design?
Our current plan is to surface the information about the block when the user attempts to edit the page. Right now this message (or a per-wiki customized version) appears when a blocked user attempts to edit and we plan to add information about what pages, categories, and/or namespaces they are prevented from editing. Full site block notifications are maual (short of Twinkle) so any notification system we build would be larger than just these granular blocks.
I have no problem in having small limit. In practice, 3 seem to be enough for all topic bans that could be enforced with that system on the French Wikipedia (according to the list of topic bans).
I do more then 1500 blocks a year, and granular blocks would only be an option for around 1% of these. For me it is a priority that the interface for the 99% do not become more complicated then today. Meaning the options for granular should not be seen in the "normal" interface, only in a special one acccesed from the standard one.Yger (talk) 05:52, 10 May 2018 (UTC)
Personally I don't like the idea of Special:Block extension (I suggested above that making it an extension of Special:AbuseFilter would make more sense), and I strongly oppose having only one block at a time. I can name a very common example: user X has a long-term (or permanent) ban from editing a page P or a category C, say, because of their strong NPOV on the topic that is unlikely to change (think of religion, politics, ethnic conflicts etc.). Later they make offensive comments in some unrelated discussions and they should be blocked for offensive behaviour for a short period to let them calm down. This would be a horror to manage: we should replace an indefinite ban from editing page P with a, say, 12-hour block from editing the entire site, but after this 12-hour block expires we will no longer have a ban from editing P as we would have only one block at a time. Now, as a Ukrainian Wikipedia sysop I can name at least a few dozen users who already have granular blocks via AbuseFilter (a majority of them having an indefinite upload ban, but a minority have something more tricky like editing specific pages, specific namespaces or pages with specific names), and we sometimes have to block them from entire site for unrelated reasons (mostly edit wars or offensive edits). I think we can set a maximum to some technical limit that is unlikely to be reasonably achieved (256 or something like that, as any user banned from more than 256 pages is likely to be indefblocked) without making it too restrictive — NickK (talk) 13:02, 10 May 2018 (UTC)
@NickK: You highlighted the exact reason why we're going to have to build this in a way where each block will have its own expiration. We're tracking this at phab:T194697. We don't think this will change our technical direction, we had an extensive discussion about it last week and are currently drafting our proposal for the database schema now at phab:T193449.
Building on top of AbuseFilter is a non-starter for us. Our team investigated AbuseFilter last year and ultimately walked away from the projects because we did not identify any promising directions for using it to prevent or monitor harassment, and also because of the feature's technical debt and complexity. In order to use it for this, we would have to re-write it entirely, which is far out of scope for our team's work. Many other wikis already have AbuseFilter near the condition limit, so AbuseFilter unfortunately cannot be used on all wikis, but it's good to know it's working on Ukrainian!
I agree that if any user is granularly blocked from so many pages/cateogries/namespaces, it may be best for them to be siteblocked because the work to monitor their activity is counterproductive to other users' activity on the site. This is why we are curious if adding a maximum number of items to be blocked would be useful. — Trevor Bolliger, WMF Product Manager🗨00:02, 15 May 2018 (UTC)
Category only?
Latest comment: 6 years ago7 comments4 people in discussion
I have a bit of a challenge wrapping my head around the practical implications of "Category" blocking: I think it introduces complication than might be useful, or introduce all kinds of practical challenges in the long run. For example, does the block treat everything in the sub-categories? If so, how do you determine if the category tree has reach a point of absurdity? High level categories should not, by definition, be very big in the content, so to do an effective block on a topic, you would have to include all of it's subcategories. However, those top level categories are bound to have all kinds of logical contradictions within the category tree, that may push it to absurdity or catch content that is not intentionally in that category -- and probably will pick up something that is not logically a "sub-topic" of the main category, but is categorized as such because of some other relationship.
If you are going to do Categories, you should also include Template transclusions: there are more blocks where I would want to ban someone from "Everything in the scope of WikiProject [X]" (i.e. has the WikiProject Template) than from a particular category: most folks' topical violations travel across the subjects within a domain, but would not normally be in the same category tree (unless you include categories to the point of absurdity, which will capture a bunch of content that is not in the original intended scope).
Moreover, if you don't include transclusions, folks will be forced to create "maintenance categories" for blocking folks, which introduces yet more non-content clutter on pages. This is a recipe for creating more arguments and misunderstandings among different editors.
It depends on how the project manages categories. On the French Wikipedia, there are portals on all articles, and those portals add hidden categories to the page, so I think that category blocking would work pretty well. On the English Wikipedia, Wikiproject templates already add categories to talk pages (for instance w:en:Category:WikiProject New York City articles), so this would work without having to deal with templates, but only if the system allows blocking articles by categories on their talk pages.
@Orlodrim: I worry about the proliferation of unnecessary maintenance categories though. Moreover, as more of the classification functions of categories get handed off to Wikidata: the effectiveness of relying on a category as a tool for defining a set, seems incredibly limiting. Whereas template transclusions are something that we won't be loosing anytime soon. If we want the tool to stay relevant over the long term, we really ought to include transclusions. Sadads (talk) 13:25, 16 May 2018 (UTC)
@Sadads: Great idea about template transclusions, or we can even probably build off of the backend of what Article Alerts uses to determine which pages are in WikiProjects. I've created phab:T194804 to capture and track this idea.
@TBolliger (WMF): That's interesting! On EnWiki and Commons blocking a top level category, and not doing the subcategories at a particular depth, kindof defeats the purpose of keeping someone out of a workspace though. I am thinking some of the more controversial areas that have results in topical bans on enwiki (i.e. en:Category:Scientology and (en:Category:Alternative medicine) -- doing a topical block well in those domains, would require an admin to add dozens, if not hundreds of categories -- even if the tool is super user friendly the user overhead for that, its still a huge waste of time (and would be easier just to do a full block). If part of the goal, is to make it easier for Admins to do more flexible blocking strategies, only top level categories is not very empowering -- and I would expect would make the tool not worth using. Template transclusion or WikiProject info is a bit more consistent with the theory though, Sadads (talk) 00:57, 16 May 2018 (UTC)
@TBolliger (WMF): I have to agree with Sadads here. Categories going deep is rife with errors and false positives. Anyone adding a subcategory (maliciously or not) will affect how this works immensely. Removing a subcategory will also affect previous (but active) blocks. I am not sure subcategories are manageable. Blocking on categories (top level) is fine with m.e and much better than what we currently have. -- Alexf (talk) 01:23, 11 August 2018 (UTC)
Is there a tool available to tell how many articles are impacted by blocking one category? Groetjes --Neozoon (talk) 11:54, 16 May 2018 (UTC)
Stigma of blocking
Latest comment: 6 years ago2 comments2 people in discussion
This is an ability that can only be welcomed as much as possible. However, if we are talking about community health, we also need to talk about the community. I don’t know about the situation everywhere, but in my experience people value a ‘clean log’ quite a bit, and not having a ‘clean log’ in terms of blocking can lead to some prejudice to opinions of users, disenfranchisement in terms of the ability to have higher positions in the community etc. Adding a completely new ability to this, that might and will be used probably a lot more selectively when it comes to conflicts etc., will lead to increasing this stigma that comes with the act of ‘blocking’, even if it was a fairly minor dispute.
I think the most considerate approach to go around with this is to have another special page, called ‘topic block’ (or ‘topic ban’, as we call it in Russian Wikipedia), that will come with its own log and will be linked to administrator as an alternative from Special:Block. It will reduce the harm that this feature might potentially bring to editors for years to come, unless, of course, community will be so zealous it will look in that log as well (but after that we at least can’t say that we didn’t try to prevent some harm that would come with this). stjn[ru]13:19, 16 May 2018 (UTC)
Hello, I would like to have the stigma of being / having been blocked bright on the user page. But after a certain period of time, it should disappear again. Ziko (talk) 14:37, 16 May 2018 (UTC)
First designs
Latest comment: 6 years ago29 comments11 people in discussion
Hi all!
Thank you for your comments to the "help us design" discussion above. We've enlisted the assistance of Alex Hollender, a User Experience designer here at the Wikimedia Foundation. Here is our first wireframe based on the discussions on this talk page, Wishlist proposal, and Phabricator to date.
We believe the Special:Block page is already at its limits with its current layout and would like to propose this new organized layout. This will make it easier to add the granular blocking (page, category, namespace, etc) and whatever is to come in the future. All of the same functionality is available on this new layout, but in a more organized, step-by-step process. Here's the wireframe:
To set a granular block (as opposed to a full-site block) we have three ideas of how to design this. Currently we are not setting a limit to the number of pages, categories and namespaces a user can be blocked from. We would love to hear from everyone on this page about what you prefer!
We also think we may want to move the block history to the right of the page for LTR wikis for users using large monitors so it is more easily visible:
Without wearing the WMF hat, and as an active admin who does a lot of blocking, I must say these designs are beautiful! Of the three options, I think option 2 is easiest to wrap your head around. Though I'm guessing you meant for the input fields to be plain text, and not boxes with X's (since there's only one value per row)? Option 1 is nice but it might look messy for pages/categories with long titles. Putting the block log on the right side (if the window size is big enough) would be wonderful, too. With the advent of granular blocks I suspect block logs will become much longer. You might even consider setting some maximum height of the log and making it scrollable. — MusikAnimaltalk20:27, 31 May 2018 (UTC)
I haven't been following the prior discussion very closely, so forgive me if this has been answered somewhere, but if someone is blocked from a category, does that prevent them from editing any page listed in that category? In any case, I agree with MA's comments on this. As long as we don't end up looking at Comic Sans all day. ;) —DoRDtalk20:54, 31 May 2018 (UTC)
@DoRD: I can guarantee it won't be Comic Sans (it's a tactic used in wireframes to convey these are just sketches and not final designs.) You are correct in your understanding: if a user is blocked from a category they will be blocked from all pages within that category. For example, if a user were blocked from es:Categoría:Brad_Pitt they would not be able to edit those 4 pages. — Trevor Bolliger, WMF Product Manager🗨21:20, 31 May 2018 (UTC)
With my WMF hat off, I also want to +1 MusikAnimal's feedback -- with Option 2 being the best. I like the idea of, once an item is selected for blocking using a drop down selector (as opposed to free text), turning it into a click x box: it helps ensure that an item is blocked properly and you don't accidentally do a bad block because of misspelling/formatting. I want to +1 the block log as a separate panel, and emphasize the importance of this information being higher. Sadads (talk) 21:11, 31 May 2018 (UTC)
@MusikAnimal:@Sadads: Thank you, hatless people. I agree that making the log scrollable could be useful as we do anticipate more blocks to occur. And yes, the x's for Option 2 are accidents, as is the x on the username/IP input as you can only block one user at a time. If we go for options 1 or 3, the input box will grow vertically as necessary. For all three options there will be type-ahead suggestions and validation that you've selected a valid page, category, or namespace. — Trevor Bolliger, WMF Product Manager🗨21:20, 31 May 2018 (UTC)
I like the distinction between "Prevent user from" and "Additional options". I also think that moving the history to the right on large monitors is useful. One note on the "Reason" select element: The wireframe assumes that the block reasons are fairly short. At least on Commons the reasons are up to about 100 characters long, so it makes sense to have the select element and the text input element on two rows, instead of one as depicted here. Sebari– aka Srittau (talk) 21:33, 31 May 2018 (UTC)
This may be out of scope for this project, but I thought to bring it up anyway: It would be useful to render parsed text in the reason popup, instead of Wiki text. Links are pretty common in block reasons, but make it hard to spot the correct reason in the popup. Sebari– aka Srittau (talk) 21:49, 31 May 2018 (UTC)
@Srittau: If the text area grew in height as you type, would that be acceptable? And your idea for supporting formatting in block reasons is unfortunately out of scope for this project, but I agree it is something worth looking into. We're having a particularly hard time deciding how to handle large desktop-formatted templates to display to blocked users on mobile. — Trevor Bolliger, WMF Product Manager🗨21:55, 31 May 2018 (UTC)
@TBolliger (WMF): I was talking about the select input with pre-defined reasons. These pre-defined reasons (and therefore the select input) can be quite long (see screenshot), so having the free-form text input next to it would probably not be a good idea. Sebari– aka Srittau (talk) 12:56, 3 June 2018 (UTC)
Already said this on en, but options 1/3 are my preferred. Also, I'll echo my comments there that only going one deep in the category tree is going to be a clusterfuck and actively increase disruption and probably socking on the projects. I'd prefer it default to indefinitely deep in the category tree, but there should at least be an option to set it for how deep to do. TonyBallioni (talk) 14:14, 1 June 2018 (UTC)
Hi all — thank you for feedback so far on both here on Meta Wiki and on English Wikipedia. It seems like Option 1 has the most support, with some folks preferring option 2 or 3. We have two more variations that have come up: Option 1.2 (which swaps the order for full-site and granular blocks) and Option 4 which deemphasizes “full block” by making it a checkbox under granular block. It would still be enabled by default. Any thoughts about these new options?
Other notes:
We’ve received several comments in support of moving the block log to the right (for left-to-right languages) on large monitors. We’ll have to calculate the exact breakpoint for this to happen so it is still readable, and we may make it scrollable or expandable to save even more space.
We’ve received support for separating “prevent user from” and “additional options”
It has been suggested that we use type-ahead suggestions for pages and make it possible to use a mouse to remove items once selected.
The ‘Reason’ dropdown needs more room. We’ll address this in the next wireframe, same with adding the ‘other’ text area back for expiration.
Category depth is still a very real question. I originally suggested that this would only support 1-level deep (i.e. block users from editing pages belonging directly to a category but not pages within its sub-categories) but it has been suggested that categories have infinite depth (i.e. block users from a page if it is in any level of sub-category from the original blocked category.) We’ll need to design something that is not computationally heavy, such as 2-categories deep. More feedback would be greatly appreciated on this topic.
There is criticism that category blocks will cause problems because they may allow other non-admin users to dictate the parameters of a block by adding or removing categories to a page.
It has been requested that we drop this project or to build it as a different tool from Block. My team (the Wikimedia Foundation’s Anti-Harassment Tools team) has identified this as a long-requested feature with lots of promise to address situations of harassment and other user misconduct where the offending user does not deserve a full-site block response but should still be quarantined from a part of the wiki. We still believe this tool holds great potential for helpful impact and are proceeding as such.
It has been requested that we build separate expiration times for granular blocks vs. full-site blocks. We plan to build this after our initial version, which will just be page blocks, in phab:T194697.
We also have some wireframes for how Special:BlockList could be updated. We also think this table could be expanded to Special:Contributions to make the block information easier to read, especially in cases with several blocked pages:
A wireframe of Special:BlockList showing a new column for the type of block
A wireframe showing the BlockList design used on Special:Contributions
Completely tone deaf response. Will you once again force this "feature" on all wikis even without consensus? --Nemo14:46, 7 June 2018 (UTC)
I also don’t think that you are even hearing or answering to any concerns that people might have with this feature. I don’t think there’s no need for it, but to have exactly one forced vision for this that everyone must discuss, frankly, against their will is not how things in Wikimedia community are done. At all. stjn[ru]21:29, 11 June 2018 (UTC)
@TBolliger (WMF): Could you please explain in more detail why this cannot be a separate page? You explain why dropping this project is not an option (and I completely agree with it), however, you don't explain why building it as a separate tool is not an option. Personally I as an admin already happened to deal with users who both have a long-term granular block (e.g. because they have strong NPOV violations in a topic) and a short-term full-site block at the same time (e.g. because of offensive behaviour or edit wars). Your proposed solution does not help resolve this problem — NickK (talk) 09:35, 15 June 2018 (UTC)
@NickK: Building this as a separate tool is an option, but we believe it will be more efficient and effective if we build this on top of Special:Block. Not only is it a more technically simple solution but we also strongly think it fits into the existing mental model and workflows of blocks. We want to allow for multiple expiration dates for these blocks (e.g. a block on '2018 FIFA World Cup' could expire at the end of July, a block from uploading files could be indefinite, and a 24-block would be possible without overwriting either of the previous blocks.) This work is tracked in phab:T194697 — Trevor Bolliger, WMF Product Manager🗨22:14, 15 June 2018 (UTC)
@TBolliger (WMF): Thank you, this is clear now. The issue is that prototype suggests that these options will be exclusive (a radio button is used) which is why I asked. The reasoning regarding workflows makes sense in general. Still I think there is a huge operational difference between full-site and granular blocks. Full-site blocks have to be fast while granular can be slower: blocking a cross-wiki vandal as fast as possible is priority, while setting a block for an experienced user from editing a specific article is hardly ever extremely urgent and can be on a subpage or similar. Full-site blocks have to be more visible than granular ones: full-site prevents from editing all pages but one (own talk page), while granular allows to edit the entire site but one page. I even think they should be clearly to distinct to avoid confusion (concerning BlockList design used on Special:Contributions). It might also make sense to track separately cases of full-site (say, if there is some specific block enforcement like ArbCom decision) and granular blocks instead of having a mixture in the same log. All this does not mean this cannot be done in the same tool, the major issue is that there should be a distinction between these two options — NickK (talk) 23:21, 15 June 2018 (UTC)
NickK, by "tracking separating" do you mean record it publicly in a different log format? I've been think about how to better track enforcement of sanctions in complex cases of user misconduct. This goes with other stuff that our team is working on related to a reporting system for user misconduct and a better method for admins to keep track of cases while they are doing a new investigation or a follow up to an existing case. I think tracking the these blocks outside of the block log would be part of it. SPoore (WMF) (talk) , Trust and Safety Specialist, Community health initiative (talk) 16:23, 21 June 2018 (UTC)
@SPoore (WMF):, I mean indeed recording it publicly in some unrelated log instead of the wireframe showing the BlockList design used on Special:Contributions presented above — NickK (talk) 17:42, 21 June 2018 (UTC)
@TBolliger (WMF): but the thing is, when you’re introducing a solution that would require more cautious approach, you must do it that way. Introducing granular blocks would immediately skyrocket block rates for users, since in the cases like edit warrings, and topic bans they would be more than helpful and rightly so. But with calling it a ‘block’ and tying as an option on Special:Block page you have to consider all the impact you will make, not just the positive fluff. And the negative impact would be in immediate surge of blocks on most minor offences (if you’re going to call this block, it will be considered a block), in drastic increase of ‘holier-than-thou’ attitude by users (since blockage carries immediate reputational pushback towards a user), in further worsenment of community relations when in some projects they aren’t on the all-time high either. So in trying to better the community health, you would actually immensely damage it by going like you want, despite any concerns that you still haven’t addressed. stjn[ru]18:12, 16 June 2018 (UTC)
Hello stjn, The topic of "stigma" or "poor reputation" from partial blocks is something that needs to be thought about when they are used. The Anti-Harassment Tools team is aware that the term block has a specific meaning now and that it will need to evolve as the various additional types of partial block expand. For example, blocking file uploads or stopping someone from editing in a particular namespace (templates or categories or Wikipedia) is vastly different from a full site block. I anticipate that local terminology and processes will be developed on each wiki and will mitigate some of your concerns. I know that policy and processes will likely need to be updated, too. Part of my work is to assist as needed with these local discussions. In a few weeks, I plan to open a space on Meta where people can start planning how to do local discussions. I'll ping you to the space when it starts. SPoore (WMF) (talk) , Trust and Safety Specialist, Community health initiative (talk) 16:23, 21 June 2018 (UTC)
Isn’t a simpler solution to just have a new additional page for different types of blocks that would be promoted to sysops from Special:Block with some kind of message? If you add it as a way to set up restrictions, and practically speaking, they are restrictions, there would be no significant drawback from using them when the other impact from the feature being available would be still very positive (for example, in Russian Wikipedia there is a specific autopromoted ‘uploader’ group, which would likely be superseded by the ability to block people from uploads). And another aspect, as I see it, is in that sysops themselves are, too, somewhat conservative in their workflow. When Special:Block was remade to OOUI, when date picker was added there, time and time again I as a developer in Russian Wikipedia heard questions to local developers whether or not we have done it and whether or not it could be reverted. Even more than the social aspects, I sadly have to fear that such a major reworking of Special:Block would be considered by many as outrageous and non-useful simply because it interferes with their workflow (and probably would break our local scripts, but that is manageable) so much more than previous improvements did. stjn[ru]16:46, 21 June 2018 (UTC)
stjn I understand that changing Special:Block is going to be a problem in that it has the potential to disrupt workflows on hundreds of wikis. :-( We need to tackle the problem from three directions. 1) Make the modification in a way that are incredible helpful so people mind less. 2) Use approaches that are more likely to break fewer workflows. 3) Communicate early and often with as many people as possible about work that we doing.
We are still in the design and planning process so we still have time to get the opinions of more people. I'm due to make another round of mass messaging and announcements to update people who don't come to Meta. Hopefully this will bring in more people to explain their local workflows and we can plans ways to minimize the disruption. SPoore (WMF) (talk) , Trust and Safety Specialist, Community health initiative (talk) 19:41, 21 June 2018 (UTC)
You talk about "the existing mental model and workflows of blocks", but only one or perhaps a handful wikis were considered in inferring this supposed mental model, out of hundreds just in the Wikimedia land. All the others will get a one-size-fits-all cultural imposition. --Nemo19:39, 20 June 2018 (UTC)
Hello Nemo, the point that you are making is what keeps me awake at night. :-) It is actually a worse problem than you describe because we are also designing tools that needs to work with the next wave of users who join the wikimedia movement over the next 3-5 years from more places around the world. What I can tell you is that the Wikimedia Foundation Community health initiative and members of the Anti-Harassment Tools team are aware of the strategic planning that is happening in the wikimedia movement related to community health. We anticipate that the planning which will include how to make wikis more welcoming to new users from small and medium size language wikis.
The solution to the issue can't be doing nothing for several years while the strategic direction discussion is finished, so we're being transparent about our ideas and encouraging people from all wikis to share their ideas now. We'll be at Wikimania and plan to speak with people who are not regular contributors to meta wiki discussions about the specific projects that we are doing including this one. If you know someone who would be interested in speaking to us send them our way. Also people who are not comfortable posting in Meta discussions can reach me by email. SPoore (WMF) (talk) , Trust and Safety Specialist, Community health initiative (talk) 16:23, 21 June 2018 (UTC)
Update: We're putting category blocks on hold, focusing on page and namespace blocks
Hi all, my team shares our project plans and designs here on Meta Wiki so we can make sure we're building the best possible tools. Based on feedback we've gotten so far we've decided to put category blocks on hold and instead focus on building page, namespace, and upload blocks first. Category blocks introduce several complexities (how deep should the category blocks apply? how do we monitor bad-faith category manipulation? etc.) that became more apparent thanks to discussions on this talk page — thank you for participating, because we want to make managing uncivil users less burdensome, not more. Once we have all the details ironed out for these more straightforward types of blocks we plan to return to the topic of category blocks, likely not before August of this year. Watchlist this page for more updates.
We're working on another round of designs, which I'll post here as soon as they're ready. Keep the feedback coming, if you haven't voiced your 2¢ yet.
Hello @ThurnerRupert: this has to do with 'rights' in concept only. Rights are associated with groups (e.g. Special:ListGroupRights) and groups are assigned to users, either manually (e.g. admin) or automatically (e.g. autoconfirmed). Blocking does not alter the groups to which a user belongs, it is another intercept to certain actions (e.g. email, editing, moving pages, etc.) — Trevor Bolliger, WMF Product Manager🗨17:19, 6 August 2018 (UTC)
Leave it like it is
Latest comment: 6 years ago6 comments5 people in discussion
Blocking is already quite alright like it is. Bans are set at the discretion of the community and are often "broadly construed", which is not amenable to automation. The blocking function is quite alright as it is and does not need tinkering, so please stop tinkering with it. Seraphimblade (talk) 03:41, 3 June 2018 (UTC)
+1. Code is law, and adding such options will impose or otherwise encourage practices beyond the status quo or the consensus. Social decisions should be left to social instruments. --Nemo11:30, 3 June 2018 (UTC)
I think you’re not entirely right – it is entirely possible to do this ‘socially’ so that it can improve certain user interactions (such as mediations etc.) that right now can require only will from user to restrict themself. However, calling it and tying it to the ‘blocking’ is an utterly wrong decision that would encourage sysops going around ‘blocking’ people from some topics for minor offences and then pointing to those blocks as an example of their ‘destructive’ behaviour afterwards. Blocking should be left alone, but the idea of granular restricting itself is more than honourable. stjn[ru]15:09, 4 June 2018 (UTC)
All the points above have merit. I think it boils down to when granular blocks should be used, which probably would not include the "broadly construed" use cases. Indeed this technical capability may encourage misuse, so it may require some policy changes. However at it's core, I think granular blocks aligns with the philosophy of taking the minimum amount of preventive measures necessary to stop the disruption. Currently discretionary sanctions, topic bans, and (some) single-page edit wars are enforceable only by site-wide blocks. Surely it would be advantageous to enforce technically, so the user can still edit freely elsewhere. Whether or not we want to use technical measures is a community decision.
A much better example, applicable everywhere, is dealing with IPs and IP ranges. There may be scores of innocent users in a given range, when the disruption is limited to a single page or category. Currently we either have to block the whole range or protect the pages, in both cases shutting out the innocent, or resort to the AbuseFilter, which adds a runtime expense to everyone who edits. In this sense granular blocks are the natural solution. — MusikAnimaltalk18:43, 4 June 2018 (UTC)
Hello Seraphimblade, when I first joined the WMF Anti-Harassment Tools team last year and reviewed the list of potential ideas for our team to work on, I had a low opinion about the usefulness of per user page blocks for precisely the same reason that you mention. Topic bans on ENWP (where I have most of my experience as an admin) are written usually as "broadly construed" and that is not enforceable in a meaningful way as an editing restriction by blocking by page or category. Our team's first consultation about this at Wikimania last year re-enforced my negative view. Our meeting had mostly ENWP administrators attending and the agenda I set focused on AHT trying to create a tech solution to enforce editing restrictions as currently used on ENWP.
But because there was longstanding interest in the idea on wiki and phabrecator that AHT should not ignore, we went ahead and held several more on wiki discussions about potential ways that per user blocks could be used. And over time I've read more comments about the way that granular blocks could be used that are different than enforcing "broadly construed" style indefinite content topic bans. And slowly, I have come around to a more positive opinion about their effectiveness. I found it appealing to be able to do a) Single page temporary user bans as a replacement for Full Protection when only one or a few editors are continuing to cause problematic edits. b) ip or range blocks for only select page(s) c. blocking file uploads, one type of namespace, or single points of problematic contributions that now can only be done with a full site ban.
Setting a page block
Textarea disappears when a specific option is selected for expiration
Textarea disappears when a specific option is selected for reason
Setting a category block
Setting a namespace block
Setting a namespace block, if we want to support multiple namespaces at once.
Setting a file upload block
If we make this a part of regular Special:Block (and not a new tool) we can add the dropdown for 'Full site' block
If we integrated with Special:Block, the granular options could live behind a tickbox or dropdown.
Admins can set different types of subsections to block — pages, categories, namespaces, and uploading files.
This is a slightly more advanced layout and would require some logic to identify what the user is typing, but keep the UI simple.
A wireframe of Special:BlockList showing a new column for the type of block
A wireframe showing the BlockList design used on Special:Contributions
