What to do when the maintainer has gone away?

By lsolesen on 23 jun 2012

Tags

drupal
planet drupal

Drupal is an awesome open source system, and the community around Drupal is great. There is a lot of very useful contrib modules. I have supplied several issues and some small patches to several projects, and most maintainers swiftly responds.

Other projects the maintainers are very busy, and that is quite understandable. However, for me to keep being interested in trying to help to improve some module, it is important that one is able to see some headway in a project. You actually want to see some of your improvements and bug fixes committed - which makes it easier to move on to the next improvement without your patches going stale.

Consider these examples:

  • parser_ical. I filed a bug and provided a patch in January. I tried contacting the maintainers to get the patch included, but received no response. The module still stands as unsupported in the D7-version. I would like to help change that, but when the maintainers does not reply, it is difficult.
  • media_gallery. We are a couple of people who has been trying to do a lot of the dirty work in the issue queue for media gallery. We have been closing issues, fixing small bugs, providing patches, trying to find a way to make it work with the 2.x-branch of media. But still there has been no response from any of the current maintainers. I tried through the issue tracker, IRC and through the contact form on d.o. 

Both projects are really good and created by skilled people. And off course skilled people get busy, and do not have the time for exactly that project right now.

But how can the community solve this? It is very likely that people will just cease to provide bugfixes and help maintain an issue queue, if they can see no progress from their work.

Kommentarer

By John Barclay on 24 jun 2012 at about 08:48.

sometimes the trick is to move the patches farther along, so when the maintainer is busy they can more readily apply the patches.

- include simpltests with patches

- include test cases/examples

 

Another common problem is alot of patches in the queue that have not been reviewed and tested by the community.  If everytime someone committed a patch to a particular module, they reviewed and tested 2 other patches, this would help move the patches forward.   Since one already has the -dev version of a module available when the patch is written, its a good time to review other's patches.

By juliangb on 27 jun 2012 at about 14:15.

Everyone feels this way at some time - the problem is that your current sticking point is likely to be because you want to use this module NOW, but the maintainer may not have a pressing deadline etc. (quite simply, different people have different schedules).

I'd agree that the best way is to progress the patch to RTBC.

As a maintainer of a couple of modules, my spare time ebbs and flows, but when I have time, I always start by looking for RTBC patches to commit, then I review issues marked Needs Review, then Needs Work, before going for new work. I also prioritise bug reports over other tasks or features.

By lsolesen on 30 jun 2012 at about 02:44.

@John Barclay and juliangb. I agree that people need to help getting patches into RTBC and that people have different schedules. However, for people to go digging through code and keeping their motivation to create patches, it is important to get feedback from the maintainers. Waiting months without response on your issues is probably to long to keep people engaged with your module. You will spend time on a module, because you need it. Waiting without response would probably make you look somewhere else - leaving the whole community worse off?

I have asked to co-maintain media_gallery to get something committed, and luckily the maintainers responded quickly to that issue :)

Tilføj kommentar