Rules on How to Work on Projects

The rules that follow are needed within the BURG, to allow a maximum number of folks to interact effiiciently on any given project.  So no deviations can be tolerated.

Project management

  1.  Normally, a project will have 2 or 3 people working on it.  The most junior person (hereafter referred to as "the kid") spends the most time, and will be the first author on the paper that comes out.  The successful completion of a project should be a paper or two, and a thesis chapter, written by the kid.
  2. Often a project will grow as time goes on; the kid should try to fight this.
  3. On a first project, a graduate student can expect to spend at least one year.
  4. The kid has responsibility for keeping the project moving, focussed, and organized.

Project initation

At the very start, its vital to be organized in a way that Kieron can find relevant stuff quickly.
  1. In pbe@dft:proj, create a subdirectory with a mnemonic for the project, consisting of no more than 4 letters, such as doub (for double excitations), osc (for oscillator strengths), mem (for memory), etc.
  2. Create several subdirectories, as needed, for storing stuff as its created:
    1. binder  - contains contents of binder with paper copies of notes
    2. drafts - contains all old drafts, eg k5_22.tex, h6_31.tex, etc.
    3. enotes  - all enotes from the project, any eformat.
    4. enotes/figdata - contains all data used for figures in paper in ASCII format
    5. plus any specialized files (eg gnuplot scripts)
    6. lit     - contains relevant pdf's while project is building, and
    7.           file of bibitems;  later pdf's merged into lib and bibitems will be merged into refers.txt
    8.    preprint - contains compressed format for website, both ps and pdf
    9.         - labelled AGB02.ps,...
    10. sub     - contains submitted version of paper, including cover letter.
    11. sub/resub - for resubmitted version
    12. sub/erratum - for erratum

    13.  

Early stages: Literature

As the project begins, its very important to develop a library of papers that form the basis for the project, as well as the
motivation and the connection to the rest of the world.
  1. In pbe@dft:paper/lib, create another subdirectory with the mnemonic, put all e-papers as pdf's relevant to the project, even duplicating existing ones in the main lib/papers directory; later this gets moved over to the proj directory
  2. At the same time, create refs.loc, a local file of bibitems in the same style as refers.txt, listing all relevant papers.

Early stages: Keeping notes

  1. Very careful notes should be kept as the project develops.  A good way to think  about this is to imagine you are run over by a bus, and another graduate student will need to pick up where you left off.  How much time will be wasted?  Also, 50 years from now, Kieron had better be able to reconstruct everything you did, or he'll come looking for you.  There is no statute of limitations on this.
  2. The kid needs to archive everything as it gets done.  About 1/4 of all time spent on a project should be devoted to archiving.  If this is done carefully as the project develops, it will save lots of time when the paper is being written.
  3. The kid creates an archive enotes, putting all electronic notes, including graphs, etc, that she wants others to see, and keeping a contents file with a list of entries.
  4. Alternatively, the kid makes a hardcopy and puts in a binder available on her shelf of all these items, especially those that are hard to store electronically; enotes have the advantage of producing instant thesis chapters.
  5. For very general useful results, often either fundamentals from books or interesting worked simple models, the basic equations need to be added to our general notes, in proj/gen.

Middle stages: Writing a paper

  1. When Kieron (hereafter referred to as "the boss") says its time, create pbe@dft:proj/osc/drafts, with your first pathetic attempt at communicating with the outside world.
  2. All versions of the paper should be labelled both by the date and the author, eg f5.02.01.tex.  Every version should be turned into a ps and an email with the precise location sent to the boss.
  3. All papers are written in revtex.  All symbols must conform with the dft.tex macro definitions.  If new macros seem warranted, create a local macros.tex file.
  4. Within the paper, all equations should be labelled, with a useful acronym.   It should normally be texed with the eqlabels turned on.  Eg. \label{Seqn}.  All figures should be similarly labelled, but with an f: prefix, eg. \label{f:KSpot}, tables with t:, etc.
  5. All citations must be put in refers.tex according to our notation, and then cited that way in the paper.  Usually \cite will be defined simply to write the citation directly in the paper, eg \cite[HK64] makes [HK64] appear in the text.
  6. Understand that it often takes at least a year to get a paper finally finished.
  7. Omit needless words!
  8. Avoid superscripts like e^{i k x}, when \exp(i k x) will fit on the line.
  9. Use two column output everywhere to save paper.
  10. Always put integration variables right next to integral signs, to avoid confusion.

Late stages: Finishing a paper

  1. When a paper is almost ready for submission, it must be defended in a group meeting talk.  One other group member, not working on the paper, is designated as the critic.   When the critic's comments have been addressed, then it can be sent in.  The most important part of this process is usually NOT the scientific content itself, but the presentation, i.e., what has the critic not understood, and why.
  2. When ready, both a sub and a preprint subdirectory must be created, containing all materials used to generate them, eg original tex file, ps of figures, etc.
  3. When the paper is submitted, it must also be put on the  xxx server, especially if its going to a chemical journal.
  4. The paper should be added to refers.txt.
  5. Preprints, both electronic and paper, must be mailed out at that time, and it should go on the group publications website,using the usual notation.   The kid must suggest at least 12 names of folks to send it to.
  6. The notes must be turned into a permanent archive at that time, to be slightly modified upon acceptance of paper.  This just means working through all items in the notesdirectory, and removing useless duplicates, and tidying the kept ones, which must include all data tables used in figures,etc.
  7. Eventually, the work will be accepted, and the website and refers.txt must be updated, possibly changing the acronym, eg. FMB10.  At that time, the name of the notes subdirectory should also be changed.

  8.