Page MenuHomePhabricator

Do not display "this user is blocked" messages on user & user_talk pages for partial blocks
Closed, ResolvedPublic3 Story Points

Description

Problem to solve
Currently, "this user is blocked" information messages appear when viewing redlink and editing user and user_talk pages of blocked users. These information messages seem appropriate if a user is blocked sitewide, but not appropriate if a user is only partially blocked. Block stigma is real, and showing this message whenever anybody edits their talk page could do more social harm than good.

Viewing redlink userpageViewing redlink user talk page
Editing user talk in 2017 editorEditing user talk in 2010 editor

Acceptance criteria

  • Leave these messages as-is if the block is sitewide
  • Do not show these messages if the block is partial *unless* the user is not allowed to edit the page in question:
    • Redlink user page read mode (example)
    • Redlink user talk page read mode (example)
    • Editing mode of user page — 2010 wikitext editor
    • Editing mode of user page — 2017 editor
    • Editing mode of user talk page — 2010 wikitext editor
    • Editing mode of user talk page — 2017 editor

Details

Related Gerrit Patches:
mediawiki/core : masterChange rules when displaying block log extract
mediawiki/extensions/VisualEditor : masterChange rules when displaying block log extract

Event Timeline

Restricted Application added subscribers: MGChecker, Aklapper. · View Herald TranscriptAug 30 2018, 3:17 PM

Since this appears to be the log message, it should automatically update when T197108 is completed.

Since this appears to be the log message, it should automatically update when T197108 is completed.

Nice!

But we still need to decide if the message is appropriate to display at all for partial blocks. If setting a partial block acts too much like a scarlet letter then it might dissuade admins to set them in some scenarios.

dmaza added a subscriber: dmaza.Aug 30 2018, 4:17 PM

But we still need to decide if the message is appropriate to display at all for partial blocks. If setting a partial block acts too much like a scarlet letter then it might dissuade admins to set them in some scenarios.

Well, the blog log has all the information. You can easily see it if you search for that user. It might be alright to display it

SPoore added a subscriber: SPoore.Aug 30 2018, 6:20 PM

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.

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.

aezell added a subscriber: aezell.Aug 30 2018, 8:03 PM

Moved from T197117.

It'll be interesting if we decide we want custom messages (as in, different from the block log) for several different pages. How does a page like the Talk page pull in this info? Would the API need to identify the source of the request so it could send back the correct version of the block message? Or, would each "host" page have to have code to modify the block log? How would we support translations for all of these variations?

Alex Hollander's next round of designs will be available next week, and he's introducing a new element that summarizes the block(s) currently levied against a single user. I think this could be used in this context instead of the latest log entry.

TBolliger renamed this task from Determine (then implement) what messages should appear when editing a partially-blocked user's userpage or talkpage. to Do not display "this user is blocked" messages on user & user_talk pages for partial blocks.Oct 29 2018, 11:04 PM
TBolliger triaged this task as Medium priority.
TBolliger updated the task description. (Show Details)
revi added a subscriber: revi.Nov 6 2018, 4:07 AM

