Transfer the kde-russian mailing list to kde.org servers
Open, Needs TriagePublic

Description

Возможно, стоит перенести на сервер KDE список рассылки kde-russian.
Задачи:

  1. Договориться с админами об именовании
  2. Импортировать архивы и список пользователей
  3. Протестировать работоспособность
  4. Предложить переход в kde-russian.

Контактное лицо по поводу старого сервера — @sibskull.

aspotashev added a subscriber: aspotashev.EditedJan 26 2019, 1:12 PM
  1. Желательно сохранить текущий адрес рассылки: "kde-russian@lists.kde.ru" , потому что он указан во многих источниках, на которые нельзя повлиять.
  1. Архивы должны быть доступны по старым ссылкам, например по такой: https://lists.kde.ru/pipermail/kde-russian/2019-January/019645.html

Нужна возможность скачать архивы одним файлом.

  1. Что можно сделать с подписчиками, которые подписывались на дайджест? Можем для них сделать незаметный переход?
  1. Есть много подписчиков, которым приостановлена отправка рассылки по разным причинам, например:
    • почтовый ящик перестал существовать,
    • временные технические проблемы.

В новом движке для рассылок поэтому нужна возможность смотреть в админке, почему (и когда?) перестала отправляться рассылка.

  1. Желательно расширить лимит на размер письма (сейчас 100 КБ).
  1. Желательно разрешить отправку в рассылку с любого адреса, даже если он не подписан. Нужна модерация и админка для модерации с возможностью подключения сразу нескольких модераторов.

Now, in English...

This task is about (possible) transfer of kde-russian mailing list to KDE servers.

Requirements (some may be optional):

  1. Preserve the ML address (kde-russian@lists.kde.ru) since it's referenced by many resources, can't influence them (e.g. 3rd-party websites; social media; "About KDE" dialog in previously released versions of KF5 and kdelibs4). Or change ML address and setup forwarding from kde-russian@lists.kde.ru to the main ML address.
  2. The previously created permalinks to archived emails should live on ( e.g. https://lists.kde.ru/pipermail/kde-russian/2019-January/019645.html ).
  3. Possibility to download gzipped archives, see https://lists.kde.ru/pipermail/kde-russian/ for reference.
  4. What can we do for existing subscribers who subscribed to "ML digest"? Are they easy to transfer in a way transparent for subscribers?
  5. We have a lot of suspended subscriptions. In my understanding, that's mostly due to temporary mail delivery problems. What would kde.org's mailman do on failure to deliver email to a subscriber? Can moderators/admins monitor such failures?
  6. The current ML limits email size to 100 KB (including attachments). This is often not enough for translation files (even gzipped), need to raise this limit.
  7. The current ML rejects incoming emails from non-subscribers. This needs to be changed for pre-moderation for non-subscribers.

Please note that it is generally better to post links to things like this in #kde-sysadmin on IRC rather than #kde-www as they are more likely to be missed there.

In terms of your requirements:

  1. We can do this, what we'll likely do is alias the mailing list address and have it forward to a new address.
  2. This might be a little iffy, depending on how well structured the existing archives are and how a modern mailman handles them - there is some possibility of breakage but overall links should keep working (once again, may be subject to redirects to the new list name/address)
  3. That's just a mailman config option from my understanding. We may need to check our obligations in respect of the GDPR though.
  4. Subscribers details can be exported and re-imported to the new system, as long as you have (shell) access to the old system
  5. We have standard behaviour in this case for any other Mailman instance - after 5 days of bounces users subscriptions are suspended.
  6. The limit can be raised if need be yes, it's a list preference set through the Mailman interface.
  7. That's another list preference setting
aspotashev renamed this task from Перенос списка рассылки на сервер KDE to Transfer the kde-russian mailing list to kde.org servers.Mar 5 2019, 10:10 AM

For the record: the idea of the ML transfer has been approved by current subscribers ( see this discussion thread in Russian -> https://lists.kde.ru/pipermail/kde-russian/2019-March/thread.html#19667 ).

Hi Ben, we have concensus that kde-russian mailing list should be transferred. Could you please clarify on the next steps?

Nicolas gave his explaination on GDPR:

IRC, [10.03.19 21:41] <aspotashev> You mentioned GDPR. How to new mailing list at @kde.org would be different from all the others already existing at kde.org?
Nicolás Alvarez, [10.03.19 21:43] I guess by subscribing to kde-devel@kde.org people gave consent to KDE to handle their personal information (such as email address)
Nicolás Alvarez, [10.03.19 21:44] And they similarly gave consent to whoever runs the kde-russian list now
Nicolás Alvarez, [10.03.19 21:46] But if we migrate the list, someone who subscribed to the Russian mailing list and only gave permission to one organization will now have their info handled by another
Nicolás Alvarez, [10.03.19 21:46] At which point you go "pfft really?" :P but well I'm not even sure if that's the issue, just trying to understand it too
IRC, [10.03.19 21:47] <aspotashev> Sounds logical to me. How can this be worked around?
IRC, [10.03.19 21:48] <aspotashev> The "clean" way would be to create an empty new ML (kde-ru@kde.org?) and encourage all kde-russian@lists.kde.ru subscribers to subscribe there as well.
IRC, [10.03.19 21:48] <aspotashev> and then merge the ML archives somehow
IRC, [10.03.19 21:49] <aspotashev> However for the subscribers this would be much more PITA than care from our side

Do you think GDPR is such a big threat for us that we better start with an empty new mailing list like I described above?

Given that transfer of the mailing list archives would also involve transfer of personal information (as names + email addresses are contained in them) if we were to take that view then those wouldn't be transferrable either.

From my perspective I think it's fine for us to transfer them, given that everyone who is currently on the list has agreed (as part of the consensus) that the list should be transferred.

In terms of the next steps for the transition, you'll need to get access to the underlying system hosting the current list, as we'll need that in order to extract the current archives (and it's also the easiest way to get the list of members, both digest and normal modes)