Contributing to Drupal
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Contributing to Drupal

on

  • 1,429 views

 

Statistics

Views

Total Views
1,429
Views on SlideShare
1,426
Embed Views
3

Actions

Likes
0
Downloads
0
Comments
0

2 Embeds 3

http://us-w1.rockmelt.com 2
http://a0.twimg.com 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • - Try to reproduce the issue based on the provided information. If you can reproduce the bug, provide detailed steps and describe your configuration and other modules installed on the site where you reproduced it. - If you can't, ask for the steps to reproduce, installed modules and so on - If it's not a bug but just needs something configured differently or another module or ... explain that, switch the issue to "support request" and set it to "fixed". Even better, create a documentation page and point to it in the issue. - Reclassify the issue as necessary, maybe it's not a bug but a missing feature, or not critical but only a normal bug. (See http://drupal.org/node/156119 and http://drupal.org/node/45111 for information about what status/priority means what)
  • - Set up a clean environment for the version of the code that is specified for the issue.  - If the issue comes with an existing patch, apply the patch now, so you can correct work that was previously done. Work on your fix Test (preferably using the SimpleTest framework) - Be sure that the file has been commented and formatted correctly before creating the patch. - Submit the patch to the appropriate issue and mark it "Needs review”
  • Always use an existing solution where one exists Find a balance between sufficiently abstracted to cover multiple use cases, but not too complex as to be unmaintainable Build a proper internal API (you’ll thank yourself later) Use OO where possible, but wrap code in functional wrappers, especially factory functions Pay attention to what version of PHP the Drupal version is written for Learn the Form API and use it properly Learn how to use drupal_alter and work with hooks Use the database API Release before a major code change is committed to the repository, not just after Use the SimpleTest framework
  • Not doing anything for two years then writing "I think I have this working" is not a good way to close a thread.
  • I became lead 6.x maintainer in September 2011
  • Shiny Well-architected Built with a purpose Completely rewritten for Drupal 7 Leverages Entities, Ctools and other Drupal 7 stuff Has only one module Has a very busy issue queue
  • Built up over time A mix of styles Not all of it seems to work properly Probably looked completely different at some point Extended many times Difficult to maintain Completely different from the Drupal 7 version Built around disparate internal APIs, across 5 modules, supporting integration of roughly 10 other contributed modules Has a relatively quiet issue queue

Contributing to Drupal Presentation Transcript

  • 1. Contributing to Drupal Christopher Skene
  • 2. Summary
    • What is Drupal and who contributes?
    • Why contribute to Drupal?
    • Challenges of contributing?
    • Types of contributions
    • Case study: Display Suite
  • 3. 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
  • 4. The best bits
    • Balances flexibility with ease-of-use
    • Extensible
    • Uses design patterns extensively
    • Completely open-source
    • Collaborate with other developers
    • Can be scaled acceptably
    • Most content problems already solved through contributed modules
    • You can rely on community developers
  • 5. 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
  • 6. 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 commits
    • The 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/eJgMBy 6yr 2wk, 1013 commits
  • 7. @xtfer
    • Web developer, project manager, communications and marketing practitioner
    • http://drupal.org/user/31698
    • Drupal.org member for 6yr 9 wks
    • 127 commits
    • Maintainer for contrib modules Display Suite 6.x, Layouts, Registry, Query Tools , and the Velo administration theme
    • Built a large number of government and non-profit sites using Drupal 5, 6 & 7
    • Contributor to the Drupal 8 core context initiative
    • First module (a Drupal 5 theme engine) in 2007
    • First module contribution April 2011
  • 8. 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, @EvanDonovan
    • 4 yr 14 wk, 151 commits
  • 9. Also…
    • A rising tide raises all boats
    • Providing solutions is the fastest way to get people to help you
    • Everyone has different skills – the whole is greater than the sum of its parts
  • 10. Challenges of contributing
    • Learning the basic APIs first takes time
    • Breaking PHP programming habits
    • Understanding the breadth of modules already available
    • Tough review processes
    • Lots of waiting
    • Dealing with technical criticism
    • Nobody uses your module (rejection)
    • Everybody uses your module (overload)
    • You can, and will often, be wrong
  • 11. Ways to contribute http://drupal.org/contribute
    • User support
    • Documentation
    • Help to maintain existing modules
      • Help maintain issue queues (triage etc)
      • Track down reported bugs
    • Translations
    • Testing
    • Design and Usability
    • Donations
    • Module and theme development
  • 12. Developer contributions
    • Theming (i.e. working with the theme layer)
    • Glue code (usually submitted to documentation)
    • Module patches 
    • Custom module functionality
    • Contributed modules & themes
    • Core patches
    • Core initiatives
  • 13. Theming
    • Most people start with theming
    • Simple PHP
    • HTML & CSS
    • Extending a base theme (e.g. Zen, Omega)
    • Some snippits contributed to documentation
    • Unlikely to result in a community contribution
  • 14. Glue Code
    • Make modules work together
    • Customise module behaviour for a given project
    • Requires no module changes
    • May appear in a custom module or theme
    • Sometimes submitted to documentation or on blog posts, but rarely results in a module
  • 15. Module patches
    • Bugs, features or integration work for existing modules
    • Anyone can contribute but module maintainer has final decision
    • Patches count as a commit, if attributed correctly
  • 16. Basic patch workflow
    • Try to reproduce the issue based on the provided information
    • If you can’t, ask for steps to reproduce
    • Reclassify the issue if necessary
    • -- How to contribute to Drupal
    • http://bit.ly/u0uyuw
    • by Sascha Grossenbacher, @Berdir
    • 3yr 46 wks, 710 commits
  • 17. Tips
    • Procedures differ somewhat by maintainer and module
    • Some modules may be effectively abandoned
    • Get a good git viewer
      • e.g. SourceTree, Tower, gity, gitx
    • Test fixes with a clean Drupal site and the default theme
  • 18. Help a patch along…
    • Learn to roll a git patch correctly
    • Use the right issue number in your patch
    • Check your work with the Coder module
    • If a module has tests, update the tests if necessary
    • Swap patch reviews with colleagues
    • Providing accurate and concise descriptions of problems
    • Refrain from posting till you’ve worked through the problem properly
  • 19. Creating a patch
    • Set up a clean environment
    • Apply existing patch (if applicable)
    • Work on your fix
    • Test (preferably using the SimpleTest framework)
    • Check formatting
    • Comment appropriately
    • Submit 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
  • 20. General rules for committing code
    • 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.
  • 21. 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
  • 22. Module stats
    • 12699 modules total
    • 9016 full projects
    • 3516 sandboxes
    • 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
  • 23. 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
  • 24. 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
  • 25. 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
  • 26. Control presentation of fields
  • 27. Display Suite in Drupal 7 http://www.flickr.com/photos/williamcromar/5345283531
  • 28. Display Suite in Drupal 6 http://www.flickr.com/photos/7891209@N04/2586286021/
  • 29. 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
  • 30. 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
  • 31. Thanks!
    • [email_address]
    • @xtfer
    • http://drupal.org/user/31698
  • 32. 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
  • 33. 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)
  • 34. 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
  • 35. 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:
      • unstable x , alpha x , beta x , rc x
    • Development work should be done in branches named with the issue number you are working on