Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough

Diaries of a module maintainer, part 1 - Gardening the issue queue

I've been maintaining a growing amount of modules over the years. I am starting to document my observations, habits and challenges, in the hope they'd be useful to other Drupal coders.

I devote time and energy to the development of a module. Since I consider myself a software craftsman, each module is a creation of mine - an artifact to which I try to imbue functional and aesthetic values. I also imbue each module a life of some sort, since it will be utilized on (hopefully) many sites, go through evolutions, and have a lifetime until it is no longer needed and used.

All this just to say that I develop an emotional relationship toward each module, and the moods of these relationships are reflected in my habits.

Handling issues is the daily activity of every maintainer. Before we get more abstract, let's see some simple practices I follow here:

Documenting the commit

I make it a point to link specific commits to the issue that motivated them. So for issue #2047473 "text shows incredibly small", I committed a fix whose comment says:

Remove non-portable CSS #2047473

Drupal cleverly links the issue number to the issue page above. However, there's no mention of this commit on the issue page. That's why I add a comment - to the issue, this time - typically saying

Committed a fix on some branch.

and I link this sentence to the actual git commit page. It would be great if Drupal.org included an automatic list of referencing commits on the issue page, just like Trac (and I'm sure other SCM sites) does.

Documenting the fix

When marking an issue as fixed, I make sure to explain how the issue was fixed, to set the expectation of the reporter and other interested users. They can then test the fix more easily, and the probability of getting useful feedback is higher.

For example:

I basically removed the padding declaration for the input elements.

In the case of responding to feature requests, I include in the fix comment a short description of the new functionality and UI that were introduced, and describe a short recipe to test them. Often, when dealing with 3rd party modules, it's not clear where in the Drupal UI the functionality is made accessible. That's what I am trying to avoid here with the description / recipe - I am sure that screenshots would also be useful.

I've also seen maintainers attach their own committed patches to the issue - I find this clarifying to quickly assess the fix (from the perspective of an interested user). Maybe allowing the Drupal git server to embed the commit (like GitHub does) would solve this more cleanly.

  • Designing the module page
  • Making releases
  • Working with co-maintainers
  • Integrating with Drupal and other modules
  • Submitting patches to other modules
  • Designing module UI
  • Handling rising complexity
  • Providing professional services around your modules
  • ... and whatever else may come!
Author: 
Original Post: 

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web