¿Qué opinan los usuarios sobre un número razonable de votos por nivel de confianza? Veo que en meta hemos cambiado TL0 de 2 a cero votos y TL4 de 10 a 8. Me he dado cuenta de que me he quedado sin votos, ¡incluso siendo administrador aquí! 
2 Me gusta
Siempre he pensado que el número está deliberadamente limitado para que funcione como un indicador de ‘esto es realmente importante para mí’. Todavía puedo dar me gusta a todas las solicitudes y añadir mi caso de uso a las solicitudes de funciones, incluso si me quedo sin votos. Y todavía puedo votar sobre estos temas una vez que se complete otra solicitud de función que voté y el tema se cierre.
1 me gusta
@tobiaseigen, no los limitaría… Me encuentro sin usar nunca los votos porque, para mí, o simplemente apoyo u opondo algo; tratar de determinar si algo es seriamente importante para mí no es un uso particularmente pragmático de mi tiempo, cuando existen los “me gusta” en su lugar.
2 Me gusta
Moví esta discusión reciente a la original de Jammydodger porque me parece correcto continuar hablando aquí sobre la votación.
Me gusta la idea de los límites, pero también creo que hay tantas solicitudes de funciones abiertas que parece injusto tener un límite muy bajo. ¡Yo mismo me siento limitado por esto! Los votos también son una señal, y al no permitir que las personas voten, privamos al equipo de producto de esa señal.
Me inclino a aumentar los límites en las líneas siguientes. ¿Qué opinan?
| Nivel de confianza | Votos actuales | Votos propuestos |
|---|---|---|
| TL0 | 0 | 0 |
| TL1 | 4 | 10 |
| TL2 | 6 | 20 |
| TL3 | 8 | 24 |
2 Me gusta
Imo 24 lo convierte en prácticamente ilimitado
Me gustan los límites actuales, te hacen pensar.
2 Me gusta
Me pregunto si el estricto racionamiento de votos preciosos resulta en información limitada. Los recuentos de votos generalmente parecen bajos para el número de usuarios aquí. Muchas sugerencias de funciones tienen más “Me gusta” que votos, pero me imagino que solo se notan los votos.
Estar perpetuamente sin votos y tener que priorizar y sacrificar para votar en cualquier cosa nueva es una barrera importante. Reviso mis votos existentes para ver cómo puedo liberar votos… pero ninguna de las solicitudes es indigna. Simplemente se desplazaron del feed y se olvidaron.
¿Debo renunciar a ellos?
¿Debería dar un impulso a mis favoritos con un comentario? Habiendo votado por una función, comentar “¡Sí, buena idea!” se siente como una acumulación superflua.
Buenas ideas se quedan con uno o dos votos. ¿La gente no las está descubriendo, no está interesada, o… simplemente se quedaron sin votos? 
Aumentar los límites no requeriría un montón de codificación y parece que ayudaría, pero también pienso en cómo ensanchar una carretera para reducir el tráfico solo atrae más tráfico y vuelves al punto de partida.
Solo estoy lanzando ideas… algunos cambios funcionales que requieren un montón de codificación como alternativas a un límite estricto:
- Asignar un número de votos por mes basado en el nivel de confianza (TL). (En el “día de votos” hay una ráfaga de actividad ya que la gente visita Feature y evalúa los elementos abiertos…)
…o, como mencionó heliosurge, eventualmente liberar votos:
- Liberar un voto utilizado después de un tiempo determinado, o
- El personal revisa las solicitudes de funciones obsoletas de forma continua y, o bien a) da un impulso al tema para otra oportunidad, o b) comenta con “no hay planes de abordar” y libera los votos.
…En cualquier caso, los votos emitidos permanecen en su lugar, y los usuarios no pueden exceder su asignación de votos al desvotar estos temas.
(Fácil para mí decirlo. Probablemente sea mucha codificación 
)
2 Me gusta
@sam, a mí no me pasa, ya que solo uso los “me gusta”. Su implementación actual se siente un poco redundante, muy parecido a que existan tanto el “upvote” como el “pulgar hacia arriba” para GitHub Discussions.
2 Me gusta
Estar de acuerdo en que tener una señal duplicada es confuso
“Me gusta cómo escribiste la solicitud de funciones, me parece bien”
Vs
“Este está ciertamente entre mis 8 principales, creo que Discourse debería crearlo”
Puede ser un experimento interesante deshabilitar los “me gusta” del OP cuando la votación de temas está habilitada.
1 me gusta
Hay algo sobre el cierre de algunas solicitudes con “lo sentimos, no vamos a hacer esto”.
Ciertamente hay algo extremadamente convincente en cerrar funciones completadas de 2 años como hechas, y solicitudes de funciones que ya no tienen ningún sentido como obsoletas.
2 Me gusta
No creo que cambie mucho al final. La mayoría de mis votos se añadieron hace un año. Sí, habría podido votar en más temas, pero una vez que he gastado todos mis votos, vuelve a ser lo mismo: tendría que esperar a que uno se complete y se cierre, o necesito retirar mi voto de otro tema. Estoy bastante seguro de que también hay más de 20 buenas solicitudes de funciones en Meta 
Como dije antes, para mí los votos son algo más fuerte que un “me gusta”. Pero sigo pensando que los “me gusta” en la primera publicación también son muy útiles para captar el interés. Han sido el indicador durante más de 10 años cuando no se permitía votar. Por lo tanto, ignorarlos, especialmente en solicitudes de larga data, significa ignorar la única forma en que los usuarios podían mostrar apoyo en ese entonces.
Además, tal vez nadie piense que la solicitud de función es algo que necesita tanto como para gastar un voto en ella, pero a muchos usuarios les gusta porque creen que sería útil. ¿Dice un voto (generalmente del autor de la solicitud) más sobre cuán útil sería esa función para una variedad de sitios de Discourse diferentes que varios “me gusta”?
Me pregunto si, en lugar de aumentar el número de votos de “estoy realmente interesado en esto”, sería mejor limitar el número de temas en los que se pueden distribuir.
Así que, en lugar de tener 378^ [
] temas de este año para votar, podría tener sentido preseleccionarlos.
Por ejemplo, solo las solicitudes con una cierta cantidad de reacciones que indiquen interés de múltiples usuarios son aquellas en las que se puede votar, o se podría limitar por tiempo y decir que la votación está restringida a temas de un cierto período de tiempo para encontrar los favoritos dentro de ese grupo de funciones.
También se podría decir: “Estamos revisando la cola de revisión. ¿Qué solicitudes se te ocurren?”. Luego, esas se moverían a una subcategoría y se votarían.
Poder gastar 4 votos en ~100 temas sería proporcionalmente más que poder gastar 10 votos en todos los temas de funciones abiertos.
3 Me gusta
@sam, esperaba lo contrario. ¿Los votos proporcionan algo, técnicamente, que los “me gusta” no? Dudo que a alguien le guste una Solicitud de Funciones (FR) que no apoya.
Si los “me gusta” se deshabilitaran cuando los votos estuvieran habilitados, eso “reduciría la inteligencia”, creo. A modo de comparación, que Forgejo y GitLab no limiten los votos positivos podría indicar que existe valor en tenerlos como un simple indicador de apoyo frente a no apoyo.
Explorando hoy Feature por curiosidad, fue interesante comparar estas vistas filtradas:\n- Resultados filtrados para categoría:feature estado:abierto orden:likes-op\n- Resultados filtrados para categoría:feature estado:abierto orden:votes\n\nMe pregunto qué se podría hacer con una consulta de Data Explorer que incluya tanto Votos como Me gusta… 
\n\nAdemás:\n[quote="Moin, post:30, topic:308402"]\nen lugar de tener 378 temas de este año para votar, podría tener sentido preseleccionarlos\n[/quote]\n\nPensamiento de automatización: tal vez un grupo “principal” basado en Me gusta podría escalar las solicitudes a estado votable.\n\nPensamiento de curación manual: ocasionalmente, una solicitud con mérito obvio es seleccionada por el personal independientemente de los votos, por lo que, en cierto modo, ya ocurre algo de curación. ¿Pero tal vez todo debería pasar por una rápida revisión del personal?\n\nEjemplo de apoyo: Encontré 8 solicitudes de características sobre “permitir a los usuarios cerrar sus propios temas” – desde 2014 hasta 2025 – un par cerradas, pero la mayoría abiertas con 0 votos. Algo no está funcionando bien si la misma solicitud se hace repetidamente mientras que las versiones más antiguas pasan desapercibidas y sin votos.\n\nSi los usuarios no están buscando, o no ven los diálogos de “tu tema es similar…”, no estoy seguro de qué más se podría hacer aparte de que las solicitudes iniciales lleguen a un punto de control del personal: 
si es nuevo, mover el tema a una categoría de votación; 
si existe una solicitud similar, responder con un enlace.\n\nSolo estoy pensando en voz alta. Sé que todo requiere recursos…
El límite estaría bien si el equipo publicara los votos después de componer una lista de los temas votados. Quizás publicar los votos trimestralmente. La actualización incluso podría detallar las características que el equipo ha elegido añadir a la hoja de ruta con un posible cronograma en términos de prioridad.
De lo contrario, 24 realmente no es ilimitado, ya que algunos votos han quedado inmovilizados durante más de un año y posiblemente más. También es una molestia intentar eliminar votos en características aparentemente muertas que quizás ni siquiera se estén considerando.
Quizás una idea sea crear de vez en cuando una lista de funciones que el equipo está considerando seriamente y crear una encuesta para que la gente vote y luego actualizar las cosas a partir de ahí. La votación de temas no está mal si hay un ciclo de lanzamiento. Cuál debería ser ese ciclo es algo que el equipo necesita discutir y decidir.
[quote=“Heliosurge, post:33, topic:308402”]El límite estaría bien si el equipo publicara las votaciones después de componer una lista de los temas votados.
[/quote]
no entiendo, ¿no pueden publicar votos sobre cosas que ya no son importantes para ustedes?
Eso presupone que estas cosas votadas anteriormente se han implementado o ya no tienen importancia.
Recopilar las solicitudes de funciones en una lista de las que el equipo está considerando agregar en el futuro y liberar esos votos para que se utilicen de nuevo, en mi humilde opinión, tiene sentido.
¿Por qué usar la votación de temas? Como mencionaste, los “Me gusta”/reacciones podrían usarse en lugar de limitarse a un número fijo de votos. Usar, digamos, una reacción particular como 
podría ser suficiente para medir el interés en una solicitud de función particular, ya que podrías usar un script de explorador de datos en esta categoría para devolver los temas principales, tal vez en la publicación de apertura, con la mayor cantidad de esta reacción en particular.
Frente a limitar la votación, que realmente no parece que vaya a ninguna parte, ya que en mi experiencia no hay actualizaciones directamente relacionadas con esta categoría. Puede que las haya de vez en cuando y tal vez simplemente no lo haya notado.
Estoy seguro de que algunas de las cosas nuevas implementadas pudieron haber sido una solicitud de función en algún momento.
En mi humilde opinión, la votación de temas podría ser mejor para concursos, votando por los X temas principales con una fecha de cierre establecida para el día del anuncio de los 3 primeros ganadores. Pero utilizada en esta categoría, se siente más como un concurso sin una conclusión clara, con la necesidad de adivinar los votos.
1 me gusta
He comentado mucho sobre el proceso aquí, pero para ser justos, hay muchas solicitudes de funciones etiquetadas como completed – Resultados filtrados para categoría:feature etiqueta:completed
2 Me gusta
La etiqueta completada ayuda. Pero encuentro que si el equipo quiere medir más interés en las solicitudes de funciones, limitar el número de votos puede ser contraproducente.
Como Sam mencionó con las diversas señales como Me gusta/Reacciones. (Elegir una reacción específica) O incluso sin límites de votos. Ya que no todas las Ideas tendrán votos/reacciones de la gente, ya que podrían no estar interesadas en una idea específica. Por ejemplo, creo que hay una solicitud para Elegir un equipo del foro.
Si bien en algunos foros esa podría ser una idea/opción, muchos no querrían que un posible concurso de popularidad decida quién controla el foro.
Por lo tanto, aún obtendrá funciones con más votos/reacciones que indiquen el nivel de interés general de la comunidad en lugar de limitar a un número establecido, lo que es más probable que divida el interés y tenga muchos más Empates, por así decirlo.
1 me gusta
Revisar la etiqueta realmente ayuda a ver cuánto se ha añadido. Simplemente se siente demasiado restrictivo limitar el interés de los votos. Incluso algunas de las características completadas tuvieron pocos o ningún voto. Por supuesto que las victorias fáciles y sencillas son buenas.
Mi sueño aquí sería que todos tuvieran sus propias vistas personalizadas y clasificadas por orden de prioridad de las funcionalidades, las cuales podríamos agregar en diferentes vistas colectivas a través de diferentes “lentes”.
Así, en lugar de que sea un voto/no voto binario en todo, podría elaborar mi lista de “los 10 mejores” y mostrarlos en orden de preferencia. Usted podría hacer lo mismo. Y luego podría hacer cosas como “muéstrame la lista de los diez primeros para las personas que se unieron a meta en el último año” o “muéstrame la lista de los diez primeros para las personas que están en nuestro plan de inicio”, etc.
Mientras tanto, tengo otras ideas sobre cómo podemos hacer que las cosas sean un poco más manejables aquí, que se relacionan con ideas sobre cómo gestionamos un roadmap y un backlog abiertos en general. Estas implican algunos cambios en cómo gestionamos las categorías de errores (bug), funcionalidades (feature) e interfaz de usuario (ux), y cómo separamos la ideación más abierta de las propuestas y/o especificaciones más concretas para las cosas en las que estamos planeando trabajar o que estaríamos encantados de ver contribuidas.
Espero tener algo parecido a una RFC (Solicitud de Comentarios) lista para discusión antes de fin de año.
4 Me gusta