1. The (primary) development activities that go on before the product is released (designing, planning, coding, documentation, etc.)

2. The (primary) development activities that go on after a product is released (bug tracking, suggestion lists, and enhancements).

3. "Breaking in" a new developer (choosing a bug to work on, mining the code for rationales)

4. User activities (reading documentation, asking questions)

[My inclination is to counsel a sharp focus on those activities, excluding the formal processes for the moment. The only conceivable counter argument is that the design really needs to take them into account, in order to ensure future compatibility with those systems. For some reason, my "gut feeling" is not to worry about it -- but I want to leave the door open for alternative views. It helps if we can restrict our focus, but...]

• Doug is going to work with Lee Iverson to put together a system he can use to demo Augment in the very near future. Whenever that is ready, it will be item #1 on the agenda.

• It is apparent that a large number of projects are currently underway in the "distributed collaborative project" design space.

  It was felt that we should use one or more of them to replace the fragile email medium we are using, so that we can get a better idea of what needs to be done, and use whatever the system gives us to help us do the design work.

  [I sent out the list of candidates yesterday. Apologies if I overlooked anyone's past contributions. Send them to me and I'll start v.2 of the list.]

• Doug mentioned that Sun had donated a server for Bootstrap use. Whatever system we select might be hosted on that system.

• We identified several important agenda items, and prioritized them. [Upcoming email.]

This was the unofficial meeting, held at the Applewood Gourmet Pizza palace, where they have salmon pizza and barbeque chicken pizza, and all kinds of good stuff...

• For maybe the first time, I articulated clearly the reservations I have about the transcoding approach:

1. It *could* be a coding dead-end.

   That is, it might take us part of the way to where we want to go, but leave us with no good way to progress from there. I don't *know* that to be the case, but I'm concerned that it may be.

2. The rather interesting tidbit of information that surfaced recently: That the folks who build the HTML-page-annotation system (Crit) found themselves using EMAIL to carry on discussions -- even though they tried to get each other to annotate HTML pages.

   This led to the observation that there is something seductive about the email interface -- the immediacy, the way information comes to you, and asks only for a reply. That, in turn, led to the realization that email the right interface, but the wrong data structures.

   Add good data structures to the system, and the result should be interesting...]

• A new member of the group, Debra England from McKinsey and Company (a group that focuses on defining and promoting organizational "best practices") kept asking: What is it that we are building? What are we about, anyway? I came up with one possible statement. Debra suggested that it would be a good assignment for the group to ask *everyone* to write up a concise statement (a sentence or a paragraph).

  [That "homework assignment" will be in my very next email.]

  
  

Eric Armstrong
eric.armstrong@eng.sun.com