Introduction OOPSLA'99 invites high-quality papers describing research and/or experience with object technology. Research papers should describe work that offers a significant contribution to the state of the art. Experience papers should describe broad insights gained from practical application of object technology--of use to other researchers and practitioners alike. Both kinds of papers are expected to make substantial, lasting contributions to the field. (Practitioner's reports offer another outlet for describing practical experiences with object technology. Practitioner's reports are more appropriate for describing anecdotal experience with a single system, while experience papers are more appropriate for scientific evaluations of experience with many people and systems.) The program committee will evaluate both research and experience papers using the same standards, based on their relevance, significance, generality, correctness, and clarity. Some suggestions for writing good papers may be found here. Relevant subject areas include, but are not limited to, language design and implementation; frameworks; design patterns; reflection and metaobject models; object databases and persistence; distributed, parallel, or real-time systems; analysis and design methods; software engineering practices; object testing and metrics; programming environments; theoretical foundations; and experience with object-oriented applications and systems. Questions about the relevance of a paper may be addressed to the program chair at oopsla99@sei.cmu.edu. A submission consists of two parts: cover-page material and the paper. Cover-page material includes the following information: The cover-page material should be sent in a plain-text e-mail message to oopsla99@sei.cmu.edu. It should also be included on the first page of the paper. The second part of the submission is the paper itself. Full papers, written in English, are required, to be received no later than 1 April 1999. The submission deadline is firm: unlike some previous years, no extensions will be granted and no late papers will be accepted. Papers must be no longer than 10,000 words (not counting figures, tables, and references) and 20 pages (1.5-spaced in 11-point font, excluding references); overly long papers will be rejected outright by the program chair. We prefer that the paper be submitted electronically via email to oopsla99@sei.cmu.edu, formatted as an Adobe Acrobat [.pdf] file or a PostScript document printable on US letter-sized (8.5"x11") paper. The cover-page material and the paper may be sent in the same e-mail message. We will not attempt to debug printing problems; if a submission does not print successfully, the submitter will be notified and must then send six copies of the paper by overnight express mail. If electronic submission is not possible, then six copies of the paper (printed double-sided if possible) should be mailed to the following postal address: Linda M. Northrop Faxed submissions will not be accepted. Here are some tips, advice, and pointers on how to write a research paper. Some are aimed at OOPSLA papers, while others were originally targeted to other forums. Most advice is universal.
Introduction Practitioner Reports are an integral part of the technical program of OOPSLA, providing discussion of project experiences of object-oriented technologies to a large group of peers. They are definitely not research presentations. Our expectations, beliefs, and fears can be validated, or dashed, by the experiences that are reported by real projects. For many OOPSLA attendees, these reports are the most important part of the conference. Prospective speakers are invited to submit a 4 to 12 page description of their project experiences and intended presentation of those experiences. This report should clearly identify, and discuss in detail, the issues that represent the main contribution of the talk. Reports with project metrics supporting their claims are particularly sought, as well as those that show both benefits and drawbacks of the approaches used on the given project. The submission must include a short abstract suitable for inclusion in the advance program if it is accepted. The review process for Practitioner Reports requires personal contact with potential presenters; therefore, submissions must include contact information for a primary contact including postal address, telephone and fax numbers, and electronic mail address. You (the primary contact) will be contacted at least 3 times during the selection process: If your talk is accepted for presentation at OOPSLA, you will be expected to provide both an advance copy of the presentation for distribution at the conference, and a 2-page summary to be published in the OOPSLA companion. Because of tight time requirements, your initial submission is expected to be complete enough for both a decision, and if accepted, publication of information in the advance program. A complete submission must be written in English and have the following information: The submissions can be sent by paper or by PostScript to: OOPSLA'99 Fax submissions will not be accepted. Electronic submissions must consist of straight 7-bit ASCII with less than 60 character lines, or a conforming version 3 PostScript file for 8.5"x11" paper, whichever is appropriate to your content. The OOPSLA'99 admin. office will not attempt to debug PostScript problems. Submissions that do not print will be returned to the submitter who will than have the opportunity to FedEx a physical copy. Questions should be directed to the OOPSLA '99 Practitioners Reports Chair at oopsla_prac_rpts@acm.org Practitioner Reports are due in the OOPSLA '99 Office no later than 1 April 1999. You will be notified of acceptance in mid May. For accepted reports, advance copies of the presentation and the write-up for inclusion in the OOPSLA addendum are due by 9 August 1999. A practitioner's report ideally tells an informative story on some aspect of the development, delivery, design, or architecture of a significant object-oriented application. The best papers present two - four points from a single focused topic or case study and include some reflection on broader issues. On the other hand, research papers disguised as experiences gathered in an academic setting and papers discussing the implementation of a commercial product that are thinly disguised advertisements are inappropriate. Many potential authors with valid experiences don't know how to write a technical paper for a conference. The key to a good practitioner's report is to present the experiences and ideas clearly and succinctly. Practitioner's reports needn't mimic the style of a research contribution. For example, extensive citations or discussions of areas for future research aren't appropriate. However, practitioner reports should include the relevant facts, sum up key points, and cite related ideas/approaches when appropriate. They also must present enough details so that others can understand, relate to, and benefit from the experience. Practitioner's reports should assume that their audience understands object technology, current methods and practices. It is appropriate to assume that the audience does not know much about the application area discussed in the paper, and that they don't wish to. The audience is more interested in the important aspects of application/technology development that are affected by the use of object technology. Ideally, the paper should present lessons learned that can be easily compared with others' experiences. Presenting a balanced view of both positive and negative aspects of the experience can be illuminating. Many submissions fall short of their potential simply by attempting to cover too much ground. A good rule of thumb is to center the report on the two to four main insights gained from the experience. For example, when presenting a case study, it isn't necessary to include coding examples. When discussing a project history, it is appropriate to summarize the highlights and perhaps amplify a few key points. Including too many low level technical details is generally not interesting. New techniques should be presented in a abstract form which is obviously applicable to multiple languages. Papers solely discussing detailed language specific techniques are more appropriate for a language specific conference or journal.
Tutorial Submission Guidelines Overview One of the hallmarks of OOPSLA is the breadth, depth, and high quality of its tutorial program. Traditionally, OOPSLA tutorials have covered all aspects of object-oriented technology from introductory surveys to industrial software engineering practices to leading-edge research topics. For OOPSLA '99 we especially encourage proposals for innovative tutorials - tutorials that depart from lecture-style delivery, or tutorials on highly advanced object technology. Anyone considering submitting a proposal for a tutorial should carefully review these guidelines and follow the process outlined. To be considered, Tutorial Proposals must be in the format described below. All submitted Tutorial Proposals will be evaluated by the OOPSLA '99 Tutorial Committee. The OOPSLA '99 Tutorial Committee consists of people from industry, academia, and industrial research, all with extensive experience in object-oriented technology. The evaluation criteria they will apply to select proposals and to weed out competing proposals on the same subject are, in priority order: Upon concurrence with the OOPSLA '99 Conference Chair, the Tutorial Chair will send notification of acceptance or rejection. Accepted tutorials will become part of the OOPSLA '99 Tutorial Program and will be described in the Advanced Program using the text submitted in the tutorial proposal. Camera ready and electronic tutorial notes for participants will be required by a date stipulated in the acceptance notifications. Though the above five tutorial proposal review criteria may seem obvious, we would like the OOPSLA '99 Tutorial Program to be the best yet. So it is worth elaborating on the second criteria, namely completeness and quality of the tutorial proposal. Completeness Solid Content OOPSLA tutorial attendees expect material that is correct, specific, and original. They want to leave the tutorial with new knowledge about your corner of object-oriented technology. They have real problems to solve and are attending your tutorial because they expect to receive information that they could not simply obtain by reading the latest paper on the subject. A synthesis of work in an area or comparison of techniques provide the attendee with a basis for decision making. Kernels of new ideas in object technology or early experiments with object innovations give attendees insight into new technical areas that they can mature for their own research or application needs. Case studies of real projects are also particularly interesting and add transferrable specificity to technical concepts. Commercially or sales-oriented presentations are never acceptable. Effective Delivery OOPSLA attendees choose a tutorial to receive information on a well scoped subject that is distilled, packaged, and delivered in a way that short cuts the traditional book learning process. Effective delivery is not accidental. The quality of the tutorial materials and the instructional skills of the tutorial speaker(s) are key. Projected instructional material should be capable of being viewed in large (100-200 person) room. Individual slides should be simple and quickly understood. Diagrams should contain just the necessary information: not too much, not too little. Computer screens or screen snapshots are unreadable without using large fonts. Presenters should be well prepared and should communicate concepts and examples in a way that permits frequent interaction with the audience. The presentation should enhance the visual materials not just reiterate them. For OOPSLA '99 we are interested in proposals for innovative tutorial delivery. Appropriate Expertise The attendees not only expect the tutorial material to contain distilled expertise, but they also expect the tutorial speaker(s) to be experts in the field and to be able to answer a wide variety of questions. Moreover, the attendees rely upon the tutorial descriptions to match their own expertise level with their tutorial selections . Tutorial content and presentation should be primarily targeted at the one of the following expertise levels and that level should be clearly stated in the tutorial description. OOPSLA Tutorials are classified in expertise levels: Tutorial proposals will be submitted through the web. From the tutorials submission page, the submitter will enter all necessary information. The submission will not be accepted if not all of the required information is entered. The information to be submitted will either be entered directly into a web page form, or the submitter will be able to import a file with the necessary content. The web submission system will be able to handle PostScript, PDF, Microsoft Word, and HTML. Each submitted proposal MUST include the following information: Cover Sheet including Tutorial Description and Brief Bio This is the advertising copy for the Advanced Program. The cover sheet includes each speaker's name and affiliation, as well as the contact information (phone, email, postal address) for the primary contact person. It also includes a classification of the tutorial level (introductory, intermediate, advanced, or expert) as well as a listing of any prerequisite knowledge that attendees should have. The submitter will designate a topic area of the tutorial and whether it is intended as a half day or full day tutorial. The tutorial description will be edited by the Tutorial Committee to maintain consistency among entries, but due to publication deadlines, presenters will NOT get an opportunity to revise text after the original submission. Make the description complete, descriptive, and less than 200 words total. The description should have THREE parts : abstract, tutorial objective, and attendee background. The abstract should briefly describe the tutorial content and presentation style. The tutorial objective should state succinctly what the attendee will understand, learn, or be able to do after taking the tutorial. The attendee background should state clearly all assumed participant knowledge or skills. See Section VII for examples. The brief biography should be no more than 150 words to summarize the presenter's resume. NOTE: Tutorials always sell out. There is no need for proposers to worry about making their tutorial sound wider than it is to attract more people. On the contrary, precision in the description is more likely to gain acceptance than is vague broadness. Content Outline The outline should illustrate the scope, both breadth and depth, of the tutorial. The estimated time to be spent on each major item should be noted. Significant examples, case studies, or exercises that will be used should be included. A half-day tutorial is three hours broken into two session by a coffee break. A full-day tutorial is six hours broken into four sessions by lunch and two coffee breaks. Half-day tutorials are the norm unless a full day is absolutely needed to meet well scoped tutorial objectives. Presenter Resume A summary of technical and presentation experience for each presenter. References from previous presentations are useful. Be certain to include previous OOPSLA or other conference tutorial experience. The technical experience related to the subject should be highlighted. Tutorial Resume Has this tutorial been given before? (which is different from whether the presenters have given tutorials before). Is so, where? Other material that might be submitted (but is not required) could include: For additional information, clarification, or questions please feel free to contact the Tutorial Chair, Jay Almarode, at oopsla_tutorials@acm.org Tutorial Proposals due to OOPSLA by: 15 March 1999 Below are some examples of the essential and required three pieces, abstracts, objectives, and attendee background, of good tutorial descriptions. These are good examples of the information requested. No endorsement on contents or topic is implied by the use of these examples; they are merely for illustration purposes. Abstract: When the performance penalty of object-oriented systems is mentioned, a common response is to blame antiquated hardware designs for not supporting object-oriented languages as they deserve. To what extent can the performance gap between conventional languages and object-oriented languages be closed using hardware? What architectural changes benefit object-oriented systems, and by how much? There have been many attempts to make hardware that better supports object-oriented programming. This tutorial describes some of these systems, and the extent that they have succeeded or failed in their aims. These systems include the iAPX432, SOAR, Rekursiv, and MUSHROOM, as well as some features from mainstream architectures such as SPARC. Abstract: This tutorial presents techniques for improving, understanding, and expressing object analysis and design models. These techniques include development of: Use Case Conversations, User Navigation Models, CRC cards, object behavior stereotypes, control style analysis, behavior refactoring worksheets, hot spot cards, and flexibility design. These techniques can be successfully applied to augment your analysis and design toolkit, regardless of methodology. This tutorial will be conducted as a hands-on-workshop where we review guidelines and examples to illustrate key techniques, and use the techniques to develop the artifacts. Abstract: There are many issues that need to be addressed before a truly reusable C++ class library can be built. This tutorial will examine these issues from both an abstract perspective (design) and a pragmatic perspective (code). Abstract: As Smalltalk projects grow, they tend to hit the Smalltalk productivity wall - the point at which added resources do not contribute proportionately to project progress. This can happen at any point between three to six or more developers. This tutorial defines the problem, surveys available products, and provides generic and customized practical solutions using Object Technology's ENVY/Developer as a model. Abstract: A project that is using object technology and an iterative development process faces a number of unique issued in order to deal with the project's entire life cycle. This tutorial presents a process framework that can be tailored to a specific project's situation. The tutorial follows a logical order of topics facing projects. Topics include estimating, scheduling, methodology selection, iterative development, and reuse. Specific advice derived from multiple project experiences is given during the discussion of each topic area. Objective: The intermediate level C++ programmer who attends this tutorial will gain experience in the following areas: the design of a minimal public interface; the handling of variable-sized object; the avoidance of memory leakage; the construction of optimally reusable base classes; heuristics for efficient operator overloading; the roles of containment, inheritance, and multiple inheritance in C++ programming; the use of polymorphic vs. Monomorphic functions. Objective: This tutorial is intended to prepare the participant (1) to determine whether an object DBMS is appropriate technology for his or her database needs (2) to understand the technical tradeoffs between relational and object DBMS technologies, and (3) to evaluate the commercially available object DBMS products. Objective: Participants will acquire experience using design patterns to solve real problems. This experience will enhance participants' design abilities by teaching them how to apply design patterns to their own object-oriented systems. Objective: Participants will be acquainted with a comprehensive test plan that integrates the construction process and the testing process, and will be provided with a scalable total process that can be tailored to the size of a project and the degree of coverage required by the application. Background: Participants should be experienced Smalltalk programmers Background: Participants should have a general familiarity with the object-oriented paradigm, preferably being fluent in one or more object-oriented languages. Familiarity with Smalltalk will be useful, but not required. The intended audience is professionals charged with developing or managing instruction in object-oriented techniques, either in a university or industry context. Background: The tutorial is targeted to those individuals interested in the managerial issues that influence the success of object -oriented software development efforts. It is assumed that the audience has some familiarity with the basic concepts of object technology and have begun to worry about how to effectively employ the technology. Background: Basic knowledge of the operational behavior of languages, particularly inheritance and polymorphism, but with no formal theoretical understanding. Only a knowledge of simple set theory will be required; and a willingness to perform certain mathematical substitutions. The tutorial is aimed at software professionals wanting to write type-correct software; language designers wanting to understand type issues in OOP; final year undergraduates and first year graduate students wanting to relate traditional notions of type to OOP. This is the information that you will be required to supply when you submit a tutorial proposal by the web. All information is required unless explicitly marked optional.
Educator's Symposium Submission Guidelines General Information The Educator's Symposium is for professionals who have a vested interest in object technology education and training. This one-day symposium is a unique forum for academic and industry educators to discuss their needs and ideas for incorporating object technology into courses, curricula, and training plans. The Symposium will include invited talks, short presentations, panels, workshop summaries, interactive exercises, posters and other opportunities to exchange course materials. OO educators and trainers from all levels of academia and industry are invited to send submissions. Submissions will be published in the Educators' Symposium proceeding notes. Selection will be based on clarity, originality, technical and educational merit, and, most of all, the potential relevance to other OO educators and trainers (the "reuse value"). The review committee will look for ideas that can be utilized by others at the Symposium (specific ideas for general use). Acceptance of your paper only guarantees that it will be published in the Educators' Symposium proceeding notes. It does not guarantee that the one-day program will allow time to present it. However, all those with accepted papers will have the opportunity to participate in some way in the day's program. Submissions that do not follow the guidelines stated in this document are not likely to be considered for review. Submissions are solicited in the following six categories: 1. Experience paper: "My challenge and how I solved it" There is no doubt that all those in OO education and training face similar challenges. Submissions in this category will present a challenge encountered in an academic or industry environment and a description of an innovative idea that was used to meet that challenge. (Everyone has something to contribute in this category. If you do not wish to submit a paper, please put your idea(s) on a poster. See submission category #6 below.) Submissions must include the following sections: 2. Case study At the ’98 Symposium, many educators expressed the need for case studies to use in their OO courses. Submissions accepted in this category will be published in the Symposium proceeding notes and authors may be given the opportunity to briefly explain their experiences with the case. Submissions must include the following sections: 3. Research paper Submissions in this category will report on a research project that contributes to knowledge in the field of OO education and training. Submissions must include the following sections: 4. Collaborative effort report Teaching and learning OO can be tough without "a little help from our friends." Submissions in this category will describe successful collaborative efforts between instructors (in the same or different organization), between academia and industry, and/or between students. Submissions must include the following sections: 5. Reports of other 98/99 OO education/training events If you are organizing and/or participating in any OO education or training event, such as a workshop, working group, or conference during the year (or at OOPSLA’99), we want to hear about it. (Submissions in this category can include a description of an upcoming event if the event is being held after the March deadline.) Submissions must include the following sections: 6. Mini "poster" All attendees are asked to bring a small poster (3 ft. x 3 ft. or smaller) to the Symposium, to be displayed on boards throughout the room. This is an additional opportunity to share the materials you use in your classrooms (exercises, effective evaluation questions and methods, course materials and handouts, a web page address (with the contents of that page), description of course needs, things you want to brag about or advertise, anything!). Nothing fancy is needed . Proposals are not required . Feel free to grab some materials as you run out the door to OOPSLA and simply tack them up on the boards when you enter the Symposium. OOPSLA'99 The dates for the review process are as follows: The "Educator Scholarship" program will be available again this year. OOPSLA'99 Educators' Scholarships Applications due: 1 July 1999 OOPSLA'99 is proud to announce the availability of scholarships for educators from 2 and 4 year colleges to attend the Educators' Symposium and Conference. These scholarships are sponsored by the Association of Computing Machinery (ACM) Special Interest Group on Programming Languages (SIGPLAN). Scholarship recipients will be reimbursed for the following expenses: Questions should be directed to Mary Lynn Manns, the Educators Symposium Chair at oopsla_edu_symp@acm.org Application materials must be sent to the OOPSLA'99 Administration office at the address shown below. 1. On or before 1 July 1999, complete the application form, and mail it with two signed letters of support (one from your Department Chair and/or Dean and one from another person who can speak about your involvement in teaching OO technology) to: OOPSLA'99 Fax submissions will not be accepted. Electronic submissions should be in one of the following file format: MS Word, PDF, or HTML. 2. Scholarships will be awarded based on the nominee's ability to use his or her experience at OOPSLA to further OO education and training in their educational institution and/or the wider OO community. Notification of scholarship awards will be e-mailed by 15 August 1999. 3. Scholarship recipients must formally accept the award by 31 August 1999. 4. Scholarship recipients must register for OOPSLA'99 using standard procedures no later than the conference's early registration deadline. 5. Scholarship recipients must attend the complete conference, from 1 November through 5 November. 6. Scholarship recipients must submit expense reports for reimbursement of travel and accommodation expenses by 20 November 1999. 7. Scholarship recipients must submit OOPSLA'99 experience reports by 1 December 1999. Demonstrations are an opportunity to display the application of object-oriented technology in real-world situations. It is also an opportunity to share the unique and interesting technical aspects of your object-oriented projects, tools, or systems. Presentations must be in the form of running computer programs, although a brief overview presentation is expected. We are seeking proposals for demonstrations of commercial and in-house applications, as well as academic and corporate research. Demonstrations will be selected on the basis of technical merit, relevance to object-oriented technology, unique features, and feasibility of presentation at OOPSLA. Presenters of accepted demonstrations must be members of the development or implementation team and must keep in mind that they will demonstrate to a technical audience looking for technical content. A word of caution to commercial developers: product marketing or sales presentations are inappropriate for this forum and will not be accepted. Demonstrations of commercial products should be focused on presenting the technical content of the product itself, and must not be related to the commercial aspects of the product. Please submit the following information by the OOPSLA '99 Demonstration deadline (27 July 1999): to: OOPSLA'99 Successful demos will be expected to provide 2 page summary to be published in the OOPSLA companion. We encourage workshops on innovative topics as well as more traditional object technology topics. Possible subjects include: Workshop organizers typically solicit a short position paper from interested individuals, and choose workshop participants based on the merits and relevance of their submissions. Prospective organizers must submit a proposal of up to two pages in length that includes a description of the primary workshop themes, a description of the problems to be addressed, a proposed agenda, and a list of references to other papers, workshops and forums motivating the workshop. Proposals must also include names, affiliations, addresses, phone and fax numbers, and electronic mail addresses of all prospective co-organizers, and indicate a primary contact. Each workshop must have at least two organizers, preferably from different organizations. Proposals must be submitted to the OOPSLA '99 office, at OOPSLA99@acm.org, by March 15, 1999; electronic mail is preferred. Prospective organizers will be notified of acceptance by May 24, 1999. The proposals received are reviewed by the Workshop Committee to determine a high quality and appropriate mix for the conference. Proposals are reviewed against the following criteria: Please note that the proposal must be suitable for use as the abstract describing the workshop in the OOPSLA Advance Program. There is no time in the schedule to make a second pass over the abstract once your workshop proposal has been accepted. Please keep this in mind when you are writing the abstract for your proposal. If you have any questions, please feel free to e-mail the OOPSLA '99 Workshops Chair at oopsla_workshops@acm.org. OOPSLA panels have always been informative and lively and are among the best-attended events at the conference. If you would like to engage large numbers of OOPSLA '99 attendees in debate or discussion of a current topic, we invite you to organize and submit a panel proposal. Panels, debates, and goldfish bowls are sessions that raise important issues and encourage discussion in a variety of ways. A panel presents a specific number of viewpoints, a debate formalizes the presentation of two or more opposing viewpoints, and a goldfish bowl allows numerous viewpoints (including those of the audience) to be presented in a largely unstructured format. For those of you unfamiliar with the goldfish bowl format, it consists of a discussion group initially comprised of specially invited participants encircled by an audience. Spare places in the discussion group are available and audience members may take up these places when they feel they have a contribution to make. Members of the discussion group, including the invited participants, leave their places when they have had their say, making room for new participants. Panels should be fun, as well as informative-creative formats are strongly encouraged. In addition to the formats described above, you might consider a round table discussion, a more dynamic mode of audience participation, a gameshow format or pre-panel input from the audience. The best panels include participants from many walks of life for maximum breadth of perspective. Valuable insights can come from non-gurus! If you have a good panel idea and would like suggestions for panelists or feedback on format, feel free to contact the panels chair at oopsla_panels@acm.org prior to the submission date. Note: final submissions must be complete. Submissions are due no later than 15 March 1999 and should be submitted electronically to: oopsla99@acm.org or sent physically to: OOPSLA'99 Posters are an excellent forum for authors to present work that may be too preliminary for a full paper, or which the authors would like to share in an informal and interactive session. Work that has a strong visual component (e.g., diagrams, and graphs) is especially appropriate for the Posters track. The most successful posters are those that attract the attention of attendees as they stroll past the displays, either during the interactive poster session (generally held during the Welcome Reception) or when relaxing in-between other sessions. Poster authors are required to attend the scheduled interactive Poster session, staying with their poster so that they can discuss their work with conference attendees. These discussions tend to be open and free-flowing, with questions and comments going back and forth between authors and viewers. The session is held early in the conference, to promote continued discussion among interested parties. Some Poster authors post an informal schedule along with their poster, listing times when they plan to be available for discussion later on during the conference. Others leave sign-up sheets for interested viewers to obtain further information. The goal is to develop a poster that encourages small groups of individuals interested in a technical area to gather and interact. Posters are advertised in the Final Program and will appear in the OOPSLA’99 Conference Companion as two-page extended abstracts. The Conference Companion will be distributed at OOPSLA ‘99, so attendees will be able to learn more about individual Posters before or after visiting the exhibit. Proposals consist of a cover sheet, an extended abstract, and a preliminary graphic layout: Note that this abstract must be camera-ready–the abstracts of accepted posters will automatically be published in the Conference Companion. Authors of accepted posters will receive a detailed guide concerning poster construction and presentation at the OOPSLA ‘99 conference. Submit 3 copies (hard copy) of your proposal to: OOPSLA ‘99 Faxed submissions WILL NOT be accepted. Proposals for Posters will continue to be accepted on a space available basis; however, in order to be included in the final program, they must be submitted by: 11:59 p.m. Pacific Time, Monday, 26 July 1999. If you have any questions, please feel free to e-mail the OOPSLA ‘99 Posters Chair at oopsla_posters@acm.org. The purpose of DesignFest is to give attendees the opportunity to learn more about design by actually participating in the process, rather than just reading about it. The DesignFest is not about passively sitting and listening to experts talk about design -- it is about sharpening your design skills by rolling up your sleeves and working a real design problem with others in the field. The DesignFest is neither a design class nor a tutorial; it is an opportunity for designers to sharpen and measure their skills by interacting with their peers. This call-for-participation is for design problems, not participants. Design problems should be sufficiently large that they present an interesting challenge, and yet sufficiently small that the participants can complete a design in a single day. We invite authors to submit problem proposals, especially ones extracted from real-world projects. People wishing to participate in solving these problems (rather than submitting them) should simply sign up for DesignFest on the OOPSLA '99 registration form. When submitting a problem description, you should use the following structure as a guide. A description of a domain. This description can be accompanied by pictures, images, text, videos or whatever. The purpose of this description is to make clear in which context the problem is placed. The text should explain terminology and should be understandable by laymen. All abbreviations must be explained. A description of the program that is wanted. This should state the goals of the program and the required functions. This description should state what the program should achieve without enforcing any solutions. Because of time limitations these should of course be restricted. An indication should be given of performance requirements and capacity. Requirements should be "refutable" statements (at least according to Michael Jackson). Descriptions of interfaces to other systems. This could be header files or file formats. This is of course optional when no interfaces to other systems are necessary. These are references to articles, other similar systems or implementations. Initial submission can be in the form of email (plain text) to oopsla_designfest@acm.org. After the problem is accepted and review comments have been exchanged, it is necessary that the problem author submit their problem in HTML format as an email attachment. Please look at the DesignFest site for examples of HTML formatting. After the problem has been submitted, any changes to the problem should be submitted as differences only (i.e., old form of paragraph followed by revised form of paragraph) unless the problem is still in plain text form. Once we have put the problem into HTML form, we prefer to receive only the changed paragraphs.
Home | Advance Program | Call For Participation | Conference Registration & Information Submission Process | Submission Guidelines | Important Dates | Mid-Year Workshops Conference & Program Committees | Past OOPSLAs & General Info
Submission Guidelines
Important Dates
Format of the Submission
Software Engineering Institute
4500 Fifth Avenue
Pittsburgh, PA 15213 USA
Practitioner Reports Submission Guidelines
Format of the Submission
Mechanics of Submission
485 NE 181st Ave., Suite 463
Portland, OR 97230 USA
voice: +1-503-252-5709
fax: +1-503-261-0964
email: oopsla99@acm.org
Deadlines
Samples and Examples
Tutorial Evaluation Criteria
Make sure that all four required parts of the Proposal Form have been thoroughly completed. There should be sufficient information in the proposal to allow the committee to clearly understand the intended audience, the tutorial objectives for this audience, the technical content plan and the tutorial organization and approach that will be used to achieve the objectives.
Quality
The quality of any OOPSLA tutorial is directly derived from three factors: solid content, effective delivery, and appropriate expertise.
Tutorial Proposal Format
Submission Process
Deadlines
Notification of acceptance or rejection mailed by: 17 May 1999
Camera ready and electronic tutorial notes due to OOPSLA by: 9 August 1999
Examples to Emulate
Example Abstracts
Example Tutorial Objectives
Example Attendee Backgrounds
OOPSLA '99 Tutorial Proposal Checklist
Submissions
Format of the Submissions
Mechanics of Submissions
465 NE 181st, Suite 463
Portland, OR 97230
voice: +1-503-252-5709
fax: +1-503-261-0964
e-mail: oopsla99@acm.org
Important Dates
Nomination Process
465 NE 181st, Suite 463
Portland, OR 97230
voice: +1-503-252-5709
465 NE 181st, Suite 463
Portland, OR 97230
voice: +1-503-252-5709
fax: +1-503-261-0964
e-mail: oopsla99@acm.org
Proposal Review and Acceptance
465 NE 181st, Suite 463
Portland, OR 97230
USA
voice: +1-503-252-5709
Format of the Submission
Mechanics of the Submission
465 NE 181st Ave., Suite 463
Portland, OR 97230
USA
voice: +1-503-252-5709
e-mail: oopsla99@acm.org
Deadlines
Questions
How to Submit Problems
Contents of the Problem Description
Detailed Requirements
Use Cases
References for Further Study
Form of Submission