Parece um pouco estranho escolher uma categoria com base em “quem é mais provável de consertar”. Você também diria que um fórum em branco por causa de um display: none global não é um bug porque um designer o consertará?
E claro, você pode dizer “não importa, basta selecionar um, podemos movê-lo”, mas isso só ajuda para postar. Quando eu tentar encontrar relatórios anteriores, procuraria por ambos os problemas em UX. Seria possível rastrear a responsabilidade pela correção independentemente das categorias?
10 curtidas
Estou com você, isso é extra confuso, é muito difícil para os operadores saberem o que fazer aqui.
@tobiaseigen / @jordan.vidrine alguma opinião sobre este problema?
@Moin alguma sugestão sobre como isso poderia funcionar melhor?
Eu acho que uma alternativa é simplesmente ter as coisas vivendo em feature/bug incondicionalmente e usar tags para denotar experiência do usuário.
É um problema difícil com certeza.
4 curtidas
Esta me parece uma boa solução. É óbvio em qual categoria postar, e aqueles que se importam com UX podem acompanhar essa tag. Outro bônus é que podemos eliminar uma categoria!
Não tenho certeza de como separar os tópicos atualmente em UX que provavelmente iriam para Bug ou Feature. Pode ser um bom exercício para revisar e limpar tudo isso.
4 curtidas
Algumas reflexões da minha parte:
- Acredito que dividir mais de 3000 tópicos em apenas 2 categorias é muito trabalho, e me pergunto quem terá tempo para assumir essa tarefa.
- Além disso, não acredito que todos os tópicos em UX possam ser facilmente divididos em Recurso (Feature) e Bug. Para mim, um relatório sobre um texto que não pode ser traduzido não é realmente um relatório de bug[1]. Da mesma forma, apontar um texto incompreensível ou desatualizado não é nem uma solicitação de recurso nem um relatório de bug[2]. Da mesma forma, descrições de experiências de usuário que não contêm um erro nem uma sugestão de melhoria concreta não se encaixam em Recurso ou Bug[3].
- Não sei como vocês lidaram com isso até agora, mas tive a impressão de que os desenvolvedores, quando necessário, também trabalhavam em tópicos de UX, e vice-versa. Pergunto-me se seria possível manter as coisas como estavam, com o grupo que monitora a categoria simplesmente informando o outro grupo, se necessário, sem mover a postagem. No entanto, não consigo avaliar isso totalmente, pois não conheço os processos anteriores ou atuais.
5 curtidas
Obrigado Moin! Você levanta bons pontos. Eu também estava olhando o número total de tópicos de UX e é muito! 
Talvez o problema que estamos tendo seja que a categoria UX é inadequadamente descrita e, portanto, as pessoas postam coisas lá que deveriam estar em Bug ou Feature. É assim que a descrevemos em nossa documentação interna.
A categoria UX é um meio-termo entre a categoria Feature e a categoria Bug. Geralmente, problemas de exibição menores iriam para cá em vez de Bug, e seria o lar para pequenas alterações em recursos existentes. Mais tópicos de ‘qualidade de vida’ do que qualquer coisa grande.
Geralmente, o tratamento desses tópicos seguiria o padrão da categoria Feature - Sobre a categoria de recursos
Marcação
hmmm, este eu classificaria como bug… de um ponto de vista puramente prático, mas é triado com muito mais frequência por mim, pois UX atrai coisas mais vagas.
Neste caso, esse problema de distintivo parece um bug de tradução para mim.
Na verdade, também parece um bug para mim, nada está aberto à interpretação aqui, nosso texto está claramente errado e precisa ser atualizado.
Isso, no entanto, está muito no tema de UX para mim, é uma discussão aberta sobre um ponto problemático sem recomendações concretas ainda. Está nos dando uma história e um lugar para extrair tópicos específicos de bugs/recursos no futuro.
Talvez tudo o que precisamos aqui seja esclarecer melhor as regras, deixar UX para discussão aberta e não estruturada e histórias de usuários e manter “falhas claras” em bugs… e “listas de desejos claras” em recursos.
Entendo que tudo é muito cinza neste mundo, é difícil puxar uma varinha mágica e consertar tudo.
Ser mais claro sobre nossas expectativas certamente ajudará.
7 curtidas
Vocês estão contornando os usuários agora. Não podemos (e não vamos) saber como uma empresa atribui ou classifica as coisas. É algo totalmente interno. Tudo o que podemos fazer é adivinhar se algo é um bug, um problema de UX ou algo totalmente diferente. E moderadores e funcionários fazem sua mágica depois disso, como planejado no núcleo do Discourse.
Então, este tópico é realmente para funcionários e usuários avançados, e nós, meros mortais, podemos parar de segui-lo, ou alguém realmente acha que eu, que não consigo diferenciar uma imagem de uma imagem dependendo se algo está acontecendo no nível do arquivo ou do contêiner, tem a capacidade de adivinhar qual posição dentro do CDCK cuidará de um problema?
Em um nível mais geral, existem dois aspectos, pelo menos (como todo mundo sabe):
- as categorias não são caixas lógicas onde existem limites rígidos
- para quais usuários as categorias são feitas, públicas ou internas
Eu não sei… Segui a política onde uso
- suporte se não sei se o problema sou eu,
- UX se tenho a sensação de que algo foi planejado para funcionar dessa maneira
- bug se algo parou de funcionar ou quebra totalmente os lugares
Mas eu nunca escolherei uma categoria dependendo de quem, em qual posição, tentará cuidar dela. É puramente uma questão gerencial.
2 curtidas
Gosto da ideia de ux como uma tag (e talvez ter dev como uma tag também?), mas concordo que pode haver casos de UX que parecem não pertencer realmente a uma categoria diferente.
E alguns tópicos podem ser tecnicamente um recurso, mas são tão pequenos que pareceriam fora de lugar na categoria de recursos para votar, por exemplo: Clickable components instead of just the Edit button
Mas talvez não devêssemos nos importar? E qualquer problema que peça para mudar algo pertence à categoria de recursos, não importa quão pequeno seja?
Ou talvez devêssemos ter uma categoria “Sugestões” – para coisas que não estão quebradas, não são uma solicitação de recurso completa e não são sobre como fazer as coisas. E então podemos marcá-lo internamente como dev ou ux.
Editar: percebi que já temos uma tag de ux, ela está apenas subutilizada no momento.
4 curtidas
Uma categoria Sugestões parece importante. Eu a tenho em minhas 2 comunidades. Às vezes, uma tag pode ser esquecida ou a categoria UX pode não ser tão clara para certos usuários, mas uma categoria Sugestões é bem clara sobre para que serve.
1 curtida
Eu realmente não acho que precisamos mudar muito as categorias aqui, elas têm funcionado bem por um tempo e a má categorização acontece, mas não em uma taxa excessiva, pelo que posso ver. Se menções, tags e atribuições não resolverem o problema para triagem interna, parece que algo está dando errado… porque temos muitas opções ali.
2 curtidas
Cavando fundo, não tenho certeza, @moin 
Eu acho que o núcleo do problema aqui é:
- Sam recategoriza algo de UX → Bug
- Sam sabe como tocar em qualquer coisa sobre a postagem de alguém pode fazê-los se sentir mal, ou sentir que cometeram um erro
- Sam pede desculpas
- Então os usuários ficam confusos, querem se autocorrigir, e há um ciclo doloroso.
Talvez o problema raiz aqui seja?
Sam deveria se sentir à vontade para recategorizar como achar melhor, para atender melhor às nossas necessidades de negócios, e não deveria se desculpar sobre as coisas toda vez que ele faz isso?
2 curtidas
Tenho pensado sobre este tópico nas últimas semanas, enquanto participo de discussões, abordo tópicos nas categorias UX Bug Feature e crio meus próprios tópicos.
Acho que este é definitivamente o caso. Sam e os membros da equipe são livres para categorizar e marcar tópicos como acharem melhor, no interesse de responder ao tópico e chegar a uma resolução. Se os membros estiverem confusos sobre essas decisões, eles podem entrar em contato com @moderators.
Este é um ótimo exemplo de um tópico que pertence a UX. É pequeno e se concentra especificamente em fazer uma melhoria na interface. É também um ótimo exemplo do tipo de colaboração entre membros da comunidade e a equipe que gostamos de ver, que leva a melhorias de qualidade de vida muito boas. 
Continuando com o exemplo que Charlie citou, uma área em que nossa equipe precisa trabalhar é dar seguimento a tópicos como este até o fim para que possam ser fechados. Mesmo essa excelente colaboração ficou com algumas pontas soltas. Isso é natural no fluxo e refluxo da discussão e colaboração aqui, e nossos engenheiros e designers estão ocupados. Como resultado, melhorias de UX às vezes caem entre as frestas, não importa quão boa seja a sugestão ou quão pequena seja a solicitação. Depois de um tempo, @moderators podem ajudar a identificar esses itens e encaminhá-los.
Atualizei a descrição da categoria UX para tornar público qual tem sido nossa abordagem interna para esta categoria. Espero que isso ajude a todos a entenderem melhor o que entra em UX versus outras categorias Feature e Bug.
Discussão sobre pequenos problemas de exibição e pequenas alterações na interface do usuário do Discourse, e como os recursos são apresentados (incluindo linguagem e elementos da interface). Mais tópicos de ‘qualidade de vida’ do que qualquer coisa grande.
As tags completed ou fixed são aplicadas aos tópicos nesta categoria, dependendo da natureza do tópico.
Me diga se isso não está claro o suficiente ou se você consegue pensar em mais refinamentos. Gostaria de dar o mesmo tratamento a Bug e Feature, mas vou segurar por enquanto.
Acho que também deveríamos usar mais a tag ‘ux’. Seria útil para triagem, na minha opinião, algo pode ser um tópico de suporte ou bug, mas que se refere à UX. Isso também resolveria a dúvida de “isto é um bug, mas é algo visual, deve estar em Bug ou em UX”.
=> torná-lo um bug, mas colocar uma tag ux
Acho que a categoria UX deveria ser principalmente sugestões de melhorias, coisas que não estão claras. Não coisas que estão quebradas.
Pelo menos essa distinção faz sentido para mim.
3 curtidas
Concordo em usar mais a tag ux, em todas as três categorias! Pessoas que se importam muito com UX podem então acompanhar essa tag.
Parece que ainda não estamos totalmente alinhados - para mim, UX pode conter tanto bugs quanto solicitações de recursos, mas eles têm que ser pequenas melhorias de “qualidade de vida” e nada grande. Se algo estiver realmente quebrado na UI, ele vai para Bug. Se for um projeto importante (por exemplo, permitir a edição da meta descrição de uma tag), ele vai para Feature.
Como você melhoraria a descrição da categoria UX para corresponder à sua compreensão das coisas?
Boa pergunta. Eu diria algo como…
Um tópico de UX é usado quando o produto funciona tecnicamente como pretendido, mas o design, a interação ou o fluxo criam atrito, confusão ou ineficiência desnecessários para os usuários.
Também concordo que ele contenha:
Mas acho que qualquer coisa que esteja realmente quebrada, mesmo que pequena, deve ser apenas um bug com uma tag de UX.
3 curtidas
Que tal isso para uma nova descrição de UX? Parece um pouco rígido, mas mais conciso. Acho que funciona? (Postei um UX tópico para relatar que as tags não são exibidas corretamente nos banners das categorias)
Original:
Discussão sobre a interface do usuário do Discourse e como os recursos são apresentados (incluindo idioma e elementos da interface).
Atual:
Discussão sobre pequenos problemas de exibição e pequenas alterações em recursos existentes na interface do usuário do Discourse e como os recursos são apresentados (incluindo idioma e elementos da interface). Mais tópicos de “qualidade de vida” do que qualquer coisa grande.
As tags completed ou fixed são aplicadas aos tópicos nesta categoria, dependendo da natureza do tópico.
Novo sugerido:
Tópicos de UX são usados quando o Discourse tecnicamente funciona como pretendido, mas o design, a interação ou o fluxo criam atrito, confusão ou ineficiência desnecessários para os usuários. Também para pequenas melhorias de “qualidade de vida”. As tags completed ou fixed são aplicadas dependendo da natureza do tópico.
1 curtida
Obrigado, parece bom para mim 
Legal! Fiz a alteração.
(Observação: é muito estranho que as alterações na descrição demorem alguns minutos para aparecer no banner da categoria. Nem mesmo um refresh forçado resolve.)
2 curtidas