Panels

The aim of the ICSE 97 panels is to stimulate discussion about ideas and issues of crucial importance to the software engineering community. Panels may emphasize complex technical issues, but they may equally provide an opportunity to propose views and address controversies through the medium of informed debate. Suitable topics for such discussion include pressing issues in software engineering theory and practice, emerging industry trends and enabling technologies, and professional, organizational, and social issues associated with software engineering.

A panel is an interactive discussion. It is essential for the moderator and panelists to design it in advance, for them to prepare fully, and for the moderator to exercise control over the discussion. Too many promising panels turn out to be dreary paper sessions in disguise. We want the panels at ICSE 97 to stick (positively) in people's minds.

Deadline

Types of Panels

Panels last 90 minutes and can be organized in many formats. Several suggestions are provided below. However, we strongly encourage proposals in original formats that will engage the panelists and audience in a lively and substantive discussion.

Analytic Panels

An analytic panel analyzes and synthesizes current practices in the various fields of software engineering. The panelists aim at introducing the audience to new ideas and should therefore be technical experts selected from distinct fields but addressing a single problem. Panelists should address the following questions:

• How do their topic areas complement each other?
• How do we reconcile vocabulary, concepts and notations?
• How can their research results be transferred effectively to industrial practice, and, conversely, how can industrial needs be recognized and addressed by the research community?

The biggest challenge in an analytic panel is to ensure it does not deteriorate into a paper session. It is therefore essential that panelists' ideas are explicitly interrelated and synthesized.

Comparative Panels

In a comparative panel, panelists compare distinct approaches, techniques and models to a particular problem. Panelists should explain why their approach is better than everyone else's (and not merely assert that it is). The panel should aim at identifying the common philosophy among the approaches represented in the panel, and on what crucial distinctions (as opposed to accidental details) their differences depend. A comparative panel should be controversial, but the panelists should treat each other's approaches with respect. Panelists should be technical experts within the same field.

The biggest challenge with a comparative panel is to ensure that the panelists understand and respect each other's approaches and do not see the panel as an opportunity for a sales job. One technique is to have each panelist present "someone else's" approach as positively as possible.

Exercises

In an exercise, the aim is to have panelists solve a small but representative problem, using their chosen approach and with little preparation. In suitable circumstances, the problem scenario could be revealed to the panelists at the start of the session itself. The problem scenario will be selected in advance by the moderator of the session.

The biggest challenges with an exercise are to ensure that the panelists are prepared and that the audience goes away seeing the forest, not just the trees. For an excercise panel to achieve any closure, it is essential that the moderator be able to summarize at the end of the session the key similarities and differences among the panelists' approaches.

Predictive Panels

In a predictive panel, panelists from different fields discuss the ways in which emerging techniques and technologies will affect the practice of software engineering in the future. Panelists should be experts in their relevant fields and should have clear ideas about how work in their fields is influencing the future.

The challenge with a predictive panel is to avoid idle speculation and waffling. The key idea is careful selection of the topic and panelists.

Topics

Panels may address any topic of relevance to software engineering research and practice. Panels are an opportunity to stimulate thinking about how software engineering is evolving. This means that topics need not be limited to the conventional boundaries of the field.

Review Process

Each proposal will be reviewed by the members of the panel committee, who will consist of academics and practitioners. We are looking for stimulating and timely proposals that will be debated by well-informed and engaging panelists and that will form a diverse, controversial, and well thought out collection. Please feel free to contact either panel co-chair in advance to discuss your proposal.

Our criteria will include:

• Clear emphasis on a well-defined topic, and the positions that the panelists are likely to take;
• Relevance of the proposed topic to software engineering research or practice;
• Likelihood of debate and controversy;
• Demonstrated expertise of the panelists;
• Evidence of fresh thinking in the panel format.

In summary, we will ask ourselves whether the average audience member will go away from the panel with new and valuable ideas.

Format

Proposal

A proposal should contain the following:

• A one-page description of the topic, stating compelling issues to be debated, and their relevance to software engineering.
• A one-page description of the panel format (not limited to those specified above), stating how the panel will be conducted and why the proposed format is suitable for the given topic.
• A one-page summary of the organizer(s) and all the panelists, including names, affiliations, telephone numbers, and e-mail addresses. Panelists must have agreed to be members of the panel.
• A half-page position paper from EACH panelist, summarizing his or her view about the topic, the issues it raises, and their qualifications to address the topic.

Conference Proceedings Summary

A summary of each panel will appear in the conference proceedings. The panel organizer is required to collate the half-page position papers (or later revisions of them), together with an introduction into a summary description of the panel. Panelists must agree to the half-page position papers being published in the conference proceedings.

Upon Acceptance

Authors will be notified of acceptance or rejection by the end of November 1996.

Summaries of accepted panels will be published on the World Wide Web in the pre-conference publicity. Panel organizers will be sent an author kit for preparing camera-ready or electronic materials ready for publication. These materials are due 24 Feburary 1997.

Panel organizers are expected to help panelists prepare for participation and coordinate the contributions of the panel.

Ground Rules

1. Your submission must be in English.
2. Electronic and fax submissions are not accepted.
3. Submissions which arrive after the deadline will not be considered.
4. Your submission should contain no proprietary or confidential material and should cite no proprietary or confidential publications. Your submission should not be a demonstration of a commercial product.
5. Responsibility for permissions to use video, audio or pictures of identifiable people rests with you, not ICSE 97.
6. If your submission is accepted, it will not be published without copyright release forms signed by the first-listed author or a representative of the first author's institution.
7. We strongly suggest the use of express mail or a courier service, for speedy delivery. Customs labels should bear the words "Educational materials with no commercial value."

Checklist

Please follow the steps in this checklist to ensure completeness of your submission.

1. Read the Invitation To Submit.
2. Fill out Cover Pages One and Two.
3. Prepare a Panel Proposal in the Conference Proceedings format for publication, as described above.
4. Collect Cover Pages One and Two, the Conference Proceedings Summary, and the Proposal, in the order given, in a packet, and make 6 copies of the packet. Use 8.5 x 11 inch or A4 paper.
5. Make sure each copy of the packet is STAPLED, not loose or held by clips.
6. You may include a self-addressed reply postcard which will be mailed to acknowledge receipt of your submission.
7. Send the 6 copies of your submission packet, and the reply postcard, to one of the Panels Co-Chairs at the Send To address shown below.

Send To

Colin Potts
College of Computing
Georgia Institute of Technology
801 Atlantic Drive
Atlanta, GA 30332-0280, USA

E-mail: potts@cc.gatech.edu
Tel: +1-404-894-5551
Fax: +1-404-853-9378

or

David Leblang
Atria Software
20 Maguire Road
Lexington, MA 02173, USA

E-mail: leblang@atria.com
Tel: +1-617-676-2610
Fax: +1-617-676-2600

For more information