Il me semble un peu étrange de choisir une catégorie en fonction de « qui est le plus susceptible de corriger le problème ». Diriez-vous aussi qu’un forum vide à cause d’un display: none global n’est pas un bug parce qu’un designer s’en chargera ?
Et bien sûr, vous pouvez répondre « ça n’a pas d’importance, sélectionnez simplement l’une ou l’autre, nous pouvons le déplacer », mais cela ne sert qu’à poster. Lorsque je cherche des rapports antérieurs, je rechercherais ces deux problèmes dans Contribute > UX. Serait-il possible de suivre la responsabilité de la correction indépendamment des catégories ?
10 « J'aime »
Je suis avec vous, c’est très déroutant, il est très difficile pour les opérateurs de savoir quoi faire ici.
@tobiaseigen / @jordan.vidrine avez-vous des réflexions sur ce problème ?
@Moin avez-vous des suggestions sur la façon dont cela pourrait mieux fonctionner ?
Je suppose qu’une alternative consiste simplement à avoir des éléments dans feature/bug inconditionnellement et à utiliser des tags pour indiquer l’expérience utilisateur.
C’est vraiment difficile, c’est sûr.
4 « J'aime »
Cela me semble être une bonne solution. Il est évident vers quelle catégorie poster, et ceux qui s’intéressent à l’UX peuvent suivre ce tag. Un autre avantage est que nous pouvons éliminer une catégorie !
Je ne suis pas sûr de savoir comment séparer les sujets actuellement dans Contribute > UX qui voudraient probablement aller dans Contribute > Bug ou Contribute > Feature. Ce pourrait être un bon exercice de passer en revue et de tout nettoyer.
4 « J'aime »
Quelques réflexions de mon côté :
- Je pense que diviser plus de 3000 sujets en seulement 2 catégories représente beaucoup de travail, et je me demande qui aura le temps de s’en charger.
- De plus, je ne pense pas que tous les sujets liés à l’UX puissent être facilement divisés en “Fonctionnalité” et “Bug”. Pour moi, un rapport sur un texte qui ne peut pas être traduit n’est pas vraiment un rapport de bug[1]. De même, signaler un texte incompréhensible ou obsolète n’est ni une demande de fonctionnalité ni un rapport de bug[2]. De même, les descriptions d’expériences utilisateur qui ne contiennent ni erreur ni suggestion d’amélioration concrète ne correspondent ni à “Fonctionnalité” ni à “Bug”[3].
- Je ne sais pas comment vous avez géré cela jusqu’à présent, mais j’avais l’impression que les développeurs, lorsque nécessaire, travaillaient également sur des sujets UX, et vice versa. Je me demande s’il serait possible de maintenir les choses comme avant, le groupe surveillant la catégorie informant simplement l’autre groupe si nécessaire, sans déplacer le message. Cependant, je ne peux pas évaluer pleinement cela, car j’ignore les processus d’avant ou d’aujourd’hui.
5 « J'aime »
Merci Moin ! Tu soulèves de bons points. J’ai aussi regardé le nombre total de sujets Contribute > UX et il y en a vraiment beaucoup ! 
Peut-être que le problème que nous rencontrons vient du fait que la catégorie Contribute > UX est mal décrite, du coup les gens y postent des choses qui devraient aller dans Contribute > Bug ou Contribute > Feature. Voici comment nous la décrivons dans notre documentation interne.
La catégorie #ux::category est un peu une zone tampon entre #feature::category et #bug::category. En général, les petits problèmes d’affichage iront ici plutôt que dans #bug::category, et ce sera le lieu pour les petits changements apportés aux fonctionnalités existantes. Plus de sujets « qualité de vie » que de gros changements.
En général, la gestion de ces sujets suivra le modèle de la catégorie #feature::category - À propos de la catégorie fonctionnalité
Balisage
Hmmm, celui-ci je le classerais comme un bug… d’un point de vue purement pratique, mais il est trié beaucoup plus fréquemment par moi-même car l’UX attire plus de choses vagues.
Dans ce cas, ce problème de badge ressemble à un bug de traduction pour moi.
En fait, cela ressemble aussi à un bug pour moi, rien n’est ouvert à l’interprétation ici, notre texte est tout simplement faux et doit être mis à jour.
Cependant, cela relève tout à fait du thème de l’UX pour moi, c’est une discussion ouverte sur un point de friction sans recommandations concrètes pour le moment. Cela nous donne une histoire et un lieu pour extraire des sujets de bugs/fonctionnalités particuliers à l’avenir.
Peut-être que tout ce dont nous avons besoin ici est de mieux clarifier les règles, de laisser l’UX pour des discussions ouvertes et non structurées et des récits d’utilisateurs, et de garder les “défauts clairs” dans les bugs… et les “listes de souhaits claires” dans les fonctionnalités.
Je comprends que tout est très gris dans ce monde, il est difficile de faire disparaître la magie et de tout réparer.
Être plus clair sur nos attentes aidera certainement.
7 « J'aime »
Vous contournez maintenant les utilisateurs. Nous ne pouvons pas (et ne pouvons pas) savoir comment une entreprise attribue ou classe les choses. C’est une chose totalement interne. Tout ce que nous pouvons faire, c’est deviner si quelque chose est un bug, un problème d’UX ou quelque chose de totalement différent. Et les modérateurs et le personnel font leur magie après cela, comme prévu au cœur même de Discourse.
Alors, ce sujet est-il vraiment destiné au personnel et aux utilisateurs expérimentés, et nous, autres mortels, pouvons-nous arrêter de le suivre, ou quelqu’un pense-t-il vraiment que moi, qui ne peux pas faire la différence entre une image et une image selon que quelque chose se passe au niveau du fichier ou du conteneur, ai la capacité de me demander quelle position au sein de CDCK s’occupera d’un problème ?
À un niveau plus général, il y a au moins deux aspects (comme tout le monde le sait) :
- les catégories ne sont pas des boîtes logiques où il y a des limites strictes
- pour quels utilisateurs les catégories sont faites, publiques ou internes
Je ne sais pas… J’ai suivi la politique où j’utilise
- support si je ne sais pas si le problème vient de moi,
- UX si j’ai le sentiment que quelque chose est censé fonctionner ainsi
- bug si quelque chose a cessé de fonctionner ou casse complètement les choses
Mais je ne choisirai jamais une catégorie en fonction de qui, dans quelle position, essaiera de s’en occuper. C’est purement une question de gestion.
2 « J'aime »
J’aime l’idée de l’ux comme tag (et peut-être avoir le dev comme tag aussi ?), mais je suis d’accord qu’il pourrait y avoir des cas d’ux qui ne semblent pas vraiment appartenir à une autre catégorie non plus.
Et certains sujets peuvent être techniquement une fonctionnalité, mais sont si petits qu’ils sembleraient déplacés dans la catégorie des fonctionnalités pour voter, par exemple : Clickable components instead of just the Edit button
Mais peut-être que nous ne devrions pas nous en soucier ? Et tout problème qui demande de changer quelque chose appartient à la catégorie des fonctionnalités, peu importe à quel point c’est petit ?
Ou peut-être devrions-nous avoir une catégorie “Suggestions” – pour les choses qui ne sont pas cassées, qui ne sont pas une demande de fonctionnalité à part entière, et qui ne concernent pas la façon de faire les choses. Et ensuite, nous pouvons la taguer dev ou ux en interne.
Edit : j’ai réalisé que nous avons déjà un tag ux, il est juste sous-utilisé pour le moment.
4 « J'aime »
Une catégorie Suggestions semble importante. Je l’ai dans mes 2 communautés.
Parfois, une balise peut être négligée ou la catégorie Contribute > UX peut ne pas être aussi claire pour certains utilisateurs, mais une catégorie Suggestions est assez explicite sur son objectif.
1 « J'aime »
Je ne pense vraiment pas que nous ayons besoin de changer grand-chose aux catégories ici, elles fonctionnent bien depuis un moment et la mauvaise catégorisation arrive, mais pas à un rythme excessif d’après ce que je peux voir. Si les mentions, les tags et les assignations ne suffisent pas pour le triage interne, il semble que quelque chose ne va pas… car nous avons beaucoup d’options à cet égard.
3 « J'aime »
En y regardant de plus près, je ne suis pas sûr @moin 
Je pense que le cœur du problème ici est :
- Sam recatégorise quelque chose de Contribute > UX vers Contribute > Bug
- Sam sait que toucher à quoi que ce soit dans le post de quelqu’un peut le rendre triste, ou lui donner l’impression d’avoir fait une erreur
- Sam s’excuse
- Ensuite, les utilisateurs sont confus, veulent se corriger eux-mêmes, et il y a un cycle douloureux.
Peut-être que le problème racine ici est :
Sam devrait se sentir libre de recatégoriser comme il l’entend, afin de mieux répondre à nos besoins commerciaux, et ne devrait pas s’excuser chaque fois qu’il fait cela ?
2 « J'aime »
Je réfléchis à ce sujet depuis plusieurs semaines, alors que je participe à des discussions, que j’aborde des thèmes dans les catégories Contribute > UX, Contribute > Bug et Contribute > Feature, et que je crée mes propres sujets.
Je pense que c’est tout à fait le cas. Sam et les membres de l’équipe sont libres de classer et d’étiqueter les sujets comme ils l’entendent, dans l’intérêt de répondre au sujet et d’arriver à une résolution. Si des membres sont confus face à ces décisions, ils peuvent contacter @moderators.
C’est un excellent exemple de sujet qui appartient à Contribute > UX. Il est mineur et concerne spécifiquement l’amélioration de l’interface. C’est aussi un très bon exemple de la collaboration entre les membres de la communauté et l’équipe que nous aimons voir, et qui conduit à des améliorations très appréciables de la qualité de vie. 
En reprenant l’exemple cité par Charlie, un domaine sur lequel notre équipe doit travailler est de mener des sujets comme celui-ci jusqu’au bout afin qu’ils puissent être clos. Même cette collaboration, qui était tout à fait excellente, s’est terminée avec quelques fils non conclus. C’est naturel dans le flux et le reflux des discussions et de la collaboration ici, et nos ingénieurs et concepteurs sont occupés. Par conséquent, les améliorations de l’expérience utilisateur tombent parfois entre les mailles du filet, peu importe la qualité de la suggestion ou la petitesse de la demande. Après un certain temps, @moderators peut aider à identifier ces cas et à les mener à bien.
J’ai mis à jour la description de la catégorie Contribute > UX pour rendre public ce qui a été notre approche interne pour cette catégorie. J’espère que cela aidera tout le monde à mieux comprendre ce qui relève de Contribute > UX par rapport aux autres catégories Contribute > Feature et Contribute > Bug.
Discussion sur les problèmes d’affichage mineurs et les petits changements dans l’interface utilisateur de Discourse, ainsi que sur la façon dont les fonctionnalités sont présentées (y compris le langage et les éléments de l’interface). Plutôt des sujets de « qualité de vie » que des choses majeures.
Les étiquettes completed ou fixed sont appliquées aux sujets de cette catégorie en fonction de la nature du sujet.
Faites-moi savoir si ce n’est pas assez clair ou si vous pouvez imaginer d’autres améliorations. J’aimerais appliquer le même traitement à Contribute > Bug et Contribute > Feature, mais je vais attendre un peu pour l’instant.
Je pense que nous devrions également utiliser plus souvent le tag « ux ». Cela aiderait, à mon avis, à trier les sujets : quelque chose peut être un sujet de support ou de bug tout en relevant de l’UX. Cela résoudrait aussi le doute : « C’est un bug, mais c’est visuel, doit-il être dans Contribute > Bug ou dans Contribute > UX ? ».
=> En faire un bug, mais l’ajouter avec un tag ux.
Je pense que la catégorie Contribute > UX devrait principalement concerner des suggestions d’amélioration ou des points peu clairs, et non des éléments cassés.
Du moins, cette distinction me paraît logique.
3 « J'aime »
Je suis d’accord pour utiliser davantage la balise ux, dans les trois catégories ! Les personnes très soucieuses de l’expérience utilisateur pourront alors suivre cette balise.
Il semble cependant que nous ne soyons pas encore tout à fait alignés — à mon sens, Contribute > UX peut inclure à la fois des bogues et des demandes de fonctionnalités, mais ils doivent correspondre à de petites améliorations du « confort d’utilisation » et rien de plus important. Si quelque chose est vraiment cassé dans l’interface utilisateur, cela relève de Contribute > Bug. S’il s’agit d’un projet majeur (par exemple, permettre la modification de la méta-description d’une balise), cela relève de Contribute > Feature.
Comment améliorerais-tu la description de la catégorie Contribute > UX pour qu’elle corresponde à ta compréhension des choses ?
Bonne question. Je dirais quelque chose comme…
Un sujet d’UX est utilisé lorsque le produit fonctionne techniquement comme prévu, mais que la conception, l’interaction ou le flux créent des frictions, une confusion ou une inefficacité inutiles pour les utilisateurs.
Je suis également d’accord pour qu’il contienne :
Mais je pense que tout ce qui est réellement cassé, même si c’est mineur, devrait simplement être un bug avec une balise UX.
3 « J'aime »
Et celle-ci pour une nouvelle description Contribute > UX ? Elle semble un peu rigide, mais plus concise. Je pense que ça marche ? (J’ai créé un sujet pour signaler que les étiquettes ne s’affichent pas correctement dans les bannières de catégorie)
Version originale :
Discussion sur l’interface utilisateur de Discourse et la manière dont les fonctionnalités sont présentées (y compris les éléments linguistiques et d’interface).
Version actuelle :
Discussion sur les petits problèmes d’affichage et les modifications mineures des fonctionnalités existantes dans l’interface utilisateur de Discourse, ainsi que sur la manière dont les fonctionnalités sont présentées (y compris les éléments linguistiques et d’interface). Plus de sujets « d’amélioration du quotidien » que de grands changements.
Les étiquettes completed ou fixed sont appliquées aux sujets de cette catégorie en fonction de la nature du sujet.
Nouvelle proposition :
Les sujets UX concernent les cas où Discourse fonctionne techniquement comme prévu, mais où le design, l’interaction ou le flux créent une friction, une confusion ou une inefficacité inutiles pour les utilisateurs. Il s’agit également de petites améliorations du « quotidien ». Les étiquettes completed ou fixed sont appliquées en fonction de la nature du sujet.
1 « J'aime »
Merci, ça me convient parfaitement 
Génial ! J’ai effectué la modification.
(à part : c’est tellement bizarre que les changements apportés à la description prennent quelques minutes pour apparaître dans la bannière de la catégorie. même un actualisation forcée ne le fait pas.)
2 « J'aime »