Steven Chen writes:
I am currently working on the proposal of List Configuration Tool in GSoC idea list.
Glad to hear it!
I wonder what kind of configurations should be exported, and what should not.
Q1. We can get nearly all the configurations for a list from the core's REST API (https://mailman.readthedocs.io/en/release-3.1/src/mailman/rest/docs/listconf...), but some of the data should not be exported, such as
created_at,last_post_at, and etc. Hence, we may need a filter to extract out the meaningful configurations to export out.
If you are migrating a list to a new host, you *do* want to export those details.
At this level, I think it's probably more meaningful to separate the attributes into "read/write" (RW) and "read-only" (RO). The tool's UI should allow you to see everything, export everything, and change the RW attributes in place. RO attributes would include things like last_post_at, and maybe list_id (oops, that page doesn't mention the RFC 2919 List-Id attribute ... that should be part of the config!) Perhaps the list's addresses should not be RW by default but there could be a "hot stove" mode where you can change them.
Also, there are partially identifying attributes like 'acceptable_aliases', which might be useful as initial values in some cases (for example, I have a tree of umbrella lists for my advisees depending on enrollment status and expected graduation year -- the all_students top umbrella list should be an alias for all the others).
I wonder whether we have a more convenient way to get all meaningful configurations,
No. There is the "collection" endpoint ".../config", and the individual resource endpoints like ".../config/display_name". These are written with the 'PUT' and 'PATCH' HTTP methods, respectively. That's it.
and what kind of configuration fields are expected to be exported from the user's perspective?
Look up "list styles". This is a partial configuration that can be applied to a new or existing list. I think that there are "stylable" options such as 'advertised', there are list-identifying attributes like 'display_name',
Q2. Besides all the configurations obtained from the listconf mentioned in Q1, we have more configurations for a list, such as member list. In the Idea Page (https://wiki.list.org/DEV/Google%20Summer%20of%20Code%202021), it says that the membership roster should not be included by default. Since we already have the
list_mass_subscribemethod for importing a lot of subscriptions at once, so should the list configuration tool include the functionality to handle membership automatically or just does not include the memberships in the exported configuration?
I don't think this is necessary. Postorius already has a "good-enough" interface for this.
For Q1, I do have some thinking for some important configuration fields that should not be exported: owner_address: should be filtered out, since only the list owner can import the configuration template,
But this attribute is independent of the admin who does the importing. Also, you need to serve the host migration use case.
the owner_address should be set when the owner apply the configuration template to the list instead of import from the previous configuration. mail_host, fqdn_listname: should be filtered out, since lists are created under the domains, domains should be created before the lists are created. Hence, only the name before the domain should be included in the exported configuration, and the full fqdn_listname can be generated when creating the list.
Consider the virtual host use case, such as readthedocs. Suppose they migrate doc-sig@mailman.readthedocs.org to mailman.readthedocs.io. Then they need at least the subdomain "mailman."
The styling use case should be more flexible. Perhaps a checklist of all RW attributes.
I do need more suggestions on what to choose in the configuration that can be exported. Any suggestion is welcome.
You might want to ask the users (specifically, mailman-users@mailman3.org).
I would not worry too much about this, however. At this stage, you can have a tentative list of the kinds of attributes and which attributes are which kind. It's more important to think about use cases you want to serve, at least migrations and list styles, and maybe the tool can replace the current list configuration UI in Postorius. Also, is it just a backend for Postorius? Can it be written in Django? Or should it be written in Python, so it can be accessed from Postorius, the command line, and perhaps even EMWD's alternative Affinity management interface (that might be difficult since Affinity is written in PHP)?
I forgot to mention this previously, but you should make your account on summerofcode.withgoogle.com *immediately*, and start your proposal there. Make sure all needed fields are filled out. You can edit up until the deadline (at least that was always true in the past). It hasn't happened for several years, but Google's site has crashed or been extremely congested just before deadline, and if you don't have a proposal filed at that point, you're out of luck -- Google has always been very strict about that. If the schedule is incomplete, we can deal with that, but if any required data doesn't have at least a starter draft, it's no go. (Of course we can't accept updates after the deadline, but we can accept updates off-line if the site is crashed.)
For scheduling format, especially milestones, please refer to https://wiki.list.org/DEV/SPAM. I suspect that hasn't been updated since 2016 or 2017, so the URLs and some other information may be out of date.
I also recommend reading at least the introductions to the articles on "Waterfall_Model" and "Test-Driven_Development" (TDD) on Wikipedia. I don't necessarily recommend either as a great way to plan a software development project, but they give some idea of the kinds of activities and events that go into a plan. The ideas of writing documentation (the spec) and tests (TDD) first are important to thinking about plans, even if you don't necessarily follow those particular methodologies.
Regards, Steve