@PrincessLuna Some people use specifically selected combinations of sites so the condition results in an accuracy less than the limit on some specific site, but the condition is not automatically rejected, because the accuracy across the multiple sites selected is above the limit. So, the official answer is no, but the effective answer is yes. However, there is a manually checked limit that the combination of the user's enabled conditions must meet that limit for total accuracy (but not by site).
@CalvT븃 Perhaps I failed to describe it reasonably. It's been discussed multiple times, both from the point of view of how to set conditions to do it and what we should do to prevent it (a bit longer discussion) (there are multiple other discussions). It's relatively easy to demonstrate that it's one of the things that happens.
@Makyen Yeah, I was present for the second one. However, it's mainly on the big sites that you can do it, as most small sites knock it out of balance. (They don't bring enough tps for the amount of fps they bring).
I don't see the way the minimum weight check is calculated being a problem.
However, I do think we should have some kind of minimum on the minimum weight, especially now that we are pinning more reasons at one for testing
Thankfully, at the moment you really have to be a charcoal regular to understand the ins and outs of MS, and so pallet of bricks still applies.
@CalvT븃 That's counter to your prior statement that you don't see a problem. Or is it that you see an overall problem, but not a problem about how acceptable weight is calculated for a condition?
@Makyen basically, I think the way the percentage is calculated for conditions at the moment (the way it calculates it globally, instead of per site) is fine. However, I think we should have a minimum on the minimum weight - IE: it should not go below 160.
When it comes to reasons, I like SFTP's idea of grouping similar conditions and taking the max weight
@CalvT븃 IMO, if there is a problem, or not, depends largely on if we care about the perception of outsiders as to our overall rate of FP on autoflagged posts. If we don't care about that, then let the users apply whatever conditions they desire. If we do care about that, then have restrictions which make it so that, as best we can determine, the conditions will meet a certain accuracy criteria in all the situations in which they are applied.
This means that we should check the accuracy of the condition on a per site basis, when the site has enough data to permit such a check. The reality is that content varies by site. Thus, the effective accuracy varies by site.
The current autoflagging system was working fine, until we started playing around with the conditions. If there was a minimum for the minimum weight, then almost all these new conditions wouldn't be valid
BTW: I also agree that we should only count weight from the highest of very closely related reasons. However, I disagree with the details that have been previously described as to what's related (e.g. detecting the same thing in a title as is in the body are separate; but detecting the same thing in the body twice is the same).
@CalvT븃 But minimum weight isn't what's been defined as the criteria. The criteria has been defined as accuracy. Your basically arguing that you want to use a pre-defined weight to stand in for accuracy, when the issue is that the accuracy isn't being applied in known situations.
@Makyen Well the accuracy metric is being abused - that's what the problem is. And undo has a very valid point about smaller sites - that often they would never reach the threshold. The only way to make them reach it now is to include them in a global condition.
What I'm saying just to make is clear is all conditions would have to have an accuracy of over 99.75% and a minimum weight of 160 (both, not one or the other).
@CalvT븃 Yes, smaller sites must be grouped with larger sites, because there isn't enough data for them. This also allows abuse by selecting the larger site to be one where there happens to be a very low FP rate. A, probably, more appropriate solution for smaller sites, which don't individually have enough data, would be to require that conditions for those sites meet the accuracy requirement across the data for all sites, not just the sites they are grouped with.
Basically, accuracy of specified conditions varies based on the content against which the detection reasons are run. Our smallest separation of content types is by site, based on the site's TP/FP rate. If we have the finer grained information about how well the detection reasons work, which is what enough data for a particular site gives us, then we should use it, for that site.
If we don't have enough data, then we should not assume that the site under consideration matches the content type that happens to be in the site the user has chosen to group with it. We should assume that we need to apply the general overall data.
@ArtOfCode Yup. I have it too. But a post with "potentially bad keyword in title, potentially bad keyword in body, toxic body" would be flagged by that, and it easily could be an fp
@ArtOfCode That would be good yeah. But to me it'd be easier to put a minimum on the weight and be done with it. The minimum is based on a percentage of the default condition or something
@Mithrandir Your Alqualondë SD instance appears to be rising out of standby without the currently active instance dying. This is (at least) the second time it was directed to be in standby.
@CalvT븃 I'm fine with that happening. If someone's doing that and then comes crying to us that they got declined flags because they did dumb things with their conditions, it's their own stupid fault.
(that's also what the new manual validation thing is designed to stop - that particular combination may or may not be under 99.75%, but a lot of the tricks like that are)
@ArtOfCode Fine. My concern is more someone getting a load of fp autoflags on somewhere that isn't that friendly to Smokey, in turn annoying the community there
PS: Perspective has a weight of 0 - maybe the potentially reasons could as well? Instead of 1
@ArtOfCode The only thing that concerns me is that those conditions reflect on our overall statistics -- most of our autoflagging FPs have fairly low weights
@NobodyNada Yup, but that's what the broad-level accuracy minimum is for - we set that and use the manual tool to keep those FPs to a level we can accept.
@SmokeDetector While the question does request Android applications, the link provided is to somewhere that is not the Google play store, but which appears to be attempting to mimic the Google Play Store. Doing so is largely only done for spam and/or malicious applications. Thus, I consider this post to be spam/rude/abusive, depending on how one wants to look at it. Basically, it's something from which users should be protected.
@gparyani Much harder to implement because it involves MS interaction and new functionality written for that interface. And I don't even pretend to fully understand how the Metasmoke stuff really works
@quartata because that was only written as a basic wrapper around Windows git so that those using Windows environments could still run tests
and have very basic Smokey functions minus git
there's far better Git wrappers out there, that one was written out of being annoyed as heck about the complaints about Git not working and breaking Smokey for windows tests
so if you can rebuild it to be async and work properly, good, I'll be happy to test
but i'm not familiar with the asyncio.subprocess stuff
yet
so
@quartata i'll look into it if you add an issue for "Make _Git_Windows async." but note it'll need to be rewritten to have a different name if we open it crossplatform.
Currently, if a question or answer accumulates a sufficient number of offensive or spam flags against it, it is automatically deleted and a reputation penalty is imposed on the poster. Likewise, comments that have a sufficient number of flags against them are auto-deleted. This requires no modera...
@NicHartley At least in the past it's been explicitly stated that they don't (IIRC, don't have the ability to list such; see it if go to post, but not a list). It's one of the arguments that's been used against automatic 6-flags.
Features standing in the way of 6-flagging: (1) no retraction of flags via the API; (2) retraction impossible after 6-flag nuke anyway; (3) no list of deleted posts for mod verification.
Just imagine how would it be if "oops" button retracted all 6 flags and the post returned to original state...
@NicHartley AFAIK there's not convenient way to find them. We can look at a list of all deleted+downvoted posts, but that'll include many non-flag-deleted.
Yep. I'm a mod on a very small beta, so it's easy enough for me to do, but it isn't even easy to find the 1 or 2 spam posts we've had.
On SO it must be nearly impossible.
That's half of the reason why I built a list into the site dash (example for SO)
