Release a new distribution every month in 2014
This challenge is a stencil quest on questhub: in each calendar month of 2014 you have to release a distribution that you haven't released before, and write a blog post about it. This might be an entirely new distribution, one that you've adopted, or one that you're helping with. The rules so far are:
- You have to release at least one such dist within each calendar month. You can't catch up, by releasing 12 in December.
- You must blog about the dist and link to the blog post in a comment on your quest. It doesn't matter if the blog post is in a following month.
- Renaming one of your existing dists doesn't count :-)
Come and join us!
If you're going to try and do this by adopting distributions, you might want to get started now.
I have a list of 77 distributions that I'd like to create (32 Lingua, 10 Unicode, 4 Regexp, 4 Test, etc.), but I'll probably release a maximum of 4 new distributions in 2014. The reason is that I need to focus on quality rather than quantity. I can do a lot more for the Perl community and for my own work by focusing on improving existing projects and dedicating enough time to release a few awesome new projects. If I focused on a specific number or frequency of new projects, it would come at the expense of the quality of those projects and existing ones. In fact, if I knew for sure that nobody was using them, I would delete 8 of my existing 15 CPAN distributions right now because I don't think they're being used and I don't plan on updating them. CPAN would be better off with a reduction of distributions and an increase in quality of each distribution.
As for blogging, I wholeheartedly agree. I really need to make more time for this and it would be great if I could stick to a goal of blogging about my Perl/CPAN work at least once a month.
> In fact, if I knew for sure that nobody was using them, I would delete 8 of my existing 15 CPAN distributions right now because I don't think they're being used and I don't plan on updating them.
Set yourself a quest to delete 5 of them. Release versions with them marked as deprecated, and direct potential users to alternative modules, if there are any. And schedule their removal from CPAN.
> CPAN would be better off with a reduction of distributions and an increase in quality of each distribution
Note that this challenge says you can do it all by releasing existing distributions that are new to you. And you can use the adoption list to identify currently unloved distributions that are demonstrably of some value to CPAN.
Whoa, hold your horses – not the best idea to just delete them.
I’ve made this experience a couple of times: gone to look for a module I spotted and bookmarked from the uploads feed years ago, only to be unable to find it, until I figure out that it was thrown away by its author.
Why would you do that? If the module isn’t crappy, just “not much use”, please just pass ownership to ADOPTME. And if you think it’s crappy code and you want to remove the pollution, better to add a notice to that effect to the POD, assign co-maint to ADOPTME, and see if anyone pops up to take care of it. If after years there hasn’t been anyone, OK, fine, go ahead and trash it.
Of course the fact that there is BackPAN means this is not a critical issue – worst case, someone who is really after it (as I was in the case of those modules) can still locate it and get a copy.
But if it isn’t terrible code and you are merely done with it, just let it go free and find happiness on its own… why strangulate it?
I don't know why the list of adoptable modules at metacpan is so short, but at
https://rt.cpan.org/Public/Dist/ByMaintainer.html?Name=ADOPTME is a full list.
Whoa, hold your horses Aristotle! :-)
I didn't say "just delete them". I said mark them as deprecated, "and direct potential users to alternative modules, if there are any. And schedule their removal from CPAN". Ie remove them at some later date, having given notice.
I'll write a separate post on deleting things from CPAN!
Jakob, I was referring to my adoption list, which has a lot more candidates.
I wasn’t alarmed that you did not suggest a deprecation period. I was dismayed that the goal of the sole course of action you suggested is deletion, as though the natural order of things. My own feeling is that deletion should be very rarely chosen and that most people should intend for something else, depending on what circumstances and motivations suggest.