Karl Williamson

tl;dr

Choose a bug that has a reproducing case from the list of open issues. Get the Perl source from GitHub, and put the reproducing case into a test file that we have designed for the purpose, and submit a pull request to GitHub for it. That's it.

The test is marked as expected to fail. Having this test in place helps us in several ways. One is that sometimes having to write a test is the straw that leads a developer to think it's just too much trouble to tackle this. Another is that, not all that infrequently, a change made for some other reason fixes one of these bugs, and we don't know it. But having this test would cause us to get notified that the bug is now fixed. It might even be that your work would show that the bug is already fixed.

We're happy to add you to the list of people who have contributed over the years to Perl's development, or to have you remain anonymous if you prefer.

If you've ever thought about contributing to open source, this is a great way to get started, without requiring much effort. Then you can see if doing this suits you.

Even if not, this is a way to easily improve your programming skills. The open bugs are generally things that aren't in the mainstream, so you get to see edge cases, the like of which you may never have thought about.

Details

The Perl interpreter has about 2200 open issues. That number is dauntingly large, and I believe leads people to avoid tackling them, "What's the use!".

I recently skimmed over the list, and started to look closer at ones I thought I might know something about or have the background knowledge to be able to address. I created my own, much smaller, list of ones to eventually look at. That means I don't have to do anything more right away, just when I have the time and inclination to look at some of them.

I haven't looked in detail at most of the ones I tagged, but even so, this little exercise led to the closing of about 1% of all the open issues. I'm familiar with some portions of the Perl implementation, but have never touched much of it. The number of already-fixed bugs has got to be quite a bit larger than the 1% I quickly found.

This file in Perl's GitHub repository has been designed specifically to contain these kinds of tests. It has detailed instructions at the top about how to add a test to it.

Some of the open issues contain code that would be trivial to add to that file. Others would be more challenging. Still others don't lend themselves to doing this at all (say the ones that wish Perl had some feature or another). Choose whatever you are comfortable with.

perlhack tells you how to work with GitHub and submit your change.

perlhacktips and perlgit go into more detail.

If you run into problems, you can ask on this irc channel

And read any comments below that may be added to clarify things