Papers Prez

This page contains the policies and procedures for preparing papers and presentations in the Jimenez Group.

Paper Preparation FAQs

What is the group procedure for writing a paper?

• We start with an outline (bulleted abstract + figures), as described in this outstanding paper by Whitesides.
• Once we have agreed on the abstract and the figures, we start the writing of the actual text.

How do we track papers on Asana?

• When we decide to write a paper, we create a task named "Track XX paper to submission", with the appropriate followers. All paper versions and comments should go through this Asana task, to provide a central repository for the discussions that we can find later.
  • This task should have a subtask with the text "Verify that all paper specs in Pol&Proc are met before sending any draft to Jose"
• When the paper is submitted, the above task is marked as complete, and we create a 2nd task named "Track revision of XX paper to publication." The initial task will be very messy by then, and this provides a clean slate at a natural breakpoint. Again all paper versions and comments should go through this Asana task.
  • This task should have a subtask with the text "When paper is published in final form: provide PXPs of all figs (incl. Supp Info) as a single zipped folder to Anne (for checking/upload/linking)"
• When the paper is published after the proofs are processed and the figures have been provided, the 2nd task should be marked complete.

What is the group file naming convention?

• File names for ALL non-online (Word, PPT, Excel, PDF etc) files shared within the group and with others should start with the date and be in the format "2013_06_15_LastName_BriefSubject_v1.doc"
  • Date should be on that format with YearIn4Digits_Month_Day. This sorts the files naturally by creation date in Windows etc.
  • No spaces or dashes / hyphens (-) should be part of any filename, as those tend to create problems.
  • Always increment the date & version number in the file name when making ANY changes to the file. Otherwise this can create a lot of confusion and wasted time, and result in losing changes
  • Again, NEVER re-share a file that has had any changes without increasing the version number (it is free!)
  • When reviewing a file and providing any edits or comments, add your initials or name at the end of the file before sharing back, e.g. "2013_06_15_LastName_BriefSubject_v1_Jose.doc"
  • This does not apply to Google Docs since there is only one shared version, but does apply when e.g. making a PDF printout out of a GDoc
  • This may not be doable for e.g. Squirrel or Tofware files, but should be done for all other files of any kind unless there is an important reason why it is not possible

What are the group specifications for outlines to be reviewed by Jose?

___ File names should always follow the group file naming convention above
___ Include your best guess of title, author list, and journal(s) to submit to.
___ Include the key findings as bullets in the abstract.
___ Include only limited / schematic text with section and subsection headings (only if it helps the discussion, otherwise a bulleted abstract may be sufficient).
___ Include all the figures even if incomplete. Write a note below each figures if it needs to be improved, or if the data is not yet fully processed.
___ Include placeholders for missing figures, if possible with a simple cartoon of how the figure may look.
___ Include key literature references that motivate or support the work.

What are the group specifications for papers to be reviewed by Jose?

