Monday, October 18, 2004

Election Discussion

10/18/04
Team, may I clarify a few points about IEEE rules.

1. IEEE Rules say that the TC (Technical Committee) Chair needs to be elected. Now, we are not a TC - just a conference under the Software Engineering TC. The TC chair for Software Engineering is elected.

2. I have modified the current charter, since bullet 2 was erroneously written as TC chair - and we are not at TC, just a conference under the Software Engineering TC. Bill, who has generously served as the SC chair has been in this position probably from the start (15 years ago). To help clarify this, since it was not initially obvious to me, let me cite an example with a sister conference, DSN. The DSN (old FTCS) was a conference and a TC by the same name...thus, FTCS was the conference, and FT was the TC that reported to the Technical Activities Board of the IEEE. We, the ISSRE conference do not report to the TAB, but the Software Engineering TC.

3. I do not believe that the IEEE rules require that the SC chair, or the SC be elected. DSN and IPDS that are very well established conferences do not have publically elected SC members. It will be interesting to check ICSE does, which is the premium conference in our Software Engineering TC. It is prudent for us to get the current IEEE Software Engineering TC chair to weigh in on this. If it not a rule, then this committee is the body to make the recommendation, by its authority.

4. We had a lot of discussion about democracy, election, and executives appointments a couple years ago, and I recall that Norm was for all elected positions, whereas the other members of our charter felt that these need to be appointed. What I put down was a compromise - since I believe there is merit in both positions: appointments for leadership and executive positions gain speed, competence and accountability, while election keeps it open.


Best regards,
ram

==============================================
10/16/04

Norm,

Thanks for your prompt response. However, my main concern was about practical implementation of the election process.

As I am also for complete democracy, I propose that we make a vote on this point!
Ram, could you please consider my suggestion seriously.

Best regards
Karama

=============================

10/16/04
All,

I am for complete democracy! I believe everyone should be elected! If we don't do it this way, we will be at variance with IEEE policy. All the officer positions I know off in the IEEE are elected. All standards boards positions are elected. The ICSM SC memebers are elected. ISSRE is the only body I know off to not use a complete elective process -- undemocratic!

Norm

Saturday, October 16, 2004

Sam

Hi Ram,
Thanks for sharing the ISSRE Charter. I suggest firming up the following, eg.
Said election will take place concurrent with ISSRE or X days after the ISSRE is held.
:
Logistics of election:

a. Around the ISSRE timeframe, to take advantage of the opportunity to communicate the process to people.

b. For instance, the election process could be announced, and/or the individuals can present themselves at the meeting, etc.

See you in two weeks,
Sam



Ram Chillarege wrote:

Karama Kanoun

Dear Ram,
You did a great job! I have only a few comments.
I may confess that I am still some problems about election of 4 SC members. I am sure that this will be a very difficult job in practice, if we would like to do it correctly. If we keep this election process, we have to define it clearly from a practical point of view, right from the beginning. Otherwise it will be an open matter. Moreover, when the conference is outside USA, only few US people will attend.
However if all of you prefer election, I have to accept. But, may I suggest that those who are in favor of election should propose the election process to be discussed among us. I think that it is important to include the way election should be conducted in the proposal. Sorry for this.
Point 4:
As per our previous discussions, I would like to recall my proposal during the last PC meeting(s): "the PC chair name has not to be provided in the conference proposal. It should result from an agreement between the SC and the GC, once the proposal is accepted".
In this way PC chairs are not linked to any specific proposal.
From my point of view, the programme committee members are first proposed by the PC chair(s) to the GC, then recommended to the SC.
Final decision by the SC.
I would also add in point 4:
The GC should have served as a PC member or in a position such as tutorial chair, fastabstract chair ... to qualify.
The PC chair should have served as PC member to qualify.
That is all
Best regards
Karama

Wednesday, October 13, 2004

Michael R. Lyu Review

Ram,

The Charter is quite well done! I particularly like the limited terms for the members in the Steering Committee. I heard complaints that ISSRE SC seldom changes membership. I think the Charter should be implemented as soon as possible.
One question about "GC should have served as a PC member to qualify."
Should we be so stringent? A powerful GC in a foreign country may be high-up and well connected locally, but he/she may not have PC track record with ISSRE. On the other hand, he/she can work with someone with long-term connection to ISSRE. (In fact, he/she may be brought in to ISSRE by them.) Should disqualify such proposals, even though the proposals can be very strong? (The Chater currently does not ask PCs to serve as PC members before.)
Some typos:
1. Under Section 1, SC, the 7th bullet item, "rolls" should be "roles."
2. Under Section 4, GC and PC and conference selection, the 1st bullet
item, closing parenthesis ")" is missing.
Cheers!
-Michael

Friday, June 25, 1999

Feedback from Steering Committee June 1999

