How and why to Become a Contributor to PyTorch: Community & Partner Talks at PyTorch Conference 2022
Hi, my name is Zane Rizvi. I’m a tech lead on the PyTorch developer infrastructure team. Our goal is to build tools that make it as easy as possible for PyTorch contributors across the entire open source community to contribute to PyTorch. So, why contribute? Since you’re listening to this talk, chances are you’re either a user of PyTorch, you integrate PyTorch into your existing systems, or you build a product that your customers use with PyTorch. Could you go back on slide please? If you’re a PyTorch user, you might be wishing that your tool is better in some way. Maybe you’re running into pain points, or you’re wishing that PyTorch scale better to your workflows. You might have an idea to how to optimize transformers even better. You have the power to change your tool to make it better suits your needs. And by doing so, not only will you be scratching your own itch, you’re going to be improving the state of the art for the AI industry. If your customers use PyTorch, you can evolve PyTorch to optimize it for your product. Companies like Nvidia, AMD, Microsoft, Intel, they all regularly make contributions to the PyTorch code base to make it more performant on their platforms, and by doing so, they give their customers a much better experience. So, you have an idea. Let’s get some feedback on it. The early feedback process is designed to make it as easy as possible for you to quickly find out how well your idea lines up with PyTorch’s vision. And it need be to help you tweak your ideas a bit to make them something that the PyTorch community will be excited to adopt. Now, we want this process to be as easy as possible for you. And sometimes, that means just jumping straight into a pull requests. This is the case for smaller changes like bug fixes or documentation improvements. For anything that’s a simpler feature, perhaps, you can file an issue and GitHub. Those are good for you just share the change that you want to make, mention the benefits that you’re expecting to get, and share that you’re willing to implement the idea yourself. We’ll get back to you really fast on that. And for the more involved proposals, you can submit a request for comments. This is good for things that are more detailed, and it will allow the PyTorch members to give your ideas the more thoughtful and detailed feedback that they deserve. All right. You’ve had your idea. You read our contributing to MD Guide to figure out how to build and test PyTorch locally. You start developing. Awesome. And then you get stuck. We have a whole bunch of ways for you to get unlocked. We have a couple forums. There’s Discuss.pyTorch.org, which is for PyTorch users, but you can use it to also figure out our better understand our APIs. And then we have Dev Discuss, which is a special forum for PyTorch contributors like yourselves. If you encounter bugs, you can file an issue and GitHub. And also do that if you find instructions are confusing or vague. If you have an idea for how to better improve your workflow to make it easier to contribute, you can also file a GitHub issue for that, or you could bring it to our office hours. The Dev Experience Office Hours is an open-ended forum where you can talk about anything related to your developer experience. You can talk about roadblocks that you’re running into, a request that you might have. And if you’ve ever been curious about how a particular piece of infrastructure works over here, you can even come and ask us about that. We’re always excited to help explain it. Now, you’ve gotten yourself unblocked. You’ve built out the feature, and you’ve tested it, and you’re ready to get it merged. Now, the fast way to make that happen is to submit a PR and assign it to the right reviewer. But how do you know where the right reviewer even is? If you’ve gone through the approval process earlier, the feedback process, then you can assign it to the person who gave you some feedback. Or you can check out the list of maintainers. And find one that owns the area that’s responsible, that’s affected by your changes. And if none of those options help out, it’s okay. No big deal. Just leave the reviewer section on the PR blank, mark your PR as being ready for review, and within a couple of business days, our PyTorch Tri-S Quad, our PR Tri-S Quad, will take a look at your PR and assign it to the right person. It takes a little bit longer that way, but we’ll make sure your PR gets attention. Now, once you’ve gotten more ramped up on the PyTorch code base, we’ve got a couple more perks that you can make your lives even easier with. We have a Slack workspace that you can join us on. It’s useful to have even faster collaboration with the core PyTorch maintainers, the people who are more invested in the PyTorch community. You can even become a maintainer yourself. We’re always looking out for strong contributors who have expertise in a given area who can take ownership of it. Anyone anywhere in the world is eligible to become a PyTorch maintainer. And finally, the Dev Experience office hours are open to everyone from beginners to novices. Everyone is welcome. Now, let’s talk about some of the tools that we’ve built. There’s the HUD, which is a site, which gives you a lot of information about the PyTorch repositories and the commits that have been made. And one of the big use cases that you might find it helpful for is those times when you have a test that’s failing on your PR. And it doesn’t quite seem like it’s related to your changes. You can hop onto HUD, take a peek to see if this failure is seen if it’s a symptom of some more widespread outage. Or you might discover that you should take a closer look at your code. Then there’s Docker CI, which is a GitHub bot, which provides a comment at the top of your PR. And it lets you just find out what the current status of the CI is. That’s the lower screenshot over there. You can see how many tests are still pending. And if anything has already failed, you can get a link to quickly dive into their end debug it. Then there’s Merge bot. Another GitHub bot, which lets us apply custom rules during merges and reverts. This useful for things like fine grained permissions checks are making sure that we run extra tests just before we merge your change into GitHub. Then there’s also Flaky test bot, which is exactly what it sounds like. It automatically detects and disables tests that are Flaky. Now, this is a lot of stuff to remember. If you want one link to remember all of this information, let it be this one. You can remember that, right? Or you can search for PyTorch contribution guide. It’s going to be the first link on the results. And this will give you everything that you need to get ramped up as a PyTorch contributor. Now, if you have any questions, feel free to reach out to the PyTorch team at any of the resources that I’ve ever mentioned earlier. Or you can reach out to me personally on Twitter, at Zainar Zivi, and I’ll be happy to help you out. Thank you very much, and have a great day.