Invitation Workflow

Notes based on Feb 21st, 2006 meeting

Sheila, Mimi, Bryan, Philippe, Katie (at the end)

Issues with Stamping

• an email cannot be both inbound and outbound : that's an issue for a unique event being both received as an email and shared
• sent email can't be sent again : this will frustrate users who, for instance, forgets someone on an invite

Possible solutions

• have a heuristic in Chandler that merges items and resolve contradiction (even it's a little bit crude)
• we could erase the old email and resend, loosing some info doing that (not ideal but...)

Other solution (future)

• have a Base item that holds all the info (who, etc...) including versioning of the item
• emails are sent separately and linked to the Base item

This is something which seems very different from stamping but requires lots of work at all levels (repository, data model, UI, etc...). Does not seem like feasible in 0.7.

Concern (from devs) : is the stamping solution (chosen for 0.7) driving us further away from the real solution?

Consensus

• For 0.7, we'll be covering the "transportation of events" use case, not scheduling coordination or any other complex interaction scenario. Basically, if we can send events and have them appear on other people Chandler's as events, we're fine.
• we'll use stamping for this though we know it has limitation
• we'll start discussing the complete solution (that involves versioning) though we won't see implementation of this in 0.7

Next Steps

• review the phasing of "invite and scheduling" and call out what will work, what won't and what needs support from the Platform team (data model change, if any)
• start discussing the complete solution with the Platform team