Checklist for Writing Papers with Prof. John Lee

This page was copied from Prof. Lee's former advisor Prof. Vincent Mooney and then has been modified and added.

How to write a good abstract for engineering papers and journals

State motivation (and reasons) with current trends
Consider the track which you are submitting
Give the (theoretical) gist summary about what the paper is, with one or two sentences
Manifest contributions (which may be combined into number 3)
Explain how (using what method or approach), with one or two sentences
About actual implementation and performance result
Major advantages (and disadvantages such as area or power)
Potential current and future applications (beneficiary)

Typical evaluation criteria for engineering papers and journals

Title accurate?
Abstract clear and concise?
Problem clearly defined?
Prior work accountable?
English?
Novel?
Important?
Relevant?
Theory technically Sound (if applicable)?
Methods, algorithms and proofs clearly described?
Methods technically Sound?
Symbols, Terms and Concepts adequate?
Figures and Tables clearly seen?
Experiments and results clearly described?
Experiments technically Sound?
Overall Organization and Flow
Overall Presentation: Sufficiently Comprehensive and Balanced
Missing important references?
Length appropriate?
Overall Recommendation (maybe different from average)

How to write a paper or journal for engineering papers and journals

Emphasize novelty, what is different from others. Substantiate the novelty with experiment, comparison, analysis and/or applications.
Use relevant keywords that the reviewers are looking for the targetting conference.
Do not unnecessarily mention anything that may make reviewers mistakenly depreciate our work, because most reviwers are busy and may not be familiar with our work and thus make a sudden judge without completely and throughly read the paper. Avoid any such sentence. (I am saying this because one reviwer mistakenly thought and made judge based on an irrelevant reference put at the end of a sentence, which we intented to refer a run-time complexity placed at the end of the sentence, but the reviewer applied the reference to the entire sentence of our work, and thus s/he concluded and said that there is nothing new in this paper.)
Ephasize contributions specifically and in a way the reviewer can buy.
Be aware that reviewers are eager to prune inappropriate papers, picking out hidden assumptions, absurdity, incompleteness, contradiction and unsubstantiated claims.
Do not give reviewers any chance with which they depreciate our work. These may include the following minor things: but are not limited to, grammar mistakes, undefined terms, unclear or ugly drawings, ugly layouts.
Do not assume that reviewers will dig out and appreciate our novelty. Instead, reveal, explain and underline our novelty.

Title: that most perfectly describes your work in a concise form.
Abstract: Summarize your work. Emphasize an important result and contribution
Introduction: Background, trends and future expectation that justify why you are focusing on the topic. Must emphasize why this discovery is important.
Previous Work: What others have done so far with respect to the topic.
Motivation: Initial motive and the reason why you have decided to focus on the topic. (Problems)
Definitions: terms that help describe your topic.
System Model: What your target looks like. (including Assumptions)
Methdology: How you have achieved your topic. (including Algorithms, Approaches, Methods, Small examples, Expected results (Complexity if applicable))
Implementation: How you have implemented your methodology.
Experimentation: How you have proved your methodolody and topic. (Simulation environment, Application, Results, Analysis)
Conclusion: Important results, Contributions, Future work
Acknowledgement:
References:
P.S.1: Sections can be merged if it looks better. For instance, previous work and motivation, or implementation and experimentation.

Strategies to submit a journal article based on a previous paper accepted in a conference

Write caring about more smooth flow, targeting broader readers
Add a little more previous (related) work
Add more complete assumptions and definitions
Add more theorems (lemmas and corollaries) and proofs
Add more examples
Add more details in algorithms, architecture (schematics), implementations
Add more synthesis results with various sizes or cases
Add more simulations in performance with more complicated scenarios
Add more observations, analysis, tradeoffs

Checklist I of subset of items to satisfy before giving any version of any paper to Prof. Lee to read over:

I.1. Run spellcheck on the entire document (including references).

