Report a Topic

[citizenos]

Report a Topic

[oksks]

Just arrived here, as I went through the Report Topic flow (for Crowdin screenshots) and it's really weird to go through a proper flow, click the "YES I'M ABSOLUTELY SURE" (or something) in the "Are you sure you want to report this topic?" window, and then have everything disappear without any confirmation that I've actually gone through it successfully.

Pretty please add a confirmation - maybe even pin a red notification to the topic's heading, that "You've reported this topic on DD.MM.YYYY".

[tiblu]

Assets (sorry, not public yet): https://projects.invisionapp.com/d/main#/console/9829159/241763981/inspect

[tiblu]

@loorm What do you think we should do when a Topic gets moderated?

I think we should follow our rule of hiding not deleting.
We should also consider a situation when the Topic gets fixed, then we could make it visible again.

[tiblu]

I am to create some new e-mail templates so I created a side track - #41 and will fix this before I complete this task.

[tiblu]

Marked as "blocked", we need to discuss what the UX will be.

The questions are:

• IF a Topic gets moderated, what will be shown in the FE?

All the work done so far is in the "report_topic" branch - https://github.com/citizenos/citizenos-api/tree/report_topic

[loorm]

My 10 cents:

• both public and private topics can be reported, regardless of their status (even closed topics, because they are still visible)
• reporting should be similar to argument reporting (same reasons, same dialog asking for explanation)
• any logged in user should be able to report any public topic (need to check legals, if non-logged in users also need to be able to report)
• if a public topic is reported, it is automatically switched to private, pending fixing or moderator decision, if topic is in voting, voting should be halted - THIS IS AN IDEA TO BE DISCUSSED
• moderation cycle should be started similar to argument reporting incl. topic owner notification etc.
• there should be a clear notification / overlay to indicate, that the topic contains potentially offensive material, that has been reported, the decision is pending and user should read on at their own risk
• if a topic is found to be offensive and author does not fix, we don't show it on front page, but possibly will show it to subscribed users, only with an overlay similar to "deleted" arguments.

[tiblu]

The proposed mechanics with @loorm @kevincrepin @tiblu

• You can report both public & private Topics
• Report notification/email:
  • Private topics - to creator, admin level members
  • Public topics - to creator, partner/global moderators, admin level members
• What happens to reported Topic?
  • Nothing happens on report itself (before moderation)
  • When moderated:
    • Hide from Home page default view
    • Home page new filter to show "moderated" Topics
    • Overlay the Topic in READ ONLY view, with "Show anyway" action
    • Notification bar in EDIT MODE ("Youre editing reported topic") for all views (voting, followUp, closed)
      • Show count of reports
      • Show link to moderation guidelines
    • EDIT MODE has "Submit for review" to notify Moderators that the violation has been removed.
    • No search engine indexing of moderated topics.
• Report reason "Contains spam or is unrelated to topic" REMOVED for Topics
  • Split into 2 "Contains spam" / "Unrelated to Topic"
• IF a reported Topic gets exported, it will have notice in the final document about being reported with the violation reason.

Open questions:

