This is from Prof. Jason Eisner to his first-semester, first-year
CS graduate course.  I recommend spending some time on reading this and
applying what's applicable and understanding what's analogous

--CB

In CS 400, you are practicing writing the kind of research papers that
you will submit to conferences.  So don't assume that I am the reader!
Assume that your paper is being read by someone who has never heard of
CS400.  This means you should:

- Introduce the problem you are solving, and explain why it is
important.  (This is essential if you want people to read your
work!)  Some of you did this, and it improved your papers a lot.
Typically the motivation and introduction take up about 1
single-spaced page in a 7-page conference paper.

- Don't refer to your friends by only their first names.  :-)

- Use an appropriate writing style for a conference paper.
This should be clear and simple, not too informal but not
stuffy either.  The CS400 "Getting Started" page has

This level of detail is also necessary for the reviewer to
evaluate whether you did your experiments correctly and whether
your conclusions are justified.  For example:

+ Be precise.  A few of you were occasionally confusing
built.

+ Don't just say "edge detector"; say which edge detector.
It might matter.

+ Don't say "the data in /u/jason/..." -- that directory is
not available outside URCS.  Instead, name the UMIST Face
Database and give a citation so that the reader can find it.

+ Don't assume that the reader knows which images were
used for training and which were used for testing.
Explicitly say: "Faces 1r, 1s, and 1t, comprising a total
of 144 images, were reserved for testing."  They can't
replicate your results unless they know this.

+ If the reader might be unfamiliar with your tools or data,
then say enough so that he or she will be able to notice any
possible problems without having to read everything in your
bibliography.  (For example, if you used a machine learning
algorithm, then say how much training data you had -- then
the reviewer can easily tell whether you had "enough" data
for that method to work well, in her opinion.)

Some LaTeX issues:

- Variables should be typeset in math mode, just like more
complicated expressions.
Wrong: The x and y coordinates
Right: "The $x$ and $y$ coordinates"

- Learn how to use the \figure and \table commands to produce
"floating" figures.  This means that the figures will appear
nearby in the text, where the reader can find them, but they
may be moved a little bit so that

- Also learn how to use the \caption command to put captions
on your figures.  The caption can summarize the point of the
figure and explain how to interpret it.  This is convenient
for the reader.  It also allows you to omit some of these
details from the main text, although the main text should still
direct the reader to the figure at an appropriate time.

- Learn how to use the \label and \ref commands to refer to
figures, equations, etc., by number.

- Learn to use the \cite command to refer to entries in your
bibliography.

Writing problems:

- Have a friend read your report to look for problems with the
writing.  Your friend can tell you where you are not being
clear.  If you are still learning English, your friend may
also help find your grammar errors.

- For those of you who are still learning English, the
most common problems involved articles and determiners
("a," "an," "the").  You may want to review the rules

When doing technical writing, it can be especially hard to tell
the difference between mass nouns ("face orientation") and count
nouns ("the neural network").  Hint: you can guess that "face
orientation" is a mass noun because it is an abstract area of
research.  Also, it describes an activity (the verb "orient" +
the noun ending "-ation"), and activities are usually mass nouns.
You can guess that "neural network" is a count noun because each
network is a separate object: you can compare 3 different neural
networks.

http://www.bristol.mass.edu/Department_Pages/Quest_Writing_Lab/grammar/articles.htm
http://www.utoronto.ca/writing/l2the.html
http://owl.english.purdue.edu/handouts/esl/eslart.html
http://owl.english.purdue.edu/handouts/esl/eslcount.html
http://owl.english.purdue.edu/handouts/esl/eslcount2.html
http://www.aitech.ac.jp/~iteslj/quizzes/grammar.html
http://webster.commnet.edu/grammar/determiners/determiners.htm
http://webster.commnet.edu/grammar/noncount.htm

- Some of you who are learning English also had problems with verb tense:

When you are talking about what you did, use the past tense.
Don't forget and leave it out!
When you are talking about the properties of the problem, use
the present tense, because the problem still has those
properties.
should use the past tense if you think the system is dead
("Version 1 of my program WAS 1000 lines long and ACHIEVED 9%
accuracy"), and the present tense if you think of the system
as still in use ("The current version of my program IS only
3 lines long and ACHIEVES 89% accuracy.").  The most important
thing is to be consistent.

Here are some pages about verbs for ESL users:
http://www.bristol.mass.edu/Department_Pages/Quest_Writing_Lab/grammar/verbs.htm
http://owl.english.purdue.edu/handouts/grammar/g_tensec.html

And some miscellaneous things:

- Some of you did an excellent job of including images that showed
the results of different stages of your algorithm.  This was
tremendously helpful.  A picture really is worth a thousand words.

- I'm afraid most of you violated the licensing restrictions on
using the UMIST Face Database.  (The authors of the database
require that you cite a paper from their group if you use the
database.)  I did warn you that there were licensing restrictions
and told you where to find them ...

I won't turn you in this time :-), but I want to emphasize that
when a researcher gives data or code to the community, it is
important to respect his or her conditions.  The most common
condition is that the code remain open-source: roughly speaking,
if I give a program away for free, I might require that if you
extend the program further, then your version must be free too.
See www.opensource.org for more details.

- To those of you who included an acknowledgments section,
well done.  No one is an island.

- Finally, save paper - remember to print double-sided!

I hope all this advice was useful.  Writing effective, clear,
interesting research papers is one of the most important parts
of being an academic.  So learn to do it well, and learn to
enjoy it!