Direction for this Group: Organize and Mobilize Churches to Improve Drupal

I think this is a great goal, if a bit optimistic. I expect churches are being hit just as hard as the average person during these times, so they may hesitant to spend money on web development, especially when most churches still thing of the web as little more than an electronic brochure.

So, a big part of step 4 will be marketing; we need to convinces churches of the imperative of using Social Media/Web 2.0 technologies to connect with their congregation, and help their members connect with one another. We need to emphasize the ways in which a good web application can reduce administrative staffing needs by automating the process of collecting and updating member information & directories, managing event registration, distributing publications, etc.

For example, many moderately large churches now have a 'small groups pastor' who's primary responsibility is to connect people looking for a group with one near them, and to help new groups form. A drupal-powered directory could handle this work perfectly, with Google Maps integration to show where groups meets, and automated e-mail reminders to encourage you to actually visit one of the groups you looked up over the weekend, or notices to group leaders when they get 'hits' on their directory listing, to encourage them to send a welcome note. Now the small groups pastor can spend his time training group leaders and recommending curriculum, instead of standing in for Match.com. Or he can go start that glam metal band he always wanted to be in, and the church can redirect his already diminishing salary to orphans in Uganda.

Anyway, add me to the list of interested developers, especially if you can raise some funding. I'd like nothing more than to lock myself in a closet for a month or two and emerge with "Chrupal." I've been the lead on a similar project to develop a Drupal package for labor unions, so I'm aware of some of the choices you'll need to make and some pitfalls to avoid.

Regarding the examples in step one, CiviCRM does donor management and event registration pretty well, and it's integration with Drupal is continuously getting better, so it might be a good short term solution. In the long run, however, I would very much like to see a pure-Drupal solution for church CRM.

By the way, step 7 is launching a hosted service for churches that think 'VPS' and 'DNS' are probably slang for the latest vices in the youth group. I suspect most church secretaries would become Hindu before they figured out that they need to increase the memory limit in php.ini, let alone that that's the reason the church website is WSOD. (Only 10% of church in america have more than 1000 adult members; outside that size, I doubt churches have an IT guy on staff.)

To pull this off, I think we'll need a team something like this:

Financial Lead: Determines how & how much to pay all the people below. Determines if we need an LLC or something to protect the developers from being sued when a bug deletes all of First Baptists donation records for the past 10 years. Goes to jail when the Fundraiser discovers he's been cooking the books.

Marketing / Fundraising Lead: Organizes churches to contribute & to be the primary beneficiaries of our work. This person can identify the gatekeepers (might be pastor, might be denomination, might be elders or deacons, etc) and speak their language.

Project Lead: Defines the requirements and works with Tech lead to make sure they are implemented sensibly. This person can tell us we need Facebook integration and back it up with statistics on the number of church goers who regularly use Facebook.

Tech Lead: Manages a code repository and coordinates other developers to make sure they are duplicating effort or breaking each other's work. Makes sure developers work is abstracted enough that it can easily be contributed back to the larger Drupal community and be useful. This person can talk intelligently about the trade-offs between using taxonomies and CCK multi-select fields. Can identify when to adapt existing modules and when to write news ones.

Developers: write code. Can hook_form_alter(). can hook_nodeapi(). Can theme_function_i_just_wrote().

Drupal Liason: Works on the Drupal 7 issue queue to make sure that the eventual transition is as painless as possible, and benefits our project as much as possible. Knows and cares about database schema minutia, RDF, and API signatures. Can argue convincingly why FCKeditor should be in Core.

QA Lead: Does usability testing with church staff and tells Tech Lead when things are broken. Can translate, "I clicked the thing and it didn't work" into "The user didn't realize that he needed to click the 'submit' button after uploading a new imagefield file." Can tell the difference between a user ignorant of interfaces and a user interface ignorant of users.

Infrastructure Lead: Makes sure churches have suitable hosting for running this stuff when we're done, and/or designs a system for a hosted service. Knows why MySQL 5 is important and where to set php runtime configurations. Can separate the sheep form the goats among hosting companies. Can implement redundant back-up systems. Can acquire and install SSL certificates. Can apt-get update; apt-get -u upgrade.

Migration Lead: Oversees migration of churches existing drupal or non-drupal websites & databases to our nifty new stuff. Knows how to clean up HTML generated by Microsoft Word. Knows how to get data from Access or Excel into Drupal nodes and CiviCRM records.

