layout: post title: Gold stars for Drupal contrib modules -- and how to get one created: 1179296664 categories:

• PHP
• simpletest
• unit testing
• Drupal

So, it's probably about time I took some thoughts that have been rambling around my head for a while and even spilled out a bit in #drupal here and there, and talked about what I think about "gold stars" for Drupal contrib modules. 

Nick Lewis has written one of his usual thought provoking posts on the subject of having a "top tier" of contributed modules. I agree...in principle. But he's also wrong.

I've been an advocate for more access to all. Give that poor, downtrodden PHP programmer in the corner a CVS account. It will make them a better person, they'll learn best practices, and a glorious garden of contrib will flourish. Well...not so much, although there are some fantastic starting points out there in contrib, and a few great, solid pieces of code that perform yeoman work. 

Want a gold star? Here's how to get one:

1. Your code conforms to coding standards, right? Coder module can help you.
2. You use the new system of branches and tagged releases. You there, in the corner, speak up! Yes, OK, if you are pre-Drupal-5 and dww project module goodness, stand down: you can just run a 4.7 branch and be done with it. But tag up on Drupal 5+, and you can still get a gold star.
   
3. Tests. Lovely, lovely unit tests. Simpletest (dear gawd, the test module doesn't even have an official Drupal 5 release...). You've got tests, and they succeed. Intrigued? Like the idea of having code that you KNOW works, even after you've made changes, or someone else has submitted a patch. Learn more about the simpletest framework and module (OOP fans rejoice! The simpletest framework uses classes, so now you can have your Drupal and eat your OOP, too)
4. Insert some final hand waving about being a good maintainer. This means probably having at least one co-maintainer for all but the simplest of modules, not being a duplicate-but-slightly-different-module, plus no-I-didn't-bother-to-try-and-get-incredibly-useful-feature-into-core will also be frowned upon. Yes, this point is the fuzzy one. Got better suggestions?

What are the consequences? Maybe only a select few get gold stars. Those with stars get more stars. merlinofchaos gets a new wizard robe, the rest of us have quidditch mud thrown in our faces.

But wait. Here's a suggestion. What if, if you don't follow these steps...you don't get publicly listed. That's right, forget the gold star.

What if, when browsing the downloads section for contributed modules, it only listed modules that met these standards. You could, of course, still get to those projects, and visit their issue queues, and link to them directly. And maybe, if killes is feeling especially generous and has had a delicious newbie snack to tide him over for a while, there's a special "I know what I'm doing and I really want to see the stinky code over the corner even though it will probably eat my baby" button/flag/giant padlock that you can click to get to browse through all the modules.

But the default is, no gold star, no public listing.

Perhaps even more radical – and if you pay attention to nothing else, internalize this bit – what if, on every project you worked on, every time you touched a contributed module, you did the following:

• Run it through the Coder module, make fixes if necessary and submit a patch
• Verify that all simpletests complete without errors. No tests available? Write at least one and submit it as a patch.
• That feature that you want/need added? Write it up! And make a simpletest. And submit a patch.
• Review and comment on at least one other patch in the queue.

I think clients want tests. It reduces their maintenance costs long term. Oh? You thought you were buying a finished product? Remember, CMS is a project, not a product.

Do I need to write up the bit about having a "patches" directory, and a developer ticket which links to the patch and the drupal.org issue queue number, and that the work isn't done until the issue is closed and the code is resynced with the upstream tree? Let's take that as a given...

What would be the long term effects of individual developers and consulting shops adopting such a model? How much would the code quality improve over time? On the second project that you start, where 80% of the modules are the same as the last one, which now all have simpletests available, how much time would you save?

Some food for thought. I think it's a process I'd like to embark on. In the short term, it's going to be HARD. But in the long term, I think the mountain pygmies will thank us.