> I'm really proud of the way that we empower our communities to handle abuse on their own; we give them the tools and just trust them to do it. -- Tim Post
Ubuntu development is in danger: they are running out of alphabet. Next version is Xenial Xerus.
Most posts have NULL in the CommentCount field
The CommentCount < 30 clause explicitly filters out rows where CommentCount is NULL. (This is because NULL represents the absence of data so logical operators involving NULL always return false.) Thankfully, SQL flavors offer ways to treat NULL as...
@Normal On occasion they have been. A while ago, a spammer on writers would delete their account after posting spam. I don't remember that occurring more recently though.
I've formalized, a bit, the spec sheet. It's late though and I want to sleep. I'm going to post it below so everyone can take a look at it before I go hacking at the Google Doc. Something that should still be cleaned up a bit - the implementation section. We should figure out what the "Musts", "Shoulds" and "Mays" are.
2
Motivation:
The primary time that spam is posted and visible to end users, is in the 4-12 UTC time range daily. Large population centers - Europe and North/South America - tend to be asleep during these time frames. Due to this decreased user activity, spam persists on the site for a much longer period of time than some users feel is acceptable.
<Insert links to Smokey's chat graph and Metasmoke's report by hour graph>
Background:
SmokeDetector is a headless chatbot that detects spam and reports it to various chatrooms around the Stack Exchange network. It utilizes a combination of the …
@Andy I really like this. Both "may"s can be dropped, I think. They don't seem to be important for initial deployment, and the fact that more features may be added later is sort of understood. I would add one more thing: the system will notify (in chat) of its intention to flag a post automatically. (So that trusted users may halt flagging before any damage occurs.)
The part about cycling through users looks less important than others; I'd delegate it to "should/may" part.
@Undo I'm always very nervous about any kind of coordination of spam or offensive flags, seeing how this has been abused in the past. The 100-rep penalty and potential blocking of any posts from that location are really severe actions, and if there's any chance of false positives I'd be afraid to allow this.
To make a case that this would be reliable, I'd like to see a dry run for a week where Smokey would generate a log of all the posts it would have triggered auto-flags on, but not act on any of them. We could manually review all of these posts and see if it got any of them wrong.
By the time a post comes through the web socket, gets through the regexes, and from Smokey to metasmoke, there's probably been a few seconds elapsed at least.
I would think we'd be safe assuming it's still there
Worst case, we put it in a queue to be retried later.
Post 1: That does not look like a valid post URL. Post 2: That does not look like a valid post URL. Post 3: That does not look like a valid post URL. Post 4: That does not look like a valid post URL.
Post 1: That does not look like a valid post URL. Post 2: That does not look like a valid post URL. Post 3: That does not look like a valid post URL. Post 4: That does not look like a valid post URL.
@Undo Basically, if a report from Smokey would have triggered automatic spam flags from people who had this enabled, I'd log the post URL to a file at that point. At the end of a week, we could look at the posts that would have been flagged as spam by this. If even one or two false-positives appeared in that list, I'd have concerns about it. That's what I'd like to see first.
That's great. Because then pre-running the posts caught by websockets data through bodyfetcher becomes a very reasonable thing to do. More data for metasmoke, fewer false positives.
Most posts have NULL in the CommentCount field
The CommentCount < 30 clause explicitly filters out rows where CommentCount is NULL. (This is because NULL represents the absence of data so logical operators involving NULL always return false.) Thankfully, SQL flavors offer ways to treat NULL as...
