Thanks for engaging with me on this, @Stephen.
I think this is very community specific
I agree. That’s why I propose that it be controlled by a settings checkbox (whether by re-using one of the existing ones relating to not permitting duplicate titles or adding a new one).
What value is there in having a smaller number of much longer topics?
As background, on our Discourse site, we have a “Notifications” category, each of whose subcategories receives mails that are sent by scripts when certain events occur (e.g., testing failures, new issues filed, new Stack Overflow questions posted, new mentions of our project on discussion sites, etc.). These categories are designed to permit community members to track and discuss particular types of events that they may be interested in.
In some cases, the mails generated by our scripts have predictable, deterministic subject lines by design, such as “linux64 testing”. For example, if we have a new failure in our linux64 testing on August 15th, that generates a mail. If additional failures creep in on August 16th, that generates a second mail with the same subject line. Then if all the failures are resolved on August 17th, a third mail with the same subject line is generated indicating that resolution. Then if we have new failures on August 31st, we generate a fourth mail with the same subject line, and a fifth when the failure is resolved.
With the current site behavior, each of these mails generates a brand-new topic named “linux64 testing” with no linkage or relationship between them, making it difficult for humans to correlate the events or decide which of the five topics they should use for follow-up discussion about the failures. Whereas what we’d like is for all five mails (and any user discussion that transpires on them) to appear as posts within a single topic so that a developer can look at all testing failures in a given configuration within a single topic, organized chronologically.
Another impact of the current Discourse behavior is that someone who is receiving email notifications for the category or topic in question sees five unrelated threads in their inbox named “linux64 testing”. Whereas if Discourse were to merge these into a single topic, that person would see all the “linux64 testing” posts associated as a single thread within their mail reader, making it far easier to navigate and much more like any traditional conversation.
We run several dozen testing configurations each night, each of which has a unique subject line when failures occur, so the current situation results in something of a sprawling mess which is hard to navigate, with a distinct, shallow topic per mail, all interspersed chronologically. Whereas, our ideal would be for the “Notifications.Tests” category to show a single topic per configuration which stores all human or script-generated posts about that configuration chronologically, as determined by that unique subject line.
[This testing category isn’t currently publicly visible on our site @Stephen, but if you’d like to see what it looks like and feel the pain firsthand, I’d be happy to temporarily grant you read access to it…just let me know.]
For communities such as meta this would mean that any user who emails in with ‘problems configuring mailgun’ will continue to be notified of updates months or years after solving their issue.
I agree that this choice may not be as sensible for a community as large and long-lived as meta that doesn’t have a need for aggregating mail-generated posts into a single topic as we do. So you probably wouldn’t want to opt into such a feature if it existed. (And maybe over time, a site like ours wouldn’t want it either for the same reasons, in which case I think the ideal would be to be able to apply the checkbox on a per-category basis, but I didn’t want to ask for too much when I believe that a single site-wide setting would suffice for us at present).
That said, even if a site like ours were to opt into such a feature, and the original poster of the ‘problems configuring mailgun’ topic was annoyed by subsequent posts that shared the same subject line, presumably they could unsubscribe from the topic in order to avoid continuing to receive updates if/when someone else uses the same subject line (or simply adds another post to the given topic via the web interface)?
[That said, I expect that most human users will post via the website, so imagine this feature having a bigger impact on script-generated posts than human-generated ones]