How to contribute to an open source project on GitHub

http://blog.davidecoppola.com/2016/11/howto-contribute-to-open-source-project-on-github/

by vivaladav • 10 years ago

433 92 10 years ago

blog.davidecoppola.com

dibanez• 10 years ago

I've been doing this without thinking about it for a while and after reading it from a beginner's perspective It seems like quite a few steps. It is the "right" thing to do though, as far as I know.

dorianm• 10 years ago

Or in a lot of cases you can use github's edit button ;)

besselheim• 10 years ago

Agreed, it's much easier for quick bugfixes on code that you otherwise don't want to invest your time into.

Whackbat• 10 years ago

For anyone that is new to contributing to projects using git for version control I strongly recommend giving this tutorial a read: https://www.atlassian.com/git/tutorials/syncing

Additionally, the best way to learn git is to use it so try all the examples.

atemerev2• 10 years ago

Step 1: stumble upon a terrible bug (or that really obvious missing feature that _should_ be there) in your favorite library / framework / app.

Step 2: rant about it on HN / Github issues / whatever.

Step 3 (optional): try to reach developers on GitHub and get the obligatory "pull requests are welcome" response.

Step 4: In frustration, clone the repository, fix the damn bug and submit your pull request.

Steps 5..41: have an angry and emotional discussion with the devs who refuse to accept your PR because broken binary compatibility / regression tests / coding style / your choice of variable names etc. Fix all these issues and resubmit the PR until it's accepted.

Step 42: And this is how you become a contributor to high-profile projects like Docker, Akka, Spark etc, and now free to boast about it in your CV!

gosubpl• 10 years ago

https://xkcd.com/386/

Disclaimer: I am an akka and akka-http community contributor. I don't know how this works for other projects.

But I don't think the process is as painful as you describe in the akka world. My experiences are quite to the contrary. The community here is warm and welcoming. But, please look at this from the other side. Would you use the software in your mission critical application if the project was accepting quickly contributions from random strangers on the internets?

Please, find an issue marked as community in https://github.com/akka/akka/issues or https://github.com/akka/akka-http/issues and give it a go. How to solve the "credentialize yourself" problem? Be known to the commiters by first working on a docs issue.

atemerev2• 10 years ago

I am half-joking, of course; when I have submitted my first (minor) PR to Akka, I thought "wow, that is probably the most complicated code I ever had to follow through!" So I expected that I could get many things wrong, and will have to correct them first. So I did.

Akka community is excellent.

logn• 10 years ago

Step 4: In frustration...

Step 4 requires no frustration. It should be a relief you can fix it yourself rather than hope for some opaque engineering team to maybe fix it at some future date since your company doesn't have the Platinum Support package.

Steps 5..41: ...

I think maintainers of small projects should do their best to merge whatever is given to them without back and forth or delay--just a prompt and sincere thanks. There's no reason to treat contributors like junior devs you're trying to teach and guide. Sometimes that requires swallowing some pride in having the code be just right or means you may want to fix up a few things after the merge.

tananaev• 10 years ago

As a maintainer of small project I would say that it depends. If the code is really useful and contributor is not willing to fix any of my comments, I would merge it anyway and fix it myself. If the code is so bad that it would be easier for me to completely re-write it myself, I would reject it.

I'd like to think that my code review comments are reasonable most of the time, so it doesn't usually take more than 2 or 3 iterations to complete a pull request.

angry-hacker• 10 years ago

Yes.

I remember when my first ever request was accepted. The fev thanked and with next release I saw he changed few things in my code, small things. Nevertheless it made me more comfortable submitting pull requests and really happy at the time.

cloudjacker• 10 years ago

And this is how you become a contributor to high-profile projects like Docker, Akka, Spark etc, and now free to boast about it in your CV!

And get the same pay as everyone else that doesn't play any of these reindeer games, because recruiters already know how to find us and setup the interviews!

agibsonccc• 10 years ago

To be fair here: It's on both parties to be mature about this interaction.

It is the responsibility of the developers of the project to be responsive though.

I would just like to add that many open source projects you are looking at are funded

by companies with salaried developers (all of the ones you listed are).

These companies have customers that come first.

Their has to be due diligence on what goes in to the code base.

If you are ready to submit a pull request to a project and the developers are receptive

to teaching then view it as a learning experience.

Try to understand both sides though.

