## Proposed changes to Mailman core

  1. Add configuration option similar to `config.styles.paths` but for general plugins. Paths in this list will be used to find components that Mailman will use, similar to `find_components` coupled with a standardized plugin structure:
    - `plugin package`
        - `handlers`
        - `rules`
        - `chains`
        - `commands`
        - `pipelines`
        - `styles`
        - `rest`

  2. Let plugins add Pipelines the same way they can add Handlers, Rules etc...
    - This means refactoring `BasePipeline`, `OwnerPipeline`, `PostingPipeline`, `VirginPipeline` from `mailman.core.pipelines.py` into a package `mailman.pipelines`
    - Use `find_components`, or rather it's sibling function created in 1.

  3. Let plugins subscribe to receive events.

  4. Let List creator specify List Style when creating it through Postorius.
     - The REST api supports it, add bindings to MailmanClient and a field to Postorius.

  5. Allow multiple callables in `pre_hook` and `post_hook` run in order specified. Also allow callables for when Mailman exits.
     - Already a [MR #264](https://gitlab.com/mailman/mailman/merge_requests/264).

  6. Allow Mailman core to send events to Postorius, HyperKitty and any app that subscribes through a new REST api call with a callback.
     - [#329](https://gitlab.com/mailman/mailman/issues/329)
     - Also add an `IEvent` interface, as currently events don't implement any interface at all.

  7. Drop `ext_dir`.

  8. Let plugins add routes to the REST API. Under `/plugins/<plugin_name>/...`.
    - Create a new `IRESTSink` interface, that is callable `func(request, response)` and knows it's prefix relative to it's root.
    - Use `falcon.API.add_sink(callable, prefix)` to add all `IRESTSink`s from both `mailman.rest` package(unused, no sinks necessary for core) and plugin's `.rest` package.
    - [falcon.API.add_sink](https://falcon.readthedocs.io/en/stable/api/api.html#falcon.API.add_sink)
    - Or use the current `ObjectRouter` with plugins providing a `Plugin` object with routing working as currently.

  9. ? Make all commands be able to require confirmation and make this a configurable option.
    - How?

  10. ? Add possibility of config inclusion to `mailman.cfg`, or of per-plugin config.

  11. ?? Add a new attribute to several core models (MailingList, User, Address, ...) in which plugins can store metadata about said objects. This attribute woul be a PickedType, really a dict with, plugin-names as keys. Each plugin could access its and only its metadata attached to a given object.

## Proposed changes to MailmanClient

 1. Add bindings for specifying list-style on list creation.

 2. Add bindings for `/plugins/<plugin_name>/...`.
    - Pretty low-level, since each plugin can handle requests as it wants.

## Proposed changes to Postorius and HyperKitty

 1. Add additional blocks to some base templates.

 2. Add a dropdown list-style selection field to list creation template + view.

 3. Let Postorius and HyperKitty subscribe to receive events from Mailman Core, add an API route to receive them in django-mailman3.