On Responsible Considerations

The power to consider a node comes with great responsibility.
-- Friar (and strongly echoed in What is consideration?)

Recently, we've seen a number of new friars (and above) pitching in with the clean-up process. While it's nice to be able to catch the poorly-formatted nodes, the missing <CODE > tags, and the occasional "tpyo," a pattern (or two) appears to be emerging and some of us are becoming concerned.¹

Specifically, we're seeing an increase in what may be called "inappropriate" Consideration requests. For example, titles are being changed when they don't need to be, off-topic nodes are being deleted out of hand (with no attempt to gently correct the posting monk's understanding of the site's primary focus), and (most seriously to my mind) the Reaper is being fed things that aren't in his dietary plan (such as "no effort" and "not perl").

Yes, each of these actions is occasionally needed; however, I would argue that some nodes are being Considered when they should simply be voted down.²

Before I explain that in more detail, please allow me to outline a few tenets that I believe the Monastery values most:

• Honest questions deserve honest answers, for you cannot learn unless you make mistakes.

• We like Perl. It's the main focus of our site, but sometimes we need to talk about other stuff in order to use Perl well.

• While we don't want to write your code for you, we will help you get over the potholes in the learning curve. Perl isn't necessarily complex, but learning to use it well can be and we fully appreciate the fact that there's a lot to learn when you're first getting started.

• We do not like to rewrite our own history, for in showing others our mistakes, we reveal our humanity and illustrate the areas where we've personally run into roadblocks. In turn, this helps others avoid the same pitfalls.

• Very few of us are comfortable with the idea of censorship.

(I'm sure those can be put more succinctly and elegantly, but I hope you get the idea.)

So, what am I trying to say here?

• The point is, deleting (or obscuring) a node is Serious Business^TM. Some of us are feeling that too many nodes are getting reaped before they're given a chance. I personally know of at least one new member that had his first post reaped with no feedback and then chose never to return. We can't prevent that, of course, but in discussing this with him in the ChatterBox at the time, I learned that a) he was 15, b) had little to no experience with online communities, and c) didn't really understand how to obtain technical support (or how to research technical answers with the tools available).³

• Along the same lines, it's possible that people are confusing Nodes to Consider with moderation. As a monk in good standing, your primary feedback devices are your votes, your replies, and /msg. If you feel someone continues to post flagrantly off-topic nodes, then vote them down and then tell the monk why you did so. Better yet, offer a link to a better source for that information.

• Similarly, if you post a reply that essentially duplicates another monk's earlier reponse, don't rewrite history by considering your node. First off, it confirms the earlier monk's advice and second, you may have said things in a slightly different fashion, one that helps the idea click in the original poster's mind. (It's also a nice validation of your idea, if you think about it.)

• Finally, it's a simple fact that people new to the Monastery and to Perl will ask questions that've been asked before.⁴ Don't delete their nodes simply because the question is unoriginal. Vote it down if you must, but at least /tell the monk where to find the previous answers. Better yet, reply publically so the next initiate who comes along with the same question has a chance at finding the answer before posting.

• Parenthetically, I would like to point out why "no effort" and "not perl" are not valid reasons to delete nodes via Consideration.

  There are any number of reasons why a monk (or visitor) may post nodes that are not as well crafted as ones posted by more experienced ones: the poster may be new to Perl, they may not know our traditions, they may not be that familiar with the machine they're running Perl on, they may not be as experienced as you, they may not be posting in their primary language, they may be simply looking for pointers to information sources, and many others. In addition, you may not understand how it really does apply to Perl.

  In the past, the membership has responded to incomplete or poorly formatted nodes by providing links to the archives, the Friendly manual, and so forth. I think I'm pretty safe in saying that nearly all the members of various teams do not want to see that ethic change.

Yes, we have deleted and edited nodes in the past. We've also had misgivings about those actions, some expressed privately. The point is, we have these tools because we do need them from time to time. However, let's not use them instead of the ones we're supposed to be using. If you don't like a node, vote it down and then tell the monk why you did so.

Please only offer a node for the Reaper when it:

• Is unarguably and undeniably trollish.
• It is a true duplicate (e.g. the poster accidentally hit the Submit button twice).
• Contains code that is patently illegal or potentially risky to the Monastery. (Even then, we will probably obscure it until a consensus is reached.)
• Does not contain replies trying to provide (or at least point to) a technical answer.⁵
• Is *clearly* spam (e.g. product or service) advertising with no Perl-related educational content.
• Is *clearly* inflammatory, abusive, and otherwise over the edge of professional disagreement.
• Advertises (or links to) stuff we don't care about (e.g. warez, pr0n, and other non-professional material).
• Is so off-topic that there's no way in the world that anyone could be using a Perl script/program to implement it. (But ask before you Consider...just in case.)

Please do *not* offer nodes to the Reaper if it's:

• Not a true duplicate (e.g. it was just asked by someone else a couple of days ago.)
• Been asked before.
• Potentially not be as rude as you think.⁶
• Simply a so-called "useless thank-you" or "non-contributing" node.
• "not perl", shows a "lack of effort", or could be answered with a simple google search.
• Provides the same answer as a different monk in the thread.
• A technical, off-topic question that a) has replies and b) acknowledges the inappropriateness in some way, e.g. "Look, folks, I'm sorry, but I'm stuck on this. I don't know where else to turn.⁷"
• Attempting to rewrite history, e.g. the author requests the delete because it was a mistake *or* deliberately obscures/removes the original content.

