Clear questions and runnable code
get the best and fastest answer
How I came to contribute to Perl 6by kyle (Abbot)
|on Jul 14, 2009 at 17:50 UTC||Need Help??|
This is the story of how I came to be a Perl 6 contributor—not a major contributor, but a contributor nonetheless. My message of hope to monks the world over is this: You too can contribute to Perl 6! You may think yourself insufficiently awesome, but I disagree. You too can contribute to Perl 6! Let me tell you how I did it so as to make your own path clear.
The Perl 6 project has several parts you may have heard of.
Before I go on, I should mention that I decided early on that I would help with testing. In Getting Involved with Perl 6 - 2009, moritz suggests that this is a good way to get involved. You may consider my story here a demonstration of that assertion.
Step 1: Get a commit bit
I showed up on the #perl6 of irc.freenode.org one day and asked for a commit bit for the Pugs repository. Within 15 minutes TimToady had asked me for my email address and preferred svn nick. I got an email to finish the process, and that was it. The traditional first commit is to add one's name to the AUTHORS file to confirm access, which I did.
Step 2: Look for something to do.
This is actually easy.
The go-to place for ideas is spec/TODO. In it you'll find:
There is a lot to do! Not only that, there are things to do that require very little expertise. The first thing I did was convert some old style deprecated testing code into its more accepted analog. This was a very mechanical search and replace style of operation.
Step 3: Join mailing lists
The next thing I did was join the perl6-language and perl6-compiler lists. From one of those I started receiving bug reports that were going into the RT queue.
Low hanging fruit!
I had a look through the perl6 queue in RT at Perl.org. I've always thought that every bug one finds should have a test that shows its presence or absence. With this in mind, I set about testing the bugs in the queue.
This is easy because code is provided. Whoever wrote the bug included code and their expectations for it. It's straight forward to convert that code to tests. The hardest part, usually, is to figure out where to put the test. Whenever I have time, I can go browsing for a bug, see if I can find a test for it, and write one if there isn't one. (If there is a test, I note that in the ticket before moving on.)
Step 4: Settling in
A lot of the "action" is on the IRC channel. There are robots there for sending a message to someone who's not present. There's a robot there that will pass Perl 6 code to different implementations and report the results. Most importantly, there are people who know more than I do about the topic at hand.
The people on IRC are very monk-like in their patience and helpfulness. In particular, moritz has offered me testing wisdom on many occasions. I've learned things like:
My only word of warning is that when the spec is not clear on some subject, the members of the IRC channel are not always more clear. More than once I have asked questions and found the (many) answers even more perplexing. A question along the lines of "what should this code do" can lead to a design discussion and dizziness.
Step 5: ?
Step 6: Profit!
It's been almost a month since I got that commit bit in "Step 1". I've learned a lot about Perl 6 and semi-related topics in that time, and I've been able to add a little bit to the effort to bring the next Perl into the world. You can too!