We’ve noticed unpleasant trends in our most popular open source projects:
- patches not getting merged
- bugs not getting fixed
- issues going unanswered
We believe the causes of the problems are:
- feature requests, help requests, bug reports, and patches all in the same system
- limited amount of manpower
We want to do better so we’re trying a new policy that we believe is helping.
Limit what’s in the queue
The GitHub Issues queue should contain items we can act on and close quickly.
This means feature and help requests should be submitted to the appropriate mailing list. If you’re worried about your pull request not being accepted, reach out to us on the mailing list before you start coding.
We’re trying to keep issues restricted to two kinds:
- Pull requests that we can easily merge in
- Bug reports that we can act on
We’re always going to be looking at pull requests before issues, meaning the fastest way to get your bug fixed is to submit a pull request that fixes it.
We’ve been doing this on a few projects and the results have been good.
By keeping the list restricted to items that we can act on quickly, we’ve brought Paperclip’s issues count down to 25 from hundreds and Factory Bot’s issue count has consistently been in the single digits.
Although this means that we’ll be closing some issues that might represent real bugs or valuable features, we’ve found that we can actually move more code through the queue by weeding out the issues that we can’t act on.
To recap:
- Pull requests will be addressed first.
- Bugs that we can’t reproduce or act on quickly will be closed.
- Feature and help requests will be closed with a link to the mailing list.