Joanne Bechta Dugan 6/24/99

Hi Ram,
I took a look at the ISSRE charter page that you pointed me to. I really like the idea of "area coordinators" and the longer term influence that they can present. The continuity from year to year is important.

Think about integrating the tutorials into the conference, the way that RAMS does. I've been tutorials chair at RAMS for the past several years, so I know the process well. There are about 20 2-hour tutorials spread out over the whole conference. At any given time, there are 2 tutorials, one paper and one panel session. The tutorials are tremendously popular and are a major drawing point (and, some would say, THE reason for the turnaround in attendance (which was dropping precipitously for several years)). Some people ONLY attend tutorials. They get CEU credits (for which they pay). I really think that this is a better model than one day of tutorials preceeding the conference. If the tutorials are "free" (i.e. included in the registration) then (1) the registration fee could be higher (it's about $500 for RAMS) and (2) the attendance would probably be higher. (Note however that the tutorial instructors are "unpaid" (but they get a gratis registration). Also the "tutorial notes" are rather substantial (not just foils) and are (a) distributed to all attendeed and (b) available for sale (and they sell pretty well).

I think you underestimate the effect of location -- a "good" location will help draw people. If I can only go to 1 or 2 conferences a year, and there are several good conferences to consider, I may well be swayed by a nice location (like Florida in december) as long as it's not tremendously expensive. (I think that FTCS madea big mistake in putting FTCS-30 in the heart of NYC at >$200 per night for the hotel and $700 for registration)

I really like the AC proposal and don't think that the PC chair whould see it as a threat.


Thanks a lot. I'll be happy to help if you need it. If there's interest in changing the tutorial model I'll be glad to share my experiences with RAMS. Take care,
Joanne --------------------------------------------------------------------- Joanne Bechta Dugan jbd@Virginia.edu Professor of Electrical & Computer Engineering 804-982-2078 University of Virginia FAX: 804-924-8818


--------------------------------------------------------------------------------


W. W. Everett:

I appreciate Bob's concerns. However, I explained to Bob in a hallway
conversation that his impression is not the purpose of the ACs. He is
repeating his impression of the past chairs panel presentation and not what
I subsequently explained to him. The purpose of the ACs has nothing to do
with setting up fiefdoms and driving a wedge between academe and industry. Rather ,the purpose of the ACs is to ensure coverage by SRE in vital industrial application areas (e.g. E-Commerce) across multiple ISSREs.



Bob Szabo:

During the conference last week, we had a panel session composed of the
prior ISSRE chairs. During the talks, the concept of Area Coordinators was mentioned. As it was explained, we heard the AC's would come to command a permanent program committee. Coupled with mulit-year AC appointments, I can't help but think this will damage ISSRE in the following ways ...

The conference is likely to become less open given the creation of
separate AC fiefdoms. This puts too much power into the hands of a
smaller number of people. The yearly rotation of general chair, program> chair, etc. helps ensure openness.

Separate AC's could ultimately lead to a split between the academic and
industry groups to the point where we may wind up having two separate
conferences. One of the strengths of ISSRE is the bringing together of
these two worlds. We should work hard to preserve this unique
relationship.

In summary, I think we should do everything possible to preserve the joint
industry/academic flavor of ISSRE, NOT split them apart. While the
academic portion seems to operate under a clear set of directions, it is
clear the industry portion is operating on an ad hoc basis year after year.
Perhaps we should focus our energies on documenting a separate industry
program process much like we have for the academic (research) process?




Wednesday, June 02, 1999

Veena - Archive

Email: 6/1/99

Ram:


You/Joanne have done a great job putting together all our discussions on a set of vgs. Here is my input for the recommendations.
- Appoint a SC
- Follow up on the idea of ACs
- Focus on a few specific areas that are relevant and timely, e.g. networks, networking software industry practice of SRE
- what is done in the bigger companies today, what works well, what does not, what is useful in producing reliable software products in a cost-effective manner SRE needs of smaller companies SRE in the context of fast time-to-market products SRE for systems built with off-the-shelf components
- Tutorials should also be in the areas that ISSRE selects to focus on
- Panels should also be in the focus areas rather than on the traditional topics. For example, people have heard the Musa view on SRE many times and can read his books and papers. Need new views and on new topics. (Did not mean to pick on Musa but that example came readily to mind.)

The other slides. Since the slides present the material in our notebooks there is naturally some overlap. I think you have 2 choices here:
- either preface the material appropriately and leave as is so the reader knows what to expect and is not bothered by the repetition; or
- edit the material for sharper focus, this could entail a lot of work and would have to be done by one person.

I am OK with either option. The recommendations are probably the most important and should be concise and specific.


- Veena
--------------------------------------------
VEENA B. MENDIRATTA Bell Labs,
Lucent Technologies, Room IH 5B-403 2000 N Naperville Road, Naperville IL 60566
voice: 630-979-3872 fax: 630-979-9364 email: veena@lucent.com
---------------------------------------------


--------------------------------------------------------------------------------



Notes taken from conference call 2/22/99

Role of industry -


inform research community of their needs
panel where industry presents how they do SRE
traditional large company view
small company/Silicon Valley view

These ideas could be built into the objectives (operational: do A,B,C) and mission (long-term role of ISSRE) of ISSRE *

*Look at other conferences that are similar to and/or have overlap with ISSRE (Norm)

*Some conferences have specific objectives like: - education -> good tutorials - vendor participation, they need to sell products (Ram)

*Balanced growth by focusing on specific initiatives in the conference, e.g.: - SRE for networking - interface with the safety community (Norm)

*Followup to previous idea: - actively seek papers in the chosen theme area - involve the industry players from the area and - educate the practice on the theme (Ram)

*Steering committee should: - look at strategic directions in the industry - have a multi-year perspective - look at long-term initiatives (Ram)

*New conferences are created to meet a need: more people want the role of GC, PC, etc. Can we meet this need in ISSRE, e.g., by creating multiple Area Chairs? (Ram)

*Growth should be a new strategic issue: how should balanced growth be acheived? (Ram)

Saturday, May 29, 1999

Norm Archive

Email 5/28/99

Dear all,

My suggested recommendations, in brief, are the following:
o Create the SC.
o Identify several key technical areas and pursue them with the aid of the ACs. For example, SRE in networks: LANs , Internet, WWW, Distributed Systems.
o Create the role of the AC.
o Appoint the ACs.
o Consider adding Testing as an integral part of ISSRE. Perhaps change the name to ISSRET

I would like to add the issue and recommendation concerning having joint budgets when ISSRE combines with another conference like ISSRE\ICSM 2000. The reason for this proposal is that many of our functions and expenses are joint activities: for example "Industry Day", Tools Fair, social events like the visit to the Tech Museum of Innovation and musical recital, and publicity. It makes sense to have a single budget because that would reflect the actual way we have been operating. Also, it is difficult to separate out these expenses by conference. I have made this recommendation to Anne Marie Kelly, Maggie Johnson, and Leonard Tripp. So far there has been silence. I don't think the CS wants to change. Perhaps if our committee would make such a recommendation, we could achieve reform in budgeting not only for ISSRE but for other CS conferences. ---------------- Minor point: there is a typo in "Objectives #2" in the foils.

Regards
Norm At 11:58 AM 5/28/99 -0400


--------------------------------------------------------------------------------

Notes from 12/15/98
Dear colleague,
In response to Ram's call for thoughts about ISSRE charter and policy, I propose the following for consideration by the Committee:

Although Bill Everett wants to restrict the Committee's work to ISSRE, I don't think ISSRE's charter and policy can be adequately addressed without first considering the policy of our TC on SRE under which ISSRE operates. If we don't understand the objectives of our field and TC, we may hard pressed to intelligently formulate a policy for ISSRE. As you know, the TC is under the Computer Society Technical Council on Software Engineering. In this spirit, I would suggest the following approach:
What is our vision for the field of SRE and the TC on SRE for the next 5 - 10 years?
- Examine the current TC SRE charter and see if it needs upgrading.

How is this vision translated into a charter and policy for ISSRE in this
time frame?

What are the objectives of ISSRE?
Who are or who should be the customers of ISSRE?
How can we best meet these customers' interests and needs?
- What are the important technical and application issues that ISSRE should
address in the next 5 - 10 years?
What should the priorities be among the following in ISSRE programs:

- Community:

Industry
Government
Research
etc.

- Personnel:

Reliability engineers
Quality assurance engineers
Test engineers
Developers
Managers
etc.
What should be the criteria for paper, panel, tutorial, and tool submissions?
What should be the criteria for key personnel and site selection? (I have
attached a Word 97 file that contains the ICSM criteria.)


I would not expect that we would be able to address all of these issues in
depth in the time allotted, but I do think these are important factors to at
least consider in developing ISSRE policy.
-----
Comments please


--------------------------------------------------------------------------------



The ICSM Charter sent by Norm:
Criteria for Selecting ICSM Key Personnel and Conference Location


Purpose: Minimize the probability that a poor combination of PC personnel and conference location leads to disastrous results for both ICSM attendees and the reputation of ICSM. We must strike a balance between openness and competence (not necessarily mutually exclusive).


1. Qualifications for General Chair

Minimum

i) Served successfully (as judged by the SC) at least once in one of the officer positions (see list of officer positions at the bottom of this appendix).


