Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

Consideration overhaul?

by castaway (Parson)
on Mar 07, 2004 at 14:32 UTC ( #334609=monkdiscuss: print w/ replies, xml ) Need Help??

This is about some suggestions on how to change/approve the considerations/voting system, with the aim of nudging people towards thinking before they consider, and reading nodes/replies before they vote on considerations.

Without further ado, the following suggestions have been made:

1. To encourage more consideration before Consideration; not allow considering of nodes until they have been around for at least X hours. Probably this would only apply to root nodes. Editors would still be able to step in and edit nodes without them being considered, thus immediate problems such as lack of code/html tags etc would still get fixed. Downside: root nodes that are (really) offensive would also take a while to get removed, although 3 editors could still nuke them.

2. Change the consideration choices; Instead of just a text box and a button, the nodelet could actually list reasons like delete, fix formatting, duplicate, retitle, OT etc. With the textfield for the reason, and box that takes an id, for the duplicate type. This could be combined with the above to allow only certain types of considerations immediately, and others later.

3. Nudge people voting on considerations to actually read the node in question; This involves changes to, or doing away with, Nodes to Consider. The assumption being that people go to Nodes to Consider, look through the considerations, and vote, without actually going to the node itself, and reading it, and/or its replies. (Which might, for example, prove that a node isn't as OT as was believed at all). So, Nodes to Consider could just list nodes that have been considered, without showing what for, or the node contents, but just providing links to the nodes in question.

4. A further improvement on this would be to add links in the approval nodelet showing the 'next considered/last considered' nodes, (usefully, just the ones one hasn't voted on yet). Making it easier to not go to Nodes to Consider at all.

Update: Oops, forgot to mention that this came from the editors' wiki.

C.

Comment on Consideration overhaul?
Re: Consideration overhaul?
by TomDLux (Vicar) on Mar 07, 2004 at 16:14 UTC

    I've generally avoided consideration, because it wasn't a very clear process. I hope these suggestions will clear things up a bit.

    I especially like idea two, of having meaningfull options, instead of trying to guess whether the appropriate response to "Lacks code tags" should be "keep", "edit", or 'delete"? Or is this just for before it's been considered?

    Old grammar bugbear: don't mix nouns, verbs and adjectives in the list. Is it a list of problems, such as 'formatting problems' or 'OT'? Or is it a list of things to do with the message, such as 'delete','retitle'?

    --
    TTTATCGGTCGTTATATAGATGTTTGCA

      There are four choices when voting on a consideration:

      • Keep: I think no intervention is neccessary with this node. It is fine as-is.
      • Delete: The node should be reaped.
      • Edit: Something should be changed with the node, by the editors, but it should not be deleted. This could be formatting, moving, or retitling.
      • Nada: I have no opinion on this node at this time.

      I hope I've given proper parallelisim to the list above. (Now, if I could only spell parallelisim.) Note that "keep" is "I think this is good", and "Nada" is "I don't care either way".


      Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

      I like suggestion two as well, but I think it would also be nice to know when the node was considered. Sometimes some great threads follow the node after it is considered, leaving one to wonder why it was considered. Knowing that the consideration was before the thread would be helpful.

      - - arden.

Re: Consideration overhaul?
by davido (Archbishop) on Mar 07, 2004 at 18:10 UTC
    I'm not in favor of option #1: "not allow consideration of nodes until they have been around for at least X hours"

    This means that for timely cleanup an editor will have to actuall notice the issue. With considerations, level-6 monks and above can become the eyes and ears of the editors. With long consideration delay, editors have to do their own hunting/seeking for trouble. This basically increases the amount of work editors must do (while admittedly removing a little work in keeping up with considerations). This also could mean that potentially important janitor work gets missed until several hours pass. It basically negates the effectiveness of the consideration process.

    I see "considerations" as "red flags" that the editors can focus attention on. Without considerations, there are no red flags, and editors must stumble across problems themselves until nodes reach "x hours old".

    I think that an important aspect of the consideration process is education. Until people better understand what to consider, why, how, and how not, we'll keep seeing goofy considerations.

    I get disgusted when I see "Considered by XXXXX: Strange post." What's the point of the consideration? Is the person who considered it suggesting we delete, edit, keep? If we edit, in what way is he suggesting it be edited? If the "Comment" box for considerations were changed to a "Recommended action" box, maybe we'd get more assertive and well-thought-out considerations.


    Dave

Re: Consideration overhaul?
by revdiablo (Prior) on Mar 07, 2004 at 22:19 UTC

    I really like suggestion 2, especially coupled with the idea that certain types of Consideration require a couple of hours before they become available. I think Edit should be available right away, but Delete should require a delay. Not saying anything new here, just voicing my opinion on the matter.

    Out of curiosity, though, is there a reason this overhaul is being considered? Are there a lot of Considerations going across the board that shouldn't be? I guess I'm just wondering if there's any justification for adding even more complexity to the Monastery.

      Since what are good and bad reasons to consider, are largely a matter of opinion, I purposely avoided mentioning what prompted this conversation. (And Im not going to add it).

      In general though, there have been some which have lead to reapings of nodes as 'not perl', when it turned out the author just didnt explain enough, which they went on to do, despite the root node being reaped. C.

Re: Consideration overhaul?
by theorbtwo (Prior) on Mar 07, 2004 at 22:48 UTC

    I like 1..3 above. I don't like 4, not because it's not a good idea, but because I suspect it would be a DB hog, just like the Node Navigator nodelet. (If there are any DB-heads with some free time, I'd love to get it back.)

    Some additional ideas: Rate-limit how many nodes can be considered by a single person per day, or for that matter, how many considerations you can vote on.

    Take away XP for poor considerations, and possibly give points for ones that succeed. (Requires more editoral work, though.)

    Hide the name of the consider to voters.

    Record the names of voters on reaped nodes.

    Give editors a check-box that says "vote this option three times" on consideration voting, and take away editoral deletion.

    Change the required votes for reaping to 2*(keep+edit)<reap

    Allow editors to unreap nodes.

    I'm just brainstorming here, of course...


    Warning: Unless otherwise stated, code is untested. Do not use without understanding. Code is posted in the hopes it is useful, but without warranty. All copyrights are relinquished into the public domain unless otherwise stated. I am not an angel. I am capable of error, and err on a fairly regular basis. If I made a mistake, please let me know (such as by replying to this node).

Re: Consideration overhaul?
by PodMaster (Abbot) on Mar 08, 2004 at 10:36 UTC
    I for one would like to know when nodes were reaped if that information is available.

    MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
    I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
    ** The third rule of perl club is a statement of fact: pod is sexy.

      That was something else I was pondering.. A reaped nodes list, showing when/how etc. That (w|c)ould be useful information.

      Update: It appears the reaped-dates aren't in fact stored anywhere, from what I can see on reapnode (pmdev link). It would be an easy patch to add that info to the actual reaped node. Saving it somewhere is a bit more effort, as the reapednode table would have to be expanded a column.

      Note: There is actually a list of reaped nodes, although the 'Write-Ups' link on NodeReapers homenode shows 'none', the query behind it does show a list of reaped nodes. The dates are the original node creation dates, however.

      C.

Re: Consideration overhaul?
by dws (Chancellor) on Mar 10, 2004 at 19:08 UTC

    While we're considering consideration, I'd like to see an explicit "Move" option.

    Sometimes the consideration text is ambiguous about whether the intent is to move a post or edit it. Having a single "Edit" button that can mean both "Move" and "No, Edit!" doesn't provide clear guidance to the editors. I'd rather not look at the votes and guess at their intent.

Re: Consideration overhaul?
by Aristotle (Chancellor) on Mar 11, 2004 at 10:48 UTC

    The problem as I see it is not with the consideration process as such, it is with trigger happy root node reapings. I don't see why the entire process should be impeded to help that and how it would do so at all. I particularly dislike the idea of a delay imposed on Consideration, for the reasons davido mentioned.

    So, we're talking about root nodes, and we're talking about reaping; nothing else. When do we especially want it and when don't we especially want it?

    We especially want it when a dupe is created. These should be as easy and as quick to dispose of as possible.

    We especially don't want it for a number of ill thoughout consideration reasons that seem to be applied to root nodes only. (I haven't seen a note get reaped as "not perl" yet.)

    To delay undesired reaping of root nodes, I suggest to simply raise the number of delete votes required before a root node consideration leads to reaping. As either an alternative or a compounding measure, the noderep required for reaping could also be lowered. This would easily allow the node a chance to acquire keep votes and remain.

    Dupes are not much of a problem even then. Proposition #2 could help; particularly if the approval nodelet listed the choices as labels with radio buttons, as then there could be an input box for the node id that could be required to be filled in. That would make sure that the consideration reason always contains a link to the dupe and is therefor easy to check. It is also conceivable that once a node is considered as a dupe of another, the other dupe cannot be considered as being a dupe any longer. Or if that is considered a problem, then both could be considered but their votes would be lumped together and it would then be at the discretion of a janitor which one to reap.

    Makeshifts last the longest.

Re: Consideration overhaul?
by davido (Archbishop) on Mar 17, 2004 at 08:17 UTC
    I just wanted to document here one point discussed recently in the CB.

    The idea of a drop-down menu of consideration reasons has been discussed. My additional refinement would be to have individual "reasons" removed from the drop-down list after a node has been previously considered for that reason.

    That way, for example, a node won't get considered for "promotion to tutorials" several times, each time ending in a "keep" majority.

    Think of it a little like the US Legal system.... where, while there may be multiple appeals filed in the wake of a court decision, each appeal must argue a unique point. Once an appeal has been ruled upon, any future appeals must be in regards to other topics of discussion.

    Coming back to the Monastery, that would mean that a node couldn't be considered twice for topic change, but it could be considered once for topic change, and later on, considered again for the different purpose of the addition of code tags.


    Dave

      I don't think this should ever be done. A better way to address the presumed problem (and something that would be useful for many other reasons) is to make available the consideration history of a node including when it was considered, for what, how the vote turned out, when and why it was unconsidered (which will require asking for a reason when janitors unconsider a node), etc. Perhaps considering a node that had previously been considered could display the consideration history and prompt "are you sure?". Fixing a title once doesn't mean that a much better title can't be suggested. Not being a duplicate once doesn't mean it can't become a duplicate. Or a poorly worded consideration might fail for the wrong reasons. Etc.

      - tye        

        I totally agree. I have unconsidered on a few occasions and wish there had been a place where I could have said something like "This has already been considered for reap, as OT, and unconsidered. Please don't do it again!"

        It would also be nice if something similar could be done wrt approvals.

        jdporter
        The 6th Rule of Perl Club is -- There is no Rule #6.

Re: Consideration overhaul?
by PodMaster (Abbot) on Oct 02, 2004 at 13:34 UTC
    Here is what I believe should be the new look of the Approval Nodelete. As you can see (hopefully), it makes clear all the valid reasons to consider a node and makes it easy for people to make the right choice. You can consider a node for both deletion (offtopic) and editing(unfrontpage). All the options with a text input field require values.
    http://crazyinsomniac.perlmonk.org/perl/misc/approval.nodelet3.html
    castaway I like your item #3, Nodes to Consider should just link to considered nodes (and maybe also list the consideration reason, and maybe also display current totals if a friar+ has already voted on a particular node), so that a voter has to visit the node in order to vote on it.

    MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
    I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
    ** The third rule of perl club is a statement of fact: pod is sexy.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: monkdiscuss [id://334609]
Approved by gmax
Front-paged by TStanley
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others surveying the Monastery: (7)
As of 2014-12-27 03:33 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (176 votes), past polls