I remember the first pull request I did on an open source project, and it was because I "knew" right away how to fix the issue. The code was well documented, the README was welcoming in a sense that there wasn't a mystery into what the project was doing and there were defined tests.
I was a newb to GitHub, never forked anything, didn't know even how to PR. Spent more time looking up how to do all of that. What was merge, squash etc...
First Timers Only
There is a great site called https://www.firsttimersonly.com/ if you are looking for a project that has simple issues to fix or never contributed before.
http://up-for-grabs.net - another great site that aggregates all types of projects from various languages that tag their issues with help wanted, jump in, and/or up-for-grabs.
Sometimes documentation is a great way to contribute to a project. https://docs.microsoft.com/ has a TON of their projects on there and all of the docs are open source and accepts pull requests. ASP.NET and even Azure docs are there for updating.
What keeps you from contributing?
- First timer?
- My code stinks?
- Where do I start?
Post a comment here or @spboyer
Top comments (7)
I contributed to a Wordpress plugin recently that broke on my client's website. Since there was no active fix, and my client needed his website online pronto, I applied a patch and submitted a PR. Not sure if it was actually committed to the master branch though š
Basically if I find a solution and it's not too opinionated/sloppy, I submit a PR. Or if I'm so frustrated with a project, like their documentation, I'll submit a PR to make my life (and everyone else's) easier.
What stops me from contributing?
Complex APIs/app structures that require me to do significant research and tinkering to get comfortable with before I'm capable of finally contributing. Repo's like the React or Laravel frameworks are like this, I feel like I'm not contributing until I finish drinking the koolaid.
When there are no approachable "easy" tickets/features
When most other features I'm interested in are being worked on already by core contributors in a way I don't agree with.
There are never any design tickets. If repo's needed restyling with CSS, or new iconography, or UX help -- I feel it'd be more approachable than a complex hook or method that requires integration testing.
I get that. If you feel overwhelmed in the muck of the "style"; it can be daunting to get it done. Sometimes I'll just create an issue or comment on an existing one.
I'm an official contributor to the core React repo, as evidenced here.
But my contribution was literally updating a conference calendar which was hardcoded on the React website and had become out of date. I Googled around for relevant React conferences and changed a markdown file. The website is no longer even part of that repo if I'm not mistaken.
It was hardly a technical contribution to any great extent, but in making the PR I got to learn how the React pull request process works and got some experience in making an actual PR to an actual big open source project.
I recall having a fairly low-level PR I wanted to make to Ruby on Rails. This one was most-certainly technical. But I got a bit lazy once it came to trying to understand the process of making a PR and ultimately lost interest. I bet that had I already had the experience of submitting to that project, I would have ultimately gotten around to submitting to Rails.
I see little things like this happen all the time. Especially when new and/or popular projects are open sourced. Spelling mistakes, grammar checks, etc. and you see the Tweets -> "I'm a contributor to X!".
It's not a small thing, it does in fact help. Every PR that is merged or even not merged in fact helps a project.
Issues too! Discussions etc.
and blog posts, articles, and tutorials about it!
Most of the times, the scenario is:
I said "most of the times" because there is a repository that I have contributed to, that I contribute because I have the same vision with the project.
My most recent PR was to a project I was using which displayed PHP warnings under certain circumstances. It wasn't because the input was unexpected, it was because the code was handling it incorrectly. It wasn't a visible error most of the time. I could have raised an issue, but instead I just went ahead and fixed the two lines I felt were at fault and gave a brief explanation of what I'd done in the PR comment.
This took about 15 minutes and didn't inconvenience me in any way. It was such a minor issue compared to others that if I'd ticketed it it would probably never get read. As it happens, it's not been read as a PR either, but there's only so much you can do, right?
My most recent non-PR was something I fixed locally with a patch to a contrib module for something, but I selfishly didn't want to give my solution back to the community because I don't want to encourage people to use that software. I know that other people are perfectly capable of making up their own minds about whether to use something, but I also don't want to be part of promoting what I see is a problematic platform. So while the idea crossed my mind and it wouldn't have taken long, I didn't get involved.