RFC to split reports into admin and mod reports ( lemm.ee )

The RFC PR is here: https://github.com/LemmyNet/rfcs/pull/6

Reposting RFC contents below:

Summary

Rather than combining all reports into a single report inbox, we should allow users to select whether they are reporting to mods or admins, and we should split reports into different inboxes based on that selection.

Motivation

The current approach has some shortcomings:

  • Users are not currently able to bypass mods and report directly to admins - this may allow mods to conceal instance rule breaking in specific communities
  • Admins are not aware of community rules, so they may wish to take no action for most community rule breaking reports. However, if an admin resolves such a report, the relevant community mods most likely never see it.
  • Different instances may have different rules, but somebody resolving a report on one instance will resolve it for other instances as well, thus potentially resulting in missed reports.
  • Mods might take local action on a report and mark it as resolved even in cases where a user should be banned from the entire instance. In this case, admins are very unlikely to see the report.

Guide-level explanation

When creating reports, users will be able to select if it's a mod report, or an admin report (or both)

image

Note: labels on the sreenshot are illustrative, actual labels can be more user-friendy. Maybe something like:

  • Breaks community rules (report sent to moderators)
  • Breaks instance rules (report sent to admins)

Instead of the current single report inbox, there will be three different kinds of inboxes

  • Admin reports - show all reports sent to admins (only visible to admins)
  • Mod reports - show all reports sent to mods for any communities the user moderates (visible to admins in case they are explicit mods in any communities)
    • This is equivalent to the report view that mods currently have in Lemmy already
  • All reports - Shows a view of all (admin and mod) reports, only visible to admins
    • This is akin to the current 0.19.3 admin report view, and would allow admins to still keep an eye on mod actions on their instance if they wish

The UI wouldn't need to change for mods, but for admins, there would be a new selection at the top of the reports page (the "mod reports" tab would only be visible if the admin is also a mod in any community):
image

Resolving reports should be more granular

  • Reports in the "admin reports" tab can only be manually resolved for admins of the local instance
    • To reduce overhead, banning the reported user on the user's home instance + removing reported content should automatically resolve reports for remote admins as well.
  • Reports in the "mod reports" tab should be manually resolved by relevant mods (including admins, if they are explicit mods in the relevant community).
    • To reduce overhead, admins banning the reported user on the community instance OR the user's home instance + removing reported content should automatically resolve reports for mods as well
  • Admins could still resolve reports in the "all reports" tab
    • If it's not an admin report, and not a mod report from a community the admin explicitly moderates, then there should be an additional warning/confirmation when resolving a report here. This is to prevent cases of admins accidentally preventing mods from moderating according to their own community rules.

To further clarify automatic resolution of reports: in any case where there is no further action possible, the report should be automatically resolved.

Mods should be able to escalate reports to admins

This would generate a corresponding report in the admin inbox.

Reference-level explanation

  • In the UI, changes are needed for both reporting as well as the reports inbox views
  • In the database and API, we should split reports by intended audience
  • Federation needs to be changed as well in order to allow distinguishing the report target audience

Drawbacks

It might make reporting slightly more confusing for end users - the mod/admin distinction might not be fully clear to all.

Rationale and alternatives

Alternatively, we could make reporting even more granular. It would be possible to allow users to select only a specific instances admins as the intended report audience, for example.
However, I think this has several downsides:

  • Makes the report UI even more confusing
  • Potentially takes away valuable information from other admins (imagine a user only reports CSAM to their own instances admins, while leaving the offending post authors home admins in the dark)

Prior art

Most other social networks allow users to select whether they are reporting a violation of community rules, or site rules as whole.

Unresolved questions

Does ActivityPub properly support splitting up reports like this?

Future possibilities

In the future, it might be a nice addition to have some automation to always escalate to admins, even if they're submitted as mod reports, based on report keywords. For example, "CSAM", "Spam", etc.

Ludrol ,
@Ludrol@szmer.info avatar

Yes! This is something I was looking for.

The wording could be changed but a good documentation would also be important to make better moderators across whole fediverse.

I still don't know how exactly moderation on lemmy works.

Drewfro66 ,
@Drewfro66@lemmygrad.ml avatar

One additional suggestion I might make is to allow you to report the post to your own instance admins but not the host admins. This would be useful for when you want a post to be hidden or an instance defederated and you don't want to also send your identity to the instance you're reporting.