Themers: Migrate existing church web design to a Drupal theme, or explain to them why it sucks so bad and give them something better. Knows the difference between $page, $node->type=='page', and page.tpl.php. Knows how to say, 'your site looks like crap' with tact.

Training/Support Lead: Makes sure churches can & do actually use this stuff. Doesn't mind explaining the same thing three times. Knows how to use GoToMeeting or some equivalent.

Support Technicians: Answers questions via a ticketing system, like "How do I change the service times that are on the front page?" or "How do I remove all the forum posts by the Junior High pastor that just got arrested?"

Obviously some of these roles might be filled by the same person. I think this project could be executed just fine with 3 or 4 committed people; but if funding is short, it might take a lot more semi-committed people.

It might also be good to organize a consulting team to help church integrate their offline activities with their new Web 2.0 presence. E.g., it's one thing to make it super easy to upload MP3 to the website, but who's going to help Father James record his sermon to MP3 format in the first place, when he still does his sermon notes by typewriter?

Best,

Matt
Ninjitsu Web Development

Drupal.org user profile
Portfolio: http://www.NinjitsuHosting.com/portfolio
Drupal Micro-blogging: http://twitter.com/matt2000

You can count me in on this. While I am a programmer, my Drupal knowledge is still short of what it needs to be to do serious development, but I can probably help with areas such as Infrastructure/Support/Migration.

@Matt2000: Well done analysis by the way.

I'd also note that some requirements will vary by denomination. Catholic parishes will have different needs and financial guidelines than say Baptist or Mormon churches.

--
-Rob de Santos
Web: http://www.afana.com
E-mail: rdesantos@afana.com

The Web Empowered Church has a reasonable package built around Typo3.
I think Drupal could support a better facility that is easier to manage.
The associated book of the same title has some good ideas for what
a church should and shouldn't do on a website.

What I've seen at our church is that the web maintainer doesn't know much
about websites, just how to push HTML that comes from FrontPage or similar
app. Once setup, Drupal is actually easier to use, but getting it designed and
configured still takes someone knowledgable. That leads to a one
equirement of being relatively simple to setup.

I also would like to see a good base set of modules specified to make it
easier for churches with very small budgets to be able to figure out what
they will need.

The Web Empowered Church is at http://webempoweredchurch.com/

DougM

The issue with Install profiles is the amount of time it takes to truly build one. You have to manually export the files out of a current drupal install and paste it in the text.

Here is the video of the presentation:

http://www.archive.org/details/DrupalconDc2009-InstallerProfiles

I am curious is a PHP file could be created to basically run a wget on a server to download a packaged install then runs the basic drupal install.php.

Maybe have a drop down list of drupal installs to grab and modules/themes and then this script grabs them and untars them in the correct location.

Not sure really if there are security limitations to this. But I suspect as long as we aren't adding any custom modules security wouldn't be as big of a deal.

I agree, creating an maintaining a profile may be more effort than beneficial - and maybe patterns would be a better way to do it (I attended the profiles DrupalCon session - but I still need to watch the Patterns one).

What I did like about profiles was the new user experience - they have ONE radio button to select at install time - and they end up with a site with the necessary modules installed, themes installed, configuration done, and sample data loaded and ready to show off and tweak from there.

Support would be simplified because it would be very easy to install the exact same site as they are working with and be seeing exactly what they are.

It would also have the potential to save a lot of time in setting up a church site if 50% if the effort to set up the common stuff could be done for you - and you only had to do the other 50% (delete some modules, add some, configure, theme, etc).

So has anyone worked with patterns enough to know whether it can give this same, one button user experience?

Great discussion Brad and Matt and everyone! I had hoped to discuss this more with everyone at Drupalcon but did not have a chance, but this will be a good place of course.

I agree that we need to organize and collaborate. We have started a wiki to collaborate on "best practices"

Visit and add to the wiki here...

http://groups.drupal.org/node/19972

Obi-Wan (Lee Raney)
Dallas Drupal Group

www.Christian.com

In an earlier post matt2000 stated that: "CiviCRM does donor management and event registration pretty well, and it's integration with Drupal is continuously getting better, so it might be a good short term solution. In the long run, however, I would very much like to see a pure-Drupal solution for church CRM."

I'm new to Drupla and CiviCRM, so this question may be a little naive. Why is it important to have a pure Drupal solution rather than leveraging the power of CiviCRM and the energy already being invested in that system?

Thanks,
Ron