[chandler-users] Intelligent Event Scheduling
other at peaceful.com
Fri Mar 23 07:35:09 PST 2007
Hi Mimi and all,
Thank you for your thoughtful and detailed replies. I'm going to
respond, but I know you are all super-busy (even without access to your
shared calendars!), so don't feel obligated to continue the thread.
And thanks for that topical journal entry on negotiation etc.!
In my workgroup experiences, we came up with a great many
protocols/customs in the way we did our engineering. So it would not
have been a burden for us, for example, to have a guideline like this:
"When scheduling a meeting, flag the Commitment Level appropriately if
you know it, from the drop-down list. As a guideline:
0 = No entry [default]
1 = Must attend (e.g., you're the facilitator)
3 = Important to attend (e.g., participant in a code review)
5 = Will only attend if bored"
Scheduling a meeting with a dozen people is so time-consuming because of
its serial nature: you find a proposed time, then need to hear back from
everyone before you take the next step, etc. It's great to see the
features that you're adding that will shorten this loop! For sure,
there's a plethora of other factors to consider in scheduling a meeting,
but for me waiting for responses on 'Commitment Level' caused the
majority of the iterations on the scheduling loop. I think my usual
A) Are you available anytime sooner?
B) Do you have to attend Meeting X?
C) Can you arrive late/ leave early in Meeting X?
D) How early/late do you work?
E) Can you reschedule Meeting X?
Commitment level would go a long way to short-circuiting the loops for
(A) and (B).
There are also missed opportunities. In overlaying calendars, I always
tended to just skip over (i.e., not consider) timeslots in which more
than one or two people had conflicts. So knowing up-front that the
conflicts were "soft" would have been wonderful. While
emails/negotiations are a great supplement, they aren't as concise or
efficient as a "choose one list."
Actually, I've had trouble scheduling meetings with just a couple of
people (who were not CEOs) if either: a) they were managers; b)the
scheduled meeting needed to be more than 90 minutes; or c) The
participants spanned time zones such that the working hour overlap was
reduced. The latter was particularly troublesome because the limited
overlap not only reduced the number of viable timeslots, but the density
of conflicts during the overlap was much higher since all meetings with
geographically dispersed participants needed to be crammed into the
From the responses I've read, it seems to me that the definition of
"small workgroup" is being quite narrowly defined by the Chandler team.
You're assuming that there are few if any private (detail-less)
meetings, that the number of people is pretty limited, and that the team
is homogenous enough to know at a glance the Commitment Level of
anyone's event. Excepting for family, I doubt that anything in my
career (college, four high-tech jobs at companies of varying sizes over
a 25-year period) would have simultaneously met these criteria.
If the scope is being kept narrow just for the purposes of getting the
product released, then that is emminently sensible. But I'd be
concerned if Chandler 1.0-2.0 is fundamentally based on (and limited by)
the presumption that the generic "small workgroup" has all these
Don't get me wrong: with or without the Commitment Level feature, I'm
excited and eager to use Chandler. It's just that I sense killer
feature in here somewhere, so I'm impatient. I know, I know, then I
should contribute. Well, I downloaded all 100MB+ of sources yesterday.
A billion bits is a little intimidating. :-)
Mimi Yin wrote:
> Hi Alan,
> Here's a bit more design background which may clear up a few of your
> In our experience, the tricky part with small workgroups is that it's
> hard to get to enter this kind of data into any 'system'. Many people
> simply store these kinds of fine-grained distinctions in their head.
> Many times, people don't really know if they 'need' to attend an event
> or not, because so many of these decisions are relative. Perhaps the
> event they have blocked off from 1-2PM today is not that important,
> but then again, perhaps it's more important than the event you're
> trying to book them for. They can't know until you make the proposal.
> Instead, as Jeffrey said, our approach has been to provide users with
> some flexibility around scheduling so that it's easy for people to
> negotiate their way to a good meeting time.
> Here are some ideas from a list discussion we had a little over a year
> ago: http://wiki.osafoundation.org/Journal/NegotiationAndScheduling
> That being said, there are ways to use the attributes we have today to
> figure out how set in stone an event is...assuming you're sharing
> + Event status in Chandler is specific to the user, it can be shared
> or not shared. So when an event is Tentative or FYI, it's Tentative or
> FYI to the 'owner' of the calendar.
> + Addressing fields. To:, CC: and BCC: are good clues about whether
> someone is required to attend a meeting or not.
> Finally, re: small workgroups. In Chandler vernacular, workgroup means
> an almost closed, discrete group of people working together. It's not
> to say that the workgroup never interacts with people outside of
> itself, but it would be safe to say that over 80% of people's daily
> interactions are within the workgroup. So I have no doubt that
> scheduling a meeting with just 1 other person can be extremely
> difficult, if if both people are CEO-types with tightly packed
> schedules. But the size of any individual meeting wouldn't qualify
> that group as a small workgroup.
> So you can imagine that if there is a group of 10-15, even up to 30
> people who work closely together all the time, each person would get a
> pretty good sense of all the meetings that go on within the group and
> even many of the meetings that happen outside of the group (e.g.
> meetings with board members, client meetings, etc.).
> I hope that clarifies more than confuses. You've definitely identified
> a problem that we want to solve and are working towards solving, even
> in Preview, but we're coming at it from a different tack. As Katie
> said however, we don't know what our plans are for 1.0 as of yet and
> based on the dogfood feedback we get, we fully expect to continue
> iterating on our scheduling workflows.
More information about the chandler-users