Drupal and Public Library Policies
It's spring in the North Country...and that means that Ewa Jankowska, director of the Clinton-Essex-Franklin Library System is scheduling Trustee Forums for library trustees, so I'm dusting off my notes and slides. The first one is Saturday, May 16 10AM-1PM at CEFLS. There are some spaces left, so contact CEFLS if you're interested.
By coincidence, I'm working on a new Drupal site and had one of those moments where two different projects clicked together. The issue is policies for organizations and policies for Drupal sites.
When we kick off a new (or converted) Web site, there's usually some kind of planning meeting with management and often board members of non-profits. These meetings typically are poorly attended, because potential attendees know that language not normally used in polite society will be bandied about--words and phrases such as SQL, PHP, Javascript, HTML, and the even-stronger fighting words such as Microsoft and Apple.
I've been thinking how wonderful it is that my checklist for an initial Drupal meeting is devoid of terminology. It's all about policy issues such as who can update, edit, or delete the site's content. Just plain ordinary, understandable, and simple policy matters.
Having just gone through planning for such a meeting, I realized that it would not be simple, and that's prompted me to revise the policy section of the Trustee Forum.
Policy discussions quickly get to the heart of an organization, and can easily get out of control. I was at a library board meeting once where the simple question of whether a trusted volunteer could be allowed to have the library key to set up for a community meeting quickly ricocheted into issues such as insurance, the envelope with library fine money in the director's unlocked desk drawer, the character of the volunteer, and even the issue of whether the community group should be allowed to use the library (in the end, they were denied use of the library). It seemed to take only a minute or two for the meeting to collapse.
So now I've got an outline of issues to consider both from the standpoint of non-profits and from organizations planning Drupal sites.
1. Policies need to be clear (and not personal).
2. There has to be a quick and simple method for getting interpretations and appealing rulings. (This seems to be missing in many cases.)
3. Policy meetings are about policies: let's not talk about MARC records (libraries) or PHP. It's too easy to hijack a policy meeting into a jargon-laden coterie of obfuscation.
4. The reason for a policy should be self-evident.
On the Drupal side, it's a mistake to think that the non-jargon policy issues are going to be simple to identify and resolve. The fact that we've arrived at a point where we can discuss them without resorting to jargon and excluding many stakeholders is terrific, but the fact that these issues may not have been discussed for a long time (if ever) can make them very difficult to consider. All too often, the policy issues regarding the Web site are decided by a few people and often they're decided by the Webmaster or consultant without input from management.