Des recommandations pour une configuration optimale de gestion des problèmes avec Discourse?

Aujourd’hui, la partie la plus négligée de notre communauté est la façon dont nous gérons les problèmes au sein de celle-ci. Pour information, nous gérons une communauté axée sur le produit, composée d’utilisateurs des produits développés par notre entreprise. Les problèmes peuvent bien sûr désigner des bugs, des demandes de fonctionnalités ou des problèmes généraux – tout comme un problème GitHub, en fait. Des problèmes provenant de nombreux vecteurs différents, tels que :

  • Problèmes GitHub pour le code/les outils que nous (mon équipe) possédons également
  • Problèmes GitHub pour notre marché open-source (plus de 50 dépôts/sujets en croissance)
  • Problèmes généraux/commentaires/bugs soumis concernant notre produit
  • Problèmes au sein de la communauté elle-même (demandes de fonctionnalités communautaires, etc.)
  • Problèmes internes soumis à notre équipe par d’autres unités commerciales (aujourd’hui, ils les envoient via Slack)
  • Problèmes de documentation

Ci-dessous se trouvent quelques-unes de mes réflexions actuelles et désorganisées sur la gestion de cela, mais j’ai pensé voir ce que d’autres font dans leurs communautés en attendant. Alors, comment faites-vous ?

  • Une partie de cette équation est votre lutte classique et éternelle entre les catégories et les étiquettes en termes d’organisation générale.
  • Les utilisateurs sont généralement dépassés par le nombre d’étiquettes possibles, peuvent ne pas savoir intrinsèquement quelle étiquette rechercher, ou dans la plupart des cas, n’essaient même pas d’en mettre une. (et exiger n étiquettes les oblige généralement à faire un effort minimum pour une étiquette)
    • Un formulaire de soumission global pourrait aider à alléger le processus de soumission pour cela, en supposant que vous optiez pour plus d’une ou deux catégories.
    • Une fonctionnalité puissante que Discourse pourrait ajouter serait de lier les étiquettes à des champs déroulants obligatoires dans les modèles de formulaire expérimentaux. Ainsi, par exemple, si la question déroulante est « Quel navigateur utilisez-vous ? », il y aurait des étiquettes Discourse associées aux réponses Chrome, Arc, etc.
  • L’un de mes plus grands problèmes à cet égard est une « vue administrative » de cette solution. Je pense que le plugin de tickets (bien que les captures d’écran soient cassées, je ne peux donc pas me rafraîchir la mémoire) pourrait être un bon cas d’utilisation pour cela.
    • J’aurais vraiment besoin d’agir sur beaucoup de métadonnées concernant le sujet à cet égard. Date de soumission, statut actuel, étiquettes associées, responsable(s), possibilité de les fermer, etc.
8 « J'aime »

Je suis tout à fait d’accord. Les modèles de formulaire pourraient devenir l’une des meilleures fonctionnalités de Discourse. Même l’ajout d’une entrée à utiliser comme titre de sujet. Il serait également pratique pour une grande variété d’utilisations de pouvoir insérer/afficher une image dans le modèle de formulaire.

2 « J'aime »

Se mettre d’accord sur le pouvoir. Tangentiel, mais il a également besoin d’une option de zone de texte entièrement libre comme la zone de texte du compositeur standard.

3 « J'aime »

Avez-vous envisagé d’utiliser le Custom Wizard Plugin :mage: ? Un exemple de configuration pour les rapports de bogues se trouve à Bug Report - Coöperative

3 « J'aime »

J’aurais dû mentionner : Je suis sur une offre d’entreprise avec Discourse, donc j’ai généralement besoin d’utiliser des #plugins officiels, ou d’en faire développer un/le faire maintenir par CDCK. :smiley:

4 « J'aime »