Skip to main content

Can you send 24 pull requests this December?

·519 words·3 mins·
CPAN GitHub
Table of Contents
❀️ It's great to see you here! I'm currently available on evenings and weekends for consulting and freelance work. Let's chat about how I can help you achieve your goals.

For many of us, the holiday season is approaching. The Advent calendars will be kicking off soon, which is great. If you're into blogging, I'm sure there are some calendars which may still be looking for articles. However, if you're looking to push some code, let me point out 24pullrequests.com The idea is that you send one pull request per day for 24 days.

There are two ways for you to contribute. You can sign up and start pushing code or you can suggest a project for others to create pull requests for. http://24pullrequests.com/projects/new Hey, you can probably do both. There's no commitment once you start. It's just a fun leaderboard to let you track your progress in the 24 days leading up to Christmas.

Now, 24 is a lot of pull requests, but keep in mind, they don't have to be just code. Documentation patches are easy to write, easy to merge and they often don't require a deep dive into the code. A lot of times when I'm browsing some CPAN docs and I come across a typo or some other little issue, I just fork the project on Github, edit the files directly with the Github editor and then send a pull request when I'm done. I can usually do this in parallel with reading the docs. So, even if I don't end up using the module directly in my project, I can just send a pull request with a couple of quick fixes and be done with it. Often the code gets merged immediately. I sent one to MIYAGAWA a few weeks ago that was merged within about 3 minutes.

So, while you can certainly send as many code patches as you like, keep in mind that doc patches are easy and they're of benefit to everyone after you who will be reading the same code.

While I'm on the topic of pull requests, if you're providing a non-trivial patch or just something that should be documented, be sure to included it in the Changes file for the repo and credit yourself appropriately. This makes it that much easier for the maintainer to merge your code and cut a new release immediately. It's the little things in life that can slow as down. The more obstacles you remove for the maintainer, the faster you're likely to see you code get deployed.

Comments
#

Author: Neil Bowers

Date: 11/25/2014 08:22:28 AM

Excellent idea!

I’ve added a stencil quest to questhub.

Now if there was only an API we could use to build a list of all the CPAN distributions that have a github repo …


Author: Olaf Alders

Date: 11/25/2014 01:33:23 PM

:) This script gets you most of the way there. Just s/twitter/github/. https://github.com/CPAN-API/metacpan-examples/blob/master/scripts/endpoints/author/1c-scroll-all-authors-with-twitter-es.pl


Author: Olaf Alders

Date: 11/25/2014 01:34:54 PM

Ah, you wanted distributions, not authors. Oops!


Author: GΓ‘bor SzabΓ³ - גאבור Χ‘Χ‘Χ•

Date: 11/25/2014 04:07:01 PM

a large subset (just set the size= to the appropriate number.)


Author: Neil Bowers

Date: 11/25/2014 09:53:44 PM

Here’s a script which generates table of the 2000 most recently released CPAN distros that have a github repo


Related

Kickstarting the Gitpan
·293 words·2 mins
CPAN GitHub GitPan metacpan perl
This Week in MetaCPAN
·826 words·4 mins
CPAN GitHub metacpan perl
How to Run a Single Test via Dist::Zilla
·375 words·2 mins
CPAN Dist::Zilla perl