Previous notes

Litmus tests for stamping design

Mimi, Donn & I have been getting deeper into the details of stamping items, so that we understand both how to display them and how to model them in the content and/or data model. There are some subtleties.

	Original Item
	Email	Task	Event	Email/event
Stamped as Email	N/A	Remains a Task	Remains an Event	N/A
Stamped as Task	Turns into Task	N/A	Turns into Task??	Remains an event
Stamped as Event	Turns into Event	Remains a Task	N/A	N/A

To make sure we've got all these cells filled in correctly, and to see how stamping affects things in different situations, we need a set of litmus tests for this functionality. If we are proposing a solution (e.g. multiple-inheritance, or a special kind of bi-directional link between items), we need to run through that solution for each litmus test.

Case	Flow	Behavior
Schedule time to fill out a form, and realize it's really a task	Event --> Task	This starts out as an event because the user's first thought was to schedule time to fill out a form. The user starts by blocking out time on a schedule and types in the headline "Fill out Form 2B". Later on the user realizes this is really a task so they want to choose the "add to tasks" or "stamp with task" button, so they can add a due date. The headline of "Fill out Form 2B" should remain visible, and the icon should change to a task icon , even though it continues to appear in the calendar.
Invited to a meeting, and need to complete a task before it	Event(+mail) --> Task	This starts out as a combined email/event because somebody invited the user to a meeting. The headline is something like "Replication Architecture Review". The user would like to remember to write the proposal that's due at this review, so they need to associate task fields with the existing event. The headline "Replication Architecture REview" needs to stay, as does the other invitation information. We're not sure if the icon should change.
Email from manager arrives to become task	Mail --> Task	An email (which is not a task) arrives. This email contains a request from somebody or simply reminds the user there's something to be done. The user chooses "move to tasks" or "stamp with task" to add this information. The icon should change because the fact that the request was delivered by email is a historical detail, while the due date and the fact that there's a task to be done is important.
An email suggestion for a meeting needs to be turned into an event	Mail --> Event	In this case, an email arrives with a headline like "Biggest party ever!", and containing a date, time and location. If the user decides to go to this party it should be turned into an event so they will want to click on "put on calendar" or whatever the stamping button is called. The user may well want to change the headline to "Crazy Dave's party" when it moves to the calendar. The icon should definitely be for an event.
Meeting organizer sends out invitations	Event --> Mail	This is the most common case for event to email stamping: the user is scheduling an event and decides to invite people. The event has an affordance for "invite people", which might be different than a simple "stamp as email" button. The icon should remain an event, and the headline should become the default email subject.
Manager sends out task	Task --> Mail	When the user wants to ask somebody else to complete a task, they click on the "assign to" button... again, this isn't simply "stamp as email" because the role of the person receiving the email is important. The icon should remain a task.

Draft 0.4A/B schedule

0.4A integration point

This integration point is scheduled for the 0.3.20 milestone, July 13 -- that's six more weeks on top of the month or so of development so far. The plan is to complete all these features, review code and check them in, and do some testing of the system as a whole. For features that are not complete by July 06, we will have to review the feature's progress and our plans for 0.4 and decide either to slip the feature to 0.4B or later, or risk slipping the date for 0.4A in order to get the feature in.

• Application WG
  • wxWidgets: flicker: native composite, active content editing, in-canvas dragging, interapp dragging
  • cpia: oscon presentation, toolbar/navbar refactoring, item collection integration, simple canvas fixes
  • Chrome: sidebar and toolbar basics (???)
  • Detail View: functional first pass (markup bar, stamping, from/to/core/notes, see also collections)
  • Summary Table View: on draw handlers, view column headers, ootb view instances, width adjustment fixed
  • dnd: content item to collection, named collection to named collection (a couple of variants)
  • Calendar Blocks: basic navigation (and mini calendar), basic drawing cleanup (font/color changes, selection feedback), basic in place edit items

