Scott Hanselman

Always Be Closing...Pull Requests

September 5, '18 Comments [10] Posted in Open Source
Sponsored By

Always be closingI 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!

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.

facebook twitter subscribe
About   Newsletter
Sponsored By
Hosting By
Dedicated Windows Server Hosting by SherWeb
Thursday, 06 September 2018 11:13:46 UTC
Governance of Open Source software is a little bit broken here: you can help by sending the code, but not by reviewing the code as there is a trust issue between maintainers and contributors. Maintainers are often overworked and hence either looking for monetization, or neglecting the project.

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.
Thursday, 06 September 2018 18:56:46 UTC
Anyone have a study or statistics on the lifespan of open source projects and how many move from high development activity to near-dead with a few years?

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.
Tom
Friday, 07 September 2018 14:14:13 UTC
@Lucas: OS License and Reviews my maintainers are in no way related to each other. First tells you how others can use the code where a maintainer just makes sure that PRs of a certain quality and standards get merged.

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.
Desy
Saturday, 08 September 2018 10:01:40 UTC
These mostly apply to code contributions. But I often contribute to Microsoft Docs, in the form of typo fixes, technical corrections, etc. Some repos respond very fast. But there are others, like MicrosoftDocs/Virtualization-Documentation, which seem to be dead.
Fleet Command
Tuesday, 11 September 2018 09:40:26 UTC
In the same way I don't want to give away code to a project without OS licence. 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.
Wednesday, 12 September 2018 03:30:04 UTC
There really is a disregard for this, I believe the best way is to share your contribution to other people beyond github, or even open a project similar to the contributed.
Wednesday, 12 September 2018 14:08:14 UTC
absolutely convinced with GoodzSex. It's weird to call out the name so loud though. Stack Exchange Overflow too comes to the mix with Github.
Thursday, 13 September 2018 08:20:02 UTC
Questionable fixes
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.
Saturday, 15 September 2018 02:09:05 UTC
Another barrier to a PR being accepted is when the open source project has a primary owner that has the "my way or the highway" attitude, where noone could possibly come up with a solution better than what the owner was planning on doing "someday".
Alex Shore
Sunday, 16 September 2018 05:50:24 UTC
great job and thank you for post

xiaomi
Comments are closed.

Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.