A recent change to discourse removed the bump when editing the last (or first post) in a thread.
This was a feature we had come to rely on and there is no viable method of imitating this for non staff ranked members.
We benefitted from this functionality primarily to bump posts that were announcement style posts or posts that intentionally received no / few replies.
These were genuine updates to a topic where an edit was removing now obsolete information. The post rising back to the top of the latest feed was very desirable as it informed all members that there had been a change.
Yes, this could be imitated to a degree with a chain of replies, but over time, this will become cumbersome for the user to gather what was being communicated (imagine 10 replies with changes, for example). It was much cleaner to edit the original post / most recent post and have the topic rise up the latest feed.
I appreciate that there will be people on both sides of this, but this was a long standing precedent in Discourse for many years, and adding an option to restore the previous functionality to Discourse will please everyone. Perhaps the optionality can be expanded over time to finely control what activity on a post constitutes it rising up the latest feed.
A link to the bug thread where this change was discussed is below:
I can’t vote on this as I’ve not yet achieved the required Trust level but I would also like to echo my approval to make this change, if it’s possible
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.
I don’t have a strong opinion about this feature, but a related problem is that I like to auto bump posts and then remove the message about it being bumped, but that isn’t possible anymore. When I delete the bump message, the message sinks back down to where it was before. If editing a message would bump it without creating a “last bumped 1 day ago” then it would be useful.
(I’d prefer to be able to bump it, delete the bump message, and still have the post remain on the front page unless I manually do “reset bump date”.)
I’m afraid that we don’t have any current plans to revert the change / restore bumps on all edits. I understand that’s not the answer you want to hear, though, and we’ll continue to monitor this topic and consider how we can better support your use cases in the future.
The fact that something doesn’t happen anymore isn’t either. Is there any data on how many administrators have noticed that Discourse’s behavior has changed? I understand your argument that there were repeated requests on how to prevent bumps. It’s obvious admins notice a bump they don’t want. But if a topic isn’t bumped, you don’t even notice that it hasn’t been bumped, even though you would have liked it to be. So it seems less likely that people ask for that.
Also, recently the fact that spam is more easily noticed if the topic is bumped came up again. I wonder why this is relevant in the now rather limited case where a post should be bumped during editing. But it didn’t matter when changing the default for most of the posts. Why does a first post that is a wiki need more spam protection that a last post in a topic that is a wiki?
As I have said many times before, I understand the advantages, but there doesn’t seem to be much interest in finding solutions to the disadvantages. It’s no use if there’s a replacement for the current workflows after a year or so. I’ll have to find a new solution now because there is not much time left where there is a supported version of Discourse where an edit of the last post moves the topic to the top.
Wiki and docs posts are bumped based on the theory that edits to those posts are generally of interest.
As for spam protection, the theory now is that these bumps never really provided much extra coverage. Most posts are not the last post, and edits to them were never surfaced by bumps anyway. So if spam via edits is a problem, it needs a different solution no matter what. This was never really an effective solution to that problem.
I think there’s a misunderstanding. My point wasn’t about why wiki posts in the first post are bumped. I was talking about the reasoning behind restricting the no-bump API parameter, as mentioned in the GitHub comment:
Should this be restricted to staff API keys? I don’t think we want regular users to be able to bypass bumping (it would allow them to inject spam into topics without bringing them to people’s attention).
If spam was truly the concern, then this restriction should apply consistently, not just in the few remaining cases where bumping happens. That’s what surprised me: the reasoning cites spam as a problem here, but bumping isn’t meant as a spam-protection mechanism in, for example, wikis that are the last post in a topic.
I do appreciate that wiki posts are bumped on updates (though the UX of being taken to the bottom of the topic while the bump reason is the first post is still confusing).
My point is just highlighting this apparent inconsistency regarding spam.