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