Quel est le nombre raisonnable de votes par niveau de confiance selon vous ? Je vois que sur meta, nous sommes passés de 2 à zéro vote pour le TL0 et de 10 à 8 votes pour le TL4. J’ai remarqué que je suis moi-même à court de votes, même si je suis administrateur ici ! 
2 « J'aime »
J’ai toujours pensé que le nombre était délibérément limité pour servir d’indicateur de « ceci est vraiment important pour moi ». Je peux toujours aimer toutes les requêtes et ajouter mon cas d’utilisation aux demandes de fonctionnalités, même si je manque de votes. Et je peux toujours voter sur ces sujets une fois qu’une autre demande de fonctionnalité pour laquelle j’ai voté est terminée et que le sujet est clos.
1 « J'aime »
@tobiaseigen, je ne les limiterais pas… Je me retrouve à ne jamais utiliser les votes parce que, pour moi, je soutiens ou m’oppose simplement à quelque chose ; essayer de déterminer si quelque chose est sérieusement important pour moi n’est pas une utilisation particulièrement pragmatique de mon temps, alors que les likes existent à la place.
2 « J'aime »
J’ai déplacé cette discussion récente dans le sujet original de Jammydodger car il me semble plus logique de continuer à y parler du vote pour les fonctionnalités à contribuer (Contribute > Feature).
J’aime l’idée des limites, mais je pense aussi qu’il y a tellement de demandes de fonctionnalités ouvertes qu’il semble injuste d’imposer une limite très basse. Je me sens moi-même contraint par cela ! Les votes sont aussi un signal, et en empêchant les gens de voter, nous privons l’équipe produit de ce signal.
Je penche pour augmenter les limites selon les lignes ci-dessous. Qu’en pensez-vous ?
| Niveau de confiance | Votes actuels | Votes proposés |
|---|---|---|
| TL0 | 0 | 0 |
| TL1 | 4 | 10 |
| TL2 | 6 | 20 |
| TL3 | 8 | 24 |
2 « J'aime »
Imo 24 turns this into practically unlimited
J’aime les limites actuelles, cela vous fait réfléchir
2 « J'aime »
Je me demande si la rationnement strict des précieux votes ne conduit pas à un manque d’informations. Le nombre de votes semble généralement faible par rapport au nombre d’utilisateurs ici. De nombreuses suggestions de fonctionnalités reçoivent plus de « J’aime » que de votes, mais je suppose que seuls les votes sont pris en compte.
Être constamment à court de votes et devoir en permanence trier et sacrifier pour voter sur quelque chose de nouveau constitue un obstacle majeur. Je consulte mes votes existants pour voir comment je peux libérer des votes… mais aucune des demandes n’est indigne. Elles ont simplement défilé hors du fil d’actualité et ont été oubliées.
Dois-je abandonner ces demandes ?
Devrais-je remonter mes favoris avec un commentaire ? Après avoir voté pour une fonctionnalité, commenter « Oui, bonne idée ! » semble être un encombrement superflu.
Les bonnes idées restent avec un ou deux votes. Les gens ne les découvrent pas, ne sont pas intéressés, ou… sont-ils simplement à court de votes ? 
Augmenter les limites ne nécessiterait pas une masse de codage, et cela semble utile — mais je pense aussi à comment élargir une route pour réduire la circulation attire simplement plus de trafic, et on se retrouve au point de départ.
Je lance juste quelques idées… quelques changements fonctionnels nécessitant du codage en alternatives à une limite stricte :
- Allouer un certain nombre de votes par mois en fonction du niveau de confiance (TL). (Le « jour des votes », il y a une effervescence d’activité alors que les gens visitent Contribute > Feature et évaluent les éléments ouverts…)
…ou, comme l’a mentionné heliosurge, libérer éventuellement les votes :
- Libérer un vote utilisé après un délai déterminé, ou
- Le personnel examine les demandes de fonctionnalités obsolètes de manière continue et soit a.) remonte le sujet pour une nouvelle chance, soit b.) commente avec « aucun projet de traitement » et libère les votes.
…Dans les deux cas, les votes émis restent en place, et les utilisateurs ne peuvent pas dépasser leur allocation de votes en retirant leurs votes de ces sujets.
(C’est facile à dire pour moi. Cela nécessite probablement beaucoup de codage 
)
2 « J'aime »
@sam, ce n’est pas le cas pour moi, puisque j’utilise simplement les likes. Son implémentation actuelle semble un peu redondante – un peu comme l’existence du vote positif et du pouce levé pour les discussions GitHub.
2 « J'aime »
D’accord, avoir des signaux en double est déroutant
« J’aime la façon dont vous avez écrit la demande de fonctionnalité, cela me semble bien »
Vs
« C’est certainement dans mon top 8, je pense que Discourse devrait le construire »
Ce pourrait être une expérience intéressante de désactiver les « j’aime » de l’OP lorsque le vote de sujet est activé.
1 « J'aime »
Il y a quelque chose à propos de la clôture de certaines demandes avec « désolé, nous ne faisons pas cela »
Il y a certainement quelque chose d’extrêmement convaincant à clôturer des fonctionnalités achevées depuis 2 ans comme étant terminées, et des demandes de fonctionnalités qui n’ont plus aucun sens comme étant obsolètes.
2 « J'aime »
Je ne pense pas que cela changerait grand-chose au final. La plupart de mes votes ont été ajoutés il y a un an. Oui, j’aurais pu voter sur plus de sujets, mais une fois que j’ai dépensé tous mes votes, c’est la même chose : je devrais attendre qu’un soit terminé et fermé, ou je devrais retirer mon vote d’un autre sujet. Je suis tout à fait sûr qu’il y a aussi plus de 20 bonnes demandes de fonctionnalités sur Meta 
Comme je l’ai dit précédemment, pour moi, les votes sont quelque chose de plus fort qu’un j’aime. Mais je pense toujours que les j’aime sur le premier message sont également très utiles pour susciter l’intérêt. Ils sont l’indicateur depuis plus de 10 ans lorsque le vote n’était pas activé. Donc, les ignorer, surtout pour les demandes de longue date, signifie ignorer la seule façon dont les utilisateurs pouvaient montrer leur soutien à l’époque.
De plus, peut-être que personne ne pense que la demande de fonctionnalité est quelque chose dont ils ont vraiment besoin pour dépenser un vote, mais de nombreux utilisateurs l’aiment parce qu’ils pensent qu’elle serait utile. Un vote (généralement par l’auteur de la demande) en dit-il plus sur l’utilité de cette fonctionnalité pour une gamme de différents sites Discourse que plusieurs j’aime ?
Je me demande si, au lieu d’augmenter le nombre de votes « Je suis vraiment intéressé par ceci », il ne serait pas préférable de limiter le nombre de sujets sur lesquels ils peuvent être répartis.
Donc, au lieu d’avoir 378 sujets de cette année à voter, il pourrait être judicieux de les présélectionner.
Par exemple, seules les demandes ayant un certain nombre de réactions indiquant l’intérêt de plusieurs utilisateurs peuvent être votées, ou vous pourriez le limiter dans le temps et dire que le vote est restreint aux sujets d’une certaine période afin de trouver les favoris au sein de ce groupe de fonctionnalités.
Vous pourriez aussi dire : « Nous révisons la file d’attente d’examen. Quelles demandes vous viennent à l’esprit ? » Ensuite, celles-ci seraient déplacées dans une sous-catégorie et votées.
Être capable de dépenser 4 votes sur ~100 sujets serait proportionnellement plus que de pouvoir dépenser 10 votes sur tous les sujets de fonctionnalités ouverts.
3 « J'aime »
@sam, j’espérais le contraire. Les votes apportent-ils quelque chose, techniquement, que les “j’aime” n’apportent pas ? Je doute que quelqu’un aime une demande de fonctionnalité qu’il ne soutient pas.
Si les “j’aime” étaient désactivés lorsque les votes sont activés, cela “réduirait l’information”, je crois. À titre de comparaison, le fait que Forgejo et GitLab ne limitent pas les votes positifs pourrait indiquer qu’il y a une valeur à les avoir comme simple indicateur de soutien ou de non-soutien.
En fouillant dans Contribute > Feature aujourd’hui par curiosité, il était intéressant de comparer ces vues filtrées :
- Résultats filtrés pour category:feature status:open order:likes-op
- Résultats filtrés pour category:feature status:open order:votes
Je me demande ce qu’on pourrait faire avec une requête Data Explorer incluant à la fois les Votes et les Likes… 
Aussi :
Pensée sur l’automatisation : peut-être qu’un « pool » principal basé sur les Likes pourrait faire passer les demandes en statut votable.
Pensée sur la curation manuelle : de temps en temps, une demande manifestement pertinente est reprise par l’équipe (staff) indépendamment des votes, donc d’une certaine manière, une curation existe déjà. Mais peut-être faudrait-il que toutes les demandes passent par une rapide revue de la staff ?
Exemple à l’appui : j’ai trouvé 8 demandes de fonctionnalités autour de « permettre aux utilisateurs de fermer leurs propres sujets » — de 2014 à 2025 — quelques-unes fermées, mais la plupart ouvertes avec 0 vote. Quelque chose ne fonctionne pas bien si la même demande est formulée à plusieurs reprises alors que les versions précédentes passent inaperçues et ne reçoivent aucun vote.
Si les utilisateurs ne recherchent pas — ou ne voient pas les dialogues « votre sujet est similaire… » — je ne sais pas quoi faire d’autre que de faire passer les demandes initiales par un point de contrôle staff : 
si nouveau, déplacer le sujet vers une catégorie de vote ; 
si une demande similaire existe, répondre avec un lien.
Je réfléchis à voix haute. Je sais que tout cela nécessite des ressources…
La limite serait acceptable si l’équipe publiait les votes après avoir composé une liste des sujets votés. Peut-être publier les votes trimestriellement. La mise à jour pourrait même détailler les fonctionnalités que l’équipe a choisi d’ajouter à la feuille de route avec un calendrier potentiel en termes de priorité.
Sinon, 24 n’est vraiment pas illimité car certains votes sont liés depuis plus d’un an et potentiellement plus. C’est aussi une corvée d’essayer d’aller supprimer des votes sur des fonctionnalités apparemment mortes qui pourraient même ne pas être envisagées.
Peut-être qu’une idée serait de créer de temps en temps une liste des fonctionnalités que l’équipe envisage sérieusement et de créer un sondage pour que les gens votent, puis de mettre à jour les choses à partir de là. Le vote de sujet n’est pas mauvais s’il y a un cycle de publication. Quel devrait être ce cycle est quelque chose que l’équipe doit discuter et décider.
je ne comprends pas, ne pouvez-vous pas publier les votes sur des choses qui ne sont plus importantes pour vous ?
Cela suppose que ces éléments, précédemment votés, ont été mis en œuvre ou n’ont plus d’importance.
Regrouper les demandes de fonctionnalités dans une liste de celles que l’équipe envisage d’ajouter à l’avenir, et réutiliser les votes pour ces éléments, me semble judicieux.
Pourquoi utiliser les votes sur les sujets ? Comme vous l’avez mentionné, les « J’aime » ou les réactions pourraient être utilisés à la place, sans être limités à un nombre fixe de votes. Utiliser par exemple une réaction spécifique comme 
pourrait suffire à évaluer l’intérêt pour une demande de fonctionnalité Contribute > Feature donnée, car vous pourriez utiliser un script Data Explorer dans cette catégorie pour retourner les sujets les plus populaires, peut-être dans le premier message, en fonction du nombre de cette réaction spécifique.
Par opposition à un système de vote limité qui, à mon sens, ne mène nulle part, car je n’ai remarqué aucune mise à jour directement liée à cette catégorie. Il peut y en avoir de temps en temps, et je ne les ai peut-être pas remarquées.
Je suis sûr que certaines des nouvelles fonctionnalités déployées ont été, à un moment donné, des demandes de fonctionnalités.
À mon avis, les votes sur les sujets seraient plus adaptés pour des concours visant à élire les X meilleurs sujets avec une date de clôture définie, afin d’annoncer les trois premiers lauréats. Mais utilisés dans cette catégorie, ils ressemblent davantage à un concours sans conclusion claire, obligeant à deviner ce que les autres ont voté.
1 « J'aime »
J’ai fait beaucoup de commentaires sur le processus ici, mais pour être honnête, il y a beaucoup de demandes de fonctionnalités étiquetées comme completed – Résultats filtrés pour la catégorie:feature tag:completed
2 « J'aime »
La balise complétée aide effectivement. Mais je trouve que si l’équipe souhaite évaluer davantage l’intérêt pour les demandes de fonctionnalités, limiter le nombre de votes peut être contre-productif.
Comme Sam l’a mentionné avec les divers signaux comme les J’aime/Réactions. (Choisir une réaction spécifique) Ou même aucune limite de vote. Car les gens ne voteront/réagiront pas à toutes les idées, car ils pourraient ne pas être intéressés par une idée spécifique. Par exemple, il y a je crois une demande pour élire une équipe de forum.
Alors que sur certains forums cela pourrait être une idée/option, beaucoup ne voudraient pas qu’un potentiel concours de popularité décide de qui contrôle le forum.
Ainsi, vous obtiendrez toujours des fonctionnalités avec plus de votes/réactions signifiant le niveau d’intérêt général de la communauté par rapport à la limitation à un nombre défini, ce qui est plus susceptible de diviser l’intérêt et d’avoir beaucoup plus d’Égalités pour ainsi dire.
1 « J'aime »
Examiner l’étiquette aide effectivement à voir combien a été ajouté. Cela semble juste trop restrictif de limiter l’intérêt des votes. Même certaines des fonctionnalités terminées avaient peu ou pas de votes. Certes, les gains faciles et simples sont bien sûr bons.
Mon rêve ici serait que chacun ait sa ou ses vues personnalisées et classées par ordre de priorité des fonctionnalités, que nous pourrions ensuite agréger en différentes vues collectives à travers différents « filtres ».
Ainsi, au lieu d’avoir un vote/non-vote binaire sur tout, je pourrais établir ma liste des « 10 meilleures » et les montrer par ordre de préférence. Vous pourriez faire de même. Et ensuite, je pourrais faire des choses comme « montrez-moi la liste des dix meilleures pour les personnes qui ont rejoint meta au cours de la dernière année » ou « montrez-moi la liste des dix meilleures pour les personnes qui sont hébergées sur notre plan de démarrage », etc.
En attendant, j’ai d’autres idées sur la façon dont nous pouvons rendre les choses un peu plus gérables ici, qui sont liées à des idées sur la façon dont nous gérons une feuille de route et un backlog ouverts plus généralement. Celles-ci impliquent des changements dans la façon dont nous gérons les catégories de bogues, de fonctionnalités et d’expérience utilisateur (UX), et comment nous séparons l’idéation plus ouverte des propositions et/ou des spécifications plus concrètes pour les choses que nous prévoyons de faire ou que nous serions heureux de voir contribuer.
J’espère pouvoir préparer quelque chose comme une RFC à ce sujet pour discussion avant la fin de l’année.
4 « J'aime »