Related discussions and opinions: https://github.com/CPAN-API/metacpan-web/issues/1643 http://neilb.org/2016/02/13/it-takes-a-community.html http://wollmers-perl.blogspot.co.at/2016/02/credit-first-or-last-uploader-on.html
2016-02-16 6:04 GMT+01:00 David Golden <x...@xdg.me>: > 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 >
