Page MenuHomePhabricator

Generate report of admins who perform many blocks so we have a list to invite to blocking consultation
Closed, ResolvedPublic3 Story Points

Description

This is a one-off.

Query https://www.mediawiki.org/wiki/API:Blocks or the DB directly.

Requirements

  • From the last 3 months / 90 days (August 1 - Oct 31 or the past rolling 30 days, whatever is easiest.)
  • For each wiki listed below, generate a report of users who have performed the most blocks
    • Limited at 10 per wiki
    • Note there's no need to check specifically if the users are in the 'admin' group, since the only users who can block are administrators.
  • Only share this report internally.

Report format

  • This can either be one giant report with a column for wiki (preferred), or individual reports for each wiki. Whatever is easiest, Dayllan.
  • Here's an example table of how the data could look
wikiusername'allow email' preference enablednumber of blocks performed
enwikiApplesyes100
enwikiBananasno90
enwikiCarrotsyes80
etc...

Wikis

Wikipedias:

  • English
  • German
  • French
  • Italian
  • Polish
  • Russian
  • Spanish
  • Swedish
  • Japanese
  • Dutch
  • Chinese
  • Portuguese
  • Norwegian
  • Ukrainian
  • Hebrew
  • Czech
  • Tamil

And also:

  • Wikimedia Commons
  • Wikidata
  • Meta

Event Timeline

TBolliger created this task.Nov 8 2017, 7:48 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptNov 8 2017, 7:48 PM
TBolliger renamed this task from Query API for admins who perform many blocks to Query API for admins who perform many blocks so we have a list to invite to blocking consultation.Nov 8 2017, 7:50 PM
TBolliger updated the task description. (Show Details)Nov 8 2017, 7:54 PM
TBolliger renamed this task from Query API for admins who perform many blocks so we have a list to invite to blocking consultation to Generate report of admins who perform many blocks so we have a list to invite to blocking consultation.Nov 8 2017, 7:57 PM
TBolliger updated the task description. (Show Details)
TBolliger updated the task description. (Show Details)Nov 8 2017, 8:01 PM
TBolliger set the point value for this task to 3.
TBolliger changed the task status from Open to Stalled.

Waiting on @SPoore

dmaza claimed this task.
TBolliger updated the task description. (Show Details)Nov 13 2017, 6:42 PM
TBolliger updated the task description. (Show Details)
TBolliger changed the task status from Stalled to Open.Nov 13 2017, 7:15 PM
TBolliger updated the task description. (Show Details)
Restricted Application added subscribers: jeblad, jhsoby, Base. · View Herald TranscriptNov 13 2017, 7:15 PM
dbarratt added a subscriber: dbarratt.

@TBolliger & @SPoore
The email address is confidential user information and might be a violation of our Privacy Policy. We should probably verify with someone in WMF-Legal before adding that to the report. To me it's unclear if we are allowed to send emails (from production) or we are allowed to export those emails (for internal uses).

TBolliger updated the task description. (Show Details)Nov 14 2017, 6:04 PM

Good point, David. Let's drop the email address requirement for now. We can go through the proper process with Legal if we need the emails.

TBolliger updated the task description. (Show Details)Nov 14 2017, 6:07 PM

'allow email' preference enabled

If you want to be technical about it, the allow email preference by itself is private. What is public is if both allowed email, and user_email_authenticated is set. But I doubt anyone really cares about exposing the preference, since the almost equivalent thing is exposed.

dmaza added a comment.Nov 14 2017, 6:59 PM

@Bawolff I don't see user_email_authenticated in the replicas. I do see ug_property = disableemail for users that have disabled it.

@TBolliger If we are gonna use the data on the replicas we can only know if users have explicitly disabled recieving emails. I would assume that since in this case they are all admins, they will have an email address and such email address would be confirmed. So technically, unless they have disabled it, they should be able to receive emails.

That's fine. And yes, it's safe to assume if they're an admin they have an email registered.

@TBolliger, I don't know if it is relevant, but we have both users with block rights who are not admins in Portuguese Wikipedia and admins with no emails attached to their accounts.

Base added a comment.Nov 14 2017, 7:57 PM

Actually people performing blocks in context of harrasment are not necessary top people by the number of blocks. In the top I suspect to be guys fighting vandals most actively, they are not necessary involved with more "social" blocks (though not necessary not involved too). Just a thing to keep in mind.

Base added a comment.EditedNov 14 2017, 8:29 PM

Perhaps something like top of admins by blocks of people with more than N edits (e.g. 500) would reflect "social" rather than CVN related blocks better.

We are gathering this list of users who frequently block others so we can consult about https://meta.wikimedia.org/wiki/Community_health_initiative/Blocking_tools_and_improvements, so it does not matter if they are an admin or not, and also doesn't matter if they are performing blocks for harassment vs. vandalism, etc.

dmaza updated the task description. (Show Details)Nov 14 2017, 10:21 PM
dmaza added a comment.Nov 15 2017, 9:51 PM

For future reference, here is the query used to generate this data.

dmaza closed this task as Resolved.
Shizhao moved this task from Backlog to Closed on the Chinese-Sites board.Nov 16 2017, 2:18 AM