b. Desirable


i) Familiar with IEEE\CS conference and publication procedures.


ii) Familiar with the local facilities (e.g., hotel) of the proposed site.


2. Qualifications for Program Chair



a. Minimum



i) Served successfully (as judged by the SC) at least twice on the PC.


b. Desirable


i) Familiar with IEEE\CS conference and publication procedures.


3. Qualifications for Tutorials Chair, Tools Chair, and Industry Track

Chair


a. Minimum



i). Served successfully (as judged by the SC) at least once on the PC.



4. Qualifications for Publicity Chair


a. Minimum



i). Served successfully (as judged by the SC) at least once on the PC.


b. Desirable

i) Familiar with IEEE\CS publicity procedures.



5. Qualifications for Local Arrangements Chair



i) Served successfully (as judge by the SC) at least once on the PC


ii) Familiar with local facilities (e.g., hotel) of the proposed site.



b. Desirable



i) Familiar with IEEE\CS hotel contracting procedures.


6. The above qualifications may be waived if, in the judgement of the

SC, individuals have other outstanding qualifications for a position

(e.g., did an outstanding job as General Chair for another conference).



7. Site Selection Criteria


i) Convenient air travel to and from the site is available.


ii) Reasonably priced hotels are available at and in the vicinity of the site.


iii) Safe environment (e.g., no nuclear fallout).


