You can submit from 23 February 2001 to 23 March 2001. All submissions use an online submission and review process. Different deadlines may apply for other submissions (posters, for example); see the conference web site for details.
Please do not ask for an extension. Our submission system precludes it.
First, please check the page that explains each input field to make sure you followed the instructions. If you still have problems, feel free to contact me.
Can I send you a draft for pre-review?
Yes, but all I can do is skim it quickly and tell you whether it's appropriate for submission in scope and format.
It would be best if you contacted the corresponding committee chair(s) directly. See the OOPSLA 2001 web site to find out whom to contact.
No. Only PostScript or PDF will be accepted. Please be sure that your file displays properly in common viewers such as Adobe Acrobat Reader and GhostScript. PDF is preferable because it is easier for most people to view and print. However, some PostScript-to-PDF converters (and vice-versa) seem to work poorly or not at all, so please check the product of any conversion carefully before submitting it.
Every major word processor can generate PostScript, PDF, or both. On some systems, this is done by "printing to a file." See for example SIGMETRICS' page on producing PostScript or PDF files from MS Word.
For more information about creating PDF across platforms, see for example the NSF PDF instructions and guidelines.
Because no one at ACM headquarters uses Frame, StarOffice, etc., and so they cannot support their templates.
If your paper is accepted, the final version must be in the required format. Life will be easier for most everyone if you use the required format from the beginning. If you must use an unsupported document format, here are detailed formatting specifications. (Margins are listed for USLetter. Adjust approriately for A4.)
|Title||Centered 18 pt, Bold, Helvetica|
|Author, ACM Fellow||Centered 12 pt, Helvetica|
|Affiliation||Centered 10 pt, Helvetica|
|Centered 12 pt, Helvetica|
|Abstract||Flush Left 12 pt, Bold, Times Roman|
|Section (heading 1)||Flush Left 12 pt, Bold, Times Roman, numbered- ex: 1|
|Subsection (heading 2)||Flush Left 12 pt, Bold, Times Roman, numbered- ex 1.2|
|Subsubsection (heading 3)||Flush Left 11 pt, Italics, Times Roman, numbered- ex 1.2.3|
|Subsubsubsection (heading 4)||Flush Left 11 pt, Italics, Times Roman, numbered- ex 220.127.116.11|
|Subsubsubsubsection (heading 5)||Flush Left 11 pt, Italics, Times Roman, numbered- ex 18.104.22.168.5|
|Text||2 column, justified, size of type 9 pt. space between lines 10 pt|
|Text Font||Times Roman|
|Column width||3.33" (8.45 cm)|
|2 column gutter||0.33" (0.83 cm)|
|Top Margin||1" (2.54 cm)|
|Right Margin||From edge 0.75" (1.9 cm)|
|Left Margin||From edge 0.75" (1.9 cm)|
|Bottom Margin||1" (2.54 cm)|
|Copyright space on 1st page||lower left column 1.5" (3.81 cm)|
|Paragraph indentation||Flush Left|
|Footnote/Citation||9 pt, Times Roman|
|Bibliography/Reference||9 pt. Use the standard CACM format for references, i.e., a numbered list at the end of the article, ordered alphabetically by first author, and referenced by number in brackets . Reference number in brackets positioned as a negative indent. Text aligned .25" (0.63 cm) in from margin, ragged right margin.|
|Subsequent pages||For pages other than the first, start at the top margin and continue in double-column format.|
|Tables/Figures/Images||Placed in text as close to reference as possible. May extend across both columns to a maximum width of 7" (17.78 cm).|
|Captions||9 pt, bold, Times Roman, numbered (ex. "Table 1." or "Figure 2.") and centered beneath each table, figure, or image.|
The distinction between research-based technical papers and experience-based technical papers has blurred so much that they're not worth differentiating. (For example, is a paper discussing design patterns a research paper or an experience paper?)
Practitioner Reports are short papers describing particular development projects. They are especially valuable for communicating experiences at the "bleeding edge" of technologymany attendees want to find out what it's like to adopt a new language, use a new methodology, etc.
The submission and review process is also very different for Practitioner Reports. These are solicited, reviewed, and shepherded with the goal of providing timely case studies and insights of interest to developers. In contrast, technical papers are reviewed with respect to more traditional criteria for advancing the state of the art. The Practitioner Report process is designed to help people who are still in the midst of the development projects they're describing.
All kinds! Well, all kinds dealing with object-oriented systems, languages, and applications. OOPSLA is a very diverse conference. See the Technical Paper Submission Guidelines for details and hints.
There are lots of approaches and styles. The following resources list some advice.
Last modified 5 December 2000