Call for Papers: UH-OS 2010
Time and Place
UH-OS 2010 will convene on Friday, December 10th, 2010, at Notre Dame, Indiana.
Students in the operating systems class will present their semester projects.
The proceedings of the workshop will be published on the web.
- Date: 10 Dec 2010
- Time: 9:30AM-12:00
- Location: 116 DeBartolo Hall
- Accomodations: Comfy chairs
- Registration: Free!
Topics of Interest
Any paper in the following topic areas is guaranteed to be accepted by the program committee:
What to Turn In
23 Nov 2010
FOUR Printed Copies of Paper
2 Dec 2010
Two Printed Copies of Each Review; only ONE marked with the reviewer's name.
9 Dec 2009
One Printed Copy of the Final Paper.
10 Dec 2010
Email PPT or PDF to Instructor by 8AM
The paper must be formatted as follows:
- 8 to 12 pages long.
- 10 point font.
- Two columns.
- One inch margin on all sides.
- Must contain at least one brilliant diagram. (preferably more.)
Here is the recommended paper structure:
- Abstract. A good abstract should have five sentences
that summarizes the entire paper from beginning to end.
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 the most important points of the paper:
- The problem to be solved.
- The idea or technique used to solve the problem.
- An indication of why the idea or technique is not trivial.
- The most important technical result of the paper.
- What conclusions can be drawn from the results.
- 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.
Make sure to cite and discuss any papers or systems discussed in class.
Draw on your annotated bibliography where appropriate and supplement with
new papers as needed. How does your work differ from existing systems?
- 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. 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.
- 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.
Important 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.
- Conclusion. Wrap up the paper by reconsidering the big picture.
Describe your work in more philosophical, rather than technical, terms.
Was the general approach successful? Do you have advice for others pursuing this
path? What should the next step be?
- References should be appropriately chosen, consistently formatted,
and detailed enough to allow the reader to locate each reference.
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 project proposal.
- Questions raised during your midterm report.
- Issues discussed in both meetings with the instructor.
- Advice from peer reviews.
Peer Review Process
Keep in mind that the draft paper should be a serious attempt to
write a polished and complete paper, adhering to all of the requirements
given above. It is acceptable if the draft
is missing some final data such as the performance results of an
experiment currently running. However, you may not omit the results
section: you must still include a description of how you are evaluating
the system, what the results may demonstrate, and any intended graphs
or tables with appropriate axes, captions, and keys, albeit minus the missing data.
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 several reviews from your peers in this class as well as others.
Of course, that means you must write some reviews.
The instructors will write an "editor's summary" of each of the reviews
and give comments on what must be done for the final paper.
Half of your draft paper grade will evaluate the quality of your draft paper,
and the other half will evaluate the quality of the reviews that you have written.
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 a full page worth of text.
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.
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 future readers will not miss the point.
What if the reviewer didn't even get the main point of the paper?
Again, do not 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!