View stunning SlideShares in full-screen with the new iOS app!Introducing SlideShare for AndroidExplore all your favorite topics in the SlideShare appGet the SlideShare app to Save for Later — even offline
View stunning SlideShares in full-screen with the new Android app!View stunning SlideShares in full-screen with the new iOS app!
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.
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.