I.2. Make sure all numerically labeled items such as "Figure 4", "Table 7", "Chao [7]" or "Definition 2" do not have a carriage return between the item name and the number, e.g., "Figure
4" is bad -- in latex, this can be done with the tilde, e.g., "Figure~4" keeps the item name and number on the same line. In MS-DOC, apparently cntrl-shft-spacebar achieves the same effect as the tilde in latex. By the way, Prof. Lee prefers that you use latex, but if you do not, then you are expected to be able to reach the same performance as latex with whatever editor you choose to use.

I.3. Make sure all items such as figures, tables and definitions stay together on one page -- for example, it is not acceptable to have a picture on one page with its caption on the next -- in latex, this is automatically taken care of, but if you do not use latex as Prof. Lee recommends, then you are still expected to be able to reach the same performance as latex and you must check for things automatically taken care of by latex such as I.2 above and this one (I.3).

I.4. Similar to I.3 above, make sure that a section heading does not sit alone at the bottom of a page -- for example, it is not acceptable to have "Section 3. Widget Design" appear at the bottom of a page, with the beginning text on the next page. In latex, this is automatically taken care of, but if you do not use latex as Prof. Lee recommends, then you are still expected to be able to reach the same performance as latex and you must check for things automatically taken care of by latex such as I.2 and I.3 above and this one (I.4).

I.5. If you use latex, make sure all sentences have at least one space between them -- "<word>.[space]<Word>" -- and latex will automatically handle the sentence spacing properly. If you do not use latex (e.g., if you use MS-word), make sure all sentences have two spaces between them -- do a global search and replace all cases of "<word>.[space]<Word>" with "<word>.[space][space]<Word>". In latex, this is automatically taken care of, but if you do not use latex as Prof. Lee recommends, then you are still expected to be able to reach the same performance as latex and you must check for things automatically taken care of by latex such as I.2, I.3 and I.4 above and this one (I.5).

I.6. If you do not use latex (e.g., if you use MS-word), check your spacing in general -- do a global search on double spaces and make sure all double spaces are what you intend.

