NEILB's Blog

A key part of the Pull Request challenge is deciding which CPAN distributions to hand out each month. In this post I'll describe the way I rank distributions, with the highest-ranking previously-unassigned dists handed out each month. You can browse the list of ranked distributions. This is still very much a work-in-progress — I'm looking for input on the criteria used to 'score' distributions.

We recently established an informal metadata standard for marking a distribution as deprecated, using the x_deprecated key. This is useful when automatically processing distributions, rather than pattern matching on the word 'deprecated' and variants. MetaCPAN will probably visually identify a distribution as deprecated based on this metadata. Here I'll describe how to add this to a distribution, using some of the distribution builders.

Until recently I've always done pull requests in the master branch, but after talking to various people I've learned that this isn't best practice. So I thought I'd share what I've learned so far. Feel free to learn me some more.

You've been handed a random CPAN distribution and been told to do something with it. But what? In this brief post I'll outline a high-level way to consider your options, and what to do for each option, with pointers to online resources to help you.

When you submit pull requests, the owners don't owe you a merge, and you shouldn't start hassling them to act on it. The flip side of that: if you're the owner (or maintainer) of a github repo, and someone submits a pull request, please at least communicate, even if you don't plan on acting on it anytime soon.

This is a list of things you might consider doing when you've been assigned a CPAN distribution as part of the CPAN Pull Request Challenge (aka the CPAN Lottery). Before doing anything, please remember that the goal here is to improve CPAN while having fun, possibly learning stuff, and engaging with others. This is not a numbers game: there won't be a prize for the person making the most pull requests, and that would likely annoy the owner / maintainer as well.

This is a collection of thoughts related to the etiquette of making pull requests. This is written with the CPAN pull request challenge in mind, but hopefully much of it applies more generally. These are just my thoughts, merged with guidelines found online, hastily written up. Please add and refine based on your experience.

I think it would be helpful to establish (more of) a convention for recording your todo list for a distribution with the distribution itself. Some dists already have a TODO file. I can't find any proposed conventions for this (eg in Perl Best Practices), so how about we say it's markdown, call it TODO.md, and get MetaCPAN to present it on a distribution's home page, like it does for the Changes in the most recent release?

Email me to sign up for the 2015 CPAN pull request challenge! Each month I'll assign you a CPAN distribution, randomly selected. You'll have a month to submit a pull request.

Last night I released the first version of App::todoist, which provides a todoist script. This is a simple command-line interface to todoist.com, an online todo list service. About 11pm I realised I had an hour to get something released to CPAN, or I'd break my weekly release chain.