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? https://github.com/discourse/discourse/pull/34681
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.
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.” ↩︎
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
TL4(팀 리더 4급)와 스태프가 업데이트하는 모든 게시물을 대부분의 포럼 사용자가 수정할 수 있는 위키로 만드는 것이 적절하지 않을 수 있습니다.
또한 첫 게시물이 위키인 경우 수정 시에도 토픽이 위로 올라가는 기능은, 위키 게시물이 하나 이상 포함된 토픽이나 위키가 첫 번째 게시물이 아닌 경우에도 도움이 되지 않습니다. 예를 들어 한 달 동안 수집된 내용을 다루는 토픽에서 다음 달을 위해 새 위키를 답글로 생성하는 경우를 생각해 볼 수 있습니다. 이전에는 현재 달의 위키가 가장 최근 게시물이었기 때문에 토픽이 자동으로 위로 올라가는 방식으로 매우 잘 작동했습니다.
타이머는 토픽에 삭제할 수 없는 번거로운 작은 활동 게시물을 추가합니다. 이를 삭제하면 다시 한번 위로 올림(bump) 날짜가 초기화되기 때문입니다.
변경 사항을 되돌리고 싶지 않다는 점과, 제한된 범위(자기 게시물에 대한 작은 개선)에서의 이점을 이해합니다. 하지만 그렇다면 포럼에서 확립된 워크플로가 계속 작동하도록 하는 방법을 살펴봐야 할지 모릅니다.
스태프는 불필요하게 위로 올라간 토픽을 최신 목록에서 발견하면 ‘위로 올림 날짜 초기화(reset bump date)’ 기능을 사용했습니다. 이는 스태프가 올라가야 할 토픽을 수동으로 위로 올리는 것보다 훨씬 효과적이었습니다. 스태프는 이런 상황을 어떻게 알아채는 것일까요?
@lindsey@martin@pmusaraj 이 변경 사항을 되돌리길 원하지 않는다는 점은 이해했습니다. 이 기능을 복원할 수 있는 옵션을 도입하는 것이 가능한 대안으로 고려될 수 있을까요? 그러면 사용자가 선택할 수 있을 텐데요.
이것이 불가능하다면, 편집 시 뱀(bump)을 허용하는 플러그인을 만드는 것이 기술적으로 가능한가요? 제가 직접 만들라고 요청하는 것이 아니라, 원리적으로 가능한지 확인하여 이 기능을 복원하려는 시도가 헛수고가 되지 않도록 하려는 것입니다. 저는 이 동작에 의존해 왔거든요.
