highlight modules or dists with ADOPTME or HANDOFF or NEEDHELP

[rjbs]

It is intolerably hard to declare that you don't want to deal with a CPAN module anymore. No matter what, it just sits there under your name, inviting bug reports, no matter how many times you say "No, I'm done." (It's even worse if you're only co-maint, but that's another matter.)

One accepted but basically unsupported solution is to use special permissions users to indicate the idea that you want to transfer permissions away, or just get more hands at work. Unfortunately, nobody benefits from this, because nobody can tell they've been assigned unless they go look in 06perms, which is far, far more than anyone should be expected to do.

It would be useful if the MetaCPAN web site would throw up a big notice like:

• ADOPTME: This distribution is up for adoption! Contact the modules list if you want to take over.
• HANDOFF: This distribution's maintainer is looking for someone to take over! Contact them…

[neilb]

👍

[oalders]

This can be done once metacpan/metacpan-api#338 is merged. I'll have another look at why that never made it into master.

[neilb]

I've written up my thoughts about this.

[rjbs]

@neilb Your blog post actually doesn't address HANDOFF or ADOPTME at all, from what I can see.

[neilb]

@rjbs: bugger, I thought about those at one point, then forgot to factor them in. ta!

[karenetheridge]

See also #952 and the wishlist section of the wiki.

[neilb]

@rjbs I've updated my blog post, to talk about HANDOFF, ADOPTME, NEEDHELP, and deprecated as well.

[dolmen]

Just for information: there is a place where permissions are a bit more visible that in 06perms: on rt.cpan.org, above the bug list of the distribution. That's where I usually lookup perms.
Here are a few interesting links:
https://rt.cpan.org//Dist/ByMaintainer.html?Name=ADOPTME
https://rt.cpan.org/Dist/ByMaintainer.html?Name=HANDOFF
https://rt.cpan.org/Dist/ByMaintainer.html?Name=NEEDHELP

[dolmen]

@neilb And speaking about rt.cpan.org, 06perms gives special power on RT tickets:

• only maintainers (or co-maint) can edit maintainer's notes.
• only maintainers and requestors can change the state of a ticket

[neilb]

@dolmen -- thanks, I wasn't aware of those!

I'll update my blog post.

[xdg]

My commentary on the related issue of who/why to show prominently: http://www.nntp.perl.org/group/perl.cpan.workers/2016/02/msg1400.html

[ThisUsedToBeAnEmail]

I guess this is me volunteering.

I had a play with this today and have a working end to end for NEEDHELP displaying at /release/* (was the first flag I came across inside of the demo data).

The idea with the button is it will be a mailto link that will provide the maintainers email, a default subject and body.

I would like clarification on whether you think is acceptable, whether the position of my notification is correct and also what the exact title, text and email should be for each state.

On the perl side I have made some modifications to the ReleaseInfo Model so it also retrieves permissions. Currently this is using releases main_module to make a single api request. I see inside the Permission model that you can pass a distribution but that will iterate all modules within it. I'm assuming it exists for a reason but would like clarification that permissions can be set at module level within a distribution and not just at dist level. ((1 vs $#modules) requests).

Regards Robert.

[oalders]

I guess this is me volunteering.

👍

permissions can be set at module level within a distribution and not just at dist level

Right. Essentially all permissions are at module level, since PAUSE doesn't have a concept of a dist.

I wonder if we'd want a button in the side bar as well, which could be displayed for the individual modules. Not everyone will make it over to the release page. In theory, someone could mark some, but not all, modules in a dist as ADOPTME etc. Not sure if that's the case in practice, but we should keep it in mind.

[ThisUsedToBeAnEmail]

In theory, someone could mark some, but not all, modules in a dist as ADOPTME etc. Not sure if that's the case in practice, but we should keep it in mind

If this is the case perhaps it may not make sense to display a notification at the release page. You may end up with a distribution that has all three states which could look a bit convoluted.

[oalders]

If this is the case perhaps it may not make sense to display a notification at the release page. You may end up with a distribution that has all three states which could look a bit convoluted.

Right, there could be some cases where this would be really confusing. If we were to display it on the release page we'd first have to check that every module in the dist has the appropriate ADOPTME etc. The other possibility would be to mark each individual module on the release page which is flagged in 06perms for needing help.

[haarg]

I think it would be fair to have that banner on the release page if any of the modules were marked as ADOPTME/HANDOFF. But also just basing it on the main module should be fine.

But having something on the module pages is probably more important, since those pages are often the only ones people look at.

[neilb]

I agree with @haarg: if the main module for a dist has ADOPTME or NEEDHELP, then assume it applies to the dist, and then when looking at a specific module's page, it could say "this distribution's maintainer is looking for help".

If the dist has been marked as deprecated, then the message displayed should probably reflect that as well.

[haarg]

See #1435 for discussion around deprecated modules.

[ThisUsedToBeAnEmail]

Okay so will continue to use main_module to display the notification on the /release page. I am not keen on displaying multiple notifications for each ADOPTME, HANDOFF and NEEDHELP. So will look into whether it is more logical to display the first or last found in the list of permissions.

As for module level should we also display a notification banner and a side button or just the button?

On deprecated this is already retrievable from release{deprecated}, this seems to be set at 'distribution' level. If my understanding is correct "you" (the people who decided to implement this stuff) have got it backwards because it seems much more logical to be able to deprecate a module within a distribution than to ask someone to adopt it.

[haarg]

If the entire distribution is deprecated, that is indicated with a x_deprecated field at the top of the distribution metadata. If an individual module is deprecated, that is indicated by a x_deprecated field in the module data inside provides.

[ThisUsedToBeAnEmail]

So a misunderstanding all of this is new and I should probably do more research/reading over assumptions, but thanks for the clearing that up.