iv) Support facilities (e.g., A/V facilities, copying, student registration help) are available in the area.



v) significant software industry presence in the area



8. Office Positions of ICSM


General Chair
Program Chair
Tutorials Chair
Tools Chair
Industry Track Chair
Publicity Chair
Local Arrangements Chair



(In the above, "Chair" can mean "Co-Chair". Other than for the general and programme chairs, if there is more than one co-chair for a post, then at least ONE must meet the above criteria.)







Wednesday, May 26, 1999

Conference Call List

Comments on the Foil presentation are added to our notebooks. June, 99

Draft Foil Presentation - Ver 1.0 May 25, 1999 Working version for our review.

Conference Call No. 3. March 15, '99: 12:15pm EST

Attendees Ram, Veena, Yashwant. Discussion topics: Communication package and Todos. Discussion around the issues: Papers and Sites. (Callin number 1-888-790-1048 (domestic) Passcode: 40124)

Conference Call No. 2. Feburary 22, '99: 12:15pm EST

Attendees: All. Several discussion items. Recap of last call, and discussion around issues: Overlap, Industry, Committee, Leadership.

Conference Call No. 1. January ?. '99: 12: 15 pm EST

Attendees: All. Discussion on the structure and schedule of this committee. Identification of major issues (as is now listed) and their catergorization as strategic or operational. Discussion began on the key strategic issues: Customers, Objectives, and Mission.

Sunday, April 04, 1999

Yashwant Archive

To: "Karama Kanoun" , ramchill@watson.ibm.com, veena@lucent.com, nschneid@nps.navy.mil cc: (bcc: Ram Chillarege/Watson/IBM) Subject: Re: Some thoughts

From Yashwant: April 4, 1999

Dear all, here are some thoughts from me. At the present time, the SRE TC Executive commitee is effectively the steering committee. We can have a separate steering committee, but that will make SRE TC executive committee largely redundant because ISSRE is the only significant activity for the TC. We can either suggest a reformulation of the SRE TC EC, or propose the steering function be done by EC. The TC has to play a significant role because it takes responsibility for running the activities (and answers to the IEEE-CS through SoftEng TAC). SC committee of 10-15 would be enough, there has to be significant international representation. Election of the chair: By the members of the current SC. (similar to what EC does now) Term: 2 years. Mode of election: vote, simple majority. >What about a Vice-Chair? The Vice-Chair should be eligible to be the next chair, but must be elected. Otherwise a few persons would have long term influence. Area Coordinators should perhaps be appointed for one years (with a likely appointment for another year, unless the SC is very unhappy), they should function as assistants to the Program Chair, but they should have freedom to organize special sessions by selecting papers they like. All papers should be reviewed, but in special sessions, the area coordinators should be able to decide the review/selection procedures. An example: International Test Conference. GC and PC chair(s): Generally they work as a team. The GC's leadership capabilities can be assessed by the caliber of the PCs they can get to work with them, thus I think a proposal should include names of both GC and PCs. However the SC should be able to negotiate with a prospective GC about the team he will have. Then PC members should be named by the GC and PCs, and the SC should be able to make suggestions to them. Yashwant


--------------------------------------------------------------------------------

To: "Karama Kanoun" , ramchill@watson.ibm.com, veena@lucent.com, nschneid@nps.navy.mil cc: (bcc: Ram Chillarege/Watson/IBM) Subject: Applied vs theoretical contents

