mechanisms (session summary)  takuya katayama lead the discussion on mechanisms for software process description. he classified software process views as reflected in the position papers into functional, behavioral and enactional, described some generally desirable properties of software process mechanisms, and listed those projects that seemed to have obtained non-toy experience.  he made a plea for each of these projects to answer a questionnaire that, among other things, requested information regarding how the formalism handled ill-behaved processes. one generic example of an ill-behaved process was given: repeat function1, …, functionn until predicate1, …, predicatem are satisfied. it is not really clear to me that this process is ill-defined, since it seems to be computable using normal means; my opinion is that an ill- defined process is one that is made up and/or arbitrarily changed while it is in progress, in the sense of self-modifying code (e.g., lee osterweil's universal process program --- an unfair characterization since lee didn't show up to defend himself). in any case, katayama's questionnaire will hopefully be addressed in the position papers for 6ispw.  the discussion focused on several interesting issues. the most controversial was instigated by mark dowson, when he asked what is the definition of "activity". there were a number of different responses, but most fell into one of three camps.  the first, which i'll call notation-oriented, defined an activity as the primitive (according to watts humphrey, the instruction set) of the process modeling notation. in general, the notation might lack facilities to express decomposition of an activity, or at least --- as colin tully states --- we choose to regard such units as decomposable. the second, people-oriented, defined an activity as a primitive in the real-world process being modeled. bill curtis said this might be a job that one person takes responsibility for, without interaction with other people; the process would be defined in terms of such interactions. the third, which i'll call process- oriented, was exemplified by dewayne perry's definition of an activity in terms of causes (preconditions?) and goals (postconditions?) with respect to the process. there was some argument over whether or not such an activity necessarily resulted in an observable change of state. bob balzer pointed out it is an open question as to whether syntax (notation) can realistically be separated from semantics (people and process).  there was some argument in all three camps as to whether activities were really primitive, as assumed in the definitions above, or could be decomposable at a lower level of abstraction. one issue is whether or not a particular activity can be decomposed with respect to the question at hand (david carr), for example, the encapsulation might be due to ignorance (sam redwine); alternatively, there may be no need for decomposition (frank belz).  one response by mark dowson seems to cut across all three camps: tasks are defined as managed units (i.e., the units are scheduled and allocated resources), while activities are not managed separately from their enclosing tasks. but this leads to the distinction pointed out by peter feiler of machine-level scheduling and resource allocation versus process- level, since everything executed on a computer is scheduled and allocated resources at a fine granularity by the operating system. taly minsky expressed a concern that this entire discussion was at too high a level of abstraction, and we should return to more operational definitions; however, i think that discussion of scheduling and resource allocation is quite concrete, since we can define (computer or bureaucratic) algorithms to carry out these operations.  at this juncture, anthony finkelstein pointed out the need for folk classification: what do the people involved in a process think are the meaningful units? this lead into a new controversy over the notion of "commitments", which seemed to have at least as many definitions as "activities". here the division seemed to be over whether the most important concern was why things are being done versus what is being done; there was also an issue over what it meant for commitments to be retracted. (the conversation was rather random, so i can relay only a small subset of the interesting comments made by particular individuals.)  bill curtis pointed out that computerized formalization and monitoring of commitments may appear to project personnel as naziware; further, if there is a shared information base for rationale capture, who monitors and cleans it up? sam redwine gave the example of burying a project to track the fulfillment or lack thereof of presidential campaign promises. walt scacchi made a distinction between strong commitments, with real consequences if broken, and weak commitments, which are no big deal; bill curtis mentioned false commitments, based on what is acceptable to management or customers rather than how things are really done.  according to anthony finkelstein, there are four kinds of commitment: commitment to a statement, no commitment to a statement, commitment to the negation of a statement, no commitment at all. taly minsky mentioned the commitment (or obligation) to restore inconsistent states to consistency; ian thomas pointed out such a commitment might be from an individual to himself, and not necessarily public.  there was a digression and some brief confusion over the use of the term commitment as it relates to transactions, but that was determined to be irrelevant to the discussion at hand. watts humphrey defined a commitment as between people, freely entered into, based on intelligent knowledge, public, with a clear intention of performing, and prior notification and renegotiation if the commitment will not be met. in this sense, project personnel themselves act as two agents with respect to commitments, one that makes commitments while the other monitors whether the commitments are being fulfilled (mark dowson).  after the break, two specific projects were briefly discussed.  karen huff described her work on rule-based process modeling and planning. she made three main points: (1) components should be defined to permit dynamic construction of processes, in order to accommodate failure and iteration, particularly for ill-defined processes; (2) there is an important distinction between doing versus deciding what to do, i.e., it should be possible to reason about a course of action without committing to start its execution (bob balzer describes this as envisionment versus enaction); and (3) the process should be viewed in terms of its state of completion with respect to its goals rather than as an instruction pointer and a snapshot. she noted that the ability to decide was built-in, as opposed to a separate process.  this led quite predictably to a discussion about planning (bob balzer) versus doing (pamela zave) versus planning in response to feedback from doing and measurement of progress (sam redwine). there were a number of questions, mostly from dennis heimbigner and bob balzer, regarding the power of huff's notation (apparently turing-complete in theory, but not fully implemented), its application to representing real processes (primarily unix-based coding and testing), and the difficulties encountered (there is a problem with suspending and then resuming a plan after the world has changed). i mentioned the concern about side-effects from what might otherwise be considered an atomic activity, and how such side-effects could be detected (the best we can do is operating system support --- which of course doesn't work for off-line activities) and modeled. wilhelm schaefer delineated the problem of combining process models for individuals, who can change their processes at will.  going on to the next brief project description, walt scacchi described his work on a hypertext environment, where an empirical evaluation was made with respect to student groups. the process was defined at the intergroup but not intragroup level, and there was no control over the work division among participants. not surprisingly the unexpected circumstances arose at the intragroup level, which turned out to be decomposable after all and led to the greatest variation in productivity and quality. individuals may introduce new tools spontaneously, and there's no general way to describe this. there is thus a need to produce new processes and apply them on the fly, as well a model interactions among multiple agents whose purpose may be to decide what to do next; since people meander, processes need to be able to meander. people operate in an open world situation, but the process is defined by a closed world formulation.  watts humphrey pointed out that processes don't transplant well; outside processes are not accepted and a sense of ownership (achieved through improving the process) is needed. marc kellner brought up the issue of where do processes come from, e.g., dod guidelines. this led to a discussion of description versus prescriptive processes (marc kellner) and abstraction versus instantiation of processes (bob balzer). anthony finkelstein questioned the idea of an emergent process. walt scacchi responded that modeling technology is too heavy to support modeling on the fly, and the effort of changing the model but be less than just doing the work correctly.  at the end of the session, colin tully suggested holding a process description contest, with a benchmark process that all participants would define in their own process modeling notations. anthony finkelstein pointed out that this is problematical, however, since different notations address widely differing aspects of the process. it might be most reasonable to have at least two benchmarks, one involving upstream and the other downstream activities, with no expectation that every process modeling notation addresses both areas. hopefully this will be addressed in the call for 6ispw.  gail e. kaiser