This might be used for:

Reporting spam coming from an instance that is unlikely to delete it.

Reporting CSAM on an instance that supports it.

Reporting hate speech on instances that believe hate speech is covered by free speech.

Etc.

aeharding ,
@aeharding@lemmy.world avatar

This is trying to solve what having report reasons would solve. If you had admin report reasons and mod report reasons then users can focus on what is the problem with the reported content, rather than who it should go to (casual users dgaf and probably don’t even know the difference between an “instance admin” and a mod)

So I’m not a fan. Again, this feels like trying to fix a symptom of the problem (no report reasons)

Take a few minutes and look how any other site does it.

sunaurus OP ,
@sunaurus@lemm.ee avatar

I think separate report inboxes are needed for the report reasons approach as well. This RFC doesn't prevent having report reasons, rather I think it brings us closer to that goal.

aeharding ,
@aeharding@lemmy.world avatar

Yeah, exposing what report goes to who in the create report API is my main problem with this proposal. You’re approaching this from a power user perspective.

EinfachUnersetzlich ,

As a mere user I have no idea what should be reported to whom. It needs to be really obvious and I'd like to see predefined categories as options, e.g. "breaks community rules" (ideally with options to select which rule was broken), "spam", "illegal content" (remembering that what's illegal in one place may not be illegal in others).

For reporting to admins, which admins get the report? If I'm on instance A reading a community hosted on instance B and report a comment from a user on instance C, who gets the report? It'd be really nice to see a list of those when selecting a report type, e.g. "this report will be sent to the moderators of lemmy@lemmy.ml" or "this report will be sent to the administrators of lemm.ee, lemmy.ml and startrek.website".

MimicJar ,

Someone please correct me, but a few months back on Mastodon I reported a post (on a different instance) and it went to the admin of my instance.

I assume it's the same for Lemmy.

Blaze ,
@Blaze@reddthat.com avatar

Thank you for this!

Demigodrick ,
@Demigodrick@lemmy.zip avatar

Most other social networks allow users to select whether they are reporting a violation of community rules, or site rules as whole.

Why not take this approach to simplify it then?

Asking the user to specify who they think should receive a report feels like it will add confusion (not to mention is subjective anyway), and could create delays in responding to important stuff if the user picks the "wrong" option. If a user picks the mod option on csam report then it might get missed by an admin? At least the option between "this community" or "site rules" is a bit clearer.

This is to prevent cases of admins accidentally preventing mods from moderating according to their own community rules

As an admin I should be able to respond to a mod report on a community if I'm there first and its urgent, i.e. csam. This is a policy/discussion point between mods and admins on any given instance and shouldn't be enforced in the software. Separation for clarity's sake is fine, I even encourage that as I don't tend to touch a report for a community anyway as it stands, but I should be able to mark a report complete if I have dealt with it. Otherwise I'm just going to go to the post and sort it out anyway, so its just adding complexity.

Admins can still always explicitly take over communities by making themselves mods, in this way, they are able to handle mod reports for any abandoned communities, etc

Barriers/extra steps to administration is not the way forward here. Continuing with Admins being able to mark reports resolved just makes sense.

Alternatively, we could make reporting even more granular. It would be possible to allow users to select only a specific instances admins as the intended report audience, for example.

No. This is a step backwards in transparency and moderation efforts. Granularity and more options is not always a good thing. If you've ever had the misfortune of using Meta's report functionality you'll know how overly complex and frustrating their report system is to use with all their "granularity".

Simplicity of use and getting a report to someone who can do something about it quickly should always be the priority, adding options and functionality should be secondary and support this. If you don't want to be stepping on moderators toes, make that clear in your guidelines and processes.

I am legally on the hook for content on my instance, not the moderators, and proposing changes that make it harder to be an admin is a touch annoying.

To add:
I would suggest thinking about expanding this to notify the user a report has been dealt with/resolved, optionally including rationale, because that feedback element can sometimes be lacking.

sunaurus OP , (edited )
@sunaurus@lemm.ee avatar

Thanks for the thoughts!

Why not take this approach to simplify it then?

Yeah, the wording can be changed, I'm adding a note about it to the RFC

But I should be able to mark a report complete if I have dealt with it. Otherwise I’m just going to go to the post and sort it out anyway, so its just adding complexity.
Barriers/extra steps to administration is not the way forward here.

