At the Events 2.0 presentation DWW took notes during the session. Most of the presentation was to provide context for the Revised Event Spec – published here earlier.
Huge shout out to DWW for taking such detailed notes - I've gone through and tried to edit a bit so that people who were not there would have a little more context - DWW - if I've screwed something up please don't hesitate to point it out....
Drivers for Events 2.0 -
There is not a lot of functionality within the Drupal modules around Events.
Some of the modules don't “play well with others” and are not being maintained
CCK and the Date module are the basis for “Events”, they provide the basic structure.
We need to realize that “Events” cover a lot of ground -
- personal calendaring/meeting scheduling
- milestones (project end dates, etc)
- ticketing/eCommerce (paid entrance to event, physical ticket)
- parties and small, informal meetings
In addition to the complexity of feature sets we also have to deal with technical implementation issues like “time issues”
We began to talk about “Events” functionality by creating some large buckets in which to view events. Dan is interested in the following:
- open/closed registration
- email/web as primary interface, but needs to handle off-line stuff
- other possible requirements and ways to look at it, want to include stuff in the model
He is happy to continue building out the “spec” and adding features and functionality that are not in his areas of interest in an effort to create a single repository and knowledge base for the entire community.
There was an open discussion which touched on:
- “Events” as a single time slot (e.g. A particular presentation at a conference)
- “Events” as complex aggregates of the primitves (e.g. An entire conference made up of presentations) - A concept of an event “home page”
- There are many needs of people organizing events
- OG presents a possible direction for organizing people and content around events.
- Events will be just another node type -- can add whatever you want via CCK. “Events” will have a very minimalist set of features/fields.
We talked a bit about big training events, academic conferences
- needs are totally different, and very specific than what Dan was documenting
- 2 options to approach:
-- very small module that can be integrated into larger workflow
-- eCommerce-like package/suite that does everything
- ticketing/paying stuff is the dividing line from informal/formal? (not necessarily)
- events with sub-events
re-designing data model of events module?
- lots of work w/n CCK (KarenS's date field)
- replaces about 80% of the functionality of events.module
concerts, gigs, festivals?
- custom event types for everything?
- or is it all built-in stuff?
- gig listings is a big use of this stuff
-- need to start documenting your needs/requirements
homepage for event:
- goes further, even a small gathering needs lots of posts related to it
- CCK allows flexibility
need CCK nodes as the relationship between users and nodes
- make the relationship between a user and a node itself a node
- node-reference + user-reference fields
- other optional fields depending on sites, events, etc.
events and absence of a calendaring system?
- is events related to calendaring system?
-- calendars = pre-defined blocks of time, structure of time
- event is defined as a time period
- display of time period is a separate issue
-- e.g. views_calendar
- all issues around timezones, DST, etc, --> date primitives
- using the ISO date format standard
During the conversation we noted that it would be a good idea to replace the use of “email” with the more general “communication” which would include SMS, email, RSS, whatever.
Perhaps we should look at leveraging “relationships” within events.
- make it more generic, instead of trying to define an event container type
- show how events relate to each other and leave it like that
- all the possibilities are too complex to try to encapsulate it all into a container
- how to properly export all the CCK fields into an iCal/RSS feed
- calendar aggregator -- can't have all these different fields all the time?
different participant types:
- speakers, organizers, etc
- same emails don't go to all folks
- very complex system + requirements
should it become a full-blown project management system?
- should not go down that road
- need to keep it flexible
- could be leveraged within a PM system
Dan attempted to put his work in the context of the Drupal community
- in drupal community, it's about coding first...
- Dan: this is useful, personally for me -- does it have value for anyone else?
- dww: likes to design before coding
- fenton: more design like this would help get a lot more delivered in the long term
-- visualization of what you're talking about is tremendously helpful
- Dan: problem is people who step into the community and say: you should do this
- dominik: wide needs. good metaphor is flexinode -> CCK. things that are too focused, replacing with more generic, flexible solutions
One of the participants (name??) noted that in their practice they deliver websites to customers and:
- keep re-building similar stuff for different sites
- requirements differ so much, every time, that it's ok to have to re-build
- event == something w/ a date/time
- fundamental problem, makes requirements so difficult ...
-- e.g. training events, w/ training companies
-- variations in super events
-- volume/scale becomes problematic
-- therefore, very difficult to make a generic system
- take framework, add customizations
- drive that back into a package that could be shared
- configuring all this stuff w/ CCK @ 1 site -- hard to set it up for N sites
most of the use cases here are the same as for groups:
- each event could correspond to a group
- afterwards, use it as a community you've already created
-- formal or informal/loose
- what's the diff between a group and an event-type?
similar to the idea of an "event workspace"
- integration of OG w/ events
- all the relationship/group stuff applies at all levels of the meta-hierarchy
-- subevents or event containers both have communities associated with them
events tagged with taxonomies
- perms around categories