I don't know there's enough benefit to be worthwhile for pmdev to bother with. We already have:

• Nodes to Consider
• Nodes Requiring Edits - A janitors poor-man's issue tracker.
• Recent Janitorial Edits - A history of janitors activities.

There are other tools as well. I don't remember them all. But with the power to consider a node should also come the effort to understand what should be considered, and how well-formed posts ought to look in the first place:

• What is consideration?
• Writeup Formatting Tips
• Help authors to help themselves; don't consider the small stuff
• How do I compose an effective node title?

I see far too many nodes considered for reaping. Obvious spam is ok. Obvious abusive language is ok. Blatent trolling is ok. Considering for trolling is a slipery slope, though, and for the most part I personally prefer to see less of that type of consideration, mostly because it tends to give trolls more to gripe about, but also because it becomes unclear where to draw the line. When I happen to see a node considered to be reaped for a reason that I feel doesn't clearly rise to the occasion, I vote keep. Even reaping duplicates is tricky. If the post is not 100% identical, then we're rewriting someone's history. If they are 100% identical then I prefer to keep the one that has responses. If both have responses I prefer to keep the most recent and to reparent the responses to the other node under the one that is kept. For duplicates time is of the essence; swift action can avoid gathering responses under each duplicate. The best approach is to upvote the keeper, downvote the duplicate, consider the duplicate for reaping, and make it clear in the consideration which is the keeper.

Of the three tools you mention, only "Nodes to consider" is open to ordinary mortals like me. Beyond the chatterbox, I have seen no discussion of individual nodes that are being or might be considered. This means that feedback is limited, which is why I am grateful for Chacham's suggestion that there be more.

As far as your slippery slope is concerned, I not only agree that it's difficult to know where to draw the line, but also believe that no firm line should be drawn. Trolls come and go. The more trollish nodes there are, the more eager I am to consider for reaping and to vote to reap. In other words, I am inconsistent. When the facts change, I change with them. But I acknowledge that consistency is a virtue and would not argue with those whose approach differs from mine.

These differing approaches are, IMO, part of what makes consideration a pretty good system. If people disagree, the status quo remains.

I repeat my agreement with the OP about the desirability of greater feedback for those of us who are trying to do our best with limited information. I don't know enough about the inner workings of the site (and probably wouldn't understand the code if I were shown it) to know what's possible, but it is not obvious to me why those with the power to consider should be denied the power to read the data in the tools you mentioned. I'd also like to see nodes that clearly should be reaped (right now there's a considered duplicate with 17 reap votes and no other votes) being reaped by the gods or janitors without the necessity for a reap vote after the node acquires a negative reputation. I, for one, don't like downvoting and do it only with strong cause.

Regards,

John Davies

Well said. Thank you for elaborating.

It's not so complicated, just check ntc once per day.

Every approval nodelet has a link to it, and you can also bookmark it in your personal nodelet.

I already explained how to see the node history of older posts, to get there just check your own vote history.

I think we should try to turn considerations into first-class nodes. The Everything motto is: "Everything is a node." But unfortunately that isn't quite true; some data objects managed by the engine are not nodes. Considerations being one of them. Often all it takes to turn something into a node type is to create a new entry in the nodetype table. Unfortunately, in this case, it would take a bit more than that, since, as currently implemented, considerations get deleted when the consideration is resolved (or by janitors' explicit direction). We'd have to add a 'resolved' flag field, better probably, a 'resolved' datetime field. Something like that. With all the consequent code changes.

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

Food for thought, perhaps:

When implementing changes to a table in a database, in order to have minor impact, you can create a new table with a new name to house the change, and migrate the data from the old table according to the new scheme. Then, create a(n updateable) view with the same name as the old table, querying from the new table. This sets the stage for changes with little affect on the current code base.

Once that is in place, changes can be made slowly, using the new table instead of the view, while the current code using the view.

It would be nice to know the result of a consideration regardless of the outcome.

That would amount to either 1) messaging all people involved in the consideration process or 2) sticking a consideration history to the node. I'd go for 1) since clicking away SPAM is easy, and 2) is too much work, despite being best... ;-)

messaging all people involved in the consideration process

"all people" How many are there?

Depends on each "voting tally". Five? Ten? Twenty?

perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

"Too much work" was already done.

[[chacham]]: troll (2017-05-18 16:46:42) 2/0/8

If you click on the edit number you'll see the vote details.

Hope this helps

Ooh, i did not know that. That is pretty cool. Thank you.

Hmm.. it would would be nicer if there was an indication of an edit without having to click through. But, for the most part, there is a way to check, and that was the main thing in that regard.

If the node does not get reaped or edited, there is no message and the node is not noted.

In what time frame? This is similar to the halting problem. Unless you were to set a timeout on consideration votes, it would be difficult to know when it fails. OTOH, perhaps if there is a known value of keeps where it will no longer have the potential of succeeding, then perhaps a failure note could be generated. It still leaves that in-between case where there have not been enough votes to tell definitively what the results will be.

AFA I understood the discussion, do Janitors normally "unconsider" after a while, to keep NTC short.

That's the "halt" where the originator could theoretically be messaged.

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

Last time I saw it it had between 7 and 11 "reap" and 2 "keep". It was visible for at least 24h, maybe you should have checked in the meantime.

2 keeps are enough to block automatic reaping and the janitors didn't do it manually.

I don't think a re-consideration is of any value because old posts don't attract many voters.

Consideration has nothing to do with votes, but with issues with the node. A node might well be re-considered for another reason.

perl -le'print map{pack c,($-++?1:13)+ord}split//,ESEL'

2 keeps are enough to block automatic reaping and the janitors didn't do it manually.

For the record, janitors can’t reap a node manually. Only the gods can do that.

Athanasius <°(((>< contra mundum

Iustus alius egestas vitae, eros Piratica,

> For the record, janitors can’t reap a node manually

So do you think janitors should have this power?

Maybe restricted to certain preconditions?

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

See Nodes To Consider for an overview.