As I said before, I also miss bumping topics when there is a meaningful edit.
I use rss-polling to be notified about maintenance on my forum by the RSS feed of https://status.discourse.org/. The topic is created when the maintenance starts, and it was bumped on the edit that announces it’s over. This bump is now missing, and I don’t want the topics to be wikis, as no user should edit them, nor do I want them to be docs. So, the current workarounds don’t help.
In one forum, we have a gallery topic showcasing the users’ projects in addition to the individual topics in which users present their projects. This topic is very helpful for gathering inspiration. We add an image from the presentation topic and a link to it to this gallery topic. Too many images in a post have led to performance problems and also make editing more difficult. So, we create a new post for every 10 projects. The bump when editing when the 2nd or 9th project was added was helpful. It is helpful for users to notice the update, and it was especially helpful for those who add projects manually to the topic. Thanks to the activity date, I could immediately see if someone else had already added the project. Now, each of us needs to open the topic to check this.
There are also other topics that work similarly: topics that serve as a retrospective overview of changes/activity within a month and where the latest post about the current month is updated a few times. This worked really well because changes to the last post bumped the topic. Posting each change individually would detract from the clarity of the monthly bundled entries and would still mean updates to existing entries are easily missed. A new topic each month for a few entries feels like too much, and it would also mean users would need to set up their notifications again each month, or we would need a whole subcategory that allows them to set up their default notification status.
I also enjoyed that category and tag changes on unanswered topics bumped it. Most often I use a (filtered) list of latest topics. And if a topic had a poorly chosen title or was in the wrong category, I might not click on it. If someone improves this information, I might realize that I can help after all. That’s why it was helpful when such a change caused the topic to move back above my read line.
Also, it was helpful to learn about categories and tags. I have often learned about new tags because they were added on a new topic or about the detailed difference between categories based on topics that were moved by a moderator. I sometimes even asked why, because I think that the ability to move topics to other categories also comes with the responsibility of knowing the difference between them.
I also like the approach that Discourse’s settings force you to add information instead of writing another post.
To quote the pop up message:
However, this only makes sense if others notice that you edited your post to add further information. An example I came across a few times already on Meta are updates on a post after a pull request was merged. Adding that information into the post doesn’t notify those who already read the post, and those who haven’t can easily tell by the badge in the onebox.
For me, it doesn’t make sense that the setting that blocks more than three consecutive replies by a user is still active and suggests edits as a solution, when these edits unfortunately no longer have the effect they once had.