On Thu, Jun 7, 2012 at 1:36 PM, Evan Prodromou <evan.prodro...
> Replies in-line. By the way, these are pretty distinct; I'd recommend using
> different threads for each.
If discussion for any particular item grows significantly I will split them up.
This largely depends on the activity. For instance, saying that "James
is at the store", does not tell me how much time I spent at the store.
Or saying "Sally played the game" does not say how long she was
playing. The intent is to be able to model long running activities as
opposed to point-in-time activities. The case certainly is not
applicable to all cases.
Indeed. One alternative approach is to view this a "stickiness" or
"importance" rather than "priority"... in which case, it becomes a
kind of sort key for the collection. An item with "priority":1.0 would
stick to the top of the list more than an item with "priority":0.5,
and so forth.
The main reason for modeling this as a range of values is that it
allows implementors to establish meaningful brackets on their own,
without trying to artificially fit into some arbitrary definition of
"low", "medium" and "high".
>> 3. Actionable Items ... this one is a bit of a rabbit hole really
> Yikes. This seems like a rabbit hole, indeed. Would a good example here be
> an event invitation? The expected response being an RSVP? Or a
Yes. those are great examples. Others include activities that
represents steps in a workflow.. for instance "Joe posted an expense
report" where the next actions expected are for Joe's manager to
approve it or reject it. How the specific expected action is carried
out is not important here, at a minimum all we need to capture is that
an action is required.
This particular property is fairly specific to our use cases but,
because of the potential for things getting WAY too complex very
quickly, I wanted to surface the case for discussion.