Hi Aurélien,

Thanks for the info!  Some replies inline:

- HyperKitty uses the top-level template directory (eg. it has a templates/base.html file), which is generally reserved for site-level templates.
- HyperKitty's base templates aren't broken up into blocks in such a way that they can easily be used to extend a different base template.  The base template defines both the overall page structure and various HyperKitty components, so it's impossible to, say, modify the navigation bar without replicating a large chunk of HyperKitty stuff.

I am not very familiar with Django conventions, so please feel free to point me to the right direction. Pull requests are even more appreciated! 

I can work on a pull request.  The best practice that I've seen with regard to template naming is to put the templates under an application-specific subdirectory, eg. "templates/hyperkitty/template.html".  I'm less sure about the template layout -- I typically have a base layout that breaks the page into functional blocks (header, navigation, breadcrumbs, body, footer) which get extended in application templates, but that's just the product of my own trial and error, I'll look and see if there's some more formal best practice documented somewhere.

- Moreover, both apps use the same view names in places.  For example, the HyperKitty user_profile page loads Ajax content from the "user_subscriptions" view, but Postorius defines its own "user_subscriptions" view that returns a full page.  The result is that if the main urls.py includes Postorius URLs after HyperKitty URLs, the HyperKitty subscriptions tab tries to load the Postorius page via Ajax and fails.

Do you recommend prefixing the view names?

I've seen that suggested, but I feel like that results in awkwardly verbose view names.  Django supports namespacing (so you could say {% url "hyperkitty:user_subscriptions" %}) but I haven't used this much and my initial impression from trying it is that it's fairly fragile.

- Postorius uses BrowserID authentication through social_auth, while HyperKitty includes a separate browser_id library

Yes, we are both migrating to the separate browser_id library, for security reasons.

Thanks, I will use that.

Also, I tried out the mailman-bundler package -- very convenient, thanks!  Its config lists the HyperKitty URLs last, so the HyperKitty pages look fine but you can see the view name conflict from the Postorius page at http://localhost:8000/mailman3/accounts/mailmansettings/ -- the "Profile" and "Subscriptions" links go to HyperKitty.

Cheers,
Adam