Come dimostrato dall’esempio sottostante, sarebbe stato utile lì:
3 Mi Piace
Non sono sicuro che sia una buona idea. In definitiva, noi utenti non possiamo correggere i bug. Ciò può essere fatto solo modificando il codice di Discourse, e ciò richiede il coinvolgimento di un membro del team. Se ciò non è necessario, allora Bug probabilmente non è la categoria giusta.
Sono preoccupato che gli utenti contrassegnino le soluzioni alternative come la soluzione. Ma poi il bug non sarebbe ancora corretto. Sarebbe quindi più confusionario che utile. Nel tuo esempio, il problema non è nemmeno risolto, perché esiste già una segnalazione di bug. Penso che unire gli argomenti sia la cosa migliore in questo caso. In questo modo, tutti gli utenti saranno avvisati quando ci sarà una correzione, indipendentemente dall’argomento che hanno originariamente seguito. A volte ha senso chiudere un argomento con un riferimento all’altro, ma poi i “mi piace” che hanno supportato l’argomento chiuso vengono persi, il che è triste quando gli utenti interessati sono determinati dai “mi piace”.
3 Mi Piace
Nella categoria Bug, lavoriamo solo con il tag fixed. Un post che dice che qualcosa è un duplicato non risolve nulla, nonostante sia utile, quindi non penso che sarebbe stato un buon uso nemmeno lì.
Ora, perché usiamo fixed in alcune categorie e il plugin solved in altre, penso che sia probabilmente dovuto a ciò che Moin ha già detto. I tag sono un po’ più rigidi nell’uso, quindi solo il team può decidere quando qualcosa è risolto.
5 Mi Piace
Grazie per il suggerimento! È sempre bene verificare il modo in cui sono impostate le categorie, quindi apprezzo che tu ci abbia pensato e abbia avviato questo argomento.
Come hanno sottolineato Moin e Charlie, il nostro team si affida a fixed e alla chiusura degli argomenti (azioni disponibili solo a noi) per comunicare con la community che un bug è stato, beh, risolto! Questo sembra funzionare abbastanza bene ed è un modo per noi di mantenere un backlog abbastanza evidente di bug che necessitano di essere risolti.
È vero che nella categoria dei bug, una persona che è in grado di fornire una soluzione non ottiene credito per essa nello stesso modo in cui lo farebbe nelle categorie con il plugin solved abilitato, il che è un peccato. Nella categoria dei bug, la persona che segnala il bug ottiene un badge per esso se viene apprezzato da un membro del team Discourse. Ma altri che aiutano lungo il percorso fornendo passaggi per la riproduzione, segnalando duplicati, suggerendo soluzioni e così via non otterranno credito. Qualcosa su cui riflettere.
In questo caso sarebbe stato bello se tu avessi potuto accreditare Moin per aver segnalato che il report è un duplicato, ma mantenere l’argomento crea anche un po’ di rumore in più che renderà un po’ più difficile per il team analizzare tutti i report di bug aperti. Quindi spero che non ti dispiaccia, ma ho impostato un timer per eliminarlo.
1 Mi Piace
@tobiaseigen, non è a questo che serve la funzione di blocco? Eliminarlo farà sì che alcuni URI esterni che vi puntano diano errore 404, il che non è l’ideale.
Non teniamo tutto! 
Non preoccuparti troppo del 404.
Tuttavia, non lo applichiamo in modo coerente perché è un lavoro extra. Penso che ci sia del merito nell’etichettare automaticamente con “fixed” quando chiudiamo, quindi per i casi anomali in cui non risolviamo possiamo modificare con un tag speciale.
Richiederà comunque una nuova automazione.
4 Mi Piace
Ho riscontrato più volte il problema di cercare informazioni, vedere un link che sembrava interessante, ma che portava a un 404 quando cliccato, il che era piuttosto sgradevole.
In questo caso, segnalerei il post, che verrebbe modificato/rimosso da un moderatore.
Per evitare ciò, prima di eliminare un argomento, dare un’occhiata alla sezione dei link del primo post:
E quindi agire preventivamente rimuovendo quei riferimenti ai link sarebbe la cosa migliore, ma richiederebbe anche più lavoro.
2 Mi Piace
Ho proposto il contrario a @tobiaseigen: aggiungendo il tag fixed, chiudi automaticamente; lo stesso vale per solved.
Forse la risposta è un sì, e? Automazione che aggiunge il tag fixed immediatamente se viene chiuso e chiude l’argomento (o lo pianifica per la chiusura) se ha il tag fixed? Potremmo fare lo stesso in UX con i tag fixed e completed.
Ci sono mai casi in cui chiudiamo argomenti Bug senza voler aggiungere il tag fixed? Vedo che ci sono molti argomenti di bug che sono chiusi ma non hanno il tag. Dedicherò un po’ di tempo oggi all’esplorazione.
Una cosa che mi è piaciuta del comportamento del plugin solved è che quando viene selezionata una soluzione, l’argomento viene programmato per essere chiuso automaticamente 30 giorni dopo l’ultima risposta. Questo è comodo perché è netto e permette alle persone di intervenire se ne sentono ancora il bisogno. Probabilmente ci fa risparmiare lavoro perché le persone non segnaleranno l’argomento per chiedere la riapertura.
1 Mi Piace
Il motivo per cui non mi piace la chiusura => aggiungi automaticamente il tag è a causa dei casi d’uso in cui non è stato risolto o non verrà mai risolto. Ritengo che eseguire 1 azione (“aggiungi tag”) che imposta automaticamente il timer dell’argomento per chiudersi dopo 30 giorni sia il modo ottimale.
2 Mi Piace
Ho passato del tempo su questo e vedo che @chapoi ha la giusta idea. Penso che quello che vogliamo fare qui sia abituarci a taggare gli elementi fixed che sono stati corretti, e poi creare un’automazione che imposti un timer per chiudere automaticamente, come il plugin solved. Possiamo ancora chiudere l’argomento immediatamente se è giustificato, ma in alcuni casi penso che sia bene lasciarlo aperto un po’ più a lungo per dare alle persone la possibilità di testare e riferire se stanno ancora riscontrando un problema.
Ci sono argomenti come Rendering 'TypeError' with theme components after update che penso non dovrebbero ricevere il tag fixed, perché il bug segnalato nell’OP non è stato corretto. In questo esempio non c’è stato un repro da parte dell’ingegnere che ha cercato di correggerlo.
C’è anche After deleting a topic, the delete button shows up instead of the restore button che è stato chiuso come duplicato. Immagino che quando Deleting a topic cannot be undone sarà corretto, entrambi potranno essere taggati fixed e chiusi? Ma come ci assicuriamo che ciò accada?
Ci sono molti argomenti in Bug che sono chiusi ma non hanno il tag fixed. Vorremo esaminarli retroattivamente.
3 Mi Piace
Il mio problema è l’usabilità qui. Voglio che gli ingegneri abbiano una soluzione a 1 clic qui.
- Fare clic su “Risolto” in Azioni argomento o Azioni argomento amministratore.
- Succede la magia:
- Timer argomento creato per chiudere in 1 giorno lavorativo
- Argomento taggato con “risolto”
Non sono un fan dell’UX per la semplice “etichettatura dell’argomento” perché è molto macchinosa.
- Navigare in cima all’argomento
- Fare clic sul titolo
- Fare clic sulla casella dei tag
- cercare “risolto”
- aggiungere “risolto”
- fare clic sulla casella di controllo
Questa è molta macchinosità.
Sono felice che possiamo aggiungere questo flusso, ma avremo bisogno di un componente tema per questo o di qualche tipo di automazione che introduca questa interfaccia utente (che può anche essere utile).
4 Mi Piace
Sono con te! Stavo anche pensando all’usabilità quando ho proposto “sì, e” sopra. Attualmente abbiamo una memoria muscolare attorno alla semplice chiusura degli argomenti Bug quando vengono corretti. Questo corrisponde anche a come gestiamo internamente i todo.
Mi piace l’idea di un pulsante “corretto” con un clic.
1 Mi Piace
E la community ha risposto 
6 Mi Piace
Fantastico! Ho provato il componente tema di Nate sul mio sito personale e fa quello che promette. Ottimo lavoro e implementato anche rapidamente! 
Per poterlo usare qui, dovremmo essere in grado di limitarlo a una categoria. Se decidiamo che questo approccio funziona bene, vorremmo anche essere in grado di creare più di un pulsante.
A titolo informativo, Sam sta anche lavorando a un’implementazione sperimentale diversa e molto più flessibile, utilizzando l’automazione.
2 Mi Piace
Penso che questa modifica ci aiuterebbe parecchio qui su meta. Ho fatto un seguito internamente per vedere se può essere implementata utilizzando l’implementazione sperimentale di Sam tramite automazione o creando una fork del componente tematico di Nate e utilizzandola qui.
Il componente di Nate fa effettivamente la stessa cosa ed è molto bello, ma dovremmo creare una fork perché non installiamo componenti o plugin di terze parti su meta. 
1 Mi Piace
Se lo fai, la cosa onorevole da fare sarebbe offrire a Nate un riconoscimento finanziario di ringraziamento, come fai per i rischi identificati per la cybersecurity tramite HackerOne.
2 Mi Piace
Manteniamo questo argomento focalizzato sul fatto che la community trarrebbe beneficio dall’uso di qualcosa come il componente tematico di Nate. In caso affermativo, risolveremo i dettagli con Nate.
Sarò felice di aprire un altro argomento su come i contributori open source vengono ricompensati per il loro lavoro in generale, se lo desideri.
2 Mi Piace