introduction  the intended theme of this workshop was that of "experience using software process models". this experience was expected to reveal a number of crucial issues in the prescriptive and descriptive use of those models and their underlying support. for example:  suitability of existing models \--- a model should be effective in describing and prescribing a wide range of actual software processes; it must also address a wide range of activities within each process including, in particular, individual and group interactions. experience using the model should answer the following questions: how usable are the models for guiding and controlling software development and maintenance; how well do the models scale from processes-in-the-small to processes- in-the-large; what activities are covered in the development and maintenance life-cycle; what policies of individual and group coordination and cooperation are prescribed by the models; and what mechanisms (tools) and structures are needed for supporting and/or enforcing these policies?  instantiation of process models --- a software process model must be fully or partially instantiated to obtain a specific process definition for all or part of a project. generic process models, which can be customized for particular projects by being instantiated in various ways, enhance the potential for process model reuse. what are the characteristics of widely applicable process models? how is an appropriate model (or appropriate customization of a generic model) selected to meet the specific needs of a particular organization or project? what are the mechanisms needed for customizing and creating enactable model instances?  dynamics of process models and model instances --- process models will evolve over time as experience accumulates, the requirements change, and the applicability of a given model is extended; process model instances may change during their enactment, either adding detail not prescribed by the model (refinement) or modifying (and possibly creating) detail to accommodate unpredictable contingencies. to what extent can software process models be evolved or adapted? how are the models verified and validated and what are the mechanisms for gaining and using feedback on model usage? how are instances refined and modified dynamically?  the basic agenda for the workshop was to begin with the current state of the art, distill the experience that we have gained to date, and then generalize from that the directions we ought pursue.  review of the state of the art (keynoter: bill curtis; reporter: watts humphrey). a summary discussion of the current state of the art in enactable software process models.  mechanisms (keynoter: takuya katayamna; reporter: gail kaiser). a discussion of experience with notation in actual models --- the syntactic concerns of process models. what is right/wrong with our current facilities? what are the lessons learned?  policies (keynoter: mark dowson; reporter: peter feiler). a discussion of experience with domains in actual models --- the semantic concerns of process models. what are lessons to be learned about model specific semantics? model independent semantics?  data (keynoter: jack wileden; reporter: lolo penedo). generalizing and synthesizing from our experience, what are the object base and typing issues that need to be addressed for process modeling?  control (keynoter: bob balzer; reporter: dewayne perry). generalizing and synthesizing from our experience, what are the dynamism issues that need to be addressed for process modeling?  emerging issues --- summary (keynoter: sam redwine; reporter: david garlan). as a result of the discussions, what are the emerging issues given our base of some experience?  as the position papers seem to establish an agenda of their own independent of the call for papers, so to the discussions establish an agenda of their own independent of the published one. a number of important general topics and issues arose from the discussions (as you will read more about in the ensuing session summaries).  in reviewing the state of the art, the discussion delineated the following general objectives of process modeling: to provide a precise framework for understanding, experimenting with, and reasoning about the process; to facilitate process automation; and to provide a basis for process control.  with this as the basic context, the discussion centered round the notions of activities, commitments, and policies. what is an activity? is it an atomic or a decomposable unit? how is it described? what are the meaningful units of commitment? what is the result of breaking a commitment? are there meaningful consequences? what level of constrainedness should policies have? should they be viewed as restrictions, or as scopes of autonomy? how are conflicts among policies handled or resolved?  one thing that become abundantly clear in the experience discussions was that we had very little experience. we find ourselves suffering from the rather frustrating "chicken and egg" syndrome: we need more experience in order to determine the notation and underlying abstractions that we need, but we need notations and underlying abstractions in order to get that experience.  the important question, in generalizing from the syntactic and semantic details of existing process models, is "what is new here?" some of the new wrinkles are constraints, multiple views, and multiple levels of context (or, perhaps, intent). on the data side, we need to develop a type model appropriate to process modeling that inherently reflects the assumptions, presumptions and observations found in modeling software processes. on the control side, we need to be able to express various aspects of a model at different levels depending on the intended use of those descriptions (for example, we may find a particular aspect better expressed as a goal in one context and as a recipe in another).  in summary, we need more experience, we need more self-application (that is, we need to practice what we preach), and we need to look to other disciplines to see how they have solved their process problems. despite this lack of experience, the workshop was successful in that we made some progress in clarifying further some of the important issues and we broadened the areas of concern. we continue to have a rich and open field of research.  dewayne e. perry