@Niharika @jwang @drochford It would be good for us to get this data out to the communities. Maybe a blog post?

@DannyS712 I appreciate the work that you put into improving the logging of blocks. I agree with @Niharika that there needs to be a target wiki(s) that are interested in implementing this change. Through a Rfc or other type discussion, they will need to weight the pros and cons of this design and be ready to put into place by updating their their local policies about logging blocks. Special:Block is a widely used feature and it is important to have very broad input about the benefits of making the change.

Good news. We just finished writing and proofreading the proposal. Voting phase has finally started!

@Niharika that sound like a good idea. Also, each of the test wikis has a page that describes pb and the questions that we are trying to answer with the testing. The talk page this page is likely to be where we will get the most feedback.

@MarcoAurelio @DerHexer Let me try to answer as to why the original plan was to remove partial blocks from Special:CentralAuth and also reassure you that your feedback is essential for having the block feature work well for all necessary workflows that use it. So thank you for commenting.

@dbarratt the current steps reflect a combination of the conditions when it is normal practice (acceptable) to suppress a user account name and lists, and the usual workflows. that are used.

Created now

@Niharika another option is to have a special page for partial block feedback that is linked to from the main feedback page.

@Niharika that is a very good question. I suppose that we could link to the general page and ask for targeted feedback about partial blocks, but leave space for other feedback. https://meta.wikimedia.org/wiki/Community_health_initiative/Blocking_tools_and_improvements/Feedback

@Niharika https://meta.wikimedia.org/wiki/Community_health_initiative/Partial_blocks/Feedback is the best one to keep the comments focused.

@alanajjar you can describe what you found on Arabic Wikipedia related to the page freezing and not showing block message when adding a category with a gadget. I would appreciate you sharing the particular details and screenshots.

Thanks @dom_walden Sounds good. Looking over the list I don't see any other beta sites that will give us extra information that we would use right away. So, from my perspective we're done for now.

It is intentional that only indef blocks allow for user names to be suppressed. We are using it only to suppress indef blocked troll accounts that meet a strict criteria for suppression. This is not needed for partial blocks even if time period was indef.

I agree with Trevor that we should keep it for now

Earlier I thought of the term Screening because it is a form of Assessment but better since it has a connotation that it is not exact or permanent. But there are other meaning that are really different and also I don't know if it would translate well. So, I rejected it.

Judgement is a problematic name for all the reasons stated by others already and needs to be replaced before that it completely undermines the good that could otherwise come from this work.

@TBolliger I see why you prefer option 1. It follows traditional on wiki values and is the safe approach. The only reason that I might consider including their talk page is that some users get stuck in a rut and spend all of their time ranting on talk pages, even their own. Block all talk page access might bring them back to productive editing again. I wouldn't be opposed to a wiki experimenting with this approach. to see if it helps some users.

-I have mixed feeling about talk namespace blocks that includes their user talk page. I lean toward not blocking it UNLESS the page is added as part of the actual partial block. And then pre-fill the checkbox.
-I would make them list it in the block itself not with a simple check or to assume a talk namespace block would include their talk page. This would take away errors that would be difficult to resolve if talk page access is gone. This would still allow for the flexibility to do a rare user talk page or namespace block that includes their talk page.
-That said, it is a corner case that we could eliminate by allows allowing them to edit their own talk page with all pb. There would be no big loss by eliminating it since it is not available now.

I agree that we need to re-think changes introduced with the patch.

@dmaza If a sitewide blocked user can edit their talk page, then the message needs to display. This is very common and expected result that we shouldn't change.

@Trevor, agree that this ticket should not do the big change of stopping admin from unblocking their own account. And also the PB can not modify belong in another ticket, too.

This something we need to more research around through user interviews or on wiki discussions. And then do testing around it as we roll it out on our first wiki.

I agree with Trevor's concern. Currently, Editing Restrictions as logged now are not easily found and not displayed when you look at user contributions or when you go to the user's talk page. It might be a disincentive to use partial blocks if there is a social stigma.

I looked at a few of the other possible user action that might show up as admin actions but nothing showed up as obvious.

Yes, it makes sense that it could be including non-admins with page move rights. https://en.wikipedia.org/wiki/Wikipedia:Page_mover#Suppressredirect

Looks good to me.

Strong preference for Share these results since a discussion might not be the appropriate context.

In T2674#4400001, @putnik wrote:

For namespace blocks, it should be possible to specify a list of excluded pages. For example, if the user talk namespace is blocked, there should be able to exclude a pages of several admins that the user can ask, or page for requests to administrators for project namespace block.

@alexhollender "There's a discussion happening about improvements to this blocking tool. Come check out the designs and join in" is perfect. There needs to be a link to discussion on meta at the end.

We talked about this last week and agreed that the wording needs to be changed to lose the "we" to make it more reflective of the participatory design and research approach that we're using.

