`!subscribe` adjustments to allow for sub-roles

[janine9vn]

What feature are you proposing?

I would like to re-think how our current !subscribe interaction works to allow for more sub-roles that we can ping for announcements.

There are a couple of options here which is why I'd like the input for the larger community:

Option A - !subscribe subcommands. !subscribe would still keep the current behavior. !subscribe pyweek would add the appropriate PyWeek role. We can continue adding in sub-roles as sub-commands as we need them.

Option B - Components We change !subscribe to use discord components. Each role would have a button that people can toggle to opt in and out of. This changes the current interaction required from users but would be much nicer in terms of opting in and out of multiple roles. Plus, who doesn't love buttons?

Option C - Slash Commands This is likely not to happen, but I figured I'd put on the table for completeness. We add in slash commands so people can pick from a list of what they want to be notified for. Pros: It's really nice interface for this kind of thing. Cons: We'd have to find a library to incorporate and add another major dependency.

What is your justification for the proposed feature?

I would like to add a @PyWeek Participant or @PyWeek Announcements role that people can opt-in for to receive announcements specifically for PyWeek. Pinging the @Announcements does not make sense for all PyWeek announcements as part of the information is only relevant to people who are actively participating in PyWeek and, during the judging phase, have submitted an entry.

[Akarys42]

I like option B. How would you like to select which roles are available to that command and which aren't? Always use the same PyWeek role and store it as a constant?

[HassanAbouelela]

I like both B and C, though I'd like a possible demo because I'm not familiar with components yet.

I'm of the opinion though that we don't use the python bot for this, at least not until we figure out our framework situation. I'm fine with a second bot for it.

[ChrisLovering]

I like option B too, I think we just store a list of roleIDs that are self assignable, and have the command render those to names and then put them in the button.

It's fairly simple with d.py to have the current state show in the buttons and have them change on click after assigning the role

[Akarys42]

I'm of the opinion though that we don't use the python bot for this, at least not until we figure out our framework situation. I'm fine with a second bot for it.

Again another bot? I don't really see the use for this, besides Python is soon:tm: getting its 2.0a0 upgrade. It isn't like we are gonna switch frameworks overnight.

[HassanAbouelela]

For things that are already in d.py v2, that's fine, I'm just thinking if we need to add another framework for it, let's get another bot.

[bsoyka]

Option B seems like it'd be the simplest in terms of user experience, and it would also work fairly well in terms of "backwards compatibility" with anything saying to use !subscribe.

This also relates to the idea of using another bot, since a new bot would likely require another prefix and cause some confusion from old instructions. It's probably easier to actually switch to v2.0 than to make a new bot entirely and likely end up combining them again later on.

[dawnofmidnight]

I like the idea of Option B, it seems like the simplest and most obvious experience for users.

I don't think we really need another bot if we're already upgrading to d.py v2.0, building it into Python should work perfectly fine.

[jb3]

We decided that we will pursue option B in tonights staff meeting.

Once we've migrated to Discord.py 2.0 in python-discord/bot#1815 we'll be able to implement this feature, so we can open issues now pending that migration.