RKMR has kindly informed me that many of the regulars from the old EFNet #perl channel are now meeting on a new server: irc.infobot.org. I suspect that there is still a #perl channel on EFNet; however, when I wrote this document, I felt that it reflected the views of a majority of the regulars on that channel. As such, it is probably more applicable to the "new" #perl channel than to whatever has sprung up on EFNet.
Either way, I still feel that these are good ideas for
any technical channel, and I hope they continue to be
useful.
Please note that the original author of this page (Tkil) is, by his own choice, is no longer an active member of the #perl community. Therefore, anything mentioned here may have fallen out of date since he wrote it. He still believes that these are good principles to adhere to when talking on the channel, but he is less sure whether the attitudes of the regulars still concur with what he has presented here. And now, back to our regularly scheduled program...
Most of us here on #perl are here because we enjoy hanging out with other people who use Perl. Most of us enjoy helping others with Perl problems and with learning perl.
As with most free software support systems, however, the avalanche of repetitive and trivial questions starts to wear even the most dedicated helpers out. This is my attempt to reduce confusion, help others help themselves, and reduce burn-out on the part of the nice people in the channel.
Since we were running out of room in the /topic line for describing all the things that annoy the channel, here is a quick rundown:
Many people who arrive on #perl for the first time are confused by this restriction; they've only ever heard of Perl in its capacity to implement CGI-compliant scripts. They don't know that Perl is a full programming language that was around before the Web was conceived, and people use it for many different tasks.
The main reason that we exclude CGI and Web questions is a simple one: most of them are boring, trivial, answered elsewhere, and the vast majority are not about Perl. That's right. Most of them are about server configuration issues, CGI parsing issues, etc. The fact that the failing CGI script is written in Perl doesn't really matter; it's not a difficulty with Perl, so we probably can't help.
Rather, most of us probably could help, but if we wanted to help with web and CGI questions, we'd hang out on #CGI or #web or #www. But we're on #perl, because we prefer helping people with Perl.
(For a somewhat stronger take on the "no CGI" rule, take a look at what thoth (a.k.a. Tom Christiansen, Perl consultant and author) has to say about it.)
So where can you go, if you have a problem with a CGI Script written in Perl?
Through the tireless orchestration of Tom Christiansen and a cast of thousands of contributors, Perl is possibly the best-documented programming language available today. As such, please take advantage of this resource before asking us a question which is answered there.
Note that we don't usually mind if you come onto the channel and ask: "Where can I find information about __________". We understand that the Perl documentation set is large, and that it can take a while to get familiar with its layout. The questions we don't like are something like: "Tell me about _________, I'm too lazy/hurried to find it in the docs". This is asking us to parrot the documentation for you, and this annoys us.
So where to start? Well, all installations of Perl should have a functioning "perldoc" program which can display the documentation. On Unix systems, "man" should also work. If you prefer, this documentation is available in HTML and other formats for printing or reading on-line.
At last count, perl ships with more than 1300 pages of documentation. That's a lot, and it's often intimidating. I don't have any sure-fire tactics for navigating the docs; all I can recommend is reading the FAQ (which will give you many pointers as well as directing you at the appropriate documentation page for more info) and then maybe keeping the "perltoc" document open in a program which can do searches. I use XEmacs + manual-entry.el; a web browser window would probably work just as well.
Remember that the FAQ was copied onto your local disk as a part of the Perl installation process. You can read it with "perldoc", just like the rest of Perl documentation. Doing "perldoc perlfaq" will get you a quick table of contents -- it's broken into multiple parts to make browsing it more convenient.
If you have the "grep" utility, you can use it to search through the documentation set that comes with Perl. To locate the directory where these were stored in your Perl installation, you can execute the following one-liner (in unix-like shells):
perl -MConfig -le 'print "$Config{installprivlib}/pod"'
Again, if you ask us where to look for more info, we're generally happy to help. If something in the documentation confuses you, or you can't understand it, ask us -- we'll try to explain it, and if it really is a problem with the documentation, Tom would love to hear about it.
Also known as the "No 'K3wlt0k'" prohibition, this is in place as a courtesy to the rest of the channel. To us, IRC is all about communicating; when you pepper your messages with non-standard words and entities, you are hindering communication because we have to slow down and parse what you are trying to say. Is this really how you want to treat people that you're asking help from?
Particularly annoying (to me, at least) are modifications that don't have significant savings in typing or reading time. Using "u" instead of "you" only saves two characters of typing, while making 50 or 100 people have to read your line twice. As a counterexample, most of us won't complain if you use "q" to abbreviate "question".
Totally worthless modifications, such as using numbers for letters, will usually come very close to earning you an instant kickban. Nicknames built with these constructions will predispose most of #perl to think that you're an idiot. You have been warned.
In the end, though, realize that we are not impressed by your ability to phrase your comments in a well-nigh incomprehensible manner. Most people who use this text style are the ones asking us for help; the more annoying your messages are to read, the less help you'll actually get.
This rant is not meant to intimidate non-native speakers of
English, or even people who don't speak English at all.
#perl is a global community, and we understand that not
everyone speaks English. We can usually distinguish between
"k3wlt0k" and sincere pidgin English. If we do accuse you of
"kewltok", please just explain that you are not a native
speaker, and we'll do our best to try to communicate with you
and to help you solve your problem -- maybe even in your native
language! While most EFNet IRC channels speak
English by convention, many of the regulars on #perl
are fluent or native speakers of other languages. It never
hurts to ask!
It sounds like a good idea: make the text transmitted over IRC a kind of basic "enriched text format", adding information to your transmission through precise use of these attributes.
Instead, it's used almost exclusively for gimmicks (the "bold colon"), automated messages (the auto-away messages), and general channel spamming ("look, a colored rose!"). As with kewltok and auto-noise, this tends to annoy the channel regulars, so we ask you to please not use it.
This is compounded by the fact that these extensions to the IRC datastream are not standardized, and not all clients support them in the same way (if at all). This can cause various garbage characters to appear on people's terminals, so please just don't use it.
Note that IRC, being primarily a text medium, has adopted some conventions from Usenet regarding essential markup: you can have *bold* or /italics/, an even _underlines_ if you like. (We also support the full stable of emoticons.) We occasionally borrow the markup of SGML or HTML: <silly>I hear Apple is going to start producing an iPerl.</silly>. If you use these ideas, use them sparingly; most of us are fully capable of understanding plain English, and enjoy conversing in simple text.
Many current IRC clients (BitchX, mIRC) have the ability to keep track of how long since you've last sent a message, and will helpfully inform all your channels that you've been idle for 10 minutes. Ask yourself:
Does anyone really care?
Think about this: #perl typically has 80-120 people on it. Every time you send a message to the channel, you're asking a hundred people to pay attention to it. How many of them really need to know? As with the "kewltok" mentioned above, the people most often guilty of this offense are exactly those people who are asking favors of the more experienced channel regulars. Please don't annoy people you're asking for help; it usually doesn't work very well.
(It doesn't help that most of these auto-away messages are particularly gaudy with bold and colors, which just makes them that much more annoying.)
Note that this prohibition extends to most forms of manual "away" settings as well. Even if you set yourself to be "/away" manually, does the whole channel really have to know? The usual exception to this rule is a very small action, such as: "/me &", using the unix character "&" to indicate that one is "backgrounding" and thus not paying attention to the channel.
This one is short and sweet. Please don't paste more than 4 or 5 lines to the channel at once. If you absolutely must paste more (up to about 10), ask on the channel first -- and don't do it if people say "no".
#perl often has various well-known Perl personalities and book authors. They are here because they are donating time to helping people, and because they enjoy the camaraderie and friendship of fellow Perl-philes. They are not here to answer all questions instantly.
As such, please don't send private messages to them about your problems. If you address the whole channel, then you get many more eyes to help you. If your question doesn't belong on the channel, it's likely that we wouldn't be pleased to get it in /msgs either.
If someone invites you to /msg them, that's fine. If you really feel you would be welcome to /msg someone, send them a small one first: "hi, do you mind if i /msg you with a problem?" Don't be offended if the answer is "yes, i mind. please keep it on-channel".
purl is our local infobot; she has much useful knowledge. If you ask about the location of something, the meaning of an acronym, or what section of the perl documentation to find something in, don't be surprised if she /msg's you with the answer.
Along with this, please don't play with purl on-channel. She can answer queries just fine over "/msg", so please don't flood the channel with a bunch of attempts.
This (perhaps unfortunate) rule is mostly just a fact of life on
EFNet IRC. Channel regulars can feel free to
talk about web, use kewltok, or do whatever. The other channel
regulars will often shut that person down. It usually balances
out. But please don't spend too much time and effort whining
about it.
On the other hand, being a channel regular does not give anyone the right to be preemptively rude. If a channel regular is abusing you (and you think you didn't earn it), just let it flow for a while, then carry on with your normal existence. The channel ops are humans too; we get annoyed and irrational sometimes.
Of course, this document does not reflect the opinion of the entire #perl channel, or even of all the regulars. I'm known to be fairly moderate on the channel regarding these rules, and this was my attempt to write down some guidelines that, if followed, should have others making you welcome on #perl.
Happy hacking.
Thanks to the following people for their input and help in forming this document, and for making #perl an interesting and rewarding place to hang out:
(Omission from the above list has more to do with my worthless memory than with any disrespect meant to the participants of #perl. In particular, concrete suggestions of improvements to this document should guarantee you a slot here -- if I missed you, please accept my apologies and send me mail complaining about it. Thanks! :)