Folks,
I'm really getting excited with all the participation! Let me take a moment to start a new thread regarding the "meta-process" I'm engaging in and what my goals and objectives are:
- Get out a new version of Events - soon!
- Work in a community context
- model good software development behavior
- document the hell out of Events for future generations...
We all agree on the basics - but I think that some of the comments are out of scope for what I'm interested in. Here's what I'm interested in - I want to get functionality out that can be used for grassroots, community based organizing - in this case Houseparties. I would also like to see the system usable by political and other campaigns to do less-formal campaign based events. In my view (which is subject to change) this does not include "volunteering", "choosing a date for a meeting", "pre-event organizing" - you get the idea.
That being said I would be happy to help document all these other issues/scopes - but I would probably need to see a clearly defined statement of functionality/description.
So if you would like to see a broader scope - this is the place to have that discussion.
Comments
History
I get the feeling from looking at what Event, Signup, RSVP, etc offer, that all this grew out of a certain style of real-world event, similar to what you are talking about, fairly structurally simple, free events which are basically gatherings of people
And also get the feeling that a lot of people use CiviCRM if they get into Event ... EventFinder is dependent on this usage
I think this is all not so good for Drupal as a product, though
Maybe it is not the responsibility of developers to think on behalf of Drupal as a general product, but somebody should
It's a great product, and it should have a first-class Event and Calendaring system, as that is certainly near the heart of any group-ware usage
It should be able to easily match what many live sites already do with events, site that specialize in events, community sites, newspaper sites, music/entertainment sites
And it shouldn't require coding or very involved theming to produce a robust event/calendar, imho
One way to go about this is each person who has a specific functional outcome in mind, simply frames requests/suggestions as parts, sub-sections of a more generic and robust overall model
I think your class diagram is a good step in this regard
If you have a robust model, you don't necessarily have to build out all parts of it right away
Some parts may remain as just placeholders, but the schema makes sense and others can jump in, extend the ui, workflow, etc, during some subsequent release, with no overall rebuild or redesign required
So, we could go for a good model that can last a while, but then as far as immediate goals for the next release, just chunk off parts of the ui/workflow that individuals want to build right now
Example: on the add Event screen, if it has collapsible areas, then in the future, additional collapsible areas can be added, without the design and flow being compromised
Same for search, etc
that's exactly what I'm hoping for
Yeah - this is the best workable model for development. There needs to be a well worked out framework and a decent set of functionality then people can build what they need.