Remember: these are only guidelines. If you're not sure if a node should be Considered, then please follow the directions in the FAQ and ask a more experienced monk before considering it.

Update: Also, please keep the same guidelines in mind when reviewing nodes under consideration. Don't trust the reason submitted by the considering monk. Review the situation carefully and make an informed choice. (If you don't have time, then please don't review the nodes.)

And if you feel a node should not be under consideration or are not sure, then vote Keep--especially if a Delete vote has been requested. Also, try to check the Reputation of the node before voting Delete. If it's not on worst nodes *OR* has replies, it will not be reaped.

Please do not request that the replies be re-parented just so a bad node can be reaped. That changes history....we don't like that (see above).⁸ </update>

If you would like to read more about the true purposes of the Consideration process, why it exists, and previous discussions about how it should be used, please review the following nodes:

• The Consideration FAQ)
• Friar
• Remember, before you consider, please, Please, PLEASE:
• Is nodereaper on worst nodes of note?
• Care and Discretion
• On using tact

As our fearless leader stated recently, we'd prefer the Monastery remain a place without a lot of hard and fast rules. We'd rather the Community policed itself, by exercising restraint and taking personal responsibility for personal actions. We'd rather not have to change the experience of the Many to account for the personal irresponsibility of a Few. However, we will do what's necessary to help everyone continue to enjoy the Monastery and learn from the wisdom of its members. If we can do this without code changes, all the better. If we can't, well...

On behalf of at least a few of the cleaning crew, thanks in advance...⁹

--f

Footnotes:

---

1. How concerned? Enough to threaten a variety of rants and/or seriously consider changes to the current system.
    
2. And, yes, I've been guilty of contributing to that as well. (Thanks for catching that, tye.) That's what led me to start thinking on this in the first place.
    
3. I guess I felt disappointed with the way that turned out because I thought it was a perfect opportunity to help someone grow a little and I always felt that we failed to fully take advantage of that opportunity.
    
4. This is one reason why I added a Welcome to the Monastery section to Tutorials. It was a small attempt to document the basic ideas in another commonly visited location.
    
5. This requirement may change when nodes can be more easily moved between various sections and replies are easier to reparent. For the moment, however, please consider the work of those that've already replied. They should have a chance at being heard, too.
    
6. Please see On Online Communication for some of my thoughts on this subject.
    
7. Um, before posting one of these nodes, please try using a decent search engine or asking for a good place to look in the ChatterBox.
    
8. And, yes, I've been guilty of this in the past as well. No longer...unless I truly feel it's necessary, such reparenting orphaned nodes.
    
9. And thanks in the present to tye, chromatic, and the others who previewed this node and offered their input (which is definitely incorporated). Thanks also to zaxo who's reply prompted the update and reminded me of another point I'd originally wanted to make.
    

[mirod]

I agree with the idea that reaping a node is serious stuff and that it should be done only in serious cases.