If the user is blocked (partial or sitewise), they're blocked from doing stuff. It just adds more work for admins&co. who probably will need to verify they're partially blocked from time to time. (Block interface might display that the user is partially blocked but non-admins don't have information.)

All the logs are already visible in Special:Log and therefore that creates social stigma. Not displaying it on userpage just adds more workflow.

@revi

There are different ways the stigma can rear its head. I acknowledge that there may be some workflow changes for admins but one of our biggest concerns is that partial blocks won't be set because of this very public display. Special:Blocklist and Special:Log can both be filtered by username via URL parameter and convey less of a badge of shame.

Alternatively, we could display this information only for administrators. I'm not certain this is 100% necessary though.

revi added a comment.Nov 6 2018, 4:33 PM

I honestly do not think partial block won't be used just because it's seen on userpage/talk/contribs (hereafter $place). It's already very publicly seen on RC, Watchlist, logs, and anywhere it's logged. And the same things can be done by putting the "partial-blocked" template on user page, which has been done for almost all siteblock on Korean Wikipedia until 2017.

Additionally, it's somewhat inconsistent that you see a site-wide block on $place but not partial-block. You expect to see both or nothing, and I bet there will be someone who thinks it's a bug (that partial block is not displayed).

RC, Watchlists, and logs are searchable yet ephemeral while these red boxes are highly visible and permanent. From our interviews and other research we expect many partial blocks to be indefinite. One of the goals of this feature is to retain contributors who have received a partial block. Seeing the "this user has been blocked" message every time they edit their talk page is works counter to this.

This information absolutely should be findable — easily so — but displaying it right on the user's primary form of communication is overaggressive in my opinion.

One option would be to have a visible but discrete icon on the userpage that can be clicked/moused over. There would not be any stigma if this were something like "status", appeared on every user/user talk page and showed things like what permissions a user has (admin, rollback, etc) as well as items like "partially blocked" and "editing restrictions" (although as the latter are not known to the software at all these may not be possible). My first thought is that this would be similar in size and placement to en.wp's lock icons, featured article stars, etc.

I guess this would require more programming and be beyond the scope of just the harassment team's current tasks though.

I know there are many custom user scripts that display this information, such as User:PleaseStand/User_info.js.

I do like making this a bit more formal and accessible to all user accounts, but you are correct in this is outside our purview and scope.

TBolliger set the point value for this task to 3.
dmaza claimed this task.Nov 20 2018, 7:30 PM
dmaza moved this task from Cards ready for development to AHT Sprint 33 on the Anti-Harassment board.
dmaza edited projects, added Anti-Harassment (AHT Sprint 33); removed Anti-Harassment.
dmaza moved this task from Ready to In progress on the Anti-Harassment (AHT Sprint 33) board.
dmaza added a comment.Nov 22 2018, 5:05 AM

Should the message be displayed if the block is partial and it applies to the page? It could be an explicit Page/Namespace block or the block might prevent the user from editing their own user talk

revi removed a subscriber: revi.Nov 22 2018, 5:05 AM

Certainly I think that if the user is blocked from editing their own talk page this should be made clear to other users, regardless of what sort of block it is the result of.

I don't think its necessary for any other page. If a user is e.g. pinged from/invited to comment on another page but is unable to due to a (partial) block they will have the option of replying on their own talk page with a ping or just ignoring the invite/ping - exactly as they can if site blocked presently.

Should the message be displayed if the block is partial and it applies to the page? It could be an explicit Page/Namespace block or the block might prevent the user from editing their own user talk

Certainly I think that if the user is blocked from editing their own talk page this should be made clear to other users, regardless of what sort of block it is the result of.
I don't think its necessary for any other page. If a user is e.g. pinged from/invited to comment on another page but is unable to due to a (partial) block they will have the option of replying on their own talk page with a ping or just ignoring the invite/ping - exactly as they can if site blocked presently.

I would agree with @Thryduulf here. If a user is partially blocked from editing the User: or User_talk: namespace(s) and/or their user or user_talk pages, these messages should still appear.

Dayllan, if it turns into a rats nest of checks and conditions, we can take a step back and come up with a complete matrix of when this should and should not appear.

dmaza added a comment.EditedNov 30 2018, 5:10 AM

So here is a proposal for consistency. What if we only show the message if the user is not allow to create the user page or to create the user talk page regardless of the block type?
The only difference from what we have discussed so far is that if the user is sitewide blocked but can create their own talk page, the message will not show on their talk page.

Here is a set of conditions where the message will be displayed

PageBlock typePrevent edit own talk page Can edit this page?Display block message
User PageSitewidedon't care
User PagePartial don't care
User PagePartial don't care
User Talk PageSitewide
User Talk PageSitewide
User Talk PagePartial
User Talk PagePartial

Does this makes sense or do we still wanna leave the current behavior for the user talk page (message always on regardless if the user can create the talk page).

To summarize, if the user can create the page, the message will not be shown.

TBolliger added a comment.EditedNov 30 2018, 7:27 PM

Hi Dayllan, thank you for writing this out and providing the table.

Question: Would this logic apply to only the blocked user looking at their own pages, or to all users looking at the blocked user's pages? (From my understanding and assumption, it is "all users".)


The only difference from what we have discussed so far is that if the user is sitewide blocked but can create their own talk page, the message will not show on their talk page.

This may be problematic. There are important use cases for displaying this message on the user talk page, regardless of if they can edit it or not. (For example, the message conveys "this user has been dealt with" so others don't have to waste time leaving them a message. Let's double-check with Sydney.

@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.

@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.

After more thought (and a sandwich) I concur with Sydney. If a user is sitewide blocked but can edit their talk page, the message needs to appear to all users.

Change 477721 had a related patch set uploaded (by Dmaza; owner: Dmaza):
[mediawiki/core@master] Change rules when displaying block log extract

https://gerrit.wikimedia.org/r/477721

Change 477722 had a related patch set uploaded (by Dmaza; owner: Dmaza):
[mediawiki/extensions/VisualEditor@master] Change rules when displaying block log extract

https://gerrit.wikimedia.org/r/477722

dmaza updated the task description. (Show Details)Dec 5 2018, 5:47 AM

Change 477721 merged by jenkins-bot:
[mediawiki/core@master] Change rules when displaying block log extract

https://gerrit.wikimedia.org/r/477721

Change 477722 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Change rules when displaying block log extract

https://gerrit.wikimedia.org/r/477722

Catrope closed this task as Resolved.Dec 5 2018, 11:58 PM
Catrope moved this task from Review to Done on the Anti-Harassment (AHT Sprint 35) board.