Approval of Submitted Events
A common approach for vetting submitted events is desirable. Given the following use case:
- A user submits an event
- The user expects the event to appear in a particular departmental feed, e.g. a "history lecture" might appear on a history department's web site.
General Thoughts:
- Is the submitter suggesting that the history department be the sponsor or contact for the event? Or, is the goal to suggest that the event would simply be of interest to the history department (and should show up in their suite or feed)?
- Bedework does not currently implement notifications for submitted events, though it's intended (and needed).
- Events should be easily cross-posted between any number of suites and/or feeds. An important role of a public events calendar is to advertise events, so getting them to as many appropriate places as possible seems desirable. We expect to make arbitrary event tagging by calendar administrators available in v.3.6.
- Events should be easily specified by tag (category ... I'll use these terms interchangeably), creator, location, etc - so that users can pull only those events of interest to them in feeds / subscriptions. In a global calendar suite, users should not have to know who's responsible for an event to find it (in web parlance, imagine a functional architecture vs. one based on an org chart ).
- We intend both global categories and categories owned by groups. When this is available, groups can generate specific feeds based on tags over which only they have control. This will provide fine-grained control over what shows up in calendar suites/feeds/subscriptions (note also that all these can be filtered by creator too). In the short term, it would be possible to modify the admin client to reveal certain categories only to specific groups and/or automatically mark special categories under specific circumstances. A particularly good example for private categories is for promoting special events to highlight or to publish in print. In such cases, the group that owns the category should be notified so they can accept (tag) the event for their feed. Assuming the (v.3.6) ability to arbitrarily tag events, the notification might link to the event in question for the admin to tag (or not). This kind of use case would probably not ask the user to specify a group, but would have the user ask to promote the event to a particular place (e.g. the front of the campus web presence).
- We've been concerned that if a user is asked to pick a particular group to vet an event, the user is likely to pick incorrectly. For this reason our general submissions client posts to a global pool. Some thoughts on this:
- We've considered notifying all administrators of a submitted event. If a user has selected a particular group as the target for approval, that could be made clear in the notification, but it seems a good idea to make all admins aware of the event in case a) the user simply chose incorrectly or b) more than one group wants to grab hold of the event and tag it for their own calendar suite or feed.
- Having a submitter select a group to notify is one more thing for the user to think about or get confused over. Administrators, on the other hand, know which events they are interested in picking up.
- There may be an element of peer pressure in "spamming" the admins to make sure they address the pending events...
- A form at the departmental level might solicit users to "post a history department event" which could pre-select an admin group for targeting - though the user may still want to select multiple groups to suggest cross-tagging. Many lectures, for example, are cross-disciplinary.
- If you create more than one submissions calendar collection in the tree (in the /public/unbrowsable/ submissions folder) the submissions client will expose them for the user to select. You might find that using a couple of these would provide a means of targeting various subsets of the administrative groups and could provide another way to filter pending events in the admin client. Targeting large subsets seems reasonable, e.g. student events (clubs) vs. staff events (hr briefings) -- but many of the latter events are less likely to be submitted and more likely to be directly posted by the hr administrative group.
- Perhaps only a small group of people could be charged to vet pending events and pass them along to the groups most appropriate for final approval. ..."Calendar moderators" or the like.
