Being able to set this as a global default would be very useful for Mozilla.
I’m not sure you need to be sure, considering it already exists! (Which I discovered when looking for a place it would be sensible to place such a button)
Since neither of us knew it was there, maybe there’s a need to better expose it?
I’m not sure I agree with any of your hypothesis, at least as a reflection of the current state of Discourse. In terms of where we want to go, I definitely agree with the latter half but strongly disagree with the first half.
Not being able to only hear about a particular subsection of the forum, through the web interface, would completely break Discourse for use within Mozilla. I reckon it would completely break Discourse generally.
Eliminating Tracking wouldn’t be much of a loss, since it’s rather useless at the moment (although I would say a better option would be to make it work properly). But Watching is essential for receiving notifications. In fact, your proposal seems to eliminate notifications altogether.
In the proposal, I’m only suggesting that these changes are made for categories not topics:
There would be no more global “mailing list” mode, only the category one, so there would no longer be any need to mute a category in combination with mailing list mode. You would just opt in to mailing list mode on the categories you want to.
Again, just to be clear, the suggestion isn’t to remove in-app notifications altogether. It’s only to eliminate them at the category-level.
Are you saying that you or other users on your site actually do rely on getting in-app notifications for each post in particular categories?
Without category-level watching, there would be no method of distinguishing topics in categories you’re interested in from those in categories you’re not, in the web interface.
I don’t think we want to move to emails being so decoupled from the “in-app” experience, hence why I proposed allowing users to be emailed for tracked topics (along with making tracking a category actually track the topics within, otherwise it’s a bit useless). This way users can choose whether email is just a push notification mechanism (and therefore only reflective of their in-app notifications), or whether it’s a mailing list mechanism (and therefore reflective of everything they’ve expressed an interest in on Discourse).
This is EXACTLY the functionality I require for a community I’m trying to get moved to Discourse. I was coming here to post the same thing but it couldn’t have been said better, how can we get this working?
I agree that there fundamental differences between the web interface and the email interface via mailing list mode but it should be possible to apply mailing list mode to only specific categories.
I’ll use the lists.samba.org mailing lists as an example of “GNU mailman” lists and what I would expect a migration to Discourse to work like if they decided to switch to using it in the future:
Each list would become a category in Discourse
Each category would function as an independent mailing list via mailing list mode.
The “GNU mailman” install at lists.samba.org shows 19 total lists.
Right now the only one I’m subscribed to is samba-announce which is a “Low volume list for Samba announcements” that includes announcements of when new releases of samba are released (which is why I’m subscribed to it).
If they switched to using Discourse then I would expect that mailing list mode works per-category to have the same type of mailing list experience I had before the switch to Discourse.
So in my opinion, the mailing list mode should be a per category feature instead of every message as core functionality to match the expectations of users including me that are used to the mailing list functionality provided by software like “GNU mailman”.
I’m not Sam, but most groups who are moving from mailman (or listproc?) have many lists, not one. I’m working with a group now (that I think will become a customer when they’re convinced that the 1990s are over) that needs to be slowly weaned from mailing lists and per category mailing lists would help.
I’ve got a use case for mailing list mode per category: urgency.
I have two sites, one of which is a community housing association. When we have an onsite ‘incident’ like a burglary, it is assigned to a category called ‘Incident’. It would be nice to have this category mail everyone with urgency, whilst all other posts can be served by a less urgent Digest.
The difference is that by watching a category, all topics in the category become watched in the Discourse and notifications appear for them.
The mailing list mode is solely about emailing topics in a category without affecting notifications.
If I’m looking at a category then I will either look at the category manually on the Discourse interface or use mailing list mode but I don’t want the excess notifications caused by watching a category.
My watched topics section in Discourse becomes a bit of mess when every topic in a category is watched as then I can’t find the topics that I primarily want notifications from.
What if you were able to disable in-app notifications for Watching? (Or for any content that has already been sent by email, as also suggested earlier here).
Because I want the in-app notifications for my watched topics and have per-category emails.
This is no reason both features can’t be used at the same time.
Watching only specific topics with notifications on the web site and getting all emails for a category.
I think it’s fine to consider “mailing list mode per category” as an enhancement of our existing mailing list type support. I am still curious to hear what @sam thinks about it.
By default when you enable mailing list mode “all categories” are included, if you don’t like that you can clear All and select the specific categories.
