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

Re: Is nodereaper on worst nodes of note?

by footpad (Monsignor)
on Mar 19, 2001 at 01:03 UTC ( #65303=note: print w/ replies, xml ) Need Help??


in reply to Is nodereaper on worst nodes of note?

I agree that NodeReaper has gotten a little carried away and that we should be concerned about it.

Here's a few ideas:

  1. Access to Nodes to Consider

    I think jcwren has a good idea and that jorg raises a valid point. As an alternative, what if we limit Nodes to Consider to the Top 100 Monks? This is a) a nice, round number, b) should be reasonably trivial to implement, c) features a pretty broad range of opinion, talent, experience, and so on. Furthermore, it would also change as member participation changes and would be resistent to "Saint-overload" as the Monastery grows and ages.

  2. Tweak the Reaper's code

  3. If memory serves, a node is reaped when it receives a greater 5-2 Delete/Keep before getting a reply and so on. In reviewing the nodes that have been reaped, it looks as if the current algorithm doesn't take Edit votes into account. Perhaps the equation should be reworked to a) include Edit votes and b) increase the ratio to 10:2.

    When combined with a more limited consideration membership, this should more accurately reflect the collective will of the most experienced (and presumably participating) monks.

  4. Allow the Editors to "un-reap" nodes.

    No matter how (or if) we tweak the Reaper, mistakes will be made. Since the janitors are trusted to edit, certainly they should be trusted to clean up when the Reaper's gets overly enthusiastic.

Thoughts? Feedback?

--f

Update #1: In response to tye's reply below:

I'm not saying get rid of the Reaper. I agree that he serves a useful purpose.

Your formula is reasonable.

One reason why I suggested the janitors gain restoration powers was designed to help off-load some of the work from TFL. Most of the Editors are here much of the time, whereas vroom pops in periodically. It's just seemed a more optimal use of resources.

As far as getting to word out, well, there have been a number of posts on the subject since Consideration was introduced. Many of these were well received, but the problems they tried to address still exist. I believe part of this stems from a number of people using the Approval nodelet instead of their votes. I don't expect it's the Senior Monks and limiting access to Approval Nodelet should help reduce this sort of Approval abuse.

I agree with you that duplicate or slightly duplicate questions should be allowed to remain. As I've said previously, vote them down and then take the opportunity to educate the poster and those who follow.

As far as your extensions to Nodes to Consider itself goes, I agree with them, especially the first ones. :-)

Update #2: Fixed a "tpyo" and clarified the purpose of Update #1.


Comment on Re: Is nodereaper on worst nodes of note?
(tye)Re: Is nodereaper on worst nodes of note?
by tye (Cardinal) on Mar 19, 2001 at 03:13 UTC

    First, I strongly feel that we still need the reaper. Janitors don't have the power to reap nodes and I don't think they should (at the very least not single-handedly, though perhaps three-at-a-time makes sense, especially if they can reap nodes with a positive rep for cleaning up true duplicates). I also feel strongly that we need to adjust things.

    I don't want to just up the number of votes required to delete, nor to just lower the number of votes required to keep. I've seen nodes that should be deleted not get deleted and nodes that should be kept get reaped (and nodes that should be reaped get reaped with about the right amount of work). But I think having a bit more complex formula will help.

    I propose that the "delete" votes reaching 5+3*(other votes) when the node's reputation is negative (I was thinking we should allow reaping of zero-rep nodes, but I've changed my mind) should cause the node to be reaped. So a node with 1 vote to keep and 2 votes to edit would require 14 votes to delete before it could be reaped.

    Update: The current rules are that 5 votes to delete works as long as their aren't 2 or more votes to keep. So votes to edit play no roll and there is no ratio involved. So once there are 2 votes to keep, there is no way the node will ever be reaped (except if vroom does it by hand, which is always possible). 1 vote to keep and 5 votes to delete is currently enough (if the rep is right when the 5th vote to delete is cast) while my change would require 8 votes to delete in that case (or more if there are also "edit" votes).

    vroom already has the power to unreap mistakes and he has used it. I don't think giving that power to editors is required.

    I think a lot will be helped by just getting the word out that it isn't appropriate to reap nodes just because they aren't the best node on the subject (and this word needs to get out or we'll still be reaping the wrong nodes even with all of the other changes I've proposed). If someone asks a question that was just asked yesterday, they shouldn't have their node reaped. They probably shouldn't have their node approved, either, but a polite pointer to the previous question and some hints about learning how to use the site will usually get posted soon enough.

    There are always going to be similar answers posted at about the same time (even if "we" implement something like the improvements I've outlined for reducing the creation of such duplicated effort). I see absolutely no value in reaping any of such duplicates and will continue to vote "keep", even when the original author asks to have their own answer deleted for that reason (actually, right now I vote "edit" so that I have a hope of eventually "unconsidering" the node).

    I'd like for reaping of a reply to check whether the parent has been reaped. If so, and the parent has no replies of its own, the parent should be rereaped so that it will be removed from NodeReaper's list of nodes and can't be accessed any more. The rereaping would also check for a reaped parent node so that an entire thread can be reaped off of the site. This is only meant for trolls.

    Currently, anyone (even a troll) replying to a trolling causes that trolling to be accessible forever. I agree that we want to keep bad nodes around as a part of history and/or as examples of bad nodes. But I don't think we should keep examples of trolls around. I think that would just tend to give a troll a sense of accomplishment and give new trolls ideas.

    I could see raising the level limit for being able to vote on considered nodes, but I wouldn't raise it much. I'd really like to see, on the Nodes to consider page:

    • Automatically display who considered the node
    • Allow additional lines to be appended to "reason for consideration" to allow expressing of opposing viewpoints
    • Show whether the rep of a node currently allows it to be deleted (showing the actual reps of nodes you've already voted on would be nice, too, though less important)
    • Limit the display of nodes on Nodes to consider by:
      • Honoring <READMORE> (if I can have only one of this, I'd probably vote for this one because it gives the Janitors enough power to resolve all of the display issues)
      • Not displaying more than the first N characters or first M lines (whichever comes first)
      • Changing <pre> to <code>
      • and/or just displaying the raw user input as if there were <code> tags around the whole thing
    • Displaying what section each node is in and what approvals it has

            - tye (but my friends call me "Tye")

Log In?
Username:
Password:

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

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (7)
As of 2014-12-28 19:25 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (182 votes), past polls