RFC: Retiring inactive mailing lists

[Ben Cooksley]

On Wed, Sep 17, 2025 at 7:24 AM Christoph Cullmann <christoph at cullmann.io>
wrote:

> Hi,
>
> On Tuesday, September 16th, 2025 at 21:17, Ben Cooksley <bcooksley at kde.org>
> wrote:
>
> On Wed, Sep 17, 2025 at 6:47 AM Christoph Cullmann <christoph at cullmann.io>
> wrote:
>
>> Hi,
>>
>> On Tuesday, September 16th, 2025 at 20:36, Ben Cooksley <
>> bcooksley at kde.org> wrote:
>>
>> On Wed, Sep 17, 2025 at 3:07 AM Christoph Cullmann <christoph at cullmann.io>
>> wrote:
>>
>>> Hi,
>>>
>>
>> Hi Christoph,
>>
>>>
>>>
>>> On Monday, September 15th, 2025 at 20:42, Ben Cooksley <
>>> bcooksley at kde.org> wrote:
>>>
>>> On Tue, Sep 16, 2025 at 4:14 AM Christoph Cullmann <
>>> christoph at cullmann.io> wrote:
>>>
>>>>
>>>> Hi,
>>>>
>>>> https://invent.kde.org/websites/kde-org/-/work_items/42
>>>>
>>>> should now contain state of the lists we have.
>>>>
>>>
>>> Thanks Christoph. The really sad part is people who have sent patches or
>>> otherwise have been interested haven't received replies, and in my mind
>>> that really justifies closure and redirection of those lists.
>>>
>>> Does someone want to file some tickets and i'll then proceed with
>>> closing down the dead lists?
>>> (noting where needed if a list should be merged into another list)
>>>
>>>
>>> I am not sure what the best process is.
>>>
>>> I would assume to close all lists that not had any mail since the last
>>> 2023 'are you alive' ping is save.
>>>
>>> That is close to 2 years.
>>>
>>> I guess mailman allows to re-open closed lists if ever the need arises?
>>>
>>
>> Depends on how I do the closure.
>>
>> Normally when we close a mailing list we fully remove it, so the only
>> thing left behind is the list archives.
>> That means the list of subscribers, etc. is fully purged.
>>
>> If we were okay with reopened lists starting from scratch then that is
>> fine.
>>
>> Otherwise we would have to delete the mail forwarding into Mailman but
>> leave the list itself still registered in Mailman and set the list to
>> hidden/private.
>>
>>
>> I would prefer the second choice.
>> For sure there will be a few lists that need reviving in the future and
>> that would make it easier.
>> (and if I am wrong, which would be nice, I assume it is not that much
>> more work)
>>
>
> It's pretty low effort to create a list, the only downside is the loss of
> subscribers - and for those dead lists there is a good chance some of those
> emails are no longer interested anyway, so we would probably want to blank
> if the revival came after any length of time.
> In the not too distant future we will need to move to Mailman 3, and i'd
> very much prefer to only move over active things as part of that move.
>
>
> Ok, then I can live with just killing the lists, too.
>
>
>
>>
>>
>>> All other stuff needs in detail discussion I guess.
>>>
>>> Is our mailing list mail server able to generate more graceful bounce
>>> mails that contain some generic contact info like
>>>
>>> 'head to kde.org/xyz...'
>>>
>>> for people that try some non-existing address?
>>>
>>
>> We can add entries to the blocked-destinations list to achieve some level
>> of customisation, however the sender will still receive back the bounce
>> email that would contain just that one line of text we can provide as part
>> of blocked-destinations.
>> Anything else would require quite a bit more setup.
>>
>> For most of the dead lists though we could forward them easily enough to
>> one of our existing lists which is probably a better user experience?
>>
>>
>> Good question, I would rather really get just a bounce, one never knows
>> if not some old bugs point to them or other stuff and that
>> then ends up on the other list we point it to.
>>
>
> Wouldn't this mean people like the person who did the Calligra porting
> work would just see their email lost rather than sent to somewhere that has
> some life?
>
>
> I think that is the sad reality, but that one person got now from me a
> mail in person.
>
> I don't think that will make people sad, they are sad already that in most
> cases they got no answer for years. A bounce is a much better answer than
> none
> or ending on a totally different list.
>

My thinking is that for some project specific lists they have a natural
successor in the form of the module mailing list, and in those cases the
mail should be passed through to the bigger list?


>
> Greetings
> Christoph
>

Thanks,
Ben


>
>
>
>
>> Btw., all that stuff really cries for a gardening team :) ironic that
>> that list is dead, too.
>> Perhaps one could revive that as GitLab team for all interested.
>>
>> Greetings
>> Christoph
>>
>>
> Thanks,
> Ben
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20250917/5fa3a5e0/attachment-0001.htm>