제목 수정 시 답글이 있는 주제(토픽)가 위로 올라옵니다

내 포럼과 메타(Meta)에서 제목이 수정되면 해당 주제가 맨 위로 올라가는(bump) 것을 확인했습니다. 제게는 이 기능이 다소 혼란스럽습니다. 주제가 목록 맨 위에 나타나면 새로운 내용이 추가된 것으로 오해하기 쉽지만, 실제로는 보통 최신 게시글로 이동하게 되면서 첫 번째 게시글에서 제목이 수정된 것이기 때문에 변경 사항을 알아차리기 매우 어렵습니다.

마지막 게시글에 대한 수정은 더 이상 주제를 맨 위로 올리지 않도록 변경된 것을 확인했습니다. 현재 주제 제목 수정 시 bump가 발생하는 것이 그 변경 사항의 부수적 효과(side effect)일 가능성은 없는지 궁금합니다.

이 문제는 카테고리 및 태그 수정 시에도 발생합니다.

3개의 좋아요

감사합니다. 몇 시간 전에 해당 PR이 병합되었으니 그럴 가능성이 높네요. @martin 님이 확인해 보실 겁니다.

1개의 좋아요

Moin, 이제 이해했습니다… 더 이상 마지막 게시글인지 확인하지 않으므로, 주제 OP의 내용만 변경되는지 확인하고, 그렇다면 범프(bump)를 우회해야 합니다.

여기에 수정 사항이 있습니다:

카테고리 변경으로 재현할 수 있었지만, 태그 변경으로는 재현할 수 없었습니다.

3개의 좋아요

수정해 주셔서 감사합니다

필요한 경우 재현을 위해 태그를 추가하여 Profile picture next to pinned topics 스레드를 올렸습니다.

3개의 좋아요

음, 이제 재현할 수 있네요. 어제는 왜 안 됐는지 모르겠네요.

음, 네. 제목 수정 시 토픽이 상위 목록으로 올라가지 않는 것은 타당하다고 생각합니다. 하지만 카테고리 및 태그 수정에 따른 상위 목록 이동은 다음 두 설정 때문에 복잡합니다:

이 설정들은 원문(OP)을 수정할 때 토픽이 상위 목록으로 올라가는지를 제어합니다:

하지만 이 설정들은 카테고리/태그 변경 시 실제 알림이 전송되는지 여부도 제어하기 때문에, 이 문제를 분리해서 해결하는 것이 다소 복잡합니다. 내부적으로 조금 논의해 보고 다시 알려드리겠습니다.

편집 시 토픽을 위로 올리는 기능(bump)을 제거하기 전에는, 제목, 카테고리, 태그 변경 시 해당 토픽에 답변이 없어야만 토픽이 위로 올라갔습니다. 답변이 있는 경우에는 마지막 게시물이 아니었기 때문에 토픽이 위로 올라가지 않았습니다. 이 기능을 복원할 계획이신가요, 아니면 이러한 경우의 토픽 위로 올림 기능도 차단하시길 원하시나요?

저도 테스트 토픽에서 카테고리를 편집했는데 왜 토픽이 위로 올라가지 않는지 궁금했습니다. 편집 허용 기간(editing grace period) 때문인 것 같습니다. 5분 동안 기다린 후 카테고리를 편집하니 다시 토픽이 위로 올라갔습니다.

답변(reply) 외에 현재 어떤 요인이 토픽을 위로 올리는지 여전히 혼란스럽습니다. 이를 이해하면 사용자가 Discourse의 지시에 따라 새 답변을 연속으로 게시하는 대신 기존 게시물을 편집하도록 유도하는 경우, 그 편집을 어떻게 인지할 수 있는지에 대한 해결책을 찾는 데 도움이 될 것입니다.[1] 시스템이 답변 대신 게시물을 편집하라고 안내했는데, 실제로 그렇게 했음에도 아무도 이를 알아채지 못하는 상황은 다소 답답한 경험이 될 수 있다고 생각합니다. 또한, 이제 위키 게시물의 편집을 어떻게 추적할 수 있는지에 대해서도 도움을 요청했습니다.

