I'm open to all of those suggestions as well as committing to design and CSS work for them. I would need a web dev to help me though; I'm not great with Django.
Please note, the reason Hyperkitty didn't cause this sort of thread or honestly any sort of drama or controversy when it was deployed is because it required no current users to change anything about their workflow, with one small exception - mm3 didn't come out w topic support which was used on the packagers list. (I don't believe that's an issue anymore.) The whole point of the design was to enable a new group of would be contributors be able to participate alongside the folks already there, so that everyone could participate together. Existing ML users never need to use Hyperkitty if they don't want to, and yet, users new to the project can start reading and participating in threads right away w no mail client config and never receiving a single email if they so desire. I believe quite strongly (and have from the start when I first heard of the project) that Discourse's basic UX model is fundamentally flawed. If we deploy discourse and roll it out, we *may* get new users, but as noted in this thread, we will lose existing ones. Participating in upstream effort on Discourse, improving it, etc is foolish bc the fundamental model is broken. When some people think of email, they think of mutt or thunderbird, annoying client config, setting up procmail or fetchmail or whatever other complex elaborate tools many of the ppl reading this use. Email is just a basic standard. Discourse does not follow that standard. There is no reason a social media timeline like experience for the teenagers is not possible using email as the underlying system. Jabber never really took off, except Google Hangouts and FB messenger both used it (no idea if they still do.) The reason our open standards like email and xmpp are dying off is bc the primary biz model of the companies that used them relies on getting eyes on ads, and scanning content in ways that mean giving users a choice of client that works best for their needs is off the table. Basically dont confuse the front end youre used to with the underlying tech. I think it's a better idea to use a tool based on open standards, that allows users to use the client experience that works best for them. If you try to force everyone down one road it won't work. ~m _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
