-
Notifications
You must be signed in to change notification settings - Fork 77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
/rules command with *most* rules as subcommands #448
Comments
I like this a lot. What I'm wondering is how we'd be able to keep these subcommands in sync with any changes made to the rules, should that ever happen. We have If it is the former, then getting message IDs shouldn't be a huge issue but I'm just wondering about the implementation when it comes to, say, adding new rules or if for whatever reason, the rules order changes or in some other way each rules' message IDs change. Did you already have ideas for how this could be handled? Same for the actual bot message that would be posted. Is your intention just to have the bot message include a link to the specified rule message in the rules channel? Or to actually include the contents of rule embed? I'm not 100% sure how that might work if the latter, since the rules embeds contents are handled by Dyno. Wondering what your thoughts are on implementation @JustWaveThings as well as @TheOdinProject/odin-bot |
I haven't looked too deeply into the implementation details now that there is movement to have one source of truth for the rules and be able to build the Discord rules/ TOP app from that source, I'm happy to wait for that to be complete so I can see how they implement the /updaterules command. However that command is structured, I feel like (HOPE?!?!) it would be most of the way there to be able to populate the bot commands. There might be unique challenges because I don't know if I'd want every rule as a subcommand. That might be a bit overwhelming/overkill. Ideally, I'd get a separate command working to populate the commands from the same source of truth as the /updaterules command. From there, I think I'd need/want input on how best to get the command/code into the staff workflow. Not sure if just asking staff to run two commands when the rules update, or if the command could be triggered by the /updaterules command. |
My two cents:
I think the second option is better, both from a coding POV (not having to deal with Message ID's etc), as well as from a user POV: If I'm getting tagged about a broken rule I'd much prefer getting the actual text of the rule, rather than having to click a link to see the rule.
My immediate thought would be to define which rules you want, and then when run parse out the text from that command. |
I'm not sure if we want to spam the whole text in the public channel. I don't think it's a heavy lift to click the link that takes one directly to the rule in # rules, which is an improvement now where we link the user to the whole channel for any rule break. Also by linking them to the specific rule, they might be more likely to read the other rules, where they probably would not if just the broken rule text was presented to them. My initial thoughts anyway. I want to avoid being spammy with rule embeds. People can get fatigued seeing them a lot and can come across as impersonal/hostile if overused. |
@JustWaveThings Ah, I hadn't caught up with the rules discussion. That sounds like a good move, e.g. if it's something like what we have with Then yeah, it'd probably be easier to think about implementation once the rules thing has been agreed on and even better so once actually implemented. And yeah, I'm not really liking the image of having the bot post the actual rule embed but just a link. Because right now, to link a direct rule you'd have to manually go to the rules channel, find the message then copy its link. Would be nice to just zip through a menu/type out without leaving the channel. |
Exactly my thoughts. Decrease staff effort, increase learner knowledge of rules in real-time in public, and promote more eyeballs on the rules that the team has put many many hours of thought and care into crafting. |
Ah, wait: I was thinking of the text/link as something that would only be shown to the user (which now that I say it: that's impossible, I think). Yeah, you're totally right. A link is better |
Yeah. Understandably, ephemeral responses can only be set for the person who executed the slash command i.e. the mod. So not really the most useful XD |
I mean we could make it create a private thread with the full text of the message in it and tag the user, but I think doing the link real-time in public will be the best bang for the buck. |
The link sounds both simpler but also more beneficial for anyone lurking so they can see it too. |
Complete the following REQUIRED checkboxes:
I have thoroughly read and understand The Odin Project Contributing Guide
The title of this issue follows the
command name: brief description of request
format, e.g./help: add optional @user parameter
The following checkbox is OPTIONAL:
1. Description of the Feature Request:
New bot command:
/rules with subcommand /user and then subcommands for each of the rule sections. This would be done for rules we commonly discuss in public channels and everyone would be able to see who initiated the bot. Bannable or otherwise serious rule-breaking should be excluded from this slash command, as that's not handled in public.
Story:
EXTRA:
2. Acceptance Criteria:
A list of checkbox items that explain the requirements needed to be met to resolve this request, e.g.:
3. Additional Information:
https://discord.com/channels/505093832157691914/991035592332673125/1158391257131929760 Yes, it was a dream.
The text was updated successfully, but these errors were encountered: