Segnalazione incoerente dei Topic come ☑️ Risolti, Completati o Corretti qui su meta.discourse.org

Ciao a tutto il meraviglioso staff di Discourse che gestisce e mantiene con tanto amore questo fantastico forum online con il proprio prodotto.

Ho notato che il plugin Solved è attivo per Support. È fantastico vedere questo dogfooding in azione! Lo stesso vale per l’uso dei tag fixed e completed.

Purtroppo ci sono un sacco di Discussioni in Support, Contribute > Bug, Contribute > Feature e Contribute > UX che non sono state contrassegnate con questi tag. Questo è piuttosto confuso per gli utenti di questo forum e ostacola ricerche efficaci di soluzioni già esistenti. In sostanza, se non devono essere usati in modo coerente, probabilmente non dovrebbero essere usati affatto.

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

10 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 quel contesto, James! :hugs:

Quindi, per riassumere, sembra che al momento abbiamo cinque modi per indicare quando un argomento ha seguito il suo corso e deve essere chiuso. Questo lo riassume correttamente?

cosa dove chi
:check_box_with_check: Discourse Solved Support #installation Development #data-reporting Support > SSO proprietario dell’argomento, @team, TL4
fixed Contribute > Bug Contribute > UX (funziona ovunque) @team
completed Contribute > Feature Contribute > UX @team
delivered Marketplace tutti i membri
:locked: chiudi argomento ovunque @team e automatico

Questo mi sembra davvero una varietà enorme. Non so perché i tag siano diversi. Forse è utile/informativo che le persone possano scorrere individualmente quelle liste di tag. Tuttavia, questi tag e il loro scopo non sono così facilmente individuabili.

:check_box_with_check: solved è facilmente individuabile e funziona molto bene per il supporto. Credo abbia senso limitarlo a quella categoria. È utile poter filtrare gli argomenti risolti/non risolti in quella categoria — anche se spesso dimentico quel menu a tendina e vorrei fosse più evidente nell’interfaccia utente. :blush:

fixed è usato solo in Contribute > Bug e Contribute > UX e indica che un bug o un problema UX è stato risolto.

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

delivered è usato solo in Marketplace.

Gli argomenti vengono :locked: chiusi per una varietà 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 esempio documentazione o release-notes)
    • come tattica di moderazione per porre fine a discussioni in argomenti che sono diventati improduttivi o hanno seguito il loro corso

Alcuni possibili prossimi passi:

  • aggiungere descrizioni ai tag fixed, completed e delivered che spiegano come li utilizziamo
  • creare una query di Data Explorer con risultati simili alla 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 Data Explorer che elenchi gli argomenti che sono stati chiusi, corretti, completati o consegnati in un determinato arco temporale
  • creare un argomento qui in Contribute > Site feedback per condividere i risultati delle query sopra ogni settimana utilizzando un’automazione
  • creare un argomento qui con una piccola guida su come chiudere gli argomenti e riunire un team per seguirlo, iniziando a lavorare sulla lista in ordine cronologico inverso
4 Mi Piace

Ho aggiunto le descrizioni come segue, in modo che appaiano quando passi il mouse sopra il tag o vai alla pagina del tag. Fammi sapere se hai suggerimenti. Sono indeciso tra mantenerle brevi e concise o fornire un contesto più dettagliato. Le categorie stesse hanno descrizioni più dettagliate.

fixed

Diamo priorità alla risoluzione dei bug nel nostro software segnalati nelle categorie Contribute > Bug e Contribute > UX. Una volta risolti, i bug ricevono questo tag.

completed

Quando le funzionalità suggerite nelle categorie Contribute > Feature e Contribute > UX vengono implementate, ricevono questo tag.

delivered

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

3 Mi Piace

Mamma mia. Lo hai fatto sembrare complicato. :slight_smile:

In apparenza, applichi il tag fixed ai bug che sono stati risolti e completed alle richieste di funzionalità che sono state implementate. [1] Fa parte del processo di chiusura degli argomenti (e di aggiornamento delle parti interessate con le informazioni rilevanti). Sono stati inizialmente implementati per fornire un’indicazione visiva del fatto che ‘era successo qualcosa di buono’ rispetto al simbolo di lucchetto di un argomento chiuso. Quando questi tag vengono applicati in modo coerente, si ottiene un bel effetto a onde verdi quando si scorre l’elenco degli argomenti nelle rispettive categorie.

(E delivered era un tag separato ma simile, non controllato dal team, quindi poteva essere utilizzato in Marketplace)

Per Risolto, ci sono diverse categorie in cui è attivo, non solo la categoria generica Support. Praticamente tutte le categorie in cui la maggior parte degli argomenti saranno domande che possono ottenere una soluzione. Support, #installation, Development, #data-reporting, Support > SSO

