The Drupal.org infrastructure is a great resource for developers: A hub for development, with a combination of version control access, issue tracking, and automated testing.

Of course, it can be improved, and I don’t want to open a can of worms by saying it is perfect (it isn’t).

But I think the community does benefit from an environment that is designed especially for it.

Within this environment, we also have useful tools that help maintain quality in Drupal code.

1. The issue queues and workflow are set up to foster peer review, which (in line with the open source way) gives unlimited human eyes on a problem, rather than being siloed within a commercial organization. 
2. Contributed projects such as dreditor allow fast, tangible reviews from reading through code, giving a clear comment for others to work from. 
3. Automated tests mean that once you’ve set up code, you will automatically get the green or red light as to whether a change has unintentionally broken anything. 
4. The coder module allows automatic reporting of code style, which helps bring the community towards common coding standards and accelerates the speed at which a contributor can become familiar with a new section of code. 

But these checks do add to the hassle of contributing a patch. Not good.

Formalising the process of review

On one of my projects, the Project Management Module, I was weighing up whether I should formalise the review process.

Previously, whilst a lot of the factors mentioned were taken into account (although not coder), it was a little haphazard, and I felt it wasn’t clear enough.

I wanted a contributor to know what the hurdles they were in advance, so that they could write a patch at the outset that solved the issues.

There are typically several patches undergoing review at the same time in the issues queue, so I also wanted to be able to speed up the review process to minimise the need for patch rerolls.

My biggest concern here was that I would alienate contributors to the project. This would not be an acceptable sacrifice, even if it meant that we were upholding the coding standards more precisely, etc.

Contributors come first

You’ll have got the message by now that one of the biggest risks to an Open Source project is (in my opinion) alienating your contributors.

So, whilst I’ve gone ahead and put a bit more structure in how I review patches, my focus has been on keeping the process easy and worthwhile – with a focus on the new element, coder reviews. 

Those regulars in the Project Management Module issue queue will keep me honest in the comments, I’m sure!

Is there a point to code style?

There are massive advantages to uniform code style among a community, but it is an investment made in a patch, with a longer term reward.

I’ve done two things to make coder patch reviews less painful:

1. Show the results: I’ve set up a developers website for the Project Management Module.

   You can see it at http://api.project-management-module.org.

   The aim here is for developers now to reap the benefits of the documentation that we’re adding to the code. 

2. Lower the hurdle: I understand that not everyone has a test site running the coder module, and it adds a lot of time if you need to set that up each time.

   So I’ve opened up coder on the Project Management Module demo site.

   You can see it at http://drupal-7.project-management-module.org/admin/config/development/c....

   A check of a patch now takes a few seconds, and can be done before submitting on Drupal.org (in fact, you could use it for your patches too - it isn't module specific).

So far, I’m pleased with the results.

Nobody has complained about additional hurdle of coder reviews, and there have been some very positive comments about having an API site for all to see.

Conclusion

Alienating contributors is a real risk when formalising a process in an Open Source project, but it doesn’t mean that you shouldn’t try it.

Before implementing any change, think about how you will make the change worthwhile from the point of view of other contributors – whether by showing the point of it, reducing the pain, or both.

When have you tried to formalise a process in Open Source?

Has it worked?

What steps did you take to ensure contributors were not alienated? 

As always, I’d welcome your thoughts in the comments.

Category: WebsitesTags: DrupalDrupal PlanetMaintaining an Open Source ModuleOpen SourceCoderPatches