• Services WG
  • Content Model: work to include calendar object schema, date/time schema issues, email object schema, task schema
  • Email: ability to download IMAP content and store in repository
  • Sharing/publishing: design, protocol selection, content model; write or integrate WebDAV client library, publish arbitrary collection of Content Items to a WebDAV server, ItemCollectionsProposal
  • Parcel loading: close on and implement formats for parcel data
  • Other services: schedule manager, threading work for notification manager
  • Certificates: create, password-protect, replace, verify others' certificates

• Repository WG
  • Access Control: Principal identification, storing ACLs, implement API
  • Sharing/replication: implement private attributes, remote browsing
  • General application support: unglue threads from repository views
  • Data model: Item clouds, exportable addresses
  • Queries: String parser

• Issues
  • Sharing addresses -- not sure how much

0.4B integration point

This integration point is scheduled for the 0.3.23 milestone, Aug 24, a total of six weeks after 0.4A completes. Again, we'll start reviewing features a week in advance (Aug 17) to see if we move the feature to the "release" period (risky), cut the feature from 0.4 entirely, or slip the completion date for 0.4B in order to get the feature complete.

• Application WG
  • wxWidgets: generic drawer, notebook flicker, bakefiles for osx, html plan, 2.5.2 integration
  • cpia: general support, documentation (???)
  • Chrome: sidebar filtering (???)
  • Detail View: custom widgets (date/time widget, expandable block), sharing bar, conversations (stretch)
  • Summary Table View: sort, timestamp, icons, ad hoc collections, column header changes, image in header
  • dnd: content item to adhoc collection, named collection to detail view
  • Calendar Blocks: advanced info design, advanced in place editing, composite views, advanced mini calendar
  • sharing ui: sharing circle, sharing views (content item and item collection), basic email integration

• Services WG
  • Content model: work to include item discussions, python objects, contacts
  • Email: Compose and send an email; SMTP support
  • Sharing: Import changed items from collections on WebDAV server (read-only?), ExportableAddresses^?

• Repository WG
  • Version merging (threading)
  • Sharing/replication: read-write, two-way replication?
  • Queries: evaluation engine, use existing repository storage structures (indices?)
  • Security: SSL

• Issues
  • Replication & conflict resolution issues

0.4 Release

The release period will have much less feature work than 0.4A and 0.4B periods; some people will fix bugs for most of this period and we'll have more of a focus on testing and polishing the 0.4 features that are already complete or mostly complete.

The 0.4 release period has up to one month free for feature work. This is intended for feature work that slips from 0.4A or 0.4B and is well understood, or for stretch feature work if we are very good -- we do not intend to fill this feature work period with planned feature lists until at most a month or two before. Stretch features are not shown here but are considered in each WG planning page so that the design team can get a feel for what might be attempted.

Dates:

• Begin Aug 24 (or later if slippage occurs)
• 0.3.25 milestone (September 21): feature freeze
• 0.3.26 milestone (October 5): code freeze
• October 26: release

Work to do:

• wxWidgets: 2.6.0 integration
• Documentation

Definitions

Feature freeze

happens at 9:00 a.m. It means that no features which are incomplete (unusable) at feature freeze should get checked in at that date or after. Features can be merely roughly usable in 0.4 because 0.4 is still a developers release, so our quality bar is not as high as productized software. After feature freeze, developers should only be working on and checking in bug fixes. Bug fixes need approval if they're destabilizing. After feature freeze, developers are most likely to work on bugs first, then documentation and/or testing.

Code freeze

happens at 9:00 am. It means that no bug fixes should automatically be checked in after this time -- a decision to accept a bug for the current release target is a decision to risk slipping, and must be approved. After code freeze, developers are most likely to work on bugs if they have showstoppers assigned, or work on projects for the next release on their local machine or a forked CVS tree.

Release

scheduled three weeks after code freeze in order to allow the most important bugs to be found, approved and fixed during the "freeze" period.

-- LisaDusseault - 03 Jun 2004