Mi sembra un po’ strano scegliere una categoria in base a “chi è più probabile che risolva il problema”. Diresti anche che un forum vuoto a causa di un display: none globale non è un bug perché a risolverlo sarà un designer?
E ovviamente potresti dire “non importa, seleziona semplicemente una categoria, possiamo spostarla”, ma questo è utile solo per la pubblicazione. Quando provo a cercare segnalazioni precedenti, cercherei entrambi questi problemi in Contribute > UX. Sarebbe possibile tracciare la responsabilità della risoluzione in modo indipendente dalle categorie?
10 Mi Piace
Sono con te, questo è extra confusionario, è molto difficile per gli operatori sapere cosa fare qui.
@tobiaseigen / @jordan.vidrine avete qualche pensiero su questo problema?
@Moin avete suggerimenti su come questo potrebbe funzionare meglio?
Suppongo che un’alternativa sia semplicemente avere le cose che vivono in feature/bug incondizionatamente e usare i tag per indicare l’esperienza utente.
È sicuramente un problema difficile.
4 Mi Piace
Mi sembra una buona soluzione. È chiaro a quale categoria pubblicare e chi è interessato all’UX può seguire quel tag. Un altro vantaggio è che possiamo eliminare una categoria!
Non sono sicuro di come smontare gli argomenti attualmente in Contribute > UX, che probabilmente vorrebbero andare in Contribute > Bug o Contribute > Feature. Potrebbe essere un buon esercizio passare attraverso e ripulire tutto.
4 Mi Piace
Alcune mie riflessioni:
- Credo che dividere oltre 3000 argomenti in sole 2 categorie sia un lavoro enorme, e mi chiedo chi avrà il tempo di assumersi questo compito.
- Inoltre, non credo che tutti gli argomenti in UX possano essere facilmente divisi in Funzionalità e Bug. Per me, una segnalazione su un testo che non può essere tradotto non è proprio una segnalazione di bug[1]. Allo stesso modo, segnalare un testo incomprensibile o obsoleto non è né una richiesta di funzionalità né una segnalazione di bug[2]. Allo stesso modo, le descrizioni di esperienze utente che non contengono né un errore né un suggerimento di miglioramento concreto non rientrano in Funzionalità o Bug[3].
- Non so come abbiate gestito la cosa finora, ma ho avuto l’impressione che gli sviluppatori, quando necessario, lavorassero anche su argomenti UX, e viceversa. Mi chiedo se non sia possibile mantenere le cose come erano, con il gruppo che monitora la categoria che informa semplicemente l’altro gruppo se necessario, senza spostare il post. Tuttavia, non posso valutarlo appieno, poiché non conosco i processi precedenti o attuali.
5 Mi Piace
Grazie Moin! Fai alcuni buoni punti. Stavo guardando anche il numero totale di argomenti in Contribute > UX ed è davvero tanto! 
Forse il problema che stiamo affrontando è che la categoria Contribute > UX è descritta in modo inadeguato, quindi le persone pubblicano lì cose che dovrebbero essere in Contribute > Bug o Contribute > Feature. Ecco come la descriviamo nella nostra documentazione interna.
La categoria #ux::category è un po’ una via di mezzo tra #feature::category e #bug::category. Generalmente, i problemi di visualizzazione minori andrebbero qui invece che in #bug::category, e sarebbe la sede per piccole modifiche alle funzionalità esistenti. Più argomenti di “qualità della vita” che di grandi novità.
In generale, la gestione di questi argomenti seguirebbe lo schema della categoria #feature::category - Riguardo alla categoria feature
Tagging
hmmm questo lo classificherei come bug… da un punto di vista puramente pratico, ma viene gestito molto più frequentemente da me perché l’UX attira cose più vaghe.
In questo caso, quel problema di badge mi sembra un bug di traduzione.
In realtà, anche questo mi sembra un bug, non c’è nulla di aperto all’interpretazione, il nostro testo è palesemente sbagliato e necessita di essere aggiornato.
Questo, però, è molto nel tema dell’UX per me, è una discussione aperta su un punto dolente senza ancora raccomandazioni concrete. Ci sta dando una storia e un luogo da cui estrarre in futuro argomenti specifici di bug/funzionalità.
Forse tutto ciò di cui abbiamo bisogno qui è chiarire meglio le regole, lasciare l’UX per discussioni aperte e non strutturate e storie utente e mantenere i “difetti chiari” nei bug… e le “liste dei desideri chiare” nelle funzionalità.
Capisco che tutto sia molto grigio in questo mondo, è difficile agitare una bacchetta magica e sistemare tutto.
Essere più chiari sulle nostre aspettative, però, aiuterà sicuramente.
7 Mi Piace
Voi state aggirando gli utenti ora. Non possiamo (e non lo faremo) sapere come un’azienda assegna o classifica le cose. È una cosa totalmente interna. Tutto ciò che possiamo fare è indovinare se qualcosa è un bug, un problema di UX o qualcosa di totalmente diverso. E i moderatori e lo staff fanno la loro magia dopo, come è pianificato nel nucleo di Discourse.
Quindi questo argomento è effettivamente per lo staff e gli utenti esperti, e noi altri mortali possiamo smettere di seguirlo, o qualcuno pensa davvero che io, che non so distinguere tra un’immagine e un’immagine a seconda che qualcosa stia accadendo a livello di file o contenitore, abbia la capacità di chiedermi quale posizione all’interno di CDCK si occuperà di un problema?
A un livello più generale ci sono due aspetti, almeno (come tutti sanno):
- le categorie non sono scatole logiche dove ci sono limiti rigidi
- per quali utenti sono fatte le categorie, pubbliche o interne
Non lo so… Ho seguito la politica in cui uso
- supporto se non so se il problema sono io,
- UX se ho la sensazione che qualcosa sia pianificato per funzionare in quel modo
- bug se qualcosa ha smesso di funzionare o rompe completamente i posti
Ma non sceglierò mai una categoria a seconda di chi, in quale posizione, cercherà di occuparsene. È puramente una questione manageriale.
2 Mi Piace
Mi piace l’idea dell’ux come tag (e forse anche del dev come tag?), ma concordo sul fatto che potrebbero esserci casi di UX che non sembrano appartenere a una categoria diversa.
E alcuni argomenti potrebbero essere tecnicamente una funzionalità, ma così piccoli da sembrare fuori posto nella categoria delle funzionalità per votare, ad esempio: Clickable components instead of just the Edit button
Ma forse non dovremmo preoccuparcene? E qualsiasi problema che chieda di cambiare qualcosa appartiene alla categoria delle funzionalità, non importa quanto piccolo?
O forse dovremmo avere una categoria “Suggerimenti” – per cose che non sono rotte, non sono una richiesta di funzionalità completa e non riguardano come fare le cose. E poi possiamo taggarla internamente come dev o ux.
Modifica: mi sono reso conto che abbiamo già un tag ux, è solo sottoutilizzato al momento.
4 Mi Piace
Una categoria Suggerimenti sembra importante. L’ho inserita nelle mie 2 community.
A volte un tag può essere trascurato o la categoria Contribute > UX potrebbe non essere chiara per alcuni utenti, ma una categoria Suggerimenti è piuttosto esplicita sullo scopo per cui è stata creata.
1 Mi Piace
Non credo davvero che dobbiamo cambiare molto riguardo alle categorie qui, hanno funzionato bene per un po’ e la categorizzazione errata accade, ma non a un ritmo eccessivo per quanto posso vedere. Se le menzioni, i tag e le assegnazioni non funzionano per il triage interno, sembra che qualcosa stia andando storto… perché abbiamo molte opzioni lì.
3 Mi Piace
Scavando a fondo, non sono sicuro @moin 
Penso che il nocciolo del problema qui sia:
- Sam ricategorizza qualcosa da Contribute > UX → Contribute > Bug
- Sam sa bene quanto toccare qualsiasi cosa nei post di qualcuno possa fargli sentire male, o far sì che pensi di aver sbagliato
- Sam si scusa
- Poi gli utenti si confondono, vogliono correggersi da soli e si crea un ciclo doloroso.
Forse il problema radice qui è?
Sam dovrebbe sentirsi libero di ricategorizzare come ritiene opportuno, per meglio soddisfare le nostre esigenze aziendali, e non dovrebbe scusarsi ogni volta che lo fa?
2 Mi Piace
Ho riflettuto su questo argomento nelle ultime settimane, partecipando alle discussioni, affrontando temi nelle categorie Contribute > UX, Contribute > Bug e Contribute > Feature, e creando nuovi argomenti.
Penso che sia assolutamente così. Sam e i membri del team sono liberi di categorizzare e etichettare gli argomenti come ritengono opportuno, nell’interesse di rispondere all’argomento e giungere a una risoluzione. Se i membri sono confusi riguardo a queste decisioni, possono contattare @moderators.
Questo è un ottimo esempio di argomento che appartiene a Contribute > UX. È di piccole dimensioni e riguarda specificamente il miglioramento dell’interfaccia. È anche un ottimo esempio del tipo di collaborazione tra membri della comunità e il team che ci piace vedere, che porta a miglioramenti molto apprezzati della qualità della vita. 
Proseguendo con l’esempio citato da Charlie, un’area su cui il nostro team deve lavorare è portare a termine argomenti come questo, in modo che possano essere chiusi. Anche questa eccellente collaborazione è rimasta con alcuni fili in sospeso. Questo è naturale nel flusso delle discussioni e della collaborazione qui, e i nostri ingegneri e designer sono impegnati. Di conseguenza, i miglioramenti UX a volte finiscono tra le maglie della rete, indipendentemente da quanto buona sia la suggerimento o da quanto piccolo sembri il requisito. Dopo un po’, @moderators può aiutare a identificarli e accompagnarli alla conclusione.
Ho aggiornato la descrizione della categoria Contribute > UX per rendere pubblico il nostro approccio interno a questa categoria. Spero che questo aiuti tutti a comprendere meglio cosa rientri in Contribute > UX rispetto ad altre categorie come Contribute > Feature e Contribute > Bug.
Discussione su problemi minori di visualizzazione e piccoli cambiamenti nell’interfaccia utente di Discourse, e su come le funzionalità vengono presentate (inclusi linguaggio ed elementi dell’interfaccia). Più temi legati alla «qualità della vita» che grandi novità.
Vengono applicati i tag completed o fixed agli argomenti di questa categoria, a seconda della natura dell’argomento.
Fatemi sapere se non è abbastanza chiaro o se potete pensare a ulteriori affinamenti. Vorrei applicare lo stesso trattamento a Contribute > Bug e Contribute > Feature, ma per ora mi asterrò.
Penso che dovremmo usare di più il tag ‘ux’. Sarebbe utile per la triage, a mio avviso: un argomento può essere di supporto o un bug, ma riguardare l’UX. Questo risolverebbe anche il dubbio: «Questo è un bug, ma è qualcosa di visivo; dovrebbe essere in Contribute > Bug o in Contribute > UX?»
=> rendilo un bug, ma aggiungi il tag ux
Penso che la categoria Contribute > UX dovrebbe essere dedicata principalmente a suggerimenti per miglioramenti o a cose poco chiare, non a cose rotte.
Almeno questa distinzione ha senso per me.
3 Mi Piace
Concordo sull’uso più frequente del tag ux, in tutte e tre le categorie! Le persone molto attente all’UX possono quindi seguire quel tag.
Sembra però che non siamo ancora completamente allineati: a mio avviso, Contribute > UX può contenere sia bug che richieste di funzionalità, ma devono trattarsi di piccoli “miglioramenti della qualità della vita” e nulla di grande. Se qualcosa è davvero rotto nell’interfaccia utente, va in Contribute > Bug. Se si tratta di un progetto importante (ad esempio, consentire la modifica della meta description di un tag), allora va in Contribute > Feature.
Come migliorerebbe la descrizione della categoria Contribute > UX per riflettere la Sua comprensione della situazione?
Ottima domanda. Direi qualcosa del tipo…
Un argomento UX viene utilizzato quando il prodotto funziona tecnicamente come previsto, ma il design, l’interazione o il flusso creano attrito, confusione o inefficienza non necessari per gli utenti.
Vanno bene anche se contiene:
Ma penso che qualsiasi cosa sia effettivamente rotta, anche se piccola, dovrebbe essere semplicemente un bug con un tag ux.
3 Mi Piace
Che ne dici di questa nuova descrizione per Contribute > UX? Sembra un po’ rigida ma più concisa. Secondo me funziona? (Ho creato un argomento per segnalare che i tag non vengono visualizzati correttamente negli banner delle categorie)
Originale:
Discussione sull’interfaccia utente di Discourse e su come vengono presentate le funzionalità (inclusi lingua ed elementi UI).
Attuale:
Discussione su piccoli problemi di visualizzazione e modifiche minime alle funzionalità esistenti nell’interfaccia utente di Discourse, e su come vengono presentate le funzionalità (inclusi lingua ed elementi UI). Più argomenti di “miglioramento della qualità della vita” che di grandi novità.
I tag completed o fixed vengono applicati agli argomenti in questa categoria a seconda della natura dell’argomento.
Nuova proposta:
Gli argomenti UX si riferiscono a quando Discourse funziona tecnicamente come previsto, ma il design, l’interazione o il flusso creano attrito, confusione o inefficienza non necessari per gli utenti. Si applicano anche a piccoli miglioramenti di “qualità della vita”. I tag completed o fixed vengono applicati a seconda della natura dell’argomento.
1 Mi Piace
Grazie, mi sembra un’ottima idea 
Fantastico! Ho apportato la modifica.
(a parte: è così strano che le modifiche alla descrizione impieghino un paio di minuti per apparire nel banner della categoria. nemmeno un aggiornamento forzato lo fa.)
2 Mi Piace
(post eliminato dall’autore)