Writing Papers

Managing Git repo and File structures

Name the repo paper_name, e.g., paper_gentree where gentree 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.

1 directory per paper (which is a clone of a Github repo), e.g., paper_gentree
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.
- arch.(pdf|png) (optional): a diagram describing the architecture of the framework or tool

After submitting a paper, I save a copy of the submitted pdf file and create a tag for the latest commit to keep a history of that submission.

Save the submitted pdf file as VenueYearX.pdf, where X is submit for the original submission version, final for final (camera-ready) version and rI for the ith revision for additional revisions between the original submission and final (e.g., for jounal).
```
git add icse2021submit.pdf  
```

Then create an annotated tag for the commit

git tag -a icse2021submit -m "ICSE 2021 original submission" commit_hashid (optional)
git push origin icse2021submit
git show icse2020submit

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

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

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).