Congratulations on being selected!
Note that Mailman is a PSF suborg, so you have to comply with PSF reporting standards. I'll get back to you if you need to do anything more. The only thing I can think of offhand is to register with the PSF "planet" (or whatever they're using to aggregate blog posts). I *think* that's not even ready yet (or maybe they set it up today).
My apologies for disappearing on you after the application period, it's been very busy for me (most of my teaching responsibilities are in spring term, April-June, and startup is alway demanding).
A few comments on the content.
Jan Jancar writes:
### Current state
Relevant mailman-developers thread from GSoC 2015: https://mail.python.org/pipermail/mailman-developers/2015-March/024477.html
Thanks for the summary. I was wondering what people meant by "plugin", now I know! (I wouldn't call this a "plug-in architecture" to be honest; I'll be interested to study your improvements.)
### Proposed changes
- Add configuration option similar to config.styles.paths to Handlers, Rules, Chains etc.. Which Mailman will use to look for components, so that plugins can just be accessible on the python path and not necessarily inside the Mailman package.
Not enough, IMO.
Or use just one path per plugin and a standardized plugin structure:
Yes, more structure, please.
- Let plugins add Pipelines the same way they can add Handlers etc...
- Let plugins subscribe to receive events.
- Let List creator specify List Style when creating it through Postorius.
AFAIK this is already an RFE.
- Allow multiple callables in pre_hook and post_hook run in order specified.
Seems reasonable, you'll need to talk to Barry about that. (Of course you can always implement this with a hook-managing hook function. So it's a matter of abackward compatibility.