Make it clear why someone would choose this module over other modules, yes. But, if you can, also try to make it clear why one would not choose this module - what limitations or other downsides does it have? For example, some people have a perverse fear of source filters (others have a very reasonable fear of source filters ;-}), so because you use this controversial feature, you should clarify that. For example, I'm not sure, but somehow I think you'll have problems inside an eval STR. Maybe not - but the better you document what you can and cannot do, the more realistic users' expectations will be.
Even if it means that I need to avoid doing something so that your module works, that's still relevant information. (And if you plan on cleaning up that limitation in the future.)
In reply to Re^2: When is it better to NOT release a new module?
by Tanktalus
in thread When is it better to NOT release a new module?
by snowhare
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |