PL: Email and Piazza Group PoliciesGuidelines for writing posts (in piazza group posts and in general).

What to do with a question

If you’ve got a question, you have several options for asking it: use the piazza group, email us, or come to office hours. As a general rule, questions with answers that benefit others should always go to the piazza group. The piazza group was designed for this purpose, and has several features that make posting questions easy and efficient:

Questions that you know are applicable only for you (and only such questions) can be emailed to the course staff. For example, a question on a grading issue, administrative requests etc.

Do not send homework files to the course staff! When we get them, we usually use the submission system to submit the file for you. Try to submit even if you’re late for a submission. If you have any issues that you cannot resolve, consult us, but please avoid sending us your solution.

How to ask a question

There is a good document by Eric S. Raymond how to ask good questions. Reading it is a good idea for this course an in general. (In case it’s not clear: this is for your benefit — you want to know how to ask good questions to maximize the quality of answers you get.)


Surely you know how to use email... However, you can almost always improve your style. In general, the points in this page apply for both piazza group posts and direct emails. They also apply in any other public forum.

It’s generally best not to email us bits of your code that aren’t working. 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.

Piazza Group

The piazza group for this class can be found at It is hosted on, and is available to all students. Note that you can configure your account to receive alerts whenever there are new posts. Even if you don’t, some important messages from the course staff will be sent as email notifications too.

The piazza group 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 forum. (Also, it is wiped on every semester.) In addition, remember that you can post anonymously, so that other students don’t know who you are.

Use the piazza group for discussion, questions, and comments related directly to class material. (For example, clarification of a homework, questions about lectures, etc.) In general, everything that is posted on the piazza group 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).

Posting code

This is the most important and least bendable rule. Code from a homework solution that you’re working on 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, or better, make your post private so that the staff can decide if it can be made public. 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 homework in progress.

Public posts and direct emails

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

Plaintext, MIME, and HTML in emails

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 particular, avoid emails that use boldface to point at some part of the text. Such extra typesetting are often lost in textual email clients, small phones, etc.

A few useful links on how to set up your mail client to send plain text emails for Gmail, Thunderbird, Outlook, Evolution.

Spelling and such

Don’t worry, you are not expected to spell correctly. Not in this cours at least. 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, please. (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.) Capitalization and punctuation are much appreciated too. This isn’t twitter.

Line lengths

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.


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 an email, it is important to include text from the previous one so that the person who reads it knows what you are talking about. Doing this correctly is a bit of an art that many 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 as is — but that’s something that your software should do. Partial context is therefore best when it precedes your reply.

And, of course, the signature from the email 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.