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:
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.
무언가 더 이상 일어나지 않는다는 사실도 마찬가지입니다. Discourse의 동작이 변경된 것을 알아차린 관리자가 얼마나 되는지에 대한 데이터가 있나요? bump를 방지하는 방법에 대한 반복적인 요청이 있었다는 당신의 논리는 이해합니다. 원하지 않는 bump는 관리자가 쉽게 알아차릴 수 있습니다. 하지만 토픽이 bump되지 않으면, 그것이 bump되었기를 원했을지라도 bump되지 않았다는 사실조차 알아차리지 못합니다. 따라서 사람들이 이를 위해 요청할 가능성은 낮아 보입니다.
또한 최근에는 토픽이 bump되면 스팸이 더 쉽게 발견된다는 사실이 다시 언급되었습니다. 왜 이것이 수정 시 포스트가 bump되어야 하는 경우처럼 제한적인 상황에서 관련이 있는지 궁금합니다. 하지만 대부분의 포스트에 대해 기본값을 변경할 때는 중요하지 않았습니다. 위키인 첫 번째 포스트가 위키인 토픽의 마지막 포스트보다 왜 더 많은 스팸 보호가 필요한가요?
이전에도 여러 번 말했듯이, 장점은 이해하지만 단점에 대한 해결책을 찾으려는 관심은 많지 않아 보입니다. 1년 정도 후에 현재 워크플로우의 대체제가 있어도 소용이 없습니다. 마지막 포스트의 수정이 토픽을 맨 위로 올리는 것이 지원되는 Discourse 버전이 있는 시간이 얼마 남지 않았기 때문에, 저는 지금 새로운 해결책을 찾아야 합니다.
위키 및 문서 게시물은 해당 게시물에 대한 편집이 일반적으로 관심사라는 이론에 기반하여 상단으로 올라갑니다(bump).
스팸 보호에 관해서는, 이러한 상단 올림(bump)이 실제로는 추가적인 커버리지를 거의 제공하지 못했다는 것이 현재 이론입니다. 대부분의 게시물은 마지막 게시물이 아니며, 이러한 게시물에 대한 편집은 본래 상단 올림으로 노출되지 않았습니다. 따라서 편집을 통한 스팸이 문제라면, 어쨌든 다른 해결책이 필요합니다. 이것은 그 문제에 대한 효과적인 해결책이 된 적이 결코 없었습니다.
오해가 있는 것 같습니다. 제 지적은 첫 번째 게시물인 위키 게시물이 왜 상단으로 올라오는지에 대한 것이 아니었습니다. GitHub 코멘트에 언급된 대로 no-bump API 파라미터를 제한하는 이유에 대해 말씀드린 것입니다:
“이것은 스태프 API 키로만 제한되어야 하는가요? 일반 사용자들이 상단 노출(bumping)을 우회할 수 있게 하고 싶지 않습니다(이렇게 하면 사용자들의 주의를 끌지 않고도 주제에 스팸을 주입할 수 있게 됩니다).”
만약 스팸이 진짜 우려 사항이었다면, 이 제한은 상단 노출이 발생하는 남은 몇 가지 경우에만 적용되는 것이 아니라 일관되게 적용되어야 합니다. 제가 놀란 이유는 바로 이것입니다: 즉, 여기서는 스팸을 문제로 인용하고 있지만, 예를 들어 주제에서 마지막 게시물인 위키의 경우 상단 노출은 스팸 방지 메커니즘으로 의도된 것이 아니라는 점입니다.
위키 게시물이 업데이트될 때 상단으로 올라오는 점은 인정합니다(다만, 상단 노출 사유가 첫 번째 게시물인 상태에서 사용자가 주제 하단으로 이동하는 UX는 여전히 모호합니다).
제 지적은 스팸에 관한 이 명백한 불일치를 강조하는 것뿐입니다.
최근 최신 esr 버전으로 업데이트했는데, 사용자들이 이 기능이 제거된 것을 알아차렸습니다. 최소한 관리자 설정에서 활성화할 수 있는 옵션으로 남겨야 한다고 생각합니다. 제 경험상, /latest 토픽 목록은 커뮤니티 참여 측면에서 Discourse(그리고 다른 포럼 플랫폼)의 가장 중요한 기능 중 하나입니다. 스레드의 마지막 게시글을 수정하거나 잠긴 스레드의 첫 번째이자 유일한 게시글을 수정하는 것은 스레드 끝에 새 게시글을 작성하는 것과 같으며, /latest에 표시되지 않으면 독자들이 업데이트된 정보를 확인하지 못할 수 있습니다.
실망스럽습니다. 저도 같은 문제를 발견했습니다. 이런 종류의 변경은 전혀 좋아하지 않는데, 특히 오랫동안 유지되어 온 기능이 예고 없이 갑자기 사라지는 경우는 더 그렇습니다.
이 변경은 이중 게시(double posting)를 부추길 뿐입니다. 이전에는 사용자가 자신의 스레드에 답글을 남길 필요가 없으며, 수정만 해도 스레드가 올라간다고 설명하면 충분했습니다. 하지만 이제 그 조언은 더 이상 유효하지 않습니다. 대신 스스로에게 답글을 남기는 것(이중 게시)이 효과를 보게 되었습니다.
오늘 저는 누군가를 도와주고 있었는데, 약 7시간 전에 해결책을 제안한 뒤, 방금 또 다른 가능한 접근법을 떠올려 스레드가 올라가도록 해서 스레드에 있는 모든 사람이 이를 고려해 보기를 바랐습니다.