I'm not clear on what real problems this is really intended to solve, and
for at least some of the proposed problems, I'm not convinced it's the
I'll try to restate the problems in my own words:
(1) Last uploader as "point of contact"
How often is this really a problem? (e.g emails to point of contact) I
suspect that most "contact" is via RT or GH issue trackers. At least RT is
multi-user. (GH has its own issues).
When it is a problem -- when the last uploader doesn't want to be the point
of contact -- under what circumstances is having someone else be better?
* if primary maintainer is active, they can re-release to be the "last
* if primary maintainer is not active, how is listing them any better for
the community than the last person? It's still a dead end.
(2) co-maint escape hatch
Changing how metacpan lists stuff doesn't solve the underlying permissions
problem, so I don't see how this is anything other than the same as #1.
If we have co-maints without *any* primary maintainer, that's a problem
with a one-time solution -- find them and promote them. Then they can
choose to handoff to ADOPTME or whatever. (N.B. this is a good QAH project)
If we have co-maints with inactive primaries, PAUSE admins are happy to
help, which solves the actual problem instead of just hiding it on
metacpan. I suspect the number of times this is an issue is single-digits
per year or less, so getting people willing to come forward is a matter of
We still have the interesting situation of a co-maint who drops
permissions, but still shows up as the uploader (from when they had
permissions). That's a detectable situation if we wanted to do something
about it and I'll come back to that.
We also have the interesting situation where all permissions on a package
are dropped entirely and the next uploader gets first-come. I think that's
a bad idea -- if a permission drop would eliminate all owners, I think it
should revert to ADOPTME, so that PAUSE can ensure a suitable handoff based
on the CPAN river position. (This too be a great QAH change, btw)
Therefore, I don't think the proposal does much for the real problems
underlying the stated problems. That said, I can think of other reasons
that such a change might be beneficial:
(a) We now have the notion of a "primary" owner of a *distribution*, now
that we manage distribution names via package permissions
(b) We *already* have an "organization" view -- the primary plus
(c) By listing *current* primary and co-maints for a distribution on
MetaCPAN (based on matching package permission), we make ownership
issues/depth more transparent to the community -- shifting the focus to
those individuals rather than (historical) uploaders.
This way, if a co-maint drops permissions, the visible "team" gets smaller.
Another UX idea could be to annotate somehow how active each team member is
on CPAN (not just for the distribution in question). E.g. mouse over a
team-member's picture and you get a pop-up that says "last seen X days ago"
(i.e. last upload of anything to CPAN was X days ago).
That lets the community see how active/passive the organization's members
are. When an active co-maint drops off, leaving the primary person who
hasn't uploaded to CPAN in 8 years, that's significant and useful
information to know.
It's also excellent for highlighting ADOPTME, etc. situations.
Thus, compared to Rik's original proposal, I suggest that emphasizing the
full, current 06perms team (denoting who is primary/secondary and with some
sort of "CPAN activity" indicator), is more beneficial than just
emphasizing the primary maintainer over last uploader.
I think it offers more useful community info about the "quality" of the
distribution and still allows a comaint to "drop off" if desired.
I think the current "authors", "contributors" and "uploaders" can/should be
consolidated into a "contributors" list, orthogonal to the primary+comaint
team indication. (As there may be legacy authors in the 'authors' metadata
who don't have any current permission).
I.e. the "contributors superset" is "everyone who ever worked on this
thing" whereas "primary+co-maint" is "current group taking responsibility
for this thing".
* promote co-maints without primary to primary
* make last owner dropping permissions revert to ADOPTME
* publicize the PAUSE admin process to encourage co-maints to propose
ADOPTME status when appropriate
* have MetaCPAN/etc. show primary + comaints as owners of distributions
rather than uploader
* have MetaCPAN/etc. give indicators of primary + comaint CPAN activity in
* have MetaCPAN/etc. keep authors+contributors+uploaders in an orthogonal
list of "contributors".
David Golden <email@example.com> Twitter/IRC/Github: @xdg