Planning your public events system

Start with a sketch

A good way to start is to sketch out a hierarchy of calendars that work in your organization.  Start modestly, with a sparse tree of calendars that you'll likely end up using.  It's much easier to add than it is to move calendars (and their attendant objects -- categories, topical areas, and subscriptions) around later.   By the time you've instantiated your modest tree, you'll have the know-how needed to configure Bedework in the shape of your organization.

If you loaded the recommended data set when you initialized Bedework, you already have a hierarchy that can serve as a starting point or as an example.   Click on View All Calendars in the public client (yourserver:8080:/cal) to take a look at the shipped hierarchy.  

There are many kinds of calendars (event collections) that you might want to have.  It is likely that at least some departments or offices in your organization will want their own calendars.   It is also possible that you'll want to have calendars that group like events together.  For example, you might want holidays collected on a calendar.  You also might want to have social events on a separate calendar.   You'll also want to consider grouping calenders into folders.

There are two primary considerations in deciding how to group calendars together. 

1. Since in the usual configuration, everything in a folder will be tagged with a common tag, would anybody be interested in the whole collection?  For example at a university, a folder called School of Science with members that include Biology and Chemistry probably works better than a folder called Departments with members that include Anthropology, Engineering, Biology and Medicine; while users might be interested in looking at which events occur within the School of Science, they are unlikely to be interested in events that take place in any department because it isn't a particularly useful way to filter events.
   
   
2. This will be become clearer later, but it is often useful to tie a View to a folder.  You can see the views along the left-hand side in the public client.  The considerations are much the same. 

In general, there are two common ways to group calendars:  By organizational structure (example: School of Engineering folder with Civil Engineering and Mechanical Engineering as members) and by function (example:  Lectures, Seminars, and Conferences folder with Lectures, Seminars, and Conferences as members).  Many organizations use both kinds of groupings.  The advantage to the "both ways" approach is that events can be routinely tagged twice: one tag to indicate who the event is associated with and one to indicate what kind of event it is.  Users (and web sites than consume events) can then easily filter events by who or by what kind.