------------------------------------------------ Please quickly scan the notes below to see if any apply to your paper. As always, questions welcome. ----- Abstract: must have one. No abstract, no ULW credit. This isn't me, it's the way it is. Repositories, databases, etc. will oursource your abstract-writing if need be:they need it. The abstract summarizes the paper, is often all that appears in searches of on-line or other indexes like Citeseer. It's the first thing a reader (or referee) looks at: next is conclusions, (and next is the reference to see if his work is cited). It's usually the last thing you write, but not crazy to write it first so you have an idea what you want to say and then re-do it last when you know what you've said: often emphases change during writing. Go to any CS journal and read some abstracts. A surprisingly common fault still survives out there, so help stamp it out: Never start abstract with ``This paper ...'' . Another fault, far's I'm concerned, is to take a couple of paragraphs from introduction or conclusion and copy them as an abstract. The three things are different. The abstract is an overview of the motivation, methods, results, and especially novelty and surprising results. Thus it a little ``hook-ey'': you want to elicit ``tell me more, sounds interesting''. By contrast, the Introduction can start back in prehistory, leisurely make its way to (finally) what you're going to do in the paper. Problem is by then people may have stopped reading since they don't know where you're headed. Hence the abstract. OR you can start with a dramatic sort of intro: here's a problem no one's solved. We need an answer! What to do? (tear off shirt and tie and spectacles to reveal big red S on chest) Look! I'm going to tell you the answer and how you can do it at home! (type thing)... Conclusions: should have them. If your paper isn't defending a hypothesis, ``Summary'' could be more appropriate title for this section. It's the second thing your reader will look at, should be there in CS professional writing. Good practice even if it seems you're repeating yourself. Conclusions are often just a list of points you covered, things you proved, etc. but it's always nice to tie your work into a broader context, or restate your findings in a different way, whatever it takes to boil down your work into a coherent little story. Page numbers: should have them. Page numbers are quite useful and professional. Gives reviewers like me places to refer to, and citers to cite page numbers. You'll need them if you use a table of contents. It's the professional thing to do. Sections and Paragraphs: should have them. Sections and subsections are often but not always numbered like 1. 1.1 1.2 ... 2. 2.1 2.1.1 ..., the outline form you would use in a table of contents. etc with the restriction that there's no 2.1 without a 2.2, etc. (no lonely (sub)sections). Breaking up paper with sections is good for the reader. Being organizational units, sections are natural candidates for shuffling until they make a logical order. Section titles tell the topic of the section, and sometimes you can tell by your table of contents that you should re-organize. When dealing with a topic, you may notice you've written 1 1/2 pages, all one paragraph. Granted it is one subject, but better to break up your prose into smaller logical units. Consider a sub-section for your 1 1/2 pages, and break it up into 10- or 20- line paragraphs. Ideally each paragraph has (usually starts with) a topic sentence that says what the paragraph is doing, and possibly has a transition that leads reader into the last paragraph. The above structuring process is a great time to shuffle sentences into a logical order so the paragraph flows and is maximally clear. Personally, I sometimes think I write sentencess almost at random, because I do a lot of re-ordering to put them in a logical sequence. Figures: should use easy and unvarying conventions: In scholarly writing, you want every figure to have a number and to refer to every figure in the text (fig. 3) seems to be most common but there's nothing wrong with (Figure 7a) either. Each figure has a caption that looks something like this: Fig. 1. The recent history of freebo-dixxonian dynamics. (a) Freebs plotted semilogarithmically against dixxits. (b) Number of dixxits, 1878 -- 2014. (From Smith 1996b). The caption should be brief but should explain (label) what's in it. Extra explanation in the text is usually expected, so it's OK to be terse in the caption. If you copied the image from somewhere, it's honest to cite and reference the source, and for a book or maybe even a journal publication you might need permission to use the figure. At that point it's probably easier to redraw it! Optional note: styles vary: captions can be very minimimalistic, maybe only a title (above, ``The recent ....dynamics.'') I find that needlessly hard on the reader. OR, you can be like the Scientific American (at one time, anyway), with Looooong captions that meant you could pretty much get the whole article just by looking at the pictures and reading the captions. I find that redundant. LaTeX: a good thing to learn?? LaTeX is the most-used text processing system for Computer Science: that's why all our papers look alike. Latex has tags for stylistic functions and formatting, and out of the box it knows how things ``should'' look in a paper. It can be customized (Michael Scott's text book is all LaTeX). It supports a user-created bibliographic database you create, and will a combination of the \cite{} and \bibliography{} commands will keep track of your citations, keep them consistently numbered and pointing at your biblio entry even when you move them around. Same thing with numbering figures and sections: it takes care of ALL the bookkeeping. \tableofcontents generates you table of contents from section structure. Worth learning if you're going to be a CS pro. One easy way is to find a paper in LaTeX source form and the result in PDF. 'Which' and 'That': 'That' is a restrictive pronoun, used in defining or individuating a concept: ``The book that is on the table...'' identifies which book you mean out of several in the room. 'Which' is nonrestrictive, often adding extra information about a known individual concept: ``The book, which is on the table...'' given the reader knows the book referred to already, this informs him that it's on the table. Usually 'that' and 'which' are disambiguated by context, so writers are prone to pick them out of habit, at random, etc. But they are not always interchangeable, and the problem almost always arises with 'which'. A sentence can have totally different meanings depending on whether the 'which' is understood in restrictive (should be 'that') or non-restrictive sense. Usually misusing 'that' sounds really bad and is thus less common. 'Which' sounds more posh and formal, so attracts more misuse. Rule: see some authoritative source like an English style manual or http://www.everythingenglishblog.com/?tag=restrictive-pronouns or wikipedia. Simplest rule: in scientific writing, use 'that' unless it sounds bad. Better rule: if you can put a comma in front of it without sounding awful, it's 'which' (see above examples). Note: Very commonly done wrong, especially by Brits. 'This' considered dangerous: As a very good rule, don't start sentences with ``This '', like ``This means'' or ``This caused'' or ``This is''. Your ``this'' refers to something just mentioned that is obvious to you but often not clear to your reader. It's easy to disambiguate with a noun saying what in the last sentence the 'this' refers to. ``This problem means'', ``This action failed'', etc.