Improve Abuse Report Management system
Problem to solve
Improve the functionality for managing abuse reports on large GitLab installations such as GitLab.com.
This issue was created to address this research proposal: ux-research#64 (closed).
Further details
Currently the number of abuse reports is relatively low and we don't keep history of the users who have submitted reports. We need to gather feedback from all team members who manage abuse reports in order to understand how they currently use the system and what they'd like to improve about it.
Here are the suggested improvements we've received so far:
-
Keep a permanent record of abuse reports even after they've been addressed.
- "There's no permanent record; if I remove a report it's removed entirely (whether I block the user or not). If someone later wants to know why a user was blocked or why they weren't blocked, there's no way (that I've seen) to show this." (ux-research#64 (comment 69375276))
-
See if a user has been reported in the past.
- "It'd be useful to see if a user has been reported in the past. For example, if someone has a habit of opening up spurious issues, each one in isolation might look like a false report. This isn't as important at the current volume, but it's something that will come in handy at scale." (ux-research#64 (comment 69375276))
-
See all abuse reports a specific user has made.
- "Similarly, it'd be useful to see what reports a specific user has made. Someone with a vendetta or who simply thinks it's fun could repeatedly submit false reports and we have no way to see this beyond reading through the page (and if old reports have been permanently deleted, as above, then we don't even have that)" (ux-research#64 (comment 69375276))
-
Create an audit log.
- "Someone went into the alert queue and cleared it out yesterday. Who? Beyond knowing it was an admin, I have no idea." (ux-research#64 (comment 69375276))
-
Reject an abuse report while also sending feedback to the reporter.
-
Add ticket numbers for abuse reports.
What does success look like, and how can we measure that?
- We've gathered feedback from all Security Products team members who manage abuse reports.
- We've discussed their concerns and suggestions with the Product and UX teams.
- We've created issues, prioritized improvements, and scheduled the issues.