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 essa discussão recente para o tópico original do Jammydodger, pois faz sentido continuar conversando aqui sobre a votação de funcionalidades da tag Contribute.
Gosto da ideia de estabelecer limites, mas também acho que há tantas solicitações de funcionalidades abertas que parece injusto ter um limite muito baixo. Eu mesmo me sinto limitado por isso! Os votos também são um sinal, e ao não permitir que as pessoas votem, estamos privando a equipe de produto desse feedback.
Estou inclinado a aumentar os limites nos moldes 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 a estrita ração de votos preciosos resulta em inteligência limitada. Os contagens de votos geralmente parecem baixos 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 sejam notados.
Estar perpetuamente sem votos e sempre ter que fazer triagem e sacrificar para votar em algo novo é uma barreira significativa. Reviso meus votos existentes para ver como posso liberar votos… mas nenhum dos pedidos é indigno. Eles apenas rolagem do feed e foram esquecidos.
Devo desistir deles?
Devo impulsionar meus favoritos com um comentário? Tendo votado em um recurso, comentar “Sim, boa ideia!” parece um entulho supérfluo.
Boas ideias ficam com um ou dois votos. As pessoas não estão descobrindo-as, não estão interessadas ou… estão apenas sem votos? 
Aumentar os limites não exigiria uma série de codificações, e parece que ajudaria — mas também penso em como alargar uma estrada para reduzir o tráfego apenas convida a mais tráfego e você volta ao ponto de partida.
Apenas especulando aqui… algumas mudanças funcionais que exigem bastante 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 Contribute > Feature e avaliam itens abertos…)
…ou, como heliosurge mencionou, liberar votos eventualmente:
- Liberar um voto usado após um tempo definido, ou
- A equipe revisa solicitações de recursos obsoletas de forma contínua e ou a.) impulsiona o tópico para outra chance, ou b.) comenta com “sem planos de abordar” e libera votos.
…Em ambos os casos, os votos emitidos permanecem no lugar, e os usuários não podem exceder sua alocação de votos desmarcando esses tópicos.
(É fácil para mim dizer. Isso provavelmente exigiria 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.
Brincando com o canal Contribute > Feature hoje por curiosidade, foi interessante comparar essas visualizações filtradas:
- Resultados filtrados para categoria:feature status:open order:likes-op
- Resultados filtrados para categoria:feature status:open order:votes
Fico imaginando o que poderia ser feito com uma consulta no Data Explorer que inclua tanto Votos quanto Curtidas… 
Além disso:
Ideia de automação: talvez um “pool” principal baseado em Curtidas pudesse escalar solicitações para o status de votável.
Ideia de curadoria manual: ocasionalmente, uma solicitação com mérito óbvio é adotada pela equipe independentemente dos votos, então, de certa forma, já ocorre alguma curadoria. Mas talvez tudo deveria passar por uma rápida revisão da equipe?
Exemplo de apoio: encontrei 8 solicitações de recursos sobre “permitir que os usuários fechem seus próprios tópicos” — de 2014 a 2025 — algumas fechadas, mas a maioria delas abertas com 0 votos. Algo não está funcionando bem se a mesma solicitação for feita repetidamente enquanto versões mais antigas passam despercebidas e sem votos.
Se os usuários não estão pesquisando — ou não vendo diálogos do tipo “seu tópico é semelhante…” — não tenho certeza do que mais poderia ser feito além de fazer com que as solicitações iniciais passem por um ponto de verificação da equipe: 
se for novo, mova o tópico para uma categoria de votação; 
se já existir uma solicitação semelhante, responda com um link.
Só 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 essas coisas, anteriormente votadas, tenham sido implementadas ou que já não tenham importância.
Acredito que faz sentido reunir os pedidos de recurso em uma lista dos que a equipe está considerando adicionar no futuro e liberar esses votos para que sejam reaproveitados.
Por que usar votação de tópicos? Como você mencionou, os curtidos/reactions poderiam ser usados em vez de ser limitado a um número fixo de votos. Usar, por exemplo, uma reação específica como 
pode ser suficiente para avaliar o interesse em um pedido de recurso Contribute, já que você poderia usar um script do explorador de dados nesta categoria para retornar os principais tópicos, talvez na primeira postagem, com a maioria dessa reação específica.
Em vez de limitar a votação, que realmente não parece levar a lugar algum, pois, na minha experiência, não há atualizações diretamente relacionadas a esta categoria. Pode haver de tempos em tempos, e eu simplesmente não percebi, talvez.
Tenho certeza de que algumas das novas funcionalidades implementadas podem ter sido um pedido de recurso em algum momento.
Na minha opinião, a votação de tópicos pode ser melhor para concursos, onde se votam nos X principais tópicos com uma data de encerramento definida para anunciar os três primeiros vencedores no dia. Mas, usada nesta categoria, parece mais um concurso sem uma conclusão clara, exigindo que se adivinhe o que se deve votar.
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