cyphar2• 10 years ago

Steps 5..41: have an angry and emotional discussion with the devs who refuse to accept your PR because broken binary compatibility / regression tests / coding style / your choice of variable names etc. Fix all these issues and resubmit the PR until it's accepted.

As a maintainer, I can completely see where you're coming from here and some of nits that I have against PRs probably seem quite trivial. However, if you have a fairly large project then as a maintainer the onus is on us to make sure that things don't break (and that the project remains manageable). Not to mention that the argument people use (that we should just make a follow-up commit that fixes the PR so it's actually acceptable) doesn't _really_ work if you're someone who has to do bisects often -- I'm not going to merge code that is clearly wrong in several places (unless the code is returning a "not implemented" error).

It's not a pride thing, as maintainers we have much less time than the contributors (there are fewer of us than there are of you) so we can't carry every PR that someone drops on our issue tracker.

Of course, for runC we have automated testing that verifies that things like golint and gofmt succeed (so we don't have to waste time going back-and-forth with contributors about it). Lots of smaller projects don't do this, which leads to nothing but annoyances for contributors.

Also, in general when reviewing a change I try to state whether or not the idea is sound. If I am commenting on your choice of variables or how you've structured your algorithm, that means that I like the idea (and is an implicit "I will merge this once you fix <these set of nits>"). Not all maintainers do this, but most learn to do this quite quickly.

brobinson3• 10 years ago

I dislike the idea of using 'origin' for my own remote name.

I keep 'origin' as the canonical remote and my local master branch tracks origin/master. I use people's usernames for their remotes (including for my own).

If I'm pushing a feature branch to my own remote:

    git push -u myusername mybranchname

If I need to checkout someone's PR, it's:

    git remote add theirusername git@github.com:theirusername/repo.git
    git fetch theirusername
    git checkout -t theirusername/repo

I've seen people at work who are new to git/Github struggle a lot with the 'origin'/'upstream' differentiation recently, especially when they're learning branching, and they don't seem to have any problems once I switch them over to using 'origin' + usernames.

dom0• 10 years ago

If I'm pushing a feature branch to my own remote:

I grew so tired of that that I just wrote a little wrapper script, that just does the right thing (tm). So it's

    $ shit push

for me.

cynicaldevil2• 10 years ago

Same here. Except I use 'myfork' as the name for my remote repo. Origin/upstream always got me confused when I first started learning Git, so I created my own naming conventions.

brobinson3• 10 years ago

Too late to edit, but that should be:

    git checkout -t theirusername/theirbranchname

rcfox• 10 years ago

FYI: GitHub will create a branch in your repo for pull requests. You shouldn't need to pull directly from someone else's repo just to look at their pull request.

http://stackoverflow.com/a/30584951

brobinson3• 10 years ago

Didn't know you could pull by ID! Thanks!

majelix• 10 years ago

Of these, 1: Chose the project you want to contribute to (and 1.5: Choose the issue to work on) and 9: Follow up are the hard ones. Both are primarily social problems.

For 1, it's mostly about knowing yourself. What projects interest you, and where can you contribute?

For 9, it's convincing the owners that your contribution is a net positive. Start with 2: Check out how to contribute, and proactively reach out so your pull request doesn't come out of the blue.

Oh, and be willing to put your ego aside -- it can be tough to defend your work, particularly if you're a new (and thus haven't built up trust) contributor. It gets easier, both as the project learns to trust you and as you learn the work within their practices.

boulos• 10 years ago

So actually, I was thinking about #1 the other day as well. When you go to GitHub.com, they now have /explore and /showcases. But, even if you find something interesting (say https://github.com/showcases/open-journalism), it isn't clear that any of those projects are suitable for contribution. Not everyone uses a CONTRIBUTING.md, but even more so, I think many of the showcased projects on GitHub fall into the "Free to make a copy of" not open to contribution.

So I keep coming back to what has been said elsewhere: the best way seems to be to find a bug in something you use, realize it's open source and go from there. That's unfortunately not a great way to mobilize the masses of people that could contribute, but don't have a particular project in mind (think GSoC).

aban• 10 years ago

If you'd like to avoid switching to the browser in your development workflow, I recommend checking out Git-Repo [0] that was posted to HN a little while ago [1].

Git-Repo basically tries to put as many steps of the contribution workflow in terminal as possible, by using the API of the git hosting services. It currently supports GitHub, GitLab, and Bitbucket.

[0] https://github.com/guyzmo/git-repo

[1] https://news.ycombinator.com/item?id=12677870

i9182u79ikjnsk• 10 years ago

Shudder. This embodies all that is wrong with open source development these days.

Horrible GitHub workflow: corporate logos, octop^Hcat, CoC shoved in your face on every commit.

I'm currently forced to contribute to a GitHub project, it is the most annoying, bureaucratic and brainwashing workflow I've ever experienced.

delan• 10 years ago

corporate logos, octop^Hcat

Only two logos appear in the entire pull request process, and those are the two small silhouettes that you see on every page.

CoC shoved in your face on every commit

Codes of conduct? While they are becoming fairly prevalent, the GitHub interface has no special understanding of them.

csl• 10 years ago

There is one very important tip that's missing: Follow the original coding style exactly.

Not just spaces vs tabs or block styles, but idioms and other idiosyncrasies, too. Why? Imagine reading a source repo where every second block uses different bracket styles, mixing spaces with tabs and so on. It's going to look like a kludgy mess, and will be distracting to read.

There is no correct style for most languages (perhaps `go fmt` might be an exception), only opinions.

hzoo4• 10 years ago

Right! And a lot of projects have a linter in place that runs in continuous integration (travis, etc) that you can see in the PR or just locally.

In Babel we use ESLint for this https://github.com/babel/babel/blob/master/Makefile#L20-L27

danso• 10 years ago

I agree, and it's one of the reasons why novice-to-intermediate programmers should try to pitch in to a project, even for something very minor. I remember making a pull request to a Ruby project and getting rejected and being told to fix all the rubocop errors, which made me aware of the existence of tools for auto-style-detection/linting, and of best practices in style that greatly improved my programming experience.

That kind of practical thing is not well-covered in tutorials and self-learning curriculums.

sctblol• 10 years ago

flake8 for Python is nice, although defaults can be a bit weird...

tedmiston• 10 years ago

Code Climate or Codacy are nice too. They collect tools like flake8 and run a server side report kind of like coverage.

the84727• 10 years ago

Follow the original coding style exactly.

Personally I would take any formatting and just run an auto-formatter over the code section when I work on it the next time in case it bothers me.

Correct and sane code are far more important than hassling someone else to conform to a particular style.

In my opinion applying styles is a task for machines, not humans.

Arnt• 10 years ago

It's more than that.

I've had a patch rejected because my unit tests used the wrong verification manner (java assertTrue() instead of assertThat() in cases where the latter would report better error messages were the test to fail, as I recall). Automatic blah will never catch this kind of thing.

Ditto for human-readable messages that have/lack full stops at the end.

Ditto for if() foo vs if() { foo } and the ever-lovely style question, are abbreviations such as TCP to be called TCP or Tcp in camelcased identifiers?

Style is largely a human matter.

BurningFrog• 10 years ago

Well, you can't do that when reading code on github.com, for example.

Even if I have the code checked out, I don't want to clutter my diff with hundreds of reformatted lines just to read it.

It sounds like formatting isn't important for your code comprehension. That's nice for you, but for many of us, that's just not how our brains work.

exhilaration• 10 years ago

Is there a breakdown of top projects by language? I'm a C# developer and would love to put my skills to work on an open source project, but how do I find one?

hzoo4• 10 years ago

Not the best way to find an open source project to contribute to but you can check trending per language https://github.com/trending/csharp or the top starred repos that are C# https://github.com/search?l=C%23&q=language%3AC%23&ref=advse....

I'd be much easier to find a project you use or know about so you have a lot more context into the project, it's usage, documentation, etc.

tintoy• 10 years ago

Up-for-grabs lets you filter by language:

http://up-for-grabs.net/#/tags/C%23

mholt• 10 years ago

I just want to emphasize that if reviewers ask you to make changes to your pull request, it is not a rejection or lack of appreciation. As the maintainer of an open source project, I greatly value contributors who will iterate and iterate until the change is accepted, and often, I will give them push rights ("collaborator" status) to pay it forward.

And if a change is rejected, it's usually because there was not enough discussion beforehand about how to solve the problem, the change itself did not undergo enough discussion/iterations, or the change is not really a solution to a problem. (It's not the maintainers saying "Go away and never come back" -- more like, "Thank you for your effort! Please approach this differently.")

