[wp-meta] [Making WordPress.org] #5717: Support Forums: Improve topic report functionality

[Making WordPress.org]

#5717: Support Forums: Improve topic report functionality
----------------------------+--------------------
 Reporter:  Clorith         |      Owner:  (none)
     Type:  task            |     Status:  new
 Priority:  normal          |  Milestone:
Component:  Support Forums  |   Keywords:
----------------------------+--------------------
 This will be an overarching task of multiple enhancements that together
 will make things better in the grand scheme of things.

 The current state of a reported topic is a mix between using the `modlook`
 tag, and storing the reporter details in postmeta and displaying it in the
 sidebar.

 Although a great initial implementation, over time some other needs and
 necessities have shown them selves.

 I'm proposing we retain the sidebar report area, but make it more user
 friendly (we do get users joining Slack asking where to report a topic or
 review for example).

 To improve discoveryability here:
 - Always show the report area, but make it context aware, if you can't
 report a topic, show why (topic is closed, only logged in users may report
 a topic etc)
 - Add some kind of visual indicator, something simple but effective like
 making the flag icon "report this red", when there's little to no color
 used elsewhere?

 For the reports them selves, move away from postmeta, and instead inject
 the report message as a custom comment type, only visible to those with
 moderator capabilities. This also brings multiple benefits to the table;
 - Easier to read, compared to the compacted sidebar area
 - Puts the report into context in the timeline of a thread
 - Allows us to pull data in user profiles on the reports they make, to
 make it easier to identify potential new members for the team

 There is one drawback to moving it out of postmeta, I'd call it a minor
 inconvenience that's easy to solve, more so than a drawback. A migration
 script should be ran to pull existing reports out of postmeta and added as
 post types as well. This should work well to backfill, since we have
 author data, report reason, and a timestamp, all that's needed to fit it
 into the timeline.

 Those were the easy tasks, next up some improvements for privacy and user
 security.

 Privacy related, we tell users that their report is anonymous, only
 moderators can see what they reported, and that they reported, a topic
 (unless they manually added the `modlook` tag), when in reality if a mod
 doesn't understand the report, the user will more often than not be called
 out in the #forums channel on Slack.

 Let's improve on this, and add an inline action to the report comment
 type, allowing someone with moderator caps to reply directly to the
 reporter. This would be a one-way communication tool, it would still
 register who wrote the reply for our own sake (since this would be hidden
 to non-moderator users), but it would always send a notification to the
 reporter about the outcome of their report (I think this might be a
 benefit regardless if you need to clarify something, or if action has been
 taken, let the reporter know that their report was seen and acted on in
 one way or another).

 The benefit of this kind of notification is that we can set the sender,
 let the message be sent by the "WordPress.org Forums" or similar, taking
 the moderator out of the equation in a "we are one" kind of scenario. This
 does remove a little bit of the human element, but it also removes a huge
 factor for retributions against individual moderators if the user doesn't
 know which moderator acted on their topic.

-- 
Ticket URL: <https://meta.trac.wordpress.org/ticket/5717>
Making WordPress.org <https://meta.trac.wordpress.org/>
Making WordPress.org