Split pending request channels into helper requests and mod requests

[SunCatMC]

The Problem

Currently requests that can be solved by helpers are lost in the request channel when there's a large volume of mod requests (like adding category)
Same the other way around, but it's not as critical here because mods aren't locked up from resolving helper requests

Possible Solution

Split the requests into 2 categories: helper and mod request. Possibly detecting mod requests automatically and sending them into different chats, and have a way to manually switch the chat by an additional reaction

[dericksonmark]

Hello!
To sort the requests, MojiraBot would probably need to know specific keywords to look out for. Here are the requests I usually see:

• Reopen request
• Ownership request
• Add version
• Category request
• Invalid
• Awaiting Response
• Cannot Reproduce
• Duplicate
• Relates to
• Label request
• Confirmation status
• Fix version
• Incomplete
• Remove attachment
• Remove comment
• Private

Now, to figure out which requests can be done, there needs to be some sort of priority system; if a request says, for example, "Fixed in 1.16.2", MojiraBot could be confused as to whether or not it is an affected versions request or a fix request. This list is not in order at all, but when fixing this issue, priority should be added to certain requests, like reopen requests, ownership requests, and fix versions as to not confuse the bot if multiple filtered keywords are used.

• If a request contains 'duplicate', 'duplicates', 'dupes', or 'dupe', it should go to the moderator channel
• If a request contains 'can't reproduce', 'cannot reproduce', 'can not reproduce', 'unable to reproduce', 'can't confirm', or 'CR', it should go to the moderator channel
• If a request contains 'relates' or 'related', it should go to the moderator channel
• If a request contains 'owner' or 'ownership', it should go to the moderator channel
• If a request contains 'category', 'categorize', or 'categorized', it should go to the moderator channel
• If a request contains the latest release or version number or 'affects', but does not contain 'fixed', 'fix', or 'not', it should go to the helper channel
• The opposite of the bullet point above (fix version requests) should go to the moderator channel
• If a request contains 'reopen' or 're-open', it should go to the moderator channel
• If a request contains 'remove', 'hide', or 'delete', it should go to the moderator channel
• If a request contains 'title', or 'description', it should automatically go to the helper channel
• If a request contains 'invalid', 'TS', 'support', 'account', 'purchase', 'payment', 'purchasing', 'optifine', 'spigot', 'bukkit', 'paper', 'bungeecord', 'forge', 'pirate', 'pirated', 'technical', 'billing', 'combat snapshot', 'combat test', 'combat testing', 'feature request', 'system requirements', 'computer requirements', 'graphics requirements', 'gpu requirements', 'system requirement', 'computer requirement', 'graphics requirement', 'gpu requirement', 'cpu requirements', 'cpu requirement', 'multiple bugs', 'multiple issues', 'outdated', 'translation', 'translations', 'crowdin', 'wrong project', 'incorrect project', 'english', 'hypixel', or 'modified', it should go to the moderator channel
• If a request contains 'awaiting' or 'AR', it should go to the moderator channel
• If a request contains 'confirm', 'confirmation', 'community', 'cc', 'consensus', or 'confirmed', it should go to the helper channel
• If a request contains 'label', it should go to the helper channel
• If a request contains 'incomplete', it should go to the moderator channel
• If a request contains 'private', it should go to the moderator channel
• If a request contains 'gamemode', 'game mode', or 'gm', it should go to the helper channel
• If a request contains 'environment' or 'enviroment' (that's a common misspelling!), it should go to the helper channel

Capitalization and punctuation should be ignored.

Everything that misses any of these filters could go to the moderator channel. Some of these filters are not necessary if they do not affect any of the other filters and should be sent to the moderator channel anyway.

Anything that is reacted to, like you said, to switch the channel, could be added to a text file that stores all of these wrong channel requests. If there are any keywords that users start using in their requests that are missed by the filters, someone could take a look at the text file and modify the code.

I'm sorry for making so many category requests.

Congrats on creating mojira/mojira-discord-bot issue #100! 🎉

[SunCatMC]

add "forge" to modified ones

[dericksonmark]

Updated. Thanks!

Changes:

• Added 'Cannot reproduce' message
• Addes 'spigot', 'bukkit', 'paper', 'forge', and 'pirate' to filter for Invalid

[SunCatMC]

why "relative"?

[SunCatMC]

and add "hide" and "delete" to comments

[dericksonmark]

Updated!
Changes:

• Removed 'relative' from "Relates to" filter
• Added 'hide' and 'delete' to "Remove" filter

[chandler05]

I am concerned that some users will still use confusing terms, or include multiple different requests in one request (like having an affected version and ownership request in one) Explanations for reopens might also accidentally include WAI keywords as well.

• You have forgotten ownership requests!
• Add "Unable to reproduce" to cannot reproduce
• Helpers cannot delete comments or remove attachments, so those need to be removed from that bullet point
• "Account", "Purchase", "Purchasing", "Payment" and similar should be added to the invalid section
• Adding game modes or removing environment should be assigned to helpers

[chandler05]

Plus, misspelling might be an issue too

[dericksonmark]

Oh, no! The reason I decided to write that comment was for which terms should be used for ownership requests, and I must've been so distracted trying to think of everything else that should be filtered out that I completely forgot. Oops. :(

To solve your issue about multiple requests, the filters should probably be set up using 'else if' statements so that a system of priority could be set up (if a keyword is higher in priority, then no more filters will be activated and the request would be sent to that channel; also, it doesn't have to be else if, that's just the only thing I know how to use to solve the issue).

Looking at my priority system again, I do think that it is not in the most logical order. Keywords for the moderator channel should probably be higher priority, as well as, like you said, reopen requests. Reopen requests should probably be first in priority followed by ownership requests; both of these request types could include other keywords.

I will change everything you said to change.

If a word is spelled incorrectly and no filter picks up a keyword, then the request would be sent to the moderator channel. If a moderator would not like to solve the request (because a helper can), or the other way around, they could react to the message with something like 🔁 , and then the request would be transferred to the opposite channel.

I hope that makes sense. :)

There are so many things that can make a report invalid:

'invalid', 'TS', 'support', 'account', 'purchase', 'payment', 'purchasing', 'optifine', 'spigot', 'bukkit', 'paper', 'bungeecord', 'forge', 'pirate', 'pirated', 'technical', 'billing', 'combat snapshot', 'combat test', 'combat testing', 'feature request', 'system requirements', 'computer requirements', 'graphics requirements', 'gpu requirements', 'system requirement', 'computer requirement', 'graphics requirement', 'gpu requirement', 'cpu requirements', 'cpu requirement', 'multiple bugs', 'multiple issues', 'outdated', 'translation', 'translations', 'crowdin', 'wrong project', 'incorrect project', 'english', or 'modified'

not all of these would have to be filtered for; that would probably be a lot of code.

[NeunEinser]

or include multiple different requests in one request (like having an affected version and ownership request in one)

That shouldn't be a problem as it then will contain a keyword that makes it a mod request.

[SunCatMC]

not all of these would have to be filtered for; that would probably be a lot of code.

it's just the same code over and over. some can even be combined like transtation[s] or multiple <bugs|issues> (not the code, just the explanation format)
On the other hand having too many counditions could be slow, but i don't know how many conditions are required for noticable slowdown