Note: What is referred to here as Color Triage Status is also known as the Unpurged Triage Status.

The table below is a proposal for auto-triaging behavior in Chandler in the preview time frame. For every scenario or 'event', there is a column for whether the item is:

1. Marked as NOW, LATER, or DONE, in other words, has it's triage status Color set to GREEN, YELLOW or GREY
2. Placed in the NOW, LATER, or DONE Section
3. Placed in the NOW, LATER or DONE section in the Dashboard view when the item has been 'marked' from the Calendar view.

Some open issues to note:

1. Look out for the ?s
2. Should we auto-triage events to DONE when the end date/time passes? I think this is highly contextual. For events on calendars that are highly personal, auto-triaging to DONE may not be desirable because almost every event on the calendar produces follow-up tasks that need to be dealt with in the aftermath of a meeting or appointment. For calendars that are largely FYI calendars (e.g. Office calendar, U.S. Holidays calendar, Local event calendar), auto-triaging to DONE may be very desireable, although you could argue that users will want the event to be auto-triaged to DONE immediately after they've seen it (as opposed when the end date/time passes). Given that Preview is ostensibly focused on small workgroup collaboration on highly personal calendars and that our target user is the Hub, who more often than not has follow-up tasks for almost every meeting they run/attend, I would propose that we keep the design as is (no auto-triaging events to DONE) and consider allowing users to set a preference on a per-collection basis in the future.
3. Can we set the section triage status to automatically match the color triage status when users are marking triage status in the detail view from the Calendar app area / view? This is mostly an implementation/schedule issue?
4. Should we set the section triage status of items that have been created and edited by other sharees to NOW? Formerly, I proposed that we only set the section triage status of items created by and updated by others and that we leave edits where they are, in accordance with the item's color triage status. However, given the close collaboration we've seen amongst our dogfooders, I'm wondering if we want to treat edits the same as new items and updates.

	NOW			LATER			DONE
Event	Color	Section	Calendar	Color	Section	Calendar	Color	Section	Calendar	Open Issues
Passage of time
Alarm date/time passes	Y	Y	na	N	N	na	N	N	na
Event date/times pass	Y	Y	na	na	na	na	N?	N	na	Should Auto-triaging events to Done based on End date/time be a per-collection user preference?
User actions
Create new item	Y	Y	Y	na	na	na	na	na	na
Alarm date/time is set	Y	N	Y?	Y	N	Y?	Y	N	Y?	Only if the TS has not been explicitly set by the user. Once the TS matches both Alarm and Start date/time, auto-triaging recommences
Event date/times is set	Y	N	Y?	Y	N	Y?	Y	N	Y?	Only if the TS has not been explicitly set by the user. Once the TS matches both Alarm and Start date/time, auto-triaging recommences
Other users' actions
New item is created	N	Y?	na	na	na	na	na	na	na	Should section triage status be a per-collection user preference?
Item is edited	N	Y?	na	na	na	na	na	na	na	Should section triage status be a per-collection user preference?
Item is updated	N	Y	na	na	na	na	na	na	na
Machine actions
Problem with item	N	Y	na	na	na	na	na	na	na

Workflow for Newly created items

New items, created in all contexts:

• From the CLI toolbar text field;
• New button in the toolbar;
• Item menu; or
• Double-clicking directly on the Calendar canvas

...follow the same workflow:

1. Section triage status is set to NOW
2. Color triage status is determined by first any Alarm date/times that have been set and second by the event start and end date/times if the item is an event.

Recurrence

Recurring events follow the rules described in the table above. However, there are behaviors unique to recurrence that don't really fit into the table structure, so I will outline them here in a list.

• Instances of recurring events are auto-triaged in the same way as non-recurring events. However, barring 'modifications' to individual instances, instances of recurring events are represented by one occurrence per triage status section in the Dashboard view.
• For LATER events, the representative occurrence is the next occurrence.
• For DONE events, the representative occurrence is the more recent occurrence.
• Instances triaged as NOW remain individual events and are not 'pruned'.
• Instances that have been 'modified' and therefore appear different from other instances in the series are also singly represented in the Dashboard.
• Recurring events need to respect the stamp-based filters for each App area. For example, non-Task occurrences will not appear in the Task app area Dashboard.

---

Meeting Notes: 20070130

We had a productive, albeit slightly confused meeting today :o) and came away with some solid next actions for implementing 'smarter' auto-triaging in Chandler. To summarize the decisions that we made:

Rules for Auto-triaging based on User actions: 1. New items have their 'Color triage status' set to NOW and are placed in the NOW section. 2. New items have their 'Has been explicitly triaged by user' flag set to False. 3. When/if an user sets an alarm date/time or event date/time on the item, the item is auto-triaged according to the IMPORTANT DATE on that item (using the same logic we use today to figure out which date to display in the Date column). 4. When/if an user explicitly sets triage status on an item, auto-triaging based on the user setting alarm and event date/times stops. (More on what 'explicitly sets triage status' means below.)

For Preview:

1. We are NOT going to attempt to treat triaging in the Calendar view context differently from triaging in the Dashboard view. This essentially translates into: ignore the 'Calendar' column in the table.
2. We are NOT going to auto-triage events to DONE when the end date/time passes.
3. We are NOT going to support user preferences for deciding whether you want to see newly created items and recently edited items in the NOW section of the Dashboard view on any given collection.
4. We are NOT going to try and figure out a way to re-activate auto-triaging based on alarm and event dates set by the user, once the user has explicitly set triage status on an item.

We ARE going to:

1. Attempt to auto-triage items based on the alarm and event date/time information users set on the item; EXCEPT WHEN
2. Users explicitly triage an item by either clicking on the triage status button in the Dashboard view or in the markup bar of the Detail view;* OR
3. Items are 'tickled' into the NOW section because of an alarm date and/or event date.

*We need to be able to share that an item has been 'explicitly triaged' so that if one sharee explicitly triages an item, it not only 'turns off' auto-triaging in their Chandler, but also disables auto-triage for sharees as well. This would only apply if Triage status is being shared.

NEXT ACTION: Jeffrey and Bryan need to go away and figure out how to define #2 and 3.

In Sharing-related scenarios:

1. Newly created, recently edited, updated items and items with errors will all be placed at the top of the NOW section. The Color Triage status will be set by whatever auto-triaging rules apply.

NEXT ACTION: Bryan Stearns needs to investigate sharing the right triage status. Currently we share the 'Section triage status'. We should probably be sharing the 'Color triage status'.

NEXT ACTION: PPD update Dashboard spec.

-- MimiYin - 29 Jan 2007