awkward_yeti• 10 years ago

what if I want to start my contribution I just don't know which project to choose ? this assumes that I already know the project I want to contribute to.

cynicaldevil2• 10 years ago

Usually people begin by contributing to projects which they already use. For a beginner, it might be better to start contributing to a project which is mainly written in the language which they're familiar with. Also, try to find a project which is beginner friendly; they usually have some issues marked as 'beginner' or 'good first bug', and also have a CONTRIBUTING.md page.

Bonus: A good idea is to start contributing to a project which contain problems sets to be solved by coding the solutions in a particular language. You could send PRs for creating/implementing some problems. http://exercism.io/ is a good example.

cheiVia02• 10 years ago

For almost any project there is an infinite amount of work to do. Check out OpenHatch for opportunities, or just dive in for things you rely on. Big communities are great too, checkout Linux or one of the distros:

https://openhatch.org/ https://kernelnewbies.org/ https://www.debian.org/intro/help

TAForObvReasons• 10 years ago

The way people (usually) contribute to an open source project on GitHub is using pull requests.

I disagree with this premise. The way people usually contribute to an open source project on GitHub is creating an issue or adding to a discussion. IMHO this is more valuable than actually writing code because it helps other developers gauge the relative demand for a feature/bugfix and sometimes you find out that other people have already solved the problem in their own forks.

