Drupalcon notes: Best Practices in Contrib Development and Support
For new, improving, and prospective module maintainers.
You're not forced to do anything. However, if you post it, you're endorsing it. At that point, you have some responsibility. You'll need to work with the security team on fixing vulnerabilities, and support your code. Clearly communicating your intentions to your users is good, too. Poorly maintained projects give us a bad name.
Best practices: Community Management
How to enlist help:
- Encourage people in issues
- Solicit feedback on issues/patches before committing
- Ask people who contribute a lot
- Training people is better than fixing it yourself.
Finding maintainers / co-maintainers:
- Put it on your project page
- Blog, tweet, IRC, etc
- What makes you a good co-maintainer? Involved with issue queues, IRC, forums; likes communicating; Sloppy Sam
- Abandoning and adopting modules procedure: http://drupal.org/node/251466
- Ask on the dev mailing list: http://drupal.org/mailing-lists
- Be responsive.
- Involve community members.
- Provide docs!
- Train contributors.
- http://drupal.org/node/467548 templates for issue status transitions
- Remember that not everyone speaks English natively.
Best practices: Drupal Project Management
When to branch? How to maintain branches?
- Official releases are really nice for you and your users.
- Official releases means "it's worth it to upgrade."
- Don't make a release after every commit
- Don't go months an dmoths without official releases, if you've made fixes
- It's a balance - more art than science
Source code control:
- Commit early and often. Smaller changes are easier to review, understand, and revert
- Provide credit in your commit messages http://drupal.org/node/52287
- Learn Git.
- http://drupal.org/coding-standards - handbook section on coding standards
Coding Best Practices
- http://drupal.org/node/1354 - Doxygen doc standards
- http://drupal.org/project/api - make your own API site!
- http://drupal.org/handbook - put a doc page for your module in the Drupal handbook
- Add README.txt and INSTALL.txt files to your module.
- If your module provides hooks, make a mymodule.api.php file.
- Always start with the module's short name
- Avoid collisions
- Files: mymodule.stuff.inc
Functions are generally
- Don't ever give a module, theme, or install profile the same name
- Tests make your module more reliable
- Write a test when you add a feature or fix a bug
- http://drupal.org/simpletest for documentation
- Simpletest module: http://drupal.org/project/simpletest
- Automatic testing for contrib patches: http://qa.drupal.org
- Signup to enable testing: http://drupal.org/node/689990
Drupal standard methods and APIs
- http://drupal.org/developing/modules - module developer guide
- http://drupal.org/node/326 - drupal API handbook
- http://drupal.org/project/examples - examples for developers
- http://growvs.com/n/353 - Drupal 6 API cheat sheet
- Learn to use t() except in hook_menu() and watchdog()
- Crucial: it lets your site be localized, but lets you change string presentations in an English site using locale or stringoverrides
- http://drupal.org/node/322729 - Localization API handbook
- http://localize.drupal.org - localization site
- http://localize.drupal.org/translate/projects/$project/warnings - localization warnings for your drupal project.
Make your module themable:
- http://drupal.org/node/165706 - using the theme layer
- http://api.drupal.org/api/group/themeable - API topic on themeable functions