A good paper should:

• be informative. The readers of your paper should learn something from it. It should be clear whether readers can apply your work to their own environment, and how they would go about doing so. "Negative results," which contradict the conventional wisdom, are often more important than positive results, especially when backed up by solid evidence.

• demonstrate, to others in the field, the value of the work being discussed. Successful product sales or freely-redistributable source code alone do not necessarily make an idea valuable to the audience. The innovations or techniques that you discuss need not be major breakthroughs in their fields, but should at minimum demonstrate something new, potentially useful, and non-obvious. Your paper should clearly demonstrate any improvements over the previously published work in the field.

• include sufficient references to prior publications or products, along with an explanation of how your paper builds upon or improves upon the related work. The Program Committee expects you to make a substantial effort to find related work, as part of the process of documenting what makes your paper interesting.

• not be marketing literature. While it might be appropriate to show how your product differs from, and improves on, other products on the market, this must be done as even-handedly as possible. The goal of your paper should be to inform other people working in the field, not to sell your product to customers. The Program Committee will be strict about this.

• demonstrate the maturity of the work. The work you describe should be well under way. Most of the design, implementation, and testing should be accomplished by the submission date, since you will not have much additional time before the final deadline. If it makes sense for your paper, you should provide results demonstrating the performance of the work described. The appropriate metrics might include speed, reliability, cost, or something else that people will find useful. However, do not focus on quantitative results to the exclusion of other useful understanding.

• be clearly written. Submissions should clearly describe the ideas, work already accomplished, and work to be completed. We encourage you to use some of the available online writing style guides, if you need guidance in this area. Good examples include: https://www.cs.columbia.edu/~hgs/etc/writing-style.html, https://telin.rug.ac.be/~pds/thesis/sci.html, and especially https://gatekeeper.dec.com/pub/DEC/SRC/publications/levin/SOSPhowto.html.

If you are a potential author in need of more guidance, we encourage you to contact the Program Chair at wiess02chair@usenix.org, or any member of the Program Committee.