Enforcing unreap

At the moment, there is nothing to stop an unreaped node from being re-considered and reaped again. I'd like to fix that by having an 'unreapable' flag settable by gods and janitors. Unreapable nodes would be indidcated as such via the approval nodelet.

Now for the questions:

how will we use the flag to stop reaping?
E.g. we could use it to stop the node from being considered again by not showing the consider checkbox and textfield in the approval nodelet (probably too extreme).

Or else we could use it in the approval nodelet and Nodes to consider by not showing the 'delete' radio button.

Or else we could use it in consider by not invoking reapnode if the flag is set.
Should the flag be stored in a setting (e.g. approval nodelet settings) or in a (new) table?

Thanks for all ideas.

Comment on Enforcing unreap

Replies are listed 'Best First'.
Re: Enforcing unreap by grinder (Bishop) on Sep 24, 2005 at 21:46 UTC
What about a bit of sociable engineering? Change the consideration nodelet to add the text: "This node has already been reaped and unreaped. Are you sure you want to put it up for consideration to be reaped again?" Or words to that effect. An innocent bystander coming late into the party may have missed the hue and cry, and this might be a cheaper means of achieving the same end. • another intruder with the mooring in the heart of the Perl	[reply]
Re^2: Enforcing unreap by GrandFather (Saint) on Sep 24, 2005 at 21:50 UTC
Fine but verbose. How about: Reaped/restored already Perl is Huffman encoded by design.	[reply]
Re: Enforcing unreap by Tanktalus (Canon) on Sep 24, 2005 at 20:28 UTC
I'm not sure I understand why re-reaping is a bad idea. Nor why it's coming up - has there been a recent rash of bad considerations resulting in unjust reaps which were then unreaped, considered poorly again, and garnered the popular vote to be reaped a second (or third or fourth...) time? If you don't want to trust those who have the power to consider or vote on considerations to make these decisions, then I think you should just stop that, and leave all "considerations" in the hands of those who you do trust. Or, if you decide that it's better to decentralise this ability across so many people, then I'm not sure why you're trying to circumvent it. But, if you are going to put this type of veto power in, then I would suggest that the approval nodelet must tell anyone who would consider that the delete button won't be available because this node is marked as being non-reapable so no one tries to consider for "delete: troll" or something that encourages people to vote for delete, only to find out it's not there. Of course, a similar message should show up for those voting on it so they know why delete isn't an option when they think it really needs to be deleted (again/still).	[reply]
Re: Enforcing unreap by yitzchak (Sexton) on Sep 28, 2005 at 02:33 UTC
I would rather see effort spent toward allowing votes by three janitors to force reap or unreap a node, similar to the no longer available three-janitor nuke. Or in testing castaway's consideration changes that have languished so long.	[reply]
Re^2: Enforcing unreap by Arunbear (Prior) on Sep 29, 2005 at 20:38 UTC
There is aleady editor_vote - (patch) that would enable janitorial reaping as you've described. What I'm trying to point out is that unreap on its own doesn't do much good unless there is a way to make it stick. Another idea that occurs to me is that whenever a reaped node is unreaped, we would record that in an unreaped table. Then we make a superdoc that shows any nodes in reapednode that were once unreaped, so janitors can unreap again. What do you think?	[reply]
Re^2: Enforcing unreap by castaway (Parson) on Sep 29, 2005 at 20:44 UTC
Yes, me too ;) My changes don't address this particular problem.. But it would be nice to get them in, since I was planning follow-up ones to the actual consideration system. (The current ones are more moderation/approval ones). C.	[reply]
Re: Enforcing unreap by castaway (Parson) on Sep 29, 2005 at 20:41 UTC
I'd second/third the idea to just put a visual reminder in the nodelet, if theres already been a reaping. Its not that much of a problem, that I'm aware of. And remember, Perl doesn't have shotguns, it just asks you not to invade it's private space. C.	[reply]