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.” ↩︎
제 사용 사례에서, 주제를 편집하여 최신 피드 상단으로 올리는 것은 버그가 아닌 기능이었습니다. 저는 주제에 변경 사항이 있었음을 사용자에게 알리기 위해 이 동작에 의존하고 있었습니다.
마지막 게시글을 편집하여 주제를 올리는 동작은 최신 피드에서 게시글을 위로 끌어올리고 사용자의 시선을 끌어모으는 데 많은 사람들이 의존하고 있을 가능성이 큽니다.
게시글에 답글을 달아 변경 사항을 알리는 것은 효율적이지 않습니다. 사용자가 1번 게시글을 읽은 후, 답글을 달아 주제를 올리면 사용자는 답글로 이동하게 되는데, 편집 내용이 1번 게시글에 있는 경우(제 경우엔 항상 그렇습니다) 사용자는 그 변경 사항을 보지 못하게 됩니다.
번(bump) 기능을 어떻게 활용하셨고, 어떤 경우에 도움이 되셨는지 설명해 주실 수 있을까요?
여전히 새로운 동작 방식과 구버전 동작 방식 중 어떤 것을 더 선호해야 할지 결정하지 못하고 있습니다.
예를 들어, 아직 답변이 달리지 않은 주제에서 제목, 카테고리, 태그를 수정하면 해당 주제가 맨 위로 올라가던 점이 좋았습니다. 덕분에 해당 카테고리나 태그를 주로 살펴보는 사용자들이 이를 알아채고 답변을 달 수 있었습니다. 또한 이 기능 덕분에 포럼에서 모더레이터들이 카테고리와 태그를 어떻게 활용하는지 배우는 데 큰 도움이 되었습니다. 주제가 답변을 받기 전에 자주 이동되었기 때문입니다.
또한 Discourse의 설정이 새 글을 쓰는 대신 정보를 추가하도록 유도하는 방식도 좋습니다. 하지만 이는 주제가 맨 위로 올라갈 때만 효과가 있습니다. 현재는 사용자가 연속으로 3개 이상의 글을 쓸 수 없도록 차단되어 있지만, 편집 시 주제가 맨 위로 올라가지 않아 아무도 이를 알아채지 못할 가능성이 높다는 모호한 상태에 있습니다.
답변이 없는 위키 주제에 변경 사항이 있을 때 주제가 맨 위로 올라가고, 해당 주제를 클릭하면 편집된 게시물로 바로 이동하게 만드는 방식도 좋은 해결책이라고 생각했습니다. 위키가 다시 번(bump)을 일으키도록 변경되었음에도 불구하고, 이는 마지막 게시물일 때만 적용됩니다. 맨 위로 올라간 주제를 열었는데, 도착한 위치(마지막 게시물)에서 왜 그런지 명확하지 않아 혼란스럽습니다.
다만, 작은 변경 사항이 번(bump)을 일으키지 않는 점은 좋습니다. 이전에는 번(bump)을 일으킬 정도로 중요하지 않다고 생각해 추가하지 않던 작은 세부 사항들을 추가하기 위해 편집을 더 많이 하고 있다는 것을 알게 되었습니다.
의도적으로 답글을 받지 않는 게시물도 수정이 이루어지면 최신 피드로 상단까지 올라가곤 했습니다. 예를 들어 정보가 변경된 공지사항 같은 경우였죠.
주제에 대한 진정한 업데이트로, 이제 더 이상 유효하지 않은 정보를 제거하는 수정이 이루어졌을 때 최신 피드 상단으로 다시 올라가는 것은 매우 바람직했습니다. 답글을 연달아 달아 이를 처리할 수는 있지만, 시간이 지남에 따라 사용자에게 어떤 내용이 전달되었는지 파악하는 것이 번거로워집니다(예를 들어 10개의 답글에 걸쳐 변경 사항이 쌓인 경우를 상상해 보세요). 원래 게시물이나 가장 최근 게시물을 수정하여 주제가 최신 피드에서 위로 올라가도록 하는 것이 훨씬 깔끔했습니다.
이 문제에 대해 양쪽 모두의 의견이 있을 수 있다는 점은 이해합니다. 디스코르스에 예전부터 오랫동안 유지되어 온 기능을 복원하는 옵션을 추가하면 모든 사용자에게 환영받을 것입니다. 아마도 시간이 지남에 따라 이 옵션을 확장하여, 게시물에 대한 어떤 활동이 최신 피드에서 위로 올라가는 것으로 간주되는지를 세밀하게 제어할 수 있게 될 것입니다.
저에게는 수년간 이어져 온 방식이 최적이며, 이제 그 방식에 의존하게 되었습니다.
이 변경 사항은 저를 당황스럽게 했습니다. 사용자가 게시물을 수정하여 주제를 다시 상단으로 올리기 위해 게시물 날짜를 수동으로 변경할 수 있긴 하지만, 왜 예전처럼 자동으로 그렇게 하지 않을까요?
TL4(팀 리더 4급)와 스태프가 업데이트하는 모든 게시물을 대부분의 포럼 사용자가 수정할 수 있는 위키로 만드는 것이 적절하지 않을 수 있습니다.
또한 첫 게시물이 위키인 경우 수정 시에도 토픽이 위로 올라가는 기능은, 위키 게시물이 하나 이상 포함된 토픽이나 위키가 첫 번째 게시물이 아닌 경우에도 도움이 되지 않습니다. 예를 들어 한 달 동안 수집된 내용을 다루는 토픽에서 다음 달을 위해 새 위키를 답글로 생성하는 경우를 생각해 볼 수 있습니다. 이전에는 현재 달의 위키가 가장 최근 게시물이었기 때문에 토픽이 자동으로 위로 올라가는 방식으로 매우 잘 작동했습니다.
타이머는 토픽에 삭제할 수 없는 번거로운 작은 활동 게시물을 추가합니다. 이를 삭제하면 다시 한번 위로 올림(bump) 날짜가 초기화되기 때문입니다.
변경 사항을 되돌리고 싶지 않다는 점과, 제한된 범위(자기 게시물에 대한 작은 개선)에서의 이점을 이해합니다. 하지만 그렇다면 포럼에서 확립된 워크플로가 계속 작동하도록 하는 방법을 살펴봐야 할지 모릅니다.
스태프는 불필요하게 위로 올라간 토픽을 최신 목록에서 발견하면 ‘위로 올림 날짜 초기화(reset bump date)’ 기능을 사용했습니다. 이는 스태프가 올라가야 할 토픽을 수동으로 위로 올리는 것보다 훨씬 효과적이었습니다. 스태프는 이런 상황을 어떻게 알아채는 것일까요?
@lindsey@martin@pmusaraj 이 변경 사항을 되돌리길 원하지 않는다는 점은 이해했습니다. 이 기능을 복원할 수 있는 옵션을 도입하는 것이 가능한 대안으로 고려될 수 있을까요? 그러면 사용자가 선택할 수 있을 텐데요.
이것이 불가능하다면, 편집 시 뱀(bump)을 허용하는 플러그인을 만드는 것이 기술적으로 가능한가요? 제가 직접 만들라고 요청하는 것이 아니라, 원리적으로 가능한지 확인하여 이 기능을 복원하려는 시도가 헛수고가 되지 않도록 하려는 것입니다. 저는 이 동작에 의존해 왔거든요.
