The sign-up process for Discourse is more complicated than the sign-up process for a Mailman list.
It has been said many times that for every extra field or step people must take completing a form, half the people who start the form will not get to the end of it.
A Mailman list only asks somebody for their email address and then it auto-generates their password. There is no need to choose a username or fill in any other fields.
For communities who run Discourse but want to offer a Mailman-like mailing list experience, users have to manually go into the preferences to enable the email mode of Discourse.
It would be nice to have a single sign-up page where people only see the following:
enter your email address
choose the sections you want to be subscribed to (much like choosing which lists to join on a Mailman server)
and everything else will automatically be set up in Discourse email-mode.
This is a good idea for mailing list centric sites. I believe @mcwumbly has proposed similar ideas in the past.
It also might make sense for sites with strongly segregated categories, to show a list of categories at signup and more or less force the user to make a decision about which categories they want to see, or not.
I think Discourse could definitely stand to offer a smoother experience for people wanting to sign up (to the extent of being able to sign up entirely via e-mail, for example). Where it would go on the priority list is a different question, but I wouldnât feel strongly enough about it to personally stand in front of @codinghorrorâs house carrying a sign or anything.
This would be the root of our problems as well, and itâs a use case which Mailman (and Google Groups) cater incredibly well to, and Discourse falls a little short on.
While there are a significant number of users who do want Discourse to behave Mailman-like, we canât assume that everyone does, especially newer contributors who havenât been exposed to Mozillaâs mailing list culture.
So the question is: how do we expose something like this to users who do want to party like itâs 1999, without confusing those who donât.
Offering an invitation link not tied to an email but configured for setting groups would help.
The link could be used to onboard users for different groups or transition users from other platformsâone click and hit the social media account button (or add username/email).
Site admins could also set up an email autoresponder with that link in the response so users could join âby email.â
With communications technology it is not really helpful to focus on time like that.
Metcalfeâs law tells us that the value of a communications network is proportional to the number of users squared.
If you have a Discourse site with 50 users, the value is 50^2 = 2,500
Now take the Metcalfe value of all the free software communities happily communicating over Mailman and SmartList using their email addresses. If you assume there are 50,000 participants in the universe of loosely coupled email lists and communities, then the Metcalfe value = 50,000^2 = 2,500,000,000.
A new community joining this loose network actually becomes part of that: in fact, if you add the 50 people from that Discourse example to the other 50,000 then you get 50,050^2 = 2,505,002,500. Notice that this is much bigger than the sum of two squares: communities gain a lot more by working together. This also makes the community more robust against competition from closed, proprietary alternatives.
If Discourse plays happily in the world of email then it also becomes part of that success story.
Another unpleasant thing I noticed in emails from another Discourse site is that the URLs in the emails donât go back to the domain of the Discourse site, they all seem to go through some unrelated redirection service. That made me more suspicious of using Discourse or communities who rely on it.
Is that a site hosted by us, or is it self-hosted and perhaps using an e-mail service provider such as mailgun, sendgrid, etc? Iâve noticed some ESPs like to play stupid click-tracking games, and it shits me sideways, but thereâs not a whole lot that can be done, because e-mail deliverability is a hellstorm that no small site operator should have to deal with, so third-party ESPs are the least-worst remaining option. If youâre seeing such click-tracking shenanigans from a site hosted by us, please let me know so I can work out whatâs going on and BURN IT WITH FIRE.
Any serious Internet user who encounters a Discourse site for the first time and sees this click tracking is going to be suspicious and Discourse and/or the community running it are going to look bad.
I donât think it is an either/or situation, I feel you can extend the email capabilities or make it customizable without denying people the ability to run a traditional forum in the style of a closed and autocratic walled garden if that is their dream.
The fact that you offer email support and call it a âMailing list modeâ has tempted a lot of communities to try Discourse instead of a basic email list service, believing they will get everything Mailman offers plus web access. Once they get up and running they slowly discover that the email support is not quite the same though. Iâm not suggesting you are deliberately drawing people in with the offer of email support, but they are being attracted to Discourse on that basis.
Once theyâve invested time in setting it up and they have content in the platform it is then very hard for them to migrate to a full mailing list service and it would seem more logical to offer them some buttons they can click to simply make Discourse act more like mailing list servers.
The joys of open source software. Do you really think weâd be serving the Internet community better by taking Discourse proprietary, so we can control how e-mail is sent? Any âserious Internet userâ who canât recognise shitty ESP click-tracking links needs to have their seriousness level re-evaluated.
Well, yes, thatâs the goal. Finite resources and all that, though. Care to contribute?
No, I was simply making an observation about the impression it creates. I agree it is not the intention of the developers for it to look like this.
Most of my own expertise is in real-time communications, so the best way I could probably contribute would be helping somebody develop a WebRTC plugin.
In any case, before anybody has a crack at developing these improvements, it is useful to discuss them and agree what the team would like to support in the long term, that is why I raise a lot of ideas before any code is written.