Collective/community moderation for backend

[thomasgwatson]

All queries about posts are impacted:

• need to check if a post is flagged
• maybe just limit it to that for feed loads and rely on a click-through (and thus a load of PostDetail) to load all the extra stuff

posts table

• Need a short-hand way of knowing if a post is flagged. Do we do it in the db on the table and update constantly? Do we add it to the Post model as a getter and expose that way?

  platform agreements

  These now need to be tracked in the db. After thinking about it for a bit, it is pretty simple to just keep them as a separate table, instead of messing around with extending the agreements table.

posts_users

• [ ] track whether a user has clicked-through on a post
• [ ] reset this value with each flag?
• [ ] build out mutations and model methods to allow this

How do we want to handle the database

• flag table (? a new table => moderation actions)
• activities table rehash?

I would also expect that moderation actions will be a record for other forms of moderation action in the future but we don't need to plan for that now

Need to capture

• relationships to agreements (many to many, so join table go whoosh. agreements_moderation_actions)
• text
• relationship to reporter (to one)
• relationship to post (to one)
• status (allow them to be cleared or reset)
• whether the reporter can be shown

Query changes (graphql)

• [ ] posts need to expose something concise (one field)
• [ ] posts need to expose a full relationship to moderation_actions
• [ ] ModerationActionQuerySet

Mutations

• [ ] allow moderator to clear flags
• [ ] allow creation of flag (no edits?)
• [ ] allow clearing of flag by reporter (no deletes?)
• [ ] record click-through by user

Notifications:

• [ ] Author and moderators are notified that a post has been flagged from their group
• [ ] Moderators get a notification if a post in their group has been flagged in another group (extra)

[thomasgwatson]

@tibetsprague Ok... so if we have to do think, I'm thinking about cranking it out asap.

Can you think of any other backend requirements, mutations, query changes, db changes? etc

[thomasgwatson]

Ok, thinking about alternatives/possibilities here, even though I don't think they'll make it into the MVP

1) Along the lines of 'everything is a post' thinking;

Moderation_actions could be seen as an extension to the posts table. So everytime a moderation action is taken, it also creates a linked post. That linked post gives us a dedicated space for on-going discussion about the moderation action. (Previously I think there was some idea that this discussion would take place in the comments of the original post)

Instead the separation of the discussion allows for a separation of commentary (like editing discussions in wikipedia). The creation of a post would create a simple way to filter/query for moderation actions (they could be included in custom views much easier), allowing the mixing of (for example) proposals and moderation actions into a single posts stream

I don't think we should just modify the posts table to just add another type (like with proposals). In part I would be worrying about overloading the Posts table.

The separation of the discussion to its own post would also help with another possible change: being able to submit one flag for multiple pieces of content. Lots of apps ask you if any other content from someone you are reporting is flaggable. Having the discussion separate would be necessary in this instance.

Again... I am reluctant to increase the scope to include these ideas but want to document some of my thinking as I start implementing

[tibetsprague]

agreed on the moderation_actions table, and I think on posts we should have a cache of current # of "flags" or "reports", need to think about the best language here. That way we dont have to add a whole other join when loading the stream, then when someone clicks on the post we can load the full set of moderation actions. this column gets updated whenever a new moderation action occurs.

good question about whether to reset the click through anyway column if the post is flagged even more. probably not, I think at that point its up to the user whether they want to flag/report/hide that post (future idea to allow for hiding posts even if you dont want to report it)

do we have to have a table for platform agreements or can we just store them in the code, in a JSON file maybe? rather not add more database queries if we don't need to. I guess if we are having moderation actions reference an agreement to know which agreement I broke we may want to be able to reference the agreement by id, and track reports over time that way. so yeah, probably do need a table. will have to be a polymorphic relationship though, agreement_id, agreement_type.

[tibetsprague]

on the fence about creating a post for moderation_actions 🤔 if we do do that then it would have to be a different post type though, how else would we know when and where to show it? I dont imagine ever having 1 flag for multiple pieces of content at the same time, what scenario can you imagine for that? for the one you describe it could still just create multiple moderation_actions

[thomasgwatson]

When I've reported stuff on twitter or facebook there are times its asked if the user I am reporting has other prohibited content. And yeah, the post would still show up everywhere else as is but I was thinking it'd be nice for it to be default discussion and then be upgradable by moderators (or the community in the future) to a proposal. Then we could start tying together some of the features and having some forms of proposals be platform-enforceable.

Again, this is just speculation for the future that I wanted to air out

[thomasgwatson]

"(future idea to allow for hiding posts even if you dont want to report it)"

I think there is a rich vein of possibilities with tracking post-user state, like hiding things, "show me later", "last seen", etc etc that feed into helping folks 'catch-up' on content

agreed on the moderation_actions table, and I think on posts we should have a cache of current # of "flags" or "reports", need to think about the best language here. That way we dont have to add a whole other join when loading the stream, then when someone clicks on the post we can load the full set of moderation actions. this column gets updated whenever a new moderation action occurs.

Do we need a number? Is a boolean enough? Like its just a boolean column on posts... ahh but what about a multi-group post? Are we blurring it everywhere if it gets flagged somewhere (I think we said yes for platform at least...). Many its not a boolean but an array of groupIds (if you are in one of the flagged groups, we blur it)

[tibetsprague]

we need a number because the amount of hiding of the post will evolve as the # of reports come in. and maybe it needs to be on the groups_posts instead of on the post.

[thomasgwatson]

hmmm, and the number might go up or down.... or be cleared by an admin...

I was going to suggest an array of groupIds on the post table, with multiple reports meaning that the same groupId is repeated per report. It'd be easy to query (just an extension of the Post type), since we aren't directly returning values from the groups_posts table at the moment (so changing that would be more futzing in the resolvers).

But that gets messy in the future when we track this tug-of-war idea of reports being reviewed by the community. Again, we could just punt on that (since we aren't implementing it now anyway) and just focus on the tighter scope of whether something is flagged or not. An array of groupIds would work for that

[KevinTriplett]

@thomasgwatson I would love to meet on zoom, so you can describe what you're seeing. Moderation is a domain I'm highly interested in, and I have good experience with databases, so I should be a quick learner and offer suggestions. I'm aware of the "too many cooks" and "design by committee" syndrome, so my role is to support, rather than muck things up. Here's a calendly link to help with timezones: https://calendly.com/kevintriplett/project-meeting

[KevinTriplett]

On re-reading the discussion, I feel more strongly that this could be a HUGE differentiator for Hylo and one that would benefit from a series of small, iterative experiments. Moderation is something the community I'm a member of (Emergent Commons) is focused on (it's the reason for our founding) and we've been running experiments for the past three years to refine our innovative approach. But we've run into limitations with Mighty Networks and improved moderation would be a major reason for our migrating to Hylo. I would very much like to be involved in helping guide this effort, if you're willing to accept my input.