On Wed, Apr 26, 2023 at 7:12 AM Marshall Clow via Boost
Are you using a threaded e-mail reader? If so, do you care if discussions are changed to be flat (like Discourse)?
Yes, and Yes.
The current situation is this. For various reasons, we have no forum for the new website. And a new forum is crucial for attracting new people, as no one in their twenties or earlier wants to use a mailing list. However, we also recognize the importance of preserving the mailing list interface and threaded discussion model. After spending months of doing tests and looking at existing solutions, we have reached the conclusion that the only way to bring maximal satisfaction to the community is for us to implement our own web-based forum which supports threaded discussion and also has a mailing list interface, such that the mailing list experience is unchanged for those who still want to use it (which seems to be quite a few people). The other alternative is to do a clean break and deploy something completely new, which would be Discourse. The downside of Discourse is that it does not support threaded discussions, and because of their philosophical objection to hierarchical conversations, it most certainly never will. Check this out: https://community.lsst.org/t/understanding-and-using-discourses-flat-threadi... This rationale sounds very good on paper and it probably works for things such as support fourms. But it is poorly suited for the specific nature of the Boost mailing list where discussions can rage for months (I miss that). Enormous discussions were the bread and butter of the social experience and that needs to be revitalized. Anyway... Pros of Discourse: * Already written * Has an email interface * Can be restyled to match the site (mostly) * Probably cheaper long-term Cons of Discourse: * No threaded discussion * Written in Ruby, a dying language --- Pros of Writing It Ourselves * Uses Python, a popular language * Preserved mailing list experience * Threaded discussions * Customized to suit our needs Cons of Writing it Ourselves * More expensive long-term * Takes longer to reach feature parity * We have to maintain it Note, the C++ Alliance is covering all of the expenses for development so the expense issue is not of particular importance, our priority is on getting things done perfectly for users even if it costs a bit more.