I noticed on my forum and also on Meta that topics are bumped when the title is edited. For me this is quite confusing because the topic appears at the top of the topic list, so I expect something new, but it’s very difficult to spot the change because usually I am taken to the latest post while the edit happened on the first post.
I noticed you changed that edits on the last post no longer bump the topic. Is it possible that the fact that edits of the topic title now trigger a bump is a side effect of that change?
Thanks Moin, I see now…since I’m no longer checking if it’s the last post, I need to check if only topic OP stuff is changing and bypass the bump if so.
I have a fix here:
I was able to reproduce with category changes but not tag changes.
Hmm okay I think it’s valid for the title not to bump the topic, but I think the category + tag edit based bumps are complicated by these two settings:
These control whether a topic is bumped when editing the OP:
But, these settings also control whether an actual notification is sent when changing category/tags so it’s a bit complex to detangle. Will discuss this internally a bit and loop back.
Before you removed the bump on edits, title, category, and tag changes only bumped the topic when it had no replies. Otherwise, no bump happened because it wasn’t the last post. Do you plan to restore that, or do you want to block these bumps too?
I also wondered why a category edit on my test topic didn’t bump the topic now. I have the impression it’s because of the editing grace period. After waiting for 5 minutes, editing the category bumped the topic again.
I am still confused about what causes a bump now, apart from a reply. Understanding that could help me find solutions for how I notice edits where the user followed the Discourse instructions to edit their post instead of posting consecutive replies[1]. I think it might be a frustrating experience when the system tells you to edit your post instead of replying, you do that, and no one notices. I also asked for help on how edits on wikis can be tracked now.
Happy birthday
“No more than %{count} consecutive replies are allowed. Please edit your previous reply, or wait for someone to reply to you.” ↩︎
Er wordt hier nog een aanpassing gedaan om ervoor te zorgen dat de wijziging van de titel, tags en categorie niet de bump veroorzaakt. Zit maar even stil…
For my use, editing a topic to bump it to the top of the latest feed was a feature, not a bug. I relied on this behaviour to communicate to users that there had been a change in topics.
The last post being edited, causing the bump, is probably relied on by many to lift posts up the latest feed and bring items to people’s attention.
Communicating the change by replying to a post is not as efficient as once a user has read post 1, bumping with a reply will take them to the reply, if the edit is in post 1 (which it always is in my case), they won’t see it.
If there were a setting available to toggle this change, people could really tweak this to their liking, rather than flipping a long established feature on its head
I don’t always want to bump a topic edit, but sometimes I’d like to make a timely change more obvious. Auto-bump is an option, but not quite what I’d like:
It’s tempting to suggest a “Now” option on the auto-bump menu, but the auto-bump notice also indicates an automatic – not deliberate – bump, which is a different signal:
I’ve sometimes wished for a topic bump-on-edit option that could be enabled for roles or trust levels. I imagine buttons for “Save Edit” and “Save Edit and Bump”:
…and the resulting notice might say Topic edited by staff or similar.
Can you explain how you used bumping and in which cases it was helpful for you?
I still can’t decide whether I prefer the new or the old behavior.
For example, I liked the fact that changes to the title, category, and tags bumped the topic back to the top if it hadn’t received any replies yet. This allowed users who were mainly looking at these categories or tags to notice them and reply. It also helped me a lot here in the forum to learn how the moderators use categories and tags. Topics were often moved before they were answered.
I also like the approach that Discourse’s settings force you to add information instead of writing another post. However, this only works if it moves the topic back to the top. So it’s currently in a weird stage where users are blocked from writing more than 3 posts in a row, but editing won’t bump their topic so it’s likely no one will notice.
I also thought having a wiki topic without replies so that changes there bump the topic, and when you click on the topic, you immediately land on the edited post was a good way to handle this.
Even though wikis now bump again, they don’t do so only when they are the last post. I find this confusing because I open a topic that has been moved to the top, but where I land (at the last post), it is not clear why.
However, I like that small changes do not cause a bump. I have noticed that I have been editing more to add small details that I would not have added before because I considered them too unimportant for a bump.
You have hit the nail on the head with your points
Posts that intentionally receive no replies used to go up to the top of the latest feed if there was an edit - It could be an announcement where information has changed for example
For genuine updates to a topic where an edit removes now obsolete information, rising back to the top of the latest feed was very desirable. It could be done 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. Adding an option to restore the previous long standing 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.
For me, the way its been for years is optimal and I’ve come to rely on it.
This change has caught me off guard and while users can alter post dates to raise their topic back to the top post edit, why not just have it happen as it always has before, automatically?
It would be very helpful if this bump on the last post edit was returned to the product, as in one move, more than a decade-long precedent has been overturned, which has been painful for us.
Users who are Staff can resolve this by moving the date but other users cannot. I think either an option should come in to allow bump on edit or the previous behaviour should be restored
We don’t intend to revert this change. I discussed internally, and for your use cases, you can either:
Make the OP of the topic a wiki post. Edits to wiki posts will still bump the topic.
Make a new post in the topic when important edits are made.
Also, using the Auto-Bump Topic timer should work as well. In future, we may introduce additional config options to allow for finer per-category control on topic bumping.
Maybe not every post that gets updated by TL4s and staff should be a wiki which most users of the forum can edit.
Also bumping when the OP is a wiki and edited doesn’t help for topics with more than one wiki post in them or where the wiki is not the first post. For example in a topic for things that are collected during a month, and then you create a new wiki as a reply for the next month. This worked very well as the wiki for the current month was the most recent post, so the topic was bumped.
The timer adds annoying small action posts to the topic, which you cannot delete, because that results in the bump date to be reset again.
I understand that you don’t want to revert the changes, and I can see the advantages in a limited area (small improvements to your own posts), but then perhaps we need to look at how to ensure that the workflows established in forums continue to work.
Staff uses reset bump date when they see a topic in latest that has been unnecessarily bumped, somehow worked better than staff manually bumping topics that should have been bumped but weren’t. How do they notice these?
As Martin said, at this point we are not reverting this change.
There are three workarounds:
Making the OP a wiki
Using the Auto-Bump Topic Timer
Posting a reply to explain the edit (@Moin, this is the suggested workaround in the cases you describe when something shouldn’t be a wiki and you don’t want to use the Auto-Bump Topic Timer)
We also continue to bump Docs Categories topics when they are edited.
I understand these workarounds are not ideal for all use cases. As you encounter specific use cases where none of these option are viable, please share those with us in a Feature topic.
@lindsey@martin@pmusaraj Understood that you aren’t looking to revert this change. Is it a possible consideration that an option could be introduced to restore this functionality? So users can choose?
Failing this, is it technically possible to create a plugin that allows bumps on edit? I’m not asking you to make one, but asking if, in principle, it is possible, so that I don’t go down a dead end here trying to restore this behaviour that I’ve come to rely on
