CSU660 Mailing List Policies

If you've got a question, you have several options for asking it: use the mailing list, email us, or come to office hours. As a general rule, questions with answers that benefit others should almost always go to the mailing list. Questions that apply only to you (and only such questions) should be emailed, as should anything that you don't want other students to know about. Don't hesitate to use the mailing list, and don't be embarrassed to ask something in public — we've all asked stupid questions before and will do so again. As trivial as your question may be, there are very likely others who would want an answer too.

Everyone knows how to use email these days. However, you can almost always improve your style. In general, the points in this page apply for both mailing list posts and direct emails.

It's generally best not to email us bits of your code that aren't working. (If the code in question doesn't relate to a problem set, see the section about posting code to the mailing list, which is the appropriate action to take.) Office hours exist so you can get more in-depth help. However, if you must mail code, make sure you do it well: it should be indented properly and commented adequately, the difficulty you are having should be carefully explained, etc. Do not email code as an attachment, please. Just put it in the body of the message.

The mailing list for this class can be found at http://groups.google.com/group/csu660/ (send mail to csu660@googlegroups.com). It is hosted on Google Groups, which means that it can be used in a number of different ways. Some of these may only be available if you have a Google account. This should not be a problem: it is best to stay with the default email delivery, this way you are less likely to miss important information. This also means that posting on the mailing list is getting to many people and you should not use it for irrelevant topics.

The mailing list is accessible only to people in this course, invisible to the rest of the world. You are safe in general from having your words archived forever for all to read, unlike a public mailing list. (Also, it is wiped on every semester)

Use the mailing list for discussion, questions, and comments related directly to class material. (For example, clarification of an assignment, questions about lectures, etc.) In general, everything that is posted on the mailing list is important enough for everyone to read. If a conversation “thread” drifts away from relevance, you should consider a different medium, or taking it off-line (personal emails).

This is the most important and least bendable rule. Code relating to problem sets should never be posted, no exceptions. (Sample expressions for the sake of questions and discussions are fine though.) Infractions are generally considered violations of academic integrity and thus can carry severe punishments. If you are unsure if a posting is ok, don't risk it: ask. This does not, however, prohibit asking questions about why a bit of code acts in a certain way, as long as the topic in question comes from lecture or section, not a problem set.

Make sure you use each medium for what it is good for. When a public discussion on the mailing list becomes private, you can switch to direct emails. But be careful of going the other way: it is considered rude to post in a public forum something you have received in private email. You can do so only if both parties agree on the move.

Don't worry, you are not expected to spell correctly. You're not even expected to run a spell checker before posting (although we certainly won't complain). However, this is not an excuse to act like you've never seen the English language before. Try to avoid being completely lazy (standard acronyms such as “IMHO” for “In My Humble Opinion” are fine, but things like “ur” for “you are” make the reader spend far more time deciphering your post than what you save by not having to type as much), please. Capitalization and punctuation are much appreciated too.

Like your code, posts should not have excessively long lines. This generally means 72 characters per line, 80 maximum. If your software can't handle this, get new software or expect to be ignored. It's just plain annoying for the reader to have to deal with long lines.

Some email clients default to sending MIME-encoded, HTML-based “styled text”. This is an abomination! (Well, how about “severely annoying”?) Anyway, all course-related posts and emails should be in plaintext only.

In addition to meeting the line length criterion above, there are a few other recommendations for signatures. Short signatures are best, and anything longer than four lines is generally inappropriate (no fancy ASCII art, please). Also, please try to include the correct signature delimiter, which is two dashes followed by a space on a line by itself. Some programs do this automatically, while in others you have to include it in the signature itself.

When replying to a post, it is important to include text from the previous post so that the person reading knows what you are talking about. Doing this correctly is a bit of an art that some people seem to have difficulty mastering. In addition, there is often much debate about quoting. However, regardless of your personal feelings on the matter, we expect you to abide by the guidelines that follow.

One of the important tasks is removing, or “snipping”, the part of the original text that you are not replying to. Also, if the text you want to quote is especially long, you may want to delete it and instead include a brief summary or something to remind the reader of the topic. In addition, you should put your text below the quoted text. Although some people prefer putting the quoted text at the bottom, this is considerably harder on the reader. It makes some sense if you want to leave the original post for context context in — but that's something that your software should do. Partial context is therefore best when it precedes your reply.

And, of course, the signature of the post to which you're replying is almost never relevant, so you should almost always be sure to snip it off if your software doesn't do that automatically.

Another thing that makes it easier for the reader to follow the flow of a discussion is the fact that most reader software can figure out what is a reply to what and make a graphical representation of the conversation. They do this by using some ugly-looking headers (Message-ID: and References:), which means that you can't just pick any post to reply to, even if it has the same Subject:, nor can you send out a new post and just retype the Subject: line.

In addition to quoting an appropriate amount of text, you should keep the “attribution line” at the top of the article, so the reader knows who said the text you're quoting. It can be very confusing to see quoted text without knowing who wrote it.