Editing a node though, especially when it requires only adding <code> or formating tags (gosh! why don't people just use the preview button and try to figure out why their post looks ugly?) is a much less serious matter. I still think that it should not be done without the node being considered and some edit votes cast on it (I usually wait for 3 edit and no keep). This is a simple measure to help preventing the power of editing to corrupt me: I only edit posts that other monks want to be edited, I don't decide it myself.

Changing the title of a node is a grey area. In most case a /msg to the author of the node, pointing out why a change in title would be nice, might be better than considering it.

Update: In any case, I think that the best way to get a post fixed is by messaging the author, as footpad did with this one actually ;--). Funny enough I did not remember Messaging authors of baddly formated posts by you which I posted a long time ago, but I guess I am consistent on this!

--
The Error Message is GOD - MJD

[dws]

Editing a node though, especially when it requires only adding <code> or formating tags ... is a much less serious matter. I still think that it should not be done without the node being considered and some edit votes cast on it.

I agree that there's a line, but when there's something obvious like missing <code> tags, or a closing markup tag, it seems like a waste of time and effort to consider the node and wait until enough people make a "well, duh. fix it." vote. I don't wait. I fix stuff like this when I see it.

I also, on occassion, change node titles. Usually, this is to fix obvious typos. On occassion, it's to make the node title either appropriate ("help me" isn't), or findable via search. I usually leave a note at the bottom of the post, and usually /msg the author. So far, nobody has objected, and i've gotten several "thanks" from people who hadn't thought about searchability when titling their post.

If there's a concensus among editors that this is over the line, I'll stop.

[Zaxo]

My first useless Me Too post!

I don't think any of us were born knowing this stuff.

I've been voting 'keep' a lot lately, is there anything more or better we should do?

After Compline,
Zaxo

[greenFox]

++ great node!

"Attempting to rewrite history, e.g. the author requests the delete because it was a mistake *or* deliberately obscures/removes the original content."

This is one of my personal gripes :) A lot can be learnt from a wrong response and an update as to what was wrong and why should be all that is needed. I don't see another way to discourage this kind of behaviour so I tend to just vote to "keep" them, though if I am feeling particularly grumpy I might down vote as well -especially if the content has been removed :)

Update: see this node ++ Tye for putting it so well.

--
Until you've lost your reputation, you never realize what a burden it was or what freedom really is. -Margaret Mitchell

[Juerd]

# "not perl", shows a "lack of effort", or could be answered with a simple google search.

"Not Perl" is in my opinion a very good reason for consideration if the post is about programming, but not about Perl. I assume PerlMonks is not the place for Javascript, Python, Ruby, C, Java, etcetera. Of course language comparisons are welcome, and people should be able to express something in another language if that's a logical way to present it. And of course off topic Meditations should be possible. But let's keep SoPW, Q&A and the many code dump places Perl-only.

"Lack of effort" is the good reason for consideration of nodes of people who try to get free custom scripts. I consider nodes that are "I need a script that..."-like.

- Yes, I reinvent wheels.
- Spam: Visit eurotraQ.

[chromatic]

Perhaps if "not perl" and "no effort" were being used responsibly, I could agree. As it is, when nodes such as My Home Script are reaped almost instantaneously, I (speaking only for myself and not for any other editor or god) am strongly tempted to disallow both. I've even provided code to prevent their use. (It has not been applied, and I suspect it will not be applied. The point was to demonstrate that I'm serious about the matter.)

Let me be clear: I do not see consideration as a way to rid the database of otherwise non-offensive nodes that *someone* thinks *may not* fit into one particular view of the monastery. You are under no obligation to provide a free program to anyone who asks. I'd rather let a few *potentially* off-topic posts slide than prevent the normal system of intelligent and considerate replies from providing adequate guidance.

I've warned certain monks about being overzealous in the past, and will continue to do so. I really don't want to go down the path of meta-consideration, and would prefer just to remove the privilege in cases of abuse.

I hope that footpad's word to the wise will prove sufficient.

[stefp]

"not perl" is very much a gray area.

As an example, consider my Re: stdout/err redirection, my recent post. It indirectly suggests that a perl wrapper may not be the best solution to do redirection. It is about a tool that I feel a good complement to perl: socat. So does this node should be removed because it is "not perl"? I posted it because I consider it of genuine value even in the perlmonks forum. Nevertheless, as a form of politness, I state clearly from the start that this is not a perl solution so people have information to skip my post if uninterested.

