Call for Papers: WOW-SYS 2004

The First Workshop On Working distributed SYStems

Time and Place

There will be two technical sessions:

• Session One: Tue, 30 Nov 2004
• Session Two: Thu, 2 Dec 2004
• Location: CSE Conference Room
• Accomodations: Comfy chairs
• Registration: Free!

Topics of Interest

• Data aware biomolecular computations via grid enabling data control primitives.
• Distributed firewall policy analysis.
• Process migration via remote fork.
• Support for parameter sweeps in a fault tolerant, massively parallel, peer to peer simulation environment.

Important Dates

All materials should be turned in at the at the beginning of class period on the date due. Please remember that late submissions are severely discouraged and will be penalized 50% of the available points. Materials submitted after class has begun will be counted as late!

Important Considerations

• 12-14 pages long.
• 10 point font.
• Two columns.
• One inch margin on all sides.
• Must contain at least one brilliant diagram. (preferably more.)

Here is some general advice from the USENIX association:

In a good paper, the authors will have:

• attacked a significant problem
• devised an interesting and practical solution
• clearly described what they have and have not implemented
• demonstrated the benefits of their solution
• articulated the advances beyond previous work
• drawn appropriate conclusions

Here is the recommended paper structure:

• Abstract. Give one hard-hitting paragraph that sums up your paper. Remember that many people will read only your abstract and nothing else. Spend time polishing it so that it is clear, concise, and carries the essential ideas and results of your paper. One way to do this is to write it after averything else, using one sentence to sum up each section of the paper.
• Introduction. Make the introduction accessible to anyone in computer science. Gently lead your reader from a simple compelling idea down into the particulars of your work. Without getting too technical, describe your general approach and give a summary of its strengths and weaknesses. Give an "appetizer" that describes an interesting result from the end of the paper.
• Related Work. Give credit and discuss what ideas underly your work. Of course, build upon the related work that you wrote in your proposal and bibliography. However, you have certainly learned some new ideas and read some papers since that time. Demonstrate that your knowledge of the field has increased since that time.
  Note: Do not simply enumerate papers like this: A did X, B did Y. Instead, identify some overarching structure to the related work. For example, group related work by field: Distributed filesystems have taught us.... But, distributed databases have influenced us in this way... Or, perhaps connect together theory and practice: Lamport's Byzantine fault tolerance [W] is put into practice by X, Y, Z... Think about the historical sweep of ideas, rather than single instances of papers.
• Architecture or Method or Algorithm. Your primary contribution to computer science is an idea and an explanation of its consequences. Explain, in broad terms, the concept that you have developed. Go beyond what you actually built: how could this concept be applied to a wide variety of applications, or settings, or users? How is it better, worse, or different than previous approachs to this problem. What are the limitations to your approach?
• Implementation or Case Study or Status. Of course, there is never enough time to build all of the great ideas that you have. However, you should have built at least one working instance in order to evaluate your idea. Describe what you built. Perhaps it is only one case of the ten ideas you described above. Perhaps it doesn't have all the features of your idea. Describe what you actually did and how it relates to the big picture above.
• Results or Evaluation Evaluate your work critically. Identify the key distinction between your paper and previous work. It could be performance, scalability, fault tolerance, complexity, expressibility, usability, or something else entirely. Find a way to measure the difference. Sometimes this is obvious: performance is measured in time. Sometimes you have to think a little more broadly: software complexity can be measured in development time or lines of code.
  Note: Don't just report the good news. Surely if your work offers a benefit in one area, it will have a price in another area. For example, usability can often be obtained at the price of performance. Don't shy away from the bad news: discussing weakness and limitations frankly makes your paper more interesting and more impervious to criticism.

It is absolutely imperative that authors make sure that they have addressed any issues raised at each step of the project development process. To this end, you are strongly advised to re-read previous feedback several times. Human memory is often leaky. Use your notes and old materials to ensure that you have changed what you have been asked to change. Ensure that you incorporate all that you have learned from the following sources:

• Feedback from the annotated bibliography.
• Feedback from the project proposal.
• Questions raised during your midterm report.
• Issues discussed in both meetings with the instructor.
• Advice (both direct and indirect) from the peer reviews.
• Questions raised during your final talk.

Peer Review Process

We will be using a peer review process in order to turn good draft papers into outstanding final papers. After submitting a draft, you will receive (at least) three reviews: one from a peer in this class, one from a peer outside of this class, and one from the instructor. Of course, you will write some reviews for other students. Only the instructor's review will determine the grade of your draft paper. The additional reviews will provide valuable feedback that you must apply to your final paper.

In order to allow each reviewer to speak candidly, peer reviews will be single blind. This means that the identity of each reviewer will be concealed from each author. If any author should ask another whether he or she was the reviewer, the proper answer is always no.

Writing Reviews: Each review must use this reviewing form. You should plan to spend about one hour digesting each paper, and each review should be about one page worth of text. (To make sure that you do a thorough job of reviewing, a small fraction of your draft paper grade will reflect the quality of the reviews that you have written.) Just as if you were preparing for class, you should read each paper at least twice: one for an overview, and again for details. Summarize the paper to demonstrate that you actually understood it. Provide detailed and constructive comments that will help the author to write a better final paper. If the subject matter is a little out of your area, provide suggestions for making the paper more accessible to a non-expert like you.

Reading Reviews: Consider peer reviews to be a golden opportunity. They are an early poll of how readers will react to your paper before you deposit the copy that counts. Often, reviews vary widely: for the same paper, one reader might love it, and another might hate it. This is quite normal. Don't take it personally.

It is important that you seriously consider the feedback from all reviewers. Naturally, you will apply any suggestions that you agree with. But, what if the reviewer was wrong about a certain technical detail? Don't assume the reviewer is dumb: emphasize, clarify, or repeat the detail so that no future readers could possibly get it wrong. What if the reviewer didn't even get the main point of the paper? Don't assume the reviewer is dumb: clarify or extend your introduction so that every future reader will be gently guided to your main point. What if the reviewer suggests some enormous task that you don't have time to accomplish? Don't assume the reviewer is mean: address the idea and discuss why it is not feasible (or not a good idea.) Every objection of the reviewers must be addressed in some way.

Good luck and happy writing!