[ SmokeDetector | MS ] Bad keyword in body, bad keyword in title, blacklisted website in body, link at end of body, link following arrow in body, +2 more: Get a Bottle of Luna Trim Now by Whome 19 on workplace.SE
[ SmokeDetector ] SmokeDetector started at [rev 58ccf7f (SmokeDetector: Auto watch of you['re]{0,3}\Wstupid by K.Dᴀᴠɪs --autopull)](//github.com/Charcoal-SE/SmokeDetector/commit/58ccf7f) (running on teward/Solar Flare)
[ SmokeDetector | MS ] Bad keyword in body, bad keyword in title, blacklisted website in body, link at end of body, link following arrow in body, +2 more: In another Luna Trim research by Inght 19 on superuser.com
@Undo An alternate solution is to require a minimum of 3 reasons, rather than a particular weight. The difference is 3 reasons results in 44 FP for 99.90% and 200 weight gives 34 FP for 99.92%. Something that might be easier is to increase the required % to 99.9% from 99.75%. However, I'd note that a lot of the FP are on Stack Overflow where those conditions result in 99.54% (3 reasons) and 99.71% (200 weight).
@Undo I agree with that. It's the site where I'd choose for any FP which I might get. OTOH, there's clearly enough data just for SO to be able to determine that the conditions which we're permitting when someone applies them across multiple/all sites don't actually meet those requirements when applied to SO in isolation.
Perhaps what we should do is require that any conditions which are applied across multiple sites also maintain that requirement when they are applied to each individual site within that set where there are > N data points for that that site (e.g. N could be something like 1k, 2k, 5k, 10k?).
This would cover one of the gaming issues that has been mentioned: combining with some sites specifically to be able to lower thresholds on other sites. It would also, to some extent, compensate for issue that weights are calculated across the entire corpus, when they could be significantly different on various sites due to dramatic differences in content.
@Makyen A side effect would be that "watch" begins to affect autoflagging, which it wasn't supposed to. For example, "Potentially bad keyword in title" + "Potentially bad keyword in body" + "Link at the end of body".
Setting the weight requirement to 200 also forces 3 reasons, but they can't be 0-score reasons.
Apart from 0-score though, any three good reasons will combine to 200+.
@SFTP There's really no "begins". The capability to set 1/X/3 currently exists and is being used (doing so has been mentioned in here a few/several times). I don't have an issue with making the requirement be weight > 200. However, I'd much rather see implemented the more complex issue of having conditions be required to fit both the group of sites and individually all sites within the group which have enough data to be statistically relevant.
Basically, weight > 200 isn't enough to get SO to be > 99.75%, which is the current requirement. However, by combining SO with other sites, you could still apply that condition rule to SO. That this sort of thing is possible with other conditions and other sites has been mentioned in here as a method people are using with the expressed intent to increase the number of autoflags they raise.
@WELZ if you want to control reason count there's a field for that, weight is not the right tool
Put it this way: I was at 280/1/1 for a long time, never had an FP. I moved down to 250 and then 230, still never had an FP. I switched it to 1/1/3 and I got an FP in the first week.
@ArtOfDuck I was told to ping you (or actually to ping some random person named ArtOfCode. Who's that?) by the FAQ to get the reviewer privilege. Can I have it? Plz send teh reviewz.
> I'm a little teapot, Short and stout. Here is my handle; [nod at arm shaped into a "handle"] Here is my... [look at "spout", which is another handle] ... O crap, I'm a sugar bowl.
If we can, it would be a good idea to assign a lower priority to searches done via the MS web interface than other activity. Doing a search is really not something which should cause disruption in people's use of FIRE, AIM, etc.
@JohnDvorak Well, I was going to report that this was a possible DOS route via a method that didn't show it in chat or GitHub, but now that you mention it: Yes, it's an issue.