-- stefp -- check out TeXmacs wiki

[drinkd]

I have the oposite opinion. The best solutions usually require mixed language skills, and I think I (and perhaps others here) need to develop those skills.

Here is an example. There are MANY posts on PM about CGI scripts. Most of the books I have read on writing them, including Perl books, seem to agree that any page that wants to be even remotely high performance needs to have some javascript to avoid needless round trips to the server for poor form input and the like. PM has been a very poor place to learn how to write perl scripts that do this, partly because javascript discussion is looked down upon here. JS sites, on the other hand, don't show perl scripts like this because they want to avoid the Perl focus.

I had an application a few months ago where I wanted to use JS in a Perl script to re-sort a short list in a cgi form without requiring a round trip to the server. I needed to have the Perl script write the code to fill the JS array. Being somewhat new to both Perl and JS, I had much difficulty finding examples of how to do this, and felt there should have been much more in Supersearch about writing JS with Perl.

Just my 2 cents.

drinkd

[Juerd]

Here is an example. There are MANY posts on PM about CGI scripts. Most of the books I have read on writing them, including Perl books, seem to agree that any page that wants to be even remotely high performance needs to have some javascript to avoid needless round trips to the server for poor form input and the like. PM has been a very poor place to learn how to write perl scripts that do this, partly because javascript discussion is looked down upon here. JS sites, on the other hand, don't show perl scripts like this because they want to avoid the Perl focus. I had an application a few months ago where I wanted to use JS in a Perl script to re-sort a short list in a cgi form without requiring a round trip to the server. I needed to have the Perl script write the code to fill the JS array. Being somewhat new to both Perl and JS, I had much difficulty finding examples of how to do this, and felt there should have been much more in Supersearch about writing JS with Perl.

Everything you do in JavaScript, has nothing to do with Perl.
Everything you do in Perl, has nothing to do with JavaScript.

You may be using one language to generate code for the other, or maybe you found a way to use both languages together, but with normal CGI programming, you have strict separation of client and server side.

You needed some Perl to fill a JS array. Surprise: that has nothing to do with JS, only with its syntax. You would probably want to generate JS, which is (from Perl's view) just a string of code:

my @foo = qw(foo bar baz);
my $js = 'foo = new Array(' . join(', ', map "'\Q$_\E'", @foo) . ');';

Or something like that.

HTML and Javascript have nothing to do with Perl, but generating them can have. But when generating a string, it doesn't matter if it's executable code or just a string of repeated characters.

Generating Javascript code ("a string") with Perl is of course not off topic, Javascript itself would be. (Such as the recent question about closing a pop-up window. I'm not linking to it, because I hope it's reaped by now :)

By the way, have a look at Data::JavaScript.

any page that wants to be even remotely high performance needs to have some javascript to avoid needless round trips to the server for poor form input and the like.

That is HTTP, HTML, CGI and server maintenance related. It is NOT Perl related! CGI can be written in any programming language that can handle environment variables and stdin/stdout. Yes, you can write CGI programs in C, GW-Basic, Pascal, Visual Basic or even Brainfuck if you don't care about the environment variables.

- Yes, I reinvent wheels.
- Spam: Visit eurotraQ.

[mpeppler]

The "not perl" line is (as others have mentioned) blurred.

A DBI or database related question will often require a SQL answer. Quite often the SQL will be completely unrelated to the specific perl problem/script, but it is still a relevant answer.

I often step in to add additional information relating to Sybase and/or MS-SQL database programming because it enhances the answers given previously, and expands the knowledge of the user asking the original question. That is, IMHO, a reasonable use of the Monastery.

Michael

[Juerd]

[ something about SQL related answers]

Non-Perl answers should be allowed, but all m:iw/how [do[es]?|can] [I|one] @tasks in @non_perl_languages/ questions are not good for this monastery. If a user can't tell the difference, that should not be a problem, but explicit non-perl is wrong.

- Yes, I reinvent wheels.
- Spam: Visit eurotraQ.

[Rex(Wrecks)]

First off I agree with this post, and more, the spirit of it.

Being an Abbot I have been participating in the consideration process for a little while now. Most of my considerations are "Needs Code tags" or "Needs a readmore".

My questions are: Have the cleaning crew been messaging the people who are making questionable considerations? And if so what other actions/discussions have come out of that?

I don't believe I have, but if so I would like to know! That being the only way I can change my behavior. I guess what I mean is that I hope you guys have been at least informing people when you think their consideration may be out of line. My consideration habits are what I would consider conservative, but they are learned from what I have seen and experienced on the site, many new Friars might be doing what they think is conscientious and trying to help. I hope the effort is been made to guide them on a personal level as well as the broader level with nodes like this.

This community seems friendly enough that we should be able to work this out rationally, and I hope this post is a step in that direction.

"Nothing is sure but death and taxes" I say combine the two and its death to all taxes!

[DaWolf]

footpad++

I'd only add one more thing: unoriginal questions may be posted simply because TMTOWTAI - There's more than one way to ask it.

Each monk has it's own way to ask something and this could not be prevented, even with Super Search.

Regards,

my ($author_nickname, $author_email) = ("DaWolf","erabbott\@terra.com.br") if ($author_name eq "Er Galvão Abbott");

[mpeppler]

++ (and if I could I'd add the my remaining votes of the day to this post).

Michael

[tmiklas]

At first, ++!

When I look at the people here i feel small, very small. Before I've sent anything to PM (especially for the first time) I've thought it well few times and read all the answers with respect (for their authors and content itself) and appropriate attention.
Now I feel that I have grown up a bit ;-) and feel comfortable in such a great community... Anyway, english is not my native language and (yes...) I DO mistakes of every sort (and I'm really sorry for that), but who doesn't?
Few words about an XP system - it's the main feedback method, it's fast and simple... IMHO every single message (doesn't matter if it's a new thread or just next reply) brings something new, even a new point of view or (even) some fresh air :-) If it's really bad node, then --; that's the life :-) so I use my freedom with respect to it's power (votes).

