|
in reply to Messaging the result of a consideration
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.
|
Re^2: Messaging the result of a consideration
by davies (Prior) on May 21, 2017 at 09:55 UTC
|
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
| [reply] |
|
|
| [reply] |
|
|
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.
| [reply] |
|
|
nodes get reaped too fast that needs to slow down
checking in once a day is not enough, if its a crowded house nodes can get autoreaped in less than one hour -- your keep/edit/++ votes do not count afterwards -- cool heads cannot prevail
| [reply] |
Re^2: Messaging the result of a consideration
by jdporter (Paladin) on May 22, 2017 at 16:17 UTC
|
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.
| [reply] |
|
|
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.
| [reply] |
|
|
