A proposal was brought to FESCo to decide on whether there should be an inactive list policy for Fedora. FESCo collectively agreed that such a policy should rightfully be decided upon at the Council level.
With that in mind, I have the following specific proposal to offer for the purposes of starting the discussion:
Any list that hasn’t seen a message for the last four Fedora release cycles will be archived.
I’m fine with some kind of policy if the council wants to set one (like
‘lists with no posts after X time are closed’).
I’m not at all in favor of deleting lists, as they are often linked to
and provide important historical value. Of course if they have spam,
that should be deleted.
Finally, I am hopeful that we can move our mailman3 install over to
rhel9 and the latest mailman/hyperkitty/etc sometime. If we can/do, I
would prefer we enact/enforce any archive policy at that time. It would
be much easier for us to just do it as part of a migration to a new
install than to try and do it now.
I think lists are going to be around for a while. We use them for lots
of things, and of course those could be moved away, but it will take
time and effort and we shouldn’t try and do it instantly.
I do struggle with discourse and most Web2.0 social media to speed read and
keep context across large volumes of forum posts.
Abandoned Python contributions when they went over to Discourse.
Not OT here I hope: My preference would be to operate from a more
familiar email client dedicated to feeding and reading from discourse.
Using your mailing topic lists as a primary means of access.
I know that there are a few problems to be ironed out from reading about
this some time ago.
Mailing lists might be used more if this feature has been implemented in your
Discourse setup. I’d be disappointed if I have to go cold turkey with no list or
email feed from Discourse.
Webmail only ( i.e no imap /pop / smtp mail client access) is less useful when
(say) openpgp signing / auth is needed by contributors of patches etc.
+1. I agree it is wise to group major changes around the same time as the infrastructure upgrade. If part of our strategy is to modernize contributor communications, we don’t have to do it all in the first few months. I’d prefer reducing burden on infrastructure maintainers, who are a key part of anything we do with mailing lists.
I wonder whether a total shutdown is what we really want. On one hand, I do think it is important that project discussions, planning, and feedback are collected from one place. On the other hand, I also recognize there are several other periphery platforms where Fedora discussion happens and is encouraged (e.g. Reddit, Mastodon, Telegram, other forums, etc.). As a community, we have done a decent job of meeting people from where they are.
I see no reason why mailing lists cannot be the same way. While I do think we should encourage contributor conversations to move to Discourse, there should always be an option for user communities to form up with mailing lists. The only change I would make for mailing lists is that every list should commit moderators to maintain the discussions.
One of the hidden challenges of mailing lists is that they are add complexity for Code of Conduct incidents. The moderation tools of a mailing list are blunt tools. Often, the best action available is a total ban for a fixed period. In the current way, the Fedora CoC Committee ends up as a moderators group for list discussions, when in reality, there should be another group of “local” moderators to resolve complaints and issues before a problem is escalated to the CoC Committee by default.
So, this is why requiring a moderation component is important for any lists that we would continue to support. The Fedora CoC Committee should not be a general moderation group for mailing list discussion. Local moderators usually know their groups better and are often better fitted for resolving smaller issues or arguments in line with the Fedora CoC.
I’d prefer reducing burden on infrastructure maintainers, who are a key part of anything we do with mailing lists.