Chris Nulk cnulk@scu.edu recently wrote, in part...
Remember that communications with the list owners is extremely important.
Indeed!
What we did was: 0. Have a firm timeframe to complete the change over.
Haven't picked the date yet -- nor have I told the users what is coming yet until I get Mailman installed, tested, and have done some test conversions. When that's all in place, you can bet your sweet bippy there will be a firm timeframe for the conversion!
- Try to weed out as many lists as you can that may not be
used anymore.
Done. Contacted all list owners with no postings within the past year. One way or the other, all ended up being retired.
- Set up Mailman in parallel with ListProc.
Already have two separate list alias files so it will be easy to switch message delivery from ListProc to Mailman on a list-by-list basis.
- Create new lists in Mailman...
- List owners of the Mailman lists should be the same as
ListProc lists.
- Communicate with the list owners of the ListProc lists and
let them know how to access and configure the list on Mailman.
- Give list owners time to make their changes (e.g. add
moderators, set moderation, etc.) and test the list.
- After list owner testing, populate the list (or have the
list owner do it) membership.
My goal, which I did last time we did this (over 10 years ago from a homegrown system) is to have a script that does the conversion on a list-by-list basis. The list owner picks a date for their list to be 'down'. I do the conversion on that date, and bring their new list up and hand over the keys. This assumes that I will be able to do a good job of mapping the most important settings from ListProc to Mailman. If that doesn't turn out to be the case, your suggested approach of giving them some time to play with the Mailman list without subscribers may make sense. But for 80% of my list owners, once the list is initially created as either an 'announce', 'discussion', or 'moderated' list, they never mess with the configuration. So I'm optimistic I can map the list behavior automatically and have the new list working just like the old one, out of the gate.
- Communicate with the list owners for a cutover time (either
individually or all at once) to do any file conversions like archives, etc.
In the last conversion I sent out an announcement to all the list owners telling why the conversion and the time-frame to contact me when they were ready to make the switch. That allowed me to make adjustments to the process as we went since my early adopters were better at both finding the bugs, and not panicking about same.
- Monitor the process carefully.
- Remember that firm timeframe, well some list owners are
still going to miss it. Be prepared.
Indeed. Last time the deal was if I didn't hear from the list owner by such-and-such a date, the list would simply be retired. It was amazing how many people just let that happen rather than just replying to the nag message to say that they didn't want the list any more so just retire it now.
Overall, the process went very smoothly for us. We did not convert the archives.
We don't have many lists with archives. I probably will only convert if owners explicitly ask. I'm betting few will.
We did change how we populated several of our lists though which was a bit of a challange (we went from populating via a static mechanism once per year to dynamic LDAP populating).
I have a similar issue -- I maintain student announcement lists by college and class year, or even down to major code, with a weekly update from Registrar's records. I'll have to build that all over again for Mailman. Doesn't look like it should be too bad using the command line tools.
Thanks for the observations and advice.
...BC