22 Oct

Brian Gilbert

Unless you live under a rock you’ve likely heard that Drupal 8 has a release candidate it's second release candidate . This means that a stable release is not far away, and now much more complex sites can be built with Drupal 8 core alone.

For a while we’ll invariably still come up against projects that we have to use Drupal 7 for because you need certain contributed modules that don’t have a Drupal 8 release yet. Here are 7 things that will help allow you to build everything in Drupal 8 faster.

Help maintainers in their issue queues

When building Drupal 7 sites, take a few minutes to to look at the issue queue of the contribs you are using and help progress or close  2 to 3 of the open issues.

This is also a good way to get up to speed with a module before you use it, and looking at the issue queue is one of the ways we grade modules before using them. So it’s not a stretch to do it again for a few minutes after you have implemented the module.

For a more in depth list of things you can do to help in issue queues see:https://www.drupal.org/node/383956

Roll and re-roll patches

Whenever we build a site we’ll almost always find some modules that need patches applied, often we’ll have to create these patches ourselves. Rather than store these patches in our own private project repositories we always contribute them back to the issue queue of the project.

Uploading patches to issues queues has a twofold benefit, firstly it saves the maintainer from writing this code allowing them to perhaps focus on another issue instead, and secondly it allows others to make use of the fix up until the maintainer has time to incorporate it in a release.

If you find an existing patch that no longer applies, re-roll it against the latest development branch and upload the new patch to the issue.

Also remember to upload any partial fixes or findings you turn up when investigating a problem this can potentially save the maintainer or another user you investigative time allowing them to progress the issue further.

Mark issues as “Reviewed and tested by the community”

If you find an issue with a patch and successfully use the patch don’t just add a comment saying it worked for me, mark the issue status as RTBC, and comment about how the patch worked for you.

When marking an issue as RTBC you should provide some before and after information to show how the patch resolved your issue, screenshots or videos are often really helpful.

RTBC is relative. Effectively, it means "Ready to be reviewed by committers", with the assumption that enough non-committers have reviewed, tested, audited, etc, to catch the obvious problems. Different people set an issue to RTBC with various levels of effort. Some will RTBC just on a visual inspection of a patch.  Others will only do so if they've reviewed, audited, applied, tested, etc, etc.  Basically, you build up a reputation for how much your RTBC "counts" based on how thorough your reviews are when you mark issues that  
way.

Request contrib development time

If you work at a company with module contributors, request that they be allowed to allocate some of their time to work on their contribs. If you are in charge of developers give them time to work on contributed modules.

This has numerous benefits:

1. This can allow your developers to grow their expertise while working on a project they are passionate about
2. It’s now possible for developers to flag that development time was was provided by your company
3. Not only is your developer giving back to the community, your company is as well
4. Potential clients are likely looking for a team that is involved in the community
5. Your developer will become known as contributors and will be able to make connections with other contributed module developers that may benefit you in future projects
6. Drupal marketplace company listings are now weighted by community contribution

Sponsor development of modules

A lot of module maintainers don’t have a lot of time to spare between work and family, especially when they have multiple contributed modules. They may find it hard to allocate as much time as they like to their projects. If you are in a position to help fund some development time then you can use the contact form on the maintainers profile to get in touch.

Offer to co-maintain a module

If you're doing PHP based development at all, consider looking for a module you like that is seeking co-maintainers and offer to get involved.

Some potential benefits of this:

1. You may find a mentor to help you improve your coding ability
2. Your giving back to the community (good karma)
3. You will make connections and friendships with other developers around the world

Organise a module port-a-thon

Organise an event where people come to help upgrade modules to Drupal 8. This is possibly one of the hardest things to co-ordinate so I’m going to write a whole post about it in three weeks time.

Why did I write this?

The Realityloop team are involved with a substantial amount of contributed modules, many of which we no longer actively use. Our availability to work on these ebbs and flows and we’re sure there are other developers with modules that fit this pattern.

Not all of our modules need to exist in Drupal 8, but there are several really awesome ones Stuart (Deciphered) has written that we would really like to get ported as soon as possible.

I believe that as we are working with open source we have an obligation to help sustain its ongoing development this is the reason that Realityloop:

1. is a supporting partner of the Drupal Association
2. organises our local meetups and camps
3. share the modules we develop back to the community
4. mentors at DrupalCon’s
5. gives back to the community in many other ways

In many ways the power of Drupal is it’s contributed modules, it is this that allows us to build such a wide variety of sites. I’m sending a call to everyone that builds sites using Drupal to help get that power to Drupal 8 as soon as possible!

drupal planet