in reply to Consideration overhaul?

The problem as I see it is not with the consideration process as such, it is with trigger happy root node reapings. I don't see why the entire process should be impeded to help that and how it would do so at all. I particularly dislike the idea of a delay imposed on Consideration, for the reasons davido mentioned.

So, we're talking about root nodes, and we're talking about reaping; nothing else. When do we especially want it and when don't we especially want it?

We especially want it when a dupe is created. These should be as easy and as quick to dispose of as possible.

We especially don't want it for a number of ill thoughout consideration reasons that seem to be applied to root nodes only. (I haven't seen a note get reaped as "not perl" yet.)

To delay undesired reaping of root nodes, I suggest to simply raise the number of delete votes required before a root node consideration leads to reaping. As either an alternative or a compounding measure, the noderep required for reaping could also be lowered. This would easily allow the node a chance to acquire keep votes and remain.

Dupes are not much of a problem even then. Proposition #2 could help; particularly if the approval nodelet listed the choices as labels with radio buttons, as then there could be an input box for the node id that could be required to be filled in. That would make sure that the consideration reason always contains a link to the dupe and is therefor easy to check. It is also conceivable that once a node is considered as a dupe of another, the other dupe cannot be considered as being a dupe any longer. Or if that is considered a problem, then both could be considered but their votes would be lumped together and it would then be at the discretion of a janitor which one to reap.

Makeshifts last the longest.