It's great to see some feature development around Drupal 7 and conference management.
The Conference Organizing Distribution shares identical goals and is also built on Commerce Registration and Drupal Commerce.
COD for Drupal 7 does need some improvement to update its historically easy to use and flexible event registration process.
One of the principles of the Drupal project is collaboration.
I invite you to join japerry, myself and others working on COD to develop a single solution, rather than fragmenting developer resources across two distributions.
Feel free to reach out to me using my Drupal.org contact form or in the #drupal-cod channel in IRC to discuss directly.
Comments
Comment #1
kscheirerI don't see how Panopoly and COD would be easy to merge, they each have quite a different set of base assumptions. Additionally with COD's use of Organic Groups in D7, I don't think the single-event-site fits as easily - COD is now more geared towards multiple or repeating events. Thoughts?
Comment #2
markwk commentedhi ezra-g, thanks for reaching out! I'll definitely make direct contact soon, so we can discuss. Definitely no intention of fragmentation at this point. Officially there is no specific "distro" at all. It's just a bunch of features that you can add additionally to panopoly. The installation profile is almost identical to panopoly with minor changes for install drush.make files. I give most of the credit to the underlying modules you and others worked on for COD like entity registration.
Just so there's no ambiguity here: I'm definitely NOT keen on creating any kind of fork. Most of my features and modules should *hopefully* work fine with standard Drupal stuff, except for the panels and panelizer parts, which really only makes sense in Panoply type sites. I probably can work on getting the hard-requirements for panels out of it too. I actually see what I'm up and COD as pretty identity feature-wise.
I do tend to agree with kscheirer that COD went in a direction I am not totally happy with as a developer/builder, in particular the use of OG module. OG module was really great in Drupal 6 but multiple versions and changes in Drupal 7 made it hard to depend on. I had some troubles about 1-2 years ago on a project with OG in Drupal 7. I haven't honestly worked on it recently, so maybe I should go back and check.
That said, from a site builder and site admin side, I think OG module shouldn't be required for a conference site. In my experience, OG tends to confuse the average drupal user / site builder. I don't want to include OG groups in my event management features at present. I'm open to be convinced of this route but don't quite see the use case for afar.
In terms of getting back to COD's ease of use and flexibility, with the features I've built so far, I think most of them includes one demo module as well. So you have the basic feature to add the functionality and a demo module to give you a clear working example. I've also built the Drupal 7 implementation of Joyride (http://drupal.org/project/joyride), which I have used for a site tour.
Let me pull up the latest version of COD and see what we can do. What's your position on OG in COD? What led to this fairly major architecture choice? (BTW -- can you point me to the discussion that lead to this choice / implementation in COD?).
Thanks again for reaching. Let's find common ground to benefit all!
Comment #3
kclarkson commentedMark,
Here is a link to the issue that moved us towards Organic Groups: http://drupal.org/node/1084462
Also please note that there are other pieces of functionality in the issue queue that led to Organic Groups such as, reporting for each event, permissions for event organizers or permissions to access session videos after you have paid or registered.
After our discussion I can fully understand your hesitation to using organic groups :0) But with Open Atrium, Whitehouse.gov, Georgia.gov and other major sites using OG, IMHO there is plenty of support for OG.
I love the idea of Panopoly and will continue to help / monitor your progress but the features that OG provides is something that my institution needs for sure.
Comment #4
markwk commented@kclarkson: I definitely see OG making sense in some cases but perhaps not all. For the time being, I don't see myself pursuing the Organic Groups route for two reasons: 1. because I just don't have any clients that must have it like this (wish I did!) and 2. I think adding Organic Groups significantly steepens the learning curve, which is exactly the thing I want to avoid.
That said, I don't see much of a hindrance for someone else adding OG / OpenAtrium integration into the Panopoly stuff I've created already and the general route of what I'm working on is open to be adapted for OG integration. I'd love to see a general situation where features built for Panopoly could also include a small helper module, so they could be made to fit with OpenAtrium2. That's the route of the discussion I opened here: http://groups.drupal.org/node/296488
Comment #5
kclarkson commentedAhh I see where you are going with this. basically you want options. If people want the OG integration then they can add it, but you don't want it required.
This makes sense to me and is following the new model of Apps vs. a distribution. I will follow your distro and see how I can add to it.
Thanks,
Comment #6
markwk commented