Il semble un peu étrange de choisir une catégorie en fonction de “qui est le plus susceptible de la corriger”. 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 dire “peu importe, sélectionnez-en simplement un, nous pourrons le déplacer”, mais cela n’aide que pour la publication. Lorsque j’essaierai de trouver des rapports antérieurs, je rechercherai les deux problèmes dans 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 dans quelle catégorie publier, et ceux qui se soucient de l’expérience utilisateur peuvent suivre ce tag. Un autre avantage est que nous pouvons éliminer une catégorie !
Je ne suis pas sûr de la manière de séparer les sujets actuellement dans UX qui voudraient probablement aller dans Bug ou Feature. Ce pourrait être un bon exercice de passer en revue et de nettoyer tout cela.
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 des points pertinents. J’ai aussi regardé le nombre total de sujets UX et c’est énorme ! 
Peut-être que le problème que nous rencontrons est que la catégorie UX est mal décrite, ce qui amène les gens à y poster des choses qui devraient être dans Bug ou Feature. Voici comment nous la décrivons dans notre documentation interne.
La catégorie UX est un peu un entre-deux entre la catégorie Feature et la catégorie Bug. En général, les problèmes d’affichage mineurs devraient y figurer plutôt que dans la catégorie Bug, et elle serait le lieu pour les petits changements apportés aux fonctionnalités existantes. Il s’agit plus de sujets d’amélioration de la qualité de vie que de quelque chose d’important.
En général, le traitement de ces sujets suivrait le modèle de la catégorie Feature - À propos de la catégorie des fonctionnalités
Étiquetage
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. J’en ai une sur mes 2 communautés.
Parfois, une balise peut être négligée ou la catégorie UX peut ne pas être aussi claire pour certains utilisateurs, mais une catégorie Suggestions est assez claire quant à son utilité.
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.
2 « J'aime »
En creusant, je ne suis pas sûr @moin 
Je pense que le cœur du problème ici est :
- Sam recatégorise quelque chose de UX → Bug
- Sam sait à quel point toucher à la publication de quelqu’un peut le faire se sentir mal, ou avoir l’impression d’avoir fait une erreur
- Sam s’excuse
- Ensuite, les utilisateurs sont confus, veulent se corriger, et il y a un cycle douloureux.
Peut-être que le problème fondamental ici est ?
Sam devrait se sentir libre de recatégoriser comme il l’entend, pour mieux répondre à nos besoins commerciaux, et ne pas s’excuser pour chaque fois qu’il le fait ?
2 « J'aime »
Je réfléchis à ce sujet depuis plusieurs semaines, participant à des discussions, abordant des sujets dans les catégories UX, Bug, Feature, et créant mes propres sujets.
Je pense que c’est tout à fait le cas. Sam et les membres de l’équipe sont libres de catégoriser et d’étiqueter les sujets comme ils l’entendent, afin de répondre au sujet et de parvenir à une résolution. Si des membres sont confus quant à ces décisions, ils peuvent contacter @moderators.
C’est un excellent exemple de sujet qui appartient à UX. Il est petit et concerne spécifiquement l’amélioration de l’interface. C’est aussi un excellent exemple du type de collaboration entre les membres de la communauté et l’équipe que nous aimons voir, qui conduit à de très belles améliorations de la qualité de vie. 
Pour continuer sur l’exemple cité par Charlie, un domaine sur lequel notre équipe doit travailler est de poursuivre ces sujets jusqu’au bout afin qu’ils puissent être clos. Même cette excellente collaboration a laissé quelques fils lâches. C’est naturel dans le flux et le reflux de la discussion et de la collaboration ici, et nos ingénieurs et designers sont occupés. Par conséquent, les améliorations de l’expérience utilisateur passent parfois entre les mailles du filet, quelle que soit la qualité de la suggestion ou la petitesse de la demande. Après un certain temps, @moderators peut aider à identifier ces éléments et à les mener à terme.
J’ai mis à jour la description de la catégorie UX pour rendre publique notre approche interne de cette catégorie. J’espère que cela aidera tout le monde à mieux comprendre ce qui relève de UX par rapport aux autres catégories Feature et Bug.
Discussion sur les problèmes d’affichage mineurs et les petits changements dans l’interface utilisateur de Discourse, et sur la manière dont les fonctionnalités sont présentées (y compris la langue et les éléments de l’interface utilisateur). Plus de sujets de « qualité de vie » que quoi que ce soit de majeur.
Les tags completed ou fixed sont appliqués 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 penser à d’autres améliorations. J’aimerais faire de même pour Bug et Feature, mais je vais attendre un peu.
Je pense que nous devrions également utiliser davantage la balise « ux ». Ce serait utile pour le triage à mon avis, quelque chose peut être un sujet de support ou de bogue mais concerne l’expérience utilisateur. Cela résoudrait également le doute « c’est un bogue mais c’est quelque chose de visuel, doit-il être dans Bug ou dans UX ».
=> en faire un bogue mais mettre une balise ux
Je pense que la catégorie UX devrait principalement contenir des suggestions d’améliorations, des choses qui ne sont pas claires. Pas des choses qui sont cassées.
Au moins, cette distinction a du sens pour moi.
3 « J'aime »
D’accord pour utiliser davantage la balise ux, dans les trois catégories ! Les personnes qui se soucient beaucoup de l’UX pourront ainsi suivre cette balise.
Il semble que nous ne soyons pas encore tout à fait alignés - à mon avis, UX peut contenir à la fois des bugs et des demandes de fonctionnalités, mais il doit s’agir de petites améliorations “de confort” et rien de majeur. Si quelque chose est vraiment cassé dans l’interface utilisateur, cela va dans Bug. S’il s’agit d’un projet majeur (par exemple, permettre la modification de la description méta d’une balise), cela va dans Feature.
Comment amélioreriez-vous la description de la catégorie UX pour qu’elle corresponde à votre 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 »
Qu’en est-il de ceci pour une nouvelle description de UX ? Je la trouve un peu rigide mais plus concise. Je pense que ça fonctionne ? (J’ai posté un UX sujet pour signaler que les balises ne s’affichent pas correctement dans les bannières de catégorie)
Original :
Discussion sur l’interface utilisateur de Discourse et la manière dont les fonctionnalités sont présentées (y compris la langue et les éléments de l’interface utilisateur).
Actuel :
Discussion sur des problèmes d’affichage mineurs et de petits changements apportés aux fonctionnalités existantes de l’interface utilisateur de Discourse, et sur la manière dont les fonctionnalités sont présentées (y compris la langue et les éléments de l’interface utilisateur). Plus de sujets de « qualité de vie » que de sujets importants.
Les balises completed ou fixed sont appliquées aux sujets de cette catégorie en fonction de la nature du sujet.
Nouveau suggéré :
Les sujets UX sont utilisés lorsque Discourse fonctionne techniquement comme prévu, mais que la conception, l’interaction ou le flux créent une friction, une confusion ou une inefficacité inutile pour les utilisateurs. Également pour les petites améliorations de « qualité de vie ». Les balises 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 »