rust-community-discord / ferrisbot-for-discord

Rust programming language bot for Discord
MIT License
36 stars 13 forks source link

Moderation suite #51

Open dawnofmidnight opened 1 month ago

dawnofmidnight commented 1 month ago

(part of the Carl ⇒ Ferris migration) (pending discussion from mods, wait for approval to implement)

A huge part of what we got from Carl is the moderation suite, and we need to move that to Ferris. We could do a 1:1-ish port, but I know that generally we had some gripes with Carl. As opposed to the other issues, I won't propose a particular design here, although I will leave a comment with my very tentative design ideas. This is primarily here for discussion and tracking.

However, I will note that we should have integration with inbuilt Discord moderation. Regardless of the system, if a mod does a ban/kick/timeout using the native system, it should be registered in our database as being no different from an action done by our own commands.

dawnofmidnight commented 1 month ago

This is my personal design sketch for the moderation suite. It's primarily based on a my main pain point with Carl—namely, that warns, notes, bans, etc. are all separate kinds of things. I think it necessary that we have a unified infraction (bikesheddable name) interface that manages all of these.

Fundamentally, each infraction should have the following information:

These should be associated with the following commands (all of these can also be slash commands, and I'm using i as short for infraction):

Here are the types of infractions I think we should have. These should also be accessible at the top level (i.e. as both ?i ban and ?ban):

So, yeah. This is my very tentative design of the moderation suite. None of this is final or approved in any way, it's just my thoughts.

troiganto commented 1 month ago

For things like temporary offtopic bans and VC bans, Carl has generalized commands that work like mute/tempmute/unmute but for any given role. Given the large number of moderation-related roles we have, I think this would be useful here.

To avoid misunderstandings, mute/unmute should be renamed to "timeout" to make clear it uses the Discord built-in feature. Our classic muted role would then be applied by ?i temprole @Muted and ?i role @Muted or something similar.

One pet peeve with Carl is that if you don't specify a time frame for a mute, it defaulted to, I think, 30 minutes. I think that's a very minor design decision we should avoid here.