Sembra un po’ strano scegliere una categoria in base a “chi è più probabile che la risolva”. Diresti anche che un forum vuoto a causa di un display: none globale non è un bug perché un designer lo risolverà?
E naturalmente puoi dire “non importa, seleziona semplicemente una, possiamo spostarla”, ma questo aiuta solo per la pubblicazione. Quando cerco segnalazioni precedenti, cercherei entrambi questi problemi in UX. Sarebbe possibile tracciare la responsabilità della risoluzione indipendentemente 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
Questa mi sembra una buona soluzione. È ovvio in quale categoria pubblicare e coloro a cui interessa l’esperienza utente possono seguire quel tag. Un altro vantaggio è che possiamo eliminare una categoria!
Non sono sicuro di come separare gli argomenti attualmente in UX che probabilmente vorrebbero andare in Bug o Feature. Potrebbe essere un buon esercizio per esaminare 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 delle buone osservazioni. Stavo guardando anche il numero totale di argomenti UX ed è un sacco! 
Forse il problema che stiamo riscontrando è che la categoria UX è descritta in modo inadeguato e quindi le persone ci pubblicano cose che dovrebbero essere in Bug o Feature. Ecco come la descriviamo nella nostra documentazione interna.
La categoria UX è una via di mezzo tra la categoria Feature e la categoria Bug. Generalmente, problemi di visualizzazione minori dovrebbero andare qui piuttosto che nella Bug, e sarebbe la sede per piccole modifiche a funzionalità esistenti. Argomenti più di “qualità della vita” che qualcosa di grande.
Generalmente, la gestione di questi argomenti seguirebbe lo schema della categoria Feature - Informazioni sulla categoria delle funzionalità
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. La ho nelle mie 2 community.
A volte un tag può essere trascurato o la categoria UX potrebbe non essere così chiara per alcuni utenti, ma una categoria Suggerimenti è piuttosto chiara su ciò per cui è destinata.
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ì.
2 Mi Piace
Scavando a fondo, non sono sicuro @moin 
Penso che il nucleo del problema qui sia:
- Sam ricategorizza qualcosa da UX → Bug
- Sam sa quanto toccare qualsiasi cosa nel post di qualcuno possa farlo stare male, o farlo sentire come se avesse commesso un errore
- Sam si scusa
- Poi gli utenti si confondono, vogliono auto-correggersi, e c’è un ciclo doloroso.
Forse il problema principale qui è?
Sam dovrebbe sentirsi libero di ricategorizzare come meglio crede, per soddisfare meglio le nostre esigenze aziendali, e non dovrebbe scusarsi ogni volta che lo fa?
2 Mi Piace
Sto pensando a questo argomento da diverse settimane mentre partecipo a discussioni, affronto argomenti nelle categorie UX Bug Feature e creo argomenti miei.
Penso che questo sia decisamente il caso. Sam e i membri del team sono liberi di categorizzare e taggare 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 un argomento che appartiene a UX. È piccolo ed è specificamente incentrato sul miglioramento dell’interfaccia. È anche un ottimo esempio del tipo di collaborazione tra i membri della community e il team che ci piace vedere, che porta a miglioramenti della qualità della vita molto gradevoli. 
Continuando con l’esempio citato da Charlie, un’area su cui il nostro team deve lavorare è perseguire argomenti come questo fino alla fine in modo che possano essere chiusi. Anche questa eccellente collaborazione è rimasta con alcuni nodi sciolti. Questo è naturale nel flusso e riflusso della discussione e della collaborazione qui, e i nostri ingegneri e designer sono impegnati. Di conseguenza, i miglioramenti UX a volte cadono tra le crepe, non importa quanto buona sia la proposta o quanto piccola possa sembrare la richiesta. Dopo un po’ @moderators può aiutare a identificarli e a portarli a termine.
Ho aggiornato la descrizione della categoria UX per rendere pubblica quella che è stata la nostra approccio interno a questa categoria. Spero che questo aiuti tutti a capire meglio cosa rientra in UX rispetto ad altre categorie Feature e Bug.
Discussione su piccoli problemi di visualizzazione e piccole modifiche nell’interfaccia utente di Discourse, e su come vengono presentate le funzionalità (inclusi lingua ed elementi dell’interfaccia utente). Più argomenti sulla “qualità della vita” che altro di importante.
I tag completed o fixed vengono applicati agli argomenti in questa categoria a seconda della natura dell’argomento.
Fatemi sapere se questo non è abbastanza chiaro o se potete pensare a ulteriori miglioramenti. Vorrei fare lo stesso per Bug e Feature, ma per ora mi fermo qui.
Penso che dovremmo usare di più anche il tag ‘ux’. Sarebbe utile per il triage secondo me, qualcosa può essere un argomento di supporto o un bug ma riguarda l’UX. Questo risolverebbe anche il dubbio “questo è un bug ma è qualcosa di visivo, dovrebbe essere in Bug o in UX”.
=> rendilo un bug ma mettilo su un tag ux
Penso che la categoria UX dovrebbe contenere principalmente suggerimenti per miglioramenti, cose poco chiare. Non cose che sono rotte.
Almeno questa distinzione ha senso per me.
3 Mi Piace
Concordo sull’uso maggiore del tag ux, in tutte e tre le categorie! Le persone a cui interessa molto l’ux potranno così seguire quel tag.
Sembra che non siamo ancora del tutto allineati, però: secondo me UX può contenere sia bug che richieste di funzionalità, ma devono essere piccoli miglioramenti “di qualità della vita” e niente di importante. Se qualcosa è veramente rotto nell’interfaccia utente, allora va in Bug. Se si tratta di un progetto importante (ad esempio, consentire la modifica della meta description di un tag), allora va in Feature.
Come miglioreresti la descrizione della categoria UX per farla corrispondere alla tua comprensione delle cose?
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 per una nuova descrizione di UX? Sembra un po’ rigida ma più concisa. Penso funzioni? (Ho pubblicato un mio UX argomento per segnalare che i tag non vengono visualizzati correttamente nei banner delle categorie)
Originale:
Discussione sull’interfaccia utente di Discourse e su come vengono presentate le funzionalità (inclusi lingua ed elementi dell’interfaccia utente).
Attuale:
Discussione su piccoli problemi di visualizzazione e piccole modifiche alle funzionalità esistenti nell’interfaccia utente di Discourse e su come vengono presentate le funzionalità (inclusi lingua ed elementi dell’interfaccia utente). Più argomenti di “qualità della vita” che qualcosa di importante.
I tag completed o fixed vengono applicati agli argomenti in questa categoria a seconda della natura dell’argomento.
Nuovo suggerito:
Gli argomenti UX vengono utilizzati quando Discourse funziona tecnicamente come previsto, ma il design, l’interazione o il flusso creano attrito, confusione o inefficienza non necessari per gli utenti. Anche per 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