For sure we should watch it. I'm wondering if we should maybe even TP those posts. At least 2 users who exclusively post answers about the same product, and are not consistent about disclosing, seems wrong.
[ SmokeDetector | MS ] Bad ip for hostname in body, bad pattern in url body, blacklisted website in body, body starts with title and ends in url, link at beginning of body, +5 more (722): DentaFend Reviews by marylinhoosier on astronomy.SE
And then the joke is on you, because it turns out to be a completely irrelevant message that just happened to be posted immediately after the SD report.
@RyanM That's very cool. Thanks. I don't see a room for islam.se. I was thinking about that one when you mentioned that "toxic answer" was accurate. For islam.se posts that's the reason on a lot of FP.
@cigien yes, we want to have some confidence that in the enthusiasm innocent posts doesn't get reported or tpu-ed. We've had problems with that before leading to mods having to revert spam flags and such. Your participation here gave us that evidence. As for why it took so long: it is within 6 to 8 weeks, right?
the rules have weights and those weights are not directly affected by the feedback, though over time the weight is adjusted based on the rule's TP/FP ratio
so theoretically if a post is reported twice, the TPUs on the first report could affect the weights when it is reported the second time
more directly, sometimes if something got a low score and e.g. the domain name was blacklisted once we took a look at it, we might force a second !!/scan just to get autoflags on the post when clearly it deserved them, though I guess this too is a dubious practice
@RyanM if you mechanically apply the 5/5 from metasmoke then that could happen by accident anyway ... I guess in this case depends on how old the FP is and how likely we think it is that that post will be reported again
Could someone let me know if my understanding of SD's handling of black/watchlists is correct? From what I understand, they're stored in the GH repo, and updates get populated into an instance via git pull (either because of an !!/pull or -autopull in the commit msg) and restart. However, if the change happens via a command, the instance won't fully restart and will instead just reload that particular list. Is that correct?
Ok, cool. If I wanted to pick up helios again, would there be any opposition to that idea? (my understanding of helios is that it would be a repository of black/watchlists that wouldn't require git to manage, and so would allow us to build interfaces around black/watchlist management into MS).
