@Mast the MS regex support is fairly limited; we are lucky that we can even get partial parity with Smokey now - that wasn't always the case (the old MySQL we had for a long time only supported roughly basic POSIX regex)
if that was the sole criterion Stack Overflow should get 10x or 100x that but I guess we have to factor in the effectiveness of moderators and the community
@Mast Matched by /(?<=\.\w{1,5}/)(?!(?:\w+-keto|keto-\w+\b)(?:["/< ]|$))(?:[^<?&\/ "]+\/)*(?:[\w-]+-keto[\w-]*|keto-[\w-]+)[^<?& "]*(?=["/< ]|$)(?#expanded product name like keto-xx in URL path)(?#Was watched on 1561929557: 2019-06-30T14:19:17Z) on line 2388 of bad_keywords.txt
@Mast That pattern looks like it's already caught by Potentially bad keyword in body and Potentially bad keyword in answer; append -force if you really want to do that.
@Mast it seems that some of the pharma domains only target a small number of sites, like some of them are SU only and some are Workplace + AU or whatever; so it could just be a coincidence that many of them happened to be something + AU
@Mast We shouldn't be rate-limited like that, Smokey has a doubled quota (20k requests per day instead of 10k) and uses about half of it; Metasmoke is probably separate, and autoflagging only requires two(?) API calls per flag and I don't believe we flag that much.
On New Years we have NY competitions on ruSO. They are technically offtopic 'cause they are way too broad to be ontopic but they are fun and it is our tradition.
suggesting to do that across all SE sites would require a lot more work/planning/discussion/etc. on MSE and coordination of all the mods, and chances are MOST would say "no be quiet keep your site specific traditions to your specific sites"
and probably Charcoal is not the best place to get the opinions you're seeking
@CodyGray Unfortunately coffee is a tribute necessary to keep The Beasts of Chaos in check. Even more unfortunate: I'm one of those Beasts, so the coffee is supposed to be brought for me :P
@tripleee regarding github.com/Charcoal-SE/SmokeDetector/pull/5125 is there a reason you're doing "New commands" and "blacklist refactoring" as the same set of things? I'd rather see them as separate PRs
because they need to be independently addressed
and not done in an all or nothing PR
and I've asked @Makyen to comment on that approach as well :P
@ThomasWard the simple rationale is that the refactoring makes sense only for the new functionality; I can certainly create two separate PRs if that can help expedite the overall goal, but I can see how this could easily devolve into "why refactor this code when it seems to be working fine"
@tripleee well if you split the 'new commands' into its own PR I'll happily take a look at the new commands
(expect me to critique things though because new dependencies and such are a pain)
and leave the blacklist refactor for someone else to review
the fact of my concern here is:
you've basically got two separate review things that need done on a combo PR - the review of the sanity of the blacklist cleanups, and the review of new commands
of which i only will review the commands
and of which others may only review the blacklist cleanups
so it's really two separate requests not one massive intermingled one with two separate goals
that's kinda been the way things've been for an eternity with SD and such - PRs should address speicfic things and not two separate disparately-reviewable things
my 2 cents.
as it stands I don't think anyone's going to put the time to review both the blacklist refactor AND the new commands because it requires different sets of glasses/hats/eyes for each task :P
hence my latest request to split the two :)
but yeah if you split the "new commands" out of that PR into its own I'll happily take a look at those
i'm just... not sifting through a billion commits for just the new commands vs. the refactors ;)
Hey @Spevacus, I noticed yesterday while flicking through the suggested edits stats that you approved a suggested edit submitted on what was clearly a spam seed.
Not accusing you or anything, but... why? Spam is meant to be deleted, not edited.
@Ollie That pattern looks like it's already caught by Potentially bad keyword in answer and Potentially bad keyword in body; append -force if you really want to do that.