So che succede quando qualcuno di Discourse mette “mi piace” all’argomento del bug pubblicato in Bug. Utilizzate un servizio web per questo e vi limitate ad ascoltare il primo “mi piace” su un nuovo post, e vi assicurate solo che non venga messo “mi piace” più volte da qualcuno di CDCK?
Mi piacerebbe saperne di più sulla vostra implementazione!
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
(Inoltre, ho creato anche elementi simili per funzionare con una specifica reazione di un certo gruppo )
@JammyDodger questo è fantastico! Non ho ancora avuto il tempo di approfondire le query personalizzate dei badge, ma questo potrebbe finalmente darmi un’opportunità.
Se è possibile chiedere, come gestisci internamente le segnalazioni di bug oltre al badge? Almeno nel contesto di Meta? Lo aggiungi manualmente alla tua coda di bug da qualche parte? Utilizzi un plugin per inviarlo alla tua coda di bug direttamente dall’argomento?
Sono anche curioso riguardo alla logistica della gestione dei report di bug e delle richieste di funzionalità in Discourse e a come li colleghi ai tuoi sistemi di sviluppo/interni.
Sono molto divertenti. E ci sono molti esempi in giro se hai bisogno di ispirazione o consigli.
La categoria Bug è una parte importante della nostra coda di bug. Per evitare duplicazioni, spesso gestiamo il problema all’interno dell’argomento Meta stesso (usando sussurri, @menzioni e assegnazioni) e separiamo eventuali problemi in un’area Team solo se necessitano di conversazioni o input aggiuntivi significativi da parte di altri. Riceviamo segnalazioni di bug anche attraverso canali clienti, che spesso vengono risolte ‘nell’argomento’ a meno che non ci siano più segnalazioni o ne esista già una pubblica (nel qual caso una viene generalmente utilizzata come principale in modo da non dividere troppo la conversazione, e le altre vengono collegate). Per quelle che notiamo noi stessi, abbiamo un paio di argomenti interni che possiamo utilizzare per prendere nota di piccole cose pronte per qualcuno che le risolva, e per quelle più grandi creiamo un argomento dedicato allo stesso modo della categoria pubblica Bug.
In generale, il flusso è: arriva una segnalazione e uno di noi cercherà di riprodurla e raccogliere eventuali dettagli aggiuntivi necessari. Una volta confermato, invieremo un segnale @menzione al gruppo/persona pertinente per dargli una priorità e assegnarlo. La correzione arriva e viene inserita in un post per chiudere l’argomento (con un ritardo del timer dell’argomento solo per poter confermare che tutto funzioni come previsto ).
Feature è un po’ diverso in quanto spesso c’è molto di più da discutere internamente. Cerchiamo di limitare i sussurri in quegli argomenti pubblici, e li riserviamo per brevi note e per attirare l’attenzione su quelli che stanno ottenendo maggiore interesse (di nuovo, fidati @menzioni). In questo modo non frammentiamo la conversazione tra troppi posti. Anche i product manager amano interagire pubblicamente con questi per esplorare diversi casi d’uso e per sondare le possibilità (oltre a far sapere alle persone qual è il loro pensiero sull’argomento, poiché ci piace essere trasparenti dove possiamo ). Se un Feature diventa uno di quelli che stiamo seriamente considerando, otterrà un argomento interno dove sviluppatori, designer, product manager, moderatori della community curiosi, ecc. potranno tutti contribuire con idee e mockup su come pensano che possa essere meglio realizzato (collegato all’argomento Meta per unirli).
Ora che l’ho scritto, non sono sicuro che sia utile… Ma fammi sapere se vuoi sapere qualcos’altro.