Net Etiquette

The Internet (or 'Net, or Net) is a network formed of many different smaller networks of computers. However, to see it only as a set of computers is misleading, because most of those computers are being used by human beings. Knowing how to interact with a computer is an important skill, but knowing how to interact with other people who are using computers requires some additional considerations.

The Internet can be divided, roughly speaking, into several different protocols, or agreed-upon means of exchanging information. These protocols include SMTP (electronic mail transfer), HTTP (hypertext transfer, for web pages), IRC (Internet Relay Chat), NNTP (network news transfer), and so on. Computers use these protocols to exchange information with each other -- but they do so at the behest of their human operators.

As humans, we select software which allows us to communicate with other humans (or computers) in whatever fashion we find most convenient. The software gives us an interface -- a "way in" -- to what we often perceive as a location. We speak of "web forums", for example, as places where people can "go" to "talk" with each other. Likewise, we have "news groups", "mailing lists", "chat rooms", etc. Once we have mastered the basic features of the software, we see all these things as places where there are other people, to whom we can talk. We use vocabulary which mimics our corporal experience -- "go", "talk", "say" -- even when we aren't actually moving around or using our voices.

Just as people in the "real world" interact with each other in different ways, there are similar interactions in "cyberspace". People agree, disagree, argue, like each other, dislike each other, form friendships, compete, help, hinder, insult, titillate, etc. And because people can "meet" in virtual spaces more easily than they can in the real world (there's no need to get on a jet and fly to Singapore to "meet" with your Singaporean friend), these social interactions can happen extremely quickly.

Group dynamics are also extremely important. "Places" where people "meet" together often develop group characteristics which are unique to those spaces. An AOL chat room has a very different atmosphere than a Linux web forum, which in turn is very different from a mailing list about cheeses. Yet, there will be many aspects in common. This page attempts to describe some of the common characteristics of virtual communities, their rules (written or unwritten), and a rough suggestion of ways people can interact with each other more productively.

A guide to social behaviors is called etiquette. A guide to social behaviors for the Internet is therefore called net etiquette, or netiquette.

TableOfContents

1. General Rules

1.1. Listen before you speak

Your attempts to talk with an existing community will be received much more readily if you adopt a style similar to that of the other members of that community. In addition, if there is a heated discussion going on, you're not likely to get the full attention of the community.

So, in order to fit in, the first step is to listen to what's currently going on. Are they arguing about something? Wait a few minutes (for interactive forums like chat; longer for mailing lists) and see if it dies down a bit. Meanwhile, take note of what language they're speaking; what dialect of it, if any; whether they use proper spelling and punctuation and grammar, or whether shortcuts, abbreviations, or replaced text are the norm; and so on.

If a community is speaking English, you should speak English, to the best of your ability. If they're speaking French, you should speak French. If they tend to use proper spelling, then you should conform, or they're going to receive you poorly. Using abbreviations like "R" for "are", "U" for "you", "pls" for "please", etc. will earn you a great deal of hostility in some communities, but is perfectly acceptable in others.

When in doubt, you should definitely exert the effort to speak as clearly and as formally as possible. It's far, far better to use overly formal language than slang. You can always relax your grammar and spelling once you know where the lines are drawn.

1.2. Don't spam

Spam in this case covers a few different actions:

• off-topic announcements intended to earn a profit
• frequent repetition of your questions to try to get more attention

Both of these things are considered serious offenses by most communities; especially the former. Most communities that have any sort of access controls will use those controls to evict you at the first sign of commercial spamming, with no discussion or forgiveness. Many communities will take similar actions if you post URLs that earn you virtual resources (fame, fortune, "points") in any sort of online game that counts URL clicks -- that is also a form of profit for you.

Repeating a question should generally only be done if you're completely sure it was missed the first time. This means you need to wait a considerable length of time for replies before getting impatient. There is no general rule for how long this should be; it completely depends on the community.

Also, repeating the same question verbatim is considered bad form. It shows that you are not taking any initiative to resolve your own problem, or to add to the discussion. You should be spending the time between repetitions doing your own research into the problem, and adjust your question based on what you've learned. For example, "I see on <paste URL> that I can't put the foo directly into the bar, but is there any way I can work around that? I really need to put the foo somewhere."

1.3. Don't troll

Trolling is often a touchy subject, especially since it's so difficult to define. In a nutshell, a troll is a troublemaker -- someone who starts arguments for fun. Going into a community about banjos and saying how much better guitars are, compared to banjos, would be one example of trolling. But trolling is often far more subtle than this, and perception of trolls is quite subjective.

Trolls usually hang around in the larger communities, because they crave the largest possible audience. In smaller communities, they're a rare sight. Some of the common trolling techniques include:

• advocating something that competes with the target community's focus (guitars vs. banjos, Windows vs. Macintosh, BSD vs. Linux, ...)
• pretending to have a problem you do not actually have (technical, medical, etc.)
• consistently inappropriate, off-topic discussions, often involving minority group slurs, political issues, religious beliefs, etc.
• isolating one member of the community, finding issues that will upset that person, and then proceeding to do just that

A related topic is metadiscussion of the community itself. This can be tricky to handle correctly; it's one thing to point out a problem that you see, but quite another to launch into a dogmatic sermon about how people should change their behaviors in order to suit some subjective ideal. Attempting to change a community, or its long-standing beliefs, is likely to cause strife.

1.4. Be a partner, not a burden

This applies mostly to communities that offer supportive advice, but it can be generalized somewhat. When seeking assistance with something, you should do your own "homework" on the issues before asking for help. Make sure you've read the appropriate documentation, as well as the community's general help files, if any (see the various sections below...). If your problem is the sort that can be approached by experimenting, make sure you've actually tried a few things yourself, and be prepared to show exactly what you tried, and what the results were. (Obviously this wouldn't apply to irreversible medical procedures, etc.)

Nobody wants to waste time helping someone who's a burden. Of course, the line between "burden" and "novice" is subjective, and different communities (and often different people within a single community) will draw that line differently. Listening to other people's questions for a while before you ask yours would be one excellent way to get a feel for how much of the work you're expected to do on your own (see the first section above).

Always do the best you can on your own. If you're intentionally being lazy, using the community as a substitute for reading a manual you know you are supposed to be reading, you'll earn a lot of animosity.

Another way people can be a burden, in addition to not doing their own research, is by failing to speak well enough to be understood. Often, someone may not speak the community's natural language (English, Spanish, etc.) well enough -- and in many cases, the community will make allowance for that, if it's obvious that you're putting forth the best effort you can. But if it's clear you're just being lazy, fewer people are going to be willing to help you.

1.5. Details matter

Nothing is more frustrating than trying to solve a problem that isn't clearly defined. Even worse, a problem which has been misrepresented will give you nonworking answers at best, or earn you a great deal of hostility when the misrepresentation is discovered.

Avoid asking generalized questions when you have a specific problem. Don't assume that your problem falls into some larger category and then give a "simplified" example from this category you've selected. There's a very good chance that your problem is not what you think it is, so you should always say exactly what you're doing.

Make sure you have stated your goals, or your problem, clearly. Don't assume that the community knows what you're doing -- they won't, unless you tell them. Other people can't see what you're seeing on your computer screen -- unless you show them. Other people may not be using the same type of computer you are, or the same software. They may never have encountered whatever problem you're seeing, or they may not recognize it without seeing the actual error messages or output that you're seeing.

Give all the necessary background information. If this is a computer problem, tell the community what kind of computer you use. If it's a software problem, tell what software you're using (including version numbers where possible). If it's a car problem, tell what make and model and year the car is.

If you're looking for help with code, be sure you show the actual code you're using. Don't retype the code into the software you're using, because you might accidentally mistype it. Always paste it verbatim. (But be sure to respect your community's guidelines regarding large messages.)

1.6. Those are people, not robots

Sometimes it's easy to take other people for granted. This is even easier when you can't actually see or hear the other people, but instead, only the words they've written. Nevertheless, the people who are answering your questions or discussing your favorite topics with you are people, and they're subject to the same problems and limitations that you are.

Never demand answers. You aren't entitled to anyone else's help on the Internet unless you're paying them for it, in which case, you'd probably be talking with them directly, instead of through a web forum or chat room. The people talking with you are taking time out of their own busy lives to do so, and they may not have the time or the inclination to give you more than a brief response. The more demanding you are, the less likely it is that people will want to speak with you. (Another case of this is when someone asking for help says "I'm in a hurry." Well, tough shit. Improper planning on your part does not constitute an emergency on ours.)

2. Rules for IRC

Internet Relay Chat (IRC) channels are communities built around specific topics, often technical ones (but not always). IRC clients connect to an IRC server; people choose "nicknames" to identify themselves. Messages are sent by the client to the IRC server, which then repeats the message, sending it out to every person (client) connected to the same channel. As such, messages are lines of text, limited in length (usually about 200 to 250 characters). They are sometimes stripped of color and other markup (but sometimes not, depending on the channel).

"Chatting" using this software is near-instantaneous; messages sent by one client are seen by other clients very quickly (in less than one second, usually). As such, many people read the channel's messages continuously for extended periods of time, giving you an excellent chance of having your messages seen within moments. This differs greatly from mailing lists or Usenet news groups or web forums, where your messages may not be seen by other people for hours.

As such, IRC channels have evolved certain specialized rules of etiquette to keep the channel (and its members) healthy:

2.1. Know your client

It's discouraging to have to support other people's widely disparate IRC clients in addition to answering whatever questions they actually had when they entered. If you don't understand how your IRC client works, then you place a double burden on other people in the channel. (An exception to this is a channel dedicated to your particular IRC client, which is where you should turn for help if you don't understand the documentation.)

Some IRC clients, and some "scripts" that people use as add-ons to their clients, do things that are deemed undesirable by some channels. For example, in many channels, features like "announce when I go away" or "auto-rejoin if I am kicked out" are considered rude.

If you don't have a good technical understanding of how IRC works, you should definitely avoid clients or scripts that look like they were written by "hackers" (the bad kind). Anything with AlTeRnAtInG CaPiTaL LeTtErS, for example, should send you away screaming. (This is not to say that such programs have no place; just that, if you're reading this document, you probably don't want to be in those places.)

Take the time to read your client's documentation, or at least the first parts of it. Learn how to connect to various IRC server (or networks) and channels, and how to switch among them. Learn some of the various options available, and in particular, any options your client sets that are "unique" or different from other clients.

2.2. Read the topic

Each channel has a persistent "topic", which is a string of text that is intended to be read by everyone in the channel when they enter. Depending on the channel, the topic may give you URLs for frequently asked questions documents, or other special instructions that you need to follow.

Most IRC clients will display the topic when you enter the channel, although sometimes it gets lost in a flood of other text (lists of usernames, etc.). Often, you can read it again by typing /topic in your client -- but when in doubt, you should read your client's documentation, as suggested above.

If your channel has a FAQ (Frequently Asked Questions), be sure to read it before you ask anything. Asking questions which are covered in the FAQ is considered lazy or rude. There is a good chance that your question has already been asked and answered many times, and the FAQ will often have the answers you need.

2.3. Just ask the question

It's irritating when people ask "Is anyone here?" or "Can I ask a question about _ _ _?" If you have a question, and you've followed the advice above, then just go ahead and ask it. If nobody answers, then wait a while. If the channel doesn't want to entertain questions about whatever you asked about, they'll tell you (and often they'll suggest a place where you can ask such things).

One of the main reasons why IRC channel members dislike questions like "Who can help me with _ _ _?" is that answering "I can" is usually followed by a barrage of private messages from the asker. Which leads us to:

2.4. Ask the channel, not one person

Never ask just one person in the channel a question, unless it's truly a private question for that person that you wouldn't want anyone else to see. A channel usually has many people who can answer your question.

• If you send a private message to someone, and (s)he's away from the computer for a while, you won't get an answer.

• Questions sent to one person may not get you the best answer, because someone else may actually have a better understanding of the topic than the person you chose.

• People who receive privately asked questions are unlikely to want to answer them, because it's a waste of time and effort to answer a question for just one person, when the question and its answer could instead be asked in the channel, where everyone will benefit from it.

This applies most strongly to private messages (sent with the /msg command or its equivalent, depending on your client), but it also applies, to a lesser degree, to questions that are asked in the channel, with one person's name on the front of them. "Demanding" a response from one particular member of a community is not likely to be received well.

2.5. ... unless it's a chatbot

Some channels have AI (artificial intelligence) programs called "chatbots" or "bots" to answer questions or to dispense information. Sending private messages to bots is encouraged, because the bot has unlimited patience (unlike its human owner), and anything that the bot can teach you is one less question that the people in the channel will have to deal with.

Learning how or when to speak to a particular bot will take some time and experience; most of them are extremely simplistic and only answer "questions" that are composed of special key words. The best way to learn this is to observe other people doing it, and then to experiment yourself. It's best to perform these experiments using /msg (or your client's equivalent) instead of bothering the whole channel with them.

2.6. Don't flood

Many channels have guidelines on how many lines of text in a row you can send before you are considered a nuisance. The number varies widely, depending on the channel and how active it is -- the larger and more active the channel, the lower the threshold of "flooding" will be. When in doubt, ask before you paste large amounts of text directly into an IRC channel.

There is a fine line between providing necessary information to describe your problem, and flooding. Because IRC is near-real-time "chat" with other people, information is often pared down to the bare minimum, to save time. Providing copious amounts of detail that may turn out to be irrelevant, while good on many mailing lists, is frowned upon in many IRC channels.

If your problem requires showing lots of information (for example, 10 lines of code in a program you are working on), then you should put the information on a web server somewhere and give a URL to it -- but only do that after you have adequately described the problem! Coming into an IRC channel and saying who can help me with http://paste.site/paste123456 with no further description is a huge turn-off. (This is compounded by the fact that most such pasted problems will be hundreds of lines of code instead of ten lines....)

Trim your problem down to a manageable size. If you have a 100-line program that is misbehaving, but the first 50 lines of it are just displaying a menu, try removing those 50 lines (from a copy of the program), and see if it still misbehaves. If it does, then you've chopped the problem in half! Continue chopping away parts of the program that look like they're not related to your problem, until you have found the smallest possible program that demonstrates the problem; then ask about that. (Quite often, going through this process will actually help you find the problem yourself, and then you won't even have to ask.)