This question comes up time to time. For ISSRE I would favor strong applied as well as strong theoretical components. Some conferences have done it very successfully like Design Automation Conference and International Test Conference. In both of them the applied part is significantly strengthened by presence of a "trade show" like our tools fair, but on a much larger scale. ISSRE has made a significant commitment to practice of SRE and that makes it different from say, FTCS. I think we have not - done enough publicity in the practicener community - yet started to attract exhibits. Both of these require special attention for multiple years before we will see results. We should even subsidize the cost of tools fair if need for a couple of years, eventually it can be a significant money maker. Decision makers will come if there are enough exhibits, there will be more exhibits if the decision- makers come. We just have to inject some effort into the loop for a while. Yashwant

Friday, April 02, 1999

Karama Archive

April 1, 1999

Hi all,

As promised, I have prepared a list of points I would like to address. Most of them concern Points 6 and 7 in the Journal Index (Committee and Leadership).

Indeed Norm addressed a part of 6 but he assumed the existence of a Steering Committee (SC) and worked on the relation between the SC and the ACs.

I would like to give some thoughts about the composition, role and duties of the SC. We can start a discussion about the following points.

Composition, evolution of the SC: We need at least a set of people who are aware of the history of the conference, who contributed as PC or General chair and who wish to take an active role (the core) + a few people willing to participate actively. Actually the group of people involved is growing each year (adding the General Chair of the next conference). What is the optimal number? A group of 12-15? (for FTCS the SC is composed of 20 members). Do we need a good international coverage? (from Japan for instance)

Election of the chair: By the members of the current SC Term: 2/3 years? Mode of election: vote, simple majority? What about a Vice-Chair? The Vice-Chair becomes the next chair, this a way to prepare the chair for his position. Also he can replace the chair in case of problems. The first time the SC elects both the Chair and Vice-Chair. Afterwards, it elects the Vice-Chair only

Role of SC: - Oversee the conference evolution - At least one annual meeting during the conference: approval of the General Chair, the Program Chair(s) as well as the location, chaired by the SC chair - Selection of the General Chair of the conference and the conference site, three years in advance -Approval of the Program Committee Chair: the proposal is to be done by the General Chair but the consent/approval of the SC is mandatory, two years in advance. The General Chair is not allowed to add / change the PC chair(s) without the approval of the SC. - Approval of the list of PC members?? What about the selection of the Tutorial Chair? Proposed by the GC, approved by the SC? Personally I think that the role of TC is important.

Other point: The idea of Area Coordinators to monitor trends is very interesting. Norm gave arguments in favor and against the proposal. One of his concerns was the fact that "The ACs could be viewed as a threat to the general and program chairs and as interference in their responsibilities for conference management". One way to avoid this is to appoint ACs for each conference in the same manner as the other chairs. The ACs can be selected by the SC (during the annual meeting) with the consent of the GC and PC chairs to avoid this feeling of "interference". Of course they can be re-conducted for the next conference if the SC things that it is worthwhile to do it. The SC has thus more flexibility than when they are "nominated" for three years. This is also a more dynamic way of working: as things rae changing very quickly, we can adapt our strategy more quickly. At least, I think that it gives more flexibility at the beginning to see how well it works.

Best regards, Karama



Thursday, March 18, 1999

Industry, Growth

INDUSTRY
Karama's assignment 3/3/99

Role of industry

The industry can be involved in two ways:

- From industry to research: inform the research community about
- best practices, what industry does now (presentation of case studies)
- needs (to help researchers define research directions)
- From research to industry: collect feedback from the attendance (best state of the art)

Several possibilities have been suggested to involve industry:

- Participation in the PC (to solicit participation of colleagues)
- Participation in the Executive (steering) Committee
- Industrial track (as we did preciously in Monterey, etc )
- Entire track for a specific company
- Panels (such as the one organized by John Musa since a few years: "Everything You Wanted to Know About Software Reliability Engineering But Didnít Know Who to Ask")
- Allow new / small software companies to present how do they do SRE (how do they analyze the process and how do they ensure quality)
- Encourage radical ideas: this can be done in a special session similar to FastAbstracts

======================

GROWTH
Norm's assignment 3/8/99

Objective:

Ensure that long-term needs of ISSRE customers are met. For example, it is important to have the application of SRE to networks adequately represented in future symposiums. Under this plan, the program committees (PCs) would no longer be satisfied with just issuing a CFP and waiting for good things to happen. Instead, there would be a proactive effort to shape events rather than react to them, thus ensuring that the needs of important customers can be met. It is important to note that a successful enterprise is not content with reacting to demand. Rather, it creates demand for its products and
services. Thus, ISSRE needs to explore new areas of application of SRE that will support its growth.

Implementation:

This plan assumes the existence of a Steering Committee (SC). This could be the Excom. However, the Excom has more matters to deal with than ISSRE. Therefore, an SC specifically charged with ISSRE policy would be more appropriate. The SC should develop and periodically update a long-range plan
(i.e., three to five years) that defines its markets and customers and that specifies the growth areas of the future.

