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:
- you want to build a portfolio in OSS
- you wish to enter an AI world but have no experience
- you want to learn PyTorch more
- you simply just want to help the amazing-best-in-the-world-OSS-DL-framework
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.
Any Pre-Requirements?
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:
- you know git
- you have some knowledge on how to use GitHub and do Pull request
However, most likely, you also will need the following skills:
- build C++ code
- some C++ coding experience
- some Python coding experience
- Docker
How To Find Issue To Work On?
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).
Work On It
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).
How To Ask For Help?
Your PR will be auto-assigned to the team or specific folks, for example:
However:
- a person assigned to the PR might not always be the right one to review it (after all, our automation is just automation)
- a person might not be available for review at the moment
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:
- read official contributors wiki page
- ask a question directly on the issue on the GitHub
- ask a question on the dev discussion forum
- ask a question on the slack
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:
- the bug that maps modules to GitHub accounts/teams
- CODEOWNERS file
- merge_rules — list of folks per module who have permission to approve your changes to be merged
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.
Prepare the PR and Ask for a Review
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.
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;)
Profit!
You made it. Welcome to the elite club of the PyTorch Contributors. Feel free to me on twitter about it;)