생일 축하합니다 :birthday_cake:


  1. “연속 답변은 최대 %{count}개까지 가능합니다. 이전 답변을 편집하거나, 다른 사람이 답변할 때까지 기다려 주세요.” ↩︎

3개의 좋아요

제목, 태그, 카테고리 변경 시 게시물이 올라오지 않도록 추가 조정을 할 예정입니다. 잠시만 기다려 주세요…

3개의 좋아요

이 문제는 이제 수정되었습니다. 이제 제목/태그/카테고리 편집이 게시글을 위로 올리는(bumping) 현상을 더 이상 일으키지 않습니다:

3개의 좋아요

이 변경 사항을 되돌릴 수 있는 옵션이 있나요?

제 사용 사례에서, 주제를 편집하여 최신 피드 상단으로 올리는 것은 버그가 아닌 기능이었습니다. 저는 주제에 변경 사항이 있었음을 사용자에게 알리기 위해 이 동작에 의존하고 있었습니다.

마지막 게시글을 편집하여 주제를 올리는 동작은 최신 피드에서 게시글을 위로 끌어올리고 사용자의 시선을 끌어모으는 데 많은 사람들이 의존하고 있을 가능성이 큽니다.

게시글에 답글을 달아 변경 사항을 알리는 것은 효율적이지 않습니다. 사용자가 1번 게시글을 읽은 후, 답글을 달아 주제를 올리면 사용자는 답글로 이동하게 되는데, 편집 내용이 1번 게시글에 있는 경우(제 경우엔 항상 그렇습니다) 사용자는 그 변경 사항을 보지 못하게 됩니다.

이 게시글과 마찬가지로: 사소한 편집은 주제를 올리지 않아야 합니다. 당시에는 이것이 바람직한 동작이며 버그가 아니라는 의견이 많았습니다.

이 변경 사항을 켜고 끌 수 있는 설정이 제공된다면, 사람들은 오래된 기능을 뒤집는 대신 자신들의 취향에 맞게 세부적으로 조정할 수 있을 것입니다.

항상 주제 편집 시 자동 알림(Bump)을 원하지는 않지만, 때로는 시의적절한 변경 사항을 더 눈에 띄게 하고 싶을 때가 있습니다. 자동 Bump는 하나의 선택지이지만, 제가 원하는 것과 완전히 일치하지는 않습니다:

자동 Bump는 날짜/시간 설정을 요구합니다:

자동 Bump 메뉴에 “지금” 옵션을 추가하는 것을 제안하고 싶을 만큼 유혹이 되지만, 자동 Bump 알림은 자동적 – 즉 의도적이지 않은 – Bump임을 나타내므로, 이는 다른 신호를 전달합니다:
image

역할이나 신뢰 수준에 따라 활성화할 수 있는 주제 편집 시 Bump 옵션이 있었으면 좋겠다는 생각을 가끔 합니다. "편집 저장"과 “편집 저장 및 Bump” 버튼이 있는 모습을 상상해 봅니다:

image

…그리고 결과 알림에는 스태프가 주제를 편집했습니다 또는 유사한 문구가 표시될 것입니다.

저도 이전 동작 방식이 정말 유용했다고 말씀드리고 싶습니다. 구동작 방식과 새로운 동작 방식을 전환할 수 있는 버튼을 추가해 주실 수 없을까요?

번(bump) 기능을 어떻게 활용하셨고, 어떤 경우에 도움이 되셨는지 설명해 주실 수 있을까요?

여전히 새로운 동작 방식과 구버전 동작 방식 중 어떤 것을 더 선호해야 할지 결정하지 못하고 있습니다.

예를 들어, 아직 답변이 달리지 않은 주제에서 제목, 카테고리, 태그를 수정하면 해당 주제가 맨 위로 올라가던 점이 좋았습니다. 덕분에 해당 카테고리나 태그를 주로 살펴보는 사용자들이 이를 알아채고 답변을 달 수 있었습니다. 또한 이 기능 덕분에 포럼에서 모더레이터들이 카테고리와 태그를 어떻게 활용하는지 배우는 데 큰 도움이 되었습니다. 주제가 답변을 받기 전에 자주 이동되었기 때문입니다.

