Hey Michael,

Obviously, bugs 21 [1] and 22 [2] are the big ticket items that require a lot of groundwork to be laid before they get tackled. That being said, is there a plan of attack for getting those features developed, or is that too far in the future still?

Well, my intention was to first have a working and at least feature-equivalent archiver as soon as possible because Mailman 3 was supposed to be released very soon. That was back in september, and Mailman 3 is not out yet. You're right, those features require quite a bit of work before they can be tackeled, but if you think Mozilla will need them soon I guess I'll start working on them in a separate branch. I think I can have a working version using the local mail server rather soonish, maybe even for FUDCon. That will not be enough because I suspect we'll run into antispam problems (SPF for example) sending emails on behalf of the user. The solution may lie in using the Sender header, but that takes precedence in MS Outlook, so it's not ideal. I'll look into that later.

Besides those biggies, I'd love to hear how hackable y'all think the codebase is to outsiders that might want to contribute. Are there any architectural changes in the pipeline that we might want to wait to land into Trunk before getting involved?

Nothing too big in my opinion. I'm considering moving my last big feature, thread sorting, from HyperKitty to KittyStore for performance reasons, and that will cause a schema change, but I keep track of that and provide upgrade scripts. There's something not-too-nice : HyperKitty uses Bazaar as its VCS on fedorahosted, and KittyStore uses Git on Github. We'll need to sort this out at some point, but it shouldn't block you from sending patches, annoying as it is.

Put another way: if you could snap your fingers and get an extra set of development hands, what kind of work would it be most helpful for those hands to get dirty working on? UX/UI frontend stuff, python hacking on hyperkitty's backend, or are there still improvements needed in mailman3 itself to make hyperkitty's job easier?

I'd go with frontend stuff. For example tickets #9, #28 and #32 (those last two should be easy). I've added a few items that were in my local todo list, I'll try to use Trac's tickets more in the future.

URLs: https://fedorahosted.org/hyperkitty/ticket/9 & https://fedorahosted.org/hyperkitty/ticket/28 & https://fedorahosted.org/hyperkitty/ticket/32

The main trick with HyperKitty is the separation between the UI (hyperkitty, Django-based) and the backend (kittystore, Python only). HyperKitty "imports" KittyStore in the Python sense and calls its API. We don't want to expose too much of the underlying ORM (Storm). Actually, as little as possible :-)

It does have a varying level of roughness around the edges, so please feel free to ask when something's not clear.

You are very welcome in the team !

Aurélien