I.7. Make sure all examples are put in a separate example font and have a box at the end of the example. For an example of how examples done this way will look, please take a look at the following reference:
B. Saglam Akgul and V. Mooney, "System-on-a-Chip Processor Synchronization Support in Hardware," Design, Automation and Test in Europe (DATE'01), pp. 633-639, March 2001.

I.8. Make sure references are in proper format (proper quotation marks, italicized book and conference proceeding titles, pages numbers, month and year, book publisher location, etc.).

I.9. Pronouns are a major cause of confusion in English, especially the pronoun "it": therefore, please check all uses of "it" and either replace "it" with a noun or else be certain that the sentence is clear, e.g., make sure that the previous noun read by the reader is the noun intended by "it."

I.10. The verb "to get," although common in spoken English, is not considered proper in formal writing: therefore, please replace any occurance of "get" with another way of saying the same thing, e.g., use the verb "obtain" and rewrite the sentence.

I.11. If you use a new term with which the reader may not be familiar, first define the term before you use it -- e.g., if your paper discusses the design of a "Switch Arbiter (SA)", make sure you clearly define exactly what constitutes an SA before referring to how you design the SA.

I.12. Similar to the previous checklist item, even terms which may seem to be common knowledge need to be clearly explained when used. For example, consider the use of the term "dependency chain" -- which uses well known terms of a "chain" and "dependency" -- in the following: "However, if any one of the variables used for computing D_i is also destroyed, the instruction that recovers that variable must be inserted before alpha_i in Gamma, and this must be applied recursively for all other modified variables in the dependency chain." While the reader can probably apply skills similar to those used in solving the Analytical section of the GRE (remember questions such as "Bob hates Kate. Kate and Michelle are best friends.... Who lives next to Bob?") in order to figure out what is the "dependency chain" referred to in this example, the writing should be much clearer and should not require such effort to interpret.

I.13. Similar to the previous two checklist items, any time you state "the X" -- e.g., "the block ID" -- make sure that "X" either is part of common knowledge (subject to Checklist I.12 above) or was properly introduced and explained prior to referring to "the X." For example, if you say that a field in a data structure stores "the block ID," make sure that you have precisely defined block ID and where it comes from prior to saying that it was placed in the data structure.

I.14. Similar to I.11, spell out all terms upon first use in the main text as well as, separately, in any auxilary text such as an abstract or thesis summary. For example, do not refer to "MPSoC" expecting the reader to know this term without you spelling it out upon first use. When spelling out a term, capitalize the text appropriately according to the term, e.g., "Multi-Processor System-on-a-Chip (MPSoC)." While it is true that some prefer no capitalization, nonetheless, Prof. Lee prefers capitalization, so please do not say something like "multiprocessor system-on-a-chip (MPSoC)." Finally, please note that all terms should be spelled out upon first use in an abstract, thesis summary, or other separate text, and then should be spelled out again in the main text. E.g., in your abstract you might refer to "Multi-Processor System-on-a-Chip (MPSoC)"; in the main text of your paper, upon first use in the main text, please spell this out again: "Multi-Processor System-on-a-Chip (MPSoC)."

I.15. Before giving your revised version to Prof. Lee, double check all corrections/questions/suggestions he made for you by looking over the printout you have made for him. Prof. Lee's experience is that graduate students unfortunately do not typically make all his recommended corrections and answer all his questions. Therefore, please make a second pass over all of the corrections/questions/suggestions made by visually comparing the new printout with the marked up draft copy and make sure that all corrections/questions/suggestions are answered in some fashion.

I.16. Before giving your revised version to Prof. Lee, make sure to read over the printout you plan to give him. For example, if the prinout has an error that says, "Error - reference not found," then fix this and any other problems you find in the prinout. Then, print out an updated version and read it again looking for errors. Repeat this process until you can read through the entire document without finding any errors.

I.17. If you gave Prof. Lee an earlier version which he marked up with comments, then for the next revision always include all previously marked up versions when you give him the next printout.

I.18. If you are still working on some items Prof. Lee asked you to work on in an earlier version which he marked up, then please say so, e.g., "Still looking for reference X which you asked me to add."

I.19. In cases where you need to reference a submitted article -- e.g., on a Ph.D. Proposal Part 2 -- please use the following example as a guide:
V. Mooney and G. De Micheli, "Hardware/Software Codesign," submitted to Design Automation for Embedded Systems on 27 November 2002, under review.
Please do not forget to put an exact day and month of submission

I.20. Please take a look at the IEEE Style reference to help resolve style questions you may have

I.21. Make sure to click "refresh" on your web browser, double check this list, and then sign at the top of your paper "I certify that this paper passes every item on the checklist. SIGNATURE" -- or, alternatively, just sign "Certified. INITIALS" (e.g., my INITIALS are JL) at the top of your paper

Checklist II of advice to consider before writing a paper:

II.1. Focus a LOT OF ENERGY on the examples

II.2. ONLY when your examples are clear should you start writing

II.3. Start to write the example section first: when writing, you will notice the need to explain terms and methods used in the example -- in this case, stop writing the example section, add text explaining the term or method to an earlier section, and then return to writing the example section

II.4. Use small examples to illustrate your terms and ideas throughout the paper -- the best is when you have big examples at the end and use subsets of the big examples for small examples as you lead the reader through the paper

Checklist III of subset of items of typical grammar mistakes of which to be aware when writing a paper (please note that some of these have been blatantly copied from the sources cited):

III.1. that/which: "that" is used to introduce restrictive clauses (i.e., clauses that are essential to the meaning of the sentence), while "which" is used to introduce nonrestrictive clauses and are set off by commas. Although the distinction is often disregarded in contemporary usage, careful writers adhere to the distinction to avoid uncertainty and ambiguity.

Example: "The book which we found on the table belonged to Fred." This is ambiguous and could mean either of the following:
The book that we found on the table belonged to Fred. (This sentence means there were several books around, but the one we found on the table was Fred's.)
The book, which we found on the table, belonged to Fred. (This sentence means there was only one book, and it belonged to Fred.)

(Note: this advice copied from Patricia Grindel, Communications Consultant, 506 Hemlock Drive, Woodstock, Georgia 30188, 770-926-9395.)

III.2. only: to ensure clarity, make sure you put this adverb next to the word it modifies.

Example: "I only eat eggs for breakfast." This could imply that you eat eggs for breakfast, and you do not eat enything else all day.
"I eat only eggs for breakfast." This sentence is well written and clearly/unambiguously means that you do not eay anything other than eggs for breakfast.

(Note: this advice copied from Patricia Grindel, Communications Consultant, 506 Hemlock Drive, Woodstock, Georgia 30188, 770-926-9395.)

III.3. Make sure verbs agree (singular or plural) with their subjects rather than with intervening objects of prepositions. (Note: this advice copied from Patricia Grindel, Communications Consultant, 506 Hemlock Drive, Woodstock, Georgia 30188, 770-926-9395.)

III.4. Watch consistency with hyphenation and in spelling out numbers. Generally, spell out numbers one through nine and use numerals for 10 and above. An exception to this is scientific measurements, which use numerals. (Note: this advice copied from Patricia Grindel, Communications Consultant, 506 Hemlock Drive, Woodstock, Georgia 30188, 770-926-9395.)

III.5. Double and triple check proper use of articles ("a," "an" and "the") that are needed for the sentence to read properly.

III.6. Use the active voice. (This is advice #14 in The Elements of Style by Strunk and White. Please purchase this book.)

Checklist IV of items to fulfill once a conference paper is accepted:

IV.1. As SOON as possible after you find out your paper has been accepted, schedule a meeting with Prof. Lee to discuss reviewer comments and updates to be added for the camera ready final version due date; schedule plenty of time for Prof. Lee to review your revised paper prior to the camera ready final version due date

IV.2. Discuss with Prof. Lee the scheduling of your practice talk; make sure to have greater than a week advance notice in order to properly advertize your practice talk, and please note that even if your are not presenting (e.g., even if Prof. Lee is presenting), you are still required to give a practice talk first since you are the first author

IV.3. After your paper is presented, obtain a copy of the final slides as presented (e.g., if you did not present the paper even though you are the first author, obtain the actually presented slides from the person who presented the paper); coordinate with the Minister of Web Pages the placement of your paper

IV.4. Coordinate with Prof. Lee to make sure that he has a copy of the source files of your final camera-ready paper (e.g., in latex or in MS-DOC) and your final presentation (typically in powerpoint) as presented at the conference

Checklist V of items to fulfill once a journal paper is accepted or requested to resubmit:

V.1. As SOON as possible after you find out your journal paper has been accepted or requested to resubmit, schedule a meeting with Prof. Lee to discuss reviewer comments and updates to be added for the final version due date; schedule plenty of time for Prof. Lee to review your revised paper prior to the final version due date

V.2. Please keep in mind that, unlike conference papers which can be reviewed quickly by Prof. Lee in less than an hour, a complete reading (and writing down edits/corrections) of a journal paper will typically require multiple hours; therefore, please schedule approximately one week for each iteration you want from Prof. Lee, and please schedule a minimum of four iterations -- this means that your first iteration should be completed prior to four weeks before the final version due date -- for example, if you receive an email on May 3 saying a new version of your journal is required to be resubmitted in 5 weeks (by June 6), discuss the reviewer comments with Prof. Lee on May 4 but wait until May 25 to give Prof. Lee your rewrite (the first iteration), this does not leave enough time for an additional four iterations

V.3. Obviously, continue to follow all of the earlier checklist items; for example, do not forget Checklist I.16. at the first iteration, i.e., do not forget to give Prof. Lee, together with the new first revision for resubmission, the original journal paper as submitted with all reviewer comments plus Prof. Lee's comments written on the reviewer comments during the earlier meeting about the reviewer comments

V.4. After your paper is published, obtain the page numbers and journal citation information for your paper; coordinate with the Minister of Web Pages the placement of your paper

V.5. Coordinate with Prof. Lee to make sure that he has a copy of the source files of your final camera-ready paper (e.g., in latex or in MS-DOC)

Last updated April 2007.

Any suggestions, questions or concerns can be addressed to Jaehwan (John) Lee