여러분들은 신뢰 등급별로 허용할 합리적인 표의 수를 어떻게 생각하시나요? 메타 사이트에서 TL0은 2표에서 0표로, TL4는 10표에서 8표로 변경된 것을 봤습니다. 여기에서 관리자이긴 한데, 제 표도 소진된 걸 확인했습니다! 
2개의 좋아요
저는 항상 이 숫자가 의도적으로 제한되어 있어, 일종의 ‘이건 정말 중요해요’라는 표시로 기능한다고 생각해 왔어요. 표가 다 떨어져도 여전히 모든 요청에 좋아요를 누르고, 기능 요청에 제 사용 사례를 추가할 수 있습니다. 그리고 제가 투표한 다른 기능 요청이 완료되고 해당 주제가 닫히면, 이 주제에 다시 투표할 수도 있어요.
1개의 좋아요
@tobiaseigen, 저는 그들을 제한하지 않을 것 같아요… 저에게 '좋아요’가 있는 상황에서, 어떤 것이 나에게 진지하게 중요한지 가늠해 보는 것은 특히 실용적이지 않은 시간 낭비라고 생각하기 때문에, 저는 투표를 거의 사용하지 않습니다. 제게는 단순히 지지하거나 반대하는 것뿐이니까요.
비교하자면, Bugzilla에서는 일부 인스턴스만 투표 수를 제한할 뿐, 많은 인스턴스에서는 제한하지 않습니다.
2개의 좋아요
최근 이 토론을 Jammydodger의 원래 스레드로 옮겼습니다. Contribute > Feature 투표에 대해 여기서 계속 이야기하는 것이 적절하다고 느껴서입니다.
투표 수 제한이라는 아이디어는 좋지만, 공개된 기능 요청이 워낙 많아서 제한을 너무 낮게 설정하는 것은 공정하지 않다고 생각합니다. 저도 이 제한에 막혀서 답답함을 느낍니다. 또한 투표는 일종의 신호이기도 한데, 사람들이 투표할 수 없게 하면 제품 팀이 그 신호를 받지 못하게 됩니다.
아래와 같이 제한을 높이는 방향으로 기울어 있습니다. 여러분은 어떻게 생각하시나요?
| 신뢰 수준 | 현재 투표 수 | 제안된 투표 수 |
|---|---|---|
| TL0 | 0 | 0 |
| TL1 | 4 | 10 |
| TL2 | 6 | 20 |
| TL3 | 8 | 24 |
2개의 좋아요
IMO 24 덕분에 사실상 무제한이 됩니다.
현재 제한은 생각하게 만들어서 좋다고 생각합니다.
2개의 좋아요
엄격한 표 수 제한이 정보의 제한으로 이어지는 건 아닌지 궁금합니다. 여기 사용자 수에 비해 표 수(Votes)가 대체로 낮은 편입니다. 많은 기능 제안들이 '좋아요(Likes)'보다 표 수가 적지만, 표 수만 주목받는 것 같습니다.
항상 표가 부족하고 새로운 항목에 표를 던지기 위해 항상 선별하고 포기해야 하는 상황은 상당한 장벽이 됩니다. 기존에 던진 표를 검토하여 표를 확보할 방법을 찾아보지만… 어떤 요청도 부족한 것이 아닙니다. 그저 피드에서 밀려나 잊혀진 것뿐입니다.
그냥 포기해야 하나요?
내가 좋아하는 항목에 댓글을 달아 올려야 할까요? 이미 표를 던진 기능에 "네, 좋은 아이디어네요!"라고 댓글을 남기는 것은 불필요한 노이즈처럼 느껴집니다.
좋은 아이디어들은 1~2표에 머물러 있습니다. 사람들이 발견하지 못해서, 관심이 없어서, 아니면… 그냥 표가 없어서일까요? 
한도를 늘리는 것은 많은 코딩 작업이 필요하지 않을 것 같고 도움이 될 것 같습니다. 하지만 도로를 넓히면 교통 체증이 줄어든다기보다 오히려 더 많은 교통량이 유입되어 결국 원점으로 돌아가는 것과 같은 맥락이라고도 생각합니다.
단순한 아이디어를 던져 봅니다… 하드 리밋(고정 한도)의 대안으로, 상당한 코딩 작업이 필요한 기능 변경 사항들입니다:
- TL(Trust Level)에 기반하여 월별 표 수를 배정합니다. ("표 던지는 날"에는 사람들이 Contribute > Feature 채널을 방문해 미해결 항목들을 평가하느라 분주해집니다…)
…또는 heliosurge가 언급했듯, 시간이 지나면 표를 해제하는 방식도 가능합니다:
- 일정 시간이 지나면 사용된 표를 해제하거나,
- 스태프가 오래된 기능 요청들을 주기적으로 검토하여 a.) 토픽을 올려 다시 기회를 주거나, b.) "처리 계획 없음"이라는 댓글을 달고 표를 해제합니다.
…어떤 경우든 이미 던진 표는 그 자리에 남아있으며, 사용자가 이러한 토픽들의 표를 거두어(언보팅) 자신의 표 할당량을 초과할 수는 없습니다.
(제가 말하기는 쉽지만. 아마 상당한 코딩 작업이 필요할 겁니다 
)
2개의 좋아요
@sam, 저는 좋아요만 사용해서 그런 기능이 필요 없어요. 현재 구현 방식이 좀 중복된 느낌이 들어요 – GitHub Discussions에서 업보트와 엄지척이 동시에 존재하는 것과 비슷하죠. 저에게는 중요한 내용을 정리하기 위해 이미 북마크를 사용하고 있어요.
2개의 좋아요
중복된 신호가 혼란을 초래한다는 데 동의합니다.
“기능 요청을 작성한 방식이 마음에 듭니다. 저한테도 괜찮아 보입니다”
Vs
“이건 제 생각에 discourse가 만들어야 할 상위 8개 항목에 확실히 들어갈 것 같습니다”
토픽 투표가 활성화되어 있을 때 운영자(관리자)의 좋아요를 비활성화하는 것도 흥미로운 실험이 될 수 있습니다.
1개의 좋아요
일부 요청에 “죄송합니다. 이 기능을 만들지 않겠습니다”라고 닫는 것에는 뭔가 묘한 점이 있습니다.
2년 전에 이미 완료된 기능을 완료 처리로 닫고, 더 이상 어떤 의미도 없는 기능 요청을 오래된 것으로 처리하는 것은 분명히 매우 설득력 있는 일입니다.
2개의 좋아요
결국 크게 달라지지 않을 것 같습니다. 제 표의 대부분은 1년 전에 추가된 것이었으니까요. 네, 더 많은 주제에 투표할 수는 있었겠지만, 제 표를 모두 소진한 후에는 다시 똑같은 상황이 됩니다: 한 표가 완료되고 폐쇄될 때까지 기다리거나, 다른 주제에서 제 표를 철회해야 하니까요. 메타(Meta)에는 20개 이상의 훌륭한 기능 요청이 더 있을 것이라고 확신합니다. 
이전에 말했듯이, 저에게 표는 '좋아요’보다 더 강력한 의미를 가집니다. 하지만 여전히 첫 번째 게시물에 대한 '좋아요’가 관심을 끌기에 매우 유용하다고 생각합니다. 투표 기능이 활성화되기 전 10년 이상 동안 '좋아요’는 관심을 나타내는 지표였습니다. 따라서 이를 무시하는 것, 특히 오래된 요청의 경우를 무시하는 것은 당시 사용자가 지지를 표명할 수 있었던 유일한 방식을 무시하는 것이나 다름없습니다.
또한, 아무도 그 기능 요청이 표를 쓸 만큼 절실히 필요하다고 생각하지는 않을 수 있지만, 도움이 될 것이라고 생각하여 많은 사용자가 '좋아요’를 누릅니다. 한 표(보통 요청 작성자가 누르는)가 다양한 디스코urs 사이트에서 해당 기능이 얼마나 유용할지에 대해 여러 개의 '좋아요’보다 더 많은 정보를 제공합니까?
'이 기능에 정말 관심이 있다’는 표의 수를 늘리는 대신, 표를 분산시킬 수 있는 주제 수를 제한하는 것이 더 나을지 궁금합니다.
따라서 올해 투표 대상인 378개[1] 주제 대신, 사전에 선별하는 것이 합리적일 수 있습니다.
예를 들어, 여러 사용자의 관심을 나타내는 특정 양의 반응(리액션)을 받은 요청만 투표 대상으로 하거나, 시간으로 제한하여 특정 기간의 주제에 한해 투표를 제한하여 그 그룹 내에서 인기 있는 기능을 찾는 것도 방법입니다.
또는 '리뷰 대기열을 재검토하고 있습니다. 어떤 요청이 떠오르나요?'라고 말하고, 그런 요청들을 하위 범주로 이동시켜 투표하게 할 수도 있습니다.
약 100개의 주제에 4개의 표를 쓸 수 있는 것은 모든 열린 기능 주제에 10개의 표를 쓸 수 있는 것보다 비율적으로 더 큰 영향력을 가집니다.
3개의 좋아요
@sam, 저는 정반대의 의견을 가지고 있습니다 – 투표의 가치를 크게 느끼지 못하거든요. 좋아요와 달리 투표가 기술적으로 어떤 이점을 제공하는가요? 자신이 지지하지 않는 FR(기능 요청)에 좋아요를 누르는 사람은 거의 없을 거라고 봅니다. 일부 Discourse 인스턴스는 투표를 사용하지 않고, 대신 “
”와 “
”를 유일한 반응 옵션으로 제공합니다.
투표가 활성화될 때 좋아요가 비활성화된다면, 그것은 확실히 “정보를 감소”시킬 것이라고 생각합니다. 비교하자면, Forgejo와 GitLab이 업보팅을 제한하지 않는다는 사실은, 그것들이 단순한 지지/비지지 지표로서 가치를 가진다는 점을 시사할 수 있습니다.
오늘 호기심에 Contribute > Feature 채널을 둘러보았는데, 다음과 같은 필터링된 뷰를 비교해 보는 것이 흥미로웠습니다:
Votes와 Likes를 모두 포함하는 Data Explorer 쿼리로 무엇을 할 수 있을까 궁금합니다… 
그리고:
자동화 아이디어: 좋아요(Likes) 기반의 “주요” 풀을 만들어 요청을 투표 가능 상태로 승격시키는 방안을 고려해 볼 수 있습니다.
수동 큐레이션 아이디어: 때때로 명확한 가치가 있는 요청은 투표 수와 관계없이 스태프에 의해 채택되므로, 어느 정도 큐레이션이 이미 이루어지고 있다고 볼 수 있습니다. 하지만 모든 요청이 빠른 스태프 검토를 거치는 것이 더 나은 방법일까요?
지원 사례: "사용자가 자신의 주제를 닫을 수 있게 해주세요
팀이 투표 대상 주제를 목록으로 정리한 후 투표를 공개한다면 이 제한은 괜찮을 것이다. 예를 들어 분기별로 투표를 공개하는 것도 방법이다. 업데이트에서는 팀이 로드맵에 추가하기로 선택한 기능들과 우선순위 기준의 예상 시간표까지 자세히 설명할 수 있을 것이다.
그렇지 않으면 24회라고 해서 정말 무제한은 아니다. 어떤 투표들은 1년 넘게, 어쩌면 더 오래 묶여 있기 때문이다. 고려조차 되지 않을 것 같은 사실상 죽은 기능에서 투표를 제거하려고 시도하는 것도 고역이다.
가끔씩 팀이 강력히 고려하고 있는 기능 목록을 만들고, 사람들이 투표할 수 있는 설문을 진행한 후, 그 결과를 반영해 업데이트하는 것도 좋은 아이디어일 수 있습니다. 토픽 투표는 나쁘지 않지만, 릴리스 사이클이 존재합니다. 그 사이클이 어떻게 되어야 하는지는 팀이 논의하고 결정해야 할 사항입니다.
잘 모르겠는데, 더 이상 중요하지 않은 사안에 대한 투표는 공개할 수 없나요?
이는 이전에 투표가 이루어진 항목들이 이미 구현되었거나 더 이상 중요하지 않다는 전제 하에 성립합니다.
팀이 향후 추가를 고려 중인 기능 요청들을 목록으로 정리하고, 해당 투표들을 다시 활용 가능하게 하는 것이 개인적으로 타당하다고 생각합니다.
왜 굳이 토픽 투표를 사용해야 할까요? 언급하신 대로, 고정된 투표 수에 제한되는 대신 좋아요/반응을 활용할 수 있습니다. 예를 들어 
와 같은 특정 반응을 사용하면, 해당 Contribute 기능 요청에 대한 관심을 가늠하는 데 충분할 수 있습니다. 이 카테고리에서 특정 반응이 가장 많이 달린 상위 토픽(예: OP 게시글)을 반환하도록 데이터 탐색 스크립트를 사용할 수 있기 때문입니다.
반면, 투표에 제한을 두는 방식은 실제로는 어디로 향하는지 느껴지지 않습니다. 제 경험상 이 카테고리와 직접적으로 관련된 업데이트가 없었기 때문입니다. 가끔 업데이트가 있을 수는 있지만, 제가 그냥 알아채지 못한 것일 수도 있습니다.
최근 출시된 새로운 기능들 중 일부가 한때 기능 요청이었을 가능성이 높다고 생각합니다.
개인적으로 토픽 투표는 특정 마감일과 함께 상위 X개 토픽을 투표하여 발표일에 상위 3개 수상자를 발표하는 콘테스트에 더 적합하다고 생각합니다. 하지만 이 카테고리에서는 명확한 결론이 없는 콘테스트처럼 느껴지며, 자신의 투표를 다시 한번 더 고민해야 하는 상황이 됩니다.
1개의 좋아요
여기서 프로세스에 대해 여러 번 댓글을 달았지만, 공평하게 말하자면 completed 태그가 붙은 기능 요청이 많이 있습니다 – 카테고리:feature 태그:completed에 대한 필터링된 결과
2개의 좋아요
완료 태그는 확실히 도움이 됩니다. 하지만 팀이 기능 요청에 대한 관심을 더 깊이 파악하고 싶다면, 투표 수를 제한하는 것은 오히려 역효과를 낼 수 있습니다.
샘이 언급했듯이 좋아요/반응과 같은 다양한 신호를 활용할 수 있습니다. (특정 반응을 선택) 또는 아예 투표 제한을 두지 않는 것도 방법입니다. 모든 아이디어에 사람들이 투표하거나 반응하는 것은 아니기 때문입니다. 특정 아이디어에 관심이 없다면 참여하지 않을 수 있으니까요. 예를 들어, 저는 포럼 팀을 선거로 뽑자는 요청이 있는 것으로 알고 있습니다.
일부 포럼에서는 이것이 하나의 아이디어나 옵션이 될 수 있지만, 많은 사람들이 인기 투표로 포럼을 운영하는 사람이 결정되는 상황을 원하지 않을 것입니다.
따라서 특정 수로 제한하는 것은 관심도를 분산시켜 동점 상황이 훨씬 많이 발생하기 쉽습니다. 반면, 투표/반응 수가 많은 기능은 전체 커뮤니티의 관심 수준을 더 잘 반영합니다.
1개의 좋아요
태그를 검토하면 실제로 얼마나 많은 항목이 추가되었는지 파악하는 데 도움이 됩니다. 다만, 표결 참여를 제한하는 것은 지나치게 엄격하게 느껴집니다. 완료된 일부 기능조차도 표결 수가 거의 없거나 아예 없었거든요. 물론 간단하고 쉬운 개선 사항은 당연히 좋은 것이지만요.
여기서 제가 꿈꾸는 것은 모든 사용자가 기능에 대한 개인화된 순위 기반 뷰를 가질 수 있도록 하는 것입니다. 그런 다음 다양한 '렌즈’를 통해 이러한 뷰를 집계하여 다른 집합적 뷰를 만들 수 있기를 바랍니다.
즉, 모든 항목에 대해 단순한 찬성/반대 투표를 하는 대신, 제가 ‘톱 10’ 목록을 만들어 선호도에 따라 순서를 정해 보여줄 수 있습니다. 여러분도 같은 방식으로 할 수 있습니다. 그리고 나서 저는 ‘지난 1년 동안 메타에 가입한 사람들의 토크 10 목록을 보여줘’ 또는 '스타터 플랜으로 호스팅 중인 사람들의 토크 10 목록을 보여줘’와 같은 요청을 할 수 있게 됩니다.
그동안, 여기에서 일을 조금 더 관리하기 쉽게 만드는 방법에 대한 다른 아이디어들이 있습니다. 이는 오픈 로드맵과 백로그를 더 일반적으로 관리하는 방식과 관련이 있습니다. 여기에는 버그, 기능, UX 카테고리를 관리하는 방식의 변경 사항과, 우리가 작업할 계획이 있거나 기여를 환영하는 항목에 대해 더 구체적인 제안 및/또는 스펙과 더 열린 아이디어 구상을 어떻게 분리할 것인지에 대한 내용이 포함됩니다.
연말 전에 이에 대한 RFC(요구사항 제안서)를 작성하여 논의하기 위해 노력하고 있습니다.
4개의 좋아요