Goals and Objectives

• Detail out how we envision stamping to work in the Beta timeframe so that developers can plan the implementation and make key decisions regarding the domain model to support future work.
• The storyboards detailed in the spec are for 1.0.

Summary of Changes

• User problems we are addressing:
  • RECEIVE EVENT: You receive an email: Let’s have lunch on Thursday at 2PM at Quintessence, here are the directions. You want to be able to “trip over” this information on the calendar, which is where you look to figure out where you have to be next and when.
  • SENT EVENT: You are having a dinner party. You want to invite some friends.
  • RECEIVED TASK: You receive an email from your friend who’s looking for a new job: Could you give me some feedback on this cover letter? You want to be able to “trip over” this information on your task list, which is where you look to figure out what stuff you need to do.
  • SENT TASK:Tax season is coming up. You want your spouse to do your taxes for you.
  • SCHEDULED TASK: You have a task to go to UPS and ship your bike back to the manufacturer’s for repairs. You’ve got all the info about UPS hours and rates in the task notes. You figure out a time when you can go and want to put all that info on your calendar
  • SENT SCHEDULED TASK: Your roommate has to ship his bike too. He’s offered to do it for you and needs all the info about where to ship the bike to, etc
  • MEETING I NEED TO SCHEDULE: You’ve been asked to set up a post-mortem which will require a delicately crafted agenda proposal
  • MEETING I NEED TO WRITE UP NOTES FOR: After the post-mortem, you need to clean up your notes from the meeting and send them out to everyone. Your raw notes are in the notes field below the agenda
  • SENT MEETING NOTES: After you clean them up, you want everyone who attended the meeting + the rest of the company to see the notes. You want them to know what meeting it was for. What the agenda was for the meeting was. Meeting notes

• What's new:
  • Backend architecture work for stamping/domain model.
  • Send and receive a communication in Chandler stamped as a task.
  • Edit an existing event or task that has already been to sent and send out an update.
  • Receive task and event updates in Chandler.
  • Add a new column in the table to display communication status and start to handle some visual affordances for...
    • Alpha 4a: Unread, Read, Needs reply
    • Alpha 4b: In versus Out versus Neither, Error
    • Alpha 4c: Draft-ness, Update-ness, Queued
  • Displaying appropriate attribute in the Who column with an attribute label in grey.
    • Created by
    • Edited by
    • From
    • To
    • Updated by
  • Enable stamping of shared items (merge problem outlined in sharing spec).
  • Send and receive updates for shared items.
  • Fix existing bugs with unstamping items.

Risks and Dependencies

• Risk: Need to specifically figure out what is doable for Alpha4 and make sure it's coherent with the dashboard.
  • Proposal: Working closely with Bryan S and Grant on a phasing plan for Alpha4.
• Risk: The next iteration for the stamping will be describing clusters. Although somewhat described on the wiki and the mailing list, it hasn't been detailed out in spec form.
  • Proposal: Although we haven't spec'd this out in detail, tGrant has enough knowledge to go ahead and do the domain model work. We expect to have this fully spec'd out by the end of Alpha4.
• Risk: In order for users to receive communications in Chandler, we need to figure out what accounts people will use. We have not closed on a solution for Alpha4 but initial discussions indicate there are some reasonable options...
  • We provide email accounts for experimental users.
  • We insert special headers into email sent from Chandler clients so that other Chandler clients can receive them.
  • ...options still yet to be discussed with BrianK^? and on the list.

-- SheilaMooney - 22 Jun 2006