Idealmente, la migliore pratica è che l’autore originale contrassegni la soluzione, ma sappiamo che a volte non succede (per una varietà di motivi), quindi spesso scorro indietro gli elenchi degli argomenti e ne pulisco alcuni pendenti dopo un paio di settimane (una volta che sono stati considerati ‘abbandonati’).

Per quel che vale, l’argomento Customization > Theme component per quello è Reader Mode, quindi in realtà quell’argomento feedback che hai linkato non dovrebbe essere in Customization > Theme component (poiché non è un argomento relativo a un componente tema). Dovrebbe probabilmente essere in Contribute > Feature o Contribute > UX, poiché penso che sia lì che questi argomenti hanno trovato casa ora che ce ne sono di più.

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


  1. e con Contribute > UX che rappresenta una via di mezzo tra i due, si può usare l’uno o l’altro a seconda della ‘tipologia’ dell’argomento specifico ↩︎

8 Mi Piace

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

Questo non è stato fatto in modo sistematico dalla tua partenza, motivo per cui ora abbiamo questo topic per parlare di come recuperare il ritardo e istituire un sistema per non cadere di nuovo in ritardo.

Ottima osservazione! L’ho spostato in Contribute > 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…

6 Mi Piace

Torno a parlare di questo argomento perché di recente sono stato sgridato per aver segnalato un topic in Contribute > Feature che, a mio avviso, avrebbe dovuto essere marcato come completed, ma non lo è stato.

Quello che avrei voluto fare era semplicemente taggarlo io stesso. Tuttavia, poiché quel tag è riservato a @staff, non potevo. Ehi, come TL4 posso fare un sacco di cose potenzialmente distruttive, ma non quella. Non posso nemmeno modificare i tag in alcune categorie (ad esempio Customization > Plugin).

Quindi, come si fa a segnalare queste piccole cose ai moderatori senza infastidirli e senza sentirsi rimproverare? O forse l’intenzione è lasciare tutto un po’ in disordine?

6 Mi Piace

Penso che vada bene contrassegnare l’argomento come altro e dire che pensi debba essere contrassegnato come completato/risolto, almeno per gli argomenti “vecchi” (cioè: è stato completato/risolto 6 mesi fa ma l’argomento non è stato aggiornato).

(Anche se altri non sono d’accordo)

Per le cose urgenti: sarebbe buona norma per il nostro staff assicurarsi di dare seguito alle cose che risolvono.

6 Mi Piace

Penso che se aggiungessimo dei tag per contrassegnare ogni funzionalità completata negli ultimi 13 anni in cui questo forum è stato attivo, perché le persone hanno il DOC (Disturbo Ossessivo Compulsivo), sarebbe una grande perdita di tempo per tutti.

Il tag stesso è piuttosto nuovo, non è mai stato ampiamente adottato, e potremmo semplicemente chiudere gli argomenti per le funzionalità completate, consentendo a tutti di creare nuovi argomenti e citare quelli vecchi se necessario.

Preferirei rimuovere il flag #completed. È stato applicato 400 volte ed è stato creato solo come un modo per aiutare le persone a scrivere i registri delle modifiche (changelog), che ora vengono gestiti in modo diverso.

6 Mi Piace

Non sono sicuro di riconoscere questo come la ragione. È stato inizialmente implementato per fornire un indicatore visivo che separasse le richieste di funzionalità completate dal resto degli argomenti chiusi. C’è una conversazione da qualche parte qui tra me, Sam e Dave con maggiori informazioni, se fai una ricerca. (Penso fosse in qualche “sussurro”, ma non ricordo esattamente dove).

Personalmente, all’epoca non lo trovai particolarmente oneroso da tenere sotto controllo. :person_shrugging: Mi concentravo di più sulla finestra “attiva” per garantire che gli argomenti nella parte superiore di /latest fossero più coerenti, anche se ne ho curati altri se mi capitavano sotto gli occhi (argomenti correlati, e via dicendo). Effettuare un’audit completo della categoria Contribute > Feature sarebbe infatti un compito molto più grande. :slight_smile: (non per dire che non sarebbe utile esaminare e potare/fondere/chiedere quelli che sono stati persi nel corso degli anni, sto solo dicendo che richiederebbe tempo e bisognerebbe valutare dove collocarlo nella lista delle priorità).

È questa una paura di ciò che potrebbe accadere, o sta già accadendo davvero? Se fosse un caso occasionale, non sono sicuro che sia un problema troppo grande, ma se diventasse un modello, allora concordo che il sistema dei flag non sarebbe il luogo migliore per questo. Penso che un MP sarebbe un modo meno invasivo per raccogliere le informazioni.

Ma capisco anche che non vuoi davvero che sviluppatori, designer, ecc. vengano risucchiati troppo profondamente in questo, poiché avranno altro lavoro importante da fare invece di sistemare il meta. :heart:

4 Mi Piace

