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

Create tag groups #1545

Closed
mbaruh opened this issue Apr 20, 2021 · 12 comments · Fixed by #1663
Closed

Create tag groups #1545

mbaruh opened this issue Apr 20, 2021 · 12 comments · Fixed by #1663
Assignees
Labels
a: tags Related to bot tags l: 1 - intermediate p: 2 - normal Normal Priority t: enhancement Changes or improvements to existing features

Comments

@mbaruh
Copy link
Member

mbaruh commented Apr 20, 2021

It's been a concern lately of tags cluttering the bot's command namespace. To mitigate the issue, we can split certain tags into groups, and then having a lot of related tags under that group won't be an issue.

For example, !intents can become !dpy intents, and then we can add however many tags we want under dpy.

The tag group's md files can be stored in a common folder under resources.

@mbaruh mbaruh added a: tags Related to bot tags l: 1 - intermediate p: 2 - normal Normal Priority s: planning Discussing details t: enhancement Changes or improvements to existing features labels Apr 20, 2021
@Numerlor
Copy link
Contributor

The tag group's md files can be stored in a common folder under resources.

The current implementation uses folders for the (unused) role restricted tags, would we just ditch that as it's not currently in use by anything?

@mbaruh
Copy link
Member Author

mbaruh commented Apr 20, 2021

We could. I suppose we can also create a special _roles or a similarly named folder and to put restricted tags there, if we ever have any.

@wookie184
Copy link
Contributor

Thoughts on making it so some groups are tied to certain channels, e.g. so !intents run in the #discord-py channel would work as it would search in the dpy group. An issue with this is that it may be confusing for certain tags to work in some channels and not others though.

@mbaruh
Copy link
Member Author

mbaruh commented Apr 20, 2021

Yeah that sounds a bit unintuitive. Long time users learn to remember certain tags, and it would be harder if they were called differently in different channels

@Numerlor
Copy link
Contributor

We could. I suppose we can also create a special _roles or a similarly named folder and to put restricted tags there, if we ever have any.

With the metadata described in #1539 (comment) we can do role restrictions through an attribute there, as having multiple folders would be a bit difficult to navigate if a tag was both role and group restricted.

I can start working on this if that sounds good.

Are there any group you currently have in mind except the dpy one?

@mbaruh
Copy link
Member Author

mbaruh commented Apr 26, 2021

A point that was made is that it might be simpler to just use hyphens (e.g !dpy-intents), and then no code changes are needed.

The reason this issue was raised is that we've been wary of adding new tags too liberally (for example, recently there was a suggestion for more ToS related tags), fearing too much clutter, and this approach seemed like a solution.

That said, simply using hyphenated names is completely valid as well.

Opinions are welcome.

@Numerlor
Copy link
Contributor

There could be issues with fuzzy matching if we just use the prefixes so I think fully separating it with non fuzzy matched groups would be a bit easier in the code.
Using the group name to list all tags in that group would also be nice but apart from that I don't think there are UX differences between the two approaches.

@RohanJnr
Copy link
Member

It would also be nice if we could call the tag name without the group name,
example: Both !dpy intents and !intents are valid commands and the bot responds with the same embed.

@Numerlor
Copy link
Contributor

It would also be nice if we could call the tag name without the group name,
example: Both !dpy intents and !intents are valid commands and the bot responds with the same embed.

As I understand it the issue's main purpose is to avoid having all of the tags as direct commands to avoid cluttering and prevent accidental invocations. If both methods are allowed the only real thing it'd bring is the ability to list a certain group and the grouping in the source

@ChrisLovering
Copy link
Member

I like the idea of having tags separated into meaningful groups. I'd like to be able to do !tags to get a list of all tags, separated by group, along with !groupname to get a list of tags in that group.

@mbaruh
Copy link
Member Author

mbaruh commented Jun 22, 2021

We've decided to go through with the feature.

Some things to keep in mind for this:

  • Handling staff restricted commands in the new file structure. @Numerlor's suggestion seems like a good solution.
  • Discoverability. Tags under groups should remain as discoverable as possible. One approach is that when !tags is called, to list all groups and their tags, similarly to how extensions and their commands are currently listed under !help. Furthermore, !tags <group_name> can list only the tags under that specific group, like how !help <extension_name> lists only commands in that extension.
  • Fuzzy matching should be maintained. Meaning that regardless of whether someone makes a typo in the group name or the tag name, if it's small enough the right tag should come up.

@Numerlor if you're still interested I can assign you.

@mbaruh mbaruh removed the s: planning Discussing details label Jun 22, 2021
@Numerlor
Copy link
Contributor

We've decided to go through with the feature.
@Numerlor if you're still interested I can assign you.

sure, I can start working on it in a bit

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
a: tags Related to bot tags l: 1 - intermediate p: 2 - normal Normal Priority t: enhancement Changes or improvements to existing features
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants