FAQ
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 <xdg@xdg.me> Twitter/IRC/Github: @xdg

Search Discussions

  • David Golden at Feb 17, 2016 at 10:33 pm
    Related ticket:

    * https://github.com/andk/pause/issues/169 (do not permit dropping all
    permissions on indexed modules)
    On Tue, Feb 16, 2016 at 12:04 AM, David Golden wrote:

    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 <xdg@xdg.me> Twitter/IRC/Github: @xdg


    --
    David Golden <xdg@xdg.me> Twitter/IRC/Github: @xdg
  • Olivier Mengué at Feb 18, 2016 at 10:26 am
    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 <xdg@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 <xdg@xdg.me> Twitter/IRC/Github: @xdg
  • Olivier Mengué at Feb 18, 2016 at 10:47 am
    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.

    If the primary maintainer is not active but is bothered for being contacted
    about this old module he abandonned to his co-maints, he could just give up
    his first-come permission to one of those co-maint.

    I think that the point of exposing permissions more proheminently on
    MetaCPAN is to push for some mouvement of those permissions to give them to
    more active people (or to pseudo-people (ADOPTME) to clearly show
    inactivity).

    Oliver.

    PS: the current permissions on a distribution are already exposed through
    UI on rt.cpan.org, above the bug list of the dist.

    2016-02-16 6:04 GMT+01:00 David Golden <xdg@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 <xdg@xdg.me> Twitter/IRC/Github: @xdg
  • Ricardo Signes at Mar 5, 2016 at 5:10 pm
    * Olivier Mengué [2016-02-18T05:46:44]
    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.
    If the primary maintainer is not active but is bothered for being contacted
    about this old module he abandonned to his co-maints, he could just give up
    his first-come permission to one of those co-maint.
    Exactly.

    --
    rjbs
  • Ricardo Signes at Mar 5, 2016 at 5:09 pm
    * David Golden [2016-02-16T00:04:05]
    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?
    For me, I'd say it averages a few times a month. I'm slowly getting this down
    by slogging at the problem, getting permissions transferred away from me, but
    it's a pain in the rear.
    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 that's good/fine/okay-at-least, too. My reason for balking at it is
    *only* that metacpan pages are also swimming in information.

    I'd still make the primary person's name the easiest one to want to click to
    send email to. :-) (I know people *should* be using the bug tracker, but I
    also know that they often *don't.)
    Summary:
    [...]
    Cool.

    --
    rjbs

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcpan-workers @
categoriesperl
postedFeb 16, '16 at 5:04a
activeMar 5, '16 at 5:10p
posts6
users3
websitecpan.org

People

Translate

site design / logo © 2018 Grokbase