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 discussione recente in quella originale di Jammydodger perché mi sembra giusto continuare a parlare qui di votazione.
Mi piace l’idea dei limiti, ma penso anche che ci siano così tante richieste di funzionalità aperte che sembra ingiusto avere un limite molto basso. Mi sento limitato da questo anch’io! I voti sono anche un segnale, e non permettendo alle persone di votare stiamo privando il team di prodotto di quel segnale.
Sono propenso ad aumentare i limiti lungo le linee sottostanti. 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 comporti informazioni limitate. I conteggi dei voti sembrano generalmente bassi per il numero di utenti qui. Molti suggerimenti di funzionalità hanno più Mi piace che voti, ma immagino che solo i voti vengano notati.
Essere perennemente senza voti e dover sempre dare priorità e sacrificare per votare su qualsiasi cosa di nuovo è una barriera significativa. Rivedo i miei voti esistenti (i miei voti esistenti) per vedere come posso liberare voti… ma nessuna delle richieste è indegna. Sono semplicemente scivolate via dal feed e dimenticate.
Devo rinunciarvi?
Dovrei dare una spinta ai miei preferiti con un commento? Avendo votato per una funzionalità, commentare “Sì, buona idea!” sembra un ingombro superfluo.
Le buone idee rimangono con uno o due voti. Le persone non le scoprono, non sono interessate, o… sono semplicemente senza voti? 
Aumentare i limiti non richiederebbe un sacco di codice e sembra che aiuterebbe, ma penso anche a come allargare una strada per ridurre il traffico invita solo più traffico e si torna al punto di partenza.
Sto solo buttando giù idee… alcune modifiche funzionali che richiedono un sacco di codice come alternative a un limite rigido:
- Assegnare un numero di voti al mese in base al TL. (Nel “giorno dei voti” c’è un’ondata di attività mentre le persone visitano Feature e valutano gli elementi aperti…)
…o, come ha menzionato heliosurge, rilasciare i voti alla fine:
- Rilasciare un voto utilizzato dopo un certo tempo, o
- Lo staff esamina le richieste di funzionalità obsolete su base continuativa e o a.) dà una spinta all’argomento per un’altra possibilità, o b.) commenta con “nessun piano di affrontare” e rilascia i voti.
…In entrambi i casi, i voti espressi rimangono in vigore e gli utenti non possono superare la loro allocazione di voti non votando ulteriormente questi argomenti.
(Facile per me dirlo. Probabilmente è un sacco di codice 
)
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.
Curiosando oggi in Feature per curiosità, è stato interessante confrontare queste visualizzazioni filtrate:
- Risultati filtrati per categoria:feature stato:aperto ordine:mi piace-op
- Risultati filtrati per categoria:feature stato:aperto ordine:voti
Mi chiedo cosa si potrebbe fare con una query di Data Explorer che includa sia Voti che Mi Piace… 
Inoltre:
[quote=“Moin, post:30, topic:308402”]invece di avere 378 argomenti di quest’anno su cui votare, potrebbe avere senso pre-selezionarli
[/quote]
Pensiero sull’automazione: forse un pool “primario” basato sui Mi Piace potrebbe promuovere le richieste allo stato votabile.
Pensiero sulla curatela manuale: occasionalmente una richiesta con merito ovvio viene raccolta dallo staff indipendentemente dai voti, quindi in un certo senso, una certa curatela avviene già. Ma forse tutto dovrebbe essere sottoposto a una rapida revisione dello staff?
Esempio di supporto: ho trovato 8 richieste di funzionalità relative a “consentire agli utenti di chiudere i propri argomenti” – dal 2014 al 2025 – un paio chiuse, ma la maggior parte aperte con 0 voti. Qualcosa non funziona bene se la stessa richiesta viene fatta ripetutamente mentre le versioni precedenti vengono ignorate e non votate.
Se gli utenti non cercano — o non vedono i dialoghi “il tuo argomento è simile…” — non sono sicuro di cos’altro si possa fare se non far sì che le richieste iniziali raggiungano un punto di controllo dello staff: 
se nuovo, sposta l’argomento in una categoria di voto; 
se esiste una richiesta simile, rispondi con un link.
Sto solo 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?
Ciò presuppone che le cose votate in precedenza siano state implementate o non abbiano più importanza.
Raccogliere le richieste di funzionalità in un elenco di quelle che il team sta considerando di aggiungere in futuro e rilasciare nuovamente quei voti da utilizzare, secondo me, ha senso.
Perché usare persino il voto per argomenti? Come hai menzionato, i Mi piace/reazioni potrebbero essere utilizzati invece di essere limitati a un numero fisso di voti. Usare, ad esempio, una particolare reazione come 
potrebbe essere sufficiente per valutare l’interesse per una particolare richiesta di #funzionalità, poiché potresti usare uno script di esplorazione dati in questa categoria per restituire gli argomenti principali, magari nel post Op, con la maggior parte di questa particolare reazione.
Rispetto al limitare il voto, che in realtà non sembra portare da nessuna parte poiché, nella mia esperienza, non ci sono aggiornamenti direttamente correlati a questa categoria. Potrebbero essercene di tanto in tanto e forse non me ne sono accorto.
Sono sicuro che alcune delle nuove cose introdotte siano state una richiesta di funzionalità in passato.
Secondo me, il voto per argomenti potrebbe essere migliore per i Concorsi, votando per i primi X argomenti con una data di chiusura stabilita per annunciare i primi 3 vincitori. Ma usato in questa categoria sembra più un concorso senza una conclusione chiara, con la necessità di rimettere in discussione i propri voti.
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