O que as pessoas acham que é um número razoável de votos a serem permitidos por nível de confiança? Vejo que no meta mudamos o TL0 de 2 para zero votos e o TL4 de 10 para 8. Notei que estou sem votos, mesmo sendo administrador aqui! 
2 curtidas
Sempre pensei que o número é deliberadamente limitado para funcionar como um tipo de indicador de ‘isso é realmente importante para mim’. Ainda posso gostar de todas as solicitações e adicionar meu caso de uso a solicitações de recursos, mesmo que fique sem votos. E ainda posso votar nesses tópicos assim que outra solicitação de recurso em que votei for concluída e o tópico for fechado.
1 curtida
@tobiaseigen, eu não os limitaria… Eu me pego nunca usando votos porque, para mim, eu simplesmente apoio ou me oponho a algo; tentar determinar se algo é seriamente importante para mim não é um uso particularmente pragmático do meu tempo, quando curtidas existem em vez disso.
2 curtidas
Movi esta discussão recente para a original de Jammydodger porque parece certo continuar falando aqui sobre votação.
Gosto da ideia de limites, mas também acho que há tantos pedidos de recursos abertos que parece injusto ter um limite muito baixo. Eu me sinto limitado por isso! Votos também são um sinal, e ao não deixar as pessoas votarem, estamos privando a equipe de produto desse sinal.
Estou inclinado a aumentar os limites nas linhas abaixo. O que vocês acham?
| Nível de Confiança | Votos Atuais | Votos Propostos |
|---|---|---|
| TL0 | 0 | 0 |
| TL1 | 4 | 10 |
| TL2 | 6 | 20 |
| TL3 | 8 | 24 |
2 curtidas
Imo 24 transforma isso em praticamente ilimitado
Gosto dos limites atuais, faz você pensar
2 curtidas
Eu me pergunto se o racionamento rigoroso de votos preciosos resulta em informações limitadas. As contagens de votos geralmente parecem baixas para o número de usuários aqui. Muitas sugestões de recursos têm mais curtidas do que votos, mas imagino que apenas os votos são notados.
Estar perpetuamente sem votos e sempre ter que priorizar e sacrificar para votar em qualquer coisa nova é uma barreira significativa. Eu reviso meus votos existentes para ver como posso liberar votos… mas nenhuma das solicitações é indigna. Elas simplesmente saíram do feed e foram esquecidas.
Devo desistir delas?
Devo dar um empurrãozinho nos meus favoritos com um comentário? Tendo votado em um recurso, comentar “Sim, boa ideia!” parece um acúmulo supérfluo.
Boas ideias ficam com um ou dois votos. As pessoas não as estão descobrindo, não estão interessadas, ou… elas simplesmente estão sem votos? 
Aumentar os limites não exigiria um monte de codificação e parece que ajudaria – mas também penso em como alargar uma estrada para reduzir o tráfego apenas convida mais tráfego e você volta ao ponto de partida.
Apenas pensando alto… algumas mudanças funcionais que exigiriam um monte de codificação como alternativas a um limite rígido:
- Alocar um número de votos por mês com base no TL. (No “dia dos votos” há uma enxurrada de atividade enquanto as pessoas visitam Feature e avaliam os itens abertos…)
…ou, como heliosurge mencionou, eventualmente liberar votos:
- Liberar um voto usado após um tempo determinado, ou
- A equipe revisa solicitações de recursos antigas em uma base contínua e ou a.) dá um empurrãozinho no tópico para outra chance, ou b.) comenta com “sem planos de abordar” e libera os votos.
…Em qualquer um dos casos, os votos lançados permanecem no lugar, e os usuários não podem exceder sua alocação de votos desvotando ainda mais esses tópicos.
(Fácil para eu dizer. Provavelmente é muita codificação 
)
2 curtidas
@sam, para mim não, já que eu só uso curtidas. Sua implementação atual parece um pouco redundante – bem como a existência de “upvote” e “joinha” para Discussões do GitHub.
2 curtidas
Concordo que ter sinais duplicados é confuso
“Gosto de como você escreveu a solicitação de recurso, parece bom para mim”
Vs
“Este certamente está entre os meus 8 principais que acho que o Discourse deveria construir”
Pode ser um experimento interessante desabilitar os “likes” do OP quando a votação de tópicos estiver habilitada.
1 curtida
Há algo sobre fechar algumas solicitações com “desculpe, não vamos fazer isso”
Certamente há algo extremamente atraente em fechar recursos concluídos há 2 anos como feitos, e solicitações de recursos que não fazem mais sentido como desatualizadas.
2 curtidas
Não acho que mudaria muito no final. A maioria dos meus votos foi adicionada há um ano. Sim, eu teria sido capaz de votar em mais tópicos, mas depois que gastei todos os meus votos, é a mesma coisa novamente: eu teria que esperar que um fosse concluído e fechado, ou eu preciso remover meu voto de um tópico diferente. Tenho certeza de que também existem mais de 20 bons pedidos de recursos no Meta 
Como eu disse antes, para mim, votos são algo mais forte do que um “curtir”. Mas eu ainda acho que “curtidas” na primeira postagem também são muito úteis para capturar interesse. Elas têm sido o indicador por mais de 10 anos quando a votação não estava habilitada. Portanto, ignorá-las, especialmente em solicitações de longa data, significa ignorar a única maneira que os usuários podiam mostrar apoio naquela época.
Além disso, talvez ninguém ache que o pedido de recurso seja algo que eles precisam tanto para gastar um voto, mas muitos usuários gostam porque acham que seria útil. Um voto (geralmente do autor do pedido) diz mais sobre o quão útil esse recurso seria para uma variedade de sites diferentes do Discourse do que várias curtidas?
Eu me pergunto se, em vez de aumentar o número de votos de “Estou realmente interessado nisso”, seria melhor limitar o número de tópicos em que eles podem ser distribuídos.
Então, em vez de ter 378[1] tópicos deste ano para votar, pode fazer sentido pré-selecioná-los.
Por exemplo, apenas solicitações com uma certa quantidade de reações indicando interesse de vários usuários são aquelas que podem ser votadas, ou você pode limitá-lo por tempo e dizer que a votação é restrita a tópicos de um determinado período para encontrar os favoritos dentro desse grupo de recursos.
Você também poderia dizer: “Estamos revisando a fila de revisão. Quais solicitações vêm à mente?” Então, essas seriam movidas para uma subcategoria e votadas.
Ser capaz de gastar 4 votos em ~100 tópicos seria proporcionalmente mais do que ser capaz de gastar 10 votos em todos os tópicos de recursos abertos.
\n
↩︎
3 curtidas
@sam, eu esperava o oposto. Os votos fornecem algo, tecnicamente, que os likes não fornecem? Duvido que alguém goste de um FR que não apoia.
Se os likes fossem desabilitados quando os votos fossem habilitados, isso “reduziria a inteligência”, eu acredito. Para comparação, o fato de Forgejo e GitLab não limitarem os upvotes pode indicar que existe valor em tê-los como um simples indicador de apoio versus não apoio.
Explorando a Feature hoje por curiosidade, foi interessante comparar estas visualizações filtradas:\n- Resultados filtrados para categoria:feature status:open order:likes-op\n- Resultados filtrados para categoria:feature status:open order:votes\n\nEu me pergunto o que poderia ser feito com uma consulta no Data Explorer (Explorador de Dados) incluindo tanto Votos quanto Curtidas… 
\n\nAlém disso:\n[quote="Moin, post:30, topic:308402"]\nem vez de ter 378 tópicos deste ano para votar, pode fazer sentido pré-selecioná-los\n[/quote]\n\nPensamento de automação: talvez um grupo “principal” baseado em Curtidas pudesse escalar solicitações para o status de votável.\n\nPensamento de curadoria manual: ocasionalmente, uma solicitação com mérito óbvio é capturada pela equipe, independentemente dos votos, então, de certa forma, alguma curadoria já acontece. Mas talvez tudo devesse passar por uma rápida revisão da equipe?\n\nExemplo de suporte: Encontrei 8 solicitações de funcionalidade sobre “permitir que os usuários fechem seus próprios tópicos” – de 2014 a 2025 – algumas fechadas, mas a maioria aberta com 0 votos. Algo não está funcionando bem se o mesmo pedido é feito repetidamente enquanto versões mais antigas passam despercebidas e sem votos.\n\nSe os usuários não estão pesquisando — ou vendo os diálogos “seu tópico é semelhante…” — não tenho certeza do que mais poderia ser feito além de fazer com que as solicitações iniciais cheguem a um ponto de verificação da equipe: 
se for novo, mover o tópico para uma categoria de votação; 
se existir uma solicitação semelhante, responder com um link.\n\nApenas pensando em voz alta. Sei que tudo consome recursos…
O limite seria bom se a equipe divulgasse os votos depois de compor uma lista de tópicos votados. Talvez divulgar os votos trimestralmente. A atualização poderia até detalhar os recursos que a equipe escolheu adicionar ao roteiro com um potencial cronograma em termos de prioridade.
Caso contrário, 24 realmente não é ilimitado, pois alguns votos estão presos por mais de um ano e possivelmente mais. É um incômodo também tentar remover votos em recursos aparentemente inativos que talvez nem estejam sendo considerados.
Talvez uma ideia seja criar de vez em quando uma lista de recursos que a equipe está considerando seriamente e criar uma enquete para as pessoas votarem e depois atualizar as coisas a partir daí. A votação de tópicos não é ruim se houver um ciclo de lançamento. Qual deve ser esse ciclo é algo que a equipe precisa discutir e decidir.
não entendi, vocês não podem divulgar votos sobre coisas que não são mais importantes para vocês?
Isso pressupõe que as coisas votadas anteriormente foram implementadas ou não têm mais importância.
Compilar Solicitações de Funcionalidades em uma listagem daquelas que a equipe está considerando adicionar no futuro e liberar esses votos para serem utilizados novamente, na minha humilde opinião, faz sentido.
Por que sequer usar a votação de tópicos? Como você mencionou, as Reações/Curtidas poderiam ser usadas em vez de se limitar a um número definido de votos. Usar, digamos, uma reação específica como 
pode ser suficiente para medir o interesse em uma determinada solicitação de #funcionalidade, pois você poderia usar um script de explorador de dados nesta categoria para retornar os principais tópicos, talvez na postagem original, com a maior parte dessa reação específica.
Em vez de limitar a votação, que realmente não parece estar indo a lugar nenhum, pois, na minha experiência, não há atualizações diretamente relacionadas a esta categoria. Pode haver de tempos em tempos e eu talvez não tenha notado.
Tenho certeza de que algumas das novas coisas lançadas podem ter sido uma solicitação de funcionalidade em algum momento.
Na minha humilde opinião, a votação de tópicos pode ser melhor para Concursos, votando nos principais X Tópicos com uma data de encerramento definida para o dia do anúncio dos 3 primeiros vencedores. Mas usada nesta categoria, parece mais um concurso sem uma conclusão clara, exigindo que se duvide dos próprios votos.
1 curtida
Eu comentei bastante sobre o processo aqui, mas para ser justo, há muitos pedidos de recursos marcados como completed – Resultados filtrados para categoria:feature tag:completed
2 curtidas
A tag concluída ajuda. Mas eu acho que se a equipe quiser medir mais interesse em solicitações de recursos, limitar o número de votos pode ser contraproducente.
Como Sam mencionou com os vários sinais como Curtir/Reações. (Escolha uma reação específica) Ou mesmo sem limites de votos. Como nem todas as Ideias terão votos/reações das pessoas, pois elas podem não estar interessadas em uma ideia específica. Por exemplo, há um pedido, creio eu, para Eleger uma equipe do fórum.
Embora em alguns fóruns essa possa ser uma ideia/opção, muitos não gostariam de ter um potencial concurso de popularidade decidindo quem controla o fórum.
Assim, você ainda terá Recursos com mais votos/reações, significando o nível de interesse geral da comunidade, em vez de limitar a um número definido, o que é mais provável que divida o interesse e tenha muito mais Empates, por assim dizer.
1 curtida
Revisar a tag realmente ajuda a ver o quanto foi adicionado. Apenas parece muito restritivo limitar o interesse de votos. Até mesmo alguns dos recursos concluídos tiveram votos mínimos ou nulos. É claro que vitórias fáceis e simples são boas.
Meu sonho aqui seria que todos tivessem suas próprias visualizações personalizadas e classificadas por ordem de preferência (stack ranked) de funcionalidades, as quais poderíamos agregar em diferentes visualizações coletivas através de diferentes “lentes”.
Então, em vez de ser um voto/não-voto binário em tudo, eu poderia montar minha lista de “top 10” e mostrá-las em ordem de preferência. Você poderia fazer o mesmo. E então eu poderia fazer coisas como “mostre-me a lista dos dez principais para pessoas que ingressaram na meta no último ano” ou “mostre-me a lista dos dez principais para pessoas que estão em nosso plano inicial”, etc.
Entretanto, tenho outras ideias sobre como podemos tornar as coisas um pouco mais gerenciáveis aqui, que se conectam com ideias de como gerenciamos um roadmap e um backlog abertos de forma mais geral. Estas envolvem algumas mudanças na forma como gerenciamos as categorias de bugs, funcionalidades e ux, e como separamos a ideação mais aberta das propostas e/ou especificações mais concretas para coisas que estamos planejando trabalhar ou que ficaríamos felizes em ver contribuídas.
Espero conseguir elaborar algo como um RFC para isso para discussão antes do final do ano.
4 curtidas