Several Area Coordinators (ACs), such as one for networks, would be appointed for a two to three year term by the SC. The role of an AC would be to encourage the PCs to consider the needs of a given area in program planning and design. Using networks, as an example, the CFP should state that papers, tutorials, panels, fast track abstracts, tools exhibits, etc are welcome on the topics of research and practice of SRE in Internet, local area networks, wide area networks, and distributed systems
applications. In addition, researchers and practitioners in the networks area could be invited to present keynote talks and tutorials. The program design should reflect the program plan. ACs would monitor trends in the growth in their assigned areas. In addition, they would analyze the demographics of the attendees and results of attendee surveys in order to correlate attendee needs with program content.

ISSRE should not grow at the expense of quality. We should strive for balanced growth. This means that while we grow new areas, the PC is charged with maintaining quality and that quality would take precedence over consideration of including growth area papers in the program. In addition, there should be a balance between research papers and industry papers. The ideal situation is for the PCs and ACs to achieve synergism between research and practice. For example, if networks were a growth area, an attempt could be made to include research in fault detection and resolution analysis on the WEB combined with practitioner studies of Internet service providers' approach to software reliability.

Organization:

ACs would be selected by the SC on the basis of past performance on the PCs. Successful ACs would be leading candidates for future PC chairs. ACs should be appointed on a trial basis after our report is submitted.

Arguments in favor of the proposal:

ISSRE would probably grow and become more relevant because it would be reaching out to untapped communities and it would be moving to where the demand is.

One could argue that the functions of the ACs could be carried out by the PCs. However, the life of a PC is a single conference whereas the ACs would have multi-year appointments.

If ISSRE does not adopt new approaches like the use of ACs, it will stagnate at its present growth plateau.

Arguments against the proposal:

The ACs could be viewed as a threat to the general and program chairs and as interference in their responsibilities for conference management.

Worthy papers that do not address the subjects of ISSRE's planned growth may be assigned low priority for inclusion in the program.

Recommendations:

Appoint a permanent SC.

One of the first tasks of the new SC would be to identify three to five growth areas for ISSRE.

Based on the results of 2, the SC would appoint ACs in these areas for a two to three year terms on a trail basis. At the end of this time, the AC program would be assessed and either continued, and possibly expanded, or




Tuesday, March 16, 1999

Ram Archive

Ram’s Notes from 3/15/99 Teleconference Call
Ram will outline a presentation and put it on the web so that we can start filling in details that will become a part of the exec communication Discussion on Papers

Discussion on Issue: Papers
We need to attract industry papers, both from a perspective of topics and numbers (Yashwant)

The current PC review process is quite thorough but there is a concern about it not accommodating new ideas. If we go down the path of appointing area chairs, they must have flexibility to get in papers either through certification or override the review process as appropriate (Yashwant)

In the current structure, we do not focus on any one specific area, thus growing the paper numbers or quality in a specific area is going to be quite limited. We will need to exploit the area chair mechanism and, in addition, distinguish the natures of the papers.

We really have distinct kinds of papers; research and practice. The current category of paper is called industry track, which might suit the academic notion of industry needs but is quite removed from the practices as industry people would view it. For instance, a research paper is distinguished by being new and different from earlier work, whereas practice papers gain further value when the same idea is tried out by different people. Corroborating evidence from different practices strengthens a practice and industry people are constantly interested in how a similar idea got reapplied (Ram)

The design automation and test conference seem to have evolved into a good balance between research and practice. We need to emulate what they’re doing well (Yashwant)

ISSRE is really a conference for academics but we’d like to have industry papers. The perception is that while there are industry additions, such as an industry track, the central constituency of the conference is still academic. Although there are several papers from industry and they are very respected authors, they tend to be researchers from industry rather than the everyday practitioner (Veena)

We really need to focus on specific areas and lead the charge to the area chairs to grow them. This committee should identify a few of the important areas and then make it a steering committee responsibility to further refine them (ALL) The immediate areas that come to mind are: networking software, reliability and component software, the needs of smaller companies in the Silicon Valley, process measurement, and management.

When we structure the conference, it is important to have keynote speakers that are going to attract a crowd as opposed to unique presentations to honor people (ALL)

Discussion on Issue: Site Location
It is important to hold a conference in a major location. Holding them in small locations does not necessarily benefit the overall conference. On the other hand, the past experience of ISSRE has been that indeed a major location or a small location the attendance has not significantly changed. We all felt that while location is important, the content of the conference and the marketing of the conference will determine the degree of attendance we can draw. Having it in a good location without the best content isn’t going to drive up attendance. On the other hand, if we on the content and then hold the conference in a very remote location, it will not do us any good. Good examples are the STAR conference and Quality Week that have successfully drummed up attendance over the years by focusing on the content, for their constitutency and locating the conference in a major metropolis.