• ANY user can report? NO, read below (#5 (comment)).
• Can we share reporters contact info with Moderators to ask for clarification? YES, TOS update. (#5 (comment))
• Do we need to report private topics? NO (#5 (comment)).

[kevincrepin]

Couple more questions from my end:

• Do we show who reported the topic publicly?

• When reporting, is the additional text field obligatory? Do we show that input publicly?

Overlay: https://projects.invisionapp.com/d/main#/console/9829159/333531893/preview
Notification: https://projects.invisionapp.com/d/main#/console/9829159/333531894/preview
Edit mode: https://projects.invisionapp.com/d/main#/console/9829159/333531895/preview

@tiblu let's discuss when you're back from vacation.

[tiblu]

My 10 cents on the @kevincrepin questions:

Do we show who reported the topic publicly?

No, I don't think so.

When reporting, is the additional text field obligatory? Do we show that input publicly?
Not obligatory for arguments right now, so it's not obligatory for Topics for consistency.

Yes, the input is shown publicly.
I think we should consider making it compulsory to make a person think if the violation actually is there (take out the emotional aspect) and help moderation. Always good to explain your actions. WDYT @loorm?

Overlay: https://projects.invisionapp.com/d/main#/console/9829159/333531893/preview
@kevincrepin @loorm
Not sure we want to show such detailed info? Maybe just a number of reports is enough or?

@loorm Is there any progress on the open questions from legal side:

Open questions:
ANY user can report?
Can we share reporters contact info with Moderators to ask for clarification?
Do we need to report private topics?

[tiblu]

Created #70 to unify token usage before we start issuing new tokens for Topic Moderation.

[tiblu]

Differences between current argument (Comment) and new Topic moderation solutions

Ideological differences

NOTE: We use Arguments term in the UI, in the DB and technical discussions we use Comments. So, we use Comments here.

Terms:

• report, reporting - A User generated violation report.
• moderation - A Moderator has approved a report, thus restrictions apply to content.

Differences:

• Editing content
  • Comments - Once a Comment has been moderated, User cannot edit the comment.
  • Topic - User can edit Topic moderated or not.
• Reversal/disputes -
  • Comments - Once a Comment has been moderated, there is no reversal - you cannot dispute the moderators decision and make it visible in the UI. It's forever hidden from default views.
  • Topics - Once a Topic has been moderated, User can dispute the moderators decision with "Send for review" feature. Same feature can be used to lift the restrictions from Topic after User has edited the Topic.

After we have implemented the Topic moderation, it makes sense to review both solutions and unify to whichever works best.

Database schema differences

Notes on the DB differences:

• Comments schema clutters entity (Comments) table, when reporting capability is added by adding fields deletedByReportId. To clarify fields deletedReasonText, deletedById, deletedReasonType ARE NOT moderation specific - if User deletes his own comment, these are filled as well.
• Comments schema does not support disputes & reversal.
• Comments schema creates an intermediate CommentReports table which adds un-necessary complexity to the DB. The initial idea of the intermediate table was to have single Reports table and several different entities that can be linked to Reports without loosing the power of FK/PK constraints to guarantee DB integrity - that is, not to have ambiguous UUID in the Reports table that can reference any entity (Topic, Comment, User...).
• Comments schema guarantees consistency by using single Reports table.
• Topics schema supports disputes & reversal via resolvedById and resolvedAt columns. When a dispute/reversal request is made using "Send for review", Moderators get an e-mail, which grant them permission to approve changes and lift restrictions. At that time resolvedById is the Moderator id and resolvedAt is NOW().
• Topics schema guarantees consistency by extending Reports model - same solution as TopicMemberUsers/Groups extend TopicMember.
• Topics schema enables simpler queries.

Other thinking points

• What if we also start using deletedBy, deleteReasonType, deleteReasonText for Topics? This would enable Users to leave traces behind of why a Topic was deleted and we can show these reasons to Users requesting the Topic. The traces (deleteReasonText) could possibly link another Topic which was created instead or smth. The CON part of it is that if we request a reason for every Topic, it may become annoying to Users and clutter the UI.

@ilmartyrk Please have a look if this all makes sense to you, is there anything unclear or something you find weird?

[tiblu]

@loorm

The missing answers are here. These are from meeting with Kati on the 23rd of January 2019.

ANY user can report?

TLDR: NO.
Long version:

• As an anonymous user of a system I would more willing to report issues as there is no log-in barrier and also no tracking of my identity (in case you're afraid of some consequences).
• As a lawyer, it is not that convenient. In case there is some illegal activity like spamming the system to death, it's quite hard to track and trace. TODO Lawyers input of what else she did not like?
• From Moderator perspective spam is making it harder to do quality job. We assume that Moderators are neutral and won't let their personal beliefs affect the work, thus it takes more effort to evaluate each report. Moderators make sure that content is legal and polite conforms to our Terms of Use.
• From technical perspective authentication reduces probability of spam. By spamming the system it's the extra computing cycles and disk space.

Can we share reporters contact info with Moderators to ask for clarification?

TLDR: YES, BUT we need to add this to the Terms of Use (TOU) and Privacy Policy.
Long version:

• In order for a Moderator to do quality Moderation, it MAY be necessary to contact the reporter for extra info. These cases MAY include fact checking etc.
• In case of spamming, we may contact the User to try to solve the issue with communication before blocking.

Do we need to report private topics?

TLDR: NO.
Long version:

• There is no NEED from legal perspective to enable reporting content related to private Topics.
• IF we want to enable this for some reason, we MUST consider that in order to enable Moderators work, he/she needs to see the content THUS making it NOT SO PRIVATE. That is - there is an easy way to spill private data by accident. So, IFwe really want to, we have to change our concept of PUBLIC/PRIVATE to PUBLIC/ALMOSTPRIVATE.

[tiblu]

Public discussion on Topic moderation is in Citizen OS - https://app.citizenos.com/en/topics/ac8b66a4-ca56-4d02-8406-5e19da73d7ce?argumentsPage=1

[tiblu]

@kevincrepin We've added the topic moderation e-mail content to the Citizen OS public topic. We need your magic touch to make those e-mails shine! https://app.citizenos.com/en/topics/ac8b66a4-ca56-4d02-8406-5e19da73d7ce?argumentsPage=1

[tiblu]

E-mail designs are done, ready to continue with the dev!

[tiblu]

What it looks like when a person accesses a topic which has been moderated?

Source: https://projects.invisionapp.com/d/main#/console/9829159/333531893/preview

[tiblu]

@kevincrepin We had a discussion about moderation with @loorm.

The outcomes are:

• There can only be one report active at a time. Why? To avoid overwhelming moderators with reports.
• Once Topic is reported, reporting functionality is hidden/disabled.
• Once Topic is reported, NOT moderated, there has to be a notification "already reported" somewhere.
• Three can only be one review request at a time. Why? To avoid overwhelming moderators with review requests.
• Once Topic is sent for a review, "send for a review" functionality is hidden/disabled.
• Once Topic is sent for a review, there has to be a notification "already sent for a review" somewhere.
• Moderators should be able to lift restrictions from a Topic WITH AND WITHOUT a review request.

@kevincrepin Things we need to update/create:

• The moderated Topic overlay ("This topic has been reported") - https://projects.invisionapp.com/d/main#/console/9829159/333531893/preview
  • There can only be 1 report, 1 reason, 1 explanation text.
  • We need to reflect the current status on that overlay so that User has clear idea in what phase the moderation process is:
    • Waiting for update & review request - Topic has been moderated, now any of the Members with "edit" permissions needs to update the content and send a review request.
    • Pending moderator review - Topic has been sent for a review to Moderators
• We need a place where Moderators can do their work:
  • Approve or reject a report,
  • Approve or reject review request.
  • Moderators should be able to lift restrictions without a review request.
  • We need to implement it so that we make an effort in making sure Moderator actually read the Topic.

[kevincrepin]

I think for the current version of the platform we could reuse the "my Topics" layout: https://projects.invisionapp.com/d/main#/console/9829159/361400700/preview

So we have the reported topics on the left side, they're also "filterable" in case of many. On the right side we have the same general information on the topic, but in the second block we have the report information and actions.
In the menu there would be an additional menu item to get to the reported topics, but only for moderators.

Alternatively we could also just have this information as part of the "My Topics", but it will not be so visible then. Even through notifications it might still be a bit hard to find the reported topics then...

Dialog window update: https://projects.invisionapp.com/d/main#/console/9829159/333531893/preview

[tiblu]

@kevincrepin We discussed the layout with @loorm and it looks good to us.

• We're missing is a "all reports" view which is shown when there is nothing reported.
• Should we have shortcut link in the Topic view "Options" menu to take to the "reported view" for moderation? Something that pops in your eye.

[tiblu]

@kevincrepin @loorm

Everywhere where we display Topic title or content, we need a way to mask/mark/hide it until there is user request to view it anyway.
Among these are:

• Search results
• Home page
• Topics list view

[tiblu]

@loorm

Notes on the Topic report implementation v1:

• In this scope, we have resolved the Topic view (/topics/:topicId), but in the future we MUST tackle other views that expose Topic content. See #5 (comment)
• Currently we create no activities to the activity feed about the reporting. We need to agree what activites we want to create.
• The community guideline links in the emails and the FE take to Citizen OS Topic Moderation Topic. We need to polish it's content. https://app.citizenos.com/en/topics/ac8b66a4-ca56-4d02-8406-5e19da73d7ce
• Currently we hide "Report" actions when Topic has already been reported and is waiting for Moderator action. Maybe we want some other UX, to let Users know that it's pending Moderator review?
• While you can have one report request at the time, we allow multiple "Review" requests, each sends Moderators a new e-mail. We MAY want to reconsider it - make 1 review request be open at the time, but then that means we have to have a means keeping track and closing review requests. Right now review request only sends e-mails, it has no state stored in DB.
• When a Moderator reports a Topic, the UI is not updated instantly with Moderator action elements.
• When a User reports a Topic, we show no "Thanks for reporting" message. We MAY want to add that. We do say thanks in e-mail IF the User has e-mail address in the profile. IF we add "Thanks" to the UI, we MAY want to show Report ID to refer to when contacting customer support.

[tiblu]

Citizen OS deployment notes:

• PROD DB backup before update - b1242
• PROD API release version in Heroku - v494
• PROD FE release version in Heroku - v377

[KatiVellak]

Legally reviewed, during the discussions legal input provided.