What to do with the code from my rejected pull request?

Question

I just recently sent off a pull request to a small but well-known open source project. This pull request added a new feature, as well as unit tests (and improvements to the existing tests). However, the author is not accepting pull requests for this project...but that wasn't made clear until after I had already put in the work.

Now I have this extra code laying around, and it would be a shame to let it go to waste. What can I do with it? And how can I avoid this situation in the future?

Answer 1

On GitHub (and probably other services as well), the standard practice is to include a CONTRIBUTING file in the root directory of the project, with information that contributors needs. GitHub even gives potential contributors easy access to the contents of this file when creating issues or pull requests. Prior to undertaking an effort with the intent of contributing, the right thing to do would be to read the CONTRIBUTING file or reach out to the project owners. This will help you determine what you need to do to have them accept your contribution.

If, based on what you learn, the contributor will accept pull requests, then great. You can make your changes and submit a pull request. As long as you follow the guidelines, it should be accepted. But what happens when the project isn't accepting pull requests? Or, for some reason your pull request isn't accepted? You still have options.

First, you could create a patch file. Git supports this. You can somehow distribute the patch file. Perhaps create an issue on the project and attach the patch. If it's extremely popular, than maybe the creator will reconsider. It may be closed, though, but if you provide enough details, people searching for the same thing may find your issue and the patch and be able to apply it themselves.

Something to note about a patch - I'd recommend keeping it small. For example, you mentioned that you had improved existing tests. In a patch, I'd focus on the changes to implement your feature and the new or modified tests to confirm the functionality of your feature.

If this isn't good enough, you can consider forking the project. You can point back to the original project in your README. You don't necessary need to keep it in sync with the original project, but it may be beneficial. It would allow you (and perhaps others, if the author is accepting no pull requests) to be able to submit changes. Even if you don't keep your project up-to-date with changes in the original project, your contribution may help someone out there.

Again, if you did fork, you could add an issue as an enhancement request to the original project, pointing to your project. It may let the owners of the other project see if your enhancement is popular and reconsider pulling it in or may help people who find the main project and the issue and get something that will help them out.

Answer 2

To avoid this situation in future, ask the software maintainers whether they would be interested in accepting code to add your feature before you spend time writing the code.

Depending on the way the project is run they may want to have a feature request documented on an issue tracking system, forum or mailing list before they make a decision.