We discussed various growth numbers for ISSRE and have a specific set of target numbers that would be meaningful to shoot for. It will be a good idea to define these numbers up front and then figure out how we can develop a program to reach it. 1998 was a little less than 200, 1999 should be 250, 2000 should be 350 and 2001, 500.

Notes from conference call 2/22/99
Comments regarding charter:

we need a uniform team that can emulate in the conference what practitioners struggle with. (Norm)
radical things, like an entire track for a company on how they do SRE and maintenance.
We need to take industry needs and map them to a program structure. (Norm)
discussion on what SRE does now. new companies, methods, the Silicon Valley companies have different needs (Veena)
it could be a Research endeavor to analyze what the Silicon Valley firms need from a SRE standpoint (Veena)
industrial needs need to be communicated to ISSRE and we need a mechanism to do that. Ideas along these lines are taking fast abstracts as we have them today and converting them to state problems or state current practices (Veena)
what are the other conferences doing? (Yashwant)
is there something we can learn from them? (Y)some discussion about a ASM conference which is privately run and has a large turnout.
thoughts on broadening the agenda off the charter committee to include understanding relationships with the other conferences in the area. several people thought that this might be important but would take away from the work we are currently doing and require a lot of time. we should make note of it, but not invest too much energy in this direction (N)
Balanced Growth:

We had several discussions about the fact that there are several conferences that are hurting today with decreasing numbers of attendees. This is in part because there are many conferences and in part because the conferences do not deliver what the larger community needs. We recognized that growing the conference along the directions that industry people need, which is namely learning, and sharing of tools and practices. The question becomes what is balanced growth, and we discussed balanced growth from several different dimensions.

One of the thoughts is that we need to identify important areas for the industry such as and for example, SRE in networking, and then over a period of multiple years ensure that this area grows strongly. This would be a responsibility thrust by the steering committee to those that implement conferences, but the responsibility for continuity between years needs to rest with a few people who know the area. If this were done, then an area could pretty much accomplish what many a niche conference is trying to establish for itself. If they do this correctly, each one of these focused areas could almost become like a niche conference focusing on a subset of the
problems. The advantage of this approach is that these can grow the areas more rapidly and bring together their own collection of practices and tool vendors, helping the overall growth of ISSRE. One of the outcomes from this is that we have had more positions with leadership titles to offer, offsetting one of the needs that drives the creation of new conferences.

This led to some of the discussion regarding the role of the steering committee and the program committee and we need to discuss this in greater detail in upcoming meetings.

Communication to the Executive Committee:

Norm brought up an important issue of communicating our work to the executive committee. To this end, we have agreed that in two weeks from today we will construct a foil package that discusses the concerns in each issue and what our conclusions are. We should also write down
the nature of the recommendations that we are going to lean towards. We will then host a conference call and enlighten the broad SRE community to listen for 30 minutes on our presentation and then give us their feedback.

Monday, March 01, 1999

Mission, Objectives, Overlap

The Mission of ISSRE / Vision: (Notes by Yashwant)

ISSRE is an international conference dealing with "Software Reliability
Engineering" which is defined as the discipline that involves

-quantitative
-and algorithmic

methods for measuring and achieving high reliability in software. The mission of ISSRE is to advance this discipline by

- promoting research and developments in the field
- promoting dissemination of new techniques to practioners
- promoting interaction and exchange of information between
researchers/developers and practitioners.
- promoting discussion of the problems and solutions in the
field.

====================

OBECTIVES









Exchange of experience

Discussion of eveloving research

State of practice

Forum for discussion

Learn about emerging issues

Recognition of results

Exposure of work

Directions setting

More motivation

Competing process



We tried to put one or more objectives in front of each category of customer. I have just seen that Veena put most of them. I have noted the following. I think that this work can be done by e-mail once the lists of objectives and customer categories consolidated.

Senior/junior professor --> recognition / direction setting
Students --> present their wok, meet senior people, learn

Research Lab --> competing process
Development Lab --> learn (application focused)
Senior/ junior developers --> open to new things
Consultants --> promote their niche

Question: do we really need to put an objective in front of each category ? We can use such mapping for us just to be sure that we are not missing some objectives, then put both lists without any mapping.

==================

OVERLAP

My assignment is "Overlaps with other conferences". I have covered other conferences that I am familiar with. There are other conferences that have overlaps like Fault Tolerance that other committee members are more qualified to address.

Metrics
One of the biggest overlaps is with the International Metrics Symposium (Metrics). This overlap occurs because there have been a number of papers in ISSRE dealing with metrics or the relationship of metrics with reliability. On the other hand, Metrics does not overlap much with ISSRE because Metrics has had few papers dealing with reliability.

