Giving up on weekly neoCPANisms

For a brief period of time (well, one week), I had a chain of 4 weekly neoCPANisms in NEILB's NeoCPANisms contest (which is subtly different from the Monthly New Distribution Challenge 2014 quest on questhub).

Then at the end of week 23, instead of pushing out an entirely new module (I have a two or three "almost ready" distributions in my CPAN folder), I decided to give up.

I had started to participate seriously in the weekly neoCPANisms contest when I saw I had reached 3 weeks in a row (with Task-CPANAuthors-Regional, Task-CPANAuthors and Acme-CPANAuthors-MetaSyntactic. It didn't take much effort to produce Acme-MetaSyntactic-cpanauthors (an idea I had kept in the back of my mind for more than a year, actually maybe two).

Last Saturday (June 14), around 22:00 GMT (i.e. two hours before the deadline), I probably still could have rushed something out. However, I decided I wouldn't.

My main reasons were that:

  • I was tired
  • even though noone else but me is watching my code (I mean, look at the proportion of "joke modules" in those neoCPANisms), I didn't want to put out something too shabby
  • putting out stuff I'd be ashamed of later definitely goes against the spirit of the game
  • it's just a game

Neil and I have discussed "bending the rules" recently, and he decided that "unlike the original release-once-a-week competition, there would be no special dispensations, even if PAUSE died. The PAUSE timestamps are really final." Obviously, no special cases mean simpler code, and simple, easy to understand, rules. Making a special case for a PAUSE breakage or a release that was pushed on time but indexed and put on CPAN after the deadline for the sake of an author's chain length is making the whole thing more serious than it needs to be.

It's amazing to realize that DROLSKY has put at least one release on CPAN every month for 162 months (13½ years!) and counting. But even if he was playing the CPAN once-a-month game, I don't think he should think twice before taking a month-long vacation from CPAN if he wants one. He definitely deserves it!

Actually, one of the ideas Neil and I share about those dashboards is that the more leaderboards we have, the more games we have, the harder it's going to be for anyone to compete in all categories. I'd actually love to have CPAN games that are in direct contradiction: to perform great at one of the games means you will perform poorly at another. So you, as a CPAN author, would have to pick your battles.

Remember: it's just games. They are designed to encourage a certain type of CPAN behaviour (for those interested in playing) and the one important, unwritten, rule of all those games is to make CPAN better. That's the end goal, and the only one that really matters.


CPAN tortoise game: longest chain of releases of a particular distribution. A chain is disqualified if there were any two releases with release dates separated by less than 60 days. Slow and steady wins the race.

Some other ideas:

* instead of tortoise, longest chain of monthly releases for a single distribution.

* longest chain of {weeks,months} where an author makes {2,5,10,more than 10} releases.

* longest chain of {months} where an author creates {2,5,more than 5} new distributions.

* longest chain of {weeks,months} where an author makes new releases of existing distributions *only* (so, no new releases, only updates).

competing in #4 will automatically eliminate you from the neo* races.

Other leaderboard ideas:

* longest chain of {weeks,months} where someone creates CPAN RT tickets or updates existing tickets.

* total number of reverse dependencies for all of an author's distributions.

* total number of ++'s for all of an author's distributions (too much of a popularity contest?)

* Anything that involves fixing existing modules instead of creating more. Could even be weighted by # reverse dependencies or ++'s (so an applied bug fix to a common module would be worth lots of points).

* Longest chain of monthly reference to module in other sources (e.g. stackoverflow, non-Perl blogs, RosettaCode, etc.). Modules that show how Perl can be usefully extended outside of the echo chamber. Hard to tally and prevent gaming though.

* Longest chain of an author contributing to unique non-owned modules (that is, each week/month they have to submit an RT, issue, patch, pull request, etc. to a module that they don't own, each module only allowed once in a chain).

My taste runs to trying to increase the quality of what we have, vs. putting out yet another variation on some module we already have. Measuring this is certainly harder than tracking new CPAN submissions though.

The goal isn't only making CPAN better, but also to have fun.

Some good ideas for additional competitions in the comments! I like the idea of chains of contributions to other people's work. A first such one could just be to filter the current release per week / month to only consider dists where you didn't do the first release.

Dana, I like your line "increase the quality of what we have".

> a release that was pushed on time but indexed and put on CPAN after the deadline

Werd. This upload broke my once-a-day and neocpanism-a-week chains:

Request entered on: Sat, 31 May 2014 23:59:10 GMT
Request completed: Sun, 01 Jun 2014 00:00:26 GMT

I had a big sigh, but indeed, it's just a game!

And I felt like a right jobsworth saying "no" to that one. It did help me firm up my notion of the rules though, in particular "data driven".

Leave a comment

About BooK

user-pic Pink.