5
EECS 443 Advanced Operating Systems Northwestern University 5 Paper summary For every paper – a one-page summary due by 11:59PM of the previous day –Paper title and its author(s) –Brief one-line summary –A paragraph of the most important ideas. –A paragraph of the largest flaws – Being able to assess weaknesses/strengths is an important skills –A last paragraph stating relevance of the ideas today, potential future research suggested by the article, etc. Useful references –M. Hanson/D. McNamee, Efficient reading of papers in Science and Technology, 1990/2000 –R. Levin & D. Redell, An evaluation of the ninth SOSP submissions or How (and how not) to write a good systems paper, ACM OSR, 17(3), Jul. 1983.

10
EECS 443 Advanced Operating Systems Northwestern University 10 Content in a Startup Document Problem statement –What’s the problem?, Why does it matter? Who cares? Proposal –What is the basic approach, method, idea or tool being suggested to solve it? Hypotheses –What are the expected effects of the proposed solution? Why? –What are the plausible alternatives & how likely are they? –What’s good/bad about them by comparison with what’s proposed? –What have others done already? What did they learn?

11
EECS 443 Advanced Operating Systems Northwestern University 11 Content in a Startup Document Experiments –What will be done to test out the hypotheses? –How will this confirm or deny the hypotheses? –Why will the conclusion be believable? –What additional equipment or other resources will be needed? Results –What will be the outcome of the work (papers, a working system, a graph, …)? –When? What are the intermediate milestones? –How will we know when they are complete? –What are the measures for success? –How will we know to declare the project a success?

12
EECS 443 Advanced Operating Systems Northwestern University 12 Writing a good systems paper* – Criteria Original ideas –Are the ideas new? A classical problem w/ “implementation” papers –Can you state the new idea(s) concisely? Write each down in a paragraph; use it in the abstract –How do you know? Related work! –What is the problem being solved? Why previous approaches do not work? Is the work described significantly different from them? –Look at oldest/newest work referenced & types for problems Reality –Does the paper describe something actually implemented? If so, has it been used and what have you learned? Else, do the ideas justify publication now? * R. Levin and D. Redell, An evaluation of the ninth SOSP submissions or How (and how not) to write a good systems paper, ACM OSR, 17(3), Jul. 1983.

13
EECS 443 Advanced Operating Systems Northwestern University 13 Writing a good systems paper – Criteria Lessons –What have you learned from the work? –What should the reader learn from the paper? Spell out the lessons clearly. –How generally applicable are these lessons? When stating your conclusions, state the assumptions again. Choices –What were the alternatives considered at various points, and why where the choices made the way they were? A good paper doesn’t just describe, it explains. –Did the choices turn out to be right? and, if so, was it for the reasons that motivated them in the first place? If not, what lessons have you learned from the experience?

14
EECS 443 Advanced Operating Systems Northwestern University 14 Context –Clearly state assumptions & make sure to get them all down –Are they realistic? –How sensitive is the work to their permutations? –If a formal model is presented, does it give new information & insights? A model for its own sake is not very useful Focus –Does the introductory material contain excess baggage not needed for your main development? Avoid the temptation to describe all major characteristics of your system at the same level –Do you include just enough material from previously published work to enable your reader to follow your thread of argument? Don’t assume the reader has read every referenced paper and has them at hand for instant reference But don’t burden them with unnecessarily lengthy abstracts from cited works Writing a good systems paper – Criteria

15
EECS 443 Advanced Operating Systems Northwestern University 15 Presentation –Ideas organized & presented in a clear & logical way –Terms defined before they are used –Forward references kept to a minimum –Have alternate organizations been considered? –Was an abstract written first? Does it communicate the ideas? Avoid passive voice Include a simple statement of assumptions & results Leave discussion & argument for the paper Write abstract & outline before the paper Writing style –Clear and concise; check spelling & correct use of words –Check sentences are complete and grammatically correct –Avoid ambiguity, slang and cuteness avoided –Remember you are asking a favor from reviewers: “Please let me convince you that I have done interesting, publishable work.” Writing a good systems paper – Criteria