Contributing to Drupal, the Nomensa way

Here at Nomensa we have accessibility at the heart, so when we get granted time in our schedule to work on contributing modules to the Drupal community, our first choice was to look into contributing modules that could raise the standard of accessibility across Drupal.

First step towards being able to improve a site’s accessibility is to be able to validate your site content against the various standards. Although automated tools are not able to comprehensively test every aspect of accessibility guidelines due to their very nature, they can act as a quick way to get an overview of general issues across the site. As we are also working on creating a Continuous Integration (CI) environment we are particularly interested in tools that can be used to automate checks for use in CI tools such as Jenkins.

When Alastair, our Director of Accessibility, noted the release of PA11Y, an automated accessibility testing tool, we decided to take a closer look. And upon closer examination found it could be a good fit for our purposes, hence we decided to make our first contribution module an integration module for PA11Y. PA11Y has a web service component to run automated tests on websites, giving us the option to have a centralized server running that can review all our sites on demand, a potentially good fit for our CI solution.

Once I completed a first prototype version of the module it needed to go through the Drupal project application process. Contrary to what one might think, this is in fact not a process to approve a module, but a process to approve a developer using their first module.

As everything about Drupal, it is completely community focussed, and encourages community members to participate. Of course this in itself poses its own challenges, both for those submitting to the process, and those that are willing to participate in validating. Firstly there’s a chicken and egg situation, where only those who are skilled at writing Drupal code are in a situation to easily recognize issues with module code, but to become a skilled developer one needs to be able to write modules first, and who will approve those?

Also, skilled developers are most likely to be more interested in writing code, not spending time simply peer reviewing others. Peer reviewing in itself however is also a skill any developer should master, so this in itself is a reason to participate in the Drupal module approval process, from the point of view of being a reviewer. Finally, there’s the issue with the mechanism used to encourage participation, the PAreview bonus system. This encourages those who submit modules to themselves review six other modules that are up for review, in order to receive their PAreview bonus.

Those who are reviewing modules are encouraged to first look at modules that have such a bonus attached to them, which should benefit those who are willing to put in the effort of reviewing modules. This system is open to cheating however, where reviewers simply make a comment on a trivial issue to do with semantics for instance, just so they can get their bonus. This in turn is forcing the maintainers of the module approval queue to spend their time reviewing reviews in order to stop this abuse, which in turn stops them from reviewing actual modules, causing a bottleneck.

The first step to getting your module approved is to use the pareview.sh tools or it’s automated online tool; http://pareview.sh/. This tool runs Drupal coder module and phpcs on your module code, reporting common errors and issues. There is an automated process to review your module on the submission queue, so if you don’t resolve the issue it reports your module and it won’t get approved anyway, therefore it’s best to check it passes before even attempting to submit your module for review. In fact, there are some very helpful resources on the Drupal site that pretty much guide you through the process, such as:

• Drupal Project Applications page
• Code review group
• How to review full project applicatons

All in all we found the process actually to be a positive one, despite some grumblings about having to correct spelling in comments and such trivial things. The opportunity to clean up your code, and ensuring it adheres to standards really helped improve development skills, and we are planning to integrate the pareview.sh script into our CI setup to ensure future modules also adhere to the same standards.

The main issue we had following our review is that this process seems to only applies to new applications, i.e. once you’ve had your first module approved, you are free to create further modules that aren’t required to go through the validation process, hence you can forego most of the standards altogether if you choose to. This results in the undesired effect that reviewers of your module mention issues with your code that you might have been “inspired” by code from an established module such as views, apache_solr, xmlsitemap, etc, which leaves the whole standards idea a little diluted to say the least.

A standard is only as good as those that don’t adhere to it after all. As such I’d say there’s a case for ensuring all new modules at least get tested with pareview.sh automatically before being converted into full projects.

Top tips:

• Choose a simple module with a clearly defined purpose to get approval, less code to write = less code to for others to review = quicker approval
• Ensure you follow everything in the guidelines and pareview.sh your code before you submit.
• Get your own reviews in early, and get the pareview.sh bonus!
• Listen to what the reviews say, research Drupal OO coding standards, javascript standards, and any other standards that are applicable to your code, and ensure you adhere to them.
• Finally, if you don’t agree with a review, speak your mind, but keep it friendly. After all, we’re all in this together!

P.S.: The module, if you’re interested

More Drupal posts from Nomensa

• Making Drupal more accessible
• Why you should start planning your migration to Drupal 8 and 9 now