Or: how to improve the process of becoming a co-maintainer?
I’ve had more than a few projects where we used a contrib module and found a bug. We then searched the issue queue of that module to find out we were not the only one with that bug. And if we were lucky, there was also a patch that fixes the bug, so we could patch the module and carry on. But we need to make sure we document this patch to not override it when we update the module. As a Drupal developer you really want to use full released and unpatched modules.
It often happens that the maintainer of the module is too busy with other stuff and that an issue is left untouched for months. Or even worse, someone posted a patch and the maintainer doesn’t respond at all. Not even an “I’ll test when I have time”. Quite frustrating, if you ask me.
During the Drupal Process Days (CXO days) last week in Amsterdam we talked about this process and how to improve this. Some suggestions were discussed:
- There already is a procedure to become co-maintainer of a module, which few people are aware of. However, this process involves a lot of steps and takes al least 2 weeks time. And with >1000 open issues in the webmasters queue, probably a lot longer. One of us tried to walk that path, without luck.
- Implement an automated process where someone can become co-maintainer by pushing a button on the project page (only for those with GIT access). The maintainer can have a week to cancel the request, with an explanation on why not.
- As a maintainer, stimulate those who contribute patches to become co-maintainer. Some maintainers don’t want co-maintainers; whether it’s the loss of control or credits, I don’t know. But I think it’s a missed opportunity; getting someone on board doesn’t only help you fix this one bug, but he/she might help you to answer other issues as well. Take this example in one of my modules, where madmatter23 contributed a patch. I’ve asked him to jump in as co-maintainer and he did. After this bug, he solved several more issues and is still maintaining the module. Cool!
What are your ideas? How can we improve this process? Please let me know in the comments.
edit: changed the title from 'lazy maintainers' to 'slow maintainers'