core-workflow
core-workflow copied to clipboard
python
Develop a checklist for Mailman 3 list conversions
@msapiro has now converted core-workflow and core-mentorship over to Mailman 3:
- https://mail.python.org/mm3/mailman3/lists/core-mentorship.python.org/
- https://mail.python.org/mm3/mailman3/lists/core-workflow.python.org/
The formatting in the list descriptions didn't survive the conversion, so I filed https://gitlab.com/mailman/postorius/issues/242 to request a fix for that.
Beyond that though, I think we should develop our own procedural checklist that we ask list owners to go through as part of the conversion process. Some initial ideas on points to include:
- Send an email to the affected list first to say the conversion is happening, and summarise the consequences
- Ask list members to create an account on https://mail.python.org/mm3/ using their currently subscribed email address (the authentication mechanism here is access to their existing email account to receive the address confirmation email, not their old list-specific MM2 passwords)
- Explain that
https://mail.python.org/mailman/listinfo/<list-name>will be redirected tohttps://mail.python.org/mm3/mailman3/lists/<list-name>.python.org - Explain that MM3 uses a more typical "User account with list subscriptions and potentially admin and moderator permissions" model, rather than MM2's "Which list-specific passwords do you know?" access management model
- For lists with public archives, explain that the existing Pipermail archives will remain in place, but will stop getting new messages, and will be updated with links to the new MM3 web gateway page
- For lists with private archives, explain that folks will have to go directly to the new URL, since the specifics of the way MM2 private archives work mean there's nowhere to put the link to the new archive on the MM2 pages (there's no public archive page, and no way for subscribers to authenticate against the migrated list to access the private page)
- Email [email protected] to request the migration
- Once the migration is complete, email the list again to let the users know it's been done
Before migrating python-dev and python-ideas, we're also going to need a secondary archiver that offers a more pipermail-like UX (e.g. https://mailman.readthedocs.io/en/latest/src/mailman/archiving/docs/common.html#mhonarc )
Note: I haven't sent "This is done" notices to core-workflow and core-mentorship yet. I'll send short ones now, and then follow up with more complete ones once we agree on what they should say.
I noticed the footer of core-workflow mailinglist email is broken:
core-workflow mailing list -- [email protected]
To unsubscribe send an email to [email protected]
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
See https://mail.python.org/mm3/archives/list/[email protected]/message/J6B443H7KMTI2DSJTMHVG3IUYHN5IESD/ for example
The line %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s is unconverted from the old Mailman 2.1 list's footer. I have changed it to https://mail.python.org/mm3/mailman3/lists/$list_id/ which will actually render as https://mail.python.org/mm3/mailman3/lists/core-workflow.python.org/.
@ncoghlan where should the above checklist be documented? I want to request docs mailing list be updated too :)
Send an email to the affected list first to say the conversion is happening, and summarise the consequences
@Mariatta I don't actually know, since we don't currently have anything like a "mail.python.org List Owner's Handbook" for general advice to all list owners & moderators.
@brettcannon @warsaw Any ideas?
I have no clue where to put such a checklist. An appendix in the devguide? Somewhere on www.python.org?
There is a somewhat important point here: that mailing list management is a fairly isolated task. I singly or jointly own / moderate about 10 lists on the python.org domain and each has slightly different "rules" and feel.
I'm half-inclined to propose a "mailing list" mailing list! Subscribe all the xxx-list-owner addresses to it. Then the first post could be the kind of list in the OP.
But an appendix to the devguide is probably a good place to start with. I don't think it's the best long-term solution, because there's a difference between developers and infrastructure volunteers, but it's good enough for now.
How would folks feel about adding a "misc" folder to the core-workflow repo to hold things that don't have a better home yet? Then we'd just making the mailing list migration checklist a standalone file in there for now, and then adjust the description of the repo in https://devguide.python.org/communication/#additional-repositories (we should tweak that description anyway, since the core-workflow repo not only hosts cherry-picker & blurb directly, it also provides the links to other core-workflow projects, like the GitHub bots.
I'm fine with misc/ catch-all that @ncoghlan is suggesting as long as we make sure that if something does eventually deserve promotion to a better place we do and we also don't fill the directory with a ton or random stuff.
+1 for adding it as part of core-workflow, but I suggest something like "docs" instead of "misc" so the contents of that directory don't become too random.
In that case, I think what I'll do is set up a proper Sphinx project as a docs directory, akin to https://www.pypa.io/en/latest/ for PyPA.
That way we'll have somewhere to start tracking the intersections between CPython Core Workflow, PSF Infrastructure, GitHub, Travis CI, Appveyor, Roundup upstream, BuildBot upstream, etc. (I'm not going to add all of that immediately - we'll just have a place to eventually add it, without overloading the developer guide with it)
Adding another note based on a discussion with @soltysh: something we need to explain to list users and moderators when migrating existing lists is how to log in to the new site.
I did it by associating my GitHub account, but the key point is that both user access hinges on control of the mailing address used to subscribe rather than the old per-list user passwords that MM2 historically emailed to list subscribers every month, and moderator access is similarly based on the moderator's email address, rather than knowledge of the old per-list admin passwords.
(It's likely obvious by now that I didn't get around to setting up any "meta docs" last year, and it's not on my current todo list any more. Just making that explicit, rather than leaving it solely as implied based on the long silence)
I've taken the initial steps towards migrating distutils-sig to MM3, so here's an example post that attempts to explain the items in the checklist above: https://mail.python.org/pipermail/distutils-sig/2018-April/032215.html