The Charter Recommendation, submitted by the Charter Committee to the standing Steering Committee, at International Symposium on Software Reliability Engineering, (ISSRE) Denver, 2003. ISSRE is sponsored by the Technical Committee on Software Engineering, IEEE Computer Society.

Ram Chillarege, Chair, Chillarege Inc.
Karama Kanoun, LAAS, CNRS
Yashwant Maliaya, University of Colorado
Veena Mendirata, Lucent
Norm Schneidwind, Naval Postgraduate School

Charter

1. Steering Committee (SC)

·         The responsibility of the SC is to lead the conference on a long term basis. This includes implementation of this charter, the selection and of conferences for future years, and setting overall goals for the direction of this conference and technical community.  While the primary task of the SC is governance of the conferences, it should also play a mentoring role in the conferences, and not purely delegate the responsibility to the GC and PC of a particular year.

·         Member Tenure 4 years, maximum two consecutive terms.

·         Recommended Size: 9.

·         Five (5) members are appointed by the committee.

·         Four (4) members are selected by election.

·         Elections and/or appointments are to occur every two years.

·         The electorate are those who have served in an official capacity at an ISSRE conferences in the past 5 years.  Official capacity is defined as those who have served on the roles of an ISSRE "conference committee" or "program committee".

·         Election is administered by a committee appointed by the SC.

·         The SC membership should maintain a mix of people from Industry and Academia.

·         The combination of appointment and election is designed to bring in distinguished members while keeping the process open to all.

·         Appointments should be used judiciously to bring in distinguished individuals who will strongly contribute to the SC.  The election keeps membership open to individuals in the community.

·         The Steering Committee should strive to recruit into the SC members that are leaders and visionaries who can impact the development and growth of the Software Reliability area and symposium.

·         Seeding the new SC in 2003:

·         This committee will appoint 5 members with staggered terms ranging from 2 years to 4 years.

·         Elections for the additional 4 positions will occur in 2005. Staggered terms of 2 years and 4 years will be by ballot.

2. Election of the SC Chair

·         The Steering Committee Chair is elected by the Steering Committee.

·         The SC Chair must be a visionary and leader who can positively impact the Software Reliability Engineering area.

·         The term of the SC chair is 4 years.

·         Logistics:

a.      The new chair announcement and term begins at an ISSRE conference.

b.      The past chair is available as an advisor for one year.

3. Area Chairs (AC)

·         Tenure 3 years, thereby having an influence and continuity across conferences.

·         Appointed by Steering Committee.  These appointments cannot be changed by the GC or PC of a particular conference.

·         Performance Review after 1st year.

·         Examples: Fast Abstract Chair, Practice Day Chair, Student Papers and Travel Grants, Keynotes Char, and geographical area chairs.

·         Responsibility - to develop an area for the conference.

·         Transitions - ideally through mentoring the new chair.  Example that displays this transition: Fast Abstracts - Ram did this for three years, and Sachin Garg assumed this responsibility in 2003.

4. General Chair (GC) and Program Chair (PC), and conference selection

·         GC submits a proposal to chair a conference - SC will make a sample proposal available, illustrating rationale, resources and a conference team that has the credabilility to execute.  The GC should have prior leadership experience in ISSRE, or be appropriately teamed.

·         The GC can recommend potential Program Chairs to the SC.  Final decision is by the SC.

·         The composition of the Program Committee should change year to year balancing bringing in new people, and maintaining continuity.

·         The role of the GC and PC is the execution of the specific conference they are chosen to lead. The GC and PC of a future year must be active in the current (or prior) year's conference, in some capacity, so as  to gain experience.

·         GC should have served as a PC member to qualify.

·         Conference selection can be up to 3 years in advance, and no less than 18 months.

5. Location

·         Location should be practical to facilitate growth and quality of the conference.

·         Given the current membership, the conference should periodically be held in US and non-US locations.

6. Industry - Academia Mix

·         Maintain or elevate academic position.

·         Focus on strong Industry interaction and application

·         Create programs and tracks that focus on Academic Need

·         Create programs and tracks that focus on Industrial Need

·         The two can be separate tracks - on separate days, so that they allow greater interaction and synergize, not compete.

7. Balancing Research and Practice