ThomPete• 10 years ago

But what about designers?

grzm2• 10 years ago

Projects need design as well. Websites, logos, manuals/documentation: there are plenty of opportunities for designers as well.

Mz7• 10 years ago

https://news.ycombinator.com/item?id=12881822

If you could elaborate a bit on how to get involved in the non-programming piece for us non-programmers, like designers and copywriters, the world will be a slightly better place.

Thanks.

cheiVia02• 10 years ago

Debian needs some help from artists:

https://wiki.debian.org/DebianArt/RequestArtwork

smegel• 10 years ago

7. Work on your contribution

8. Write tests!

OhSoHumble• 10 years ago

Hopefully some of the project mantainers will check your pull request and will give you feedback or notify you they decided to merge your changes soon.

Ah, my experience is that I'll submit a PR and it'll just be ignored until the end of time.

evantahler• 10 years ago

Ya'll can contribute to www.actionherojs.com whenever you want!

hzoo4• 10 years ago

This is a great start!

Contributing can be a lot more than just PRs though: - answering questions on stack overflow, chat (irc, gitter, slack)

- creating a minimal code repro, checking for duplicates, checking if a bug is fixed in a later release/master branch

- writing tutorials/usage scenarios, giving talks, just using the project and providing feedback

- helping with documentation + website

- translations if possible

- reviewing other PRs

- helping with the changelog, testing prereleases

- adding to the discussion on issues

Bigger projects can have a pretty hard time with maintenance: fixing bugs, juggling PRs, making releases, answering questions, etc.

