Re^2: Responsibilities of a module author

What should I do?

In line with the guidelines I'm offering, I'd suggest adding a similar summary like you had above to the module documentation, plus a note that you're not actively maintaining it and are looking for a co-maintainer to hand off to. That way, any prospective users are at least aware ahead of time what to expect. Plus, you'll keep your request for help with it out in front of the module users.

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Comment on Re^2: Responsibilities of a module author

Replies are listed 'Best First'.
Re^3: Responsibilities of a module author by dragonchild (Archbishop) on Nov 24, 2005 at 15:31 UTC
Except, I am actively maintaining it to the best of my abilities. It's still my responsability and I will be using it for work. In addition, I want to be involved in the direction that it takes as a module I do maintain depends on it. It's never quite that simple. Oh, and PDF::Writer has no documentation as the API is completely random and will change every release for a while as I refactor. My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]
Re^4: Responsibilities of a module author by xdg (Monsignor) on Nov 24, 2005 at 16:36 UTC
I don't see anything wrong with saying that. I wasn't trying to suggest that you should deprecate a module that you are maintaining. Whatever is your situation and level of commitment, just communicate that clearly. -xdg Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.	[reply]


Perl: the Markov chain saw
	PerlMonks