Issue #1: What does "dog food usable" really mean?

I think it means that I can use a particular version of Chandler on a day-to-day basis for some basic workflows (as we've identified for calendaring in 0.5). It means Chandler has a minimum level of performance for the basic workflows and a minimum of level of reliability. This needs to be more specific but, simply, basic operations (tied to the workflows we've identified) should be as snappy as you'd expect from most other apps and should not crash more than once or twice a day based on normal usage.

For discussion, here are some salient questions to nail down this issue more specifically: [Decisions and answers to the following were made at the mgmt meeting 11/09/04]

• Do we expect Kibble calendar data to be migratable across
  1. dot releases i.e. when users switch to 0.6?
  2. milestone releases after 0.5?

Decision: We will support import and export of calendar collections to the iCalendar format (.ics files). We will ensure that Chandler can import our own iCalendar files. Chandler may not be able to import all iCalendar files (e.g. ones from Apple iCal) at the 0.5 time frame.

• If the app crashes, to what extent should we ensure data integrity? Do we need to support some kind of auto-recovery feature (as in Word or Excel)?

Decision: No auto-recover feature for 0.5. Reliability is an ongoing process. We will aim to have no known crashing bugs at the release of 0.5.

• What kind of performance goals do we require for 0.5? If we do not meet the goals are we willing to delay 0.5 until we meet such goals?
  • We know what the next steps to achieve higher performance are. However, performance work is quite unbounded at this point. In addition, it is much easier to improve performance when no new features are being added.
  • Proposal for 0.5: We work on the following next steps for performance, but don't have an explicit quantitative end-user performance goal
    • Benchmark tests on reference hardware
    • Ability to track performance progress
    • Analysis of performance bottlenecks
    • Fix known performance issues for
      • repository
      • CPIA

Decision: Go with above proposal

Issue #2: Extend development time (2-4 weeks) or sacrifice key features?

The key development areas in 0.5 are:

1. Features
   1. Calendar
   2. Collections sharing
   3. Chrome
   4. Email
2. Dev Dogfood
   1. Zaobao capplet
   2. Headless parcel framework (photo parcel as proof of concept)
3. Performance and Reliability
4. Visual polish (related to chrome features)

We can't fit all this in 14 weeks. Obviously Issue#1 is also related. If we have a high robustness standard for dog food calendaring, this will require even more development time. Proposal below assumes we don't require "1.0" level of robustness even in calendaring by 0.5.

Proposals are:

1. Extend 0.5 release by 2-4 weeks
2. Drop or scale down developer dog food goals
3. Scale down collection sharing (more like 0.4)

Arguments for extending release:

1. Katie feels that the feature set we have for 0.5 is the right set and it is not fungible with non-feature work (e.g. code refactoring) that needs to be done in 0.5 too (i.e. it's not as simple as cutting a feature to allow for more non-feature work). We are more able to produce the right chunks of work needed at this phase of the project if we extend the release
2. More people are going to take vacation in the holiday season during this release than average for the year. We should take this into account now.
3. Towards the end of 0.4, we forked off 0.4, and several developers started working on 0.5 even before 0.4's release. This worked surprisingly well. If things go according to plan, several developers will start working on 0.6 even as we extend 0.5 by 2-4 weeks.

Decision: Extend 0.5 release by another development milestone (2 weeks). Scheduled 0.5 release is mid-Feb.

-- ChaoLam - 05 Nov 2004