Comment Meta gère-t-il le badge de rapporteur de bugs ?

Je sais que cela se produit lorsque quelqu’un de Discourse aime le sujet de bug publié dans Bug. Utilisez-vous un service web pour cela et écoutez-vous simplement le premier « j’aime » sur un nouveau message, et vérifiez simplement qu’il n’est pas aimé plusieurs fois par quelqu’un de CDCK ?

J’adorerais en savoir plus sur votre implémentation !

4 « J'aime »

Nous avons un badge personnalisé pour cela. :+1: (plus d’informations sur Creating triggered custom badge queries et Enable Badge SQL)

Voici le code pour cela :

SELECT distinct p.user_id, p.created_at granted_at, p.id post_id
FROM badge_posts p
JOIN topics t ON t.id = p.topic_id
JOIN post_actions pa ON pa.post_id = p.id AND
      post_action_type_id = (
                SELECT id FROM post_action_types WHERE name_key = 'like'
       ) AND
       pa.user_id IN (
           SELECT gu.user_id
           FROM group_users gu
           WHERE gu.group_id = ( SELECT id FROM groups WHERE name ilike 'team' )
       )
WHERE category_id = (
  SELECT id FROM categories WHERE name ilike 'bug'
) AND p.post_number = 1

(En aparté, j’en ai également créé de similaires pour fonctionner à partir d’une Réaction spécifique d’un certain groupe :slight_smile:)

5 « J'aime »

@JammyDodger c’est génial ! Je n’ai pas encore eu le temps de me pencher sur les requêtes de badges personnalisées, mais cela pourrait enfin me donner une piste.

Si c’est possible de demander, comment gérez-vous les soumissions de bugs en interne au-delà du badge ? Au moins dans le contexte de Meta ? L’ajoutez-vous manuellement à votre file d’attente de bugs quelque part ? Utilisez-vous un plugin pour l’envoyer à votre file d’attente de bugs directement depuis le sujet ?

Je suis également curieux de connaître la logistique de la gestion des rapports de bugs et des demandes de fonctionnalités dans Discourse et comment vous les reliez à vos systèmes de développement/internes.

5 « J'aime »

C’est très amusant. :slight_smile: Et il y a plein d’exemples qui circulent si vous avez besoin d’inspiration ou de conseils. :+1:

La catégorie Bug est une grande partie de notre file d’attente de bugs. :slight_smile: Pour éviter les doublons, nous traitons souvent le problème directement dans le sujet Meta (en utilisant des murmures, des @mentions et des assignations) et nous ne séparons les problèmes dans une zone d’équipe que s’ils nécessitent une conversation ou une contribution supplémentaire importante de la part d’autres personnes. Nous recevons également des rapports de bugs par les canaux clients, qui sont souvent résolus “dans le sujet” à moins qu’il n’y ait plusieurs rapports ou qu’un rapport public n’existe déjà (auquel cas l’un est généralement utilisé comme principal afin de ne pas trop diviser la conversation, et les autres sont liés). Pour ceux que nous repérons nous-mêmes, nous avons quelques sujets internes que nous pouvons utiliser pour noter les petites choses prêtes à être résolues par quelqu’un, et pour les plus grandes, nous créons un sujet dédié de la même manière que la catégorie publique Bug.

En général, le flux est le suivant : un rapport arrive et l’un d’entre nous essaie de le reproduire et d’obtenir les détails supplémentaires nécessaires. Une fois confirmé, nous envoyons un signal @mention au groupe/personne concerné pour qu’il lui donne une priorité et l’assigne. La correction arrive et est postée pour clore le sujet (avec un délai de minuteur de sujet juste pour que nous puissions confirmer que tout fonctionne comme prévu :slight_smile:).

Feature est un peu différent car il y a souvent beaucoup plus à discuter en interne. Nous essayons de minimiser les murmures sur ces sujets publics, et nous les réservons pour des notes courtes et pour attirer l’attention sur ceux qui suscitent un intérêt supplémentaire (encore une fois, des @mentions fiables :slight_smile:). De cette façon, nous ne fragmentons pas la conversation entre trop d’endroits. Les chefs de produit aiment aussi s’engager publiquement avec ces sujets pour explorer différents cas d’utilisation et pour sonder les possibilités (ainsi que pour faire savoir aux gens quelle est leur réflexion sur le sujet, car nous aimons être transparents lorsque nous le pouvons :slight_smile:). Si un Feature devient l’un de ceux que nous envisageons sérieusement, il obtiendra un sujet interne où les développeurs, les concepteurs, les chefs de produit, les modérateurs communautaires curieux, etc., pourront tous donner leur avis avec des idées et des maquettes sur la façon dont ils pensent qu’il peut être mieux réalisé (lié au sujet Meta pour les relier).

Maintenant que je l’ai écrit, je ne suis pas sûr que ce soit utile… Mais faites-moi savoir si vous voulez savoir autre chose. :slight_smile:

4 « J'aime »