Last updated by stefanwray on Fri, 2012-11-30 23:21
Purpose
This document is for Executive Directors and staff at community media centers (CMC) and public access stations involved in the Community Media Drupal Initiative.
The premise is that CMCs and stations around the country have the capacity to organize and work together in a distributed, networked, environment.
The purpose of this document is to establish a guide to better understand the:
- roles required to share this development work
- tasks that are needed to get the job done
- knowledge and skills necessary to perform the tasks
- time needed on a weekly basis to dedicate to the project
- way to seek outside support and how to ask the effective questions
This document is directed more toward CMCs or stations that have an existing community media Drupal installation. It addresses the roles, tasks, and knowledge needed to maintain, upgrade, and expand an existing Drupal web system.
Modular Development and Distributed Responsibility
Each community media Drupal installation has at least three levels of code:
- Drupal Core
- Contributed Modules & CiviCRM
- Community Media Modules
- Custom Modules (optional)
As of this writing there are about 12 Drupal modules with “community media” in the title and more than 50 modules have been written just for this community media Drupal initiative. Most of these have been deployed in three Community Media Starter Kits. The Lead Maintainer for the majority of the community media modules is Kevin Reynen.
The goal of Community Media Drupal development is to not just to share the development cost of writing new Drupal code but to share in the ongoing work of maintaining, upgrading, and improving the specific Drupal modules.
It is important to understand that the actual writing of code is just one part of a Drupal module’s life cycle. Module development is an iterative process where there is ample room for non-coders to be engaged and helpful in determining new features, testing configuration and use, documenting processes, or handling support requests specific to that module.
The theory behind this type of collaboration is that if each involved CMC takes ownership and responsibility for specific community media modules, then we can:
- Better define shared needs and development goals
- More evenly spread the workload and reduce reliance on Lead Maintainers
- Reduce overall development costs
For background information on some of this see Report on the Community Media Drupal Summit.
Roles
The distinction between different roles is important. In addition to the usual Drupal roles for an installation (administrator, user), there are internal and external organizational roles.
Internal Roles
Each CMC may have one or more people who make up some combination of these roles:
- Executive Director or General Manager
- Site Administrator
- Co-Maintainer (can be the same person as the Site Administrator)
- Staff User
External Roles
- Developers
- Lead Maintainers
- Co-Maintainers & Site Administrators at other CMCs and stations
- Executive Directors and Leaders at other CMCS and stations
Tasks for Internal Roles
Executive Directors
Effective collaboration among CMCs on community media Drupal work requires support for this process throughout the organization but it especially requires a commitment from a CMC's Executive Director. In addition to making sure the organization has staff with the appropriate skill sets, Executive Directors need to ensure that staff have the time and resources to work with their counterparts at other CMCs. Executive Directors need to help cultivate an understanding and practice wherein CMC technical staff are part of the organization's team, but also part of a larger team of peers to which they may both give and receive support and guidance.
Site Administrators
Much of the administration work involved with the community media Drupal installations is fairly typical to Drupal administration and involves tasks such as:
- Upgrade modules
- Ensure site gets backup
- Monitor reports and logs
- Administer user accounts
Co-Maintainer
Every Drupal module has at least one Lead Maintainer and any number of Co-Maintainers. Lead Maintainers are Drupal developers chiefly responsible for writing and maintaining the code for a Drupal module. Co-Maintainers assist the Lead Maintainers and act as intermediaries to handle a variety of tasks that do not require knowledge of actual PHP coding.
The tasks of a Co-Maintainer are different than what is defined under Best Practices for Co-Maintaining Projects on Drupal.org. Rather, the function of the Community Media Co-Maintainer is more like the Product Owner as defined in the Agile development process. For an overview of the Agile process watch a video of a presentation from the Community Media Drupal Summit in Austin.
One of the Co-Maintainer’s main tasks to monitor the module’s issue queue for:
- Bug reports
- Feature requests
- Support requests
(Basic) When handling bug reports the Co-Maintainer:
- Verifies that errors are reproducible and not the result of misconfiguration
- If errors are due to misconfiguration, then he/she edits and improves documentation
- If errors are legitimate, then he/she assigns the issue to the Lead Maintainer
(Advanced) When a bug has been fixed by the lead Maintainer, the Co-Maintainer:
- Uses git to pull the code to a development server
- Tests the code to make sure the issue has been resolved
- Commits the code back to Drupal.org
- Closes the issue as fixed
When handling feature requests, the Co-Maintainer:
- Responds if needed to clarify the feature request
- Determines whether the feature request is appropriate for the module
- Prioritizes feature requests with higher priority for shared needs
- Consults with CMCs to determine if/when feature gets funded
Knowledge and Skills Needed
Documentation
Git
Seeking Support Effectively
Issue queue
Drupal.org has an extensive section on support.
Time Requirements
The amount of time necessary for CMC staff to devote to this work depends on several factors but especially important is the phase of the project. During initial needs assessment, site planning, installation, configuration, and other activities that are considered to be pre-launch the staff time commitment could be considerable, especially if there is minimal support from outside developers. Once a site has launched the time commitment reaches a plateau. It is difficult to estimate.
Challenges
The organization of this initiative presents a number of challenges, chief among them are the following questions:
- How to acclimate new development talent to the cm_project?
- How do shared feature requests become funded development?
- How does this scale from small, to medium, to large CMCs?
About This Document
This document was initiated by Stefan Wray of channelAustin on November 28, 2012.
Comments
What's the goal?
I am working off an assumption that the configuration, administration, knowledge and collaboration are all moving towards the completion of the three kits: easy through difficult.
What is the goal of what?
@jdcreativity - what is the goal of what? this document? or collaboration? or community media module development overall?
the goal of this document in my view is to establish some common understandings of what the requirements might be for a community media center that wants to engage its staff in this effort.
i think the goal of collaboration is to try to spread out initiatives, costs, and ownership of various aspects of this model to a range of organizations.
one challenge as noted in the text above is that we our organizations vary in size - which means variance in the relative amount of time and resources that can be committed. there is also variance in the configurations of cmcs (some are pure P, some are PE, some PEG, etc) as well as business organization and internal policies and procedures (degree to which end users are in control)
so there cannot be a one size fits all approach.
my goal in writing this is hopefully to get us to focus on all of it. we are at a point where this initiative could go in different directions.
how we proceed -in terms of cost of development, method of determining shared features, sense of participation in a national team effort - is contingent upon and a function of the degree to which each CMC is invested
Drupal often requires skills no longer common to non-profits
Due to the technical and workload onus on Drupal administrators and co-maintainers, I no longer recommend Drupal to small non-profits or businesses that I work with. In my experience, Drupal continues to require extensive proficient and advanced technical resources, which are unfortunately not common or affordable to non-profits in my geographical area (Silicon Valley, Monterey Bay, and SF Peninsula).
I'm glad to see this document (and others like it) come to life. I'd encourage all CMC ED's, board members and stakeholders to explore the tools and resources available in this (and related) project(s), and to make some hard choices about what resources that they have available to implement and sustain Drupal and other OOP resources in their organization.
@videohead so what do you
@videohead so what do you recommend for CRM and CMS?
Mixed bag
I usually do a site assessment and try to get a sense of what the organization's skillset is, and where they want to go. Joomla usually meets the CMS requirements handily, although WordPress is occasionally a better fit because they already have an investment there.
I'm still an advocate for CiviCRM, although the small number of supporting vendors can be a REAL problem.
Other CRM solutions that I recommend:
Podio
Sage
SugarCRM
Dynamics
Salesforce
I hear where you are coming from.
As someone that has recommended CMC's to adopt Drupal for the past 5 years I hear you.
I've seen a fair share of stations switch over to Wordpress over the years. I know of at least one station that would love to get off a site on Drupal 5 but can't. I know of a few smaller stations that have really taken Drupal on their own and done very well (on Drupal 6 and Drupal 7). We all know that Denver has a 2.0 release for their Drupal platform. And then there is this group trying to do work together.
I hope that at the core of this document is a methodology for collaboration that extends beyond one specific software.
But, for the moment I can say as a site administrator that Drupal 7 provides easier tools and processes to effectively manage an ongoing Drupal site than previous versions of the software.
This project is a lot of work and it is not for everybody (yet). Organizations need to both make this a line item and provide a timeline that matches their organizational capacity.
While the OMF may have code
While the OMF may have code they can build sites with, I wouldn't call that a 2.0 "release" since they aren't releasing the the code even when you ask for it. What was demonstrated at the AMC is still a work in progress and @choicelildice left the OMF shortly after the conference for another Drupal shop...
http://drupal.org/node/1853916#comment-6791072
As far as I know, neither denveropenmedia.org nor Long Beach Public Access Digital Network are using what was demo'ed at the ACM. Someone please correct me if I'm wrong about that.
As far as WordPress vs. Drupal, now that CiviCRM works with Wordpress (in addition to Drupal and Joomla) I think that can be a unifying feature. WordPress on it's own isn't really the same level of solution as drupal.org/project/cm_starterkit_moderate. I believe that Drupal still provides a better framework for building multi-user, self service solutions, but WordPress + CiviCRM is an excellent CMS + CRM.
The hope with http://drupal.org/project/cm_starterkit_easy was to be as easy as WordPress when used with the http://drupal.org/project/cm_checklist and documentation maintained by the community. While we have gotten CiviCRM packaged into Drupal at the moderate level which makes building a solution at that level much easier, the Easy Starter Kit still isn't something I would recommend to users with little or no Drupal experience.
Similar to the saying 'dress for the job you want, not the job you have', most members of the cm_ community can only support functionality easier than what they are currently adding to their own site and that requires a commitment to spend some time working on things that aren't directly benefiting you or your organization.
In regards to the clickable
In regards to the clickable agenda code referenced by "they aren't releasing the the code even when you ask for it", I apologize for missing your post. Emily Frazier emailed us directly awhile back and we sent her all the relevant code from what we have installed on Colorado Channel so she could decide what parts she might want to integrate with http://drupal.org/project/cue_builder.
I can confirm that Long Beach is not using the omp modules we've been working on -- we ran into some hurdles in regards to what the modules did "out of the box" vs the specific needs of their station combined with some bad communication in the period after choicelildice left us for Elevated Third (not choicelildice's fault in any way, he has been nothing but supportive).
I'm still very excited about the Open Media Project (in all of its current incarnations) -- we're focusing our reduced capacity on deploying all of our latest code at Denver Open Media now and once we finish that (~February) we'll assess where to go from there.
Open Media Foundation
Just to confirm that
Just to confirm that civipixel did share this code upon my asking, which was definitely helpful. The module itself is Drupal 6 and likely not something that cue_builder will reuse, and although I think it might still be applicable to use some of the javascript, my own time constraints have taken me away from the cue_builder project in the past couple of months and so I haven't looked further at that. Cue_builder is also moving in a couple of different directions, and changes to the structure need to be made next before anything else. As to the denver module, it might be good to post it up as a sandbox project or such so that others also have access to it.
Committing to Collaborating
Everyone involved in CMD has expressed a desire to collaborate, it strikes me that perhaps there’s a better way to communicate to help focus and coordinate this collaboration, which was one of the goals of the Austin Summit 7 months ago. Each of us has other roles and is involved in other projects, and in many cases is getting used to this setup, we’re at the shaping stage, and this is part of that.
Stefan’s nicely delineated some of the expectations above, I think communicating and sharing are the most important, and perhaps having a singular product owner and project manger to help shape that, although I feel many have rotated through that role quite nicely for some months now.
The weekly Google hangouts for CMC staffers have been really useful when I’ve taken part, maybe a monthly ED conference call would be prudent, or perhaps an ED get together sometime soon in the Northeast as several centers are geographically proximate.
** Some immediate help would be a volunteer to organize that and also to arrange a space and schedule for the ACM. **
Collaboration takes many forms, and a lot has been happening within the world of CMD. The exchanges are not always visually manifested and not always immediately evident or evenly determined, because the very different organizations and people working together have different, skills, timescales, expectations and final goals.
Sometimes, we aren’t even aware of a benefit we might otherwise have invested considerable time or money in – like when someone who isn’t even involved in this particular project updates something in Drupal or CiviCRM that benefits us all, and we don’t give a seconds thought.
If you give back you get back – you learn and can support yourself better. If we don’t reciprocate we will need to reconsider this initiative as a commercial solution, which will require paying considerably higher development costs.
I intend to contribute by continuing to play my part, and trust others will do the same. If you're stuck for something to do, or need help, ask - on GDO, on the Hangouts, on email - but ask everyone, this isn't a project with a singular focal point, we all share the responsibility for its growth, orientation and deployment. We can budget our time and resources, as I believe we have been, to make this a success, together.
Managing the Collaboration
Agreed. Identifying a sustainable method of project coordination is crucial to the growth and success of this initiative.
If the expansion of the starter kits is any indication, this endeavor has grown substantially more complex and has many moving parts. How this collaboration is managed is crucial, and seems to have remained elusive over the past 7 months. Without clarifying roles and structure for this collaborative work, it is going to be difficult to achieve what we all envision for the project. This document that Stefan has created is a great start for applying structure to the work.
Managing the collaboration is an important topic that should be addressed by this group, and more importantly, the Executive Directors in the near future. What does this look like? A structured community media consortium? A steering committee? If each CMC gives back to this project and volunteers as co-maintainers, project managers, etc, can the collaboration be coordinated without such a governing body? We all want this project to evolve and remain cost effective through shared funding and development, but I think that is going to be difficult to achieve without a structured body coordinating the work.
This is a classic Cathedral
This is a classic Cathedral vs. Bazaar dilemma. We've made a lot of progress in defining what is shared and common in the starter kits over the last 6 months. At the Difficult Level, the kit becomes less of a tool used to start a site and more of a way to coordinator major changes between the larger stations.
Co-Maintaining
For me Stefan’s document reveals how important coordination is to the success of this project. While the EDs resolve certain issues, Site Administrators, Co-Maintainer etc can continue to use our online meetups to discuss problems and possible solutions to issues they've encountered with various modules. I think Co-Maintainers having a central place like cmdrupal.org(site currently under maintenance) to test new features, verify that errors are reproducible, among other uses, is critical to the project’s success.
The site is the main topic for our next online Meetup on Dec. 19. I’m hopeful we can explore the use of the site by Co-Maintainers for testing.
I think testing sites are
I think testing sites are great, but I don't thinks it should be Aric's responsibility to main these for everyone. I create new sites either locally on my laptop using MAMP or on a virtual server for almost every module I maintain with only that module and it's dependencies enabled like http://isotope.alittlehelphosting.com/, http://popcorn.alittlehelphosting.com/, http://media-s3.alittlehelphosting.com/, etc.
The Moderate Starter Kit is now my standard base build for test sites. Stefan started Code Upgrade Process for CM Module Maintainers and Co-maintainers when we discussed this at the Community Media Camp in Urbana. It's still pretty confusing and would benefit greatly from some diagrams and geek speak -> plain english translation.
The gist of this workflow is to create a basic site just for testing like http://popcorn.alittlehelphosting.com/ -> Test the installation and configuration there with only a few other modules enabled -> Commit those changes to Drupal.org -> Pull the changes to a dev site with more configuration and content -> Test the updates again.
If everything works, pull the change to the live site, mark any open issue or feature request as fixed, update any of the documentation, and possibly role a new release.
There can be many variations to that workflow. The most common is when the co-maintainer/product owner isn't at the point they feel comfortable with 'git push' and only use 'git pull' to test issues marked as 'needs review'. I've introduced many of you to the joys of git pull when we are trying to resolve an issue. While the commits I make to Drupal.org are eventually rolled into a new dev snapshot you can download with drush or the web based admin/modules/install.
When Easy Starter Kit got the point is was getting stable, I added an additional virtual server to most of your virtual servers and encouraged you to go through the configuration process and open issues for anything you encountered.
I would love to see http://reservations.channelaustin.org, http://cm-theme.okv.se, http://telvue.accessvision.org, http://civicrm-certify.pcmtv.org, http://crew-connect.phillycam.org, etc, linked as demos from the project pages and used for testing and demos.
I've been working on documentation for Starting, Updating, and Upgrading Community Media Distributions. I'd be glad to add documentation for adding a sub-domain for testing and while I've already show how to Download and Install the Current Versions of Drupal and CiviCRM < 10 minutes, with a few command line instructions and drush, you can actually do this in < 5. My starting with a fresh install of the current version of the Moderate Starter Kit and then overriding any modules included in the profiles/cm_moderate/modules by placing an updated version in sites/all/modules you know that your a very close to the same version of all the modules other cm_ users should be using.
I think testing sites are
I'm sorry I didn't make it clear , the intent was never for Aric to be the only maintainer of cmdrupal .org if it were to be used as a dev site. When he and I emailed, the purpose of the site was open and using it as a dev site was just one option.
My next step is to review your suggestions and develop a workflow that manageable.