Matt Farina

Conference season is again upon us and this is the time of year I'm usually planning trips with brewing excitement. But, with the birth of my first child happening right in the middle of conference season I'm bowing out of all of them this spring. So, instead of writing about the conference I'll be attending here are some I would have attended if I wasn't already busy.

Churches use metrics and polling to try and figure out what works, what doesn't, and to gain some insight into the world around them. I'm a fan of metrics. They are a great way to observe what's going on and learn. For metrics to be usable the points measured and the way they are measured is important. This is where I've seen an enormous number of churches go terribly wrong.

Churches put a lot of time and thought into marketing themselves. The church marketing community has grown so large and vast the are even sites that parody what churches do. Some churches have marketing people on staff. And, every year millions and millions of dollars are invested in church marketing.

Yet, I submit that churches should do no marketing. Am I crazy?

It seems the issue of a lack of good available themes for Drupal has really come to the forefront this week. Not only have Todd Nienkerk, from Four Kitchens, posted about the problem and Morten posted a CVS Haiku but, we have lost countless hours in Design for Drupal meetings and IRC talking about this. One thing seems for sure. As Leisa Reichelt points out, the current drupal.org setup to contribute a theme has a high barrier to entry.

It's time for the Drupal web designers and front end developers to have their own home. This is the message coming across loud and clear at the moment.

Drupal.org was built for back end developers, programmers, and the community at that time. Over the years it was architected around those users and their needs to build a great product. But, times have changed and we have users with different needs. One group looking for their own place and set of tool is the web designers and front end developers. It's time to build it.

Back at Drupalcon DC we started to talk about what the need would be. We started a group on groups.drupal.org to get the conversation going. But, the groups system wasn't really built around the needs of the design for drupalers. It grew quickly but became stagnant. What was really needed was 2 things. A project management tool to manage the tasks of the group and a home built specifically for front end drupalers.

Churches aren't like other organizations. I regularly hear about them being compared to non-profits, aid organizations, or other volunteer organizations. This misses the mark in a big way and I'm not talking about the God factor. Let me illustrate what I mean.

Take a homeless shelter. There are 2 groups of people at them. There are those who are there running the place, feeding people, and working for the mission of the homeless shelter. Then there are the homeless people that are served. This is pretty straight forward.

The mission of the church (Matthew 28:19-20) is to go and make disciples of all nations. But, if you look at the church staff they are typically interacting with Christians around activities centered on Christians (like worship). Of the non-staff members only a small percentage volunteer and most of the volunteer time is spent on activities like worship, bible studies, and other things that are targeted at members of the congregation. The rest of the non-staff members attend Sunday morning worship on a semi-regular basis. This is a majority of the church.

Notice the difference? The members of the church and what they do doesn't revolve around the mission of the church.

The Drupal ecosystem has created a new title and job you don't find elsewhere. That job is of a themer. The name is built out of the Drupal theme subsystem. When we have had discussions regarding who the theme system should be built for or when we have talked about who the design for drupal movement is for the discussion has often turned to a conversation discussing a themer vs. designer. The problem is, for the theme system there is a better target than either of these and one the web development community at large will understand.

For many years the Drupal core development process has served us well. With Dries and a co-maintainer committing the changes of the community we have crafted a product we love and hate to use and a community we are involved with. But, the success of Drupal is stressing this 2-tiered development system. After talking to numerous leaders in the community here are a few suggestions as to how we can scale this system and relieve some of the stress for Drupal 8.

The Strain

The Drupal community has grown in size and the Drupal core package has grown in size and complexity. For anyone now sure what I mean just download Drupal 7 and compare it to Drupal 5 or 6. In many ways I think all this new stuff in Drupal 7 is good. But, we now have two big stresses.

Have you noticed that many churches aren't really communities? Some claim to be communities and a handful actually are. But, many churches are actually organizations that look more like a business with a congregation consuming services and products put out by the church staff and a handful of active volunteers. This is a problem happening at my church and something many of the churches leaders would like to change.

My old Drupal core development workflow revolved around CVS. Anytime I'd want to work on a new feature I'd do a CVS checkout of Drupal core and start working on the new feature. If I, or someone else, was working on 2 features that overlapped in code I would have to deal with massive conflict resolving or just have to wait until the other feature was committed or abandoned. Oh, and I had to be connected to the Internet to grab a new CVS checkout. That all changed when I switched to Bazaar for my core development work.

Some Of What I Can Do With Bazaar

Bazaar, a distributed version control system, let's me do a lot of things that simply can't be done with CVS or SVN. Here's a short and incomplete list:

• I don't need to be connected to the Internet to create new feature branches.
• Merges are much better making them useful. That makes branches cheap, easy, and useful.
• I can make branches of other feature branches allowing me to layer patches and issues.
• Did I mention merges are better. This means a lot less conflicts to deal with.