1. Intro / Preface
● Augustina Ragwitz
– Perl Developer since 2007
– First YAPC in 2012 (Madison)
● Currently at MediaMath in NYC
(we're hiring)
● auggy@cpan.org
irc.perl.org: auggy
freenode irc: mmmpork
twitter: @mmmpork

2. Why Am I Giving This Talk?
● I just made my first contributions
● Share what I've learned
● Encourage y'all to contribute!

3. Perl Wants You!

4. Open Source Software is Free!
● But there is a cost...

5. Open Source Software is like
Public Radio
● Ok, more like Public Access TV...

6. Pay your dues!
Contribute!
● Or just do it cuz it's fun

7. Start Small
● GOAL: Get familiar with the patching
process first!
● Small code patches
● Documentation
● Unit Tests

8. Remember...
● Working in a new code base requires
context!
● Don't be intimidated!

9. Talk to the Community!
● A lot of communication happens on IRC
● If you're not familiar with IRC →
● Server is irc.perl.org
● Check documentation for irc channel info
● Or ask in #perl-help or #p5p

10. Where can I contribute to Perl?
● Any module on CPAN is fair game –
http://www.metacpan.org
● Perl core is managed through P5P (Perl 5
Porters)

11. Perl Core (Perl 5 Porters)
● http://dev.perl.org
● p5p mailing list
– perl5-porters-subscribe@perl.org
● irc channel: #p5p on irc.perl.org

12. Get your name in it!
● Pumpkings – a rotating group of individuals
responsible for cobbling together changes
nd releasing new Perl versions
● Patches go into new versions of Perl
● Submit a patch and get immortalized!
– Your name goes into the release doc

13. Wow that sounds cool!
Sooo, now what?
● Look for things that are easy to contribute!
● Easy = small fixes for learning the patching
process

14. Easy Contributions
● Perl Core != C programming
● Documentation
● Patch supporting scripts
● Improve unit test coverage
● Some bugs are tagged in RT
https://rt.perl.org/rt3/Public/Bug/Display.html?id=116469
● Check the todo list:
http://perl5.git.perl.org/perl.git/blob/HEAD:/Porting/todo.pod

15. How to contribute to Perl Core
● Pretty well documented here -
– http://perldoc.perl.org/perlhack.html
● Perlbug + tips
– http://perldoc.perl.org/perlbug.html
● And here's a short walkthrough

16. CPAN
● The Comprehensive Perl Archive Network
● AKA the place where modules live
● Basically, an index that maps a module
name to a file archive location
● http://www.metacpan.org - provides
additional metadata not found in cpan.org

17. PAUSE
● Perl Authors Upload Server
● Where the file archives live (that CPAN
points to)
● Anyone can get an account
– Only really need one to upload an archive
● http://pause.perl.org

18. CPAN Testers
● Goal: Test CPAN modules with as many
versions and configurations of Perl as
possible on as many platforms as possible
● http://www.cpantesters.org
● http://stats.cpantesters.org

19. What should I contribute to CPAN?
● File a bug
● Improve documentation on a module you
struggled to use
– Especially if you got help from the author!
● If you had to make local changes to make it
work, submit the patch!

20. Alright, that sounds good!
How do I get started?

21. Disclaimer
● All processes demonstrated here are my
preference
– TIMTOWTDI FTW!
● Module maintainers will have their own
preferences.
● Check with the maintainer before following
these steps to submit a patch.

22. Submit a Patch to CPAN
● You need the following:
– The location of the source code repository
– Where the author wants patches submitted

23. Find the Repo
● Some modules on Metacpan have
repository info
● Check Module documentation
● Git::CPAN::Patch
● Download the source tarball (last resort)

24. Where to Submit the Patch
● GitHub, BitBucket, SourceForge... if the
author has specified the bugtracker
● Otherwise, use RT

25. RT
● http://rt.cpan.org
● Send email to bug-acme-
auggy@rt.cpan.org
● Use RT if:
– The author says to, or
– You can't find any bugtracker info in the
module
● You can attach your patch to the RT!

26. GitHub
● http://github.com
● Pull request is probably sufficient for
submitting your patch
● Optional: Create an RT ticket

27. How do I write a patch that's likely
to get merged?
● Don't submit a large complex patch
● Each issue should be its own commit
● Each commit should have a clear commit
message
● Be consistent, stick to the author's style
● Update documentation when appropriate
● Write tests to support your changes
● Include a changelog entry

28. OK so how do I submit my patch!?
● Download the source code
● Make your changes
● Submit the code

29. What happens when I submit a
patch?
● If the author accepts your change, they
merge it into their repository and release
the code!
● If your change is rejected, the author will
comment on the pull request or the RT
ticket
– Don't give up!!
– Talk it out with the author
– Use the feedback to fix your patch

30. How do I know my patch was
submitted?
● RT responds with an email
– If you don't get an email, wait a couple of
days and resubmit
● GitHub shows your pull request
– If you don't hear anything, submit an RT
ticket

31. What if the author doesn't respond,
at all?
● Send email to modules@perl.org
– Use this resource after several attempts to
contact the author
– State a log of your attempts to contact the
author
– If the author is unresponsive, you could
end up being the maintainer
● Fork!
– This is Open Source after all...

32. Collaboration is fun!
● Fun to work on interesting things!
● Get others excited about your ideas... or
get excited about someone else's!
● Good feeling to help out others
● Learn new things about programming!
● Even people who aren't using Perl at work
contribute because it's FUN!

33. Q&A