(Attending meeting: Mitch, Lisa, Sheila, Mimi, Brian, Morgen)

High level information

Shift towards agility -- do smaller, more interoperable feature additions that may be less usable to non-geeks but get something useful out earlier.

Shift towards working with a Web UI as well as with a client -- let people work with a PC client or WebUI^? on their data, wherever they are. The WebUI^? will start out simple, obviously, but in the longer run it will be more than just an appendage to the client. We will be inspired by Del.icio.us and Flickr.

We've denigrated the idea of replicating the iCal experience without having more. But this shouldn't be denigrated. First of all, we already have more -- we have the ability to share read/write, as well as the ability simply to share read-only. Second, iCal only works on Mac and nothing really similar exists for Windows and Linux.

Decisions for this meeting

These are stakes in the ground for client and server planning -- decisions about what direction to investigate for now.

1. Decide to try to use ticket-based permissions rather than authentication-based access control. Next steps: see some idea of what the GUI would look like. Goal: make it much more usable than Sharemation. Mimi will investigate this and make proposals related to #2.

2. Preserve existing investment in sending, receiving and accepting sharing invitations -- only these now work with tickets (previously used plain URLs and authentication to get permission) Decision: we will investigate this and write up a full proposal. The proposal must involve sharing via WebUI^? only as well as via Chandler -- e.g. some way of dropping "invitations" into somebody's WebUI^?.

(Sidenote: Can we make email better than dog-slow now? Slowness of email is one of the problems that makes sharing not very fun to use. )

3. We will also provide a way to get the sharing URLs so that they sharing doesn't have to go through email invitation workflow (which means that they don't have to have email accounts setup) We do both sharing invitations in Chandler and out-of-band sharing by communicating URLs containing tickets.

(Sidenote: Importing calendar events currently they go into my All collection. There's no way for the user to back out and remove the things they just imported -- because the events aren't in their own collection, there's no way to pick them all to delete them. An import should always create a new collection with the imported things. Also Chandler should always come with a default calendar collection)

4. Choose between automated account setup via Chandler, vs out-of-band mechanism

• Must involve email -- initially we probably wouldn't require that email to receive an email but we would require email uniqueness.
• Mitch prefers out-of-band account creation (assuming its simpler) but prefers that Chandler suggest what server to go to for an account (pilikia or whatever server we run on)
• Using a WebUI^? to actually register for the account allows us to evolve our account registration processes over the next six months or so. Eventually we will have a client-usable API (Web Services, e.g.) and we'll think about this as we go but not use it in Chandler in 0.6.

5. Briefly outline WebUI^? requirements - no sharing? Ran out of time -- need to do this by email.