Required disclosure: Mailman dev, and my sympathies are with the list advocates for this channel both for that reason, and for more objective ones. I don't really argue against a move to Discourse here, but I do know a bit about the problem space, and I'd like to discuss *some* aspects here. I expect it's clear which I prefer, but there are a lot of arguments "for" that I don't deal with. Dominik 'Rathann' Mierzejewski writes: >>>>> Gerald B. Cox writes: > > Regardless, as I mentioned above, if they have a bug, then it > > should be reported for them to address. > > I wouldn't call it a bug, just bad UX for a minority(?) target > audience. I'm pretty sure the Discourse developers would concede that bad UX for email users is undesirable. I'm *not* sure they would concede that it's bad UX. We know how to render HTML to plain text, to RTF, and so on; Discourse deliberately chose not to do so, but rather chose a format of their own or perhaps some existing format (this is the first I've heard of BBcode, so I can't judge). Thus, I doubt that reporting an issue against Discourse's email functionality would get action any time soon from the developers, and might get a lot of pushback. Given that support from Red Hat/Fedora community for Mailman development has decreased dramatically, I don't see why they would want to pick up responsibility for patching up Discourse instead. So I see years of annoyance for those who have really effective email workflows, being constrained to Discourse's. I suspect that the number of people who really want email is at least as big as those who really want a forum, and they probably contribute more code and admin (which are typically communication-intensive, multicast activities), though forum-oriented users may contribute greatly in other ways (user support has been mentioned, and I wouldn't be surprised if that's easier both for the OP and responders in forum format -- synchronous communication does a lot of work to avoid redundancy, and editing out mistaken information is a real feature for user support). And I suppose there are a lot of people in the middle who don't care much either way (ignoring costs of moving to a new channel, which are significant in the short run but not really in the long run IMO), probably a majority. Gerald's personal anecdotes suggest that people who are weakly attached to the channel (jumping into threads in the middle, signing up for their one issue, etc) are going to find the forum format more convenient. I find his discussion persuasive on that, as I have no problem with the forum format when I have a drive-by interest in some channel. This is *not* a put-down, it's simply a statement that a certain group of users would probably be happier with a forum. (I'm not sure user support is a goal of this channel, but I've seen many threads devoted to issues of system configuration that have zero likelihood of inducing development of Fedora.) > > Mailing list mode has been out for several years now - seems to > > me if this were a pervasive issue with a published standardize > > solution, they should take care of it. Email doesn't have a standardized solution or standardized format for content. That's why people like HTML email -- it's a quasi-standard mess that browsers and browser-derived messaging clients have huge code bases for handling, and 25 years on have gotten pretty good at it. Most clients' outgoing messages now are pretty close to HTML 5 conformant, but there's still a huge mismatch with "traditional" email clients because email standards use a different mechanism from HTML for embedding objects in the data stream. (That may not be a big problem with Discourse depending on how it handles such media, and how the lists are configured.) The standards that have been referred to are SMTP (RFC 5321, which basically requires that if you accept a connection at the TCP level, you should say you're refusing to accept mail rather than dropping it silently), the Internet message format (RFC 5322, which basically defines email as an ASCII text stream divided into a header containing various metadata and a body), and the Multimedia Mail Extensions (MIME, with a plethora of RFCs starting with the 2045-2049 series) which define ways to encode non-ASCII data (both text and non-text), ways to include non-text data, and ways to mix various media, in a message body. Among the latter is the multipart/alternative body part (defined in RFC 2046, IIRC), which allows catering to various user agents, and does require that the alternatives have as close to the same semantics as the media make possible. This provision of RFC 2046 is violated by a lot of HTML-oriented clients, which embed attachments in the HTML where they can't easily be accessed by non-HTML clients, or even provide a plain text alternative that says "use an HTML client", rather than a plain text version of the HTML content. I don't think that's a problem with Discourse, but I don't understand why they wouldn't use the traditional email conventions for quoted material in the body of a text/plain part. The fact that they deliberately did something different suggests that they think they know better than we do. :-( To the extent that HTML email is the source of posts to Discourse, there's not much that the software can do much about these differences (without incorporating the huge body of code mentioned above). MIME on the other hand can be handled with a reasonable amount of code. > I suspect the kind of people that would be bothered by Discourse's > mailing list mode deficiencies simply stop using it as soon as they > find out how bad it is for them. I don't blame them. I've heard reports of that in multiple communities now (this one, Python, and Emacs, and gratuitously on Mailman lists[1]). That said, while I think the great majority of list users would be at least temporarily inconvenienced by a switch to forum software, those who really care either way are likely to be minorities. My suspicion is that those who really dislike the forum format contribute a lot more to the community than those who really like it. It's anecdotal, but in all cases where I've seen suggestions to convert MLs to forums, the strongest proponents are people whose main current contribution to discussion is to advocate a forum, while people who do a lot of day-to-day work generally resist, some very strongly. Of course it's possible that for proponents forums are so efficient that it's worth dropping everything else to advocate them. OT, but I can't resist. > > Again, I use gmail and things look perfectly fine for me. Speak of bad UX for a minority audience, and GMail will be presented as an example of perfectly fine. :-( > And personally, I recommend against Gmail because it's known to > accept and silently drop some e-mail, which is against RFC5321 > section 6.1.-6.2. I've talked to some people who should be in the know (via DMARC dev channels) about that. They claim that they do it only for for identified bad actors, where they're 99% sure it's spam and 99% sure that an SMTP "administrative denial" will result in backscatter, as the return path goes through, uh, less-than-diligent intermediate MXes. As a mailing list owner, I think that's reasonable, though a real problem for the sender and receiver in the 0.01% of cases where they get it wrong. They probably get it wrong thousands of times a day, they process an awful lot of email.... OTOH, if some list's MTA gets banned by Yahoo! or Microsoft for backscatter, that's often a couple thousand emails per day that don't go through. YMMV, of course. I'm just presenting the strongest argument I know in favor of the practice. It's also evidence that it won't go away (and I suspect other large freemail providers do the same). Footnotes: [1] It's off-topic, and we try to keep badmouthing alternative paradigms to a minimum. ;-) _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
