Always Be Closing...Pull Requests
I was looking at a Well Known Open Source Project on GitHub today. It had like 978 Pull Requests. A "PR" means "hey here's some code I did for your project, you can PULL it from here and merge it into your code!"
But these were Open Pull Requests. Pending. Limbo Pull Requests. Dating back to 2015.
Why do Pull Requests stay open?
Why do projects keep Pull Requests open? What's a reasonable amount of time? Here's a few thoughts.
- PR as Call to Action
- PRs are a shout. They are HERE IS SOME CODE and they create work for the maintainer. They are needy things and require review and merging, but even worse, sometimes manual merging. Plus for folks new to Git and Open Source, asking them to "rebase on top of latest" may be enough for them to just give up.
- Fear of Closing
- If you close a PR without merging it, it's a rejection. It's a statement that this work isn't going to be used, and there's always a chance that the person who did the work will feel pretty bad about it.
- Abandoned
- Sometimes the originator of the PR disappears. The PR is effectively abandoned. These should be closed after a time.
- Opened so long they can't be merged
- The problem with PRs that are open for long is that they become impossible to merge. The cost of understanding whether they are still relevant plus resolving the merge conflicts might be higher than the value of the PR itself.
- Incorrectly created
- A PR originator may intent to change a single word (misspelling) but their PR changes CRs to LFs or Tabs to Spaces, it's a hassle.
- Formatting
- It's generally considered poor form to send a PR out of the blue where one just ran a linter or formatter. If the project wanted that done they'd ask for it.
- Totally not aligned with Roadmap
- If a PR shows up without context or communication, it may not be aligned with the direction of the project.
- Surprise PR
- Unfortunately some PRs show up out of the blue with major changes, file moves, or no context. If a PR wasn't asked for, or if a PR wasn't requested, or borne of an Issue, you'll likely have trouble pushing it through.
Thanks to Jon and Immo for their thoughts on this (likely incomplete) list. Jess Frazelle has a great post on "The Art of Closing" that I just found, and it includes a glorious gif from Glengarry Glen Ross where Always Be Closing comes from (warning, clip has dated and offensive language).
Jess suggests a few ways to Always Be Closing.
Two things that can help make your open source project successful AND stay tidy!
- including a CONTRIBUTING.md
- GitHub has some good guidance https://help.github.com/articles/setting-up-your-project-for-healthy-contributions/ and most of the dotnet repos have some decent contribution guidelines.
- I LOVE Gina Häußge's Contributing.md on her open source project "OctoPrint."
- using Pull Request templates that give clear guidance on how to submit a successful pull request.
- Use bots to test and build PRs, sign CLAs (Contributor License Agreements) and move the ball forward.
What do you think? Why do PRs stay open?
Sponsor: Get home early, eat supper on time and coach your kids in soccer. Moving workloads to Azure just got easy with Azure NetApp Files. Sign up to Preview Azure NetApp Files!
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
We are unlikely to use an open source library with no commit activity for the last 12 months. That's one of our first checks before reviewing the suitability of it to our needs.
OSS Projects where everyone can merge any change, end up in a huge ball of mud.
@Tom: Well the point of open source is that it's open and if a package isn't maintained, you can take the source and do the changes or fix your bug and create a fork of it.
Undisputed bugs should be great candidates to be fixed by the community, but the contributor needs to properly understand the bug and how to fix it. For example, "doing x causes a warning" should not normally be fixed by reducing the level of error reporting.
Comments are closed.
From my perspective, if there is any point in using centralized platforms like GitHub instead of decentralized solutions, it's because GitHub might be able to solve this trust and governance issues.
In the same way I don't want to give away code to a project without OS licence, I don't want to give code to a project that's going to be dead soon because maintainer insists on reviewing everything personally, lacking time to do so. It's just market economics.