send error message when telegram report is filtered #88

Open
opened 2019-06-10 09:49:47 +00:00 by b3yond · 4 comments

Author: @git-sid Posted at: 27.02.2019 14:34

Is your feature request related to a problem? Please describe.
The report filter to remove spam and unfitting reports isn't perfect.
When sending a legitimate report via telegram, the user can't directly see if their message got discarded because of the filter.

Describe the solution you'd like
Send a message when a report got filtered saying something like: "Your message wasn't recognized as a legitimate report. Therefore, we discarded it. Please try to rephrase your report."

Describe alternatives you've considered
Not warning the user. Our current approach.

Author: @git-sid Posted at: 27.02.2019 14:34 **Is your feature request related to a problem? Please describe.** The report filter to remove spam and unfitting reports isn't perfect. When sending a legitimate report via telegram, the user can't directly see if their message got discarded because of the filter. **Describe the solution you'd like** Send a message when a report got filtered saying something like: "Your message wasn't recognized as a legitimate report. Therefore, we discarded it. Please try to rephrase your report." **Describe alternatives you've considered** Not warning the user. Our current approach.
Poster
Owner

Author: @b3yond Posted at: 03.05.2019 14:15

technical argument against:

With our current architecture we are not checking inside the Telegrambot itself whether a report is_appropriate() - it is only happening in backend.py. That means that when we check for triggerpatterns and blocklist, we have already forgotten who we want to send the error message to, if it's not appropriate.

With the current architecture it's a nasty hack which could impact performance (although only slightly). With the #79 architecture rework it might be impossible, because I don't know how far we have to change the filter process because of the message queue.

Author: @b3yond Posted at: 03.05.2019 14:15 technical argument against: With our current architecture we are not checking inside the Telegrambot itself whether a report is_appropriate() - it is only happening in backend.py. That means that when we check for triggerpatterns and blocklist, we have already forgotten who we want to send the error message to, if it's not appropriate. With the current architecture it's a nasty hack which could impact performance (although only slightly). With the #79 architecture rework it might be impossible, because I don't know how far we have to change the filter process because of the message queue.
Poster
Owner

Author: @b3yond Posted at: 03.05.2019 14:22

usability argument against:

Yes, it can be confusing if you don't know whether your message was shared. But if we warn spammers that their message needs to be altered, they can trial & error way easier. How soon until some fascist realizes that while "hakenkreuz" is filtered, "haken kreuz" isn't?

Alternative:

Don't warn the user, warn the moderator. Let's log the filtered messages and display them in the settings view, then the city moderator can adjust their filters, so correct reports will be included in the future. Maybe with a button to spread a report nonetheless (although in most cases it will be outdated when a moderator looks at it).

This way we have less spam, and not necessarily frustrated users (I mean, they don't realize that their report wasn't spread, right?)

Author: @b3yond Posted at: 03.05.2019 14:22 usability argument against: Yes, it can be confusing if you don't know whether your message was shared. But if we warn spammers that their message needs to be altered, they can trial & error way easier. How soon until some fascist realizes that while "hakenkreuz" is filtered, "haken kreuz" isn't? **Alternative:** Don't warn the user, warn the moderator. Let's log the filtered messages and display them in the settings view, then the city moderator can adjust their filters, so correct reports will be included in the future. Maybe with a button to spread a report nonetheless (although in most cases it will be outdated when a moderator looks at it). This way we have less spam, and not necessarily frustrated users (I mean, they don't realize that their report wasn't spread, right?)
Poster
Owner

Author: @git-sid Posted at: 03.05.2019 20:02

they can trial & error way easier

They can already find out if their report got filtered. By being subscribed to reports and checking if the bot sent them their (spam) report back, spammers know if it worked.
So that shouldn't be an issue.

Author: @git-sid Posted at: 03.05.2019 20:02 > they can trial & error way easier They can already find out if their report got filtered. By being subscribed to reports and checking if the bot sent them their (spam) report back, spammers know if it worked. So that shouldn't be an issue.
Poster
Owner

Author: @b3yond Posted at: 04.05.2019 08:20

yeah, true... true.

still not convinced for the technical reasons. The alternative I proposed sounds more fun to me^^

Author: @b3yond Posted at: 04.05.2019 08:20 yeah, true... true. still not convinced for the technical reasons. The alternative I proposed sounds more fun to me^^
Sign in to join this conversation.
No Milestone
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: b3yond/ticketfrei#88
There is no content yet.