If they want to take the filters we've created, awesome. They do still have to attribute, we're licensed under MIT/Apache, and any change to that requires unanimous agreement from all 36 code contributors.
@JanDvorak IIRC there was a userscript that alerted you when Smokey posted a message. Considering how I'm not the only person chatting here, you might find it useful if you find it.
But if they're just taking filters, they'll have to keep coming back and collaborating with us as we create more stuff, because we move faster than they do.
If they want more effective integration, that means communication between Smokey and SE systems, and that has to involve us - nobody on the SE team has code access.
I don't think they're likely to give us all double-weight spam flags, no. They might roll out a spam-flag-weight system based on number of helpful spam flags, but that would affect all users not just us.
The basing of trust on reputation (and mod status) has been a fairly rigid part of the entire site from the very outset - I don't think they'll break that paradigm for us
My outlook is this: the effectiveness of this entire system is built on the fact that anyone can participate, regardless of rep or diamonds. Anything that changes that will reduce how effective the system is. If SE are serious about getting the best out of integration, they'll realise that and work with it somehow.
If that means people here have more power than other people... yeah, it's not an easy thing to do and we'll have some PR and HR concerns to manage for a long time. But it'll get the most out of the thing we've made.
But a serious SE will put a CM on that case to say "hey, yeah, we know it's unprecedented, but we trust these guys and we're willing to give it a try - like it or lump it."
@CaffeineAddiction You are not a privileged user. Please see the privileges wiki page for information on what privileges are and what is expected of privileged users.
This is absolutely not about you; the work y'all have done on Smokey is incredible--nearly literally so--but over years, people's life situations change, and it would be... awkward, at best... to find ourselves in a spot where you current people have all moved on (next level of school, harder job, more kids) and no new reviewers have stepped in to take your place.
This is an odd situation that I don't have an answer for yet. On the one hand I agree with what someone said last week that there should be human eyes on this process; we're not advanced enough yet to let spam detection be 100% automated. On the other hand, I'm kinda hesitant to build any system that relies on any small group of humans to vet all posts.
We all know that 6-8 units is a very rough estimate for development with SE. They like to roll things out in waves too. What if the first wave is just getting the low hanging fruit?
But, their goal isn't complete elimination of spam because it's not realistic. It's reducing the perception of spam overwhelming the sites. We - this room - know there is a lot more being blocked before it's posted. Most other users don't know that. They see spam posts or worse the spam waves, and think SE can't stop it.
If they can reduce that perception, they have a quick win. Then the next phase is when they do the real development work - blocking the spam that's not easily detectable.
@ArtOfCode The tests run findspam/etc. If there's an invalid regex, Python will throw an exception. But if the regex doesn't match anything, it won't catch it.
Not every site gets as much spam as others, most spammers aren't spamming on the math site, while spam on drupal is more frequent, the special cases lists waits until there are at least X amount of posts for that site, before resolving them all in a single API call, some sites are placed in the time sensitive as spam is more common between certain times on the day
@Ferrybig @ArtOfCode from what I can tell SmokeDetector is making use of ChatExchange ... which does a webscrape of SE instead of using SE API 1.0 or 2.0 ... is this correct or am I missing something?
So intended to be re-consumed by other developers? You might want to make the API key a configurable thing in the finished product, then, if you haven't already thought of that, so that not every app that uses the wrapper is locked to your one key.
Hotmail/Microsoft/Canonical/Ubuntu/Yahoo/Google/Facebook etc support staff just don't hang around Stack Exchange to post their support phone numbers. 99.9% chance that's a scam.
@CaffeineAddiction rule of thumb, in my opinion: "If it says ABC support number" and a random toll free number or international number, don't trust it. Burn with fire
