최근 Discourse의 업데이트로 인해 스레드의 마지막(또는 첫 번째) 게시물을 편집할 때 발생하던 범프(bump) 기능이 제거되었습니다.
우리는 이 기능을 크게 의존해 왔는데, 스태프가 아닌 일반 멤버들이 이 기능을 대체할 수 있는 현실적인 방법이 없습니다.
우리는 주로 공지 사항 성격의 게시물이나 의도적으로 답글이 없거나 적은 게시물을 범프하는 데 이 기능을 활용했습니다.
이러한 게시물은 주제의 실질적인 업데이트를 위해 편집되어 더 이상 유효하지 않은 정보를 제거하는 것이었습니다. 게시물이 최신 피드 상단으로 다시 올라오는 것은 모든 멤버에게 변경 사항이 있었다는 것을 알리는 데 매우 유용했습니다.
네, 답글을 연달아 남기는 방식으로 어느 정도 이를 모방할 수는 있지만, 시간이 지날수록 사용자에게 전달된 내용을 파악하기가 번거로워집니다(예를 들어, 변경 사항이 담긴 10개의 답글을 상상해 보세요). 원래 게시물 또는 가장 최근 게시물을 편집하여 주제가 최신 피드 상단으로 올라오도록 하는 것이 훨씬 깔끔했습니다.
이 문제에 대해 양쪽 모두의 의견이 있을 것임을 이해합니다. 그러나 이는 Discourse에서 수년 동안 유지되어 온 오랜 관행이었으며, 이전 기능을 복원할 수 있는 옵션을 추가하면 모든 사용자에게 만족스러운 해결책이 될 것입니다. 아마도 시간이 지나면서 옵션을 확장하여, 어떤 활동이 게시물이 최신 피드 상단으로 올라오게 하는지 세밀하게 제어할 수 있도록 할 수 있을 것입니다.
앞서 말했듯이, 의미 있는 수정이 있을 때 토픽을 다시 올리는(bumping) 기능도 그리워합니다.
저는 #rss-polling을 사용하여 https://status.discourse.org/ 의 RSS 피드를 통해 포럼 유지보수 정보를 알림으로 받고 있습니다. 유지보수가 시작되면 토픽이 생성되며, 종료됨을 알리는 수정 시 해당 토픽이 다시 올라갔습니다. 이제 이러한 수정에 의한 알림이 사라졌고, 사용자들이 편집할 수 없도록 토픽을 위키로 설정하는 것도, 문서(docs)로 설정하는 것도 원하지 않습니다. 따라서 현재의 우회책들은 도움이 되지 않습니다.
한 포럼에서는 개별 프로젝트 소개 토픽 외에 사용자들의 프로젝트를 보여주는 갤러리 토픽을 운영하고 있습니다. 이 토픽은 영감을 얻는 데 매우 유용합니다. 갤러리 토픽에 소개 토픽의 이미지와 링크를 추가합니다. 한 게시물에 이미지가 너무 많으면 성능 문제가 발생하고 편집도 어려워집니다. 그래서 10개 프로젝트마다 새로운 게시물을 생성합니다. 2번째나 9번째 프로젝트가 추가될 때 편집으로 인한 알림이 유용했습니다. 업데이트를 인지하는 데 도움이 되었고, 특히 토픽에 프로젝트를 수동으로 추가하는 사람들에게 유용했습니다. 활동 날짜 덕분에 다른 사람이 이미 프로젝트를 추가했는지 즉시 확인할 수 있었습니다. 이제 각자가 이 확인을 위해 토픽을 열어야 합니다.
비슷하게 작동하는 다른 토픽들도 있습니다. 한 달간의 변경 사항/활동에 대한 회고적 개요를 제공하는 토픽으로, 현재 달에 대한 최신 게시물을 몇 번에 걸쳐 업데이트합니다. 마지막 게시물에 대한 변경이 토픽을 다시 올려주었기 때문에 이 방식은 정말 잘 작동했습니다. 각 변경 사항을 개별적으로 게시하면 월별 묶음 항목의 명확성이 떨어지고, 기존 항목에 대한 업데이트를 놓치기 쉬워집니다. 몇 개의 항목을 위해 매월 새로운 토픽을 만드는 것은 과하게 느껴지며, 사용자들이 매월 알림 설정을 다시 해야 하거나, 기본 알림 상태를 설정할 수 있는 별도의 하위 카테고리가 필요하게 됩니다.
답변이 없는 토픽에서 카테고리나 태그가 변경될 때 토픽이 다시 올라가던 것도 좋았습니다. 저는 주로 (필터링된) 최신 토픽 목록을 사용합니다. 제목이 적절하지 않거나 카테고리가 잘못 지정된 토픽은 클릭하지 않을 수 있습니다. 누군가 이 정보를 개선하면, 그래도 도움을 줄 수 있음을 깨달을 수 있습니다. 그래서 이러한 변경으로 인해 토픽이 읽음 라인 위로 다시 올라가던 것이 유용했습니다.
카테고리와 태그에 대해 배우는 데도 도움이 되었습니다. 새로운 토픽에 태그가 추가되거나 관리자가 토픽을 이동시킨 것을 통해 카테고리 간의 세분화된 차이를 배우곤 했습니다. 때로는 왜 이동했는지 질문하기도 했는데, 다른 카테고리로 토픽을 이동할 수 있는 권한에는 그 차이점을 알아야 할 책임도 따른다고 생각하기 때문입니다.
또한 Discourse의 설정이 새 게시물을 작성하는 대신 기존 게시물에 정보를 추가하도록 유도하는 방식도 좋습니다.
팝업 메시지를 인용하자면:
그러나 이는 다른 사람이 게시물을 수정하여 추가 정보를 넣었음을 인지할 때만 의미가 있습니다. 메타(Meta)에서 몇 번이나 마주친 예시로, 풀 리퀘스트가 병합된 후 게시물에 업데이트를 하는 경우가 있습니다. 게시물에 그 정보를 추가해도 이미 게시물을 읽은 사람들에게 알림이 가지 않으며, 아직 읽지 않은 사람들은 원박스(onebox)의 배지를 통해 쉽게 알 수 있습니다.
사용자가 3회 연속으로 답변하는 것을 차단하는 설정이 여전히 활성화되어 있고 편집을 대안으로 제안하지만, 이러한 편집이 아쉽게도 예전과 같은 효과를 더 이상 갖지 못한다면 저에게는 의미가 없습니다.
이 기능에 대해 강한 의견은 없지만, 관련 문제로는 포스트를 자동으로 부밍(bump)한 후 부밍된 메시지를 삭제하고 싶은데, 더 이상 불가능하다는 점입니다. 부밍 메시지를 삭제하면 해당 메시지는 이전 위치로 다시 내려갑니다. 메시지를 편집할 때 "마지막 부밍: 1일 전"이라는 메시지를 생성하지 않고 부밍이 가능했다면 유용했을 것입니다.
(부밍을 한 후 부밍 메시지를 삭제하더라도, 수동으로 "부밍 날짜 초기화"를 하지 않는 한 포스트가 첫 페이지에 유지되기를 선호합니다.)
무언가 더 이상 일어나지 않는다는 사실도 마찬가지입니다. 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시간 전에 해결책을 제안한 뒤, 방금 또 다른 가능한 접근법을 떠올려 스레드가 올라가도록 해서 스레드에 있는 모든 사람이 이를 고려해 보기를 바랐습니다.