We spent a lot of effort reviewing and polishing the papers from the group, and some details have to be repeated over and over. Please review and implement all the items below before your paper is reviewed by Jose or others in the group, UNLESS we explicitly agree to a "big picture" review before the paper is complete. (Shortcut to here: http://tinyurl.com/jg-editing)

General:

• ___ All group papers will be written in a recent version of Word for windows (Word 2013 or later as of May-2015)
• ___ File names should always follow the group file naming convention above
• ___ All sections of the paper need to be there, including abstract, conclusions, figure captions etc., unless we have agreed otherwise beforehand
• ___ All section titles should be bolded (or italics for subsections) so that a quick look at the paper allows the reader to quickly identify what goes into each section.
• ___ The sections should be ordered as: Title + author list + abstract; introduction; methods; results and discussion (sometimes 2 separate sections); conclusions; appendix (if any); acknowledgements; references; Tables w captions; Figures w captions; Supp. Info.
• ___ Title + author list + abstract should all be in 1 page
• ___ Intro, References, Tables, and Figures should start on a new page
• ___ Page numbers should be in the lower right corner, and line numbering should be continuous
• ___ Use consistent margins, section title formats, spacings between paragraphs and before and after titles, justification of the text and of the first line in a paragraph etc. across the paper.
• ___ Please review a few recent papers published in the most likely journal that your paper will be submitted to, and follow other conventions based on that example.
• ___ Please review the instructions for authors of your chosen journal, such as these for ACP, ES&T, AS&T, or AGU Journals
• ___ For journals with a length limit (GRL and ES&T) summarize where you are vs the limit on the first page below the affiliations

General Writing & Expressions

• ___ Use a verb tense (past or present, with past generally preferred) consistently in the whole manuscript.
• ___ Long sentences are more difficult to understand and are prone to misinterpretation. As a rule of thumb, try to avoid sentences with more than 15 words. Break complex ideas into multiple sentences.
• ___ Remember that "the language of science is broken English," and avoid unusual or more "literary" words. This is very useful to make sure that international readers can understand your papers.
• ___ Use "significant" only to mean "statistically significant." For the general meaning use "substantial," "important," or other synonyms.
• ___ All acronyms need to be defined on their first occurrence
• ___ All instances of the word “Figure” need to be abbreviated “Fig.” unless it is the start of a sentence. Same for Section to Sect., Equation to Eq. and similar words. This is required for ACP and AMT, but it is a good idea for all journals
• ___ Be aware of your use of acronyms and use them consistently. Reviewers often complain about too many acronyms being used, but acronyms also can save a lot of repetition in the text. Avoid acronyms for terms that are only used very few times in the manuscript, unless they are common ones in our field (e.g. SMPS, PTRMS, AMS, GEOS-Chem). If a lot of acronyms are used, then consider adding a table with their meaning.
• ___ The words "Note that..." or "It is important to note that..." can typically be removed. Use sparingly if really needed.

Title Page & Abstract

• ___ Think hard about the title and how to both summarize well your results, and attract the attention of e.g. a reader in Japan who doesn't know about your specific study
• ___ The abstract is the most important piece of the paper, it will be the only item that many people read. If it is important and new, it must be in the abstract
• ___ Title, author list + affiliations, and abstract should fit on one page if at all possible

Author List

• ___ Include a full author list with affiliations (see previous group papers and/or papers on your target journal for examples)
• ___ We should include everyone who contributed substantially to the paper as a coauthor, or otherwise in the acknowledgements. If in doubt about who should be included, we should discuss before the paper is circulated, as some people will feel offended if left out (even if by mistake).
• ___ For papers from our group, the person writing the paper is always the first author, and Jose is always the last author
• ___ For everyone in our group, the affiliation should be "Department of Chemistry, and Cooperative Institute for Research in Environmental Sciences (CIRES), University of Colorado, Boulder, CO, USA." (Except for students affiliated with ATOC). Note that as of summer 2017, the Dept. of Chemistry only, and NOT Chem. and Biochem.

Introduction

• ___ The introduction should start with the big picture and quickly get specific to the topics of your paper
• ___ Importantly the context of the previous studies on your specific topic should be summarized, and their limitations that your study overcomes should be pointed out
• ___ Avoid lengthy descriptions of topics tangential to your paper. We often have to delete entire pages from group draft intros for this reason.
• ___ A typical introduction is ~2 pages in Word format (~100 lines at Font 12 w/ 1 inch margins). It can be shorter for short papers, but typically not a lot longer.
• ___ The last paragraph of the introduction should be stand-alone and summarize WHAT you did, NOT summarizing the results
• ___ A common mistake is to include some site or instrument or model details in the introduction. Those belong in the Methods section. The only place in the intro where you talk about what YOU did is the last paragraph

Methods

• For instrument details:
  • ___ For AMS: define HR-ToF-AMS in the methods section, and say "hereinafter AMS for short" (or similar statement) and use AMS only in the rest of the paper (or HR-AMS if we need to emphasize that aspect)
  • ___ Note that the correct use is "PToF" and not other capitalizations.
  • ___ For OFR: refer to it always as "OFR" or "OFR185" or "OFR254". Use "PAM" only in the methods section when describing the actual reactor.
  • ___ For CIMS: define HRToF-CIMS in the methods section, and say "hereinafter CIMS for short" (or similar statement), unless otherwise needed
  • ___ For CIMS results such as C10H12O4, use the term "elemental formula" everywhere. Avoid other terms such as elemental composition, chemical formula, molecular formula etc., each of which is problematic for various reasons.
  • ___ For all other instruments: indicate manufacturer/model or give a reference (see recent group papers to find relevant info)

Referencing

• ___ Reference lists need to be complete and properly formatted. It is hard to review papers when the references are incomplete or have many mistakes.
• ___ We should cite primary references whenever possible. A primary reference is the first one to report a given conclusion conclusively. Sometimes people are lazy and cite a paper that cites a paper that cites the primary reference. This is frowned upon and will hurt you in the long term and serious practitioners that read your papers will quickly realize this lazy practice, so we should avoid it.
• ___ Check that a reference that you cite for a given point actually provides evidence for it. Sometimes people engage in "lazy referencing" based on the title or a very very quick look. Like in the previous case, this poor practice will catch up with you eventually.
• ___ Make sure all your references are up-to-date, i.e. don't cite a paper as "submitted" when it is in press or published, don't cite an ACP Discussions paper when the final ACP version is available, etc.
• ___ In the author-date format, references should be cited chronologically, not alphabetically. I.e. it should be "(B et al 2010; A et al., 2014)" and not "(A et al., 2014; B et al., 2010)"
• ___ If a reference is used as part of the text, parentheses should be adjusted accordingly, e.g. "as discussed by Martinez et al. (2014), we follow..."
• ___ If a journal uses numbered references (e.g ES&T), our internal review should still use author-date format, as that is much easier to read and thus makes the review process faster.

Symbols, Formulae, and Units

• ___ All mathematical symbols should be in italics, both in equations and in the text.
• ___ All chemical formulas and mathematical symbols need to be subscripted or superscripted properly
• ___ All Greek letters should be in "Symbol" font. No "um" for microns or "us" for microseconds and so on.
• ___ Write units in the denominator as "-unit", not as "/unit." I.e. write g cm-3 and not g/cm3 and so on.
• ___ Only m/z (in italics) should be used for MS mass/charge units. m/Q and the Th units are not understood by most folks and are confusing, and you should avoid them while in the group.
• ___ Use lowercase italic d for particle diameters
• ___ Use OA for organic aerosols, not "org" or others
• ___ Only SI units should be used, unless an exception is essential.
• ___ Avoid the term "loading" which has led to confusion in previous reviews, use "concentration" instead
• ___ The symbol "#" for number doesn't translate internationally, use "No." instead

Acknowledgements

• ___ Always check with Jose about which grant(s) should be acknowledged. These should include any grants acknowledge in conference presentations of the same work. Leaving out a funding sources that supported the work can lead to huge problems and loss of future funding.
• ___ Graduate or postdoc fellowships for any coauthor that were active during the period in which the research was done should always be acknowledged
• ___ Make sure to include any specific wording or disclaimers requested by the funding agencies.
• ___ When acknowledging EPA funding, always add "The EPA has not reviewed this manuscript and thus no endorsement should be inferred" (or updated wording as requested by EPA)
• ___ Always acknowledge useful discussions that had a significant impact on the paper contents (but no need to acknowledge everyone we discussed the paper research with)
• ___ If appropriate, acknowledge the AMS and/or CIMS and/or PAM (or other) user communities

Scatter Plots, Regression, and Correlation

• ___ Remember that regression and correlation are different things, and come from different unrelated mathematical operations. A "correlation line" makes no sense, only a "regression line" does
• ___ "Correlation plot" should not be used, use "scatter plot" only
• ___ All regressions should be ODR (/ODR=2 in Igor) and this should be stated either in the methods section or in the relevant figure captions
• ___ Whether an intercept is fit or fixed at 0 is a scientific decision based on what is known about the data being fit, sometimes it is appropriate to show both results
• ___ Be careful with the use of qualitative expressions such as "good correlation", try to be quantitative when possible instead e.g. "R2 = 0.95"

Figures

• ___ Introduce figures in the text as soon as you start describing the relevant results. It is confusing if a lot of results are discussed before the relevant figure is introduced
• ___ Make the graphs of a sufficient size / aspect ratio / grouping so that they can be seen clearly in the review format (e.g. PDF as submitted, or ACPD / AMTD landscape pages) and in final publication.
• ___ The meaning of all traces and symbols should be in the graphical legend, NOT in the main text or the figure caption.
• ___ The figure captions should explain what the figures show (i.e. the evaporation rate vs time for systems 1 & 2), but not the scientific conclusions made from the figures. Those should be in the main text.
• ___ All fonts in graphs (axis labels, tick labels, legends etc.) need to be of sufficient size to be readable in printed form or on the web. This means 10 pt font when pasting the graphs at their actual size (or equivalent size if changing their size after pasting into Word). This is the absolute minimum size, but larger is typically better if possible.
• ___ (Starting March 2016) All figures in all group papers (also presentations, see below) should have been sized using the function provided by Harald (HS_RescaleForExport) and then pasted into the document without resizing them at all. The goal of this method is to have consistent graph and font sizes in graphs, which has otherwise been an ongoing headache for the group.
• ___ If the above rule doesn't work, then this one applies: Graphs need to have a minimum font size of 12 (“Modify Graph-->Font size”, command “ModifyGraph gfSize=12”) and copied into word document at 100% size.
• ___ As a practical rule to test the item above: put a 10 pt text box with the word "Test" next to each figure, if any text is smaller than that, make it larger (including graph legends, tickmark labels etc.). Do not send any papers to Jose until you have done this, as he is very tired of repeating this over and over.
• ___ Use color if useful, but print all your graphs in B&W and make sure they are readable in that format too, if at all possible, by wise use of symbols, dashing, and shades. (For e.g. reviewers or readers who print in B&W, plus color-blind folks).
• ___ All graphs should have this macro executed so that we can find them in the future. But for publication or presentation purposes this info should be hidden behind a white box.
• ___ All figures (and tables) should be numbered in the ordered they are introduced in the manuscript
• ___ All axes should start at 0 unless there is a strong reason to do otherwise, and have a zero line
• ___ Dates in axis labels should be in the format "6-Jan-2014" or similar, not as "1/6/2014", which would be interpreted as 1-June in much of the world
• ___ For any data shown or discussed, it should be made clear what the averaging time and other relevant details are

Supp. Info

• ___ The Supp. info will almost always be published as a PDF that we provide, thus make sure the formatting is clear
• ___ Supp Info should start with "Supplementary Information for" (in 1 line) and then give the title and author list of the paper
• ___ All the standards for figure and text quality etc. apply equally to the Supp. Info.

When sending the paper to Jose

• ___ Include a statement on your email / Asana that "I have carefully checked this draft against the specifications in the group policies & procedures page, and I believe all are met." (Or explain any that cannot be met and why). Papers without this statement may not be reviewed.

Can I be the corresponding author of a paper?

• Per tradition in the field, papers from the group have the supervisor as corresponding author. Since we collaborate with many groups, including some at CU, this is important to signal the paper as being primarily the product of our group. We rarely get emails via the corresponding author mechanism, and if we do Jose will forward them immediately.

Can I be a coauthor of someone else's paper?

• Authorship in our group is based on specific contributions to the work on that paper.
• The number 1 coauthor issue is that someone is left out by mistake. This happens A LOT, especially on papers using data from a lot of people etc. Don't assume that you've been left out on purpose before you ask.
• Importantly, if you think you have been left out by mistake, you need to ask quickly, as it becomes difficult and eventually impossible to add authors as the paper progresses towards publication.
• If you have been left out of a particular paper (NOT by mistake) and you want to discuss it, please prepare a list of specific contributions to the actual material on that particular paper. If you convince us that there are enough specific contributions, then we can reconsider the decision (for papers from our group) or ask the main authors (for papers from other groups).
• There is not such a thing as "author trading", i.e. if someone is a coauthor in your paper, you can't be a coauthor in theirs just because of that
• For secondary contributions to a field or lab study, e.g. a person helped run an AMS but did not analyze the data nor do other analyses for the paper, the policy is that person will be included as a coauthor on the main paper from our group that uses our data from that study (sometimes the first couple, depending on details), but not on latter ones. For papers were our data use is minor, the authorship list from our group is correspondingly reduced.
• Note that for papers not from our group we do not have control over coauthorship decisions. We can argue for someone to be included, but the main authors may say no.
• Coauthorship issues do lead to a lot of tense discussions and stress at times. There will be times when one feels one has been left out of a paper one should have been a coauthor of. However in the big picture sometimes you may be included on papers that you contributed a relatively small amount of work to, so it can average out in the big picture, and it is not worth getting really upset or making lifelong enemies based on this!

Paper Internal Reviewing FAQs

What is the internal review process of a paper?

• Generally we will iterate through multiple drafts, with Jose, Doug, and other group members and coauthors reviewing the paper, followed by the first author generating a new version
• We will refer to the following levels of review:
  • Level 1: "big picture" review, looking at the figures, key sections, abstract, conclusions, with input of the scientific story of the paper and its quality, gaps etc. This is a notch up from reviewing an outline, but there is not detailed text reviewing other than maybe the abstract or critical areas.
  • Level 2: intermediate-level review, with detailed comments and some editing of the text, but where the first author will address the gaps thoroughly, followed by re-review
  • Level 3: thorough review, with the assumption that the paper can be submitted immediately after this review and its comments are addressed. (In practice there is typically at least one re-read).

How do I ask the author to get back to me (as internal reviewer) on specific issues?

• Sometimes an internal reviewer will be interested in hearing back from the first author about how a few topics are addressed in the revision of a paper.
• It would be too cumbersome to do this for every comment or every highlithed comment. So the procedure is to add 3 asteriks *** at the start of a comment in Word or GDoc. E.g. your comment may say:
  • ***I think an alternative approach along the lines of Einstein et al. (2017) may be better here.
• The first author should then post their responses to those specific items on Asana (unless meeting in person or other method is easier)
• The idea is that this would be used sparingly in general, for a few comments on a paper, so that it is not too burdensome.

What is the procedure for a quick "difference review"?

• Sometimes it is of interest to generate a "difference version" between two versions of a paper. E.g.:
  • Between the version that was submitted to a journal, and the revised version before resubmission
  • Between the version that was shared with coauthors, and the version that has been modified reflecting their input
• To do this, take the original version and accept all changes, and save it. Then do the same with the revised version. Then in Word go to Review --> Compare Documents, and select the original and revised document. Execute, and save the result. All the differences between the 2 papers should be marked as "tracked changes", which makes it easy to review the changes only.
  • If changes are extensive the "track changes" generated in this way may be so many as to be less useful, but it is always worth a try and it takes 2 minutes to try.

What is a forward diff version?

• Someone (let's assume Jose for simplicity) may ask for a "forward diff version" of your paper. This has a very specific meaning and procedure:
  • You have produced a revised version, let's call it V2
  • Take the last version that Jose reviewed (V1_Edits_Jose), and accept all the tracked changes --> V1_Edits_Jose_Accepted. Keep the major (colored or otherwise important) comments. Other comments can be removed, but that's not too important.
  • Make a difference version (per item above, using Compare Docs in Word) between V2 and V1_Edits_Jose_Accepted. That is the "forward diff version."
• The goal is to enable Jose to quickly see what has changed since his last revision, and do the next round of revisions faster than if he had to read a clean version again from scratch. This is done when the paper still needed some revisions, but not so much that an additional full review was needed.

Why can't you review my paper faster? It is important for my fellowship / graduation / job application / etc.

• We try to work through draft papers as fast as we can, but producing high quality papers takes a lot of time, and there are many tasks that compete for that time. Any plans you make around publications have to take into account that our feedback may need many rounds, and each round will take some time, more so during busy times such as field studies etc. Also, at times Jose and/or Doug may be too busy for weeks (months on occasion) at a time and may not be able to read a paper immediately, although we will always try to do it ASAP. This happens in all research groups. In addition coauthors often need a few weeks, sometimes more, to provide comments on papers. You need to take this into account in planning timelines for paper submission, graduation etc. and build up enough buffer time to meet your personal deadlines.

What is the procedure for sharing a paper draft with coauthors?

• The paper needs to be sent to all coauthors with enough time for them to review it, which is typically 2 weeks. The following text can be used as a starting draft for your email (for Google Docs papers, see below for Word)

Dear Coauthors,
Please find attached our paper entitled “XX” that we have prepared for submission to YY. Please read the paper and return any comments or edits to us by ZZ, or please let us know if you need additional time. At a minimum, please confirm that you want to remain a coauthor, and please review the spelling of your name, your affiliation, as well as any details describing and using data from your instrument / model etc., though comments in all parts of the paper are very appreciated.
We will be sharing the document via Google Docs with each coauthor through their email address, and the link to the Google Doc is below. If you would like to have access with another email address, please send me that email address or click “request access” on the link. Coauthors can make edits to the paper text that will be automatically tracked as changes, and can also add comments.
Please edit and comment directly in Google Doc (and please do not download into Word and edit there), as we will be digesting coauthor comments as they arrive, and we will also be implementing some very minor changes in parallel with your review.
Link to shared GDoc (always create a new GDoc for sharing with coauthors and paste the paper there. Do not share the internal review GDoc due to clutter etc.)
Regards

• for WORD papers:

Dear Coauthors
Please find attached our paper entitled "XXX" that we have prepared for submission to journal "YYY". Please read the paper and return any comments or edits to us by XX-XX-20YY (2 weeks from the day you send the email), or let us know if you need additional time. At a minimum, please confirm that you want to remain a coauthor, and please review the spelling of your name, your affiliation, as well as any details describing and using data from your instrument / model etc., though comments in all parts of the paper are very appreciated. If you have multiple comments, using "track changes" in Word is best. Let us know if you have any questions at this time.
Regards,
-First author

• Then set yourself a reminder in Google Calendar to send a reminder email 1 week and 3 days from the due date (or some alternative of your liking). These reminders are very useful since our coauthors are typically very busy, and the reminders help to get the paper to the top of their queue.
• For people who have not replied to the first several emails after several days past the deadline, you need to send a last email before submission stating something like "The journal requires that we confirm that the submission has been done with the consent of all coauthors, so at the very least please confirm that you wish to remain a coauthor, or alternatively that you prefer to be moved to the acknowledgements section. If we do not hear from you after this reminder, we will move your name to the acknowledgements."
  • The names of coauthors who don't confirm that they want to stay indeed need to be removed from the paper before submission.

Paper External Reviewing FAQs

How do I submit a paper?

• The first author always submits the paper him/herself.
• You need to go to the online system of the journal in question, and upload the manuscript and Supp Info as PDF. Sometimes you also need to upload other documents such as copyright agreements, figures in specific formats etc. Refer to the instructions for authors of the journal you intend to submit to.
• For journals that have a length limit, some (e.g. GRL, PNAS) will not even allow you to submit if the paper is determined to be too long by an automatic checker. Others may allow you to submit (e.g. ES&T) but the paper will be rejected a couple of days later by the staff before it reaches an Editor. Thus it is very important to pay attention to the length limits.
• For several journals a letter to the editor is required. This should not be a repeat of the abstract. Rather you have to summarize:
  • What is the broad topic and the key finding(s) of the paper
  • Why is this paper appropriate to the journal you are submitting to. For this point it is good to refer to other papers on the same topic published in that journal, or to how many of the references you cite are in the journal you are submitting to.
  • Run this letter by Jose or Doug before submission.
• For journals that allow a "second contact" (including ACP and AMT), please enter Jose with his @colorado email address.
• We should discuss suggested reviewers. We typically try to suggest 10 reviewers so that the Editors have some options to choose from (though most Editors will choose reviewers not in our list as well).

What do I do after submitting a paper?

• As soon as the paper is submitted, you should send an email to all coauthors with something like:

Dear Coauthors
Please find attached the PDF of the submitted version of our paper entitled "XXX" that I just submitted to journal "YYY", for your records. We have done our best to address everyone's comments. If you have further comments, find any remaining mistakes etc., please let us know and we will address those comments together with the ones from the reviewers
Regards,
-First author

• Typically we mark the Asana task used for tracking the paper as "completed", since it tends to be cluttered. Then you should create a new task named "Track paper XXX to publication", attach Word and PDF files of the submitted version, move there any incomplete subtasks from the paper draft stage, and make any relevant group members followers.

What are the group specifications for responding to the reviews of a paper?

This is written as a guide for people in our group working on one of their first papers, although it may be of use to others.

In terms of procedure:

• As soon as you get the reviews, please forward them to all coauthors, and ask for any input they may have. This gives them more time and saves a lot of time, if they care strongly about how we respond to some review comment.
• Then you should work on the revised paper and response document as discussed below
• The revised paper and response document needs to be shared with all coauthors before re-submission. It is a bad idea to not share the response document with coauthors, even if the reviews were good and the changes are small. Depending on how extensive the reviews and revisions were and of how many coauthors we have, we may give between a few days and 2 weeks to the coauthors to get back to us. We need to hear from coauthors that they agree to re-submission before we can proceed.

Generally we need to submit three documents in response to the reviews:

• (1) A revised paper
• (2) A "difference version" of the revised paper, highlighting (e.g. with track changes in Word) all the changes between the submitted and revised versions.
  • For ACPD or AMTD paper, please take care to incorporate all the changes that may have been made at the proof stage (those should NOT be highlighted).
• (3) A point-by-point reply to all of the reviewer comments.
  • In this document we first copy all the reviewer comments, and number them as R1.1, (reviewer #1, comment #1), R1.2 and so on, in black text.
  • Then we reply below each one, in blue text, as A1.1 (reply to comment #1 of reviewer #1), A1.2, and so on.
  • If the reviewer is asking multiple questions on a paragraph, respond to the most important one first. Alternatively, it is ok to break up the reviewer paragraph into subparagraphs (R1.1a, R1.1b...) and insert your response below each one.
  • All changes to the document text need to be given in quotes and in bold in this document.
  • Make sure to subscript, italicize, and otherwise follow all the group and journal format specs in the responses as you did for the paper. This communicates attention to detail to the Editor and Reviewers, and can help get the paper accepted.

Some items to take into account when preparing responses:

• It is good to first create a response document and propose responses to each question, and then share the proposed responses with the key coauthors, before making all the changes in the manuscript. Otherwise time can be wasted by having to change 2 documents several times, before we decide on the final responses. For papers from our group, following this format is mandatory. Either share as a Word document via Asana or as a standard Google Doc (Google Doc may be useful if multiple co-authors are commenting in parallel, while Word is a little more convenient for editing/commenting).
  • When preparing draft responses, blue text should only be for text intended to be part of the responses or revised paper. Enter thoughts for discussion as comments (on the side in Word or GDocs), or at least on a different colored text.
• You can read many examples of responses to reviews in the discussion section of ACP and AMT papers.
  • However, note that some of the responses are of mediocre quality. We strive for high-quality work, thus it is not OK to copy all practices you may see on those responses.
• Some good examples of good response documents include:
  • This response document of Marr et al., ACPD 2006.
  • The responses in Aiken et al., ACPD 2010.
  • (If you see other very well crafted examples, pls link them here or let us know)
• We do not need to implement all the changes requested by the reviewers. Sometimes the reviewers are reading the paper quickly or don't have much background in some sub-area, and thus some comments may reflect a misunderstanding of the manuscript. In these cases it is OK to to disagree with the reviewer, although it is good to ask ourselves: "Could the misunderstanding be caused by our manuscript being unclear? Could the manuscript be made clearer to avoid similar misunderstandings by readers?"

If the paper goes to further rounds of review in ACPD or AMTD

• In these journals the reviews and responses to the first round of reviews are public, but later rounds are not. Changing this procedure to make later rounds public has been discussed at the Editors meetings of these journals, but for the time being things will stay as is.
• However the Editorial Board encourages authors or editors to add a final comment to the paper, posting the reviews and responses to further rounds of review, after EVERYONE involved (authors, editor, and referees) have agreed to such public posting. An example of a final comment along these lines is in the public discussion of this paper.

What are the group specifications for providing corrections for the proofs of a paper?

• For final papers (and for ACPD and AMTD also for discussion papers) the journals ask us to review a set of "proofs." Typically there are a few mistakes left and the journals introduce a number of errors while "copy-editing" the paper for publication. Typically we request 20-40 corrections for a particular set of proofs. Also figures are often small and sometimes of poor quality. Note that once the paper has been published, corrections can NO longer be made. Please adhere to the following specifications for this process:

___The first author will read the proofs completely, and check all the figures, tables, captions, references, and acknowledgements.
___Prepare a list of corrections in a new tab in this document in that format. (Or alternatively as corrections in the PDF file)
___Print the proofs to verify that they print correctly and the colors / figures etc. are readable.
___Read especially carefully the abstract and conclusions.
___Check the author list, including spelling mistakes and middle initials, as well as the affiliations.
___Check that Jose is listed as the corresponding author with the colorado email address.
___Check that the section numbers are correct.
___Check all the figures for quality, both in screen and in print.
___Check the size of all the figures, often journals make them too small in the proofs and they can be hard to read.
___Check the reference list for correctness. Update any papers that are in "discussions", submitted, or in press, if possible. Contact the authors of such papers if needed.
___Check that the acknowledgements thank the sources of funding that supported the work, if in doubt check with Jose.
___Either Doug or Jose will also read the proofs. The first author will combine them with his/her comments and send to the journal.
___Check the revised proofs in detail, and if completely correct approve for publication.
___If needed, the first author will iterate with the journal until the paper is approved for final publication. Note that journals typically introduce 1-2 new errors for every 10 errors they fix, but sometimes in can be much worse.

Paper Coauthor Reviewing (led by other group) FAQs

How do we decide who should review papers when multiple group members are coauthors?

• This will depend on multiple factors such as interest, time availability, particular individuals' expertise, the level of journal the paper will be submitted to, etc.
• A 3-level approach is proposed:
  • Level A: "Targeted Group Data Use/Context". Only one person looks at use and description or our data, methods, instrumentation. This should also include a brief skim of abstract, figures, conclusions for broad context. Make any needed edits/comments on draft for authors and give brief report to coauthors in our group (via Asana). Assign task (or subtasks) to other coauthors in our group if their attention is needed on specific concerns, questions. This level of review is applicable when the subject of the manuscript is of more limited interest to our group and when people are especially busy.
  • Level B: "Subset Full Review". 1-2 people from our group give it a full review. If needed, specific sections should be brought to the other coauthors' attention for their review or discussion. This level of review is appropriate when 1) some coauthors' role has been more limited or falls outside their expertise, 2) the subject of the paper is only of moderate interest or relationship to our research, 3) people are simply too busy within the time frame requested by authors.
  • Level C: "Full/Everyone" review. Everyone reviews and adds edits/comments in series. In some cases there may be many comments/edits after a 1-2 reviews in which case the most recent reviewer may suggest that it be sent on to the authors with the request for time to review the next version (when the rest of us can read it and in some cases some people re-read it). This level of review is appropriate when the subject of the manuscript is of high interest to our group, when different reviewers will offer different reviewing strengths (i.e. lead data collection, particular expertise in subject, etc), and when the paper is to be submitted to a high-level journal (PNAS, Nature, Science, GRL).
• This is an effort to improve efficiency and quality of the many outside coauthor reviews that our group tends to review. Formulating practical guidance for this task is new (March 2016) and ongoing, so please provide feedback as we learn what works best.

How to organize for review?

• One person is assigned as the review organizer lead.
• Make an Asana task, specify requested return date, add all coauthors from our group, and upload all files sent by authors. (Note that you can forward the email from the authors to x@mail.asana.com, and then search for it on Asana. That way the email body becomes the description, and all the files are already attached to the task).
• If only a pdf is sent and you anticipate substantial text edits, request a text file (preferably Word, but sometimes we have to settle for a LaTeX doc which can be converted into Word for tracking changes/commenting).
• Make a suggestion on level of review needed (A, B, C), potential reviewers, and open for discussion.
• After reviewing, upload edited doc with suffix specifying who has reviewed. Make any general comments as needed. Assign to next reviewer.
• When reviews are done, someone emails final version to authors and copy in important text from email into Asana comments thread for the record.
• Move due date to when next review is expected or complete if no further review is expected.

Presentation FAQs

What are the group specifications for BOTH oral presentations and posters?

___ Go over the specifications for papers above and implement any that are applicable
___ File names should always follow the group file naming convention above
___ Include one of the new CU logos on the top left. (Available here)
___ Include the logos of all the relevant funding agencies (including for Fellowships) (Available here)
___ Make sure that you list as coauthors (or in the acknowledgements, if they prefer) anyone who has contributed substantially to the scientific process, or whose data you have used.
___ For preliminary data from others, make sure to ask for permission to show them in the presentation or poster
___ Only m/z (in italics) should be used for MS mass/charge units. m/Q and the Th units are not understood by most folks and are confusing, and you should avoid them while in the group.
___ All axes should start at 0 unless there is a strong reason to do otherwise, and have a zero line
___ (Starting March 2016) All figures in all group presentations and posters should have been sized using the function provided by Harald (HS_RescaleForExport) and then pasted into the document without resizing them at all. The goal of this method is to have consistent graph and font sizes in graphs, which has otherwise been an ongoing headache for the group.
___ All graphs should have this macro executed so that we can find them in the future. But for presentation purposes they should be hidden behind a white box.
___ Dates should be in the format "6-Jan-2014" or similar, not as "1/6/2014", which would be interpreted as 1-June in much of the world
___ When sending draft to Jose, include a statement on your email / Asana that "I have carefully checked this draft against the specifications in the group policies & procedures page, and I believe all are met." (Or explain any that cannot be met and why). Drafts without this statement may not be reviewed.

What are the group specifications for oral presentations?

___ The most important aspect of a presentation is that the length works well to the time allotted. Make sure you know the time allowed (including introduction by the session chair, questions, and transition to the next speaker). E.g. in AGU talks are typically 15 min, but you only have 13 "net" minutes. Typically the material that you can present corresponds to 0.7-0.9 slides per "net" minute (depending on slide complexity, animations etc.).
___ All presentations should have a title slide that states the title, presenter and coauthors, and the location, meeting, and time for the presentation
___ All presentations should have the CU logo on the top right or left corner
___ All presentations should have a small but visible slide number in the TOP RIGHT corner. This can be added from the "Slide Master" view in powerpoint. This allows much faster feedback when preparing the presentation, and also more precise questions at the end of talks.
___ For presentation slides. All fonts in graphs axes, legends, labels etc. should be large enough that they can be read from the back of the room. Same for text in PPT slides. It is easy to underestimate this requirement, the equivalent of Font 18 pt (when typing directly into PPT) is needed. This rule is the one that's violated most often, please do not waste the group's time with axis labels, legends etc. that are difficult to read or unreadable.
___ As a practical rule to test the item above: put a 18 pt text box with the word "Test" on all slides (easiest if you put it on the Slide Master), if any text is smaller than that, make it larger (including graph legends, tickmark labels etc.). Do not show any presentations to Jose until you have done this, as he is very tired of repeating this over and over. This is the absolute minimum size, but larger is typically better if possible.
___ When presenting, remember that the audience tends to get lost in the big picture issues, while the presenter is often focused on 2nd and 3rd-order details. Remember to provide enough "framing" information, and to remind people throughout the talk about what you are talking about.
___ Think about the background that your audience has on your topic. It is your responsibility to keep connecting from where your audience is to where you are talking.
___ For group rehearsals, you need to be able to go through the presentation and tell your story in approximately the right time. Do not waste the group's time by showing up unprepared.
___ Before the conference, rehearsing multiple time to yourself (and sometimes with other group members) helps a lot to deliver a smooth presentation.
___ See these resources with more presentation tips

What are the group specifications for posters?

___ Check the conference instructions about the poster size. AGU is 6 ft wide x 4 ft tall, other conferences typically want narrower (4 ft wide) posters, but this varies a lot. Generally we want to go with the largest poster allowed, noting that the CIRES printer can only print up to 3.5 ft (42 in) wide (as of Dec 2014).
___ Please include one of the new CU logos on the top left.
___ Add a "Take Home Points / Conclusions" box at a prominent location in the poster (e.g. top center)
___ Make sure that the figures print at sufficient resolution.
___ For group rehearsals, you need to be able to go through the poster and tell 2 versions of your story: the 1-minute version, and the 10-minute version.
___ Send a copy to Jose or Doug for a final proofread before printing.

Thesis FAQs

What are the specs for putting together a PhD or Master's thesis?

• The graduate school has some rules listed here, which mainly concern format, fonts, margins etc I think.
• In terms of content, these are the specs for our group:
  • Write a short introduction chapter 1 that explains the big picture where the thesis falls in
  • Chapters 2-X are the papers (published, or advanced enough that a full readable draft can be included in the thesis). Literally the only changes are removing the author list and doing a search of replace for "paper" --> "chapter" and similar words.
  • Sometimes people keep a reference list per chapter (same as the papers), other times they prefer a big one for all chapters at the end, I think both are fine.
  • Then you have a final chapter with conclusions and OUTLOOK FOR FUTURE RESEARCH. The latter is very important, i.e. you are now the expert in the field, so if you had 3 more years to explore related topics that have been uncovered by your work, or if you were going to supervise a student working on those areas or related important areas, what would you advise they do? This is taken very seriously as you are now more expert than your advisor or anyone else on the topics of the thesis.
  • You can download thesis from previous group members or others as examples at this page in the library