Segnalazione incoerente di argomenti come ☑️ Risolto, Completato o Sistemato qui su meta.discourse.org

Ciao staff di Discourse, che gestite e mantenete con amore questo fantastico forum online con il vostro prodotto.

Noto che abbiamo il Plugin Risolto attivo per Support. Ottimo vedere questo fantastico dogfooding in pratica! Lo stesso vale per l’uso dei tag fixed e completed.

Sfortunatamente, ci sono un sacco di argomenti in Support, Bug, Feature e UX che non sono stati contrassegnati con questi. Questo crea molta confusione per gli utenti di questo forum e ostacola la ricerca efficace di soluzioni esistenti. In sostanza, se questi non verranno utilizzati in modo coerente, probabilmente non dovrebbero essere utilizzati affatto.

Posso chiedere che questo venga prioritizzato in futuro e che qualcuno (?stagista, ??AI) venga incaricato di contrassegnare correttamente quelli vecchi?

8 Mi Piace

Grazie, Nathan! Ti apprezzo per aver sollevato la questione. :sunflower: Vogliamo assolutamente fare di più in questo reparto.

Sembra che l’abilitazione delle soluzioni per la categoria Support abbia funzionato abbastanza bene per quella categoria. Anche i tag fixed e completed sono molto utili, e possono essere utilizzati in tutte le categorie.

3 Mi Piace

Non vedo il tag completed in Marketplace.

Credo che questi siano riservati allo staff.

Forse sarebbe utile estenderlo a trust_level_3? Questo potrebbe anche aiutare con Marketplace come da punto di Jay sopra.

2 Mi Piace

FWIW Per Marketplace c’è delivered, che non è limitato al team.

4 Mi Piace

Grazie per aver condiviso il contesto, James! :hugs:

Quindi, per riassumere, sembra che al momento abbiamo cinque modi per indicare quando un argomento ha raggiunto il suo corso e deve essere concluso. Questo riassume la situazione?

cosa dove chi
:check_box_with_check: Discourse Solved Support Installation Dev Data & reporting SSO proprietario dell’argomento, @team, TL4
fixed Bug UX (funziona ovunque) @team
completed Feature UX @team
delivered Marketplace tutti i membri
:locked: chiudi argomento ovunque @team e automatico

Questo mi sembra un’enorme varietà. Non so perché i tag siano diversi. Forse è utile/informativo per le persone poter scorrere individualmente questi elenchi di tag. Tuttavia, questi tag e il loro scopo non sono molto scopribili.

:check_box_with_check: solved è facilmente scopribile e funziona abbastanza bene per il supporto. Penso che abbia senso limitarlo a quella categoria. È utile poter filtrare gli argomenti risolti/non risolti in quella categoria - spesso dimentico quel menu a discesa, tuttavia, e vorrei che fosse più scopribile nell’interfaccia utente. :blush:

fixed è utilizzato solo in Bug UX e significa che un bug o un bug UX è stato corretto.

completed è utilizzato anche in Support Feature UX. UX perché gli argomenti UX sono spesso anche richieste di funzionalità. C’era un argomento, "Reader Mode" theme component feedback, che era in Site feedback ma l’ho spostato in Theme component dove sembra appartenere ora che il componente è stato rilasciato.

delivered è utilizzato solo in Marketplace.

Gli argomenti vengono :locked: chiusi per una serie di motivi diversi:

  • Gli argomenti Support vengono chiusi un mese dopo l’ultima risposta, una volta risolti
  • Gli argomenti Marketplace vengono chiusi un mese dopo l’ultima risposta, indipendentemente dal fatto che siano delivered o meno.
  • i moderatori chiudono gli argomenti
    • quando sono risolti
    • per impedire risposte (ad es. documentazione o release-notes)
    • come tattica di moderazione per porre fine alle discussioni in argomenti che sono diventati improduttivi o hanno esaurito il loro corso

