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 celle de Jammydodger car il me semble juste de continuer à parler ici du vote.
J’aime l’idée de limites, mais je pense aussi qu’il y a tellement de demandes de fonctionnalités ouvertes qu’il semble injuste d’avoir une limite très basse. Je me sens moi-même limité par cela ! Les votes sont aussi un signal, et en ne laissant pas les gens voter, nous privons l’équipe produit de ce signal.
Je suis enclin à augmenter les limites comme suit. Qu’en pensent les gens ?
| 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 le rationnement strict des précieux votes entraîne des informations limitées. Le nombre de votes semble généralement faible par rapport au nombre d’utilisateurs ici. De nombreuses suggestions de fonctionnalités ont plus de J’aime que de votes, mais j’imagine que seuls les votes sont remarqués.
Être perpétuellement à court de votes et devoir toujours prioriser et sacrifier pour voter sur quelque chose de nouveau est une barrière importante. 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é et ont été oubliées.
Dois-je les abandonner ?
Devrais-je relancer mes préférées avec un commentaire ? Ayant voté pour une fonctionnalité, commenter « Oui, bonne idée ! » semble être un encombrement superflu.
De 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 beaucoup de codage, et cela semble aider – mais je pense aussi à la façon dont élargir une route pour réduire le trafic n’invite que plus de trafic et vous revenez à votre point de départ.
Je réfléchis juste… quelques changements fonctionnels qui nécessitent beaucoup de codage comme alternatives à une limite stricte :
- Allouer un nombre de votes par mois en fonction du TL. (Le « jour des votes », il y a une activité intense car les gens visitent Feature et évaluent les éléments ouverts…)
… ou, comme l’a mentionné heliosurge, libérer éventuellement des votes :
- Libérer un vote utilisé après un certain temps, ou
- Le personnel examine les demandes de fonctionnalités obsolètes sur une base continue et soit a.) relance le sujet pour une autre chance, soit b.) commente avec « aucun plan pour y répondre » et libère les votes.
… Dans les deux cas, les votes exprimés restent en place, et les utilisateurs ne peuvent pas dépasser leur allocation de votes en retirant davantage de ces sujets.
(Facile à dire pour moi. C’est 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 Feature aujourd’hui par curiosité, il était intéressant de comparer ces vues filtrées :
- Résultats filtrés pour catégorie:feature statut:ouvert ordre:likes-op
- Résultats filtrés pour catégorie:feature statut:ouvert ordre:votes
Je me demande ce qui pourrait être fait avec une requête Data Explorer incluant à la fois les Votes et les J’aime… 
Aussi :
[quote=“Moin, post:30, topic:308402”]au lieu d’avoir 378 sujets de cette année sur lesquels voter, il pourrait être judicieux de les présélectionner
[/quote]
Pensée sur l’automatisation : peut-être qu’un pool « primaire » basé sur les J’aime pourrait faire passer les demandes au statut de vote possible.
Pensée sur la curation manuelle : occasionnellement, une demande avec un mérite évident est reprise par le personnel indépendamment des votes, donc d’une certaine manière, une certaine curation a déjà lieu. Mais peut-être que tout devrait passer par un rapide examen par le personnel ?
Exemple à l’appui : J’ai trouvé 8 demandes de fonctionnalité concernant « laisser les utilisateurs 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 faite de manière répétée alors que les versions plus anciennes ne sont pas remarquées et non votées.
Si les utilisateurs ne recherchent pas — ou ne voient pas les dialogues « votre sujet est similaire… » — je ne vois pas ce qui pourrait être fait d’autre que de faire en sorte que les demandes initiales atteignent un point de contrôle du personnel : 
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 tout haut. Je sais que tout demande 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 les éléments précédemment votés ont été mis en œuvre ou n’ont plus d’importance.
Compiler les demandes de fonctionnalités dans une liste de celles que l’équipe envisage d’ajouter à l’avenir et libérer ces votes pour qu’ils soient réutilisés a du sens, selon moi.
Pourquoi même utiliser le vote par sujet ? Comme vous l’avez mentionné, les J’aime/réactions pourraient être utilisés au lieu d’être limités à un nombre défini de votes. Utiliser par exemple une réaction particulière comme 
pourrait suffire à évaluer l’intérêt pour une demande de fonctionnalité particulière, car vous pourriez utiliser un script d’explorateur de données dans cette catégorie pour renvoyer les meilleurs sujets, peut-être dans la publication originale, avec le plus grand nombre de cette réaction particulière.
Par rapport à la limitation des votes, cela ne semble vraiment pas aller nulle part car il n’y a, d’après mon expérience, aucune mise à jour directement liée à cette catégorie. Il peut y en avoir de temps en temps et je ne l’ai peut-être tout simplement pas remarqué.
Je suis sûr que certaines des nouvelles choses déployées ont pu être une demande de fonctionnalité à un moment donné.
Selon moi, le vote par sujet pourrait être meilleur pour les concours, pour voter sur les X meilleurs sujets avec une date de clôture définie pour annoncer les 3 premiers gagnants le jour de l’annonce. Mais utilisé dans cette catégorie, cela ressemble plus à un concours sans conclusion claire, nécessitant de remettre en question ses votes.
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 »