This is my braindump response to https://rjbs.manxome.org/rubric/entry/2096
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 most-effective solution. 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 uploader" * 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 education. 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 co-maintainers (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". *** Summary: * 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 general * have MetaCPAN/etc. keep authors+contributors+uploaders in an orthogonal list of "contributors". David -- David Golden <x...@xdg.me> Twitter/IRC/Github: @xdg