ICSM
With respect to the International Conference on Software Maintenance (ICSM), the overlap has not been significant because there have been few papers dealing with the relationship between SRE and maintenance. There have been a fair number of ICSM papers dealing with metrics but not reliability per se. Also, ISSRE has had relatively few papers that address maintenance issues.

ISESS
The International Software Engineering Standards Symposium (ISESS) has had few papers on reliability, although there have been a few workshops on reliability standards. Also, ISSRE has few papers about standards.

RAMS
The Reliability and Maintainability Symposium (RAMS) has had a considerable number of software reliability papers but the symposium also has had a lot of hardware reliability and maintainability papers -- subjects that are not addressed by ISSRE.



I do not consider any of these overlaps as unhealthy. Rather, I think the more important point may be what I consider a deficiency of breadth in ISSRE. We should cover more than testing and reliability modeling and
prediction. We should view SRE as a process that should be brought to bear on the entire process of software development and maintenance from the specification of software reliability requirements to the assessment and prediction of reliability during maintenance and operations.

Two of the biggest problems in applying SRE, both from technical and cultural standpoints, are the relationship between SRE and software safety and between SRE and systems engineering. The safety community has a very different outlook on how to assure quality than does the SRE community. With
respect to systems engineering, there are many colleagues who feel that software engineering is too narrowly focused and that software engineers do not understand that software has to operate in a larger context that
involves hardware, human organizations, logistics, politics, etc.

Comments please

Monday, February 22, 1999

Veena - Conf Call notes

Notes taken from conference call 2/22/99

Role of industry -


inform research community of their needs
panel where industry presents how they do SRE
traditional large company view
small company/Silicon Valley view

These ideas could be built into the objectives (operational: do A,B,C) and mission (long-term role of ISSRE) of ISSRE *

*Look at other conferences that are similar to and/or have overlap with ISSRE (Norm)

*Some conferences have specific objectives like: - education -> good tutorials - vendor participation, they need to sell products (Ram)

*Balanced growth by focusing on specific initiatives in the conference, e.g.: - SRE for networking - interface with the safety community (Norm)

*Followup to previous idea: - actively seek papers in the chosen theme area - involve the industry players from the area and - educate the practice on the theme (Ram)

*Steering committee should: - look at strategic directions in the industry - have a multi-year perspective - look at long-term initiatives (Ram)

*New conferences are created to meet a need: more people want the role of GC, PC, etc. Can we meet this need in ISSRE, e.g., by creating multiple Area Chairs? (Ram)

*Growth should be a new strategic issue: how should balanced growth be acheived? (Ram)



Sunday, January 03, 1999

Charter Committee

Charter/Policy Committee Members:

Ram Chillarege, Chillarege Corp.
Karama Kanoun, LAAS, CNRS
Yashwant Malaiya, University of Colorado
Veena B Mendiratta, Lucent
Norm Schneidwind, Naval Postgraduate School
Status

First pass of work completed in 1999
Reported results at ISSRE Meeting in Florida
Further discussion at ISSRE Meeting in Hong Kong
Several recommendentations already adopted
Final version of Charter due in 2002

March 2002
The committee is currently converging on to a set of recommendations to be put to vote. At the recent Hong Kong ISSRE (Nov 2001), there was a request to relook at the past report from 1999, and turn it into a new set of itemized recommenations.

... from the past: July 1999

The committee has finished most of its discussions and is in the process of wrapping up its report - Under Reports you will find the first draft of the presentation of issues and the formulation of the recommendations. Feel free to look at it and send any of your comments to the committee: Ram 7/5/99.

Our feedback is being logged.

Background - what is this all about ?
This committee was set up by the ISSRE Technical Committee Chair, Bill Everett with the charge to develop an ISSRE Conference Charter in late 1998. The ISSRE conference has grown over the past 8 years and has demonstrated that there is considerable Industrial interest in the area. At the same time the Research agenda has broadened, and it was broadly felt that this is an opportune time to assess where we are and where we ought to go. The 5 person team was selected by Bill Everett representing a mix of industry and academia.

The following pages are the working documents and notes maintained by the committee. While they are not currently meant to serve the purpose of communication, we have chosen to keep them public, so that any interested person can learn of the discussions and reach us with their thoughts. We will, from time to time host borader communication forums via conference calls to let you know of the progress we are making.

Ram Chillarege, January '99
Chair, ISSRE Charter Policy Committee
ram@chillarege.com, (914) 739 2826


Objectives of this Workgroup:

Draw up a proposed charter and policy for ISSRE by May 1999 (so it may be used
during the selection of proposals for ISSRE'2001).
Review existing ISSRE policy.
Draw on charters from other conferences.
Elicit wide input from past ISSRE attendees and participants.
Provide periodic status reports back to the SRE Committee.
The proposed ISSRE charter/policy will be reviewed and voted for adoption by the SRE Committee.
This is an opportunity to set long range direction for future ISSRE's.