Forse le cose che richiedono un moderatore, ma non sono urgenti, potrebbero essere segnalate tramite messaggi privati a una casella di posta separata per un gruppo. In questo modo, tali registri di pulizia non inonderebbero la coda di revisione, nascondendo gli argomenti in cui qualcuno deve agire presto, ma ci sarebbe comunque un posto dove raccoglierli, in modo che qualcuno possa occuparsene se ha qualche minuto.

Questo potrebbe funzionare per tutti i tipi di note a margine, come un tag mancante, un link di anteprima non funzionante in un argomento di componente del tema o un argomento di funzionalità che potrebbe essere chiuso, in modo che i voti vengano restituiti agli utenti.

6 Mi Piace

Oh! Mi sto rendendo conto che il gruppo dei moderatori non ha nessuno al suo interno! Ora capisco perché un messaggio privato che ho scritto a @moderators un paio di settimane fa non ha ricevuto risposta… :sad_but_relieved_face:

L’avevo creato come parte della mia idea di avere un approccio più morbido e gentile alla moderazione qui. È importante avere un unico punto di contatto dove si possa raggiungere un moderatore e sapere che si riceverà una risposta. Spero che la decisione di rimuoverlo venga riconsiderata.

Inoltre, nel tentativo di essere più gentili e più miti, ho fatto del mio meglio per evitare di usare “perdita di tempo” come motivo per le decisioni dei moderatori. Non penso che i leader della comunità ben intenzionati che cercano di aiutare a mantenere ordinate le discussioni debbano sentirsi in colpa per questo.

Tornando all’OP… Avevo un compito abituale di revisionare e pulire gli argomenti più vecchi, ed era un buon compito manuale perché spesso c’erano delle estremità vaganti che riuscivo a sistemare lungo il percorso. A volte gli argomenti potevano semplicemente essere cancellati o uniti, ecc. Ma è un compito gargantuesco e sono riuscito ad arrivare solo a pochi anni fa.

Sarei favorevole a permettere a veterani fidati come @nathank di aggiungere i tag piuttosto che farli segnalare gli argomenti per la revisione da parte dello staff, specialmente in questo momento in cui non c’è un community manager o un team di moderazione dedicato.

Edit: ho ancora i link nella mia barra laterale! Questo serviva per vedere gli argomenti aperti, irrisolti e più vecchi di una settimana. Trovo ancora questi link utili per vedere quanto siamo bravi a risolvere gli argomenti. Forse più di noi potrebbero dare una mano con questo se lo staff non ha tempo per farlo.

5 Mi Piace

Siamo in un periodo di transizione per quanto riguarda le moderazioni, quindi alcune delle decisioni che prendiamo in questo preciso momento potrebbero non essere durature, ma ecco i miei 2 centesimi su questo particolare argomento:

Penso che dovremmo puntare a raggiungere una situazione in cui:

  • I flag vengano utilizzati per cose più importanti
  • Abbiamo un modo per gestire altre cose che sono più banali, o per il giardinaggio generale

Se vogliamo usare completed, allora dovremmo dare a un gruppo di persone il potere di gestire ciò senza usare i flag. Forse:

  • Dare ai TL3 e TL4 il potere di etichettare le cose come tali
  • Creare un argomento di “giardinaggio” dove le persone possano fare suggerimenti per qualsiasi tipo di giardinaggio dei contenuti
4 Mi Piace

Lo apprezzo molto. Dato che si può segnalare un post una sola volta e mai più, ero sempre riluttante a usare le segnalazioni per problemi banali, come un link di anteprima in un argomento di componente tema che non funziona più.

Ho suggerito la casella di posta perché pensavo che l’archiviazione delle richieste gestite potesse aiutare a tenere traccia di ciò che è già stato risolto. Questo potrebbe essere più difficile in un argomento con molte risposte.

Non sono sicuro di quanto sia utile aggiungere l’etichetta completed o fixed senza poter chiudere l’argomento. Se qualcun altro è ancora necessario per chiudere l’argomento, questo non aiuta molto.

6 Mi Piace

Stavamo valutando delle automazioni per chiudere gli argomenti con quei tag - non sono sicuro di quanto sarebbe difficile portare quegli esperimenti al traguardo.

3 Mi Piace

Offro le mie opinioni su questo.

Leggo ogni post ogni giorno. Davvero. Il mio ultimo post non visto risale a giugno 2024. Pertanto, ho visto innumerevoli segnalazioni di bug/ux risolte o completate. Generalmente, mi limiterei a segnalarle per la chiusura. Vedo meno la necessità dei tag fixed o completed, ma solo una chiusura dell’argomento. Secondo me, questo da solo significa che l’argomento è stato risolto.

D’altra parte, sono anche d’accordo con questo:

Quindi, se

fosse fatto, abbinato a

, penso che sarebbe piuttosto completo.

3 Mi Piace