Community health initiative/Blocking tools and improvements/Summary Dec 2017

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

Summary of feedback received to date, December 22, 2017[edit]

I’ve read over all the feedback and comments we’ve received to date on Meta Wiki and English Wikipedia, as well as privately emailed and summarized it in-depth on the talk archive page (along with archiving some sections.) We’re looking for non-English discussions and users willing to help translate, and will provide a feedback of those discussions in January.

Here is an abridged summary of common themes and requests:

  • Anything our team (the Wikimedia Foundation’s Anti-Harassment Tools team) will build will be reviewed by the WMF’s Legal department to ensure that anything we build is in compliance with our privacy policy. We will also use their guidance to decide if certain tools should be privileged only to CheckUsers or made available to all admins.
  • UserAgent and Device, if OK’d by Legal, would deter some blocks but won’t be perfect.
  • There is a lot of energy around using email addresses as a unique identifiable piece of information to either allow good-faith contributors to register and edit inside an IP range, or to cause further hurdles for sockpuppets. Again, it wouldn’t be perfect but could be a minor deterrent.
  • There was support for proactively globally blocking open proxies.
  • Some users expressed interest in improvements to Twinkle or Huggle.
  • There is a lot of support for building per-page blocks and per-category blocks. Many wikis attempt to enforce this socially but the software could do the heavy lifting.
  • There has been lengthy discussion and concern that blocks are often made inconsistently for identical policy infractions. The Special:Block interface could suggest block length for common policy infractions (either based on community-decided policy or on machine-learning recommendations about which block lengths are effective for a combination of the users’ edits and the policy they’ve violated.) This would reduce the workload on admins and standardize block lengths.
  • Any blocking tools we build will only be effective if wiki communities have fair, understandable, enforceable policies to use them. Likewise, what works for one wiki might not work for all wikis. As such, our team will attempt to build any new features as opt-in for different wikis, depending on what is prioritized and how it is built.
  • We will aim to keep our solutions simple and to avoid over-complicating these problems.
  • Full summary can be found here.