Discourse Post Voting에서 이어진 논의입니다:
Q&A 주제의 첫 번째 게시글은 질문 자체이므로, 상단 투표(Upvote) 옵션이 제공되지 않아야 합니다.
Discourse Post Voting에서 이어진 논의입니다:
Q&A 주제의 첫 번째 게시글은 질문 자체이므로, 상단 투표(Upvote) 옵션이 제공되지 않아야 합니다.
이것이 주제 간 우선순위를 정하기 위한 기능이 아닌가요?
현재로서는 왜 특정 주제에 투표해야 하는지 혼란스럽고 명확하지 않다는 데 동의합니다.
@volanar 님에게 이전된 게시글입니다. 이전에 언급된 적이 있었거든요. ![]()
고의적으로 그렇게 된 것이라는 답변이 있었던 것 같은데, 어떻게 찾아도 보이지 않네요. 찾아보겠습니다. ![]()
임시 해결책으로 이 CSS를 사용할 수 있습니다:
.post-stream .topic-post:first-child .post-voting-post {
display: none;
}
이것은 매우 중요한 사이트 설정입니다. 질문의 품질에 대한 투표는 Stack Overflow와 같은 사이트에서 이미 잘 확립된 기능입니다.
우리는 의도적으로 투표 컨트롤을 유지하고 있습니다. CSS를 통해 제거하는 것은 괜찮지만, 이를 위한 사이트 설정을 추가하는 것도 고려할 수 있습니다.
하지만 질문 자체는 답변들 간의 투표에 참여할 수 없습니다. 또한 답변들과 함께 필터링할 수도 없습니다. 질문은 항상 맨 위에 위치해야 합니다.
OP(원문)의 것을 다르게 스타일링하면, 답변 속의 것들과 의미가 다르다는 것을 더 잘 보여줄 수 있을까요?
질문에 대한 투표는 Discourse의 맥락에서 진지하게 논의할 가치가 있다고 생각합니다. 저는 SO(Slack Overflow) 유사 사이트에서 약간의 경험을 가지고 있으며(
여기서 post-voting 유형 주제에 대해 투표가 유용한지, 아니면 아예 필요 없는지 조금 생각해 보고 싶습니다(간결성을 위해, 이 글 이후로는 이러한 것들을 단순히 "질문"이라고 부르겠습니다).
질문이 전적으로 Q&A(질문과 답변)에만 초점을 맞춘 플랫폼(예: Stack Overflow)에서는 질문 투표(상투표와 하투표)가 특정 목적으로 사용된다는 점은 정확합니다. 특히 다음과 같은 목적입니다:
제가 아는 한, 이 기능은 현재 Discourse에는 적용되지 않습니다. 이 플러그인을 사용하든 아니든 마찬가지입니다. 이 기능이 비교적 새로운 것은 알지만, 이러한 Q&A 기능 중 Discourse에서 활용하고 싶은 기능이 얼마나 되는지 궁금합니다. 겉으로 보기에는, 이는 현재 신뢰 수준(trust level) 시스템과 기타 모더레이션 관행에서 거대한 패러다임 전환처럼 보입니다.
만약 이러한 질문 유형을 추가하는 주요 목표가 커뮤니티가 자신의 SE 스타일 사이트를 쉽게 생성/호스팅할 수 있도록 하는 것이라면, 여기서 토론보다는 더 구조화된 Q&A가 주요 목적인 경우, 그것은 정말 흥미롭고 더 많은 이야기를 듣고 싶습니다… 하지만 저는 SO에서 많은 것을 배웠고, 이는 SO의 일부 핵심 기능에 의문을 제기하게 만들었습니다. 만약 제가 처음부터 구축한다면, SO의 많은 측면을 복제하는 것을 단호히劝阻(권고하지 않는) 것입니다.
Discourse 커뮤니티가 포스트 투표 플러그인을 실행하는 것과 같은 하이브리드 시스템에 대해 생각할 때, 솔직히 질문에 대한 투표가 아예 의미가 있는지 모릅니다. 이 기능과 그 구현 방식에 대해 많이 알지 못한다고 인정하지만, 약간의 탐색을 해보고 여기에서 읽을 수 있는 게시물을 읽으며 학습한 결과, 이러한 결론에 도달했습니다.
플러그인이 공식적으로 출시된 지 1년이 채 되지 않았고 여전히 변동 중일 가능성이 높다는 것을 이해합니다. 저는 Discourse 모더레이션, 기능 또는 범위에 대해 전문가라고 주장하지 않겠습니다(실수가 있으면 수정해 주세요) 하지만, 현재 상황은 다른(그리고 아마도 더 나은) 솔루션을 사용하고 있어 질문 점수의 많은 이유가 불필요하게 만드는 것으로 보입니다.
요약(TL;DR) - 굵게 표시된 부분을 읽어보세요.
| # | 기능 | SO에서의 사용 | Discourse에서의 사용 | 유용한가? |
|---|---|---|---|---|
| 1 | 투표 알림 | 상투표는 게시자에게 평판 변화를 알립니다. SO에는 좋아요(Like) 기능이 없습니다. | 투표는 질문자에게 알림을 생성하지 않지만 좋아요는 생성합니다. | Discourse에 상투표 알림을 추가하는 것은 쉽겠지만, 왜 둘 다 있어야 합니까? 좋아요는 여기에서 질문 투표를 불필요하게 만드는 주요 이유 중 하나입니다. [1] |
| 2 | 질문자에게 미치는 투표의 영향 (평판) | 평판은 SO에서 특권이 부여되는 방식이며, 사용자의 평판은 그들의 지위의 주요 측면입니다. 잘 받아들여진 질문으로 평판을 얻는 것은 질문만 하는 사용자가 특권을 얻을 수 있는 거의 유일한 방법입니다. | 평판과 유사한 것은 없습니다. 특권은 신뢰 수준 시스템을 통해 부여되며, 이는 TL 1의 경우 단순히 콘텐츠를 읽는 것을 강조하고 보상합니다. Q&A 스타일 게시글에 대한 투표는 좋아요로 계산되는 것 같으며, 이는 질문과 답변 모두에서 부재합니다. | 게시글 생성, 평판, 특권 간의 직접적인 연결은 제가 SO에서 가장 변경하고 싶은 측면입니다. 사용자는 콘텐츠 생성을 요구하지 않는 여러 경로를 통해 특권을 얻을 수 있어야 합니다. 사용자가 TL을 얻기 위해 질문 투표가 필요하지 않다면, 그것은 불필요해 보입니다. |
| 3 | 질문자에게 미치는 투표의 영향 (비평판) | 공개되지 않은 자동 SO 재범(recidivism) 시스템의 한 측면(모더레이터가 오버라이드할 수 없음)은 일관되게 poorly-received 질문을 게시하는 사용자의 향후 질문을 차단하기 위해 질문 점수에 부분적으로 의존합니다. SO에는 사이트 라이브가 되기 전에 콘텐츠 미리보기를 요구하는 방법이 없습니다. | 모더레이터는 자동화 대신 도구를 사용하여 수동으로 사용자를 침묵, 정지 또는 TL을 오버라이드합니다. 일부 경우 새로운 게시글의 모더레이터 검토를 요구할 수 있는 설정이 있지만, 게시글의 수용도에 기반하지 않습니다. | SO의 규모와 누구나 질문할 수 있도록 허용하는 우선순위를 고려할 때, 사용자를 위한 자동 질문 밴은 이해할 수 있습니다(하지만 시스템이 대대적인 개편이 필요합니다 [2]). 기존의 TL 기반 게시 제한과 플래그 사용을 의존하면 사용자 모더레이션을 위해 질문 점수가 불필요합니다. |
| 4 | 점수가 게시글에 미치는 영향 | 낮은 점수의 질문은 첫 페이지에서 숨겨지고, 신뢰할 수 있는 사용자 또는 자동화에 의해 더 쉽게 삭제됩니다. 일부 플래그 유형은 충분한 수가 수신되면 질문을 삭제할 수 있습니다. 동일한 유형의 모든 플래그는 누가 플래그를 했든 관계없이 동일하게 가중됩니다. | 플래그에 기반하여 게시글을 자동으로 닫고, 숨기고, 삭제하는 강력한 기존 시스템이 있으며, 이는 플래그가 달린 게시글에 모더레이터의 주의를 기울이게 합니다. 좋은 플래그 이력을 가진 사용자의 플래그는 그렇지 않은 사용자의 플래그보다 더 높은 가중치를 갖습니다. | 기존 시스템은 놀라울 정도로 잘 균형 잡혀 보입니다. 과거의 플래그를 사용하여 새로운 플래그에 가중치를 부여함으로써, 사용자는 플래그를 정확히 하도록 동기 부여됩니다. 반면, 가중되지 않은 투표를 사용하여 콘텐츠를 숨기거나 삭제하는 것은 오용될 수 있으며, 과거의 투표를 고려하지 않습니다. 기존의 플래그 시스템과 함께 투표를 사용하여 게시글을 모더레이션하는 것은 불필요합니다. |
| 5 | 질문 정렬/필터링 | 질문 점수, 답변 수, 승인 상태는 모든 질문 목록 보기에서 명확하게 표시됩니다. 검색은 사용자 요청에 따라 질문 점수를 사용하여 결과를 필터링하고 정렬할 수 있습니다. 모든 주제가 Q&A이므로, Q&A만 찾기 위해 구문이 필요하지 않습니다. 검색에는 질문만 반환하는 구문이 포함되어 있습니다. | 질문 점수는 주제 목록에 표시되지 않지만, 해결 상태와 응답 수는 표시됩니다. 결과는 좋아요(투표 포함)로 정렬할 수 있습니다. Q&A 주제만 반환하는 방법은 없습니다. in:first 구문은 질문만 반환하는 것 같습니다. |
게시글 유형(Q&A vs 토론 및 질문 vs 답변/응답)에 대한 검색 구문을 추가하는 것은 가치 있어 보이지만, 약간 벗어난 주제입니다. (주제 목록에 질문 점수를 표시하기 위한 이 기능 요청 게시물)은 유용할 수 있지만, 주제 목록에서 질문 점수를 대체하기 위해 좋아요를 사용할 수 있거나, FR을 거부하고 UI를 그대로 유지할 수도 있습니다. |
| 6 | 상투표의 의미 | 질문 상투표의 호버 텍스트는 "이 질문은 연구 노력을 보여줍니다; 유용하고 명확합니다"라고 말합니다. 첫 번째 부분은 논쟁의 여지가 있고, 두 번째 부분은 주관적이고 모호합니다. 사용자는 "나도 같은 질문을 가졌다!"와 같은 많은 이유로 질문에 투표할 가능성이 있으며, 이는 논쟁적으로 “유용한” 범주에 속하지만, 주제 전문가들은 단순하지만 일반적인 질문이 유용하지 않다고 판단하여 하투표할 수 있습니다. [3] [4] | 미정의. 언제 투표해야 하는지에 대한 UI 지침이 없으며, 이는 새로운 기능이고 각 커뮤니티가 다른 이유로 투표를 장려할 수 있기 때문에 이해할 수 있습니다. 익숙한 좋아요 기능은 이 주제 형식에서 부재합니다. 좋아요가 기본적으로 하트만 사용할 수 있지만, 커뮤니티는 추가적인 리액션을 구성할 수 있습니다. | 언제 투표해야 하는지에 대해 합의를 이룬 커뮤니티에서도, 질문 투표의 이유는 답변 투표의 이유보다 훨씬 더 주관적이고 광범위한 경우가 많습니다. 답변 투표는 거의 항상 “이것이 정답입니다” 또는 "이것에 동의합니다"를 의미합니다. 좋아요, 특히 커뮤니티가 다양한 리액션 옵션을 추가할 때, 순수한 상/하 투표보다 누군가가 질문에 투표한 이유를 더 잘 설명할 수 있습니다. |
| 7 | 하투표의 의미 | SO에서 언제 질문에 하투표를 해야 하는지 10명에게 물어보면, 아마도 10가지 다른 답변을 듣게 될 것이며, 그중 절반은 “잘못된” 것이거나, 편집, 플래그, 닫기 또는 댓글로 더 잘 해결될 수 있는 것입니다. 이러한 기능의 과소 사용은 질문자가 설명 없이 하투표된 질문에 대해 혼란과 좌절을 표현하고 그러한 투표를 금지해 달라고 요청하기 위해 메타에 게시물을 올리는 결과를 초래합니다. [5] | 마찬가지로 이해할 수 있는 미정의 상태. 대부분의 질문 문제는 실행 가능한 변경 사항이나 권장 사항을 지적하기 위해 댓글을 사용하거나, 질문자에게 DM을 보내기 위해 질문의 플래그 옵션을 사용하거나, 모더레이터를 위해 플래그를 사용하여 더 효과적으로 해결될 수 있습니다. 기본 하트는 하투표의 부정적인 뉘앙스와는 맞지 않습니다. | 사람들은 미워합니다. 하투표를 받는 것을, 플랫폼이 사용자가 하투표되었음을 알리지 않기 위해 큰 노력을 기울이더라도요. 이는 도움을 구하고, 막혀 있고 좌절된 자신을 공유함으로써 취약한 위치에 있는 질문자에게 더 고통스러운 경우가 많습니다. 그들은 도움이 되지 않거나 방해한다고 해석하는 사람들에게서요. 질문의 하투표는 쉬운 반응일 수 있지만, 질문자가 개선하는 데 도움이 되지 않습니다. 다른 도구에 의존함으로써, 소외가 아닌 소통을 장려합니다. |
기존 플랫폼, 특히 당신이 도움이 되어 구축한 플랫폼에서 확립된 패턴을 따르려는 충동을 인정합니다. 하지만 제가 SE/SO 커뮤니티에 대해 얻은 큰 교훈은, 대부분의 (새로운) 사용자가 SE가 포럼과 더 유사하다고 가정하고, 특히 닫기와 투표에 관해서는 첫 번째 질문의 수용에 어려움을 겪는다는 것입니다. SO에서 질문을 하는 것은 많은 사람들에게 스트레스를 유발합니다… 인터넷에는 SO에 대한 수많은 참조가 있으며, 그들은 질문이 완전히 무시되거나, 프로그래밍 질문으로 자격을 갖추기 위한 신비롭고 자의적인 기대를 가진 자칭 플랫폼 및 주제 전문가들에 의해 엄격하게 판단될 것이라고 말합니다… 그리고 많은 사람들이 그것을 원하지 않습니다.
그들이 자주 말한 바와 같이, 그들은 사람들이 알고 있고, 연결을 만들고, 바보처럼 느끼게 하지 않으면서 도움을 요청할 수 있는 더 작고 가까운 커뮤니티를 원했습니다. 많은 측면에서, 저는 Discourse가 바로 그것이라고 생각합니다. 열린 끝과 주관적인 주제를 장려하는 더 넓은 형식을 가지면서도 더 고전적인 Q&A 형식을 지원함으로써, 커뮤니티는 그들이 원하는 방식으로 서로를 지원할 수 있습니다.
SO가 지식 도서관을 생성하고 큐레이션하는 가장 좋은 방법이었다면(그렇지 않습니다), Discourse는 (그리고 그래서는 안 됩니다) 그런 종류의 리소스를 시도하고 있지 않습니다. 홈페이지는 Discourse를 "당신의 커뮤니티를 위한 온라인的家"로 홍보합니다. 제가 제 아이들에게 집처럼 느끼게 하고 싶을 때, 저는 그들의 질문을 장려하고 육성하며, 그들이 대화에 참여할 공간을 마련합니다. 제가 그들을 도서관에 데려갈 때, 저는 그들이 조용히 하도록 상기시키고, 선반을 정글 짐처럼 대하지 않도록 막아야 하는 경우가 많습니다.
제 생각에, 질문 투표는 도서관에는 필요할 수 있지만, 집에는 아마도 필요하지 않으며 - 그것은 사람들이 집을 얼마나 즐기는지에 부정적인 영향을 미칠 수 있습니다.
이 섹션은 위 큰 표보다 훨씬 덜 중요합니다, 따라서 그것을 읽지 않았다면, 대신 그것을 읽어보세요. 표는 제가 이 요약에 도달하는 방식을 설명하지만, 제 잘못된 정보로 인한任何问题도 드러낼 것입니다 - 상기하듯, 저는 Discourse 전문가가 아닙니다 - 제가 "Discord"라고 쓰지 않도록 계속 확인합니다. ![]()
같은 주제에서 좋아요와 투표를 혼합하는 것을 피하고 싶은 마음을 이해합니다. ↩︎
경험적으로, 일부 사용자는 질문자를 더 빨리 q-ban되게 하려는 목적으로 질문의 하투표를 과용할 수 있으며, 이는 언밴을 더 어렵게 만들 수도 있습니다. 이러한 시스템에서는 의도치 않은 결과를 고려하고 이를 최소화하는 방법을 찾는 것이 필수적입니다. ↩︎
SO에서 질문 투표에 대해 TED 강의를 할 수 있지만, 많은 SO 사용자가 “정보의 도서관” 개념을 잊어버린 것 같고, "연구 노력을 보여줍니다"라는 호버 텍스트가 이를 악화시켰다고 말할 것입니다. 훌륭한 도서관에는 모든 정보가 있습니다. 도서관이 두 개 마을 떨어져 있다는 이유만으로 도서관에 무언가를 추가하는 것을 거부하는 것은 어리석습니다. ↩︎
또한, "메타에서 투표는 다릅니다"에 대해서는 말도 하지 마세요 - 하지만, 제 해결책이 Discourse와 Q&A를 병합하는 것이므로, 적어도 주제에 맞을 수도 있습니다. ↩︎
SO에서 사람들이 말하는 것과 관계없이, 하투표는 의도적으로 그렇게 해석되지 않더라도 개인적인 느낌을 줍니다. ↩︎
이 비유가 정말 좋습니다. 참고로 내 집은 때때로 도서관처럼 취급되기도 합니다(아이들이 숙제를 할 때), 그리고 도서관은 때때로 놀이 공간처럼 느껴지기도 합니다(커뮤니티 행사를 열 때). 하지만 기본 설정(default)이 중요합니다. 더 나은 방향이든 나쁜 방향이든, Discourse의 기본 설정은 더 이완된 토론 포럼입니다. 이는 대립적(adversarial)이기보다 협력적(collaborative)인 성격을 띱니다. 대부분의 Discourse 커뮤니티에서 Q&A는 예외적인 경우가 될 것입니다.
나는 복합적인 감정을 가지고 있습니다. 저는 다운보팅이 대안보다 더 관대하게 불일치를 표현하는 방법이라고 생각합니다. 다운보팅에 대한 많은 불만을 처리해 본 결과, 사람들이 가장 우려하는 점은 익명의 다운보팅이 연결된 평판 시스템의 맥락에서 부당하게 느껴진다는 것입니다. 사람들은 자신이 왜 다운보팅을 받았는지 알고 싶어합니다. 표면적으로는 문제를 수정하기 위해 알고 싶어합니다. 하지만 현실적으로는, 대부분의 경우 다운보팅한 사람과 논쟁하고 싶고, 그 논쟁에 걸 수 있는 것이 없기 때문이라고 의심합니다. 이는 대개 좋은 일입니다. 왜냐하면 그러한 논쟁은 거의 생산적이지 않기 때문입니다.
특히 질문에 대한 다운보팅은 대부분의 포럼이 협력적인 성격을 띠고 있는 Discourse에서는 더 어려운 적합성을 가집니다. Stack Overflow의 선례 없이 개발되었다면 사람들이 질문 투표 기능을 원할지 확실하지 않습니다. 이상적인 세상에서는 투표가 질문의 품질을 반영해야 합니다:
혹독한 현실은 질문 투표가 주로 커뮤니티가 질문에 대해 느끼는 감정을 반영한다는 것입니다. Stack Overflow에서 NullPointerException 오류에 대해 질문한다면, 얼마나 잘 질문하든 힘든 시간을 보내게 될 것입니다. 이미 백만 번 이상 질문된 주제이며, 사람들은 이 질문의 또 다른 버전에 답하는 데 관심이 없습니다.
아마도 이것이 질문 투표의 특징(feature)이지 버그(bug)가 아닐 수 있습니다. 그렇다면, 이는 커뮤니티가 따라가지 못할 정도로 많은 질문이 있을 때 의미가 있는 특징입니다. 이는 새로 형성된 커뮤니티나 일반적으로 협력적인 포럼이지만 가끔 Q&A로 넘어가는 커뮤니티에는 도움이 되지 않는 특징입니다.换句话说, 저는 질문 투표가 매우 많은 수의 Discourse 커뮤니티에 도움이 된다고 확신하지 못합니다. 따라서 저는 이것이 기본값이 "비활성화"인 설정이어야 한다고 생각합니다.
최근 저는 비디오 AMA를 위해 질문을 수집하고 있는 고객에게 게시물 투표(Post Voting)를 제안했습니다. 이전 시스템은 좋아요에 따라 제출된 상위 X개의 질문을 선택하는 것이었습니다. 질문을 요청한 사람은 질문 요청에 대한 답변을 쉽게 정렬할 수 있는 방법이 없었습니다. 답변이 자동으로 정렬되므로 게시물 투표는 이 용도에 완벽하게 작동합니다. 그러나 포함된 질문 투표는 무의미하고 혼란스럽습니다. 많은 사람들이 AMA를 위해 질문을 제출하기 위해 커뮤니티를 방문하고 있습니다. 좋아요는 유용한 신호가 될 것입니다. 다운보팅? 아마도 실수 클릭이거나 새로운 기능에 대한 실험일 것입니다. 저는 오늘 오후에 CSS를 통해 이를 제거할 예정입니다.[1]
테마와 함께 작동하도록 몇 가지 다른 조정도 해야 하므로, 이 짜증나는 문제를 수정하기에도 좋은 시점입니다. ↩︎
질문 자체에 대한 투표 기능을 제공하려면 토픽 투표 플러그인을 사용하는 것이 적절할까요? 아니면 제가 오해하고 있는 건가요?