>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #2009510. --> Reported by: [ezra-g](https://www.drupal.org/user/69959) >>> <p>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. </p> <p>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. </p> <p>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.</p> <p>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.</p> <p>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.</p> <p>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).</p> <p>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</p> <p>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.</p> <p>Since these pros and cons motivate (at least from my perspective) making OG optional, this seems like an appropriate place to post them.</p> <p>"Multi-conference site" as a default</p> <p>Pros:</p> <p>- Somewhat easier for some to do reporting across conferences with a single database<br> - Supports conferences that have multiple subconferences who also want shared static content<br> - Sessions (and sponsors, etc) can persist on the site across conferences<br> - Multi-event is a must have feature for LinuxFest NW, one current source of contributions to COD<br> - Attractive to organizers who run new events on a frequent basis (i.e. adding new events rather than launching a whole new site)</p> <p>Cons:</p> <p>Cons (of increased complexity):<br> - Multi-event is not a must-have feature for key COD stakeholders<br> -- Most camps, BADCamp and the DrupalCon sites (as indicated by DCon site owner)<br> -- 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.</p> <p>- Limited ability for variation or improvements between conferences<br> -- Eg, some field changes can&rsquo;t be changed after content is created<br> -- Changes in data requirements for sessions, sponsors, etc could cause issues or confusion with previous camps</p> <p>- More complex bases tend to be more difficult to extend than lighter weight ones<br> -- Makes site building less accessible to people not familiar with OG (aka, many Drupalers and adds a new bar to building for non-Drupalers)<br> -- Views, Roles, Taxonomy terms, Content need to be filtered by organic group</p> <p>- Shared install &amp; codebase increases diffictulty of differences &amp; improvements between conferences (brand new, independent site vs shared site)<br> - Can&rsquo;t use site wide architecture elements (eg, user roles such as speaker) because we must now set scope to a particular group</p> <p>- There are proven alternatives to many of the benefits of the OG architecture<br> -- Shared logins: SSO/Bakery, 1-click login on Google, shared DB tables<br> -- Spinning up a new site: 1-click distro installs, distros in general<br> -- Sharing content between conferences: Single static site, copy &amp; paste to new sites, featurized content, COD API eg (<a href="http://drupal.org/node/1663296">http://drupal.org/node/1663296</a>)<br> -- Maintaining old sites: Disabling forms, <a href="https://groups.drupal.org/node/84644">static archives</a></p> <p>- Folks are resistant to reading new docs (though docs could help address this point)<br> -- Though OG_Roles may provide an alternative in some places</p> <p>- Makes it more difficult to extend with new site-specific features (i.e. new views must take OG argument)</p>