Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical
 
PerlMonks  

Re^2: RFC: Hide Very Bad Answers From Visitors

by jdporter (Canon)
on Jul 24, 2018 at 21:44 UTC ( #1219199=note: print w/replies, xml ) Need Help??


in reply to Re: RFC: Hide Very Bad Answers From Visitors
in thread RFC: Hide Very Bad Answers From Visitors

Yeah, I was thinking vaguely of something along those lines as well. But I don't think using -$NORM is quite what we want, because that would mean that as the average node "quality" goes up, we become even more tolerant of even worse nodes. Instead, how about maybe something like -20 + $NORM. That would result in a threshold of -10.3 today. To put this in context: such a threshold would result in having no nodes posted today hidden, but all of this week's worst nodes of the week hidden (and then some).

I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies.

Replies are listed 'Best First'.
Re^3: RFC: Hide Very Bad Answers From Visitors
by Corion (Pope) on Jul 25, 2018 at 05:52 UTC

    Obviously, a node with a positive reputation should not fall under this rule.

      Right; that would be clamping at zero. I think I'd clamp at something negative. My personal feeling is to have a clamp at -7. I don't know why.

      I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies.
Re^3: RFC: Hide Very Bad Answers From Visitors
by pryrt (Parson) on Jul 24, 2018 at 22:12 UTC

    If you're going to use a formula like that, I would lobby for clamping to negative: $NORM<20 ? -20 + $NORM : -1;. Otherwise, if our $NORM quality spikes suddenly to 25*, some poor schmuck who "only" got +4 for a mostly-unnoticed post for some "Re^9" gets his reply hidden.

    *: okay, probably not likely with modern Best Nodes scores... but the idea is that I believe positive-voted nodes shouldn't be evaluated as "very bad", and so protection should be built in against that admittedly-unlikely event.

      Definitely agree with the clamping suggestion (for any system with a dynamic threshold), although I'd lower the "high" end clamp a bit, probably to -3, so that middling-to-decent responses don't get hidden simply because one or two people are having a bad day (or just want to be assholes) and give it drive-by downvotes before it receives any upvotes.
Re^3: RFC: Hide Very Bad Answers From Visitors
by hippo (Canon) on Jul 25, 2018 at 09:27 UTC
    that would mean that as the average node "quality" goes up, we become even more tolerant of even worse nodes.

    That only holds true if the actual mean quality increases. If $NORM goes up (or down) purely as a function of how many votes are cast in total (which it will), then using -$NORM seems perfectly rational.

    Instead, how about maybe something like -20 + $NORM.

    That also suffers form the same problem as just using -7: it puts an arbitrary fixed point into things which becomes problematic if $NORM changes greatly from where it is today.

      I see your point; but I note that -$NORM also has this problem, because it has an arbitrary fixed point of zero.

      I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies.

        You are of course quite correct.

        Just for curiousity, is there anything in the codebase to stop $NORM from being negative? If not, then that's potentially an argument in favour of the arbitrary fixed point being below zero. Although there would certainly be bigger fish to fry if such a thing ever occurred.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1219199]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (2)
As of 2019-04-21 06:22 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    I am most likely to install a new module from CPAN if:
















    Results (110 votes). Check out past polls.

    Notices?
    • (Sep 10, 2018 at 22:53 UTC) Welcome new users!