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
  to your own situation.
  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
       some links about this: 

     - Give enough information that the reader can replicate your work.
       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 
           about how your algorithms worked, or what you actually
         + 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
  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
       about these.  
       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
       Some links about determiners that may help you review:
     - 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
       When you are talking about the properties of your system, you
         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:
  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 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!