ioctl

Calendaring requirements.

Calendaring requirements

Initially these are in no particular order. Some of them are mine, some of them were suggested by others when I asked about this (I went looking for a product that did all of this). I'll be writing these up into a more coherent form - this is more of a brainstorm. Something missing? Drop me a line.

• User interface: views (mine, group, organisation).
• Group management: we inherit from a lot of these requirements the need to track groups - both those defined by others and user-defined ones. Membership details of groups and entry/exit etc. are also subject to ACLs for visibility/modification permissions.
• Scenario: if the semantic web allows me to determine that Charlie and Alice are a couple, Burgular Bob would find it quite helpful to find periods of two weeks or so when they are both listed as unavailable for meetings. Odds on they're on holiday. How do we combat this?
• Navigation and views (again, UI issues, but these are important) should be reasonably slick and configurable.
• Resource booking should be possible as well as getting people to meetings. Use the iCal approach of treating a resource as a calendarable object.
• Two levels of events: instances (eg, meeting, notice) and the generator of one or more instances - permitting repeated appointments, etc. Generators should be highly flexible (this group of people ought to meet once a month until further notice; such a meeting should be in the first week of the month; etc.).
• No changing the past (except for annotating previous events with information, minutes, etc), group memberships in the past should be recoverable. However, it may be that new members of a group should find previous closed minutes are now accessible.
• must know about: people (roles), groups, groups within groups.
• users must be able to define their own groups
• must handle: notices; appointments, "is X available?"
• synching: a better machine interface
• scheduling meetings for a set of people
• more structure in the appointment descriptions
• all objects with fine-grained visibility controls: personal, group, dept, public, etc.
• personalised "intray" handling of appointments: "you've been invited to this meeting. Join/decline?"
• warnings of upcoming events. What have I got on this week?
• changes to group membership should not affect history
• double-booking prevention/warning
• resource handling/booking: resources available to different categories of people
• scalable across a large userbase
• write/update permissions to appointments, etc. also fine-grained
• TODO integration? Deadlines?
• multiple interfaces: email notifications, etc.
• "what is Y doing this week?"
• Scenario - busy/available categories: eg, I'm available for meetings, but only in Boston (not Bristol), only by phone, working from home, etc. - use some of the work done for DC.coverage for geographic availability?
• (Libby) It would be good to have a public 'is X available page', don't know if that's possible.
• (Libby) Machine interface: yeah, especially an RDF interface ;-), especially by person.
• (Libby) I think syncing would be rather difficult. I'm wondering whether rdf smooshing of several calendars and then querying them would be enough (I guess that would require people with PDAs to be able to handle turning their calendar files into rdf pages somhow.
• distribution: don't rely on a single central server that knows about anyone. However, don't rely on a single installation per person either. How much fo this generality is really needed?
• More distribution: does a person have a "remote calendar API" address? More than one? How do we keep multiple instances of X's calendar in sync? (eg, two big installations and a palm pilot).
• If distributed: transport mechanism(s) should ensure reliability, recovery, security, assurance of identity, etc. as much as possible.
• Roles: single-member groups (with membership controlled by another, possibly).
• Easy one: time-zone aware / independent.
• Multi-level events: eg, a 3-day meeting with agendas for each day. Bob agrees to the timing, but regrets that he can't make it for day 3. (Scheduling different rooms for each day?) In the limit, different agenda items could be viewed as sub-events of the parent meeting; is this too cute a generalisation?
• Fuzzy scheduling. Not sure exactly what this means: currently it's just a cute phrase. "I'm 90% likely to be there", "the meeting starts at about 2pm" - analyse usefulness of this (low, I think). Although, measuring a participant's intended attendance on a (probabalistic) scale of 0-1 seems reasonable. Permits boolean or fuzzy attendance :-) Probably over-engineering here.

It's clear from the above that a fundamental need for a calendaring system is a (distributed) user/group management layer that can identify "calendarable resources" - people, roles, groups, resources.

This list should be refined into a proper set of requirements that can be used as the basis for a critique of existing standards and products.