Youssef M. Assad
youssef_assad@myrealbox.com) and is copyright 2003. Licensing is under the OPL(The Open Publication License); look it up, I'm not pasting it in here. I'll be happy to accept corrections. Hope you find it useful.
This document was written to provide a general set of guidelines for how to run a medium-to-large sized IRC channel effectively. While IRC in general is populated by thousands of smaller transient channels, there are larger ones which actually provide beneficial and/or desired common grounds; as such, it is one of the primary responsibilities of the channel operator to take decisions with the long-term survival of the channel as avalid forum in mind.
I am Youssef Assad, and I have had the honor of helping to run #egypt in Dalnet for a period of time. I no longer participate in this duty, seeing as I feel I can contribute more meaningfully to improving #egypt through policy statements such as this. Yes yes, I know phrases such as policy statement might frighten you off, but don't go away just yet. I'll try to tone down the language.
Given this background, it is natural that the ideas and opinions expressed in this paper cover #egypt on Dalnet, though I think much of what is said here will be applicable to other large IRC forums.
In my experience, IRC channels are categorized into two main groups:
#egypt obviously belongs to the second category. The conversation in it can therefore be expected to be diverse, and to cover things that some people are interested in and others aren't, such as relationships, sports, night-spots, and other interesting topics such as whether exor- sucks or not1.
On a common interest channel it is easy to tell what kind of conversation and people belong, and what type doesn't. If we're in #linux, then we're going to talk about linux. If we're on #islam, then we're going to talk about religion. If we're on #M0rgoth, then we're going to talk about things like how many times we've been dumped and whether Fosters is good or bad.
With common geography channels, things are less clear-cut and need to be explicitly decided and made public. For example, does #egypt tolerate sexual discussion on main? How about political discussion? Football flamewars? Harrassment? What does the channel consider to be harrassment to begin with?
When I say content, I mean any kind of communication; things people say on main is content. A person's nick also is content. The things one writes in the whois reply too.
A mission statement is a short paragraph which describes what the channel is, why it exists, and what its values are. For example, a hypothetical mission statement for #siberian-bossanova-lovers:
#siberian-bossanova-lovers is a channel located on the UnderwearNet IRC network. The channel was established to be an online central meeting place for all bossa nova fans in Siberia. We try to be fair, and we try to be inclusive. Since we are interested in bossa nova, we also consider discussion not related to bossa nova to be offtopic. We do not like people harrassing each other for any reason, and we try to maintain a clean and safe environment for Siberian Bossa Nova fans to chat.
Mission statements are originally something businesses and organizations use as their top-level planning tool, and to be honest it is overkill to sit and think up and agree upon a mission statement for a channel such as #egypt. At the same time, however, if there are to be channel rules, then it is worth thinking of the purpose of the channel in the first place.
Channel rules exist to communicate to the channel users what their rights and duties are in that forum. Some channels permit swearing on main; some don't. A normal user has no way of knowing whether a particular channel permits it or not without channel rules.
One point here is in my opinion extremely critical:
Channel rules apply to everyone, including SOPs, AOPs, voiced users, and normal users. Being operator is not a priviledged position that allows one to ignore rules, it is a position where one has a chance to help out in implementing the rules, enforcing them, and perhaps even formulating or changing them.
If operators are exempt from the channel rules this creates a sense of unfairness and this ruins the experience for many people.
An IRC channel is a form of social interaction; when large numbers of people interact, it is natural that conflict arises sometimes. Where there is conflict, there is a need for rules. This is exactly the same on IRC as it is in real life; no laws, no civilized society. No rules, no respectability.
That's none of my business.
Ultimately, it is the channel founder who ddcides how channel rules are determined. Some channel founders may prefer to involve the SOPs, some may also include AOPs, and in smaller channels even the voiced and normal users may participate.
Alternatively, the channel founder may decide the rules themselves. There is no rule that an IRC channel must be democratic. The only important thing is that the rules get decided on and made public.
channel rules are supposed to be based on what you think the channel is for and what its values are - remember I asked you to think of that?
The idea is to sit down and think of a set of simple statements which act as guidelines for behavior and which cover what you think the channel should be like. Let's take #siberian-bossanova-lovers' set of channel rules as an example:
This shouldn't be too difficult for one simple reason. For a channel to get as large as #egypt has, it means that it has been around for a fair period of time. When a channel matures like this, it develops its own culture, which is nothing more than a set of informal rules.
First thing is to put it in the channel topic and make it permanent. I know it's nice for the ops to get to change the channel topic line and to insert clever and witty and often meaningful words there, but that is really where the channel rules belong.
Is there an alternative to this? Yes, there is, although it is only second-best to placing the rules in the topic: have a channel bot onjoing /notice users with a listing of the rules. This is second best because the bot itself is not guaranteed to be online at all times, and because users may not receive the /notice or may not notice it. A channel topic is unmissable and a formal place for channel rules. Additionally, bots get hacked; chanserv doesn't.
Yep. I'm too much of an opinionated busybody not to have. Here you go:
Just my suggestion. This should make a good starting point.
I mentioned this earlier, but it is worth repeating:
Being channel operator is not a state of priviledge, it is a volunteer job where you are trusted to manage a channel according to its rules and policies. You are responsible for making sure people get their rights on the channel and that people remember their duties.
This one is fairly obvious; how can you keep things running the way they're supposed to if you don't know the rules?
Giving a voice is renerally - incorrectly - regarded as a way of bestowing prestige and priviledge on friends. This is wrong, and will lead to a sense of unfairness.
Technically, when a user has a voice (+v) it means that this person can speak on main when the channel is moderated (+m). The IRC protocol was originally designed with this feature such that on busy channels people could listen but not speak. People on such channels with voices were voiced for a reason, and that is that they had something to contribute and could be trusted not to abuse their ability to speak on a moderated channel.
The keyword here is trust. When an op voices a user, then this user will be able to speak on main when the channel is moderated which is usually when there are no operators to watch things. So the idea is simple:
Voice people who have shown themselves to be decent and constructive.
Voicing friends or members of the opposite gender may be nice but it is not what you were made operator for. Additionally, the number of voices in the channel should be small; if out of 100 users 92 are voiced then there is no point in moderating the channel when there are no operators online. I personally think that 5% is a fair figure; out of 100 users, 5 voices only.
Don't assume your role as operator until you know your script, have modified it if you need to, and know how to control it. There is nothing more pathetic than having your script kick and ban a user for doing something perfectly normal just because your script is misconfigured. An operator is supposed to look competent, and saying ``Sorry, that's my script'' gives the impression that you are not the master of your tools.
It is understandable for this to happen once or twice, but if you don't fix the script fast you really should deop yourself.
This one looks obvious, but it really isn't. In a well-coordinated channel, when a normal user violates a chanel rule and gets a kick, it happens sometimes that several operators place bans for the same person. when the ban masks4 differ, this means that the ban list contains two entries for one person, and this is a waste of resources5. In this example, cooperation is needed to know which ban to keep and which one to remove.
Another example is doing channel limiting with +l. Ideally, there is a channel bot which takes care of this. When for some reason a bot is not available of online, then one of the operators steps in and handles the limiting. Notice here that I said one. There is no need for 4 or 5 operators to take on this burden at the same time, and in fact when this happens then this can be considered a strange form of flooding; quarter of the screen if filled with people changing the channel limit. This is annoying.
This is uaually a case of ``know your script''.
This cooperation is also needed with other aspects of channel maintenance, such as having spambots. If there are 6 operators in the channel, then there is absolutely no need for 6 spambots. With such a large number of spambots, it is inevitable that their frequent joins and parts will flood the main channel window with join and part garbage.
Take these two examples and see how many others you can think of.
When an operator has to kick and/or ban a user, it is usually related to obnoxious behavior. It is very tempting in these cases to throw insults around - to be honest, some of users probably deserve it. While it is really a question of personal temperament, it is my personal opinion that the best way to deal with rude people is to be polite yourself when you are an operator.
When you look at the big picture, in a channel as large as #egypt you, as an operator, are setting a standard and an example. You will create more respect for yourself by not getting dragged into mudfights, and it is probably fair to say that it is your duty to maximise the level of respect for yourself since you represent the people running this channel. Looking at the even bigger picture, you represent the level of civility in Egypt's online community.
Lead by example.
Anger and provocation only creates more anger and provocation.
This is an open community. Like I said at the beginning, the only common interest people have in a channel such as #egypt is geographical proximity, so you are going to get all kinds of people in the channel. In such an environment, if we don't have tolerance then we don't have anything.
If you are a Britney Spears and Backstreet Boys fan6 and some user starts telling everyone how much Britney and Backstreet Boys suck, then you should be arguing with them either on main or in private; you should not be kicking them or intimidating them with your operator status.
Generally, the channel rules tell you when you should be getting rid of a user. There will be cases where someone deserves a kick for reasons not stated in the channel rules, but with a good set of channel rules this will be rare. If such a reason is found, it should really be added to the channel rules. There's no reason not to change the channel rules or add to them or remove from them so long as there is a good reason and so long as users are made aware of the rules.
There is no real standard for deciding whether someone knows IRC well or not, but there are certain indications which will tell you if this person needs to read a bit or not. My personal favorite is ban masks.
when you ban someone, you do it to prevent the person from coming back in. As such, you need to tell chanserv something about the user to enable chanserv to identify this user in the future to deny them access to the channel. Chanserv can look at several things:
Placing a ban mask on one of these things is inefficient; it is easy enough to obtain a different IP, for example, simply by disconnecting and reconnecting. Nicks are easy to change too, as are real names. an effective ban will take as many factors into account, in order to make it more difficult to gain entry.
Remember that no matter what kind of ban mask you place, if the person really wants to he can be back within 30 seconds. You're just trying to make it more difficult.
Using wildcards helps; my personal favorite kind of ban mask is this kind: ``*!*realname*@192.168.*''. The nick is the easiest thing for the user to change, so using it in the ban mask is not effective except for the most naive users. The wildcards (the `*') in the real name bit will match any minor adjustments the user makes there. making things just a little more difficult. The most effective part, however, is the 192.168.* part; this in effect matches any IP in the 192.168.* network7.
There are tons of other reaosns to know a thing or two about IRC, of course, but this is just the most obvious case to me. The best reference for IRC is, as ever, the formal specification which is contained in a document called ``RFC 1459''. Search for it on google but beware; it is very dry and technical, but it is a goldmine of knowledge.
New operators are needed from time to time. It is usually a good idea for the channel founder to be continuously keeping eyes out for new talent. Ideally, the normal user progresses to channel voice, and from channel voice to operator status. In a well-structured system, it is understood and a public part of the channel's policy that operators are selected from the channel voices; this has several positive effects:
Apart from the fact that it can seem unfair to channel voices if a normal unvoiced user becomes operator.
Thanks to Donald Knuth for the TEXtypesetting system, panasync for his splendid IRC client, BitchX, and to exor- for not slapping me with rotten trout.
This document was generated using the LaTeX2HTML translator Version 2K.1beta (1.48)
Copyright © 1993, 1994, 1995, 1996,
Nikos Drakos,
Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999,
Ross Moore,
Mathematics Department, Macquarie University, Sydney.
The command line arguments were:
latex2html -split 0 -ascii_mode -discard ./channel-ops-HOWTO.tex
The translation was initiated by Youssef M. Assad on 2003-09-20