·         Balance the research program from the practice program

·         Distinct programs for research and practice should be visible

·         Each should excel in its own space and domain

·         Appoint chairs and sub program committees to manage them by their own standards.

·         The tendency to become a "research only" conference as a channel for academics to publish "respectable" papers and suit the needs of only the academic community should be limited.

·         At the same time, the alternate tendency to become a practice only conference should also be balanced.

·         The conference should compare itself to the most successful conferences as a benchmark.  Examples being OOPSLA, ICSE, DACS, that have gained industry and academic respect and should be looked upon as models.

8. Growth

·         Focus on growth through programs that draw people.

·         Initiatives such as FastAbstracts have demonstrated significant impact.

·         Practice day Day has also been a successful program

·         Student travel grants have been seen to work.

·         SC should review and introduce such initiatives for growth.

·         Goal is to reach 250 participants as a minimal target.

9. Coordination with other conferences

·         Should be considered as a regular review item.

·         Minimally, co-locating conferences is a good thing, but so far has not been very successful.  This is an item for review by the SC.

10. SC should produce a state-of-ISSRE report every two years.

·         It should be a self evaluation against the goals set forth and review of successes and failures.

·         The Area Chairs should write about the area, its technial significance and industrial impact. (deleted: 11/21/04 paragraph on what and why the areas are important.  Ideally this should be data driven, not mere academic passion).

·         Input from an industrial board would be excellent. While an industrial board has not been recommended, it is the type of structure that can help ISSRE have greater impact in the area.  Work towards such panel for advice and counsel is welcomed.  As a first step is to bring into the steering committee members with such experience.

11. Broadening of Agenda.

·         ISSRE should help develop a program with breadth that encompasses a variety of topics that contribute to evaluation, design and improvement of software reliability.

·         Examples are: Software Testing, Process management, and Design which influence Software Reliability. 

·         The appointment of AC that can help us achieve breadth.

12. Operations and Efficiency

·         Codify the best practices so that we improve ourselves.

·         Mentor likely candidates for new chair positions and coach them on roles.

·         Conduct post-mortem after a conference so that mistakes are not repeated.

·         Key leadership should have prior ISSRE experience.

·         Recognize success and failures.

13. Tutorials

·         Focus should be on education, involving both practice and research.

·         Area chair's (e.g. Tutorial chair) responsibility is to conduct needs assessment and  advise PC

·         Selection of tutorials is not only by submissions.  Seek tutorials that satisfy needs.

·         The value and viability of tutorials has been questioned, since they have not been very successful in the recent years.

14. Document of Practices

·         The SC should develop and maintain a Document of Practices which can serve as a rule book and guide to organize ISSRE conferences.  This document is a resource available to each GC and PC, so we do not re-invent the wheel each year.  It also helps us maintain a certain standard that is beyond the scope of individual mentoring.  The practices should be public, so that the attendees of the conference can also examine the standards and processes that are used to select papers, run the conference and develop the area.

·         For example, we have initiated the publication of a second proceedings that include FastAbstracts and Industrial papers.  The criteria for what papers constitute (deleted: make it) these proceedings and how they are published should be codified, drawing from the experience from the past few years. (deleted: .. especially, since we have now over the past few years streamlined the mechanism.)

·         At a minimum, the following list of practices should be documented. The task can be assigned to someone with recent experience in the process, but reviewed and endorsed by the SC. Periodically, they should be reviewed, and enhanced, and in the meanwhile the processes managed with minimal deviation from them.

a.      Selection of Conference

b.      Selection of PC members

c.      Review methods for research papers

d.      Review methods for Fast Abstracts

e.      Review methods for papers submitted for the Industrial Day

f.      Publication of the IEEE proceedings and the Supplimental proceedings, and selection of papers to each mechanism.

g.  Invited keynotes - standards, methods, practices.

h.      Management of conflict of interest.

15. Re-review of the Charter implementation.

·         Two years from the acceptance of this charter, the SC should appoint a committee to take stock of its implementation.

Revision: 10/29/2004
Editorial changes: 11/24/2004 identified with delete markings and strikethrough of changed text.

© 2004.Chillarege Inc • Contact Us • Hosted for ISSRE, IEEE Computer Society •