In T197117#4323873, @dbarratt wrote:

@SPoore & @TBolliger

I just noticed this comment in the code:

If a user's name is suppressed, they cannot make edits anywhere

Right now, if the user has a block, and their username is suppressed, then they are prevented from editing on their own talk page (even if the allow setting is enabled).

Two questions:

1. Should suppressed user names be able to edit a page, regardless of whether a block exists for that user?
2. If a user has a partial block and their username is suppressed, what should happen? Should we ignore the partial block and impose a hidden sitewide block?

@TBolliger In the discussion on Meta, some people are giving good reasons for why that the word "block" would be potentially damaging to reputations. More so than the current sanctions like editing restriction or a topic ban that the partial block will be replacing or enforcing. I also think it is definitely more harm if it is logged as a partial block if it is a replace for Full Protection on a page which carries no stigma for individuals.

Track on Asana https://app.asana.com/0/364663766104026/timeline

The most important piece of this will be the information that is prompted to be posted to make a report or supplement an existing report.

@TBolliger Probably only want to look at full protection for the information we are trying to obtain. https://meta.wikimedia.org/wiki/Help:Protection

For the first release, let's only enable on meta, mediawiki.org, and de.wikipedia.

In T132220#4067247, @TBolliger wrote:

I think offering both the datetime expiration picker and a length dropdown is valuable to all wikis regardless of language. Some blocks are for common infractions — e.g. someone vandalized, they get blocked for ~30 hours. But some blocks are more nuanced — e.g. two users are in conflict, block them until we can synchronously discuss it on wiki.

In T132220#4067247, @TBolliger wrote:

I'm very curious why this didn't come up during our blocking consultation. Did we not get enough non-English participants? Granted, the page on Meta was in English but we reached out to 10 Wikipedias of 10 different languages and did see some language-specific feedback. Just not about this.

Pages created on EN WP https://en.wikipedia.org/wiki/Wikipedia:Community_health_initiative_on_English_Wikipedia/Improved_tools_and_workflows_to_report_harassment

Yes, will get it done by end of the week.

It was planned that accounts without edits should be able to receive email on their home wiki. If that is not happening, then something is wrong that needs to be fixed.

In T180722#3810175, @TBolliger wrote:

In T180722#3810151, @dmaza wrote:

How would this work if we do the sticky toolbar?

If we plan on adding any sort of information about the user in the future other than what it is already on the timeline, maybe we should consider a modal window/page with "user details", including a link to all those things.

The simplest version of this would be to have the username link directly to the userpage, which contains the links to these tools. It's an additional click and pageload.

@SPoore @MER-C — your thoughts?

In T180245#3804923, @TBolliger wrote:

Here's my first thoughts — This bar scrolls and picks up the current date as you scroll. Clicking the pin icon hides the overlay, but the pin icon would continue to float on the far right. Clicking it again would show the overlay again.

We'll probably want better icons for the pin than the 📌 emoji. Hide/show or pin/unpin.

Hovering over the icons should show appropriate hint text (e.g. "show username overlay" or "hide username overlay")

As Wpedzich says, the WMF Support and Safety team (my team) is aware of the long term abuse by Wikinger and it is not possible to keep Wikinger off WMF wikis.

In T172554#3637292, @jrbs wrote:

In T172554#3637033, @TBolliger wrote:

Does this patch apply the new style to all users, just logged-in users, or only users with the 'Strike out usernames that have been blocked' gadget enabled? I believe there needs to be a bigger discussion if this is going to apply to anyone other than opted-in users. (@SPoore, do you agree?)

Possibly butting in here, but I would agree.

Also, what's wrong with the style of the existing gadget? The slightly dimmed color and strike out combo are effective, in my opinion. And colorblind users would still benefit. Here's a screenshot:

I use and love this gadget, but could understand why some might not be able to read the stricken text. I think Nick has a point with italics too; things like Arabic etc don't really have an "italic" the way we think about it.

@Jdforrester-WMF — are your accessibility concerns related to colorblindness, or something else in addition? Would a strike-out address this?

Can't speak for him of course, but I imagine he's concerned about contrast; rgba(67,101,204,0.7) - the colour it outputs links to blocked usernames - seems to fail the AA test.

Productivity would be useful to look at. Change in the number or type of edits.

Hi all, the Support and Safety team and the Anti-Harassment Tools team have been looking at this feature as an interesting way of addressing a concern. We had some questions come up in discussion. One of these is regarding the visibility of the blacklist to other contributors. As we understand it, the current configuration is that the blacklist is an openly-viewable subpage in userspace. We could see some problems there - e.g. the creation of “enemy lists” for instance, or the escalation of an interpersonal dispute because an editor notices their name on a blacklist. Is the userspace subpage the only option? Could, for instance, the list be a Special page only viewable by admins?