Timely Pull Request Responses
I contributed some pull requests this year to several projects including the classic Jenkins Chuck Norris Plugin. Some of them were accepted quickly, others had a bit of back and forth and a few sat for months. My pull request for the Chuck Norris Plugin attempted to fix an issue where the large Chuck images no longer showed up because Jenkins had changed its’ layout design. It took diving back into some Java and brushing up on Jelly templates to figure out what was going on with the bug. After some testing I submitted a pull request and hoped to be able to integrate the fix soon after.
That was December of 2014. The fix was finally merged in November of 2015. I don’t have any negative feelings about it. People get busy. It’s open source.
At some point people get bored with projects, move on, don’t have time, or they don’t work in the language anymore. I think there’s two reasonable ways to handle this:
- Hand off maintainer duties. It’s the best option if you have someone interested in taking over the project.
- Post your explanation for not updating the project on the README to let them know pull requests and issues probably won’t get any attention. Then someone who cares enough can fork it or at least it’s use will slowly dwindle down.
In the Chuck Norris case they got a new maintainer, and my little fix is finally merged in and released.