User:LFaraone/Privost/Brainstorming

Problem statement
Many people have expressed concern that the current system for managing requests for Oversight on the English Wikipedia, OTRS, is poor. Namely, it often results in lost requests, requires a lot of manual work on the part of the Oversight team, and requires the sender to enable EmailUser or send a message from their email client.

We should take a fresh look at our existing workflow, and see whether there are ways to improve the process for all parties involved.

Article Feedback Tool
The Article Feedback Tool had a built-in mechanism for requesting Oversight, where reviewers of feedback could mark a feedback entry for hiding and generate an email to the Oversight team.

Upon receipt, an Oversighter could approve or reject the request from within the MediaWiki interface with a few clicks.

Unblock Ticket Request System
UTRS provides a structured form to request information needed to adjudicate unblock requests. It is hosted on Tool Labs, and maintained by community members. To administrators, it includes a dashboard and a clearly defined workflow for escalation to e.g. a CheckUser if needed.

Commons:Undeletion Requests
Wikimedia Commons uses a custom JavaScript widget to handle submission of requests for undeletion. It collects the required information to make a clear, actionable request and makes the edits in the appropriate place on behalf of the user.

Create an external tool to manage requests that integrates with MediaWiki
This would be along the lines of UTRS; Oversight and related pages would link to something like https://privacy.wmflabs.org/wikipedia/en/ (not a working link), which would ask the user for a link to the page or diffs they wanted to suppress. Authentication would be performed via OAuth.

Upon receipt, an email would be sent to Oversight team members. It could be limited to certain members who were "on call", or similar, to minimise leakage of requests that currently sit in the mail archives of all members. The interface would present the request, and provide a mechanism to reject, ask for more information, escalate to the team mailing list / WMF office, or approve it. Since Oversighters will similarly be connected to the application via OAuth, the requisite steps could be performed automatically from within the incident page.

For more technically-inclined Oversighers, mail filters could be used to hide requests that had been actioned already, reducing duplicate work.

While a community-managed tool, it would be subject to the Wikimedia Labs Terms of Use and data disclosed via it would still be subject to the Foundation's privacy policy.

Extend the suppression functionality to handle request management
Suppression is built-in to core MediaWiki, implemented as part of RevisionDelete. We could build additional tools to complement it inside MediaWiki, with a similar flow to that discussed above. While this has the advantage of being maintained by the WMF, it would probably have to be implemented as an extension and run through the MediaWiki code review process. This might impede the speed of initial deployment and change implementation. Your author also dislikes writing PHP.