Sinto um pouco de estranheza em escolher uma categoria com base em “quem tem maior probabilidade de corrigir o problema”. Você também diria que um fórum em branco devido a um display: none global não é um bug porque um designer irá corrigi-lo?
E, claro, você pode dizer “não importa, basta selecionar um, podemos mover”, mas isso só ajuda no ato de postar. Quando tento encontrar relatórios anteriores, eu pesquisaria por ambos os problemas em Contribute > UX. Seria possível rastrear a responsabilidade pela correção de forma independente 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
Isso parece uma boa solução para mim. Fica óbvio para qual categoria postar, e quem se importa com UX pode acompanhar essa tag. Outro benefício é que podemos eliminar uma categoria!
Não tenho certeza de como separar os tópicos atualmente em Contribute > UX, que provavelmente deveriam ir para Contribute > Bug ou Contribute > Feature. Pode ser um bom exercício revisar tudo e organizar.
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 alguns pontos válidos. Também estava olhando para o número total de tópicos em Contribute > UX e é muita coisa! 
Talvez o problema que estamos enfrentando seja que a categoria Contribute > UX está inadequadamente descrita, fazendo com que as pessoas postem lá coisas que deveriam estar em Contribute > Bug ou Contribute > Feature. Aqui está como a descrevemos em nossa documentação interna.
A categoria #ux::category é um pouco uma casa de meio-caminho entre #feature::category e #bug::category. Geralmente, problemas menores de exibição seriam colocados aqui em vez de #bug::category, e ela seria o lar para pequenas mudanças em funcionalidades 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::category - Sobre a categoria de funcionalidades
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 ser importante. Eu a tenho nas minhas 2 comunidades.
Às vezes, uma tag pode passar despercebida ou a categoria Contribute > UX pode não ser tão clara para alguns usuários, mas uma categoria Sugestões deixa bem claro para que ela 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.
3 curtidas
Indo fundo, não tenho certeza, @moin 
Acho que o núcleo do problema aqui é:
- Sam recoloca algo de Contribute > UX para Contribute > Bug
- Sam sabe como mexer em qualquer coisa relacionada à postagem de alguém pode fazer a pessoa se sentir mal, ou pensar que cometeu um erro
- Sam pede desculpas
- Então os usuários ficam confusos, querem se corrigir, e há um ciclo doloroso.
Talvez o problema raiz aqui seja?
Sam deveria se sentir livre para recolocar conforme achar melhor, para atender melhor às nossas necessidades de negócio, e não deveria pedir desculpas por isso toda vez que fizer isso?
2 curtidas
Tenho pensado sobre esse tópico nas últimas semanas, enquanto participo de discussões, abordo temas nas categorias Contribute > UX, Contribute > Bug e Contribute > Feature, e crio meus próprios tópicos.
Acho que esse é definitivamente o caso. Sam e os membros da equipe têm liberdade para categorizar e marcar tópicos como acharem conveniente, com o objetivo de responder ao tópico e chegar a uma resolução. Se os membros estiverem confusos sobre essas decisões, podem entrar em contato com @moderators.
Esse é um ótimo exemplo de um tópico que pertence a Contribute > UX. É pequeno e trata especificamente de melhorar a interface. Também é um excelente exemplo do tipo de colaboração entre membros da comunidade e a equipe que gostamos de ver, que leva a melhorias muito agradáveis na qualidade de vida. 
Continuando com o exemplo citado por Charlie, uma área em que nossa equipe precisa trabalhar é acompanhar tópicos como esse até o fim, para que possam ser encerrados. Até essa colaboração bastante excelente deixou algumas pontas soltas. Isso é natural no fluxo de discussões e colaboração aqui, e nossos engenheiros e designers estão ocupados. Como resultado, melhorias de UX às vezes passam despercebidas, não importa quão boa seja a sugestão ou quão pequena pareça a solicitação. Com o tempo, @moderators podem ajudar a identificar essas situações e guiá-las até o fim.
Atualizei a descrição da categoria Contribute > UX para tornar público o que tem sido nossa abordagem interna para essa categoria. Espero que isso ajude todos a entenderem melhor o que se enquadra em Contribute > UX em comparação com outras categorias como Contribute > Feature e Contribute > Bug.
Discussão sobre problemas menores de exibição e pequenas alterações na interface do usuário do Discourse, e sobre como as funcionalidades são apresentadas (incluindo linguagem e elementos de interface). Mais tópicos de „qualidade de vida“ do que qualquer coisa grande.
As tags completed ou fixed são aplicadas aos tópicos dessa categoria, dependendo da natureza do tópico.
Me avise se isso não estiver claro o suficiente ou se você puder pensar em aprimoramentos adicionais. Gostaria de aplicar o mesmo tratamento a Contribute > Bug e Contribute > Feature, mas vou esperar um pouco antes de fazê-lo.
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 de bug, mas estar relacionado à UX. Isso também resolveria a dúvida de ‘isso é um bug, mas é algo visual; deve estar em Contribute > Bug ou em Contribute > UX?’.
=> Faça dele um bug, mas adicione a tag ux.
Acho que a categoria Contribute > UX deve ser principalmente para sugestões de melhorias e coisas que estão pouco claras. Não para coisas quebradas.
Pelo menos essa distinção faz sentido para mim.
3 curtidas
Concordo em usar mais a tag ux, nas três categorias! As pessoas que se importam muito com UX podem então acompanhar essa tag.
Ainda assim, parece que ainda não estamos totalmente alinhados — na minha visão, Contribute > UX pode conter tanto bugs quanto solicitações de funcionalidades, mas devem ser melhorias pequenas de “qualidade de vida” e nada de grande porte. Se algo estiver realmente quebrado na interface, vai para Contribute > Bug. Se for um projeto maior (por exemplo, permitir a edição da descrição de uma tag), vai para Contribute > Feature.
Como você melhoraria a descrição da categoria Contribute > UX para refletir 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 esta descrição para o novo Contribute > UX? Parece um pouco rígida, mas mais concisa. Acho que funciona? (Eu criei um tópico para relatar que as tags não estão sendo 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 UI).
Atual:
Discussão sobre pequenos problemas de exibição e alterações mínimas em recursos existentes na interface do usuário do Discourse, e como os recursos são apresentados (incluindo idioma e elementos da UI). Mais tópicos do tipo ‘melhoria de qualidade de vida’ do que mudanças grandes.
As tags completed ou fixed são aplicadas aos tópicos nesta categoria dependendo da natureza do tópico.
Nova sugestão:
Tópicos de UX são usados quando o Discourse funciona tecnicamente como esperado, mas o design, a interação ou o fluxo criam atrito desnecessário, confusão ou ineficiência 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
(postagem excluída pelo autor)