(We're looking for help on https://github.com/babel/babel and trying to figure out how we can make the project more contributor friendly!)

Mz7• 10 years ago

helping with documentation + website

I am not a programmer. I do copywriting for pay and I have run a bunch of different personal websites over the years (15+ years, I think). I know a little HTML and CSS.

I am interested in getting involved in open source via first working on copywriting and website stuff, since that is what I already have a background in. I am finding it extremely opaque to figure out how on earth to do that.

I left a couple of related comments on HN recently:

https://news.ycombinator.com/item?id=12860294

https://news.ycombinator.com/item?id=12851361

I do have a github account and I recently went through the Hello World on how to do pull requests.

Any tips on how to begin interacting with open source projects on the copywriting and website development piece of things?

Thanks.

the84727• 10 years ago

That depends largely on what you want to edit. Websites might be static pages, generated from some simpler markup language or hosted on a form of CMS. Documentation is often generated from source code comments to some extent.

If you can't easily figure out where it is stored and how it is generated you should probably ask along with your inquiry whether the maintainers would be interested in contributions in that area.

hzoo4• 10 years ago

I think it depends on the project like mentioned.

For react, the docs for the website is in the same repo as the main code under "docs/" https://github.com/facebook/react/tree/master/docs.

A lot of projects do what we do with babel: have a separate repo with the whole username.github.io name: https://github.com/babel/babel.github.io.

And a lot of projects started adding links to edit the page you are currently on: http://babeljs.io/docs/learn-es2015/ (see the "edit this page" link on the header. For yarn it's on the bottom: https://yarnpkg.com/en/docs/. That at least makes it easy to edit a specific page for typos etc. Then you can just edit it from the website

ufmace• 10 years ago

I'd say broadly that the right first step is to communicate with the maintainers somehow. Figuring out how is part of it. Check for activity - how many PRs, open and closed, does the project have? How often do they come in, and how quickly do they get commented on or merged by project maintainers? Are they linked to Issues on GitHub or some other system, and what's the activity level on those? Maybe they have a mailing list, Google Groups, IRC, Slack, or something else. Find it, see if it looks active, maybe send out a quick hello and see if anybody responds, and have a chat with them about what you'd like to do, if they're open to that, and how they would like for you to proceed. If they use GitHub issues or some other open issue tracker, you could open an issue for poor documentation or whatever, with an offer to fix it, and see if anybody responds.

Sounds complex, but you should only spend like 10-20 minutes on this. If you can't find clear signs of activity in that amount of time, there's a good chance that the project is abandoned or only accepts contributions from a private group. It may take a couple of days or so to get a response to messages on less active projects, that's okay. If you can't see any activity or get any response from maintainers in a reasonable timeframe, then don't bother. If your contributions are wanted and have a good chance of being accepted into the project, then somebody should be willing to write a few sentences to you specifically telling you so, and outlining how to contribute or where to find a current contribution guide.

fphilipe• 10 years ago

I can highly recommend hub [1], which does steps 3, 4, and 5 in one command:

    hub fork username/repo

1: https://github.com/github/hub

cthulhuology• 10 years ago

For many projects, Github is just a place to publish yet another public repo. Using github issues and pull requests is a sure fire way to feel ignored. If you want to contribute, e-mail the lead maintainer. Do not submit patches to the ether. Do not think anyone will look at your patches. Having started several large open source projects, and started / worked for a number of open source companies, I can tell you the best way to get involved is to work on your personal relationship with the other developers. If that means hanging out in IRC or Slack, that's what it takes. Github is a terrible form of communication, especially when your org / developers have 100+ repos.

kjksf• 10 years ago

That doesn't sound like a sound advice.

If the author of the repo can't be bothered to look at the issue or a PR then I don't see how they'll be receptive to emails.

Most projects don't have other ways of contacting the people involved (very few list their e-mail addresses and even less have dedicated irc or slack channels).

Yes, it happens way too often that issues and PRs are ignored but realistically it's a strong signal to stop investing more time into such projects because it's unlikely things will improve.

carussell• 10 years ago

If the author of the repo can't be bothered to look at the issue or a PR then I don't see how they'll be receptive to emails.

There's an assumption here that GitHub is automatically more convenient and desirable than an email or other project management tools. That's not a universal sentiment; not everyone wants to participate in the GitHub social network, and even tools themselves that GitHub offers are a step down depending on who you ask (like the pull request mechanism and issues and what they try to pass off as a "wiki" and...)

So just because a project and its maintainers don't have a big showing on GitHub, don't assume that means anything about the health of the project. It may just mean they have better places and ways to spend their time and get things done.

Most projects don't have other ways of contacting the people involved

Why do you think the email field that shows up in git's log was put in place? Honest question.

mugsie• 10 years ago

e-mail the lead maintainer.

Check that there is not a mailing list first. This is where the "read the contributing guide" kicks in.

I for example have quite a lot of filters, that make sure I reply to mailing lists, but if you email me directly, you may end up lumped in with all the commercial "include my $thing in your project please" emails (purely by accident)

roblabla2• 10 years ago

While it's true you might want to email the author and all, having a PR is great for one thing: letting other people looking for the bug/feature find the fix before it's upstreamed.

This is what I usually do with my PRs. I first submit the PR so it's there for other people to grab if they need it, and then I'll look into the "proper" way of upstreaming the fix.

This avoids duplication of work and enhances discoverability.

chmike• 10 years ago

There are a few steps missing. Before the push, we need to pull on master and rebase the branch on top of master. See triangular workflow in this page [https://github.com/blog/2042-git-2-5-including-multiple-work...]

tbarbugli• 10 years ago

I would add "Make sure the maintainer of the repo will merge (or even look at) your PRs". I more than once had very reasonable PRs (bugfixes) waiting to be merged forever.

CharlesMerriam2• 10 years ago

Wow! When you want to fix a typo, it can be as little as two hours!

cyphar2• 10 years ago

To be honest, typo fixes are fairly draining as a maintainer in large projects. Especially if it's a small (one-line) fix.

Yeah, I get that you want to contribute and that's awesome (one of the best things about free software is that everyone can contribute). But the relative benefit of the actual change versus the time-to-check-the-PR and time-to-reach-consensus-with-another-maintainer is quite low in most "typo fix" PRs.

If you're going to make a typo fix PR, please at least run a spell checker on the file that you're doing the typo fix on (and even better run it on the whole repo). Because at least then, your PR has a higher benefit ratio.

That being said, if you still make a typo fix PR I will merge it eventually. Just be aware that I sigh out loud each time I get a notification for typo fix PR, and I will almost certainly put other things higher on my priority list.

infodroid• 10 years ago

There is a lot of overlap with Github's own guide to Contributing to Open Source [1] and Forking Projects [2]:

[1] https://guides.github.com/activities/contributing-to-open-so... [2] https://guides.github.com/activities/forking/

jhchen• 10 years ago

This guide is heavy on the mechanical side and misses a lot of important substantive parts, if your goal is to add value to an open source project.

Don't just create a fork, branch, and submit a PR without context. First, make sure the intent of your change is actually desired. Just because someone opened an Issue does not mean that it belongs in the project. Anyone in the world can open a Github Issue for any reason. Instead engage and discuss the Issue first and make sure it's actually something the project wants.

Don't just start writing code. Familiarize yourself with the codebase. This comes naturally if you are a user of the project, as you will naturally run into bugs or learn the software's behaviors and as you discuss the Issue or features with maintainers. There are far fewer right ways to build a feature than possible ways.

Finally, understand that your contribution is not "free" for the project. It takes time and consideration to even look at your PR and even more to code review it. The more popular the project, the more true this is.

notyourwork2• 10 years ago

To sum all that in a nutshell: Collaborate.

delish• 10 years ago

I'm curious to see what others think about your comment, notyourwork. To me (maybe only me!) it looks like you're putting a pithy stamp on what the GP said. Going a little farther, it looks to me like you're taking credit for what the GP said. I do not see the value of saying, "To sum all that in a nutshell: Collaborate." I see a value in what the GP said.

That said, this is the first time I've criticized this kind of comment. I've seen people pithily-sum-up others a lot. If others disagree with me, I'll take that into account.

no_protocol• 10 years ago

Don't just create a fork, branch, and submit a PR without context. First, make sure the intent of your change is actually desired.

I think all that matters is that the change is something you want. If no one else has any need for it, you can continue using it as long as you wish to maintain your fork.

It's great to collaborate and share ideas before you start working, but if it's something you need, you'll do it even if everyone else says it's pointless.

fapjacks• 10 years ago

There is, however, value in submitting a PR without diving into the often stalemating "discussion" happening in a lot of projects. As much as I wish it weren't the case, I have found over the years that if your code follows conventions, works, and is useful, asking for forgiveness is much, much easier than asking for permission.

sdrinf• 10 years ago

| Finally, understand that your contribution is not "free" for the project. It takes time and consideration to even look at your PR and even more to code review it. The more popular the project, the more true this is.

Understand code interactions: they scale N^2 with each new feature added. Specifically, each interaction your feature has with all the other features has to be coded, and then each new feature might interact with yours. This is the curse of scope freak.

It is the sole responsibility of the PM/owner of the project to select which features worth this.

matiasz• 10 years ago

It’s amazing that there aren’t many articles like this one. I wrote something very similar [1] last year because I simply couldn’t find a complete, step-by-step guide that addressed the details of forking, branching, etc.

[1] http://www.matiasz.com/2015/04/16/contribute-open-source-rep...

joelhooks• 10 years ago

Here are some screencasts on this topic if that sort of thing interests you: https://egghead.io/courses/how-to-contribute-to-an-open-sour...

winterismute• 10 years ago

Why did this get so many upvotes? It's well written, but isn't it just a trivial guide on how to do a pull request? Not trying to be controversial, I'm just genuinely curious.

How to contribute to an open source project on GitHub

Related Stories