We had a rather good meeting at SRI this month.
Highlights of the Formal Meeting
--------------------------------
This was the official meeting, held at SRI.
* Joe Williams gave a high level "markety" overview
of the thing we are planning to build. There was
a strong general feeling that the picture he was
presenting was not accurate, but the style and sense
of focus was good. When *do* have an accurate
picture to portray, I suspect he'll summarize it
nicely.
[One nice thing that came out of that presentation,
for me, was that it brought it into clearer focus
why I have been wrestling with data types. His desire
to identify the "fundamental information unit" of
the DKR made me realize that the real goal of the
data structure design I have been doing is to
(hopefully) identify one (or at most a few) "atomic
data structures" that can be strung together to make
everything else in the system. I think I may be
close (future email).]
* Lee Iverson gave a great overview of use case
scenarios, describing the activities that actually
go on in a software development project. Since we
all agree that our initial target is to augment
open source development activities, his overview
(coming soon to a mailing list near you) provided
a good list of activities to start on.
To anticipate Lee's email just a bit, he divided the
activities into 4 general scenarios:
a) The (primary) development activities that go on
before the product is released (designing, planning,
coding, documentation, etc.)
b) The (primary) development activities that go on
after a product is released (bug tracking,
suggestion lists, and enhancements).
c) "Breaking in" a new developer (choosing a bug to
work on, mining the code for rationales)
d) User activities (reading documentation, asking
questions)
In an effort to prune the list down to the "first cut"
activities, it was observed that some of the activities
represented "formal language" processes, or "formal
processes". Those activities included project management,
coding, bug management, and testing. The rest of the
processes were "natural language" processes, which means
that the system which is effective for one is likely to
be effective for all of them.
[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.]
Highlights of the Informal Meeting
----------------------------------
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:
a) 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.
b) 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.]
------------------------------------------------------------------------
Good friends, school spirit, hair-dos you'd like to forget.
Classmates.com has them all. And with 4.4 million alumni already
registered, there's a good chance you'll find your friends here:
http://click.egroups.com/1/2885/3/_/444287/_/956377299/
------------------------------------------------------------------------
Community email addresses:
Post message: unrev-II@onelist.com
Subscribe: unrev-II-subscribe@onelist.com
Unsubscribe: unrev-II-unsubscribe@onelist.com
List owner: unrev-II-owner@onelist.com
Shortcut URL to this page:
http://www.onelist.com/community/unrev-II
This archive was generated by hypermail 2b29 : Fri Apr 21 2000 - 21:29:13 PDT