Submissions:2017/Building MediaWiki software to enforce Page & Topic bans/Notes

From WikiConference North America
Jump to navigation Jump to search



Welcome, WikiConference North America 17 Note-takers(s)! Thank you so much for being an important part of WikiConference

Preferred number of note-takers: 2(min) & 3(max). We do not encourage everyone to multi-task during the sessions



Title: Building MediaWiki software to enforce Page & Topic bans

Day & Time: Thursday, August 10, 2017 @ 4 PM

Hyperlinks: Workshop description: Page-blocking project: Wikipedia banning policy:

Speakers: Trevor Bolliger & Sydney Poore


Peter Meyer


  • The problem of people violating blocks is said to be hard to quantify
  • Look at actual bans that are being handed down
  • These users aren't vandals, they are disruptive - pushing an agenda or pushing the limits of their ban
  • Could ORES (revision scoring) help implement a topic ban? It could record that the editor seemed to be violating the ban.
  • Topic bans — A 'medicine' ban could affect /any/ article — e.g. adding medicinal uses to a plant article.
  • How about CAPTCHA or a delay on save? Could those help slow down a distruptive editor? Comment: this is not what CAPTCHA has been used for, but it would be implementable.
  • Productizing this would take a policy change on ENWP — right now banned users are allowed to revert vandalism or BLP violations
  • Potential other feature: Avoiding repeated warnings. When User:A warns User:B, the system asks (or automatically checks!) if User:B has already been warned about the same thing.
  • Is this a form of curation? Or preventing curation?
  • "interaction bans don't work"
  • — 5 topic bans in the last week, 1 site ban
  • "Hard security" vs. "soft security". -
  • Tattling on a user who violated a ban perpetuates the drama — how do we avoid this?
  • How would this work for people creating new pages? We want to avoid adding more work to NPP
    • Banned users with Autopatrol? One view expressed: users with any ban should lose autopatrol. Another view expressed: that some are highly productive but have some specific topic ban so should keep autopatrol effect. Autopatrol is not a disciplinary issue, it's just to help reduce the load on new-page-patrollers.

Discussion Questions

Should there be a publicly viewable list of users blocked from a specific article? Would this create a “hall of shame” that would motivate trolls? Or should this list be only viewable by admins?

Advocate for transparency to allow some folks for some checks and balances.

Three strategies have been proposed. Which of these three do you believe will be the most effective method? 1) Page Blocks should prohibit the user from editing the page.

- Requires policy change

2) Page Blocks should warn the user when they attempt to edit the page, but allow them to do so.

+ Maybe a combination of 2 + 3?

3) Page Blocks should allow a user to violate their Page Ban, but should notify an admin.

- Where do you notify them? Individually? Who is responsible?
+ Maybe a combination of 2 + 3?

Topic Bans are intentionally vague. How should Topic Blocks work? 1) Topic Blocks should prohibit a user from editing a page that is a member of a certain category (E.g. Category:American_actors) 2) Topic Blocks should prohibit a user from editing a page that is a member of a certain Wiki Project. 3) Topic Blocks should not be built because they are intentionally vague. 4) Something else? ORES? AI? The Singularity?

Should page-blocked users be able to edit the corresponding talk pages and subpages?