What prompted this?
After reading a number of blog posts (here, here, and here) and thinking about my personal experiences with recently becoming a committer, I decided that it might benefit the Python community to see someone contribute right before their very eyes. First I had to ask myself: How would that benefit the community?
My first hope was that people would see what it takes to go from start to finish with a simple contribution. Reading about it is one thing, but seeing it in action can be even better. Another hope was that people might see a flaw or snag in the process and tell me what’s wrong and why. I was also hoping people who have contributed or attempted to contribute could talk about what worked or didn’t work during their experience.
So, with a ChiPy meeting on the horizon, I proposed a talk to cover some of what those previous posts were about, and at the same time dig into the code and make a contribution before the group, knowing that the talk would end up recorded and on the internet for all to laugh at see. As a “tl;dr” video summary: some people had contributed, most hadn’t, some wanted to work on documentation, one commented on sometimes rude responses, most clapped, but it seemed like all understood what was going on and I think everyone there left feeling capable. Even my Mom. Now for the video…
Video primer: this is just over 50 minutes long. The bug fixing part goes from approximately 07:00-26:00.
Semi-organized thoughts on beginning as a contributor to Python.
This is more for the “I have some free time and I’d like to help make Python better” crowd than the “I hate the GIL and I want to remove it now” crowd, but it might be helpful for both.
To me, really getting into a project is a mix of things. Some challenges, some learning. Some fun, some enjoyment. There are many things it takes, but I think one of the most important is success. In order to progress in a project, whether it’s your next great Django website or it’s painting your kitchen, you have to have some amount of success to keep on going. Not everyone is going to be successful in their first attempts at Python contributions, but I guess we have to define “successful”.
For the purposes of this article, I’m defining success as having your work committed to the Python source repository, to be included in a release. With that defined, I think there are a few things that can ease the introduction period, leading to more immediate success, which leads to more learning and challenges, which leads to more fun and enjoyment. If you keep going, you might even get commit access.
Start with documentation fixes. Read the Documentation Development page to get a feel for what needs to be done, and then check out the list of open documentation issues. Fixes to the documentation are the easiest to get traction on and to have success with. Since documentation fixes are usually less brain-intensive than C or Python code changes, they are easier for everyone involved to work with and quickly act on.
My first contribution to Python came in the form of a one-line documentation fix to the C-API, and the fix was committed very quickly after I submitted it. It felt good to start off 1-for-1 in terms of scoring my Python development work.
Stick to modules and packages that you use the most. If you are a big user of ConfigParser, take a look at it’s source in Lib/ConfigParser.py, then search Roundup for some of the open issues. Take a look at the tests in Lib/test/test_cfgparser.py and see if anything is missing and add it accordingly. Just searching for any open issue will turn up a lot of issues in modules you either aren’t yet interested in or haven’t used, which are harder to work with as a new contributor. Also check out the pages on the Python Developer's Guide.
One of the first standard library fixes I was successful with was adding context manager support to the zipfile.ZipFile class in 2.7/3.2. I was writing some code at work, just assumed ZipFile worked as a context manager, and then when I went to run it didn’t work. I dug into the code, saw that __enter__ and __exit__ weren’t implemented, so I added them, added tests, and shortly after that it was committed.
Read other people’s patches. As we all (hopefully) know, code reviews are a necessary step in software development. Even though contributing to Python isn’t typically done “on the clock” at our nice cushy day jobs, we still have to follow the processes like we (hopefully) do at work. For every few issues you fix, try to look at the list of issues needing review. Even if you don’t end up having any comments, you’ll get a feel for what people are doing and how they are doing it. If you do have comments, post away. The patch submitter(s) will appreciate another set of eyes on their work.
You’ll see more issues this way, and you’ll get a flavor of what types of issues bring out which people and what ends up being necessary. As you look around, you’ll see a guy named Mark Dickinson doing all kinds of math stuff. You’ll see R. David Murray working on email related bugs. As you become familiar with more types of issues, you’ll know who you can add to the nosy list, or the list of people who might be interested in the issue.
- Ask questions. We’ve all been through it, and we all know that bugs aren’t going to ask the question themselves. However, you have to know how to ask the right question in order to get the right response. I can’t really tell you the answer to that, but just make sure you’ve read the issue over, read the code and/or documentation over, and have given it your best shot. Present everything you have done, everything you know, and see if anyone can fill in the gaps.
- Know that if you are a Python user, you can be a Python contributor. Python’s development team is made up of people from all walks of life, from many countries, with many different backgrounds. I believe the majority of contributors are full-time software developers, myself included. Some are employed by various types of corporations, some are in consulting. There are also a number of college/university students and at least one contributor who is still in high school (and he’s a release manager at that, also contributing to PyPy). It takes all kinds of people to have a successful project like Python. Windows, Mac, and Linux users. C programmers, Python programmers, Sphinx documenters. Old people, young people. Tall people, short people.
I’ve found it fairly easy to get into Python development by using the above approaches. I started small and eased my way into bigger issues. Is this the “one true way” to do it? Absolutely not. Do what you want to do at the pace you want to do it, for the reasons you want to do it.
Being a baseball player, I always think back to how it only takes success 30% of the time to be a good hitter (again, with a varying definition of success). Sometimes you’ll submit a patch and strike out. Sometimes you’ll hit a home run. Overall, you’ll have fun doing it.