It takes a community to raise a CPAN module

CPANauthorshipcontributorspermissions Sat 13 February 2016

Some modules on CPAN were created by the same person who has always released it. But there are plenty which have been through many different hands, and which perhaps are released by a number of different project / team members. How should those different people be acknowledged? This post was prompted by IRC discussion with RJBS and GENEHACK, and Rik's blog post where he proposed that MetaCPAN should show the owner of a dist rather than the person who last released it.

I started this thinking I was going to propose one thing, but by the time I'd written it, I'd changed my mind.

Dramatis personae

Who are the people who might be involved in a module?

Those are all the roles I can think of right now, but no doubt I've forgotten some. Suggestions for better labels for the roles are welcome, as I just pulled these ones out of my, er, hat.

Where and how are those recorded?

Why might you care?

Ok, so we've identified the different people associated with a module, now let's consider it from an end-user's perspective. What are the different scenarios where someone might want to know who's (been) involved with a module? This might affect how we think MetaCPAN should present people alongside the module.

So what should MetaCPAN display?

Right now MetaCPAN displays a large picture of the last person to release the dist. In last year's pull request challenge I got Text-Diff in January. After submitting a PR with some bug fixes, OVID gave me co-maint so I could release the fixes. So now when you look at the module you see:

example module on MetaCPAN

There are a number of times when this approach doesn't feel right. The one that's bugged me is when I've adopted a module just to fix the dist's metadata, or fix a small bug. I've considered creating a second account with a name like MAINTENANCE for these sort of adoptions, so that (a) I don't get false credit for the module, and (b) it's not listed against my name. But that doesn't address all of the points above.

Furthermore, a lot of the time when people are looking at a module on MetaCPAN, I suspect they're not interested in the author, they're just looking something up in the documentation. In that case I think it's about acknowledging everyone who got the module to this point, not just the person who did the last release. Given all that, I think the following would be an improvement:

alternate author display in MetaCPAN

Everyone who's done a release (possibly just in the last N years) gets an avatar, and the (f) shows who has ownership (or could show the number of releases in parens after each author. The co-maints line tells you how many other users have co-maint but haven't ever done a release — clicking on it would roll down a list of those users. The contributors would show people listed in x_contributors.

Instead of tiling them down the right-hand side, they could be in a horizontal strip at the top, similar to the way the ++'ers are currently shown. I might play with some more designs and layouts.

I'm still thinking about this, but wanted to post as far as I'd got.

ADOPTME, HANDOFF, and NEEDHELP

The special pseudo-users ADOPTME, HANDOFF, and NEEDHELP, should be handled differently, with MetaCPAN clearly indicating the status. Something like this at the head of the page.

example adoption warning

This is similar to the "unauthorised release" warning that is shown if the person doing a release doesn't have at least co-maint for all packages in the release (that are eligible for indexing).

Even if those PAUSE ids have done a release, they shouldn't be treated as authors. Ie they should never be shown in the author panel on the right. I know there are a small number of releases that have been done by ADOPTME, but I think that's an anomaly.

This kind of notice should also be displayed if the metadata flags the distribution as deprecated.

All of the above are things that someone should know about before making a decision to rely on a module.

See Also

comments powered by Disqus