I’ve been working on a few new Drupal projects this fall, as well as a WordPress site, and they’ve led me to ruminate a bunch about standards and best practices, and why they’re extra important for the kinds of nonprofits I serve.
It’s not always easy to suss out what the “standard” or “best” way to build something using open source software. There’s not a single company that’s building and documenting the product. There is a community of users and developers, though. And it’s rich with information. Sometimes, conflicting information. To make the game even harder, these platforms are always evolving, so the “best” way can suddenly change. When we’re building websites in open source software, how do we figure out the best way forward?
Take a well-beaten path. For nonprofits on a tight budget--orgs that don’t have the funds for day-to-day development support--it’s important to build on a well-beaten path wherever possible. They may have to rely on freelancers, in-house accidental techies, and they may have to do work in bursts when they’ve got money, so a lot of time may go by between web projects. So one of my goals is to make things make as much sense as possible for org staff, and for any developers or accidental techies who take over after me. When I use modules, plugins, and setups that are heavily used by the Drupal or WordPress communities, then someone else can more easily Google her way to understanding what I’ve done.
Research! I do my best to find the best or most standard path by doing a *lot* of research. And when there’s more than one way to do things (almost always), I often have to make a judgment call about which way to go. It’s not foolproof, but I figure that if my filter is *always* to aim for standard, logical, clear and sustainable methods, and I communicate with clients and colleagues about the process, then I should often land in a logical place. Some of my best resources:
- Drupal issue queues
- WordPress plugin comments
- NTEN.org Drupal Community of Practice
- Lullabot, ChapterThree, PingV, Advomatic, NodeOne (all Drupal; these are just some examples of several Drupal shops that share back quality info with the community)
- WordPress theme communities (this community run by the developer of the Graphene theme is a great example)
- Talking with other builders and developers, and not being afraid to ask questions
Source Control. One standard I can never part with is keeping *all* code in source control, via Git (always for Drupal) or Subversion. And committing the code regularly. This is a low-cost but extremely powerful insurance policy for orgs. Source control creates a pile of “snapshots” of your code, so if you take a turn and fall off what seems like the best path, you can back up and alter your direction.
Image source: Richard Masoner