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

Send automatic R/A flags based on reasons? #539

Closed
iBug opened this issue Dec 18, 2018 · 9 comments
Closed

Send automatic R/A flags based on reasons? #539

iBug opened this issue Dec 18, 2018 · 9 comments

Comments

@iBug
Copy link
Member

iBug commented Dec 18, 2018

R/A flags will now disqualify posts from being picked as audits, so correctly flagging R/A has some value now.

So far MS only casts spam flags. Based on what we have, some posts are better flagged as R/A instead. A simple logic could be like this

def should_flag_ra
  @reasons.map do |r|
    ['offensive', 'toxic', 'unique', 'repeating'].map do |s|
      r.include? s
    end.any?
  end.any?
end
@Undo1
Copy link
Member

Undo1 commented Dec 18, 2018

I'm gonna start this debate with "no". I'm not thrilled about the idea of spending any dev cycles on this, especially knowing that it'll trigger more cycles with moderators declining R/A flags on spam.

I think I'd rather take the hit on a "automated flags are always spam" policy, rather than open the door to moderators nitpicking around our conditions and us needing to respond. This would be a great reason to implement manual R/A flagging, but we already have that. Might be excellent to have userscripts implement this kind of intelligent check for a "just flag this" button.

I'd be happy with a Charcoal policy of "use R/A manually when appropriate". If moderators start declining spam flags on R/A, say "it's fewer clicks for you to flag as R/A yourself than to decline flags".

Anyway, up for debate.

@thesecretmaster
Copy link
Member

thesecretmaster commented Dec 18, 2018

I think we should do our best to flag as what things are supposed to be. The point of the policy change was to keep R/A out of audits, by flagging as spam we're hurting that goal. Also, I believe our past policy has been that spam and R/A are equal, we just use spam because most of the stuff we flag is spam. Sure, we may flag some spam as R/A, but a) based on past policy, they're the same and b) it'll certainly be more accurate than flagging everything as spam.

I also think we shouldn't try and dodge talking to mods -- the more people who are aware of what we do and how we do it the better.

@AWegnerGitHub
Copy link
Member

Based on what we have, some posts are better flagged as R/A instead.

Data please.


I agree with @Undo1 . I don't like the idea of automating this yet, at all. Unless there is a lot more data than I think, I don't believe we have enough to reliably classify rude/abusive posts.

@iBug
Copy link
Member Author

iBug commented Dec 18, 2018

@AWegnerGitHub Not much data needed. We have both spam (unwanted promotional content) and abusive (rudeness, garbage etc.). This is particularly about rude posts, since people don't want to see NSFW content when reviewing (audits). Given that R/A flags have their values now, IMO it's better that we send the right flags to the right posts.

@AWegnerGitHub
Copy link
Member

AWegnerGitHub commented Dec 18, 2018

Not much data needed.

I disagree. If we are sending automatic flags, we need data. @iBug

I understand the reason we want to send the correct flag. I want to see the data we have right now that can define a rude/abusive post from a spam post from an NAA post. Until I see that, I'm not going to be comfortable doing anything automatic that casts new flag types.

Sure, we may flag some spam as R/A, but a) based on past policy, they're the same and b) it'll certainly be more accurate than flagging everything as spam.

I also disagree with this sentiment. If we are going to split how we flag things automatically, we need to do it correctly. Spam should not be rude/abusive and rude/abusive should not be spam. @thesecretmaster

@ArtOfCode-
Copy link
Member

I suspect we do have enough data to be able to classify this correctly - doing it based on reasons should be accurate enough for our purposes, given that some reasons do catch a majority of R/A not spam. That said, I have to agree with Undo - doing this opens the door to every user and their dog saying "but why isn't this reason using R/A flags" or "this combination of reasons"... and it all starts getting complicated. Simple systems are easier to maintain.

While @thesecretmaster is right that we shouldn't shy away from communicating, both with mods and with wider communities, we also don't need to open up our systems for anyone to demand a change because that's what's right in their opinion.

@ArtOfCode- ArtOfCode- pinned this issue Dec 18, 2018
@magisch
Copy link
Member

magisch commented Dec 18, 2018

to echo @Undo1 and @ArtOfCode- 's sentiment, I don't think the added dev time for this would result in a lot of added value.

Charcoal is already complex enough and already sort of struggles with site moderators getting comfortable with it, another layer of potential disagreement for little gain doesn't seem worth it.

@GolfingSuccess
Copy link

Tip: Mods can mark a spam flag as helpful without deleting the post, and then use R/A instead.

Given the tip above, I'm slightly leaning towards @Undo1's opinion. And what others have already said. The only con I can think of is mods deleting the post with the spam flag right away (habits).

@iBug
Copy link
Member Author

iBug commented Dec 22, 2018

Consensus: No we don't. It's complex enough and we better stay with spam flags.

@iBug iBug closed this as completed Dec 22, 2018
@ArtOfCode- ArtOfCode- unpinned this issue Dec 26, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

7 participants