또한 Discourse의 설정이 새 글을 쓰는 대신 정보를 추가하도록 유도하는 방식도 좋습니다. 하지만 이는 주제가 맨 위로 올라갈 때만 효과가 있습니다. 현재는 사용자가 연속으로 3개 이상의 글을 쓸 수 없도록 차단되어 있지만, 편집 시 주제가 맨 위로 올라가지 않아 아무도 이를 알아채지 못할 가능성이 높다는 모호한 상태에 있습니다.

답변이 없는 위키 주제에 변경 사항이 있을 때 주제가 맨 위로 올라가고, 해당 주제를 클릭하면 편집된 게시물로 바로 이동하게 만드는 방식도 좋은 해결책이라고 생각했습니다.
위키가 다시 번(bump)을 일으키도록 변경되었음에도 불구하고, 이는 마지막 게시물일 때만 적용됩니다. 맨 위로 올라간 주제를 열었는데, 도착한 위치(마지막 게시물)에서 왜 그런지 명확하지 않아 혼란스럽습니다.

다만, 작은 변경 사항이 번(bump)을 일으키지 않는 점은 좋습니다. 이전에는 번(bump)을 일으킬 정도로 중요하지 않다고 생각해 추가하지 않던 작은 세부 사항들을 추가하기 위해 편집을 더 많이 하고 있다는 것을 알게 되었습니다.

2개의 좋아요

말씀하신 점이 정확히 핵심을 찔렀습니다.

의도적으로 답글을 받지 않는 게시물도 수정이 이루어지면 최신 피드로 상단까지 올라가곤 했습니다. 예를 들어 정보가 변경된 공지사항 같은 경우였죠.

주제에 대한 진정한 업데이트로, 이제 더 이상 유효하지 않은 정보를 제거하는 수정이 이루어졌을 때 최신 피드 상단으로 다시 올라가는 것은 매우 바람직했습니다. 답글을 연달아 달아 이를 처리할 수는 있지만, 시간이 지남에 따라 사용자에게 어떤 내용이 전달되었는지 파악하는 것이 번거로워집니다(예를 들어 10개의 답글에 걸쳐 변경 사항이 쌓인 경우를 상상해 보세요). 원래 게시물이나 가장 최근 게시물을 수정하여 주제가 최신 피드에서 위로 올라가도록 하는 것이 훨씬 깔끔했습니다.

이 문제에 대해 양쪽 모두의 의견이 있을 수 있다는 점은 이해합니다. 디스코르스에 예전부터 오랫동안 유지되어 온 기능을 복원하는 옵션을 추가하면 모든 사용자에게 환영받을 것입니다. 아마도 시간이 지남에 따라 이 옵션을 확장하여, 게시물에 대한 어떤 활동이 최신 피드에서 위로 올라가는 것으로 간주되는지를 세밀하게 제어할 수 있게 될 것입니다.

저에게는 수년간 이어져 온 방식이 최적이며, 이제 그 방식에 의존하게 되었습니다.

이 변경 사항은 저를 당황스럽게 했습니다. 사용자가 게시물을 수정하여 주제를 다시 상단으로 올리기 위해 게시물 날짜를 수동으로 변경할 수 있긴 하지만, 왜 예전처럼 자동으로 그렇게 하지 않을까요?

1개의 좋아요

이 문제는 추후 다시 검토될 가능성이 있나요, 아니면 이 변경 사항을 조정하는 것은 이미 포기한 상태인가요?

@pmusaraj @martin 이 변경 사항으로 인해, 마지막 게시물을 편집하면 활동 피드의 상단으로 올라가던 오랜 기간 동안의 동작이 되돌려졌습니다.

10년이 넘는 선례가 한 번의 변경으로 뒤집혔고, 이는 우리에게 큰 불편을 주고 있습니다. 마지막 게시물 편집 시의 이 ‘bump’ 기능이 제품으로 복원된다면 매우 도움이 될 것입니다.

Staff 권한이 있는 사용자는 날짜를 이동하여 이 문제를 해결할 수 있지만, 다른 사용자는 그러지 못합니다. 편집 시 bump를 허용하는 옵션을 추가하거나, 이전 동작을 복원해야 한다고 생각합니다.

1개의 좋아요

