contributing to drupal
DESCRIPTION
TRANSCRIPT
Contributing to Drupal
Christopher Skene
Summary
What is Drupal and who contributes?
Why contribute to Drupal?
Challenges of contributing?
Types of contributions
Case study: Display Suite
What is Drupal
Open-source content management platform
A blogging tool
An enterprise-grade CMS
An extensible publishing tool
An application framework
A linked-data publishing tool
A community of 100s of 1000s of users
A collaborative development project
The best bits
Balances flexibility with ease-of-useExtensibleUses design patterns extensivelyCompletely open-sourceCollaborate with other developersCan be scaled acceptablyMost content problems already solved through contributed modulesYou can rely on community developers
The worst bits
Some design patterns are Drupal-specific
Still fundamentally based around procedural code
Learning to use the API takes time
Modules don’t always do what they say
Though improving, some internal logic is harebrained
Big implementations are no less complex than other enterprise CMSs
You have to rely on community developers
Who contributes?
Drupal 7 Core commit statistics…There were 954 people mentioned.A total of 10,091 mentions in 6,117 patches (about 1.6
people per patch)The top 10 people were mentioned in 30% of the commitsThe top 20% were mentioned in 85%People with 3 or fewer mentions form a group that are
responsible for almost 10% of mentions = long tail-- Greg Knaddison, @greggles, drupal.org maintainer
http://bit.ly/eJgMBy6yr 2wk, 1013 commits
@xtferWeb developer, project manager, communications and marketing practitionerhttp://drupal.org/user/31698 Drupal.org member for 6yr 9 wks127 commitsMaintainer for contrib modules Display Suite 6.x, Layouts, Registry, Query Tools, and the Velo administration themeBuilt a large number of government and non-profit sites using Drupal 5, 6 & 7Contributor to the Drupal 8 core context initiativeFirst module (a Drupal 5 theme engine) in 2007First module contribution April 2011
Why contribute?
It's fun to learn things.It's fun to solve problems.It's fun to help people out.The work you contribute back to the community can be multiplied many-fold by the others in the community. In turn, their work can provide a base for further work.Sometimes, it can even be beneficial to your job prospects.
-- Evan Donovan, @EvanDonovan4 yr 14 wk, 151 commits
Also…
A rising tide raises all boatsProviding solutions is the fastest way to get people to help youEveryone has different skills – the whole is greater than the sum of its parts
Challenges of contributing
Learning the basic APIs first takes timeBreaking PHP programming habitsUnderstanding the breadth of modules already availableTough review processesLots of waitingDealing with technical criticismNobody uses your module (rejection)Everybody uses your module (overload)You can, and will often, be wrong
Ways to contributehttp://drupal.org/contribute
User supportDocumentationHelp to maintain existing modules
Help maintain issue queues (triage etc)Track down reported bugs
TranslationsTestingDesign and UsabilityDonationsModule and theme development
Developer contributions
Theming (i.e. working with the theme layer)
Glue code (usually submitted to documentation)
Module patches Custom module functionalityContributed modules & themesCore patchesCore initiatives
Theming
Most people start with themingSimple PHPHTML & CSSExtending a base theme (e.g. Zen, Omega)Some snippits contributed to documentationUnlikely to result in a community contribution
Glue Code
Make modules work togetherCustomise module behaviour for a given projectRequires no module changesMay appear in a custom module or themeSometimes submitted to documentation or on blog posts, but rarely results in a module
Module patches
Bugs, features or integration work for existing modulesAnyone can contribute but module maintainer has final decisionPatches count as a commit, if attributed correctly
Basic patch workflow
Try to reproduce the issue based on the provided informationIf you can’t, ask for steps to reproduceReclassify the issue if necessary
-- How to contribute to Drupalhttp://bit.ly/u0uyuw
by Sascha Grossenbacher, @Berdir3yr 46 wks, 710 commits
Tips
Procedures differ somewhat by maintainer and moduleSome modules may be effectively abandonedGet a good git viewer
e.g. SourceTree, Tower, gity, gitx
Test fixes with a clean Drupal site and the default theme
Help a patch along…
Learn to roll a git patch correctlyUse the right issue number in your patchCheck your work with the Coder moduleIf a module has tests, update the tests if necessarySwap patch reviews with colleaguesProviding accurate and concise descriptions of problemsRefrain from posting till you’ve worked through the problem properly
Creating a patch
Set up a clean environmentApply existing patch (if applicable)Work on your fixTest (preferably using the SimpleTest framework)
Check formattingComment appropriatelySubmit the patch to the appropriate issue and mark it "Needs review”
-- Novice Code Contribution Guide, drupal.org/node/1319150 mostly by @kathyh
2yr 46w, no commits, lots of presentations
General rules for committing codeNo 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
Module stats
12699 modules total9016 full projects
3516 sandboxes773 4.7.x full modules2638 5.x full modules6189 6.x full modules2708 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
Display Suite
• 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– Custom fields– Views integration
• 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.
• Improve my reputation as a Drupal developer• Improve my employment prospects
Want to know more?
• http://drupal.org/contribute/development• http://sixrevisions.com/web-development/22-
excellent-tips-for-new-drupal-developers/• http://drupaldojo.com/• http://drupal.org/novice
Basic skills for Module Maintainers• 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 codedrupal.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
git usage• 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:– unstablex, alphax, betax, rcx
• Development work should be done in branches named with the issue number you are working on