There is much more to say... but I'd like to say thank you to everybody who read this node (and maybe this answer) and thought about it...
Thank you for this node, for being here for people like me...

Greetz, Tom.
* sorry for mistakes *

[PetaMem]

++ on this one, though I do not agree.

Why? Because this is the most rational, extensive and detailed explanation of an alternative view on the topic. I for myself, am now very very afraid to post some question/remark "ad hoc". Not because I am afraid it could be reaped, but I don't want to pollute PM.

The result is, that my read/write ratio of perlmonks has increased dramatically. I agree with you, that new monks may learn to study more before they ask something potentionally stupid or - worse - obsolete. Just because they haven't read the relevant "already posted/asked this" nodes.

I don't think, that it would have killed me, if some of my really dumb nodes were reaped instead of downvoted or ignored. In fact, in retrospect I'd be happy if that happened to some of them.

And this spans one argument where reaping might even be of use to those whose nodes get reaped: a) they're in some way protected from
- -ing but learn though. b) the signal/noise ratio is better for them. It might very well be, that at some 6/7+ level you aren't quite happy, that you've reached that level with 300 messages, while someone did with 50. (e.g.)

So then this brings us to the old(?) issue of being allowed to delete oneselfs nodes...

Just my 2 eurocents...

Bye
 PetaMem

[chromatic]

I disagree about reaping nodes improving the signal to noise ratio. An ostensibly lame root node that generates a handful of intelligent replies has produced good results. A reaped node with good replies leaves the good replies stranded, devoid of context. I find that more noisy.

[Aristotle]

I couldn't agree more with basically all of the post and have on occasion /msg'd monks when I thought their consideration was inappropriate, with a few pointers such as to aforementioned FAQ. My only question is with regards to:

Please do not request that the replies be re-parented just so a bad node can be reaped. That changes history....we don't like that.

What I would like to know is inhowfar that extends to replies to true duplicate root nodes. In such cases I frequently go back and consider the (usually very few) replies for reparenting to the good root node, reasoning that putting the replies back in context preserves their searchability value. As an irrelevant bonus, the reaped node is then free to silently slip into the bit bucket.

Is that bad?

Makeshifts last the longest.

[tye]

Yes, reparenting a node from one true duplicate to the other is fine. I believe footpad is talking about reparenting from:

    Some random node
     `--- A regretted reply
           `--- An informative reply

to

    Some random node
     `--- An informative reply

which is something I don't want to see.
        - tye (but my friends call me "Tye")

[Anonymous Monk]

.oO if only perlmonks had a Off topic section