Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses
 
PerlMonks  

Comment on

( #3333=superdoc: print w/ replies, xml ) 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.

Background

The Perl 6 project has several parts you may have heard of.

  • The Pugs repository (http://www.pugscode.org/) is a Subversion repo containing the official Perl 6 spec, the test suite that confirms a particular implementation conforms to the spec, Pugs (one of those implementations) and other stuff.
  • Parrot (http://www.parrot.org/) is a virtual machine designed to run dynamic language (including Perl 6).
  • Rakudo (http://www.rakudo.org/) is an implementation of Perl 6 on Parrot.

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:

  • A list of changes to the spec which require corresponding changes to the spec tests.
  • A list of areas that still need tests, broken down by spec section.
  • More general tasks for the entire test suite.

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:

  • DDT is great, but we usually don't use it because not every Perl 6 is ready for it (so tests fail for unrelated reasons), and it's hard to "fudge" for different implementations of Perl 6.
  • It's better to write "ok $x ~~ undef, ..." than "is $x, undef, ..." because the latter causes a warning, and sometimes $x.defined doesn't work.
  • git-svn is goodness.

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!


In reply to How I came to contribute to Perl 6 by kyle

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • Outside of code tags, you may need to use entities for some characters:
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.
  • Log In?
    Username:
    Password:

    What's my password?
    Create A New User
    Chatterbox?
    and the web crawler heard nothing...

    How do I use this? | Other CB clients
    Other Users?
    Others romping around the Monastery: (7)
    As of 2014-12-25 20:13 GMT
    Sections?
    Information?
    Find Nodes?
    Leftovers?
      Voting Booth?

      Is guessing a good strategy for surviving in the IT business?





      Results (163 votes), past polls