> On May 26, 2018, at 9:16 PM, James E Keenan <jkee...@pobox.com> 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 d...@preaction.me
signature.asc
Description: Message signed with OpenPGP
