Update: this is incorrect, there is a policy about this matter, but I managed to remember it 180° backwards

Just a quick note to bring up a finer point about considering duplicates. In the current state of affairs, the site deals poorly with the following sequence of events:

  1. user previews a node, patiently checking for errors;
  2. user submits node;
  3. user suddenly realises that they made a really stupid mistake;
  4. user presses "Back" (or equivalent) in the browser;
  5. and user makes change, and presses submit.

Bingo! we have a duplicate node. In this case, the correct course of action is to consider the earlier node(s), not the later node(s), for deletion. 99.999% of the time this is the right thing to do, the reason being that by the time this has happened, the higher-numbered node is more up to date than the lower-numbered.

There have been a couple of instances of this happening in the past weeks, which I why I bring the topic up.

One other point, in case people aren't aware of the algorithm: a node is automatically reaped if it has 5 delete votes, and no edit or keep votes. It also needs to have a negative reputation. There was a node that needed reaping the other day, that I downvoted and voted to delete. When the page came back, it had 6 delete votes, and a rep of -1.

Which means that it had gathered the necessary delete votes, but no-one had thought to downvote it to ensure it was reaped. So when you're considering to delete, toss a coin, and if it comes up heads, go and check Worst Nodes to see whether it has a negative rep. If it hasn't, downvote it before you consider it for deletion.

Here endeth the lesson for today.

Ok, let's look at this from a proposal angle.

The problem I see with the current policy is that people will add more information to the root node, probably making things clearer, albeit in an incorrect manner. I put forward the idea that the latter node is more "deserving" of collecting the replies.

What really needs to be done is to have a mechanism in place to stop duplicates from occurring in the first place, but I must admit that I don't have time to devote to the matter in any case.

  • Comment on Considering duplicates: reap the lowest ids, keep the highest

Replies are listed 'Best First'.
Re: Considering duplicates: reap the lowest ids, keep the highest (no!)
by tye (Sage) on Jan 13, 2004 at 01:14 UTC

    Actually, no! What you do is follow the documented site policy and keep the first and consider the later duplicates.

    The main reason for this is that you can't tell how many people had already started replying to the first node before it was even a duplicate. You'll consider the first node, reap it, and then 4 people will finish their replies and we'll have an active thread with a reaped root node.

    There are other reasons as well, but that is the most important one. The author will have to update or reply (if anonymous) to fix the original. Or one ambitious editor might decide to move the contents (which is a one-time action and currently less work than moving a bunch of replies along with the thrashing of unapproving the previously-most-current, etc.).

    The site policy allows for reaping the first in some cases. For example, if someone didn't notice the first node and approved the second (and the first wasn't approved) and so the second one ends up with most/all of the replies. Or perhaps the first is so poorly presented that useful answers are unlikely while the latter duplicate is *obviously* clearer (through this balance can quickly change when an editor throws in the missing code tags, so that isn't even a clear-cut reason to prefer a later node.)

    I'd appreciate it if you'd update your root node so that we don't have a whole flock of people who didn't read replies to your node and start thrashing against those who have read the site documentation and know what the policy is.

    In future, you might want to look at what site policy is before posting and word it as a question/proposal rather than like you are announcing policy.

                    - tye

[reply]
      In future, you might want to look at what site policy is before posting and word it as a question/proposal rather than like you are announcing policy.

      Argh! I thought it was the site policy, otherwise I wouldn't have said anything! Oh, shoot me now and put me out of my misery.

[reply]
Re: Considering duplicates: reap the lowest ids, keep the highest
by castaway (Parson) on Jan 13, 2004 at 08:07 UTC
    I'm going to go with tye on this one (site policy notwithstanding, I wonder where thats written, I havent stumbled across it yet). My instinct has always been to keep the first, and reap the following duplicate(s), the reason being that usually the second posting is accidental. (Im also pretty sure Ive tried to post something twice once, and it refuses to accept a similar looking (same title?) node right after one has just been posted, so Im curious as to how people can hit back, edit, and repost..)

    Also its nicer/easier to keep the node with replies, whichever it might be, as that makes our job easier.

    (Another reason Id like to be able to edit/remove considerations.. there have been a lot of considering-both-duplicates-by-different-people lately, risking that both get reaped..)

    C.

[reply]

      so Im curious as to how people can hit back, edit, and repost..)

      Im pretty sure it blocks identical reposts, but not differing reposts. If you edit after the "back" its not considered a dupe.


      ---
      demerphq

        First they ignore you, then they laugh at you, then they fight you, then you win.
        -- Gandhi

[reply]
[d/l]
Re: Considering duplicates: reap the lowest ids, keep the highest
by b10m (Vicar) on Jan 12, 2004 at 23:17 UTC

    Thanks for clarifying this a little. But what if the lowest id node has replies, and the highest hasn't? Shouldn't the highest node get considered?

    --
    b10m
[reply]
Re: Considering duplicates: reap the lowest ids, keep the highest
by ysth (Canon) on Jan 12, 2004 at 23:20 UTC
    Which means that it had gathered the necessary delete votes, but no-one had thought to downvote it to ensure it was reaped. So when you're considering to delete, toss a coin, and if it comes up heads, go and check Worst Nodes to see whether it has a negative rep. If it hasn't, downvote it before you consider it for deletion.
    I don't see any reason to downvote duplicates; presumably no one intentionally creates them. Can editors not choose to delete considered nodes that don't have negative reputation?
[reply]

      When somebody creates a duplicate node, they do the monestary a disservice, and deserive downvotes. The fact that the disservice is unintentional makes it not as bad, but it doesn't make it OK.

      OTOH, if you don't check, and always downvote-and-vote-delete, then the'll get a very low rep, and not just -1. So what should you do? Vote delete, and if there are at least five delete votes, and less then 3 keeps, -- it, because it means that it needs a lower rep to be reaped.

      As to your last query, yes. However editors cannot /reap/ nodes, only /delete/ them, outside of the ability to vote "delete" on a consideration, just like anybody else. The difference is that deleted nodes are really /gone/, not just slightly harder to see. (That's not 100% true. A /deleted/ node can be viewed by a god, and if he wishes (all gods are male, at present), he can undelete it. Others, however, cannot even tell that it once existed, by any art known to me.) So, IMnsHO, editoral delete should only be used in extreme cases, and the fact that there is no "editoral reap" that can be appled faster, and does not require negitive rep, is a bug.

      Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

[reply]

        theorbtwo++

        Clarifications: 'delete' can mean either 'reap' and 'nuke'. Editors can currently vote to nuke a node (which is as you described) but this will be changed to 'reap' RSN (and thanks for the patches).

                        - tye

[reply]

Back to Perl Monks Discussion