* Dave O'Neill <[EMAIL PROTECTED]> [2006-07-12T22:02:31] > Sheer volume aside, it's probably still a good idea. I don't think > there's a single-page comprehensive listing of email-related modules > anywhere else.
I know there are other modules that fit in. There's the SMS and MMS series...
suggestions welcome.
> Maybe it doesn't make sense to keep that category. Given that there
> would likely be about a hundred or so modules in it, it's probably
> easier to mark the PEP modules as such (whatever we determine that to
> mean), rather than marking non-PEP modules.
I think that's a good idea.
> Earlier today we were talking on IRC about some possible categories. I
> don't recall quite what was said, but I think the potential starting
> categories were something like this:
> - all CPAN modules that send, receive, parse, or manipulate email
> (basically, Category:Modules as it exists now)
> - modules owned/maintained by PEP
> - modules that PEP recommends (both PEP-maintained and
> not, will change over time)
> - modules that PEP recommends you not use (unmaintained,
> deprecated, or just plain bad)
I think this is an accurate portrait of what we talked about. I think the
relevant categories will be:
Modules - it's a Perl module!
PEPMaintained - it's in the PEP repository and will follow PEP guidelines
(yet to be determined; things like, "n people review API
changes")
PEPEndorsed - x out of y active PEP contributors think this is a good
module for what it does
SeemsAbandoned - no updates in a long time, despite open bugs
Superseded - another module provides all of the functionality, better
I've also created these categories:
HasProblems - the article includes a description of problems that go beyond
simple-to-fix bugs; either they're hard or they're design
issues
HasIdeas - the article includes a section about ideas for the future
The latter two should be created with templates: {{Problems}} and {{Ideas}}
will create a section header and category marker.
> At this point, it probably makes sense to define a "PEP module" as the
> email-handling modules that are a) authored or currently maintained by
> someone participating in PEP and b) don't make other PEP authors wince.
> If that turns out to be unworkable in the future, we can always
> change our minds, but we have to start somewhere.
Works for me!
I'm going to JFDI and stick these categories where I think they belong. Argue
or extend my ideas as y'all see fit!
--
rjbs
pgpJwHSX7zQeb.pgp
Description: PGP signature
