At the DrupalCon Portland 2013 COD sprint, one focus of our conversation about architecture for a 7.x version of COD was around whether to include Organic Groups as a requirement for COD, as a way of allowing for one Drupal installation/database to contain multiple individual conferences, each with their own tracks, session submission workflow, etc.
jpontani suggested that we could make OG an optional part of COD, so that sites that don't need the "multi-conference" functionality could retain a simpler site architecture, while preserving the multi-conference functionality for those sites that do need it.This could be achieved in part by using hook_views_default_views_alter() to add the OG relationship and relevant fields to existing COD views.
I'm in favor of that approach because it seems like the best compromise between two fundamentally different architectural visions for a 7.x branch of COD and ideally, would allow us to collaborate on the common, "must have" features of COD.
I recognize the signifigant value that the OG/multi-conference functionality provides for those who need it. I appreciate japerry's dedication to the COD project and recognize that his motivation largely comes from his role as an organizer for the LinuxFest NW conference, which has been the main driving force between the OG-ification of COD.
At the same time, I feel some concern that maintaining an OG-powerd COD as the default architecture increases our work as maintainers, diverts maintenance resources away from other features which are "must-haves" for the distribution, and makes COD more complex (and therefore less appealing) for some site builders.
My hope is that this compromise would allow us to meet the needs of both groups (those who value simplicity and only need 1 conference per Drupal install and those who wish to have multiple conferences in a single install).
So, my proposal in this issue is that we identify areas in the current codbase where OG functionality could me moved to a cod_multi_event (or similarly named) module
As part of the DrupalCon architecture conversation, we identified the following pros and cons to having OG required and incorporated into all aspects of COD in the 7.x branch.
Since these pros and cons motivate (at least from my perspective) making OG optional, this seems like an appropriate place to post them.
"Multi-conference site" as a default
Pros:
- Somewhat easier for some to do reporting across conferences with a single database
- Supports conferences that have multiple subconferences who also want shared static content
- Sessions (and sponsors, etc) can persist on the site across conferences
- Multi-event is a must have feature for LinuxFest NW, one current source of contributions to COD
- Attractive to organizers who run new events on a frequent basis (i.e. adding new events rather than launching a whole new site)
Cons:
Cons (of increased complexity):
- Multi-event is not a must-have feature for key COD stakeholders
-- Most camps, BADCamp and the DrupalCon sites (as indicated by DCon site owner)
-- Clear feedback from many camps and flagship Drupal conferences that complexity makes them motivated to look for other solutions: ---- Drupal community is likely to build a camp-focused alternative.
- Limited ability for variation or improvements between conferences
-- Eg, some field changes can’t be changed after content is created
-- Changes in data requirements for sessions, sponsors, etc could cause issues or confusion with previous camps
- More complex bases tend to be more difficult to extend than lighter weight ones
-- Makes site building less accessible to people not familiar with OG (aka, many Drupalers and adds a new bar to building for non-Drupalers)
-- Views, Roles, Taxonomy terms, Content need to be filtered by organic group
- Shared install & codebase increases diffictulty of differences & improvements between conferences (brand new, independent site vs shared site)
- Can’t use site wide architecture elements (eg, user roles such as speaker) because we must now set scope to a particular group
- There are proven alternatives to many of the benefits of the OG architecture
-- Shared logins: SSO/Bakery, 1-click login on Google, shared DB tables
-- Spinning up a new site: 1-click distro installs, distros in general
-- Sharing content between conferences: Single static site, copy & paste to new sites, featurized content, COD API eg (http://drupal.org/node/1663296)
-- Maintaining old sites: Disabling forms, static archives
- Folks are resistant to reading new docs (though docs could help address this point)
-- Though OG_Roles may provide an alternative in some places
- Makes it more difficult to extend with new site-specific features (i.e. new views must take OG argument)
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | Screenshot_10_21_13_11_51_AM.png | 13.27 KB | greggles |
Comments
Comment #1
kclarkson commentedGreat points here but wanted to add a little more to the "pros" to make it a bit more even.
Pros:
--More than Drupal Conferences: While this distro was designed for drupal camps and cons, there are many other conferences (education, professional associations, tradeshows etc...) that would benefit, thus increasing usage and potentially contributors. Hence LinuxFest NW
--Presenter Profiles: Having historical data from previous conferences and presentations is great for presenters. In education this is really important for the presenter as it shows their growth over the years.
--Single Domain: name for the conference each year. No need to add the year to the url
--Everyone Benefits: While some conferences say "they don't need it", they could still use it. I cannot think of one annual conference that wouldn't benefit from using an install for multiple years. Even DrupalCons and DrupalCamps would benefit from it even if they can get by without it. It would be great to go to www.drupalcon.com every year vs googling for the current year and city (yes I know it redirects).
Other Notes:
--Open Atrium uses OG: While it is a little different OA uses Organic Groups and that is a very popular distro (Ezra of course you know more than me on this).
--Complicated for Site Builders: The complexities that you mention could all be taken care of through careful UI design such as using Entity References Prepopulate, Custom Admin Views and Inline Entity Forms etc... Site builders usually want a product that works and then the ability to theme it. If its complicated from a developer standpoint it really shouldn't matter if it works :)
--Give the Fans what they want: based on the issue queue this has been a very popular request. By putting out a simple version it would only delay the progress on a multi-conference solution. We need the top maintainers to continue working on a great solution vs. putting to the back burner.
Comment #2
chrisguindon commentedI understand that having the multi-event functionality could be very useful for some but for us, at the Eclipse Foundation, I don't think this would be useful.
With this said, I don't mind if we continue working on making cod manage multi-events but I think we should keep in mind that some of us will use it as a single event website.
I would like to add that I currently need to spin out 3-5 conference sites a year for EclipseCon.
My main concerns with the multi-event functionality are the following:
- Our program committee currently chooses a different set of tracks for each conference. If I update the tracks this could cause a problem to previously created nodes from a previous conference with a different set of tracks. If this is the case I would probably need to do a hook_form_FORM_ID_alter to limit the list of tracks for each conference since the track field should include all possible tracks for all my events.
- The program committee is a different group for each conference. I currently have it setup as a user role and they have access to a bunch of admin views on the site. My concern here is that I wouldn't want a PC member to have access to the reports for an event where they are not in the PC. Is it possible to setup a user role for a group?
-We use http://www.regonline.com/ for registration. It would be a pain for my users to register for each new event on our website, before they can submit a talk for an event and then ask them to register again with regonline.
It would be nice to have an option that would automatically add all of my users to all current and future events. The main reason for this, I don't want to make it harder for my users to submit a session. Unless I am missing something but from what I can understand from OG, if I create a new event, each user will need to register to that event before being able to submit a talk even if the event is free, or paid in our case, but through reg online.
Finally I have a question, we have some events that are happening at the same time, for example next week we have EclipseCon France, the call for papers is closed but I will need to turn on the session evaluation feature. I also have Eclipse Europe where the call for papers is currently open but I won't need the evaluation feature turned on for that conference.
Will it be easy for me to enable a different set of features & functionality for each event?
Like I said earlier. I understand for some multi-event is useful but we should keep in mind those who prefer building a standalone site for each event. I think we need to set this up in a way that if only 1 event is created everything should default to that event...
For us, it's a waste of resources to maintain an old conference site we prefer achieving them into static HTML files and move on to the next without having to test new features on an old website.
Comment #3
jpontani commentedTracks would be referenced per-event using the og_group_ref field. This would allow for custom tracks per-event. Reusable tracks that aren't associated to a 'group' (event) would then fall under this problem of if you update them, then yes, old events would reflect the new tracks rather than an 'archived' revision of those tracks, unless you explicitly tell the old events to use a particular revision, which could be done.
Absolutely. OG has group roles/permissions built in, so you can create custom roles on a per-group basis and give them permissions to create specific content within that group. You can then assign roles to users, again on a per-group level. So a PC member in one group is not necessarily a PC member in another group.
This could/would be addressed in that the submission of sessions would be limited to only registered users, not necessarily people registered for particular events. Or could be managed via the same, and then upon session submission/acceptance, the user that submitted the session is automatically 'registered' if free, or have some custom code that would create a pending registration/order for that user to then go and pay for later. It's more of a site building/configuration issue rather than underlying architecture issue.
That I'm not sure. It would require some group level settings that I'm not sure what the status is for them yet.
Comment #4
japerryThose are some great points, comments, questions you make Chris -- Joe I think is pretty much right on with all of them. One key thing to take out of multi-event setup is that every event is on its own out of the box. This means that we'd use the OG permissions to setup what events have session evaluations enabled (or maybe another setting on the event group node), same for setting a schedule or opening/closing session submissions. OG user permissions would help control this.
For LFNW, we have an interesting use case in that we will reuse most (but not all) of the same rooms from year to year. Because of that, we'll still have the og_group_ref field, but since its multi-select, we can choose rooms from previous years to be used this year. If a room gets renamed, that will be made as a new node. We have about 15 rooms, 12 of them are X-100 and 3 of them are 'Sponsor A room' , ' Sponsor B room', 'Sponsor C room'. We'd tag the 12 rooms under our 2013 conference as well as 2014, but make new rooms for the sponsor specific rooms.
I agree with Kaleem that we need to make the UI for site builders easy. I presume if you're messing with our built in views, you already have experience since we have references everywhere already. OG for us is nothing more than references with user permissions right now. I don't really buy this whole 'complexity for site builders' argument. In fact I see it quite opposite. With one site, a content editor should be able to click 'add new event' and from there have the rooms and timeslots they want to select. Once they're done with that, they can click the permissions they want. This is -much- easier than the current system. This lets the development team work on a new theme (maybe look into OG theme?) or just push out a new site.
Refactoring OG into views alters I think adds more headache and time to people maintaining COD, requiring people to test both use cases in order for patches to be accepted upstream. This greatly complicates our testing system. Instead, I think it'd be better if we continue work on our 'default event' feature, which will set defaults to OG for single event sites. This will set OG defaults and be transparent to site builders, while maintaining one architecture for the site.
This got me thinking about how COD used to be and how many would like to see it be. COD grew from a single event, with simple single sessions, and single this and single that. The idea of COD in 7 (and the future) I think is to have a flexible architecture so site builders don't have to put in so much time customizing their site and breaking backwards compatibility with the upstream COD branch. If we're to subscribe to this method of thinking, we need to be thinking in many relationships and not one. We can solve the 'one' use case with defaults and wizards, and in the end, site builders won't have to hack COD to get the functionality they need.
Comment #5
coltraneI appreciate this discussion and the different stakeholder situations. I'm strongly against multi-event in COD core for the simple reason that COD doesn't have the development support to back a wizard and smart "one event" defaults on top of developing an architecture for multiple events. Commons and OA are great examples of OG-based distros with solid architecture and great features. Though both Open Atrium and Commons lagged in having a Drupal 7 version until they had full-time resources on the upgrade.
I understand that there are some people asking for (or requiring) multi-event sites, but its a hard problem to solve correctly and easily and IMO that shouldn't divert work from the standard features that the majority (if not all) COD sites need for 7.x.
As a co-maintainer of the 6.x branch of COD I saw that COD was able to move pretty fast and see strong early adoption by being lean and separating features into many components (feature modules). Only the features that were needed on 80% of sites were included back into the distribution. Similarly, sites that helped sponsor COD development always included some features that weren't part of the common need and so we skipped contributing them back to COD (e.g. regonline api). I strongly recommend keeping that approach and solving for the 80% of feature needs first instead of trying to build out an architecture that handles multiple events when there is no dedicated, full-time development support at the moment (and foreseeable future).
Comment #6
japerryI'm not sure if you have looked at the code, but multi-event support is already in COD, as well as a default event selector that automates the assignment of an event to content if you only have one event.
Except those who are actively working on COD either a) require multi-event support or b) are just fine with working within that architecture. Most of the complaints around it are people who are not working with COD and haven't actually looked at the code or tried to build a site yet. Most of the bugs around COD currently have little to do with multi-event support. Its not a hard problem to solve, and had we just made an Event CT with an entity-reference we would have never had this discussion. There is a stigma that OG is 'too hard', and that caused the issue. I agree that many COD sites won't need multi-event support, but if we don't include the CT architecture to link content to an event, those who do need it will end up forking the project.
In short, those who work on COD need multi-event or don't mind it is there, and those contributing code aren't going to write a patch to remove it. Case in point, its been 6 months and no one has offered a patch that converts everything back to a single site.
Comment #7
dyannenovaThe Drupal team at MongoDB is going to be sprinting on COD for a week at the beginning of November, and we'll definitely need to create everything with multi-event. We have around 100 events/year, and need a general events overview page, as well as one location for our events organizers to easily manage all events. The events will have completely (or mostly) different tracks, rooms, locations, attendees, speakers, and time slots, and that seems natural with the current architecture of COD, so I don't think there's any worry about being locked in to a previous event's tracks or rooms.
We've already started work on this site with one single event, and that seems straightforward. If that's all that's needed then you just won't use the Event content type for more than one event. The default event is easily set, and then can be left alone, so I don't think it should be a problem to use COD for one event only.
Comment #8
gregglesYou edited your comment to remove this, but I already quoted it. Editing should happen before hitting Save on a site that sends out emails ;)
If you want to speak in hyperboles, I'll gladly say that COD 7.x-1.x is the dead-end. I don't know of any sites that are happily using it as is other than linuxfest northwest.
I've defended Drupal7 COD over the last 2 years saying people just need to get more involved. Having gotten involved myself and filed issues and tried to help...your dismissal of the bugs and usability problems in the multi-event-enabled COD is frustrating. As a product, COD's current focus is on features that don't matter to 80% of users (multi-event) at the expense of features that do matter (e.g. registration and payment). Along with larsdesigns and others, I spent days trying to get registration to work, we filed issues, we asked for help and couldn't get it to work at all (and it obviously wasn't a pleasing experience to have to go through a lot of trouble to get something that half worked). It's true that people who need the ability to link content to an event will fork the project (or more likely have a module that extends). But they are the 20% use-case at most. Catering to them over the 80% use case is to kill the product for its stated purpose.
COD for Drupal 6 was an easy solution to recommend for events. It had the features that covered the 80% of use cases that most everyone needs and it did those things well. Camps were excited to use it. Barry Madore raved about it on a podcast. If the multi-event architecture were bringing raving fans to the project and getting them involved in fixing bugs I would support you in sticking to it. It is not (so far) bringing contributors to the project. There is a clear fall-off in contributors to the project over the last 1.5 years (which is roughly when D6 stabilized and then D7 became the focus):
It's true that 10gen is excited about multi-event COD and it's great that they are committed to working on it with such enthusiasm in November. That is, however, a risky strategy. What happens if/when they decide they don't want COD any more? By embracing the 80% use case, COD for Drupal 6 got sponsorship and patches from organizations big and small (Intel, Appcelerator, Drupal Association, an australian teacher's non-profit). If/when one of those organizations stopped funding it...the others could and did pick up. Where is that same volume and diversity of investment in Drupal 7 COD to make it resilient? Relying on 10gen to be a major contributor to CODD7 is to layer a risky strategy on top of what is otherwise proving to be unsustainable. Why do that when there is a clearly demonstrated, sustainable feature set? You've laid out your arguments. I don't buy them.
The only solution I see is to refocus on the 80% use case. To achieve that I suggest a compromise so that those interested in multi-event can keep working on it as part of the main codebase (even though that feels like a flawed proposal to me): create a 7.x-2.x branch that is single event focused and is a direct copy of codzilla and give DA's employees/contractors and Drupalcon site-builders commit access to the repositories with the understanding that they will only commit to that branch the things which they believe match the 80% use case.
Comment #9
japerrySorry for the hyperbole, it is why I removed it.
To try to get some perspective on this, I think it might be good to review the history around multiple events, registration, and contributions to COD7.
First, back in the Summer of 2012, there was peaked interest from Sean, (entity_registration aka registration module), the DA (codzilla), myself, and Ezra to get a registration system into COD. One thing that was introduced with the registration module was the Event Content type. This was needed because thats how registration module tracked registrations for free. By design the registration module supports multiple-events.
When working through the fall, there was a want to add a better configuration panel to COD, and someone mentioned the problem with having multiple events to register for, but no way to assign events to one or the other. That started the conversation of moving towards how commerce works, which associates content to products and doesn't make assumptions that your site is purely a commerce site. In the same token, it made sense that cod_support could be a set of addon modules to your existing site, where CTs related to the event would be all tied to an event as such. The first idea was just to have a simple Event CT entity reference. We had entity references throughout the scheduling system, and thus this made sense. Ezra suggested perhaps using OG because it'd give site builders additional permissions and event admin capability. I didn't see a technical reason why not to, so we did.
Late January 2013, this work was pretty much integrated in, and just before drupalcon Portland, most of the views added an OG reference field to work with multiple events. There are a few outstanding bugs, but most have been fixed that are specifically related referencing an event.
Then at Drupalcon, there was considerable debate from those who really liked this new feature and those who did not. Those who were most vocal actually didn't use COD or Features anyway. Those who did contribute back were in the 'we probably will only have one event, but I don't see a problem with the architecture' camp, and those people are still engaged in the queue.
I'd argue that the addition of OG/entity reference to CTs is not the -sole- reason why people aren't contributing back. There are many other reasons that COD7 is lagging vs COD6. And people have been more interested in getting things to work rather than stepping backwards and pulling OG out.
Since August 2012, there has only been one maintainer for COD7, me. Now that I work at Acquia, my time for COD is even less than it was, because I'm full time on Commons. We need more COD7 maintainers, something I'm going to bring up at BADcamp. There has been many things sitting in the queue for review, and the bottle neck has been me.
The DA branch is actually not that far from the COD branch. By adding a default event and reverting views, sessions are working; there are some things missing that need to be added to DA specific views, but its looking promising.
So despite this argument, COD is still moving forward. The following people have been contributing code or reviews and are actively working on COD7 in its current form.
I think better coordination in the queue and a well laid out battle plan for 'whats done' in COD-7.x-1.0 will help get people what they want. I compiled the MOSCOW from Drupalcon into a Proposed Roadmap with the features already in COD7. It can be viewed here:
https://docs.google.com/a/acquia.com/spreadsheet/ccc?key=0AkoqYoLMK8RddE...
Comment #10
ezra-g commentedI'd like to respond to what I see as a few important inaccuracies in #9. If we don't agree on the same set of facts, we're unlikely to reach the same conclusion.
1) The referenced roadmap Google Doc lists several that are marked as "complete" when that doesn't seem to be accurate based on issues filed by experienced Drupalists who were unable to use that branch to setup local camp sites. If those features need additional UX/dev work on a wizard, then they're not complete.
Eg, supporting issues:
#1981918: Make paid events work
#1979182: Create registration feature for main camp
#1846198: Why registration objects created for both the node & commerce product? - closed because the feature wast done and therefore wasn't expected to work.
Meanwhile, features #7 and 8 ("Paid/free attendee lists managed in the same system", "Create accounts for new users integrated into event signup process") which are COD's most fundamental features are in "workaround" state. To me, this is clear support for the point that the project needs to focus on development towards the "the must have" features for every COD site over other features such as multi-event support.
It seems like the difference in perspective on whether the event content type/feature is done might be the result of differing visions of success and quality: From my perspective, if a team of highly experienced Drupalists such as the DrupalCamp Colorado tech team were unable to use the COD event content type/feature to setup their site, then that feature isn't complete. They're not the only example of Drupalists who were unable to setup their site on the Drupal 7 branch of COD. We've also seen a fair number of DrupalCamp sites in the last year turn to EventBrite for registration. I'd estimate that in the Drupal 6 branch of COD, we had around 90% (or possibly more) of Drupal event sites launched during the D6 hayday use COD for event registration. What percentage do we have now? What percentage do we aim to have and do we really think we can achieve with the multi-event architecture? I mean these as [edit] *non*-rhetorical questions.
2) COD7 has no support leadership from Acquia (or anyone else)
a) The DA's work on the so-called "CodZilla" project is work on a single event branch. I agree with the proposal in #8 to make that a separate branch of COD supported by DA and others who find it useful, assuming that the DA also supports that proposal.
b) Acquia has spent thousands of dollars paying for attendance (e.g. flights, hotel) at Drupal events as well as official work time to help facilitate leadership and progress around COD. Perhaps this hasn't been "enough" time -- I'd certainly like to see us increase the amount of paid time that happens for projects such as COD going forward.
I know that since comment #9, japery has continued to work on COD and I commend that work. japerry, myself and others are on-site at BADCamp where we're sure to continue the conversation in person. I know that a goal that japerry and I share is to come to some resolution on this issue over the next few weeks so that we can focus on action and avoid diverting further energy to this conversation when it could be spend on development :).
We'll make sure that the results of that conversation are documented in this issue so that others who are not at BADCamp can stay informed.
Comment #10.0
ezra-g commentedRemoving title from body.
Comment #11
mrconnerton commentedOG is an integral part of COD.