Drupal development workflow and editorial workflow
Drupal projects have grown to rely heavily on sitebuilding. Website creators use Drupal modules like Views and CCK to create site architecture. While sitebuilding patterns have become incredibly powerful and time-saving they created a significant deployment problem: How do you deploy new features on a live site? The first, and most obvious problem was that the results of sitebuilding work needed to be exported to code. It made little sense to construct a content type or view on a development server, get it polished to your liking and then either manually do the same sitebuilding on a live server or worse yet, attempt a database merge. Now many of the sitebuilding tools available provide ways to export configuration settings. This made the promise of a mature development workflow possible.
But it also opened up a new set of problems that I don't believe the community has a good grasp on yet. Larger web projects have a strong separation between people who develop features (not the Drupal module, but more generally site features) for a site and people who maintain content, users, products, and so forth.
The ambiguity between configuration and content is not strong enough here. Some new terms are needed. I'll define development as something you need a developer to do; work that should take place in a development environment and be deployed on a production site. If it's in the development workflow, it's site development. I'll define editorial work as something a site maintainer will do. This is all work that takes place on a production site. If it's in the editorial workflow it's editorial work. Activities like adding a blog entry or removing a comment are clearly site editing. A custom module or a new custom theme would be a new feature for the site and is clearly something a developer needs to work on and perfect on a development server before deployment.
The line between development and editing is blurry. A brochureware site will generally have a services page. The product owner may want that page carefully designed. A graphic designer may spend many hours going through design iterations before the page is approved. The design may require custom HTML and CSS that is beyond what most maintainers can do. The product owner may want to see the page on the website and then go through even more iterations. The result may take so many hours that it makes sense to source control this page. A strong case could be made that this static page is no longer content but in fact site development. As such it belongs in the development workflow, not the editorial workflow.
On the other extreme there are thriving community sites that are created without a budget and maintained by product owners that do not know HTML much less PHP or the Drupal API. In this environment a development server may not even exist. All changes to the site are made on a production server. The very same people responsible for maintaining the site users and content also create content types and views. For such a site a development workflow simply does not exist. Sitebuilding becomes part of the editorial workflow.
This sprint alone I've worked on projects in both extremes described above.
It is a source of great difficulty in determining what work is in the domain of development and what is in the domain of editing. There is no right answer. The answers vary significantly between any two projects and is largely determined by budget, maintainer abilities and effort.
Site maintainers are usually really good at solving problems with the tools they have. For projects that are under continual development this can be dangerous behavior. A site maintainer may modify functionality that developers also modify on a development server. These changes are at risk of being overridden on a deployment.
As well-intentioned as they always are, site maintainers have a way of learning enough Drupal to be dangerous. I've seen sites where site maintainers create dozens of views where a single view with an argument would suffice. I've seen clients create in excess of 50 panels, where 5 would have sufficed. I've seen sites where dropdown menus have more items than the admin_menu module! The architecture of the site is at risk. Even worse, the maintainer can break site functionality through sitebuilding.
Drupal projects typically have two distinct workflows. Development and editorial. Defining what work belongs where is hard.