이 변경 사항을 되돌릴 계획은 없습니다. 내부적으로 논의한 결과, 사용자의 사용 사례에 따라 다음 중 하나를 선택할 수 있습니다:

  • 토픽의 OP(첫 번째 게시글)를 위키 게시글로 설정하세요. 위키 게시글을 수정해도 토픽이 위로 올라갑니다.
  • 중요한 수정이 있을 경우 토픽에 새 게시글을 작성하세요.

또한, 토픽 자동 올리기(Auto-Bump Topic) 타이머를 사용하는 것도 효과적입니다. 향후 카테고리별로 토픽 올리기 기능을 더 세밀하게 제어할 수 있는 추가 설정 옵션을 도입할 수 있습니다.

TL4(팀 리더 4급)와 스태프가 업데이트하는 모든 게시물을 대부분의 포럼 사용자가 수정할 수 있는 위키로 만드는 것이 적절하지 않을 수 있습니다.
또한 첫 게시물이 위키인 경우 수정 시에도 토픽이 위로 올라가는 기능은, 위키 게시물이 하나 이상 포함된 토픽이나 위키가 첫 번째 게시물이 아닌 경우에도 도움이 되지 않습니다. 예를 들어 한 달 동안 수집된 내용을 다루는 토픽에서 다음 달을 위해 새 위키를 답글로 생성하는 경우를 생각해 볼 수 있습니다. 이전에는 현재 달의 위키가 가장 최근 게시물이었기 때문에 토픽이 자동으로 위로 올라가는 방식으로 매우 잘 작동했습니다.

타이머는 토픽에 삭제할 수 없는 번거로운 작은 활동 게시물을 추가합니다. 이를 삭제하면 다시 한번 위로 올림(bump) 날짜가 초기화되기 때문입니다.

변경 사항을 되돌리고 싶지 않다는 점과, 제한된 범위(자기 게시물에 대한 작은 개선)에서의 이점을 이해합니다. 하지만 그렇다면 포럼에서 확립된 워크플로가 계속 작동하도록 하는 방법을 살펴봐야 할지 모릅니다.

스태프는 불필요하게 위로 올라간 토픽을 최신 목록에서 발견하면 ‘위로 올림 날짜 초기화(reset bump date)’ 기능을 사용했습니다. 이는 스태프가 올라가야 할 토픽을 수동으로 위로 올리는 것보다 훨씬 효과적이었습니다. 스태프는 이런 상황을 어떻게 알아채는 것일까요?

Martin이 말했듯이, 현재 이 변경 사항을 되돌리지 않을 것입니다.

다음과 같은 세 가지 우회 방법이 있습니다:

  • 해당 주제를 위키로 설정하기
  • Auto-Bump Topic Timer(자동 주제 끌어올림 타이머) 사용
  • 편집 내용을 설명하는 답변을 게시하기 (@Moin, 위키가 적합하지 않고 Auto-Bump Topic Timer를 사용하고 싶지 않은 경우를 설명하셨을 때 제안된 우회 방법입니다)

또한 Docs Categories(문서 카테고리) 주제가 수정될 때에도 계속 끌어올림 처리를 수행합니다.

이러한 우회 방법들이 모든 사용 사례에 이상적이지 않다는 점을 이해합니다. 이 옵션 중 어느 것도 적용할 수 없는 구체적인 사용 사례를 발견하시면, Contribute > Feature 주제에서 그 내용을与我们 공유해 주시기 바랍니다.

1개의 좋아요

@lindsey @martin @pmusaraj 이 변경 사항을 되돌리길 원하지 않는다는 점은 이해했습니다. 이 기능을 복원할 수 있는 옵션을 도입하는 것이 가능한 대안으로 고려될 수 있을까요? 그러면 사용자가 선택할 수 있을 텐데요.

이것이 불가능하다면, 편집 시 뱀(bump)을 허용하는 플러그인을 만드는 것이 기술적으로 가능한가요? 제가 직접 만들라고 요청하는 것이 아니라, 원리적으로 가능한지 확인하여 이 기능을 복원하려는 시도가 헛수고가 되지 않도록 하려는 것입니다. 저는 이 동작에 의존해 왔거든요.