Alcuni potenziali passi successivi:

  • aggiungere descrizioni ai tag fixed completed delivered che spieghino come li utilizziamo
  • creare una query di esplorazione dati con risultati come la tabella sopra, ma elencando il numero reale e aggiornato di argomenti risolti/non risolti, corretti/non corretti, completati/non completati, consegnati/non consegnati
  • creare una query di esplorazione dati che elenchi gli argomenti che sono stati chiusi, corretti, completati, consegnati in un dato periodo di tempo
  • creare un argomento qui in Site feedback per condividere i risultati delle query di cui sopra ogni settimana utilizzando un’automazione
  • creare un argomento qui con una piccola guida su come concludere gli argomenti e riunire un team per iniziare a lavorare sull’elenco, in ordine cronologico inverso
3 Mi Piace

Ho aggiunto le descrizioni come segue, che appariranno quando si passa il mouse sopra il tag o si va alla pagina del tag. Fatemi sapere se avete suggerimenti. Sono combattuto tra mantenerlo breve e conciso e fornire un contesto più dettagliato. Le categorie stesse hanno anche descrizioni più dettagliate.

fixed

Diamo priorità alla correzione dei bug nel nostro software segnalati nelle categorie Bug e UX. Una volta corretti i bug, viene assegnato loro questo tag.

completed

Quando le funzionalità suggerite nelle categorie Feature e UX vengono implementate, viene assegnato loro questo tag.

delivered

Quando un argomento in Marketplace viene confermato come consegnato dal fornitore o dal destinatario, viene assegnato a questo tag.

3 Mi Piace

Accidenti. L’hai reso complicato. :slight_smile:

Apparentemente, si applica il tag fixed ai bug che sono stati corretti e completed alle richieste di funzionalità che sono state implementate. [1] Fa parte del processo per chiudere gli argomenti (e mantenere le parti interessate aggiornate con le informazioni pertinenti). Sono stati inizialmente implementati per fornire un’indicazione visiva che ‘è successo qualcosa di buono’ rispetto al simbolo di blocco di un argomento chiuso. Quando questi tag vengono applicati in modo coerente, si ottiene una bella onda verde scorrendo le liste degli argomenti della loro categoria.

(E delivered era uno separato ma simile che non era controllato dal team, quindi poteva essere usato in Marketplace)

Per Solved, ci sono diverse categorie in cui è attivo piuttosto che solo la categoria generica Support. Praticamente qualsiasi categoria in cui la maggior parte degli argomenti sono domande a cui si può trovare una soluzione. Support, Installation, Dev, Data & reporting, SSO

Idealmente, la best practice è che l’OP contrassegni la soluzione, ma sappiamo che a volte questo non accade (per una serie di motivi), quindi spesso scorrevo le liste degli argomenti e ripulivo quelle in sospeso dopo un paio di settimane o giù di lì (una volta che erano considerate ‘abbandonate’).

FWIW L’argomento Theme component per quello è Reader Mode, quindi in realtà quell’argomento feedback che hai linkato non dovrebbe essere in Theme component (poiché non è un argomento di componente tema). Dovrebbe probabilmente essere in Feature o UX poiché penso che sia lì che questi sono finiti ora che ce ne sono di più.

(Penso che fosse in Site feedback poiché era un esperimento qui su meta)


  1. e con UX che è una via di mezzo tra i due, si può usare uno o l’altro a seconda del ‘sapore’ dell’argomento specifico ↩︎

6 Mi Piace

Fantastico! Grazie per aver colmato alcune lacune. Ho aggiornato la mia tabella sopra.

Ciò non è stato fatto sistematicamente da quando te ne sei andato, motivo per cui ora abbiamo questo argomento per parlare di recuperare e avere un sistema in atto in modo da non rimanere indietro di nuovo.

Ottima osservazione! L’ho spostato in Feature.

1 Mi Piace

Sì, credo che fosse quello a cui puntavo con l’OP. @JammyDodger - ci manchi tu e la tua dedizione nel mantenere Meta così fluida! Personalmente, spero che ti facciano un’offerta che non puoi rifiutare…

4 Mi Piace