There is a lot on our plates but I do want to come back to this.
We’d be very interested in this.
The lack of context in our e-mails is driving us crazy, and our users!
Perhaps we could help out somehow?
Great to hear
More than happy for you to go ahead and create your own pull request - I’ve literally had zero time recently for various reasons which is a shame as I felt I’d made a decent start on it all. I’ll keep trying to plug away at it, but if you’re able to, please do go ahead and submit a PR
My solution to this is to suggest ( or set by default that users Watch categories, instead of the more obvious Mailing list mode.
https://meta.discourse.org/t/watching-a-category-perhaps-the-best-kind-of-mailing-list-mode/27507
What I like most about this, is that how the emails get formatted to users is already a part of Discourse, no additional coding required (for the email format).
We have pre-set our users to “Watch” pertinent categories because basically we have two distinct user groups within our product offering. This works well with the major exception that without context many of our users cannot follow the thread.
Based on our community there is little chance that many of our users will move away from the listserv approach, not to mention a majority of them. So, this is a high priority for us.
@codinghorror or @sam what kind of focus will this be getting and when? Via PM you mentioned to me that if there were “paying customers” this might get more attention. Is that the best way to approach it for us?
@lake54, we’d work on it ourselves but don’t have the (Ruby) experience in house AND are trying to figure out the best way to support the open-source community.
Thanks,
Brian
Count me as another.
The other problem is that when hosting my own discourse, I can do thinks like auto-watch via database triggers. I am under the assumption that there is no way to do this once I bring other discourse to you for hosting.
It would seem to me that not only are paying customers wanting this, but implementing it would allow for more discourse sites to be migrated.
Have you changed the “email posts context” number in site settings?
I do support working on this, but we have other much more urgent needs, as in, all sites have been down, etc. That’s FAR more urgent to us.
Jeff, we changed the context number several times…also with respect to
pop3 polling intermittently stopping, we actually decreased the polling
frequency to 7 mins. Both seem to be bugs that should be addressed at some
point. Good luck with the site issues, hope you work things out!
We’ve never seen POP3 polling fail on our hosted sites with the default of 5 minutes, so I suspect that is a configuration issue of some kind.
I have POP3 polling set at 1 minute. Never any issues.
I dunno @lake54 it does not seem like this issue comes up enough to be a serious problem. I do not get many customers complaining that they don’t understand the emails we send in the current format, with the context as we’ve done it for almost 2 years.
I still feel that we should included Never/Auto toggles, I am pretty much confused daily about email flow when I get emails from BBS on mobile. Its just so hard to decipher where the conversation started. Especially if I have more than one response in the stream. We send gigantic emails that requires tons of scrolling to get to next email.
I feel like this is something similar to the “missing giant blue button” on emails that @cwodtke showed us. Nobody complains about it for multiple years but there really is an underlying issue.
My call actually would be to strip context by default, just send one email per post to users, it is simple and more importantly it encourages users to visit the main site to get context thus increasing engagement which is something we are trying to optimise for.
I think it is a better and simpler default, if people want context they opt in via user profile and get what they signed up for.
The “always context” thing is not something I am excited about but we can add the option if people really want it.
Well, simpler is a default I can definitely get behind. Let’s try it and see what happens.
(One of the reasons we did this was because @eviltrout noted that Facebook always sent some context along in the email.)
I agree … people have a hard time replying and quoting appropriately in a mailing list, too. If people want to be really clear about context, they should use inline quoting. (Just like they should on a mailing list!)
Ok here is what was decided on the team call today. This will be a user pref. Three options:
-
No context whatsoever, just the post we’re notifying you about.
-
Minimal context, just the (abbreviated, if need be) post this was in reply to, and even then only if it was an intentional reply to a specific post. this will be the default
-
“Full” context, as we do it now, same exact code paths, up to 5 unread previous replies in reverse chronological sequence.
I suppose we can add this to your plate @zogstrip, no rush, next week or later is fine…
I know I am late to the discussion here guys, but I just (two days ago) received this same request from our client.
They would like the previous posts in a particular topic included in the notifications. I’m not saying I agree, but it’s their community and therefore the request is valid.
So, I am eagerly awaiting the feature and would be happy to help when it comes to testing.
Likewise, I’m unfortunately coming to this a bit later than I intended. Thanks for keeping this idea going though!
I agree with @paully21 - the community I work with who are looking to use Discourse would want to have the option of including previous posts in the notifications. Personally I don’t need this option, but as above, it’s the community that would want it, not me.
This would be useful to keep as well for our community, where we have switched from a setup with force watched categories to mentioning groups to notify people as needed. This works better but sometimes people forget and the ability to write a follow-up post with the appropriate mentions is a bonus since it sends the original post along with it.
OK, this should put this to rest at last