I think in this particular case, some barriers are crucial. At the very least, I think we need to have warnings/extra confirmations when an admin wants to resolve a mod report.

I mean, if an admin handles it to the point where mods can't take any further actions anyway (ban + content removal), then the report is automatically resolved already, so there is no need to manually resolve. OTOH, if an admin handles it in a way that a mod might still want to take additional action (for example, the admin just removes a comment), a mod might still want to take further action (for example, ban the offending user from their community), but if the admin marks the mod report as resolved, the mod will most likely end up never seeing it.

I am legally on the hook for content on my instance, not the moderators, and proposing changes that make it harder to be an admin is a touch annoying.

Btw, I don't think any admin actions should be made harder, I am only talking about adding barriers to resolving reports which are in mod inboxes, and when I say "resolving reports", I am literally just talking about marking the report as resolved (this shouldn't really be a common action for admins - it's akin to marking DMs as read for other users IMO). I don't want to limit admins in any way from banning/removing content/anything like that.

No. This is a step backwards in transparency and moderation efforts. Granularity and more options is not always a good thing. If you’ve ever had the misfortune of using Meta’s report functionality you’ll know how overly complex and frustrating their report system is to use with all their “granularity”.

Agreed, I think that's in line with why I proposed not going that path in the RFC as well.

To add: I would suggest thinking about expanding this to notify the user a report has been dealt with/resolved, optionally including rationale, because that feedback element can sometimes be lacking.

I think that would a good additional feature, but orthogonal to this particular RFC (I mean, neither feature depends on each other)

otter , (edited )
@otter@lemmy.ca avatar

This would be very helpful with current moderation issues. If we're already feeling behind with the current userbase, imagine how bad it could get with another migration.

I'll add more thoughts here as I have them:

  • You could change the wording on the report options to clarify when a report should go to the community mods (ex. "Does this break a community rule?"). Any other issues should probably go to the admins?

    • It might help to allow community / instance admins to modify this message.

  • While I don't think admins should be removing things that were reported to the community, they should be able to remove things outside of reports (even without being a mod). Sometimes spam might get reported to the mods, but the admins need to take action. Could the 'read only' view add a little warning before action is taken?

Also a different but related issue:

  • setting some default report options that automatically go to the admins. For example: "spam" or "NSFW". This could allow the admins to triage content, or set better automated tools. It's harder to do that with free form reports
sunaurus OP , (edited )
@sunaurus@lemm.ee avatar

Thanks for the comment! I think I generally agree with your points, will try to incorporate them into the RFC soon.

While I don’t think admins should be removing things that were reported to the community, they should be able to remove things outside of reports (even without being a mod). Sometimes spam might get reported to the mods, but the admins need to take action. Could the ‘read only’ view add a little warning before action is taken?

To be clear, admins are always able to do that anyway, I'm not proposing any changes to this. I am only proposing to limit the actual "mark as resolved" action, in order to prevent admins from accidentally hiding reports from mods. But I think it makes sense to even not limit this completely, and rather just show a warning when an admin does it - I have updated the RFC.

Btw, for this one:

Sometimes spam might get reported to the mods, but the admins need to take action.

I think it will mostly be OK as long as we allow mods to escalate reports to admins. But still, maybe it is indeed necessary to allow admins to directly resolve mod reports (with an extra UI confirmation step) as well.

otter ,
@otter@lemmy.ca avatar

Appreciate you taking the time to make things better :)

freamon ,

Regarding the 'Unresolved questions' part, the ActivityPub activity for Reports is:

{
  "actor": "http://ds9.lemmy.ml/u/lemmy_alpha",
  "to": ["http://enterprise.lemmy.ml/c/main"],
  "audience": "http://enterprise.lemmy.ml/u/main",
  "object": "http://enterprise.lemmy.ml/post/7",
  "summary": "report this post",
  "type": "Flag",
  "id": "http://ds9.lemmy.ml/activities/flag/98b0933f-5e45-4a95-a15f-e0dc86361ba4"
}

From this page. I imagine it's up to lemmy where this actually gets sent (in the sense that if a community has 1 moderator, it goes to 1 inbox, but if it has 2 moderators, it goes to 2 inboxes).

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • random
  • lemmy@lemmy.ml
  • test
  • worldmews
  • mews
  • All magazines
    •