Salut au merveilleux personnel de Discourse qui gère et maintient avec amour cet excellent forum en ligne avec leur propre produit.
Je note que nous avons le plugin Solved actif pour Support. C’est formidable de voir ce formidable dogfooding en pratique ! Idem pour l’utilisation des tags fixed et completed.
Malheureusement, il y a une tonne de sujets dans Support, Bug, Feature et UX qui n’ont pas été marqués avec ceux-ci. C’est assez déroutant pour les utilisateurs de ce forum et entrave les recherches efficaces de solutions existantes. En gros, si ceux-ci ne vont pas être utilisés de manière cohérente, ils ne devraient probablement pas être utilisés du tout.
Puis-je demander que cela soit priorisé à l’avenir et que quelqu’un (?stagiaire, ??IA) soit chargé de marquer correctement les anciens ?
Merci, Nathan ! J’apprécie que vous ayez soulevé ce point. :tournesol: Nous voulons absolument faire plus dans ce domaine.
Il semble que l’activation des solutions pour la catégorie Support ait assez bien fonctionné pour cette catégorie. Les balises fixed et completed sont également très utiles, et peuvent être utilisées dans toutes les catégories.
Pour résumer, il semble qu’actuellement, nous ayons cinq façons d’indiquer quand un sujet a suivi son cours et doit être conclu. Est-ce que cela résume bien la situation ?
Cela me semble être une grande variété. Je ne sais pas pourquoi les tags sont différents. Peut-être est-il utile/informatif pour les gens de pouvoir parcourir ces listes de tags individuellement. Cependant, ces tags et leur objectif ne sont pas très faciles à découvrir.
solved est facilement découvrable et fonctionne assez bien pour le support. Je pense qu’il est logique de le limiter à cette catégorie. Il est utile de pouvoir filtrer les sujets résolus/non résolus dans cette catégorie - j’oublie souvent cette option déroulante et j’aimerais qu’elle soit plus visible dans l’interface utilisateur.
fixed est utilisé uniquement dans BugUX et signifie qu’un bug ou un bug d’interface utilisateur a été corrigé.
Les sujets Support sont fermés un mois après la dernière réponse, une fois résolus.
Les sujets Marketplace sont fermés un mois après la dernière réponse, qu’ils soient delivered ou non.
Les modérateurs ferment les sujets
lorsqu’ils sont résolus
pour empêcher les réponses (par exemple, documentation ou release-notes)
comme tactique de modération pour mettre fin aux discussions dans des sujets qui sont devenus improductifs ou ont suivi leur cours.
Quelques étapes potentielles :
ajouter des descriptions aux tags fixedcompleteddelivered qui expliquent comment nous les utilisons
créer une requête Data Explorer avec des résultats comme le tableau ci-dessus, mais listant le nombre réel et à jour de sujets résolus/non résolus, corrigés/non corrigés, terminés/non terminés, livrés/non livrés
créer une requête Data Explorer qui liste les sujets qui ont été fermés, corrigés, terminés, livrés dans un délai donné
créer un sujet ici dans Site feedback pour partager les résultats des requêtes ci-dessus chaque semaine à l’aide d’une automatisation
créer un sujet ici avec un petit guide pratique pour conclure les sujets et réunir une équipe pour commencer à parcourir la liste, par ordre chronologique inverse.
J’ai ajouté des descriptions ci-dessous, qui apparaîtront lorsque vous passerez la souris sur la balise ou que vous irez sur la page de la balise. Faites-moi savoir si vous avez des suggestions. J’hésite entre rester bref et concis, et fournir un contexte plus détaillé. Les catégories elles-mêmes ont également des descriptions plus détaillées.
fixed
Nous donnons la priorité à la correction des bogues dans nos logiciels signalés dans les catégories Bug et UX. Une fois les bogues corrigés, ils reçoivent cette balise.
completed
Lorsque les fonctionnalités suggérées dans les catégories Feature et UX sont implémentées, elles reçoivent cette balise.
delivered
Lorsqu’un sujet dans Marketplace est confirmé comme livré par le fournisseur ou le destinataire, il reçoit cette balise.
Ostensibly, you pop the fixed tag on bugs that have been fixed and completed on feature requests that have been implemented. [1] Cela fait partie du processus pour clore les sujets (et tenir les parties prenantes informées des informations pertinentes). Ils ont été initialement mis en œuvre pour fournir une indication visuelle qu’« une bonne chose s’est produite » par rapport au symbole de verrouillage d’un sujet fermé. Lorsque ces balises sont appliquées de manière cohérente, vous obtenez une belle vague de vert lorsque vous faites défiler les listes de sujets de leur catégorie.
(Et delivered était une balise distincte mais similaire qui n’était pas contrôlée par l’équipe, elle pouvait donc être utilisée dans Marketplace)
Pour Solved, il existe pas mal de catégories où elle est active plutôt que la catégorie générique Support. Pratiquement toutes les catégories où la majorité des sujets seront des questions qui peuvent obtenir une solution. Support, Installation, Dev, Data & reporting, SSO
Idéalement, la meilleure pratique est que l’OP marque la solution, mais nous savons que cela n’arrive parfois pas (pour diverses raisons), donc je parcourais souvent les listes de sujets et nettoyais certaines d’entre elles après quelques semaines (une fois qu’elles étaient considérées comme « abandonnées »)
FWIW Le sujet Theme component pour cela est Reader Mode, donc vraiment ce sujet feedback que vous avez lié ne devrait pas être dans Theme component (car ce n’est pas un sujet de composant de thème). Il devrait probablement être dans Feature ou UX car je pense que c’est là que ces sujets ont fini par vivre maintenant qu’il y en a plus.
(Je pense qu’il était dans Site feedback car c’était une expérience ici sur meta)
et avec UX étant un entre-deux entre les deux, l’un ou l’autre peut être utilisé en fonction de la « saveur » du sujet spécifique ↩︎
Génial ! Merci d’avoir comblé quelques lacunes. J’ai mis à jour mon tableau ci-dessus.
Cela n’a pas été fait systématiquement depuis votre départ, c’est pourquoi nous avons maintenant ce sujet pour parler de la mise à jour et de la mise en place d’un système afin de ne pas prendre de retard à nouveau.
Ouais, je suppose que c’est ce que je visais avec le fil de discussion initial. @JammyDodger - vous nous manquez et votre dévouement à faire fonctionner Meta si bien ! Personnellement, j’espère qu’ils vous feront une offre que vous ne pourrez pas refuser…
Je reviens sur ce Sujet car j’ai récemment été réprimandé pour avoir signalé un Sujet dans Feature que je pensais devoir être marqué comme completed - mais qui ne l’était pas.
Ce que j’aurais voulu faire était simplement de l’étiqueter moi-même. Cependant, comme cette étiquette est restreinte à @staff, je ne pouvais pas. Hé, en tant que TL4, je peux faire beaucoup de choses potentiellement destructrices, mais pas ça. Je ne peux même pas modifier les étiquettes dans certaines Catégories (c’est-à-dire Plugin).
Alors, comment est-on censé signaler ces petites choses aux modérateurs sans les ennuyer et se faire réprimander ? Ou est-ce que le plan est de laisser un peu le désordre ?
Je pense qu’il est acceptable de signaler le sujet comme autre chose et de dire que vous pensez qu’il devrait être marqué comme terminé/résolu, du moins pour les sujets « anciens » (c’est-à-dire : qui ont été terminés/résolus il y a 6 mois mais dont le sujet n’a pas été mis à jour).
(Même si d’autres ne sont pas d’accord avec cela)
Pour les choses urgentes : ce serait une bonne pratique pour notre personnel de s’assurer qu’il assure le suivi des éléments qu’il corrige.
Je pense que si nous mettons des drapeaux pour étiqueter chaque fonctionnalité terminée depuis les 13 années d’activité de ce forum parce que certaines personnes ont le TOC, ce serait une grande perte de temps pour tout le monde.
L’étiquette elle-même est assez récente, jamais largement adoptée, et nous pourrions simplement fermer les sujets pour les fonctionnalités terminées, permettant à chacun de créer de nouveaux sujets et de citer les anciens si nécessaire.
Je préférerais supprimer le drapeau #completed. Il a été appliqué 400 fois et n’a été créé que pour aider les gens à rédiger des journaux de modifications, qui sont traités différemment de nos jours.
Je ne suis pas sûr de reconnaître cela comme la raison. Il a été initialement mis en œuvre pour fournir un indicateur visuel qui séparait les demandes de fonctionnalités terminées du reste des sujets clos. Il y a une conversation quelque part ici entre moi, Sam et Dave avec plus d’informations si vous faites une recherche. (Je pense que c’était dans des murmures, mais je ne me souviens plus exactement où)
Personnellement, je n’ai pas trouvé cela particulièrement pénible à suivre à l’époque. Je me suis davantage concentré sur la fenêtre « active » pour m’assurer que les sujets en haut de /latest étaient plus cohérents, bien que j’aie également traité les autres s’ils croisaient mon chemin (sujets connexes, et autres). Faire un audit complet de la catégorie Feature serait en effet un travail beaucoup plus important. (sans dire que ce ne serait pas utile de parcourir et d’élaguer/fusionner/clore ceux qui ont été oubliés au fil des ans, juste pour dire que cela prendrait du temps et qu’il faudrait évaluer où cela se situe sur la liste des priorités).
Est-ce une crainte de ce qui pourrait arriver, ou est-ce que cela se produit réellement ? Si c’était occasionnel, je ne pense pas que ce soit un gros problème, mais si cela devenait une tendance, je suis d’accord pour dire que le système de drapeaux ne serait pas le meilleur endroit pour cela. Je pense qu’un MP serait une manière moins intrusive de recueillir l’information.
Mais je comprends aussi que vous ne voulez pas vraiment que les développeurs et les concepteurs, etc., soient trop impliqués là-dedans car ils auront d’autres travaux importants à faire plutôt que de ranger la méta.
Peut-être que les choses qui nécessitent un modérateur, mais qui ne sont pas urgentes, pourraient être signalées par MP à une boîte de réception de groupe séparée. Ainsi, de tels enregistrements de nettoyage n’inonderaient pas la file d’attente de révision, cachant les sujets sur lesquels quelqu’un doit agir bientôt, mais il y aurait toujours un endroit pour les collecter, afin que quelqu’un puisse s’en occuper s’il a quelques minutes.
Cela pourrait fonctionner pour toutes sortes de notes secondaires, comme une balise manquante, un lien de prévisualisation cassé dans un sujet de composant de thème, ou un sujet de fonctionnalité qui pourrait être fermé, afin que les votes soient retournés aux utilisateurs.
Oh ! Je réalise que le groupe des modérateurs est vide ! Je comprends maintenant pourquoi un MP que j’ai envoyé à @moderators il y a quelques semaines est resté sans réponse…
Je l’avais créé dans le cadre de mon idée d’avoir une approche plus douce et plus bienveillante de la modération ici. Il est important d’avoir un point de contact unique où l’on peut joindre un modérateur et savoir que l’on obtiendra une réponse. J’espère que la décision de supprimer cela sera réexaminée.
Aussi, dans le cadre de mes efforts pour être plus gentil et plus bienveillant, j’ai fait de mon mieux pour éviter d’utiliser « perte de temps » comme raison pour les décisions des modérateurs. Je ne pense pas que des leaders de communauté bien intentionnés qui essaient d’aider à garder les discussions ordonnées devraient se sentir mal à ce sujet.
Pour revenir au sujet initial… J’avais une tâche régulière de revoir et de nettoyer les sujets plus anciens, et c’était une bonne tâche manuelle car il y avait souvent des détails à régler en cours de route. Parfois, les sujets pouvaient simplement être supprimés ou fusionnés, etc. Mais c’est une tâche gargantuesque et je n’ai réussi à remonter que de quelques années.
Je serais favorable à permettre à des vétérans de confiance comme @nathank d’ajouter les étiquettes plutôt que de les obliger à signaler les sujets pour examen par le personnel, surtout en ce moment où il n’y a ni responsable communautaire ni équipe de modération dédiée.
Edit : J’ai toujours les liens dans ma barre latérale ! C’était pour voir les sujets ouverts, non résolus et vieux de plus d’une semaine. Je trouve toujours ces liens utiles pour voir à quel point nous réussissons à résoudre les sujets. Peut-être que nous pourrions être plus nombreux à aider avec cela si le personnel n’a pas le temps de le faire.
Nous sommes dans une période de transition en ce qui concerne les modérations, donc certaines des décisions que nous prenons à l’instant même pourraient ne pas être durables, mais voici mes deux centimes sur ce sujet particulier :
Je pense que nous devrions viser un endroit où :
Les drapeaux sont utilisés pour des choses plus importantes
Nous avons un moyen de gérer d’autres choses qui sont plus triviales, ou pour le jardinage général
Si nous voulons utiliser completed, nous devrions donner à un groupe de personnes le pouvoir de gérer cela sans utiliser de drapeaux. Peut-être :
Accorder aux TL3 et TL4 le pouvoir d’étiqueter les choses comme telles
Créer un sujet de « jardinage » où les gens peuvent faire des suggestions pour tout type de jardinage de contenu
J’apprécie vraiment cela. Comme on ne peut signaler un message qu’une seule fois et jamais plus, j’ai toujours été réticent à utiliser les drapeaux pour des problèmes triviaux, comme un lien de prévisualisation dans un sujet de composant de thème qui ne fonctionne plus.
J’ai suggéré la boîte de réception parce que je pensais que l’archivage des requêtes traitées pourrait aider à garder une trace de ce qui a déjà été résolu. Cela pourrait être plus difficile dans un sujet avec beaucoup de réponses.
Je ne suis pas sûr de l’utilité d’ajouter l’étiquette completed ou fixed sans pouvoir clôturer le sujet. Si quelqu’un d’autre est toujours nécessaire pour clôturer le sujet, cela n’aide pas beaucoup.
Nous envisagions des automatisations pour clôturer les sujets avec ces tags - je ne sais pas à quel point il serait difficile de mener ces expériences à bien.
Je lis chaque publication tous les jours. Vraiment. Ma dernière publication non vue date de juin 2024. Par conséquent, j’ai vu d’innombrables rapports de bogues/d’expérience utilisateur être corrigés ou terminés. Généralement, je me contenterais de les signaler pour qu’ils soient clôturés. Je vois moins la nécessité des balises fixed ou completed, mais juste une clôture du sujet. À mon humble avis, cela seul signifie que le sujet a été résolu.
D’un autre côté, je suis également d’accord avec ceci :
fermer le sujet
Je me suis davantage concentré sur la fenêtre « active » pour m’assurer que les sujets en haut de /latest étaient plus cohérents, bien que j’aie également traité les autres s’ils croisaient mon chemin (sujets connexes, et autres). Faire un audit complet de la catégorie 
(sans dire que ce ne serait pas utile de parcourir et d’élaguer/fusionner/clore ceux qui ont été oubliés au fil des ans, juste pour dire que cela prendrait du temps et qu’il faudrait évaluer où cela se situe sur la liste des priorités).
