On 09/21/2008 07:17:14 AM, Sawyer X wrote: > Hello everyone. > > I've been hacking away various unrelated modules (RTSP::Lite, > Net::SMTP::TLS, for example) and occasionally I send the original > author an email or a bug report to fix whatever problem I found. > However, a lot of these problems (and even more that other people > patch/comment/report) are not handled since the original author is > either too busy (could be too busy to patch or too busy to even reply > to the email), is unreachable (email not relevant anymore, person > unavailable) or various other reasons i'm sure others could jot down. > > So, I thought maybe it's 'bout time to regular the authorship of > modules. I've had a few basic concepts of it but I turn to the > community to hear what other people have to say. What do you guys and > gals think? Should we regulate? It will definitely help fix bugs and > advance some of those discontinued modules. It will help relieve some > clutter from who still get emails from people regarding issues on > their module that they just delete or do not repond to. > > Some points I thought of (which might be wrong - I wanna hear what > others think):
In general, I agree 100%. I recall that there was (a year or so ago) a call for volunteers to adopt abandoned modules. If there was a criteria for "abandoned", I don't recall it. Never heard anything more of it. If my recollection is correct, it would be useful to know what happened. > - Have a process in which someone wants to take over a module, and > the > author is asked. If he does not reply within... oh, I don't know, 6 > months? 1 year? the module authorship goes over to that person as a > Co-Maintainer - allowing the original author to continue working on > it > if he pleases (and perhaps remove the new co-maintainer from his > position). > - Maybe have a timeout period (again, 6-12 months I think) that after > that period a module is now considered (and flagged) "a community > held > module" which means any developer can request to be assigned as > co-maintainer to it. A variation of sorts on the two above. All authors get a periodic email, similar to the probes used by email lists, to his/her CPAN address. If that bounces, then the author's modules automatically get "community" status. It seems to me that anyone who is too busy to keep his/her CPAN email address current, or is off the net altogether, is probably not interested in maintaining their modules. It should, of course, be possible for an author to override this in advance, or to request it be rescinded. > - Of course, we need to make sure that new comers don't just take old > modules (which work very good) and break them which makes it > impossible for others to now use the functionality they sought in the > module in the first place. Amen to that. Perhaps a "sandbox" where new versions would live for a while? With CPAN testers getting an (automated) vote? > - Maybe have developers apply once a year (reminder system, anyone?) > to make sure their module is still under their sole authorship. Like, > get a small email from the reminder system of PAUSE and just reply > with an empty msg content. This does not strike me as a winner. If a module is in good shape (i.e., not subject to any of the problems dealt with here), why hassle? > - The trickiest: what if I wrote a module, but I don't want to add to > it, and I don't want anyone else touching it ever - I want it the way > it is and that's it. Do we fork it? Do we each start patching various > things on the system by our selves? That'd be nightmare, but... > wouldn't it still be my right? I don't know about this, but I'm > losing > sleep over the philosophical aspects of it! :) > (whoever knows the issue with ion3, knows what I mean) If I understand the Artistic License correctly, anyone can grab a module, modify it and release it under a new name. So I think that the proper concern is how to manage forked modules. Perhaps a numbering/ naming scheme that says, in effect, "This is a forked module under different authorship from the root, that has most/all of the underling functionality of the original." Guidelines for spelling the departures of the forked module from the original would be helpful, also. Additionally, there should be a procedure for bringing a forked module into the main branch, once the original author has been determined to be unavailable/uninterested. > I'm just brainstorming here but this is behavior that exists for many > of us and not once or twice we see mails that go through (at least) > this list asking for any contact to a person who is authoring a > certain module. I know I've tried reaching various people without > asking here, so I'm guessing others as well, which means the number > of > people desperately searching an author to put in a few more lines of > code (that they might have already have written for them) is greater > than we see. > > Please people, if you find this interesting, reply. Lets discuss this > as a community and try to make things better for ourselves! :) > > Sawyer. At the risk of bringing all sorts of trouble on my head :-), let me add a personal aggravation. Which is modules that have acquired a long list of unattended bug reports. Perhaps there should be a criteria here as well? I'm cool with an author not wishing to maintain something (works for me!), but why not just say so. Perhaps just the existence of a "community" category would help here. This would encourage those of us who are not in a position to actually invent from scratch but are able to contribute in the maintenance. Final thought. It needs to be _easy_ to take up a module, whether abandoned or forked. Having done so myself, the current system of having to demonstrate that the original author is unavailable is a real pain, although I understand the need for it to be that way now. Geoffrey
