[Design] 0.7 Planning
jeffrey at skyhouseconsulting.com
Thu Dec 1 15:28:11 PST 2005
> *Proposed Tenets:*
> *->* Dogfood Sharing/Calendar #2 - Move the calendar towards feature
> complete by adding features like free-busy. Respond to bug fixes and/or
> enhancements that block calendar usability as users discover them.
> *->* Plausible Dashboard - Basic working table with sort, search and UI
> polish as well as infrastructure to lay foundation for innovative PIM
> features around task and project management.
> *-> *Application Infrastructure* - *Continued work on performance,
> widgets, undo framework.
> *-> *Developer Platform - Schema upgrade, content model as well as
> refactoring and documenting APIs that 3rd party developers can use. This
> includes work refactoring CPIA.
> *-> *Release Packaging - now that some portion of the product is usable,
> investing more time to enable users to download and run Chandler on all
> 3 platforms. In particular, distribute via conventional means on Linux
I like these tenets, although I'll add a (perhaps radical) addition to
them I'd like to see in a separate email.
I'm really into Mimi's framing of 0.7 planning in terms of looking for
small use cases we can solve, so in my answers to the following
questions I'm trying focus on things I think are achievable in a few
months and are things Chandler could usefully replace.
> *->* Should we be considering PDA sync or is that out of the question
> for 0.7?
I'm convinced we need this, and soon. I'd love to have a device that
does CalDAV and contacts over WebDAV (I don't think a standard's been
written for that yet, but I imagine it'll get written), but I'm not
expecting one for 3-4 years.
I think we should try to do at least unidirectional Chandler -> device
event and reminder sync for some devices in 0.7. That certainly won't
meet everyone's needs, but I think it's plausible, and it would be
enough for my needs.
I've been (sporadically) participating in CalConnect's mobile technical
committee, and the TC is about to send out a (web based) survey about
what portable devices people are using. I'm hoping people in the OSAF
sphere will fill this out survey so we can get an idea of what devices
people who are already interested in Chandler are currently using.
> *->* How much email work should we do in 0.7 and what are the
> consequences of delaying this further? There is some email work planning
> to support of the dashboard tenet what happens if we have to make some
> tough choices and don't do this?
Sadly, I just can't see Chandler replacing Thunderbird for me in 0.7.
That isn't to say we shouldn't be working on email, just that it seems
huge. I agree with Alec that the infrastructure doesn't seem like the
hard part, it's all the small UI details, and there are a lot of those
we need to work out to get email to a usable point.
I don't see the email situation as at all hopeless, I'd just like to
break it down into really small chunks if possible, and see if we can
find any chunks that would help us quickly, and focus on those first, so
we can get product quickly while accomplishing a few more pieces of the
One possibility I've thought about is having an email mode in Chandler
that only downloads IMAP messages in my inbox that have special Chandler
headers. That way, I wouldn't worry about dealing with folder
hierarchies, or "normal" emails in Chandler yet. I'd continue to use
Thunderbird for those messages, but if we do email invitations or
capital "N" Notifications, we could start working on interoperating with
other email clients and also be adding useful features for those of us
dogfooding Chandler for calendaring.
> *->* Should we focus on trying to have a shorter release than 0.6 by
> doing less? Maybe we have 2 short releases instead of one?
I have a strong preference for short releases. There's additional
overhead, but I think it pays for itself in short order.
More information about the Design