python-discord
Allow invoking rule command with keywords rather than rule number
maybe link some keywords to rules.. like the rule-6 is related to advertising, so maybe we can just type !rule ad.
I see how this could be helpful in the face of a particular infraction by a user. If someone is advertising, it wouldn't be very productive to have the command ask them to visit a link for the particular rule in question.
Even just adding the particular rule snippet based on the optional keyword would be a more impactful way to communicate the rule that is being violated in my opinion.
!rule ad
Rules The rules and guidelines that apply to this community can be found on our rules page. We expect all members of the community to have read and understood these.
Rule 6: Do not post unapproved advertising
Would it be best to have this implemented on a keyword basis? Meaning that we have a list of particular keywords that map to a particular rule? Or would it be better to use NLP here in order to try to identify the rule that a particular user is trying to mention, and then maybe give suggestions ?
Would it be best to have this implemented on a keyword basis? Meaning that we have a list of particular keywords that map to a particular rule? Or would it be better to use NLP here in order to try to identify the rule that a particular user is trying to mention, and then maybe give suggestions ?
I think having keywords would be best, it should be simpler, as well as being more predictable and giving us more control.
With that we would need some way of discovering the keywords that work for each rule. We could include it in each rule invocation, or have a separate command that lists them.
IMO regardless of what we do, we should keep the ability to reference based on numbers, on top of whatever we do here.
The rule command has existed for quite a while that a lot of staff and regulars are very used to be able to invoke based on an index.
In terms of implementation, this is trivial, as we would just need to leave the greedy int convertor, and add an optional string param.
@ChrisLovering I don't think the point was to change the fundamentals of how the command works. Listing a rule by its number would remain the same. What we're trying to do is to make it slightly easier for people who are unacquainted with the rule numbers to find them easily.
@wookie184 I definitely agree with you on that. Because we don't want it to get too clunky and get lost in finding keywords as well.
I'll try to spin up a draft PR for this and discuss implementation details there when needed.
One aspect that is lost here is that the current rules command is dynamic. The rules are fetched from the API. The suggested approach is probably ok, but will require hardcoding keywords, which will need to be changed/rearranged if the rules ever change. How much of an issue would it be to take a keyword and check whether it appears only in a particular rule? In terms of getting undesirable results
How much of an issue would it be to take a keyword and check whether it appears only in a particular rule? In terms of getting undesirable results
Not so much undesirable results, but it would stop us having stuff like !rule tos if the rule just contains "terms of service", or !rule advert if the rule contains "advertisment".
The rules are fetched from the API
It shouldn't be too difficult to add the keywords on the site side and make them be fetched along with the rules.
@wookie184 I was thinking of how this would be implemented and I'd appreciate an opinion since I'm still not quite acquainted with how we do things here:
-
Do we keep this as 1 command only or do we have a group of commands? The "main" one would be using the rule number like usual & the other with a keyword.
-
If we decide to have one command, I suppose that we need to prioritize numbers on keywords, this leads to having a signature like this:
async def rules(self, ctx: Context, rules: Greedy[int], keyword: Optional[str]) -> None--> If no number is provided, we will try to search for a keyword that might match the one provided -
You said that "we would need some way of discovering the keywords that work for each rule. We could include it in each rule invocation, or have a separate command that lists them." This would depend on how we would be mapping our keywords to the rules a. One keyword points to one rule --> Cluggy & messy. b. Each rule number keeps a collection (list, set) of keywords -> This would require a longer lookup time in case the list of keywords grows & our target keyword is the final one to search for.
-
Since I'm not familiar with our code base, what's the most suitable place (if there are guidelines for this) to store this map?
Do we keep this as 1 command only or do we have a group of commands?
It should remain as one command, here are examples of how I think it should work:
!rule -> Shows the general rule message as it did before.
!rule 1 -> Shows rule 1 as it did before
!rule 1 2 -> Shows rule 1 and 2 as it did before.
!rule coc -> Shows the rule with keyword "coc".
!rule 1 Look at this rule -> Only shows rule 1, i.e. ignore the text if a number was already given.
!rule a b c -> There are a bunch of ways this could be interpreted: A single rule with a multiple keyword invocation e.g. !rule code of conduct; multiple rules e.g. !rule tos coc advert; or one rule and ignored text, e.g. !rule coc Look at this. I don't mind which we go with.
I think you should be able to do this with the signature you posted above, depending on how the last case I showed is handled.
This would depend on how we would be mapping our keywords to the rules
I like option b in terms of how they're stored as it sounds a bit neater to keep the keywords with the rule's definition, how the lookup is done at runtime is up to you, there should be no issue with lookup speed whatever you do as there are only 9 rules.
what's the most suitable place (if there are guidelines for this) to store this map?
The rules are actually stored on the site project so the response there should be changed to include the keywords for each rule as well as the contents. This means you'll need 2 PRs, one to site and one to bot.
If you haven't found it already our contributing guide has information on how to set up the projects, feel free to ask on the server if you have any issues setting stuff up!
Awesome, that should be enough to get me started. Thanks a lot, we'll continue the discussion in the PRs.
@wookie184 Here are the two PRs https://github.com/python-discord/site/pull/770 https://github.com/python-discord/bot/pull/2261
I'd love to have some feedback !
@wookie184 I just remembered this and I was thinking about the discoverability of these keywords.
Should we include them in the the Embed's footer maybe ? Or attach them to each rule
Here's how it currently is
Here's how it could be attached
Let me know what you think