search

rust-lang / discord-mods-bot

discord moderation bot
MIT License
72 stars 30 forks source link

[Discussion] Standardization of configuration and feature metas. #8

Open khionu opened 5 years ago

khionu commented 5 years ago

Right now, the bot is a mix of various "bars" of thoroughness and mediums, in configuration and organization. We should standardize how the bot should be structured as a collection of features. This discussion should answer the following:

Browncoat

I started a WIP command framework to handle permissions as well as argument parsing. In using Serenity, the Discord Framework we currently use, I saw a lot of room for ergonomic improvement, coming from Discord.Net. Using proc_macros, I plan on achieving a similar level of power and simplicity as Discord.Net.Commands. I can resume work on it, and I'd like us to consider using it.

The name "browncoat" comes from Firefly lore, as "Serenity".

pietroalbini commented 5 years ago

What are all the ways the bot can be configured and when to use each?

From an operational point of view I'd use the database for as much stuff as possible and environment variables for things we can't store in the db. Using the database is much better as it doesn't require any infra involvement on changes. I'd also avoid configuration files as they're a bit of a pain with Docker.

What is the explicit scope of the bot? (Single vs multi community, should it integrate with other infrastructure ie CratesIO, what kinds of features should be acceptable to be PR'd into the bot)

I'd keep the bot just for ourselves and tightly integrate it with our specific workflows, and add whatever teams think they need to work. A few examples:

If the request is from a Rust team (and it makes sense) I'd just accept it.

How should a feature be structured, in terms of file structure as well as dependencies (conceptual and concrete)

I really like how rust-lang/triagebot (GitHub's @rustbot) is structured: there are a bunch of utilities available, but all the business logic is in self-contained handlers.

What are our needs for abstracted permissions? Ie Teams, generic tiers, etc.

I'm not expert on general Discord permissions, but team members authentication should go through rust-lang/team.

khionu commented 5 years ago

but team members authentication should go through rust-lang/team.

Can we add details to this, namely Discord IDs? We can track Discord-to-GitHub by doing a GitHub OAuth2 app, but if this is meant to be the source of truth, it would be more optimal to store it here. Could have people sync through the bot, and the bot would add their ID to that repo.

To note, though, I meant "permissions" in the more vague sense. General Discord permissions might be broken up more finely than defined in that repo.

For the crates.io team: "chatops" for the app

What is "chatops"?

I really like how rust-lang/triagebot (GitHub's @rustbot) is structured: there are a bunch of utilities available, but all the business logic is in self-contained handlers.

Seems nice, but some of those files get a bit long. My prompt was also meant to consider things like a Feature trait or some other code-specific standardization.

If the request is from a Rust team (and it makes sense) I'd just accept it.

Hoping to be a bit more specific than that. I think this would be a fine default if it were to go without writing down, though.

pietroalbini commented 5 years ago

Can we add details to this, namely Discord IDs? We can track Discord-to-GitHub by doing a GitHub OAuth2 app, but if this is meant to be the source of truth, it would be more optimal to store it here.

Yes, we can add new things to the schema.

What is "chatops"?

Basically operating a service/application through chat commands. For example a command to deploy a new commit to production, or to restart the servers. cc @sgrif

Seems nice, but some of those files get a bit long.

We can surely split things from an handler into nested modules.

My prompt was also meant to consider things like a Feature trait or some other code-specific standardization.

Sure, why not.

sgrif commented 5 years ago

I don't think it makes sense for crates.io's operations bot to integrate with a bot used by other teams. Given that our bot needs to be run in an environment with credentials to access our production server, keeping it isolated from other tasks seems prudent.

technetos commented 5 years ago

Currently we use function pointers to tie commands sent to the bot to the functions run. With respect to individual team usage we could define separate modules for each team and have the functions contained within the module (really the module can be structured however we want, just expose the functions to run at the base mod.rs). This is what we currently do for tags right now.

As for team specific commands, I am envisioning prefixing the command with the team it belongs to, something like ?infra literal {arg}. Note there is a tiny bit of ambiguity in the command parsing state machine: ?foo bar and ?foo {arg} are ambiguous since anything matches arg, including the bar literal.

khionu commented 5 years ago

Browncoat addresses this by resolving the command name and command group prior to interpreting the args. A command registered as ?foo bar {args} will always take precedence to ?foo {bar as arg}

Having team modules as separate services might be prudent. The bot could be turned strictly into a command interface which then invokes other services. Clearly, this kind of setup could get fairly intensive, design-wise, but it's the most optimal solution. There is no security issue with this setup than there is by using Discord as a means of verifying the user in any respect, which, to be perfectly clear, is what we enable by making any privileged actions available to a Discord bot.