Co-worker and F# MVP Jamie Dixon sets the bar pretty high, professionally. He’s been encouraging people to contribute to open source projects. I agree, in concept! There are many benefits to this, including:
- Further establish your professional brand, outside of your employer
- More professional experience, and experience with collaborating with other professionals
- Experience with contributing to open source, instead of always just consuming it!
- Shows future or potential employers your code quality and initiative
- Etc, etc…
Anyhow, I happened to run across a small MonoGame framework. It was very similar to the one I started to write a couple of years ago, so I reached out to the owner and asked if he would be interested in me offering some ideas and doing a pull request. He said he’d consider any changes I submitted.
But wait, how do you contribute to an open source project with someone you never met. How do they ensure code quality, how do they accept or reject your contribution?
Well, I wasn’t sure. I’d worked on a few projects (open and close source) where I was a “member”, but never as an outside, stranger contributor. So, learning how to do this is yet another positive reason to do it!
The overall process:
This was a relatively tough thing to put together, so hopefully I can simplify this from many sources. You can start here, with GitHub’s summary of the process. This is how I understand it:
In GitHub, this should be somewhat obvious how to start – there is a “fork” button in the top-right of on every project:
then the rest of the git stuff should be straight-forward in terms of making a clone, pushing your changes, etc. The two things that might be confusing are getting the latest changes, and the confusingly-named “pull request”.
Getting the latest changes from the source project:
In the event that the source project changes, you don’t refresh the content in your clone, via your fork. instead, you pull the latest changes into your local clone where you are doing your changes. You can follow the instructions from here:
I did exactly this, and it worked perfectly. So now, you have an easy way to keep pulling in the latest changes from the source project, directly to your clone on your hard drive. Your fork will be out of sync until you “push” your changes up to your fork. Then, your fork will have the latest source project changes AND your changes.
Submitting a “pull request”:
A “pull request” is a request to the original project owner to “pull in your changes”. That’s great, but How do they do it?
Sorry, I watch WAY too much of this show and How It’s Made, I find myself using their catch-phrases in real-life.
OK, assuming you have all of your code now pushed back to your forked repository, you go into the GitHub website. In the top-left of your repository, there is this green button in the top-left:
Click that, and you should see a screen similar to this:
This gives you a snapshot of all of your changes. When you click “Create pull request”, it brings up an editor and let’s you write a letter to the project owner, summarizing your changes. Click submit and that will bundle up these changes and notify the source project owner. They can then review the changes, and then choose to accept or reject the changeset.
Again, this is my first time doing this, but this seems like the correct way to do it. If you see anything incorrect here, please let me know. Otherwise, hopefully I’ve helped de-mystify the process so that you can now go out in the world and start contributing to some open source projects!