Cosa pensano le persone sia un numero ragionevole di voti da consentire per livello di fiducia? Vedo che su meta abbiamo cambiato TL0 da 2 a zero voti e TL4 da 10 a 8. Ho notato che ho esaurito i voti anch’io, anche se sono amministratore qui! 
2 Mi Piace
Ho sempre pensato che il numero sia deliberatamente limitato in modo che funzioni come un indicatore di “questo è davvero importante per me”. Posso comunque mettere “mi piace” a tutte le richieste e aggiungere il mio caso d’uso alle richieste di funzionalità anche se esaurisco i voti. E posso ancora votare su questi argomenti una volta che un’altra richiesta di funzionalità per cui ho votato è completata e l’argomento è chiuso.
1 Mi Piace
@tobiaseigen, non li limiterei… Mi ritrovo a non usare mai i voti perché, per me, o supporto o mi oppongo a qualcosa; cercare di accertare se qualcosa è seriamente importante per me non è un uso particolarmente pragmatico del mio tempo, quando esistono invece i “mi piace”.
2 Mi Piace
Ho spostato questa recente discussione nell’originale di Jammydodger, perché mi sembra giusto continuare a parlare qui del voto per le funzionalità da contribuire (Contribute > Feature).
Mi piace l’idea di stabilire dei limiti, ma penso anche che ci siano così tante richieste di funzionalità aperte che mi sembra ingiusto avere un limite molto basso. Mi sento limitato da questa regola! I voti sono anche un segnale e, impedendo alle persone di votare, stiamo privando il team prodotto di tale segnale.
Sono propenso ad aumentare i limiti secondo le linee guida seguenti. Cosa ne pensate?
| Livello di Fiducia | Voti Attuali | Voti Proposti |
|---|---|---|
| TL0 | 0 | 0 |
| TL1 | 4 | 10 |
| TL2 | 6 | 20 |
| TL3 | 8 | 24 |
2 Mi Piace
Imo 24 lo trasforma in praticamente illimitato
Mi piacciono i limiti attuali, ti fanno pensare
2 Mi Piace
Mi chiedo se la rigida razionalizzazione dei preziosi voti non porti a un’intelligence limitata. I conteggi dei voti sembrano generalmente bassi rispetto al numero di utenti qui. Molte suggerimenti per nuove funzionalità hanno più “Mi piace” che voti, ma immagino che vengano notati solo i voti.
Essere costantemente senza voti e dover sempre fare una triage e sacrificare per votare qualcosa di nuovo è un ostacolo significativo. Esamino i miei voti esistenti per vedere come liberare voti… ma nessuna delle richieste è indegna. Sono semplicemente scivolate fuori dal feed ed erano state dimenticate.
Devo rinunciare a loro?
Dovrei rilanciare i miei preferiti con un commento? Dopo aver votato una funzionalità, commentare “Sì, buona idea!” sembra un disordine superfluo.
Le buone idee restano con uno o due voti. Le persone non le scoprono, non sono interessate, o… sono semplicemente senza voti? 
Aumentare i limiti non richiederebbe una serie di codifiche e sembra che aiuterebbe, ma penso anche a come allargare una strada per ridurre il traffico attiri semplicemente più traffico e ti ritrovi dove hai iniziato.
Sto solo buttando lì delle idee… alcuni cambiamenti funzionali che richiedono molta codifica come alternative a un limite rigido:
- Assegnare un numero di voti al mese in base al TL. (Il “giorno dei voti” c’è un’impennata di attività mentre le persone visitano Contribute > Feature e valutano gli elementi aperti…)
…oppure, come ha menzionato heliosurge, rilasciare gradualmente i voti:
- Rilasciare un voto utilizzato dopo un certo periodo, oppure
- Il personale esamina le richieste di funzionalità obsolete su base rotatoria e o a.) rilancia l’argomento per un’altra possibilità, o b.) commenta con “nessun piano per affrontarlo” e rilascia i voti.
…In entrambi i casi, i voti espressi rimangono invariati e gli utenti non possono superare la loro assegnazione di voti annullando ulteriormente questi argomenti.
(Facile a dirsi per me. Probabilmente richiede molta codifica 
)
2 Mi Piace
@sam, per me non è così, dato che uso solo i like. La sua implementazione attuale sembra un po’ ridondante, un po’ come l’esistenza sia del voto positivo che del pollice in su per GitHub Discussions.
2 Mi Piace
Concordo che avere segnali duplicati sia fonte di confusione
“Mi piace come hai scritto la richiesta di funzionalità, mi sembra buona”
Vs
“Questo è sicuramente tra i miei primi 8, penso che Discourse dovrebbe costruirlo”
Potrebbe essere un esperimento interessante disabilitare i “mi piace” dell’OP quando il voto per argomento è abilitato
1 Mi Piace
C’è qualcosa riguardo alla chiusura di alcune richieste con “ci dispiace, non lo faremo”.
C’è sicuramente qualcosa di estremamente convincente nel chiudere funzionalità completate da 2 anni come fatte, e richieste di funzionalità che non hanno più alcun senso come obsolete.
2 Mi Piace
Non credo che alla fine cambierebbe molto. La maggior parte dei miei voti è stata aggiunta un anno fa. Sì, avrei potuto votare su più argomenti, ma una volta spesi tutti i miei voti è la stessa cosa: dovrei aspettare che uno venga completato e chiuso, oppure dovrei rimuovere il mio voto da un altro argomento. Sono abbastanza sicuro che ci siano anche più di 20 buone richieste di funzionalità su Meta 
Come ho detto prima, per me i voti sono qualcosa di più forte di un “mi piace”. Ma penso ancora che i “mi piace” sul primo post siano molto utili per catturare l’interesse. Sono stati l’indicatore per più di 10 anni quando il voto non era abilitato. Quindi ignorarli, specialmente su richieste di lunga data, significa ignorare l’unico modo in cui gli utenti potevano mostrare supporto all’epoca.
Inoltre, forse nessuno pensa che la richiesta di funzionalità sia qualcosa di cui ha bisogno così tanto da spendere un voto, ma a molti utenti piace perché pensano che sarebbe utile. Un voto (solitamente dell’autore della richiesta) dice di più su quanto sarebbe utile quella funzionalità per una serie di diversi siti Discourse rispetto a più “mi piace”?
Mi chiedo se, invece di aumentare il numero di voti “Sono veramente interessato a questo”, sarebbe meglio limitare il numero di argomenti su cui possono essere distribuiti.
Quindi, invece di avere 378[1] argomenti di quest’anno su cui votare, potrebbe avere senso pre-selezionarli.
Ad esempio, solo le richieste con una certa quantità di reazioni che indicano interesse da parte di più utenti sono quelle su cui si può votare, oppure si potrebbe limitare per tempo e dire che il voto è limitato agli argomenti di un certo periodo di tempo al fine di trovare i preferiti all’interno di quel gruppo di funzionalità.
Potresti anche dire: “Stiamo rivedendo la coda di revisione. Quali richieste ti vengono in mente?” Quindi quelle verrebbero spostate in una sottocategoria e votate.
Essere in grado di spendere 4 voti su ~100 argomenti sarebbe proporzionalmente di più che essere in grado di spendere 10 voti su tutti gli argomenti di funzionalità aperti.
\n
↩︎
3 Mi Piace
@sam, speravo nel contrario. I voti forniscono qualcosa, tecnicamente, che i “mi piace” non offrono? Dubito che a qualcuno piaccia una FR che non supporta.
Se i “mi piace” fossero disabilitati quando i voti sono abilitati, ciò “ridurrebbe l’intelligenza”, credo. A titolo di confronto, il fatto che Forgejo e GitLab non limitino i voti positivi potrebbe indicare che esiste un valore nell’averli come semplice indicatore di supporto o non supporto.
Oggi, esplorando per curiosità il canale Contribute > Feature, è stato interessante confrontare queste visualizzazioni filtrate:
- Risultati filtrati per categoria:feature stato:open ordinamento:likes-op
- Risultati filtrati per categoria:feature stato:open ordinamento:votes
Mi chiedo cosa si potrebbe fare con una query di Data Explorer che includa sia i Voti che i Mi piace… 
Inoltre:
Pensiero sull’automazione: forse un “pool” primario basato sui Mi piace potrebbe promuovere le richieste allo stato di votabilità.
Pensiero sulla curatela manuale: occasionalmente, una richiesta con un merito evidente viene raccolta dallo staff indipendentemente dai voti, quindi in un certo senso una curatela avviene già. Ma forse tutto dovrebbe essere sottoposto a una rapida revisione da parte dello staff?
Esempio a supporto: ho trovato 8 richieste di funzionalità relative a “consentire agli utenti di chiudere i propri argomenti” — dal 2014 al 2025 — alcune chiuse, ma la maggior parte ancora aperte con 0 voti. Qualcosa non funziona bene se la stessa richiesta viene fatta ripetutamente mentre le versioni precedenti passano inosservate e non vengono votate.
Se gli utenti non stanno cercando — o non vedono i dialoghi “il tuo argomento è simile…” — non sono sicuro di cosa altro si possa fare, se non far sì che le richieste iniziali raggiungano un checkpoint dello staff: 
se è nuovo, sposta l’argomento in una categoria di voto; 
se esiste una richiesta simile, rispondi con un link.
Sto pensando ad alta voce. So che tutto richiede risorse…
Il limite andrebbe bene se il team rilasciasse i voti dopo aver composto un elenco di argomenti votati. Forse rilasciare i voti trimestralmente. L’aggiornamento potrebbe persino dettagliare le funzionalità che il team ha scelto di aggiungere alla roadmap con una potenziale tempistica in termini di priorità.
Altrimenti 24 non è davvero illimitato poiché alcuni voti sono rimasti bloccati per oltre un anno e forse anche di più. È anche un problema cercare di rimuovere i voti in funzionalità apparentemente morte che potrebbero non essere nemmeno prese in considerazione.
Forse un’idea è creare di tanto in tanto un elenco di funzionalità che il team sta considerando seriamente e creare un sondaggio per far votare le persone e poi aggiornare le cose da lì. Il voto per argomento non è male se c’è un ciclo di rilascio. Quale dovrebbe essere tale ciclo è qualcosa che il team deve discutere e decidere.
non capisco, non potete rilasciare i voti su cose che non sono più importanti per voi?
Questo presuppone che le cose già votate siano state implementate o che non abbiano più importanza.
Raccogliere le richieste di funzionalità in un elenco di quelle che il team sta valutando di aggiungere in futuro e rilasciare quei voti per essere riutilizzati, a mio parere, ha senso.
Perché usare il voto sui topic? Come hai menzionato, i Mi piace/reazioni potrebbero essere utilizzati invece di essere limitati a un numero fisso di voti. Utilizzare, ad esempio, una reazione specifica come 
potrebbe essere sufficiente per valutare l’interesse per una particolare richiesta di funzionalità Contribute, dato che potresti utilizzare uno script di esplorazione dati in questa categoria per restituire i topic principali, magari nel primo post, con il maggior numero di questa specifica reazione.
Invece di limitare il voto, che davvero non sembra portare da nessuna parte, poiché nella mia esperienza non ci sono aggiornamenti direttamente correlati a questa categoria. Potrebbero essercene da tempo a tempo e forse non li ho semplicemente notati.
Sono sicuro che alcune delle nuove funzionalità introdotte siano state in un certo momento una richiesta di funzionalità.
A mio parere, il voto sui topic potrebbe essere più adatto per i concorsi, votando i top X topic con una data di chiusura prestabilita per annunciare i primi tre vincitori del giorno. Ma usato in questa categoria, sembra più un concorso senza una conclusione chiara, costringendoti a indovinare le tue scelte.
1 Mi Piace
Ho commentato molto sul processo qui, ma ad essere onesti, ci sono molte richieste di funzionalità contrassegnate come completed – Risultati filtrati per categoria:feature tag:completed
2 Mi Piace
Il tag completato è d’aiuto. Ma trovo che se il team vuole valutare un maggiore interesse per le richieste di funzionalità, limitare il numero di voti può essere controproducente.
Come ha menzionato Sam con i vari segnali come Mi piace/Reazioni. (Scegli una reazione specifica) O anche nessun limite di voto. Poiché non tutte le Idee riceveranno voti/reazioni da parte delle persone, poiché potrebbero non essere interessate a una specifica idea. Ad esempio, c’è, credo, una richiesta per l’elezione di un team del forum.
Mentre su alcuni forum questa potrebbe essere un’idea/opzione, molti non vorrebbero che un potenziale concorso di popolarità decidesse chi controlla il forum.
Quindi otterrai comunque Funzionalità con più voti/reazioni che indicano il livello di interesse generale della comunità rispetto alla limitazione a un numero fisso che è più probabile che divida l’interesse e abbia molti più Pareggi, per così dire.
1 Mi Piace
La revisione del tag aiuta effettivamente a vedere quanto è stato aggiunto. Sembra solo troppo restrittivo limitare l’interesse del voto. Anche alcune delle funzionalità completate avevano voti minimi o nulli. Certo, le vittorie facili e semplici sono ovviamente buone.
Il mio sogno qui sarebbe che tutti avessero le proprie visualizzazioni personalizzate e classificate delle funzionalità, che potremmo quindi aggregare in diverse visualizzazioni collettive attraverso diverse “lenti”.
Quindi, invece di avere un voto/non voto binario in tutto, potrei mettere insieme la mia lista dei “dieci migliori” e mostrarli in ordine di preferenza. Potresti fare lo stesso. E poi potrei fare cose come “mostrami la lista dei dieci migliori per le persone che si sono unite a meta nell’ultimo anno” o “mostrami la lista dei dieci migliori per le persone che utilizzano il nostro piano starter”, ecc.
Nel frattempo, ho altre idee su come possiamo rendere le cose un po’ più gestibili qui, che si collegano alle idee su come gestiamo una roadmap e un backlog aperti in generale. Queste implicano alcuni cambiamenti nel modo in cui gestiamo le categorie di bug, funzionalità e ux, e nel modo in cui separiamo l’ideazione più aperta dalle proposte più concrete e/o dalle specifiche per le cose che stiamo pianificando di affrontare o che saremmo felici di vedere contribuite.
Spero di riuscire a preparare qualcosa di simile a una RFC per questa discussione prima della fine dell’anno.
4 Mi Piace