Writing Papers

Managing Git repo and File structures

1. Git repo for each paper

• Name the repo name-paper, e.g., rbsyn-paper where rbsyn is the name of the work.
• I do not put conference name as part of the repo name because it might end up not being in that conference. Instead I use git tag (shown below) to identify submission to conference.

2. File structures

• 1 directory per paper (which is a clone of a Github repo), e.g., rbsyn-paper
• Within the directory, I use very few files (paper.tex) and no sub directories
  • paper.tex: I use a single TeX file for the entire paper.

  Others might prefer using multiple files / directories (e.g., intro.tex, eval.txt, sections/related.txt). But I find it easier to just use a single file. Even when sharing or collaborating with others, in which conflict edits can arise, a single file still works well because git is pretty good at resolving conflict issues.

  • paper.bib: I use a single BIB file for bibs. My collaborators sometimes put in their own bib files.
  • figure.(pdf|png) (optional): For figures, charts, or diagrams embedded in the paper. Prefer PDFs if the content can be represented as vector graphics.

3. Do not commit temporary files generated by LaTeX or the PDF that results from the compilation. In general it is a good idea to set up correct .gitignore file and include paper.pdf in it.

After submission

After submitting a paper, I create an annotated tag for the commit

git tag -a pldi23submit -m "PLDI 2023 original submission" commit_hashid (optional)
git push origin pldi23submit
git show pldi23submit

After rebuttal

After submitting a rebuttal, save a copy of the reviews and rebuttal as a plain text file

git add pldi23-reviews.txt
git commit -am "reviews and rebuttal"

Miscs

• Prefer high-level description than technical one
  • People will not be interested in reading the rest if they can't understand (or get excited about) Intro
  • Start technical sections with something high level, e.g., an overview picture or algorithm. Don't go directly into formulae and theorems.
  • Before (or after) presenting some technical things (e.g., a theorem), explain why it is needed or useful.
• Think of a presentation as an introduction to a paper (i.e., after seeing the slides, people will want to read the paper); and think of the paper as an introduction to the work/code (i.e.., after reading the paper, people will want to use your work/code).

Adapted from Dynaroars group.