These notes will attempt to describe the structure of bedework and eventually get translated into a manual.
Public v Personal
The calendar aystem attempts to support both personal and public views of the calendar world. There are some similarities in the way they are organized but the intent is different. In the public world the intent is to publicize events. Some systems have no restrictions on who can see the events, they are intended for all. They usually place restrictions on who can edit the events, based on onership of some form. Personal events are for personal consumption, such as meetings, appointments, birthdays etc.
The calendar reflects this dichotomy. The data space is divided into two large groups, organized as trees of calendars. One is the public tree, the other is the user tree.
Personal calendars support personal or group information used by a user and/or groups of which they are a member. Bedework allows sharing using an access control system based on CalDAV so that calendars or events may be shared with other users. In many ways these are easier to understand. The personal space is a tree of calendars with a single user root. The next level down is one folder per user with the user's personal calendars under that level.
Some events are of interest to a larger group of people but are still intrinsically private in nature, that is, they are not about public events - for example, group meetings. Generally, these will be managed by a single person within the group or one who acts as an administrator for that group. The default access is private to the owner and any other access is granted either to a group or to users.
Public events are generally world-readable. They are an adjunct to web sites, mailings etc. The calendar provides information about those events in a form that can be incorporated into other standards compliant systems. Users will see these events either through the presence of a calendar on public web-sites or through subscriptions to public calendars which incorporate public events into their own personal calendar.
From the user perspective the main interest in public event is their subject. Ownership and originators usually are of little interest. If a person is interested in mathematical lectures they probably care little if the math department or the engineering school hosts it. The challenge here is to get the widest readership without annoying users or requiring them to browse through complex structures. A calendar hierarchy based on subject is usually most helpful to the user but is probably not sufficient. Tagging of events with categories provides a flexible means of associating events with topics.
Administration of public events
The intent is to try to distribute the load across the organization. Each department which hosts public events of any kind should generally wish to publicize these events as widely as possible. By using a central calendar as the starting point for a number of feeds, e.g. RSS, mailing lists, calendar subscription, they can feel that adding public events is a profitable exercise.
To avoid problems when an administrator is absent, departments can have more than one person capable of adding events. The administrative client allows for that by maintaining administrative groups. Each department will have a single group which 'owns' the events they add so that all members of the group have equal access. Associated with the group is a dummy user which is the actual owner (the "events owner"). Each group is a member of a 'supergroup' (by default "CampusAdminGroups") which gives these groups access to the public calendar space through inheritance of access rights.
These are intended to define the appearance of a calendar within a site. Each calendar suite has associated with it an administrative group and its associated dummy user. That user has a set of preferences which include the subscriptions and views. These are the views seen in the calendar when it is displayed.