How dare you - I'm glad you did :) Even though I'm a "mail/mailing list guy" using TUI MUAs, I found myself turning delivery off on many high volume MLs where the volume does not correspond to my contributor's frequency. I even read fedora-devel via hyperkitty's web interface, which is really suboptimal. So I see both the value and the problem with MLs. A different transport like public-inbox may help me but not many others. In any case, we have quite a fragmentation right now with the MLs, forum (discourse), IRC, Matrix, plus tickets on various platforms (bz, dist-git, pagure, gitlab) some of which offer teams and discussions, too. Choice is good, fragmentation is not because it makes it hard to know: - Where can I reach whom? - Where can I discuss what? So I'm really all for reducing that fragmentation, and it can be made to work as a community decision only (community discussion that you started, whatever committee's decision). Ideally, we reduce the platforms to a few which still allow choices about how to participate (clickery vs tui, poll vs push/notify). More technically oriented folks will be more capable to adapt technically (than "pure users") but less willing to communicate by clicking around in a web browser. A platform analysis in this regard could support that. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
