Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

editor delete votes

by ysth (Canon)
on Jul 13, 2005 at 19:28 UTC ( #474659=pmdevtopic: print w/ replies, xml ) Need Help??
ysth has raised the following topic:

The "feature" of allowing 3 janitors to cast an "editor vote" to delete a node and have it be nuked has been disabled. As far as I know, everyone agreed that nuking was too big a hammer. Do we want to reinstate this to reap instead?

I'm interested in hearing your opinions.

As a separate question, should nodes out there that were nuked via editor vote be reinstated as reaped nodes? There are more than 600 of them, but only 2 of those are nodes created in the last year.

Comment on editor delete votes
Re: editor delete votes
by davidrw (Prior) on Jul 13, 2005 at 19:37 UTC
    can you give a random (2 or 3) sample of the types of content in the nuked nodes (i can guess of course, but might help to see actual data)?

    What would be gained by changing from nuked to reaped? there's no way to retrieve or search either on is there? (i guess w/ reaped you can get to it by finding a reply node)

    Of the 600, how many have replies? Does nuking a node nuke it's children too?

      Maybe someone could point me to a document or, barring such a document, please explain what the benefits of reaping over nuking are? I mean, from what I can tell, a reaped node just makes it slightly more difficult to see a node, but doesn't really remove it. I presume a nuked node is just taken out of circulation such that it can't be seen anymore?

      If that's the case, I'm not sure why we reap at all - if a node is worthy of being deleted, it's worthy of being deleted, not just given a timeout in the naughty corner.

        Why do we reap? One of the biggest benefits of reaping is that reaped nodes are not searched by Super Search.(1) They also do not show up on the lists of postings in the various sections of the site, e.g. Seekers of Perl Wisdom and The Monastery Gates. So unless you really try to drill down to a reaped node's original content, you will never see it. (Reaped nodes are included in Newest Nodes, if you've enabled that in your User Settings.) So, other than the content being kept "near line" to slake the appetites of the morbid, reaped nodes are as good as gone.

        Nuking a node removes its record from the perlmonks database, so it is really gone, as far as the users are concerned. However, the data is not lost entirely — it is copied (serialized) to a backup file. So if the gods should deem it necessary, one of them can restore the nuked record. But note that this process is substantially manual, so requests from users to "please un-nuke my node" will likely fall on deaf ears. (And if I'm mistaken about this, I'm sure the gods will strike me down.)

        There has been a movement/desire amongst the janitors for quite some time, to have janitor-nuke changed to janitor-reap. I'm unaware of any dissent on the question. So I'm a little suprised that it hasn't happened yet.

        But of the question, "Why do we need janitor-nuke/reap at all?" It basically boils down to the fact that the standard reaping mechanism, which is automated (and based on the whims of hoi polloi), sometimes doesn't do the right thing, in strange/corner cases that really require a human's good judgement (where the human is someone who has the PerlMonks tenure, experience, and wisdom to know what's right for the monastery).

        (1) Technically, the reaped node's content is replaced with standard text, which, besides a pointer to the node's original content, includes the text of the consideration reason which led to the reapage in the first place; and this content is searched by Super Search.

      Does nuking a node nuke it's children too?
      No. You can see the effect of nuking on replies here, here and here (notice in the last example how the reply doesn't show up when you view the root node of the thread).
Re: editor delete votes
by Arunbear (Parson) on Jul 13, 2005 at 22:19 UTC
    I think janitorial reaping is useful for the reasons that jdporter has given. Another idea is to create a new group of super-janitors who would have reaping and un-reaping powers.
Re: editor delete votes
by davido (Archbishop) on Jul 14, 2005 at 01:47 UTC

    Janitors don't need nuke power. Frankly, there are only a few cases I can think of in the past year where janitorial reap power would have been helpful. On the other hand, I can't think of any cases where it would have hurt for the power to exist. I think for the most part Janitors have reasonable restraint, particularly when it comes to their philosophy toward reaping nodes. But I'd rather see the scales weigh against reaping in general, and that probably means not giving the power to reap to Janitors, even if it requires three or however many janitorial reap votes.

    Speaking with a few in the CB yesterday we discussed a change to number of moderation votes needed to reap a node. I'm in favor of that strategy. If I recall, it was 3 keep or (keep+edit)/2 > 3 to block. And the number of delete votes required would go to 10. We have a lot more "moderators" nowadays than a few years ago. We almost always see considerations reaching at least ten votes one way or another. Reaping is getting accepted or blocked prematurely under the current situation.

    Furthermore, there should be a Janitors checkoff required before a node that has met auto-reaping criteria actually gets automatically reaped. We have enough janitors that this shouldn't cause a substantial delay in reaping, and this will prevent mob mentality from getting a node reaped that really shouldn't be. I can think of a number of instances where this would have been a good idea over the past year or so.

    So my proposal would be: Increase number of delete votes needed to 10.
    Increase number of keeps to block to 3.
    Alter Keep/Edit to block to (keep+edit)/2 > 3.
    Require a checkoff by any janitor prior to a node actually getting reaped.

    ...just my .02 ;)


    Dave

      I've wondered (questioned, thought about) the relatively tiny amount of keep/edit votes needed to keep a given node around, blithly (from my view) ignoring the number of delete votes. As mentioned there are quite a few more moderators, and speaking from experience being somewhat new to the task, I've nearly hit the wrong button a few times for doing what was "good" for the monestary (in my opinion of course). Plus, sometimes I'll act rashly and then mull it over and wish I'd not have "voted" that way.

      I'm sure there has been a lot of discussions about this topic in the past, but I haven't supersearched at this point. If this sparks a healthy debate, great; if someone points me to the FM, I'll accept that too. If I've started a firestorm, I appologize.

      -Scott

        It's better to weigh things towards not automatically reaping in questionable cases. Nodes can still be reaped once blocked (either via unconsidering/reconsidering or appeal to the gods).
      With janitorial checkoff required, it seems like there'd be no need to tweak the vote requirements.

      I'd rather see reaping continue to be automatic (with the proposed change to required votes) but allow a janitorial unreap (which would require recently reaped nodes to be listed on nodes requiring editing or somewhere), possibly by the same 3-vote mechanism.

      In my opinion, whereever gods can be removed from needing to participate in the day to day maintenance of the site, they should be, and unreaping and force-reaping nodes seem to me the easiest pickings.

        I see your point and agree that it's unnecessary to have both a tweak to criteria and janitorial checkoff. And if unreaping is handed down to the janitors, that will help to eliminate the problem.

        I am mostly concerned with those times when you go to the fridge to grab a can of coke and find that by the time you return, someone has considered a node for reaping, and it got its required votes and was reaped before anyone with a little more seasoned judgement has time to step back and say "whoah, what's going on here?" I don't think anyone would argue with the assertion that there have been some things reaped that probably shouldn't have been. More demanding criteria, and the ability to unreap will solve this problem.


        Dave

      It should be keep+(edit/2) >= 3; changed from the current keep+(edit/2) >= 2. I like increasing the counts, as we haven't had any real trolls in years and we've had quite a bit of overreaping.

      But I also prefer janitor unreap over janitor approval.

      I support the "janitor reap" vote, but I realized that I'd be against a lot of reaps that would result because I was against the reaping of a lot of nodes that more than one janitor voted to nuke despite official policy being not to do that at all.

      But I think the solution for that is "janitor keep" votes. But with the small number of janitors, picking the numbers get trickier. Perhaps, using "keep:reap" notation, 0:3 would reap as would 1:5, but 2 or more "janitor keep" votes would prevent janitorial reaping.

      I'd also only allow janitorial reap/keep votes if the node is already considered. This has two advantages. First, it means that the reaped node has "reason" and "considered by" displayed like a normally reaped node. Second, it allows the janitorial vote to be reset by unconsidering.

      Going back to regular consideration votes. I think I'd like a sliding scale there as well. So, using "keep+int(edit/2):delete" notation, 0:8 would reap. As would 1:12, 2:16, 3:20, 4:24. So, if the delete votes reach at least 8+4*(keep+int(edit/2)), then the node would be auto reaped. But I think there needs to be a ceiling to avoid encouraging "rabble rousing" to try to overpower some conscientious 'keep' votes. And so 4 'keep' votes is enough to prevent non-janitorial auto-reaping no matter how many 'delete' votes come in.

      Also note that janitorial reap does not require a negative reputation.

      - tye        

        (sliding votes) - Yes, exactly! The thing that bothered me the most was that given a hypothetical vote of 3 keep, 25 delete, we'd end up keeping the post even though most people thought deleting it was the "right" thing to do. I think a sliding vote type system would resolve that issue, yet ensure that excessive reaping wouldn't become a bigger problem.

        -Scott

Log In?
Username:
Password:

What's my password?
Create A New User
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others about the Monastery: (5)
As of 2014-08-31 05:13 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    The best computer themed movie is:











    Results (294 votes), past polls