This blog post originally appeared on the PyTorch blog on Medium, and is written by Viacheslav Kovalevskyi.
Let’s start with “why?” Why might you want/need to embark on the fascinating journey to becoming a PyTorch Contributor? Here are several main reasons that might appeal to you:
If any of these reasons apply to you, keep reading.
A quick disclaimer: as you already know, there are PyTorch Maintainers, which is effectively the next step after being a contributor. We are not talking about them, and we are talking about just contributors.
Let me start with the elephant in the room: no, you do not have to have experience in programming to start contributing; however, yes, amount of issues that you will be able to address without programming is diminishingly small. Here is an absolute minimum of rep-required knowledge you need to have:
However, most likely, you also will need the following skills:
It is actually simple. On the PyTorch repository, inside the issue tracker, there is a “Bootcamp” label ( link to the exact query ) as well as “Good first issue” (query).
If you are interested in learning why the label “Bootcamp” is named this way, it has an inner meaning within Meta. Historically, when someone would join Meta, she/he could spend some time joining different teams. In each unit, the person would pick from a pool of tasks to get a team taste. These tasks are usually solvable by a junior team member, who has almost zero context, within one week of full-time work. This process is called Bootcamp; therefore, tasks well-suited for Bootcampers are marked with the label Bootcamp. As you can imagine, for the PyTorch team, any such task is fantastic for any new contributor (in or outside of Meta).
This highly depends on the issues. However, there are several generic suggestions. One that goes way beyond this article is the recommended environment setup for the development. We will definitely cover this in-depth in a separate article. For now, just use whatever you the most familiar with.
Another suggestion is this: work only on top of viable/strict branch and never on top of the master (unless you actually have to). Master might have some of the tests red, while viable/strict should always have all the tests green (keyword: should). This will drastically help you during the PR review step (wink-wink).
Your PR will be auto-assigned to the team or specific folks, for example:
However:
Plus, you will often need help way before PR is created. Depending on the urgency of such cases, suggestions would be to follow this order:
But what to do if no one responds to you? Or maybe you have asked a question, but it’s been two days, and no one responded to you still. Fear not. You can still find who is the right point of contact for the part of the PyTorch that you are touching. The persons of interest page is the central place with each module’s vital point of contact (POC). BTW, from time to time, you will find this page a little bit outdated. Therefore I would always suggest looking at the latest version directly on GitHub.
Interestingly, this path for finding answers does not work from time to time. I will show you a magic place, a back door, so to speak, where you can find more people who might be able to review your PR. These places, in the long run, should be fully in sync with the persons of interest page, but as of today, they are not and might include some additional POCs:
Last but not least, if you still can not find someone or no one is responding, please ping me directly on Twitter. One of our organization’s primary responsibility is to ensure that such things would NOT be happening. Sometime later, I can tell you more about how we are trying to achieve this, but in another post.
So your PR is ready for review, and you have added people as reviewers. The first thing is to check that all the tests are passing (before requesting a review).
By the way, if you have not followed my advice about building on top of viable/strict and found that some of the tests are red, you might want to rebase your changes on top of viable/strict and rerun them (and also start following my advice).
IMPORTANT: For your PR to be merged, you have to get approval from all the maintainers of the modules you have touched in the PR. These people are defined here. If you miss one or any amount of approvals, you will fail to land it.
You got the approval from the right folks from merge_rules. Now you. are ready to merge. This is the simplest part; you just need to ask the PyTorch bot to merge it:
You can see thumbs up from the bot that has acknowledged your request. It will take some time since the bot will rebase your changes on the latest version of the viable/strict and run all the tests again, but if all goes well, changes will be merged in 2–3 hours. Remember that your PR will be closed, and the merge will appear separately, unline the classical GitHub way where PR is merged directly. The reason for this is again out of the scope of the article. Next time maybe;)
You made it. Welcome to the elite club of the PyTorch Contributors. Feel free to me on twitter about it;)