Just a hunch, but is it possible you missed the --recursive
flag when cloning the repo?
Just a hunch, but is it possible you missed the --recursive
flag when cloning the repo?
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.
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)
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.
Or do you mean reports on content now go to the user’s home instance as well?
Yes, exactly.
Also, there’s no way to report a user to their home instance so long as they don’t post anything in a community on their home instance.
This has been fixed in 0.19 thankfully. But for instances running older versions, what you said is still true.
I’m not sure what the exact circumstances are here, but something to note is that upgrading to 0.19 will mostly just help with outgoing federation (0.19.2 is much more reliable and robust when delivering activities to other instances compared to 0.18). We will start seeing the full benefits of this as more of the network upgrades.
FYI to all admins: with the next release of pict-rs, it should be much easier to detect orphaned images, as the pict-rs database will be moved to postgresql. I am planning to build a hashtable of “in-use” images by iterating through all posts and comments by lemm.ee users (+ avatars and banners of course), and then I will iterate through all images in the pict-rs database, and if they are not in the “in-use” hash table, I will purge them.
Of course, Lemmy can be improved to handle this case better as well!
Well, I’m an Estonian citizen at least 😅
It helps, but it’s still not a silver bullet. For example, a Lemmy app could contain no malicious code in its open source repository, but malicious code could still be added to a binary release in an app store.
Hey, for the record, bigotry is not allowed on lemm.ee, and I have no problems with defederatating any instance which encourages its users to break that rule in any of our communities (or to harm our users in other ways).
More context here if anybody is struggling with bots: http://lemmy.ml/post/1391903
I’ll try to help you out in DMs in a minute, hang tight!
You are able to edit and remove your posts on your Lemmy instance. Other Lemmy instances may or may not also reflect these changes, but your instance admin does not have any authority or responsibility to ensure that your previously public posts get deleted anywhere else in the world other than the instance they run.
That’s exactly how it works everywhere, it’s not a Lemmy specific thing. For example, if you write a public blog post on some public blog service, and later delete it, then it won’t be the responsibility of the blog service owner to remove your post from elsewhere on the internet. It will be your own responsibility to manually request removal from other services which have copies of your post (like archvie.org etc).
Public posts and comments are, well, public (and there’s no expectation from users that their posts and comments would be private, considering the nature of what Lemmy is).
The only way to not transport public posts and comments to the rest of the internet (including but not limited to other Lemmy instances) would be to completely disconnect an instance from the internet 😅
And personal data goes really far. Even an IP-address is personal data. An e-mail address is personal data.
Thankfully, Lemmy instances do not transport this kind of information about their users to other instances!
Did you figure out how to clean it up? You can see a list of users in your local_user
table.
It’s not really a bug, it’s just a case where app developers need to update their code to support a small change in the Lemmy API. More details here: https://lemm.ee/post/34259050/12479585