> Be conservative in what you do, be liberal in what you accept from others
5
Fighting unfriendliness with unfriendliness rarely ends well; it just causes the other party to get defensive, and that only escalates the unfriendliness further. The primary goal should always be to deescalate the conflict, to turn it into a constructive conversation where both parties are on the same side working towards a common goal. If there's not a way to do that, then it's pretty much always best to simply end the conversation
9
user435118
12:06 AM
@NobodyNada Hence, I don't talk to a few people here.
@Spevacus I like everybody here, and I also like R-HUB remote support servers, which are absolutely the best way to remotely access your Mac by installing a $400 on-premise server in your home.
@NobodyNada that being said, I have yet to encounter a Charcoal regular who doesn't have positive intentions towards the project & team. Some people are easier to get along with than others (especially when those others are tired or frustrated), but in the end we are all on the same team working towards the same goals
Also @Daniil I've yet to try running SD myself, but thanks for finding points in the setup docs that could be improved, that's super helpful for someone considering trying it.
BTW has any thought been given to this comment "perhaps a slight improvement to "wiping out" the backlog is simply allowing 1 review to suffice instead of 2 for posts which meet X criteria (older than 30 days and not deleted, for fp, older than 30 days and deleted for tp, etc.)"
If not, what would be the best way to bring up such a proposal. Teams post?
@Rubiksmoose I think this could be pretty helpful in getting the review queue down and I really suspect [based on hope and intuition] that it wouldn't seriously impact accuracy in any tangible way.
@Rubiksmoose I've given it some thought. The concern I have is that our "two reviewers per post" requirement is a way to ensure transparency and accountability -- that we're not nuking stuff that shouldn't be nuked. We could consider deprioritizing old posts with one feedback, but I'm not sure I like the idea of dumping anything from the queue
I think some work on reducing fp could net some improvements here. A few examples: 1) We could establish standards for how accurate a watch should be, and then automatically flag watches that are less accurate than that. 2) We could stop reporting posts that have already been reviewed and determined to be fp, or re-report the existing report if nothing about it has changed but it needs review.
@NobodyNada Fair enough. It's just that we are putting a lot of effort towards posts that (and correct me if I'm wrong) have very dubious value and I was thinking that maybe reducing the amount of work required for low-value posts would be beneficial. I'm happy to do this if necessary but I've reviewed maybe 20 posts that seem to have added some value out of the 4000 or so posts I've done. (partially to do with how I'm reviewing but still)
@NobodyNada Also doesn't the suggestion already address the "nuking" part of your concern since the (spitballed) suggestion would only apply to tp posts that had already been deleted? It seems like there would be a way to decrease some of the concerns...
@NobodyNada I agree that this would be good suggestion overall, but doesn't really address my concern since the old posts are still out there and still take the exact same amount of work to handle. In fact it might even make the concern slightly worse since the old posts will just sit there getting older and even less valueable/more difficult to handle.
@Rubiksmoose we don't need to burn through our entire backlog all at once -- heck, there's no reason we need to burn through our entire backlog ever. But the fact is, there are posts that don't meet our current review standards, and in my opinion we should keep track of them
@Rubiksmoose Yeah, I might be onboard with getting rid of very old posts after one fp feedback
but for everything created post-Barbequeue, and for every tp, I think the two feedbacks are still really important
@NobodyNada I think there is some value in emptying (or vastly reducing) the queue otherwise what is the point in having those items in the queue at all? If the rate of review never exceeds the rate of accumulation then those posts will never see the light of day and thus never add value and will simply add to the albatross around the neck of those of us reviewing right?
Either way though, as long as we can consistently review faster than the queue piles up, IMO we don't need to be having this conversation. Before the barbequeue really took off like this, the hope was just to churn through a couple posts in the backlog each day for the next 5 years
"as long as we can consistently review faster than the queue piles up" I'm not convinced this will continue to be the case, especially if we don't stem the tide of new low-value reports.
The original Teams post notes that we were 18247 reviews shy of where we needed to be in a year. That's a lot, and we haven't even dug ourselves out from that despite some truly incredible reviewing work (~12k reviews).
I think the queue ordering change are the easiest and least controversial way to make review feel more effective. If anyone has order change suggestions please throw them in an issue and I'll try and sort through it.
Could even try to have multiple orders, like a dropdown or something.
If someone can help me get a more concrete proposal situated (as far as conditions) I'm happy to edit my post. As it is I kinda just wanted to throw the idea out there while I have the energy/impetus.
Additionally, I'm curious, what are the amounts of various weights making up the review queue right now. I'd bet money that it leans very heavily towards low weights.
Not that I'm asking someone to necessarily write that up.
@Rubiksmoose It definitely leans heavily towards lower weights. While watching reports in chat, people preferentially respond to higher weight posts and ones with reasons and/or titles which they feel are more likely to be TP, which is a good thing, as those usually need to be spam-flagged, whereas the FP posts can, to a large extent, wait.
It also shows a bit of a bias in my behavior. For a long time I reviewed every single post which wasn't "complete" ("complete" defined as: at least 2 feedbacks, all feebacks non-conflicting, and if it has tpu feedback it's deleted). That got to be just too much work, so I switched to daily reviewing every post which wasn't complete with at least one TP (and those that just looked like they should be handled). Thus, my in-chat reviews with FIRE, heavily leaned towards TP posts.
The combination of both of the above will definitely skew the posts which still need reviews towards those which are FP.
@RyanM I was wondering about that. We could consider sending the post to MS before we report it to chat, and if MS responds with a "that's already reported", we skip the report
It was previously looked at and determined that it was too expensive. I've been kicking around other ways of accomplishing something similar, which might be viable.
The part I'm confused about is why it's expensive at all. It seems like it'd just be a SELECT COUNT(*) FROM p_feedbacks WHERE link = {link} AND body = {body} AND why = {why}.
By my count, there are 7,237 reports that could have been avoided by doing that check. That's the number of reports that are exact duplicates of another report by link, body, and why (not counting the first report).
I guess I should probably check the title too, but the why text being identical suggests it's probably about the same.
Also the fact that I can check every single existing MS report for those conditions in <20 seconds suggests that it's not that computationally expensive.
Yep. We could check the feedbacks table separately if we get a hit to confirm that it has 2 feedbacks if we want to, but that's not going to happen much since it would only be in the case of finding the report already existing.
I have a hunch that Makyen knows SD and it's operating constraints better than I do so I think there are probably better reasons, that's just what I thought of.
@thesecretmaster Generally, I'm going off of the conclusions of previous discussions, where this topic has been brought up and discussed. Various solutions have been proposed, from SD making a request prior to reporting each post, to MS just accepting the report, but not generating a new post record when the body, title, username, detections, and why data are all identical with a prior report.
The advantage of the latter is that it doesn't delay the reports, and is largely something MS already does, at least to the extent of determining if there are other reports for the same post. Expanding that check to see if there's an actual duplicate wouldn't be that much additional cost.
I don't remember the exact arguments for the last times the SD check with MS to see if it's a duplicate proposal was made, but the conclusion, IIRC, was that it would take too much time in the reporting process. I'm not sure if that's the case anymore.
@RyanM I don't know if it helps, but it would also prevent some amount of confusion for newbies. I can attest to getting tripped up by this as late as a day or two ago. Definitely when I started giving feedback there were times where I didn't give feedback because I thought I had already given feedback on it (when in actuality it was a different report). Alone certainly not a reason to change, but could be a side benefit.
@metasmoke [flag-pls] This is a well-disguised spam post: it has a zero-character link to a known spam site, presumably in a misguided attempt at SEO gaming.
@NobodyNada I'm not against the idea, but it's going to be more difficult to match this with regex than actually test to see if there's HTML in the post and then test the html inside it (with a-la bs4 and some heavy bs4 search components inside there)
