Generally speaking, we are looking for papers that span a broad range of issues in the field of object-oriented technologies. Research papers should describe original work that offers significant contributions to the state of object technology. Experience papers should describe general insights gained from object technology practice. In short, we are looking for papers that make substantial contributions to the field and will be useful to researchers and practitioners alike.

CONFERENCE DATES:

Dates for paper submissions:

• Paper submissions due: July 27, 2000
• Tutorial submissions due: July 27, 2000
• Notification to authors: September 11, 2000
• Camera-ready final papers due: December 5, 2000

THE CALL FOR PAPERS:

• Authors must submit a full paper that should consist of a traditional abstract that summarizes the content/ideas of the entire paper, followed by the full paper. It should include references to related work, figures, tables, and graphs that are central to understanding the paper.

• THE NEXT STEP IS VERY IMPORTANT. PLEASE READ CAREFULLY.

  One copy of a full paper, in the PDF, PostScript, MS-Word, or plain-text format, must be electronically submitted using the web form that will be available from the COOTS Õ01 home page

• The web form will also require the authors to provide the following information:
  • The title and authors of the manuscript.
  • The name of one author who will serve as a contact, with regular and electronic mail addresses, daytime and evening telephone numbers, and a fax number.
  • An indication of which, if any, of the authors are full-time students.

• All submissions will be acknowledged.

• The paper should be at least 10 but no more than 15 pages in length. Also, the number of words should not exceed 6,000 words.

• Prizes will be awarded for Best Paper and Best Student Paper.

TO GET A COPY OF THE CALL FOR PAPERS:

A complete copy of the Call for Papers for this conference is available on the Web.

WHAT KINDS OF PAPERS DOES USENIX PUBLISH?

The most important thought to keep in mind when deciding whether to submit a paper is "What will the audience or readers learn from my paper?" We don't expect every paper to report on a major breakthrough, but we do look for something new, potentially useful, and not entirely obvious. Think about how different your work is from previously published papers; it may be good work but if there is nothing new to learn, it isn't worth reading (or writing) a paper about it. Think about how other people might find your work useful; can they apply what you are teaching them to their own systems? And, does your work really improve upon the previous state of the art? Or does it show how other people have been confused? "Negative results" that contradict the conventional wisdom are often as important as positive results.

Trying to decide if something is non-obvious isn't easy (patent lawyers make lots of money arguing about this), and sometimes the best ideas seem obvious in hindsight. However, if several people have done the same thing, and you are simply the first person to have considered writing a paper about it, perhaps it is too obvious.

The Program Committee will also be trying to decide if papers will lead to a good 25-minute presentation. Some papers are just too complex to be presented this way (perhaps you should focus on just one aspect); other papers just don't have enough to talk about for that long. On the other hand, a few rare papers are accepted mostly because the committee expects them to produce an interesting talk, but that might not otherwise merit publication.

Again, when you are writing your paper, keep in mind "what do I intend to teach the reader?" That means keeping the paper focused on one or a few main points. Don't try to cram too many big issues into the paper, and don't fill it up with irrelevant details. But do include enough background for the reader to understand why your problem is important, how your work relates to previous work in the field, and how it might fit into a practical system. Also, provide enough detail for the reader to put your performance measurements in context. It is vitally important to provide a good bibliography, both so that you give proper credit to previous work, and so that a reader can know where to turn to find additional background information. The Program Committee will not look kindly on a paper if the author doesn't appear to be familiar with the current literature.

MORE INFORMATION IS AVAILABLE

Lots of papers and books have been written about how to write a good paper. We'd like to suggest that you read a paper called An Evaluation of the Ninth SOSP Submissions; or, How (and How Not) to Write a Good Systems Paper. This was written by Roy Levin and David D. Redell, the program committee co-chairs for SOSP-9, and first appeared in ACM SIGOPS Operating Systems Review, Vol. 17, No. 3 (July, 1983), pages 35-40.

Although SOSP and COOTS have different foci, Levin and Redell give good advice for authors of any kind of systems paper. The authors have graciously agreed to make this paper available online. You can also retrieve a separate copy by sending email to info@usenix.org, including the line: send advice papers in the body of your email.

We also recommend that you read the proceedings of some recent USENIX COOTS conferences to get an idea of what kinds of papers are published. Not every one of these papers is perfect (or even great), but nearly all of them are better than the ones that were not accepted.

Finally, if you have any other questions, feel free to send mail to the Program Chairs at coots01chairs@usenix.org.

HOW SHOULD I GET MY MANUSCRIPT TO YOU?

Submissions via the form can be made in several formats. While flat text files are often the easiest to view and print, this probably won't work if you have any figures or graphics. If you do use flat text, please remember to format it neatly and ensure that the width of each line is fewer than 80 columns.

We have found in the past that PDF files (readable by Acroread or Acrobat) are often the best means of submitting papers.

PostScript files are also acceptable, but given that PostScript generators vary quite a lot, it is likely that we may not be able to print every submitted PostScript file. For instance, several software packages generate PostScript that can only be printed on Apple Laserwriters. So if you submit PostScript documents, please remember the following:

• Use only the most basic of fonts (TimesRoman, Helvetica, Courier). Other fonts are often not available with every printer or previewer.
• PostScript that requires some special prolog to be loaded into the printer probably will not work for us. Please don't send such files!
• If you used a PC or Macintosh-based word processor to generate your PostScript, ensure that it can be printed it on a more generic PostScript printer before sending it so as to ensure that the PostScript is portable.

Another alternative is to use Microsoft Word; youÕll need to indicate in your form submission which version of Word was used so that we can process it correctly.

If the paper you submit via the web form is missing figures, tables or other illustrations that are present in your original paper, please indicate this with a prominent note and contact the Program Chairs for submitting these illustrations.

Overseas authors should make sure that their abstract prints properly on US-style 8.5x11 inch paper. Please make sure that you leave enough room for top and bottom margins.

Finally, if you have any other questions, at any time during the entire submissions process, especially if you have a paper idea but have concerns about it not being "right" for this conference, PLEASE send mail to the Program Chairs at coots01chairs@usenix.org.

Good Luck,
The Program Committee