Re: Hard-to-contact / Busy CPAN maintainers (was: status of Archite::Tar::Wrapper)

[email protected] (Doug Bell) Sat, 26 May 2018 22:50:39 -0500
Newsgroups	perl.cpan.testers.discuss
Message-ID	<[email protected]>
> On May 26, 2018, at 9:16 PM, James E Keenan <[email protected]> wrote:
> 
> > I sent a Pull Request of a fix for it (https://github.com/mschilli/archive-tar-wrapper-perl/pull/11 <https://github.com/mschilli/archive-tar-wrapper-perl/pull/11>) but so far didn't get any feedback from Mr. Schilli.
> >
> > Maybe I should fork the project?
> >
> 
> It's on github, so you can fork it.  But, in my experience over the last two years, the problem is getting a new CPAN release out the door.  More than we like, we have author/maintainers of key modules -- where "key" means either high up on the CPAN river or used in the toolchain -- who decline easy stuff (e.g., corrections to tests as opposed to source code) either passively (by failing to respond) or actively (by denouncing the patch requestors).


Regarding some of these problems, I saw a neat thing today: Vox Pupuli [1] is a Github team that adopts abandoned Puppet modules to ensure continuity. The Perl Toolchain Gang [2] is similar: They maintain dual-life and/or CPAN modules that are required to make CPAN largely work. But, the PTG are topical: They have their narrow focus.

CPAN already has ADOPTME [3,4] (which may have had a Github organization at one point) and that could be a starting point for a Github organization devoted to collaboratively working on otherwise-abandoned CPAN modules (a "Vox Perl-puli").

The problems with an idea like this would be, I suspect, more social than technical. Community projects need codes of conduct, standards of patch acceptance, leadership and succession planning. It would need to start with a group of 2-4 organizers initially responsible for establishing policies and community guidelines, reviewing submissions, and doing releases, and a long tail of contributors. But, projects under this umbrella would be more likely to have work accepted, and that would likely foster more work to be submitted.

The benefits to the Perl community would be increased maintenance of CPAN modules, and a healthier CPAN in general. Folks could go through the process of adopting a CPAN module from a missing owner and then transfer it to this organization so they aren't on the hook forever (or go missing, perpetuating the problem).

Someone is free to take this idea and run with it. I've got my hands full of CPAN Testers at the moment. Also, the rest of VB Brasseur's article [5] is really excellent advice for FOSS projects in general, and I'll be implementing at least some of them for CPAN Testers.

[1]: https://voxpupuli.org/ <https://voxpupuli.org/>
[2]: https://github.com/Perl-Toolchain-Gang <https://github.com/Perl-Toolchain-Gang>
[3]: https://metacpan.org/author/ADOPTME <https://metacpan.org/author/ADOPTME>
[4]: http://blogs.perl.org/users/brian_d_foy/2013/02/mark-your-modules-as-adoptable-if-you-dont-want-them.html <http://blogs.perl.org/users/brian_d_foy/2013/02/mark-your-modules-as-adoptable-if-you-dont-want-them.html>
[5]: https://opensource.com/article/18/4/succession-planning-how-develop-foss-leaders-future <https://opensource.com/article/18/4/succession-planning-how-develop-foss-leaders-future>

Doug Bell
[email protected]
signature.asc (application/pgp-signature, 833 B)