Date: Mon, 14 Jan 2013 11:58:05 -0500 Subject: How to write and handle a paper, draft 6 frank.ritter@psu.edu From the future book: "All I need to know I learned in Grad school" [slightly revised, 24sep22/5nov21/22oct21/29sep19/28dec16/20nov16/6jul15/ 2feb15/ 2aug14/ 10 jun 13/ ] We have had some papers come out this year, and I wanted to start to regularise the process and tell you all the explicit and implicit steps of this process. Some steps have been violated recently, perhaps or most likely because people were not aware of them, rather than being lazy or malicious, I hope. If you have 10 papers in process, you might on purpose even, skip steps. If you have one paper in process, you need to do them all. On the other hand, if you have 10 papers in process, some of these steps (e.g., putting figure file names in the paper) become only more important. so, here are some draft notes. ================================ 1. Come up with idea This can happen. Go to talks, read, do your homework. They will come. Listen to Newell's "Desires and Diversions" on YouTube if you need inspiration. Phil Agre's "How to be a leader in your field" would be another useful place to start if you want a place to start. https://pages.gseis.ucla.edu/faculty/agre/leader.html ================================ 2. Draft Ideally, draft title, then draft abstract, then outline, then create first draft. Publication can be approached with a risk-driven spiral model of incremental commitment and getting buy in from stakeholders (Pew & Mavor, 2007). Get feedback, even from yourself but also co-authors and advisors and colleagues, on each cycle. First drafter is usually first author, this is also negotiable. Draft has authors and date and pages, and contact details. Authors are not added until they contribute, even advisors. Digiusto (1994) provides a very useful calculus for computing who should be a co-author. The draft file name should be sensible. I like idea NUM.doc rui-test1.doc for example number increments when changes author or changes majorly backed up daily I do not like ritter-mss20120203.docx as a file name because it does not differentiate papers (at least to ritter), the date format is obscure and obscured (3oct21 is better) and docx can't be read by all word versions (and was deliberately non-back compatible This is changing as Word migrates and now doc is not always readable!) Names like response2.3 really grind my gears. Did I open the right file? Response to what? The use of 'final' in the final name or any changing of a name (e.g., from idea1 to titleV5) except for strong reason is strongly discouraged by co-authors. You can annotate in hidden text on the title page which version got submitted; I got this very good idea from Chad Chae. So, put when submitted in hidden text in the file or '-submitted' IN ADDITION TO the version Use a bibliography tool if at all possible. This may require designating who maintains the references (this turns out to work out ok). The names of the files that give rise to the figures should be put into the mss by the figure as well. (e.g., "Figure 1. something nice (analysis-bobo.xl)," perhaps in hidden text) Figures should note the file the figure came from. The Draft should be read and edited and agreed to by every author. Each draft should/could have some commentators. You may have to call authors if they don't respond to emails -- the FDUCS book notes 30 ways that emails are not received. Before sharing, each time, make the draft as good as possible, particularly if you are a junior author: run through spell (why have readers find something that you can find?) (why have a senior author, with limited time, correct your work and delay your fame?) update citations check for awkward page breaks update abstract and ToC (if it is required, and nearly every time it is useful) It is unhelpful as a co-author to every time note that a correction could be made here, and then not specify what it is. It sucks psychic energy to guess what you mean. In most cases, you are paid with co-authorship to make the suggestion and implement it. Only leave this type of note if you are can see a problem but it is beyond you to fix it. Co-authors should endeavour to give useful feedback each pass, and to check for errors and typos every pass. It is appropriate to call to remind co-authors/advisors/PIs about the request for their comments. Drop box can be useful here, for storing papers, figures, and notes as well as git, svn, and other computational tools, depending on your lab and coordinators. Even OneDrive can be useful. ================================ 3. Re-draft usually share with all co-authors each version ================================ 4. Submit for publication. This applies to tech reports, conference papers, and journal and magazine articles. While writing or at least at this stage, check the journal or conference submission requirements for style and format. Also, check that the journal's call and that the journal's use of the call (ie published papers) match your paper. You should look at the journal you submit to before submitting. Doing so may change how you prepare the mss, including headers, references, and other aspects of what their articles look like. Read a few papers and consider citing some to show ties to the journal and field. As appropriate, you might wish to cite some papers from the journal showing that your work fits in that journal and is like work in that journal. This process can be done earlier, and done again if the paper is not accepted. It should be done, else you will waste your time and their time. On the other hand, journals that require such citations are doing that to gratuitously inflate their impact factor, I'm thinking of IJHCI, and this is foul play. You can do little but complain to colleagues and in media like this. A list of journals to consider can be found in your reference list and by talking with people. Some folks say start writing only with the journal in mind, some say write and then consider the journal. It often varies and often is done concurrently. If the call says that the paper must be anonymised, you must anonymise it. Include a running head on first page (and then on subsequent pages), date of the draft (not the day you opened it!), authors (unless required to be removed by outlet) Do not call a paper file "-final", as this may change. Only use final when you are sure, and that is only after publication. and then, the year or month-year is better. It is useful to note on/in the paper "For submission to NAMEofJOURNAL." This helps you and helps reviewers with multiple papers to review from different journals. Journals that request submissions are usually not a great place to publish. Special issues are another, complex issue that should be seen as slightly less rigorously reviewed, but can be very appropriate based on supporting the topic, editors, or journal. Every author has to approve it before submission. It is very appropriate to call to remind co-authors/advisors/PIs about the request for their approval before submission. If this is difficult, you may have to take advice about how to proceed. This may include further emails, phone calls, physical visits (seriously), requests to friends/advisors to nudge them, and ultimately, removing them and their data (which may kill the paper). If you do not, this has lead to a paper being withdrawn, the paper being rejected, being fired, and losing an advisor and losing a reference and another job. Before submission, make as good as possible. run through spell update citations check for awkward page breaks resolve/remove all comments and tracked changes update ToC (if it is included) make sure figures are included cleanly Provide a cover letter. Typically these say that it is original work, that it is not submitted elsewhere, and that it fits the journal. It might note suggested reviewers if the journal requests them, or folks who have potential conflict of interest with the work. Have to share with: co-authors, advisor(s), project PI (if you are paid), copy and that it was submitted. Upon submission if not earlier: share data with those IRB approved, and particularly with PI and Advisor Consider sharing with sponsor, committee members, interested parties, as appropriate. If you do not hear from the journal/conference in a timely manner, that is, within 2-3 months for a journal article, or within a week of the response deadline for a conference, write to the editor or publication manager. Your mss may have been lost or the reviewers may need a nudge. I would note two examples. One submission took 18 months to come back from a different journal, rejected and thus dead by lack of resources (I had moved on to other projects and the code was not available, it would have been my first journal article), and another was accepted but left out of a conference proceedings in Australia, which I had travelled to present. So, check up on your submissions. ================================ 5. Get feedback from commentators or reviewers or graders if rejected or revise and resubmit, then revise. don't let them sit. if you do this on a 2 months cycle you can get tenure, usually if accepted, go to step 7. Do not assume that the journal is sharing feedback with co-authors. Share results with them same day. Read the response letter carefully. Sometimes there are attachments that are not included that they expect you to use in your revision. Like detailed comments on grammar from a reviewer. Hopefully, they are appropriate corrections. The standard that I use and typically see for response letters is to take all the feedback, and put it into a document. Break it into actionable items. Put them in one style, like, bold, flush left. Put them in dark red. Put your draft response in another style, indented 1/4 inch, normal font. As you draft the response, the request turns to black font. As you change the paper, the author response turns black as well. When it is all black, your revised paper is ready for a final read(s). ================================ 6. Resubmit On final submission if not before, the acknowledgments must include who supported the work or helped the authors. This can include a fellowship or sponsored research. If an equipment grant paid for the hardware, this needs to be noted as well. It also included people who gave substantial comments but not editors, whose name is on it already. e.g,. journal editors, unless extraordinary. You can acknowledge reviewers if they give their names, if not, just 'reviewers'. It should also include informal commentators, research assistants, and people who gave you feedback on a talk. This should be done upon submission or even drafting, but has to be done on publication. The deadline given by conferences is pretty non-negotiable, but there are exceptions. The deadline given by journals is nearly always just a suggestion. Emailing the journal Will typically extend the deadline. Special issues are in between. Deadlines by publishers for books allow up to a year to be late, sometimes more. 5 years is too late, however I have learned to my chagrin. Have to share: with co-authors, advisor(s), project PI (if you are paid), copy and that it was submitted. Consider sharing with sponsor, committee members, interested parties ================================ 7. Accepted tell people same day, put on CV, etc. Have to share: with co-authors, advisor(s), project PI (if you are paid), copy and that it was accepted and where. Consider sharing with sponsor, committee members, interested parties put on your web site that it's up, or even put submitted version up with where accepted added ================================ 8. Get page proofs Corresponding author should share with co-authors the page proofs the same day and ask for help/note what help is needed. If these do not come in a timely manner, which is variable, contact the journal. We have had them sit lost for 2 months (somehow sent out using an automatic system), which did no one any favours. Co-authors have to have the chance to comment. Most won't take it. I almost always do. It is very appropriate to call to remind co-authors/advisors/PIs about the request for their obligation to comment on page proofs. Proofs needs to go back quickly, it is now 'closest to being done' (work on papers closest to being done heuristic, Ritter & Simon, ~1997). Checking page proofs is a high enough priority you can ask for graduate and UG exams to be shifted for you if you are a graduate or UG. (it is also an acceptable form of humble-bragging.) In any case, stay in touch with the journal if you need to delay, which might happen 1/2 of the time and ideally for less than 4 days. There are three ways to check page proofs. (a) look at the paper on the screen, and check your name and contact details, change any "in press" to published papers, and check that there are no glaring errors. Done. (b) read the paper carefully on paper, correct any typos remaining, only correct what catches your eye. You are allowed about 1-2 corrections per page that they did not catch -- The publisher wants the paper to be good at this point. (c) have someone read your paper AS SUBMITTED to you. Eudora, Acrobat, other software, and your lab partner or Special fiend can do this. You will find in too many cases that copyeditors have been too helpful. UK TV shows about cooking, i.e., Chef, and Whites, make fun of waiters for being stupid, including taking orders for eggless omletts. Copy editors will do the same to you. Their grammar skills may not even be as good as yours. For example, in a recent paper, "mandates in public" are not the same as "public mandates". 15" is not 15' / superscript ~ is not the same as ~ / line breaks on cod-ing would be great for a paper on fishing / "Since" is not the same as "because", and "which" is NOT the same as "that". / "which can help" is not the same as "which helps" / "1 way to do this" is not the same as "one way to do this" / "to range differently in image quality" is not the same as "to range in image quality". I try to do a or b, but on the first hint of dopey copyediting, I have to revert to c. You should not do just a. You should look at (inspect, really) a paper printout if at all possible. Have to share: with co-authors, project principle investigator, advisor, co-advisor (optional) ================================ 9. Get published Have to share: with co-authors, advisor, project principle investigator Consider sharing with sponsor, committee members, interested parties Day or week of publication: goes on CV goes on web site, PDF version should be citable this can be done with Word or Acrobat goes to funder (if appropriate) goes into bibliography library shared with co-authors shared with interesting parties (your mom, advisor, reviewer you thought tried to spike it, PI, potential funders, etc.) for this final file, I prefer last name of first author, then initial of all other authors. e.g., ritterRRRRRBE further examples: St. Amant gets SA. Van Rooy get VR References ========== Digiusto, E. (1994). Equity in authorship: A strategy for assigning credit when publishing. Social Science & Medicine, 38(I), 55-58. Pew, R. W., & Mavor, A. S. (Eds.). (2007). Human-system integration in the system development process: A new look. Washington, DC: National Academy Press. books.nap.edu/catalog/11893, checked May 2019. FDUCS: Ritter, F. E., Baxter, G. D., & Churchill, E. F. (2014). Foundations for designing user-centered systems: What system designers need to know about people. London, UK: Springer.
http://www.frankritter.com/papers/how-to-write-papers.txt
www.frankritter.com
CC-MAIN-2023-23
16406
application/http; msgtype=response
sha1:YLJOT3ODL37NJ7QB7Y5CWPEH43FZT4GH
<urn:uuid:e1c13737-15d4-4c51-96e1-1c44837593fb>
2023-06-01T04:33:04Z
64.29.151.221
message/rfc822
sha1:TWEKLTDCJNLI5BFFBSBFNEFM23YETJCN
<urn:uuid:d815b312-ff01-4ac9-af53-134f53584b89>
http://www.frankritter.com/papers/how-to-write-papers.txt
response
<urn:uuid:dd5fd4c8-cd63-47b9-aa64-844a355a8f39>
isPartOf: CC-MAIN-2023-23
publisher: Common Crawl
description: Wide crawl of the web for May/June 2023
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-37
software: Apache Nutch 1.19 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.4-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: https://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/