I recently made my first contribution to an established Python package (link). When I shared this milestone with friends I realized that many of them are interested in doing something similar but don’t know how. I decided to write down the steps I took in case it helps others.

Step 1: Identify Packages You Want To Contribute To

Contributing to an open source project can have a lot of ups and downs. Knowing that my effort had the potential to contribute to a package I personally use helped me push through the frustrating parts. I think that this is likely to be true for others as well.

Last June I gave a talk about my first Python project at the San Francisco Python meetup (link). That project uses the censusdis package to get data from the US Census API. During development I needed to ask the author of censusdis (Darren Vengroff) several questions. Darren was always very helpful, so when I started thinking about contributing to an open source package, censusdis was a natural place to start.

If you are interested in contributing to an open source package then I recommend creating a list of packages you use regularly or which sound interesting to you. Find the repositories for those packages on github and bookmark them.

Step 2: Select a Package That Welcomes Community Contributions

Not all open source packages are under active development or welcome contributions from the community. This is not necessarily bad – I consider my own R packages (which I describe as being in “maintenance mode”) to be in this category! But it does mean that you want to avoid putting a lot of effort into a Pull Request (PR) only to have it be ignored.

In my case, because I had already been in contact with Darren, I simply asked him if he was interested in having me contribute to censusdis. He said he was. I then asked what he thought the best way for me to get started was. He recommended that I learn the basics of Poetry, which censusdis uses to convert its functions into a proper package.

You might not be able to have a conversation like this with the maintainers of the packages on your list. But here are some questions you can ask when you look at their repos:

1. Activity: When was the last commit? When was the last release? If the repository has not had any activity in several months, then it seems unlikely that a new contributor will get much guidance, or that a PR from a newcomer will get much attention.
2. DEVELOPER.md: The censusdis repo has a DEVELOPER.md file that begins with “censusdis welcomes contributions from the community”. Do any of the repos on your list have a file like that?
3. “Good first issue”: The issues page on the censusdis repo tags some issues with “good first issue”. That is, Darren invested time to highlight issues that newcomers are most likely to succeed at closing. Do any of the repos in your list do something similar?

Step 3: Learn About Python Package Development

This is where most of my time was spent, and was a major reason why I undertook this project: I wanted to understand how writing standalone Python scripts and apps is different than writing a package that is on PyPI.

I mentioned earlier that Darren recommended I start by learning about Poetry. Unfortunately, I found Poetry to be a bit confusing to figure out on my own. What helped me most was this course on RealPython.com. I recommend that course to anyone who wants a crash course on Poetry.

I also decided to take Matt Harrison’s six-week Professional Python course before tackling my first issue in censusdis. That course walks students through the process of creating a Python package from scratch using modern constructs like pytest, type annotations and continuous integration using github actions. I had just met Matt at PyBay and enjoyed the talk he gave. Taking the course wound up being a great decision. Virtually all the information in it helped me with censusdis.

Step 4: Build And Test The Package Locally

After taking RealPython’s Poetry course and Matt Harrison’s Professional Python course I cloned the censusdis repo locally and verified that I could both build and make small changes to it. This wound up being the shortest and easiest of all the steps.

Step 5: Pick An Issue To Work On

Many of my friends expressed concern about what, exactly, they would contribute to an existing package. Some assumed that all contributions have to be a major new feature that they thought of themselves. That’s a very high bar, and would prevent most people from ever getting started! Some were concerned about asking for help in a public forum, which would leave a “permanent record” of them appearing like a beginner.

In my case I browsed the list of issues in the repo and focused on the ones that were tagged “good first issue”. My initial concern was that all the open issues might require in-depth knowledge of how the Census API or censusdis package works. Imagine my relief when I realized that a lot of issues were simply mundane software engineering tasks! In particular, the issues I helped close were:

• #282 Clear up pandas deprecation warnings
• #298 Security issue with fiona
• #300 Support Python 3.13

I can’t guarantee that your favorite Python package has a similar set of Issues. But based on my experience, I think that it’s at least worth checking.

Conclusion

Contributing to my first open source Python package was a rewarding project and I recommend it to anyone who enjoys programming in Python. Contributing to a project I personally use brought a sense of pride and changed the way I view the package. It helped me grow technically and required me to learn how Package development in Python differs from writing scripts and standalone apps. Hopefully publishing the steps I took enables others to take a similar journey.

While comments are disabled on my blog, I welcome hearing from readers. Use this form to contact me with feedback.