Skip to content
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

Make some commands ephemeral/hidden #184

Open
GoldenRedstone opened this issue Nov 22, 2023 · 2 comments
Open

Make some commands ephemeral/hidden #184

GoldenRedstone opened this issue Nov 22, 2023 · 2 comments
Labels
awaiting-discussion needs infra/committee discussion to progress

Comments

@GoldenRedstone
Copy link
Contributor

Some commands should be always visible, and some commands should always be hidden, however, we should give the user the option to make their command usage private or public, without having to move to DMs.
There is no harm in commands being nonephemeral, for the most part, but it would be good if you didn't have to announce to the entirety of UQCS when you're getting pizza.

Below are some thoughts on what commands should be always visible, visible with the option to hide it, or hidden with the option to show it.

Command Hidden
bgg Default visible
binify, caesar, hexify, morse Default hidden
cat Always visible
coin Default visible
conduct Default visible
courseecp Default hidden
cowsay, cowthink Always visible
dominoscoupons Default visible
events, allevents Default visible
hackathon Default visible
httpcat Always visible
hoogle Default hidden
latex Default visible
membercount Default hidden
mock Default visible
pastexams Default hidden
remindme Always hidden
repo Default visible
scare Default visible
scry Default visible
smoko Always visible
snailrace Always visible
syllables Default hidden
uptime Default visible
votey Always visible
whatsdue Default hidden
whatweekisit Default visible
xkcd Always visible
xsampa Default hidden
zalgo Always visible

Ephemeral commands can be implemented for commands that need to defer using
await interaction.response.defer(ephemeral=True).

@andrewj-brown
Copy link
Member

I'll ask what the rest of infra thinks about it, but it feels a bit like pointless effort when DMs exist - if you're interacting with the bot in the server, the default presumption should be that you're interacting publicly.

I'm not fantastically interested in us breaking that default, for any command, because (yeah yeah slippery slope fallacy whatever) I feel like we shouldn't even pretend we'll maintain that guarantee. For example, remindme isn't private, no matter whether you DM or not, because they go to the same DB and the debug commands will display your reminder no matter what. I don't think we should then enable people to mistakenly pretend it is private by hiding the message by default.

@andrewj-brown andrewj-brown added the awaiting-discussion needs infra/committee discussion to progress label Nov 27, 2023
@JamesDearlove
Copy link
Member

JamesDearlove commented Nov 27, 2023

imo, I think almost all bot commands should remain default visible as is and if you really don't want them public, to consider dm'ing the bot. Mostly as commands like hoogle courseecp and pastexams for example, can add to the existing conversation about what is going on.

As a public server I don't necessarily want to hide cool interactions with the bot, as it encourages discussions around improving the bot. We also embrace the chaos of "testing in prod" on occasion, and it's kinda funny when things break in a spectacular fashion.

My exception to the rule here are commands that are tied to you in some way. iirc currently only mcwhitelist, as you may not want to broadcast your Minecraft username to the entire server.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting-discussion needs infra/committee discussion to progress
Projects
None yet
Development

No branches or pull requests

3 participants