What do folks think is a reasonable number of votes to allow per trust level? I see on meta we have changed TL0 from 2 to zero votes and TL4 from 10 to 8. I noticed that I am out of votes myself, even though I am admin here! 
2개의 좋아요
I have always thought that the number is deliberately limited so that it works as a kind of ‘this is really important to me’ indicator. I can still like all requests and add my use case to feature requests even if I run out of votes. And I can still vote on these topics once another feature request I voted for is completed and the topic is closed.
1개의 좋아요
@tobiaseigen, I wouldn’t limit them… I find myself never using votes because, to me, I either merely support or oppose something; trying to ascertain whether something is seriously important to me just isn’t a particularly pragmatic use of my time, when likes exist instead.
For comparison, on Bugzilla, although some instances limit votes, many don’t.
2개의 좋아요
최근 이 토론을 Jammydodger의 원래 스레드로 옮겼습니다. Contribute > Feature 투표에 대해 여기서 계속 이야기하는 것이 적절하다고 느껴서입니다.
투표 수 제한이라는 아이디어는 좋지만, 공개된 기능 요청이 워낙 많아서 제한을 너무 낮게 설정하는 것은 공정하지 않다고 생각합니다. 저도 이 제한에 막혀서 답답함을 느낍니다. 또한 투표는 일종의 신호이기도 한데, 사람들이 투표할 수 없게 하면 제품 팀이 그 신호를 받지 못하게 됩니다.
아래와 같이 제한을 높이는 방향으로 기울어 있습니다. 여러분은 어떻게 생각하시나요?
| 신뢰 수준 | 현재 투표 수 | 제안된 투표 수 |
|---|---|---|
| TL0 | 0 | 0 |
| TL1 | 4 | 10 |
| TL2 | 6 | 20 |
| TL3 | 8 | 24 |
2개의 좋아요
Imo 24 turns this into practically unlimited
I like the current limits, makes you think
2개의 좋아요
엄격한 표 수 제한이 정보의 제한으로 이어지는 건 아닌지 궁금합니다. 여기 사용자 수에 비해 표 수(Votes)가 대체로 낮은 편입니다. 많은 기능 제안들이 '좋아요(Likes)'보다 표 수가 적지만, 표 수만 주목받는 것 같습니다.
항상 표가 부족하고 새로운 항목에 표를 던지기 위해 항상 선별하고 포기해야 하는 상황은 상당한 장벽이 됩니다. 기존에 던진 표를 검토하여 표를 확보할 방법을 찾아보지만… 어떤 요청도 부족한 것이 아닙니다. 그저 피드에서 밀려나 잊혀진 것뿐입니다.
그냥 포기해야 하나요?
내가 좋아하는 항목에 댓글을 달아 올려야 할까요? 이미 표를 던진 기능에 "네, 좋은 아이디어네요!"라고 댓글을 남기는 것은 불필요한 노이즈처럼 느껴집니다.
좋은 아이디어들은 1~2표에 머물러 있습니다. 사람들이 발견하지 못해서, 관심이 없어서, 아니면… 그냥 표가 없어서일까요? 
한도를 늘리는 것은 많은 코딩 작업이 필요하지 않을 것 같고 도움이 될 것 같습니다. 하지만 도로를 넓히면 교통 체증이 줄어든다기보다 오히려 더 많은 교통량이 유입되어 결국 원점으로 돌아가는 것과 같은 맥락이라고도 생각합니다.
단순한 아이디어를 던져 봅니다… 하드 리밋(고정 한도)의 대안으로, 상당한 코딩 작업이 필요한 기능 변경 사항들입니다:
- TL(Trust Level)에 기반하여 월별 표 수를 배정합니다. ("표 던지는 날"에는 사람들이 Contribute > Feature 채널을 방문해 미해결 항목들을 평가하느라 분주해집니다…)
…또는 heliosurge가 언급했듯, 시간이 지나면 표를 해제하는 방식도 가능합니다:
- 일정 시간이 지나면 사용된 표를 해제하거나,
- 스태프가 오래된 기능 요청들을 주기적으로 검토하여 a.) 토픽을 올려 다시 기회를 주거나, b.) "처리 계획 없음"이라는 댓글을 달고 표를 해제합니다.
…어떤 경우든 이미 던진 표는 그 자리에 남아있으며, 사용자가 이러한 토픽들의 표를 거두어(언보팅) 자신의 표 할당량을 초과할 수는 없습니다.
(제가 말하기는 쉽지만. 아마 상당한 코딩 작업이 필요할 겁니다 
)
2개의 좋아요
@sam, it doesn’t for me, since I just use likes. Its current implementation feels a little redundant – rather like the upvote and thumbs-up both existing for GitHub Discussions. I’ve already bookmarks to keep track of what matters to me.
2개의 좋아요
Agree having duplicate signal is confusing
“I like how you wrote the feature request, sounds good to me”
Vs
“This is certainly in my top 8 I think discourse should build””
It may be an interesting experiment to disable op likes when topic voting is enabled
1개의 좋아요
There is something about closing some requests with “sorry we are not doing this”
There is certainly something extremely compelling about closing 2 year completed features as done, and feature requests that no longer makes any kind of sense as stale.
2개의 좋아요
I don’t think it would change that much in the end. Most of my votes were added a year ago. Yes, I would have been able to vote on more topics, but once I have spent all my votes it’s the same again: I would have to wait for one to be completed and closed, or I need to remove my vote from a different topic. I am quite sure there are also more than 20 good feature requests on Meta 
As I said before, to me votes are something stronger than a like. But I still think likes on the first post are also very helpful to capture interest. They have been the indicator for more than 10 years when voting wasn’t enabled. So ignoring them, especially on long-standing requests, means ignoring the only way users were able to show support back then.
Also, maybe no one thinks the feature request is something they need that much to spend a vote on it, but lots of users like it because they think it would be helpful. Does one vote (usually by the author of the request) say more about how helpful that feature would be for a range of different Discourse sites than multiple likes?
I wonder whether, instead of increasing the number of ‘I’m really interested in this’ votes, it would be better to limit the number of topics they can be distributed across.
So instead of having 378[1] topics from this year to vote on, it might make sense to pre-select them.
For example, only requests with a certain amount of reactions indicating interest from multiple users are those that can be voted on, or you could limit it by time and say that voting is restricted to topics from a certain time period in order to find the favorites within that group of features.
You could also say, ‘We’re revising the review queue. What requests come to mind?’ Then those would be moved to a subcategory and voted on.
Being able to spend 4 votes on ~100 topics would be proportionally more than being able to spend 10 votes on all open feature topics.
3개의 좋아요
@sam, I was hoping for the opposite – I don’t much see the value in votes. Do votes provide something, technically, that likes don’t? I doubt anyone likes an FR that they don’t support. Some Discourse instances don’t utilise votes, and, instead, provide “
” and “
” as the sole available reactions.
If likes were disabled when votes were enabled, that would “reduce intel”, I believe. For comparison, that Forgejo and GitLab don’t limit upvotes might indicate that value in having them as a simple support versus don’t support indicator exists.
오늘 호기심에 Contribute > Feature 채널을 둘러보았는데, 다음과 같은 필터링된 뷰를 비교해 보는 것이 흥미로웠습니다:
Votes와 Likes를 모두 포함하는 Data Explorer 쿼리로 무엇을 할 수 있을까 궁금합니다… 
그리고:
자동화 아이디어: 좋아요(Likes) 기반의 “주요” 풀을 만들어 요청을 투표 가능 상태로 승격시키는 방안을 고려해 볼 수 있습니다.
수동 큐레이션 아이디어: 때때로 명확한 가치가 있는 요청은 투표 수와 관계없이 스태프에 의해 채택되므로, 어느 정도 큐레이션이 이미 이루어지고 있다고 볼 수 있습니다. 하지만 모든 요청이 빠른 스태프 검토를 거치는 것이 더 나은 방법일까요?
지원 사례: "사용자가 자신의 주제를 닫을 수 있게 해주세요
The limit would be fine if the team released the votes after composing a list of voted upon topics. Maybe release the votes Quarterly. The update could even detail features the team have chosen to add to the roadmap with a potential timeline in terms of priority.
Otherwise 24 really isn’t unlimited as some votes have. Tied up for over a year and possibly more. It is a pain to also try to go and remove votes in seemingly dead features that might not even being considered.
Maybe an idea is to once in awhile create. List if features the team is strongly considering and create a poll for ppl to vote on and then update things from there. Topic voting is not bad ud there is a release cycle. What that cycle should be is something the team needs to dkscuss and decide on
not following, can’t you release votes on stuff that is no longer important to you?
이는 이전에 투표가 이루어진 항목들이 이미 구현되었거나 더 이상 중요하지 않다는 전제 하에 성립합니다.
팀이 향후 추가를 고려 중인 기능 요청들을 목록으로 정리하고, 해당 투표들을 다시 활용 가능하게 하는 것이 개인적으로 타당하다고 생각합니다.
왜 굳이 토픽 투표를 사용해야 할까요? 언급하신 대로, 고정된 투표 수에 제한되는 대신 좋아요/반응을 활용할 수 있습니다. 예를 들어 
와 같은 특정 반응을 사용하면, 해당 Contribute 기능 요청에 대한 관심을 가늠하는 데 충분할 수 있습니다. 이 카테고리에서 특정 반응이 가장 많이 달린 상위 토픽(예: OP 게시글)을 반환하도록 데이터 탐색 스크립트를 사용할 수 있기 때문입니다.
반면, 투표에 제한을 두는 방식은 실제로는 어디로 향하는지 느껴지지 않습니다. 제 경험상 이 카테고리와 직접적으로 관련된 업데이트가 없었기 때문입니다. 가끔 업데이트가 있을 수는 있지만, 제가 그냥 알아채지 못한 것일 수도 있습니다.
최근 출시된 새로운 기능들 중 일부가 한때 기능 요청이었을 가능성이 높다고 생각합니다.
개인적으로 토픽 투표는 특정 마감일과 함께 상위 X개 토픽을 투표하여 발표일에 상위 3개 수상자를 발표하는 콘테스트에 더 적합하다고 생각합니다. 하지만 이 카테고리에서는 명확한 결론이 없는 콘테스트처럼 느껴지며, 자신의 투표를 다시 한번 더 고민해야 하는 상황이 됩니다.
1개의 좋아요
I’ve commented a bunch on the process here, but to be fair, there are lots of feature requests tagged as completed – Filtered results for category:feature tag:completed
2개의 좋아요
The completed tag does help. But I find if the team wants to gauge more interest in feature requests. Limiting the number of votes can be counter productive.
As Sam mentioned with the various signals like the Like/Reactions. (Choose a specific reaction) Or even no vote limits. As not all Ideas will ppl vote/react to as they may not be interested in a specific idea. For example there is I believe a request for Electing a forum team.
While on some forums that might be an idea/option many would not want to have a potential popularity contest decide on who controls the forum.
So you will still get Features with more votes/reaction signifying level of community interest overall vs limiting to set number which is more likely to split interest and have much more Tied so to speak.
1개의 좋아요
Reviewing the tag does indeed help.to see how much has been added. It just feels too restrictive to limit vote interest. Even some of the features completed had minimal to no votes. Granted easy simple wins are if course good.
My dream here would be for everyone to have their own, personalized , stack ranked view(s) of features, which we could then aggregate into different collective views through different “lenses”.
So, rather than have it be a binary vote/non-vote in everything, I’d be able to put together my “top 10” list, and show them in order of preference. You’d be able to do the same. And then I could do things like “show me the top ten list for people who have joined meta in the last year” or “show me the top ten list for people who are hosted on our starter plan”, etc.
In the meantime, I’ve got some other ideas for how we can make things a bit more manageable here, which tie into ideas of how we manage an open roadmap and backlog more generally. These involve some changes in how we manage the bug, feature, and ux categories, and how we separate more open ideation from more concrete proposals and/or specs for things we either are planning to work on or would be happy to see contributed.
I’m hoping to get something like an RFC put together for this for discussion before the end of the year.
4개의 좋아요