
Reply-To set to *me*. I don't really think this idea has legs at this point. It's been discussed before (it even has a SIG), but that ran out of steam and the move to Mailman 3 (whose archiver provides a more forum-like interface) is more or less imminent anyway, so it's kind of moot. I'm happy to deal with it off-list, but for the moment it's OT IMO.
Robert Vanden Eynde writes:
We are currently like a dozen of people talking about multiple sections of a single subject.
Isn't it easier to talk on a forum?
There's the Overload SIG for this discussion of media (currently inactive for many months). Transparency notice: Mailman dev here, bias acknowledged, some in the SIG were more sympathetic to forums, I don't claim to be representative of SIG opinion.
Am I the only one who thinks mailing list isn't easy when lots of people talking about multiple subjects?
No, you are hardly alone. However, in my experience good forum software is distinctly inferior to good mail software in high-traffic multi-threaded communications. There is very little that forum software can do that a mail client cannot.[1] The main advantages of forum software are better thread management (message ids are reliable and threads are built synchronously, but it's not much better) and server-side storage (but of course that's a SPoF). As the name of the SIG suggests, the problem is not so much that mail is such a bad medium; it's more that the traffic levels are higher than people are used to, so the bad experience of high traffic is conflated with a bad experience of using mail. (We do have one or two on the SIG who say that they do fine with high-traffic multi-threaded forums. I'm not sure how closely the use case matches the main python-* channels, excluding python-list.) The main advantage to using email is that management of multiple high-traffic streams requires smart, highly configurable clients. These have been available for mail since the late 80s. They've only gotten better since. Forums, on the other hand, are based on thin clients (ie web browsers), and so you get only the configuration the forum offers, and you have to tell the forum all about it. Of course we are hackers: all the main browsers are scriptable, the language is javascript, so we could write our own forum clients. But that's exactly what forum advocates want to avoid, at least if you call it "email". The problem for mail advocates is the flip side of that. That is, AFAIK there is no good mail software that runs in a browser (let alone a smartphone), and change of mail clients, like religions and programmer's editors, is advocated only at risk to limb and life. As mentioned above, this whole issue may become moot when the mailing lists are moved to Mailman 3 (we have some experimental Mailman 3 lists; ETA of a general migration is 6--18 months, at a slightly- informed guess), which has a forum-like interface to the archives called "HyperKitty". HyperKitty is not a rival to Discourse, at least not in the near future[2], but it's already pretty good.
A forum (or just few "issues" thread on github) is where we could have different thread in parallel, in my messages I end up with like 10 comments not all related, in a forum we could talk about everything and it would still be organized by subjects.
Also, it's more interactive than email on a global list, people can talk to each other in parallel, if I want to answer about a mail that was 10 mail ago, it gets quickly messy.
I have no idea why any of those things would be unmanageable in email, unless you have disabled threading in your client, or your client doesn't allow you to kill (or collapse) threads of no interest to you.
We could all discuss on a gist or some "Issues" thread on GitHub.
Those are non-starters. *You* can already do that, but very few of the committers will follow. We already have an issue tracker for very focussed discussion. This works because people actually working on an issue are frequently spending hours on it and related work, so a minute or so spent finding the appropriate issue is small overhead. The overhead would be substantially greater if you had to regularly scan all recent issues to see if any are of interest to you. Trackers are not very good at switching threads (issues), so even if you turn on push notification for new issues, there will be substantial overhead in following more than a tiny number of threads. The kinds of things that are discussed on the mailing lists generally need to be broadcast, at least at first, and (assuming a decent mail client) threads of no interest can easily be suppressed in email. That's what the committers do, mostly. (Some just live with the firehose.) Note, that's not to say a *forum* is a non-starter. I guess that good forum software provides similar features. Some senior developers have expressed interest in moving to a forum-based discussion. Just that most of the committers have broad interest in the discussion, so are going to get their news from whatever the main channels are: we need to have a fairly small number of them, and we do *not* want them split across multiple media. Finally, speaking of "split across media", any serious proposal for change of medium will need to deal with the (voluminous) mail archives. This may not be difficult ("just provide a link"), but then again it may not be that easy. I have given no thought to it yet, and I don't think the forum advocates have either. Bottom line: in the end at least one PEP (I would guess two or three) will be needed to make a major change to the workflow like this, unless it's done in the context of a hybrid Mailman + forum system like Mailman 3 including HyperKitty. Once again, I admit that I strongly prefer mailing lists. However, I also believe that it's not bias to suggest that it's volume of communication, not the medium, that is the problem here. At least in principle mail is fully capable of carrying the load. In practice, deficient mail clients (I'm looking at you, GMail and Outlook and anything on a handheld) are all over the place. In the end we'll need to balance the costs of moving (which includes the preferences of those who "just" like email better as well as setup and migration of archives) against the benefits (mostly the preferences of those who have learned to use forums very efficiently). Footnotes: [1] To my knowledge. I'm willing to be educated. [2] And it won't solve the asynchronicity of SMTP messaging. Mailman will still be primarily a mail-based system, at least at first.