Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling

Messaging the result of a consideration

by chacham (Prior)
on May 20, 2017 at 19:15 UTC ( #1190741=monkdiscuss: print w/replies, xml ) Need Help??

There is a message if a considered node gets reaped or edited, and the node is noted with this, including a link to the tally. If the node does not get reaped or edited, there is no message and the node is not noted.

It would be nice to know the result of a consideration regardless of the outcome. Also, when viewing a node, to see if it has been previously considered and what the tally was. Beside being interesting, it can prevent a second consideration of the same node.

  • Comment on Messaging the result of a consideration

Replies are listed 'Best First'.
Re: Messaging the result of a consideration
by davido (Cardinal) on May 20, 2017 at 22:35 UTC

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

    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:

    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.


      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.

Re: Messaging the result of a consideration
by shmem (Chancellor) on May 20, 2017 at 19:53 UTC
    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... ;-)

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

      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

Re: Messaging the result of a consideration
by Anonymous Monk on May 20, 2017 at 20:06 UTC
    The "approval nodelet" has a link called "node history"

    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.

Re: Messaging the result of a consideration
by Anonymous Monk on May 20, 2017 at 19:33 UTC
    You had a "troll" consideration 2 or 3 days ago.

    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'
        > 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!

Re: Messaging the result of a consideration
by MidLifeXis (Monsignor) on May 24, 2017 at 17:45 UTC

    If the node does not get reaped or edited, there is no message and the node is not noted.
    (Assumption: Considerations do not time out. This may be 100% wrong.)

    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!

A reply falls below the community's threshold of quality. You may see it by logging in.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: monkdiscuss [id://1190741]
Approved by davies
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others chilling in the Monastery: (2)
As of 2021-04-22 03:23 GMT
Find Nodes?
    Voting Booth?

    No recent polls found