RFD: Raising the number of keep/edit votes needed to prevent a reaping.

The following discussion has been shamelessly lifted from the editors wiki, at tye's sensible suggestion.

castaway, 2004-11-23
Folks, Any objections to raising the number of keep/edit votes needed to prevent a reap? (We can raise the number of reap votes needed too if need be) - reason, there are many more >lvl5 than there used to be, so more likelyhood of bungled votes, IMO. In fact, having these as some (small) precentage of the number of users >lvl5 would fix it for good..

ysth, 2004-11-23
The larger number of senior monks means more lemming-votes too. I'd rather keep it at 2 even at the cost of more trouble for janitors/gods.

davido, 2004-11/23
I could see raising the number of keep/edit votes necessary to block reaping to three, or at the very most, four. I believe also that there should be a minimum consideration time, so that if enough 'delete' people jump onto a node quickly to get it reaped, the system still gives a few minutes for voices of reason to weigh in. Maybe it could be something like this: If there are zero keep votes, the consideration lasts ten minutes. If there are one, two, or three keep votes, consideration lasts an hour. And if a fourth keep vote comes, reaping is effectively blocked.

Editor deletes wouldn't be subject to the wait period. This will allow a few Janitors to jump on something truly offensive if necessary.

Let the discussion begin...

Wiki discussion was edited prior to posting in Inner Scriptorium, to put the wiki comments in forward chronoligical order (as opposed to wiki-standard reverse-chronological order).

Dave

Comment on RFD: Raising the number of keep/edit votes needed to prevent a reaping.

Replies are listed 'Best First'.
Re: RFD: Raising the number of keep/edit votes needed to prevent a reaping. by theorbtwo (Prior) on Nov 24, 2004 at 15:36 UTC
What I'd like to see happen is for all the requirements to be raised -- both the number of votes against to block and the number of votes for to reap. Also, I'd like to see Editor's Delete be changed to a reap (and renamed Editor's Reap). There are very few things really deserving of a nuke, and for those few things, a god can become involved. Also, this code /really/ needs a good cleaning. There's probably a half-dozen places where policy is defined -- and it's not defined the same way in all of them. 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]
Re: RFD: Raising the number of keep/edit votes needed to prevent a reaping. by Arunbear (Prior) on Nov 24, 2004 at 09:55 UTC
What about introducing an "Editor's Reap" e.g. 4 Janitors vote 'reap' and the node gets reaped; this would complement the Editor's delete, but be less drastic.	[reply]
Re: RFD: Raising the number of keep/edit votes needed to prevent a reaping. by ysth (Canon) on Nov 24, 2004 at 20:59 UTC
I'd really hate to see the number of keeps increased at all, except in conjunction with a minimum time, which I am undecided on. I'd like to take this opportunity to mention the unconsider rules and a recent change to them. The unconsider option becomes available (to janitors) once there are 2 edit votes or 4 keep votes. 2 edit votes are required before a node appears on nodes requiring editing, and presumably the 4 keep votes limit is to discourage unconsidering before a reasonable amount of voting has occurred. This has had the unfortunate consequence that nodes considered for reaping (which typically get only delete or keep votes) get "stuck" when there are enough keep votes to prevent reaping but not enough to allow unconsider. The rules have now changed to allow unconsider if a node has >= 5 delete votes but too many keeps to be reaped. I second theorbtwo's concern that these kind of rules are in too many places in the code; they need to be moved to a single source.	[reply]