One of the nicest things about working with open source projects is when you – as a project maintainer – receive a pull request (or a patch) for source code on which you’ve been working.
Just like it feels, say, to get the first comment on your blog, getting your first pull request is exciting because it means that someone took the time to look at the project, perhaps browse the issues, and then contribute code to help improve your work.
But over time, you may end up getting a number of pull requests, some of which – although always appreciated – may detract from the initial vision and mission of the project.
At this point, it’s up to you to determine how to best handle these requests.
Open Source Project Management: Pull Requests
As mentioned, getting your first pull request is exciting because it’s nice to be able to have others collaborating with you on something that you’ve likely already been working on for sometime.
But there are a number of factors to consider before merging a pull request:
- Is the code up to the conventions that your project has been using?
- Does the commit resolve an outstanding issue?
- Is the commit from someone who has been contributing to discussion, or have they recently just appeared?
Of course, there are more to consider than what’s above, but these are some of the more common questions that I’ve experience when working on the WordPress Plugin Boilerplate.
On Coding Conventions
I’ve talked at length about this in other posts on this blog, so I won’t belabor the point, but coding conventions (or coding standards) are very important to have when working on a project because:
- They define a set of rules by which all code should be written.
- It makes it easier to read and maintain code over time.
- It helps to make to code look as if it was written by a single developer rather than multiple developers.
In the context of open source development, this is important because as nice as it is to have others contribute to your project, they also have the ability to commit code that may not be help up to the standard that you’ve defined or that you’ve been using throughout your project.
And as soon as you accept a request that doesn’t abide by the defined conventions, it becomes a slippery slope of maintaining the codebase moving forward.
To that end, it’s important to make sure that pull requests are code reviewed to make sure the code is up to par, and – if not – then it’s rejected and resubmitted until it is up to par.
It may require a little bit more work on the front end of the submission; however, it pays dividends once it’s merged into the project.
Resolving Outstanding Issues (Or Not?)
When a pull request is submitted, it’s important to look and see if the pull request is related to an outstanding issue, or not.
If it is, then it’s important to check to see if it aims to resolve the issue. If so, that’s great because, y’know, it’s making progress on the project; however, if it doesn’t resolve the issue, the request may need to be rejected because I may potentially be the result of yet another issue.
If, however, a request is submitting that has nothing to do with one of the issues, it’s not that the effort shouldn’t be appreciated, but it should be questioned. After all, what’s the purpose of a pull request on a new project if it’s not to resolve an outstanding issue?
Sure, it could be introducing a new feature or something that would be useful and/or appreciated, and I’m not necessarily saying that it should be completely rejected, but it should be questioned: If you’re receiving contributions to your project that may ultimately result in something that will cause other issues rather than resolve outstanding issues, and I think that outstanding issues should often take precedent over introducing new features (unless otherwise scoped, of course).
Who’s Making The Request?
I think that it’s important to pay attention to who is making a pull request.
Often times, pull requests will be issued by someone who has been involved in discussion via the issue tracker (or however you end up discussing issues), or someone who has at least been lurking in the forums, issue tracker, or perhaps even blog comments.
If you get a pull request from someone who is familiar on some level, it’s likely that they are pretty plugged into the project; however, if you receive a request from someone that you don’t recognize, it’s important to pay attention to the code that’s going into the commit.
It could be completely viable, solid code and could be someone who has just been observing the project and finally had the chance to issue a request; however, it could be from someone that has been surfing open source projects on, say, GitHub, and is issuing a request just to try to submit a patch.
I’m not saying that the latter case is a bad thing, but it’s something of which to be suspect. After all, someone that’s committing code to your project should often times be someone who has been plugged into the project from sometime.
Besides, all of the issues, pull requests, and patches that go into a project are meant to end up contributing to a milestone, and – ultimately – a release of the project.
And that’s what will be covered in the next, and final post in this series.