Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Scientific writing

Seminar on scientific writing: everything you need to know about paper publication in academia

  • Be the first to comment

Scientific writing

  1. 1. SCIENTIFIC PAPER WRITING Computer Science Department Universidad Autónoma de Madrid (Spain) http://miso.es @miso_uam Juan de Lara Madrid – June 8th 2020 This project has received funding from the European Union’s Horizon 2020 research and innovation programme under the Marie Skłodowska-Curie grant agreement n° 813884.
  2. 2. AGENDA Part I: Scientific publication Why publishing? Types of venues, review processes, types of papers Ethics, rankings Part II: Scientific writing: the literature part How to organize an article? Some tips Part III: Scientific writing: the technical part LaTeX, BiBTeX, Overleaf Part IV: Scientific writing & reviewing: the practical part Reviewing, Easychair Our writing workshop 2
  3. 3. SCIENTIFIC PUBLICATION: WHY? Communicate science • Makes scientific progress possible • Allows researchers to build on each other results Should be rigorous • Peer-reviewed • Very different from other types of literature • Very different value and trust than a post on a blog Worthy • Each paper should make a contribution • Ensure novelty and progress 3
  4. 4. SCIENTIFIC PUBLICATION DURING A PHD: WHY? Shows evidence of PhD novelty Peer-reviewed publications as a prerequisite for PhD defense • Way to ensure a minimum of PhD quality • Publications as proxies for relevant work • In our department (UAM): two journal publications Get involved with the community • Get feedback from other researchers • Present the work at conference, discuss, exchange ideas • Other researchers can build on your results Essential skill for a successful academic career 4
  5. 5. TYPES OF VENUES Journals • Specialized technical content • Normally unlimited length for papers • Publication typically takes > 1 year • Top in our area: IEEE Transactions on Software Engineering (for SE), SoSyM Magazines • Shorter papers, more informal style • Typically for a broader audience, sometimes professionals (not only academics) • Top in our area: Communications of the ACM, IEEE Software Books • Monographs vs. collections (eg., result of seminars, set of papers on a topic) • Typically specialized, sometimes for teaching (e.g., post-graduate) • Top book publisher in our area: Springer 5
  6. 6. Conferences • On a particular topic • Acceptance rate, limited length • Quicker publication compared to journals (answer in a couple of months) • Conference registration is not free, access to proceedings is typically not free (some open access initiatives, like ETAPS) • Yearly basis, strict deadlines • Top in our area: MODELS, ICSE (for SE) Workshops • On a very specialized (emerging, hot) topic • Affiliated to conferences • More permisive, the goal is discussion 6 TYPES OF VENUES
  7. 7. PUBLICATION ACCESS Open access • Diamond/Platinum: free of fees and access charges (e.g., JOT, http://www.jot.fm) • Gold open access: free for readers. Some publishers charge article processing charges (APCs) or fees (APFs) (e.g., IEEE Access). • Hybrid: closed journals, where authors can pay a fee to make their papers open. Most journals nowadays. Closed • Free for authors, paying for readers • Institutional subscription Green access • Some publishers allow authors self-archive their publication pre-print (e.g., in arXiv, institutional repository, web page) 7
  8. 8. THE PUBLICATION PROCESS 1. Work has been done that is worth publishing: • Improves something relevant (e.g, a more efficient tool) 2. An appropriate venue is selected • Workshop for incipient works • Conferences for more mature works, include some evaluation • Journal for finished works, including extensive evaluation 3. The paper is (carefully) written • What is in the paper is the only way your work is to be evaluated • Don’t expect to write a paper in one day, or even one week • You should position you work w.r.t. related research, motivate the need for your work and demonstrate that your work improves the state of the art (evaluations) 4. The paper is submitted (not done yet!...) 8
  9. 9. 9 4. The paper is reviewed • Anonymous reviewers (other researchers) • Suggestion for changes and acceptance notification 5. Notification • Accept/Reject for conferences [sometimes rebuttal] • Reject/Major/Minor changes/Accept for journals [Major/Minor changes] 1. Paper revision • Improve the paper with the reviewers’ comments • Prepare a letter explaining how you changed the paper and answering the reviewers’ comments 2. Submit revision and Go-To 4 [Accepted] 1. Preparation of Camera Ready • No need to prepare a letter, just submit the sources (e.g., LaTeX) 2. Revision of final paper proofs • As prepared by the publisher THE PUBLICATION PROCESS (CONT.)
  10. 10. THE PUBLICATION PROCESS: PEER REVIEWING Single-blind • Program Committee for Conferences (subreviewers) • Editorial Board for Journals (reviewers) • But reviewing is anonymous: you do not know who has reviewed your paper • Authors are not anonymous Double-blind • Authors are also anonymous (i.e., names do not appear in the paper itself) • Avoids bias • Becoming the norm nowadays for conferences (e.g., ICSE, MODELS) Open • Authors and reviewers are known by all participants. 10
  11. 11. TYPICAL EVALUATION CRITERIA (ICSE’21) Soundness • The extent to which the paper’s contributions are supported by rigorous application of appropriate research methods Significance • The extent to which the paper’s contributions are important with respect to open software engineering challenges Novelty • The extent to which the contribution is sufficiently original and is clearly explained with respect to the state-of-the-art Verifiability • The extent to which the paper includes sufficient information to support independent verification or replication of the paper’s claimed contributions Presentation: • The extent to which the paper’s quality of writing meets the high standards of ICSE, including clear descriptions and explanations, adequate use of the English language, absence of major ambiguity, clearly readable figures and tables, and adherence to format 11
  12. 12. PUBLICATION PROCESS: ETHICS (AS AN AUTHOR) It is not allowed to submit to the same work to several venues • Each paper should contain substantial improvement to previous publications. Proper citations. • It is normal to extend conference papers to journals (>30% increment) It is not allowed to copy phrases from other papers (plagiarism) • Not even from your previous papers (self-plagiarism) • Proper citation, also for images (request premission) It is not allowed to fabricate experimental results • Scientific fraud, criminal consequences • Make data openly available Smell: many authors in publications • “pyramid scam” • Each author should have contributed to the paper • Order of authors 12
  13. 13. PUBLICATIONS: WHERE? Publisher data bases • IEEE Xplorer • ACM Digital Library • Elsevier’s scopus • Springer Link • (most require subscription) Community data bases • DBLP Others • Researchgate (SN-like) • Sci-hub (illegal?) 13
  14. 14. RANKINGS (VENUES) Not every journal or conference has the same quality Conferences • CORE (http://portal.core.edu.au/conf-ranks/) • Acceptance ratios, reputation • A* (ICSE, OOPSLA) – acceptance rates around 10-15% • A (MODELS, ASE, CAISE) – acceptance rates around 20-25% • B (FASE, SLE, SEAA) • C, no rating (ECMFA) Journals • Journal Citation Report (JCR) • Impact based on how many citations each published paper receives • The higher the impact factor, the higher relevance each paper has • In our area: IEEE TSE, ACM TOSEM, Empirical Software Engineering Journal, SoSyM, IEEE SW, IST, JSS • Classification in quartiles (Q1, Q2, Q3, Q4) 14
  15. 15. RANKINGS Beware of predatory journals and conferences They are just a lucrative business • No real quality assessment of papers • You’ll receive a lot of SPAM about these journals and conferences • Never submit! • Will harm your CV and your reputation • https://predatoryjournals.com/journals/ 15
  16. 16. RANKINGS: AUTHORS Number of publications • Quantity  quality Number of citations • How relevant is the work • Depends on the area (some areas, like ML/AI publish much more, and much shorter papers) h-index • h-index = X if you have X papers cited at least X times 16
  17. 17. RANKINGS: WHERE? Google Scholar • Publications, citations • h-index DBLP • Publications Scopus • Publications, citations • h-index Web of Science (non-free) • JCR Microsoft academic • Venues, authors Others • Semantic scholar, researchgate 17
  18. 18. TYPES OF PAPERS Systematic Mapping Study • Analysis of the literature of a given (hot, narrow) topic • Understand what is the state of the art • Map the frequencies of publication over time to see trends • Useful for newcomers into the area • Requires high effort • Main venues: ACM Computing surveys, IEEE TSE, SoSyM, IST, etc 18
  19. 19. TYPES OF PAPERS Research paper • Describes research work done • Should compare with related research (not to the detail of an SMS!) • Long, full, regular: completed research, including evaluation • Short: new ideas, work-in progress, workshops 19
  20. 20. TYPES OF PAPERS Experience report • Challenges faced, approaches taken, observations, and insights when applying a technique to a real problem • Many times linked to application of research to industry • Industrial track in many conferences • P&I track at MODELS, ECMFA, ICSE, etc 20
  21. 21. TYPES OF PAPERS Empirical evaluation • Measure efficiency/effectiveness of a technique • User’s study (e.g., whether tool X is better than tool Y when performing an activity) • Empirical software engineering • Main venues: EMSE Journal, ESEM conference, EASE conference 21 R. Ren, J. W. Castro, A. Santos, S. Pérez-Soler, S. Teresita Acuña, J. de Lara: Collaborative Modelling: Chatbots or On-Line Tools? An Experimental Study. EASE 2020: 260-269
  22. 22. TYPES OF PAPERS Tool demos • Short paper describing a tool • Most conferences have a tool demo track • Typically a separate track in the conference • The idea is to make a demo during the conference • Sometimes a video is required together with the paper 22 Cuadrado, Guerra, de Lara. AnATLyzer: an advanced IDE for ATL model transformations. ICSE (Companion Volume) 2018: 85-88
  23. 23. TYPES OF PAPERS Poster • Very short paper describing an incipient idea • Not presented via a talk, but summarized with a poster • Read by other participants in coffee breaks • Author answers questions of interested people 23
  24. 24. TIPS Be prepared for rejections • Failure is part of the process, but you need to learn from it • Take advantage of the reviewers’ comments to make a better paper • If you cannot cope with rejections, an academic career is not for you: consider leaving the PhD • Everyone has rejected papers Take ownership of your work • Do not expect that your supervisor will write the paper for you Good research needs good writing • Good writing skills are very valuable in a researcher Inspiration exists, but it has to find you working [P. Picasso] • Everyone can have good ideas, but need to be realized • A good paper requires a tremendous amount of work 24
  25. 25. AGENDA Part I: Scientific publication Why publishing? Types of venues, review processes, types of papers Ethics, rankings Part II: Scientific writing: the literature part Dissecting an article Some tips Part III: Scientific writing: the technical part LaTeX, BiBTeX, Overleaf Part IV: Scientific writing & reviewing: the practical part Reviewing, Easychair Our writing workshop 25
  26. 26. DISSECTING AN ARTICLE Title Abstract Keywords and classification terms 1. Introduction • Sometimes another section on motivation, otherwise included in introduction 2. Sections describing the approach (1+) • Typically two or more sections (overview, concepts) • Section on architecture and tool support • Section on evaluation 3. Related Work • Sometimes after introduction, to motivate the lack of works 4. Conclusions and future work References 26
  27. 27. DISSECTING AN ARTICLE Title • Should concisely convey what the paper is about • Avoid long titles • Catchy to call the attention of reviewers and readers • Sometimes a subtitle • Examples: “Datalyzer: Streaming Data Applications Made Easy”, “Refactoring Multi-Level Models”, “Facet-oriented modelling: open objects for model-driven engineering” Authors • Position is important (1st author: most of the contributions) • In our department, PhD students are required to have 2 (journal) publications as first authors • Alphabetical order (depends on research group) • Each author should have contributed to the work described in the paper in some way (ideas, implementation, evaluations, writing, etc) 27
  28. 28. DISSECTING AN ARTICLE Abstract • Summarizes the main points of the paper • Short and to the point, should incite the reader to continue reading • Sometimes limited in length • Structured abstracts (often found in empirical software engineering venues): • Context • Objective • Method • Results • Conclusions 28
  29. 29. DISSECTING AN ARTICLE 29
  30. 30. KEYWORDS AND CLASSIFICATION TERMS Typically 3+ keywords characterizing your work • From general to more specific, like: Model-driven engineering, model transformations, ATL • Help to assign reviewers, and improve search ACM Classification terms (e.g. ACM) • Hierarchy of standard computer science topics • https://www.acm.org/publications/class-2012 • Example: 30
  31. 31. INTRODUCTION (1/2) General goal: introduce the problem you are solving, motivate the work, describe what is in the paper, and its main contributions “funnel shape”: broad at the start (general background of the problem) and narrow at the end (aim of current paper) [1] Perhaps the most important section of the paper • Entices the reader to keep reading • Engages the reviewer, and persuades her to a good score Puts the work in context • May be some short background • Depends on the audience you are presenting the paper to Introduces the current situation • Presents a problem you aim to solve • Why is it relevant? 31 [1] http://www.scientificwritingtips.com/
  32. 32. INTRODUCTION (2/2) Shortly describes the paper contribution • Should attack the problem just presented • Possibly enumerate the paper contributions For incremental work, explain the delta • Always explain the advances with respect to your previous work • Omision of this can be a reason to reject For short papers, sometimes related work is embedded here Finishes with a paragraph describing the organization of the rest of the paper • “The rest of this paper is organized as follows. Section 2, ….” 32
  33. 33. INTRODUCTION An example http://miso.es/pubs/TSE_Merlin.pdf 33 Esther Guerra, Juan de Lara, Marsha Chechik, Rick Salay: Property Satisfiability analysis for product lines of modelling languages. IEEE TSE 2020 (to appear)
  34. 34. MAIN SECTIONS Main part of the paper May be useful to start with an overview section • Describe usage scenarios • Provide a general scheme Architecture and tool support • Very common in SE papers Evaluation • Many conferences, and all journal papers should provide some sort of evaluation • Under some metrics: performance, precision and recall, etc • Formulation and answering of research questions (RQs) • User evaluation for tools 34
  35. 35. MAIN SECTIONS An example http://miso.es/pubs/TSE_Merlin.pdf 35 Esther Guerra, Juan de Lara, Marsha Chechik, Rick Salay: Property Satisfiability analysis for product lines of modelling languages. IEEE TSE 2020 (to appear)
  36. 36. RELATED WORK Compare with existing works in the literature • Position your work with respect to previous ones • Quite exhaustive, but not like an SMS • Explain what is novel in your work with respect to these approaches • Failure to identify relevant related work may imply paper rejection • Group related work on several aspects into subsections • Sometimes finish with a paragraph summarizing the novelty of your work with respect to all analysed related work 36
  37. 37. RELATED WORK An example http://miso.es/pubs/TSE_Merlin.pdf 37 Esther Guerra, Juan de Lara, Marsha Chechik, Rick Salay: Property Satisfiability analysis for product lines of modelling languages. IEEE TSE 2020 (to appear)
  38. 38. APPENDICES Extra information and details that would interrupt the reading flow: • Proofs of theorems in the paper • Listings • Forms used in an empirical evaluation • Additional experimental data Example: http://miso.es/pubs/TOSEM-trm.pdf 38
  39. 39. TIPS (1/2) Follow a clear argumentation line • Approach writing as you would write an algorithm • Know where you are heading to, take the reader there step by step • Do not make large leaps in your reasonings • Document each claim in your reasonings with references Write succinctly, go the the point • Less is more • Avoid long phrases • Avoid long paragraphs • Don’t confuse the reader with long phrases 39
  40. 40. TIPS (2/2) Make clear what is the paper contribution • Write it down explicitly • Don’t expect the reviewer or the reader to figure it out by themselves • Avoid papers of the kind “I’ve don’t this” Show that you are familiar with related work, and explain what is novel in your approach • Novel in results, not in the technique employed • For example: solve a solved problem with MDE is not a contribution. Why is the solution better? Make proper use of • Images, including diagrams, graphics, screenshots • Tables 40
  41. 41. MORE TIPS http://www.scientificwritingtips.com/ https://www.elsevier.com/connect/infographic-tips- to-writing-better-science-papers http://blogs.nature.com/naturejobs/2016/10/28/scie ntific-writing-a-very-short-cheat-sheet/ I fully recommend: “The elements of Style”. William Strunk Jr. 1920 [re-edited up to 2018] 41
  42. 42. AGENDA Part I: Scientific publication Why publishing? Types of venues, review processes, types of papers Ethics, rankings Part II: Scientific writing: the literature part Dissecting an article Some tips Part III: Scientific writing: the technical part LaTeX, BiBTeX, Overleaf Part IV: Scientific writing & reviewing: the practical part Reviewing, Easychair Our writing workshop 42
  43. 43. WRITING THE PAPER No one uses Word • Not professional results • Often perceived as a bad sign of quality • Difficult for collaborative writing • Difficult for version control • Bottom line: don’t use Word for writing papers LaTeX is the norm • Similar to HTML, or to code • Compiled into pdf (pdflatex) • Also possible to compile to .dvi (latex) and then to .ps (dvips), but try to avoid that 43
  44. 44. HELLO WORLD IN LATEX Create tex file article.tex, with content: Compile with: pdflatex article Open article.pdf 44 documentclass[a4paper,10pt]{article} begin{document} Hello world! % Writes Hellow world! end{document} Thanks to: http://www.docs.is.ed.ac.uk/skills/documents/3722/3722-2014.pdf
  45. 45. HELLO WORLD IN LATEX Anything starting by is a LaTeX command • Commands may have parameters • You can declare your own documentclass must appear at the start of every document • Article is the type of document (other possibilities report, proc, book, slides) The text of the document goes between begin{document} and end{document} • Preamble: everything before begin{document} You may need to compile twice to resolve references 45
  46. 46. ADDING TITLE AND AUTHORS 46 documentclass[a4paper,10pt]{article} begin{document} title{My First Paper} author{Your name here} date{today} maketitle Hello world! end{document}
  47. 47. ADDING SECTIONS 47 documentclass[a4paper,10pt]{article} begin{document} title{My First Paper} author{Your name here} date{today} maketitle section{Introduction}label{sec:intro} We will finish in Section~ref{sec:conclusions}. section{Conclusions and Future work} label{sec:conclusions} end{document} Subsections with subsection, subsubsection label to produce a referenciable anchor (via ref{})
  48. 48. ADDING SECTIONS 48
  49. 49. ADDING THE ABSTRACT 49 documentclass[a4paper,10pt]{article} begin{document} title{My First Paper} author{Your name here} date{today} maketitle begin{abstract} A short {em abstract} comes {bf here}. end{abstract} section{Introduction}label{sec:intro} We will finish in Section~ref{sec:conclusions}. section{Conclusions and Future work} label{sec:conclusions} end{document}
  50. 50. ADDING THE ABSTRACT 50
  51. 51. LISTS 51 documentclass[a4paper,10pt]{article} begin{document} % same as before section{Introduction}label{sec:intro} An enumeration of items begin{enumerate} item One item in the list item Another item in the list end{enumerate} An itemized list begin{itemize} item One item in the list item Another item in the list end{itemize} end{document}
  52. 52. 52 LISTS
  53. 53. PAPER TEMPLATES Most conferences and journals require using a certain template, to ensure uniformity • ACM, IEEE, LNCS, Elsevier, Springer are the most common Download the template files and add them to your paper folder Just a documentclass parameter • documentclass{llncs} • documentclass[sigconf]{acmart} • documentclass[10pt,journal,compsoc]{IEEEtran} Templates also bring commands 53
  54. 54. EXAMPLES SOSYM (SPRINGER) 54
  55. 55. EXAMPLES ACM CONFERENCES 55
  56. 56. EXAMPLES LNCS (SPRINGER) 56
  57. 57. HANDLING BIBLIOGRAPHY BibTex: http://www.bibtex.org/ “Data-base” of paper meta-data • File article.bib • Specific format Specific commands in the text to produce citations • cite{paperName} You need to compile with: bibtex article • Several cycles of pdflatex / bibtex may be required • Compiling with bibtex produces a .bbl file (never edit that directly) Other options • Biber 57
  58. 58. BIBTEX FORMAT (CONFERENCE PAPERS) @inproceedings{AroraSBZ16, author = {Chetan Arora and Mehrdad Sabetzadeh and Lionel C. Briand and Frank Zimmer}, title = {Extracting domain models from natural-language requirements: {A}pproach and industrial evaluation}, booktitle = {Proc. MODELS}, pages = {250--260}, year = {2016}, publisher = {{ACM}}, } 58
  59. 59. BIBTEX FORMAT (JOURNAL PAPERS) @article{DalpiazFFP18, author = {Fabiano Dalpiaz and Alessio Ferrari and Xavier Franch and Cristina Palomares}, title = {Natural Language Processing for Requirements Engineering: The Best Is Yet to Come}, journal = {{IEEE} Software}, volume = {35}, number = {5}, pages = {115--119}, year = {2018}, } 59
  60. 60. REFERENCE FORMATS Normally different paper templates will produce different reference formats • References numbered by order of appearance • References numbered by alphabetical order • Authors’ initials instead of numbers: [LGS20] • Authors’ names instead of numbers: (Dalpiaz et al., 2020) No need to change anything, except selecting the appropriate format 60
  61. 61. TIPS Break the paper into files • One per section Put images in a separate folder Create folders for: sources of images, auxiliary files Use vector graphics for images • In pdf format when possible Create macros for frequently used elements • Figures, mathematical formulae, etc Number different parts of screenshots • Avoid “the upper-right corner of the figure…” • Better “label (1) in the figure…” Never submit without passing a spellchecker Use lstlisting package for listings 61
  62. 62. LATEX IN PRACTICE Many editors • A basic one + command line • TeXworks (many others) Collaborative editing • Put your paper on a control version system like github • Best option • Conflicts in text are easy to handle • Allows off-line work • NEVER put .bbl, .aux, .log, article.pdf under version control • Use Overleaf (google docs-like collaboration) • You will not see what other people are doing • Requires being on-line • Good for non-techies 62
  63. 63. OVERLEAF 63
  64. 64. AGENDA Part I: Scientific publication Why publishing? Types of venues, review processes, types of papers Ethics, rankings Part II: Scientific writing: the literature part Dissecting an article Some tips Part III: Scientific writing: the technical part LaTeX, BiBTeX, Overleaf Part IV: Scientific writing & reviewing: the practical part Reviewing, Easychair Our writing workshop 64
  65. 65. REVIEWING SYSTEMS Web applications were paper submissions are handled • Easychair, HotCRP for conferences • Manuscript central for journals Support the paper life-cycle • Submit the paper • Assign reviewers • Upload reviews • Notify authors • Submit revisions • etc 65
  66. 66. EASYCHAIR 66 http://easychair.org
  67. 67. SUBMITTING 67
  68. 68. SUBMITTING 68
  69. 69. REVIEWING Carefully read the paper A review is made of • A score [-3..3] (strong reject to strong accept) • A confidence • The review text The review text normally includes • A summary (shows that you’ve understood the paper) • Positive and negative points on the paper • Major concerns • Minor concerns, typos Always use a positive tone, and include suggestions for improvement 69
  70. 70. PUBLICATION PROCESS: ETHICS (AS A REVIEWER) Constructive reviews • Don’t take advantage of being anonymous • It’s not your paper • No need to be rude Give proper attention to the paper • Carefully read the paper • Prepare a detailed review, as you’d like to receive for your own paper Don’t use reviewing to your benefit • Suggest citing your papers (only if it is appropriate) 70
  71. 71. OUR WRITING WORKSHOP We will emulate the whole process of a workshop You’ll need to: • Write a paper • Review each other papers • Revise the paper The goal is to • Learn to write a paper • Learn to write a review • Write the draft of your LowCode’20 workshop submission Of course the outcome of this writing workshop does not ensure acceptance at LowComote’20 • For the LowComote’20 you’ll probably receive help from your supervisors 71
  72. 72. THANKS! Questions? Juan.deLara@uam.es 72 http://www.miso.es modelling & software engineering research group

×