Design principles

• It's about contacts. Seltzer is for managing data about contacts, so the contact is the basic data type (compare to Drupal's "node"). Features that are indirectly related to contact management should be kept to a minimum. Features that are not at all related to contact management should be kept out of the application.
• Modules, not options. Too many configuration options can be overwhelming to new users. In volunteer organizations, being able to get new volunteers up and running quickly is crucial. Modularity allows users to learn a system and add functionality/complexity as it is needed.
• Do not hack core. Do not modify Seltzer CRM code to make it do what you want. Instead, you can create your own module to extend it. If you have a feature request or bug fix, post it to the issues section and/or email us on the developer email list. This philosophy is borrowed from Drupal, here's more info.