1. Telecommuting. It's clear that one size doesn't fit all. Morgen is in SF 2 days a week and that's working great. For the people that Mitch works with day to day, Mitch has a need for lots of face to face time with people and that drives up the amount of time that one needs to be here. This includes people like Chao who work with Mitch a lot all the time, and Mimi right now during the heavy design phase. Since Ted is starting as a remote developer, we'll need to learn to work more in ways that aren't face to face. We'll have to figure out what if anything we need, like video conferencing, etc. We'll have to figure out what to do with meetings at whiteboards, etc.

2. Design Discussion.

A. Mitch expects pretty firm design decisions to be made in the next set of weeks. In other words, to describe the focus, here's what we'll do first, here's how it relates to other pieces. Mitch and Chao and Ducky and Mimi are working on a process for doing this, and making the initial decisions.

B. Chao notes that the primary goal is to unlock developers. The three elements are: architectural interdependencies, feature list and resolving design issues. Then Chao can do a bottoms-up schedule for Canoga, and compare to top down schedule of Dec. 2004 plan, and see if we want to cut features. (Note: most of Chao's presentation is documented in DesignProgram^?.)

1. Design and feature process has two parts. One is a requirements analaysis -- what is in email, calendar in Canoga 1.0, and what is later? Chao is putting together a list of features reflecting our current best thinking. The list is not final, but it's baking, and Chao will send it out shortly.

2. There's been a lot of discussion about the actual names or labels of components; these aren't done yet. There's more agreement about relationships than there is as to labels.

3. There are also a set of fuzzy design areas which need to be resolved to get to Canoga 1.0.

4. There will be 5 capplets, or mini- applets of Canoga. Three are core for Canoga -- email, tasks, calendar. Two are supporting -- -- IM and Notes. Contacts is a capplet, but it's also a resource area for the other capplets and this is where the design issues are.

5. Right now the focus is on generic info management layer. What's the relationship between caplets; how to group things for users. A deliverable from this will be storyboards and then screenshots demonstrating how we handle Chandler "views"

6. Mitch adds: The goal of chandler has been that one's information doesn't exist in a particular bucket like "email." So this is an exercise in figuring out how information is connected between the capplets. Scenarios about: get an email, there's an event, how does it get on my calendar. Or get an email, realize it describes a task, how does that get turned into a task.

7. Chao: once we have this view of general information management is solidified, we'll have the "soul of Agenda" and can move forward on the rest of the design. This includes sharing, and how Chandler relates to the outside world. Also such things as search, scripting/agents, recognizers, security, and CPIA.

8. Notes of the design meetings^? are published to the wiki by Ducky. Mimi is working on sketches.

3. Recognizing reality -- Katie has actually been acting as an architect, so we are recognizing her role as an architect and awarded a sceptor or architectural authority. So when Katie thinks there is a right thing to do architecturally and says so, that's the thing we'll be doing. We think there's a natural distinction between the work Katie's been doing and that which John has been doing, so we're not going to try to make a formal distinction. If we find we need to later then we'll do so.

4. There's a milestone coming next Tuesday.

-- MitchellBaker - 06 Nov 2003