I know it happens when someone from Discourse likes the bug topic posted in bug. Do ya’ll use a webservice for this and just listen for the first like on a new post, and just check to make sure it’s not liked multiple times by someone at CDCK?
Would love to know more about your implementation!
We have a custom badge for that one. 
(more info in Create Triggered Custom Badge Queries and Enable Badge SQL)
This is the code for it:
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
(As an added aside, I’ve also created similar ones to work off a specific Reaction from a certain group as well 
)
@JammyDodger this is awesome! I just haven’t had the time yet to break into custom badge queries, but this might finally give me an in.
If it’s possible to ask, how do you handle bug submissions internally beyond the badge? At least in the context of Meta? Do you manually add it to your bug queue somewhere? Use a plugin to send it to your bug queue right from the topic?
I’m also curious about the logistics about handling bug reports and feature requests in Discourse and how you tie it back to your development/internal systems.
They are a lot of fun. And there are lots of examples knocking about if you need any inspiration or tips.
The bug category is a big part of our bug queue. To avoid duplication, we often handle the issue within the Meta topic itself (using whispers, @mentions, and assigns) and only really split any issues off into a Team area if they need significant extra conversation or input from others. We also get bug reports through customer channels as well, which are also often resolved ‘in topic’ unless there are multiple reports or a public one already exists (in which case one is generally used as the main one so as not to split the conversation too much, and the others are cross-linked). For ones we spot ourselves, we have a couple of internal topics that we can use to make a note of smaller things ready for someone to dip in and solve, and for larger ones we spin up a dedicated topic in the same way as the public bug category.
Generally, the flow is: a report comes in and one of us will try and repro it and grab any extra details needed. Once confirmed we’ll then send out an @mention bat signal to the relevant group/person to give it a priority and assign it out. The fix comes in, and is popped in a post to close out the topic (with a topic timer delay just so we can confirm everything is working as expected first ).
feature is a little different as there’s often a lot more to discuss internally. We try to keep whispers to a minimum on those public topics, and reserve them for short notes and drawing attention to ones that are picking up extra interest (trusty @mentions again ). That way we don’t splinter the conversation between too many places. The product managers like to engage with these publically as well to explore different use cases and to feel out the possibilities (as well as to let people know what their thinking is on the subject as we like to be transparent where we can ). If a feature becomes one that we’re seriously considering it will get an internal topic where devs, designers, product managers, curious community moderators, etc can all weigh in with ideas and mockups for how they think it can be best accomplished (cross-linked to the Meta topic to join them up).
Now I’ve written it, I’m not sure if that’s helpful… But let me know if you want to know anything else.