in reply to Re^3: Messaging the result of a consideration
in thread Messaging the result of a consideration

Hello LanX,

Interesting suggestion. In general, I would say No, but in some cases it could be useful. For example:

A reply node A is posted twice (accidental duplicate B), and the second reply (B) is considered for reaping. But B also has answers, and consequently receives upvotes. The end result is that B has, say, 15 votes to reap (and none to keep or edit) but non-negative rep, so it can’t be reaped automatically. In this case it would be nice if a janitor could transfer B’s upvotes (if any) to A, re-parent replies to B as replies to A, and then reap B. But I doubt that such a fix, even if generally approved, would be practicable to implement.

If janitors ever do get the power to reap nodes manually, I think there should be at least two preconditions: (1) the node has a high number of reap votes (significantly higher than the current threshold for automatic reaping); and (2) at least 24 hours should have elapsed since the node was posted. But of course that’s just off the top of my head. No doubt there are other factors I haven’t considered that would need to be addressed before such a change could be contemplated seriously.

Cheers,

Athanasius <°(((>< contra mundum Iustus alius egestas vitae, eros Piratica,

  • Comment on Re^4: Messaging the result of a consideration

Replies are listed 'Best First'.
Re^5: Messaging the result of a consideration
by jdporter (Paladin) on May 25, 2017 at 18:05 UTC

    How about this: Leave everything about reaping exactly as it is, except -- if the vote being cast would be the one that triggers reapage, and the user casting it is a janitor, then make the number of 'keep' votes necessary to inhibit reaping higher, like 4 or 6, instead of the normal 2.

    The effect would be that a janitor can cause the reaping of a node even if the consideration has enough keeps (2, or even 3) to prevent reapage normally. But reapage would still be prevented if there were a greater critical mass of 'keep's.

    I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies.
[reply]
      This means that janitors must wait till the critical mass of reap-votes has been reached before they can vote?

      Sounds like more work for them and more delay before a reap happens.

      Personally I trust the judgement of our janitors more than normal friars++.

      I'd have no problems giving them double votes and the right to override veto votes for AM and new monks.

      Cheers Rolf
      (addicted to the Perl Programming Language and ☆☆☆☆ :)
      Je suis Charlie!

[reply]

        Or we could decrease the number of 'reap' votes needed to trigger reapage, when the voter is a janitor.

        I'm looking for a simple-to-implement tweak which doesn't completely subvert the existing mechanism, but gives janitors a slight edge.

        I reckon we are the only monastery ever to have a dungeon stuffed with 16,000 zombies.
[reply]

In Section Perl Monks Discussion