For context, I’m a maintainer on the scikit-learn side, and a casual observer here who every now and then adds something to the conversations.
For that, I use email and not the discuss interface. While it was being discussed to switch to discuss on the mailing list, there were worries about “email only” settings allowing users to only interact with emails rather than having to come to the discuss interface.
That issue was solved, but the titles used in emails are very long and a large part of it is uninteresting boilerplate which could be removed or at best moved to the end of the title rather than having it start with it.
As an example, this is how I see a few conversations on my phone (screenshot)
This means I would have to open the conversations first to see what they’re about, and then discard, rather than being able to quickly see what could be relevant to me.
It would be nice if we could remove the boilerplate from the beginning of the email titles.
Big +1. Also, for me, replies to a post (and all further discussion) seem to fall under a different email thread to the original post. I don’t see why they shouldn’t be combined into a single thread.
You’ll probably have to change the category names to be shorter to get any benefit, if you care about the categories showing up in the titles (I, for one, probably don’t).
%{optional_re}[scipy] %{topic_title}
The %{optional_re} might help some email clients with proper threading by Subject, but it might not. It’s not clear to me how the In-Reply-To header that Discourse uses for the reply emails is supposed to help email clients link them up with the first post. It seems to only work to thread the subsequent emails together (separate from the first post). For example, the reply messages here have
It would be great if Discourse allowed subject customization per category. Having to do this as a global setting, without any logic and few %{...} options makes it tricky. I can rename the top-level categories, and I can replace [Scientific Python ...] with [SP], which should help a bit.
Yeah, I have no idea what they’re trying to do with that header. It’s supposed to refer to the Message-ID of the email it’s replying to. But that seems to be something from Amazon SES (and likely not available to Discourse when it crafts the In-Reply-To).
Okay, it’s our choice of Amazon SES, which clobbers the Message-ID, that is the root cause here. Discourse sets a reasonable Message-ID which would work with other providers.
It looks like the setting find_related_post_with_key was added a long time ago to fix that. Seems to be on by default currently, so I don’t know what’s up.
