Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight

Choose a maximum for Rep

by lemming (Priest)
on May 25, 2001 at 04:37 UTC ( [id://83187]=monkdiscuss: print w/replies, xml ) Need Help??

I was just thinking about certain posts and how while some are worthy of every ++ they get, there are occasions I see a post that is worthwhile, but I don't think that they are that worthwhile. So here's my idea

Instead of one ++, perhaps several buttons with a rep choice broken down to either 5 or 10 rep points. Like so:

• ++ • ++ < 0 • ++ < 10 • ++ < 20 • ++ < 30 • ++ < 40 • ++ < 50 • -- • +=0

Just imagine those are radio buttons and not just a mock-up. Some concerns:

  • It's not very selective with leaps of 10 rep
    It's a suggestion at this point. I'm not very GUI orriented and I'm sure someone has a better idea.

  • Doesn't scale
    True, but I'm not sure if people really want to 23, 17, or 42 as the rep number. 0 is there for rescuing trashed nodes that really don't deserve to be negative, IYO.

  • So where does the vote go?
    I'm thinking that you still get your possible bonuses for voting and if the cap has already been reached you at least get the chance of seeing what the rep is.

  • Do we really need this
    Not really, I'm just throwing more work at fearless leader, but this may spark off a better idea.

  • Replies are listed 'Best First'.
    Re: Choose a maximum for Rep
    by chipmunk (Parson) on May 25, 2001 at 05:34 UTC
      If you don't think a node is worthwhile, just don't vote on it. I'm afraid I don't see the benefit to putting this level of selection into the voting system.

      If you're one of the first ten voters, your ++<10 vote counts, and then another person votes, so the node has a rep of 11 even though you didn't want to vote it above 10.

      On the other hand, if you're the eleventh voter, your ++<10 vote doesn't count, leaving the node with a rep of 10, based on nothing more than the order in which the votes were cast.

      This system would make the votes of monks who vote first less valuable than the votes of those who vote later.

        The reason I came up with this is because I find some nodes worthwhile, just not that worthwhile.

        I disagree that votes become more or less valuable. They're as valuable as you think they are. Another option is if you vote ++<10 and it's already there, you don't spend a vote.
        Several monks actually -- votes that are at certain levels because they feel that the rep has exceeded the actual worth.
        Sometimes you want to vote on a node just to see the rep and this would allow that.
        Of course you could extend the logic so that a vote with a cap of 10 would -- a node that already has 20, or set up some mathamatical expresion if you want to get more complicated.

        Anyway, it's just an idea. I'm not attached to it.

          I believe that, under your proposal, votes cast later would be more valuable than votes cast earlier.

          Here's a statistical proof. This code tries random orders of voting, keeping track of where in the order your vote is cast, and calculates the average reputations.

          #!/usr/local/bin/perl -w use strict; $| = 1; my @all = ((5) x 6, (10) x 6); # twelve voters: six voting up to 5, six voting up to 10 for my $own (5, 10) { # your own vote my $i = 0; my @others = grep $_ != $own || $i++, @all; # remove your vote from the list for now... my(%r, %n); for (1 .. 5000) { my @voters = shuffle(@others); # shuffle the other votes splice @voters, my $pos = int(rand @voters+1), 0, $own; # put your vote back in, and save the position my $rep = 0; for my $v (@voters) { $rep++ if $rep < $v; } # calculate the reputation $r{$pos} += $rep; $n{$pos}++; # adjust the stats for this position } print "$own:\n"; for (sort { $a <=> $b } keys %n) { printf " %2d %4d %4.2f\n", $_, $n{$_}, $r{$_} / $n{$_}; } # print position, number of occurences, and average reputation } sub shuffle { my @list = @_; for (my $i = $#list; $i >= 0; --$i) { my $j = int rand $i + 1; @list[$i, $j] = @list[$j, $i]; } @list; }
          And some results (your position / occurences / mean reputation):
          5: 0 411 8.77 1 404 8.80 2 409 8.77 3 414 8.74 4 411 8.76 5 452 8.25 6 393 8.36 7 425 8.28 8 409 8.32 9 417 8.31 10 444 8.29 11 411 8.23 10: 0 386 8.17 1 439 8.15 2 420 8.25 3 435 8.14 4 393 8.21 5 407 8.74 6 437 8.73 7 412 8.71 8 444 8.69 9 402 8.67 10 399 8.77 11 426 8.75
          Observe that the node's reputation will be closer to what you personally want if you vote later. If you're voting low, a later vote leads to a lower rep; if you're voting high, a later vote leads to a higher rep.

          Several monks actually -- votes that are at certain levels because they feel that the rep has exceeded the actual worth.

          If this is true, I do not see how this is any different from the personality voting that has been railed against so strenuously. Instead of voting (or ignoring) a node's content, you are voting its Reputation.

          If those doing this are against personality voting or would rather see more votes given to code, then I ask them to reconsider this practice. I do not believe it's necessary to "take a monk down a peg" for anything other than a bad node.

          Vote the node's content, not the poster nor the node's reputation.


    Re: Choose a maximum for Rep
    by footpad (Abbot) on May 25, 2001 at 20:41 UTC

      In an attempt to spark a better idea, what if we consider borrowing an idea from (Heaven help me) /.? Namely, the ability to flag nodes with certain attributes, such as "Insightful," "Funny,", "Underrated," "Overrated," "Interesting," "FAQ", and so on?

      If pursued, I'd see this as:

      • Being a Level Power (say Level 6 or 7, to provide cues to other senior members that this may be a node needing extra attention).

        The idea here being that it should only be available to folks who've been around long enough to fairly assess the "properties" of a node.

      • Briefly summarized in Index pages underneath the posters name. For example:

        Choose a maximum for Rep
        on May 24, 2001 at 17:37
        2 replies by lemming

        Note that this only requires the addition of a <BR> tag and a description.

      • Summarized in threaded views after the post date.

        For example:

        Re: Choose a maximum for Rep
        by chipmunk on May 24, 2001 at 18:34, Insightful, Underrated

        (Apologies for to chipmunk for borrowing his node for example purposes. No offense intended.)

      • Specifically summarized only to the poster when viewed in its own window, again in the header, e.g.:

        Re: Re: Choose a maximum for Rep

        by chipmunk on May 24, 2001 at 20:28
        Insightful (3), Underrated (2)
    • If done properly, this add more information about the community's reaction to a node, as well as more drugs for the addicted.

      I realize that this is a very ambitious proposal, one needing further analysis and a lot of work to implement. However, it might be a workable solution.

      Note: Please realize that I offer this as a possible solution to a problem that I do not believe exists. I do not think the current voting system is broken. I simply think it's not being used wisely.

      Thoughts? Feedback?


    Re: Choose a maximum for Rep
    by elusion (Curate) on May 25, 2001 at 04:58 UTC
      It might be nice to eliminate some of the options (I personally don't care to see that many) by making a
      ++ < [text_box_here]
      option. It requires a little more work, but will clean up the interface if this is implemented.

      - p u n k k i d
      "Reality is merely an illusion, albeit a very persistent one." -Albert Einstein

    Log In?

    What's my password?
    Create A New User
    Domain Nodelet?
    Node Status?
    node history
    Node Type: monkdiscuss [id://83187]
    Approved by root
    and the web crawler heard nothing...

    How do I use this?Last hourOther CB clients
    Other Users?
    Others drinking their drinks and smoking their pipes about the Monastery: (7)
    As of 2024-07-24 14:53 GMT
    Find Nodes?
      Voting Booth?

      No recent polls found

      erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.