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.
In reply to Re: Considering duplicates: reap the lowest ids, keep the highest (no!)
by tye
in thread Considering duplicates: reap the lowest ids, keep the highest
by grinder
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |