No changes are committed without a corresponding issue on drupal.org.
Patches need to be reviewed by others and must be in Reviewed and Tested By the Community (RTBC) state before committing them.
Ideally, another project maintainer reviewed them and had no objections.
However, if patches are unnecessarily held off because of missing reviews, then they should be committed, so development can go on. Project maintainers are often involved in many other projects, and they have a life, too.
Follow the best practices for commit messages.
Contributing modules and themes
When to contribute?
Has it been done already?
Can you collaborate?
Is there a need?
Have you built it anyway?
Sandbox vs Full projects
Read Applying for permission to create full projects http://drupal.org/node/1011698
12699 modules total
9016 full projects
773 4.7.x full modules
2638 5.x full modules
6189 6.x full modules
2708 7.x full modules
35 8.x full modules
Module developer tips
Don’t create duplicate work
Balance abstraction with complexity
Build a proper internal API (you’ll thank yourself later)
Use object-oriented programming
Always use the Drupal APIs where relevant
Release before a major code change is committed to the repository, not just after
Learn how to do test-driven development
Module maintainer tips
Check your issue queues regularly
Write good comments, including…
What has changed
Any information a dev might need to implement a feature
The reasons why a change may not be made
Close issues you don’t intend to work on, stating why
Created by Kristof de Jaeger
@swentel, 2367 commits, contributor to 29 modules, lives in Gent, has a Drupal tattoo
Missing Drupal feature
Change field formatters, labels etc
Consists of 1 core API module and 5 provider modules
Control presentation of fields
Display Suite in Drupal 7 http://www.flickr.com/photos/williamcromar/5345283531
Display Suite in Drupal 6 http://www.flickr.com/photos/7891209@N04/2586286021/
Things I do as a maintainer
Check the Display Suite 6.x issue queue every 1 to 3 days
Respond to support requests
Triage, prioritise and patch bug fixes
Plan development for new work in 6.x
Talk to people about Display Suite
Keep the module owner (Kristoff) in the loop
Not including new work, about ½ hr per week
Motivations for becoming a maintainer
For an existing production site:
Fix some major bugs
Add support for CCK3’s multigroup feature
Drupal 6.x still has extensive use. Upgrading to 7.x is not always possible. Display Suite is a way to improve 6.x sites without upgrade.
Knowledge of PHP, MYSQL and JQuery as a basic requirement
Able to install Drupal on a server
Able to research and install modules to meet project requirements
Able to configure all the basic modules and core settings to get a site running
Able to create a custom Theme from scratch which validates with good HTML/CSS and also pays attention to usability and accessibility
Able to customise forms, core, themes without altering core files but by using template.php or a custom module.
Able to use Hooks in the theme template.php to alter forms, page layout and other core functionality
Know the most common hooks used in custom modules for accessing the core API
Can make forms from scratch using the Form API - with validation and posting back to the DB/email
Can use Views to create blocks or pages, use php snippets as arguments, etc.
Be involved with the community, understand the naming conventions, git system and ideally have submitted some code or revisions
Be a module co-maintainer (unlikely)
Guidelines for contributing code drupal.org/node/363367
All code fully adheres to Drupal's coding standards, Doxygen, commenting, and documentation standards, and all other development standards handbook pages.
All code complies with Coder module's review rules.
All changes, especially new features and improvements, are done for the newest official branch first (master or latest core compatibility) and possibly backported afterwards.
If applicable, patches should be supplied for every branch of a project. However, focus on the latest major version first.
Discuss all changes in separate issues. Create issues for almost all changes, even if you could commit them directly. This not only allows others to review them, but is also the only way to adhere to Drupal's guidelines for commit messages.
When porting a module to a new version of Drupal core, keep changes minimal and focused. Meaning: no code clean-ups, no new features.
Defer larger improvements, rewrites, and optimizations to separate follow-up issues, in case the new Drupal core allows for any. They can be done later, and depending on API changes, possibly in a new major version of the project.
The goal is to make fast progress, allowing users to adopt the new version of Drupal core and your project.
Read and understand the meaning of major versions.
-- Daniel F Kudwein, @sun
5yr 32 wk, 3774 commits
~ 50 module contributions
#1 contributor to Drupal 7
all Drupal projects use git as their vcs
With the exception of Pressflow 6.x
Learn how to use git properly and effectively
Major versions are branches, prepended by the major Drupal version
e.g. 6.x-1.x, 6.x-2.x, 7.x-1.x
Individual releases are tags
e.g. 6.x-1.12, 7.x-1.1
With the exception of the following, no other words can be used for downloadable releases:
unstable x , alpha x , beta x , rc x
Development work should be done in branches named with the issue number you are working on