How does Meta handle the bug reporter badge?

커뮤니티 구축 데이터 및 보고
1

누군가가 #contribute:bug에 게시된 버그 토픽을 좋아한다는(Discourse에서) 것을 알아요. 이 작업을 위해 웹 서비스를 사용해서 새 게시글의 첫 번째 좋아요를 듣고, CDCK의 누군가가 여러 번 좋아요를 누르지 않았는지 확인하는 건가요?

구현 방식에 대해 더 알고 싶어요!

2

We have a custom badge for that one. :+1: (more info in Creating 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 :slight_smile:)

3

@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.

4

정말 재미있어요. :slight_smile: 영감이나 팁이 필요하시다면 참고할 수 있는 예제들이 꽤 많습니다. :+1:

Contribute > Bug 카테고리는 우리의 버그 큐에서 큰 부분을 차지합니다. :slight_smile: 중복을 피하기 위해 종종 Meta 토픽 자체 내에서 문제를 처리합니다(위스퍼, @멘션, 할당을 사용하며), 상당한 추가 논의나 다른 사람의 의견이 필요할 때만 Team 영역으로 분리합니다. 고객 채널을 통해서도 버그 리포트를 받는데, 이 역시 여러 건의 리포트가 있거나 이미 공개된 리포트가 존재하는 경우가 아니라면(이 경우 대화를 과도하게 분산시키지 않도록 일반적으로 하나를 메인 리포트로 사용하고 나머지는 상호 링크합니다) 대부분 ‘토픽 내에서’ 해결됩니다. 우리가 직접 발견한 문제의 경우, 누군가가 들어와 해결할 준비가 된 작은 것들을 메모할 수 있는 몇 개의 내부 토픽을 가지고 있으며, 더 큰 문제는 공개 Contribute > Bug 카테고리처럼 전용 토픽을 생성하여 처리합니다.

일반적인 흐름은 다음과 같습니다: 리포트가 들어오면 우리 중 한 명이 재현을 시도하고 필요한 추가 세부 정보를 수집합니다. 확인이 되면 관련 그룹/사람에게 @멘션 '배트 시그널’을 보내 우선순위를 정하고 할당합니다. 수정이 들어오면 토픽을 닫기 위해 게시글로 올립니다(일단 모든 것이 예상대로 작동하는지 확인하기 위해 토픽 타이머 지연을 설정합니다 :slight_smile:).

#contribute:feature는 조금 다르며, 내부적으로 논의할 내용이 훨씬 많습니다. 이러한 공개 토픽에서는 위스퍼를 최소화하고, 짧은 노트나 추가적인 관심을 받고 있는 토픽에 주목을 끌 때만 사용합니다(신뢰할 수 있는 @멘션이 다시 등장합니다 :slight_smile:). 이렇게 하면 대화가 너무 많은 곳으로 분산되지 않습니다. 프로덕트 매니저들도 이러한 주제에 대해 다양한 사용 사례를 탐구하고 가능성을 파악하며, 우리가 투명하게 할 수 있는 범위 내에서 해당 주제에 대한 생각을 알리기 위해 공개적으로 참여하기를 좋아합니다. #contribute:feature가 우리가 진지하게 고려할 가치가 있는 것으로 판명되면, 개발자, 디자이너, 프로덕트 매니저, 호기심 많은 커뮤니티 모더레이터 등이 아이디어와 목업을 통해 어떻게 가장 잘 달성할 수 있다고 생각하는지 의견을 나눌 수 있는 내부 토픽이 생성됩니다(Meta 토픽과 상호 링크하여 연결합니다).

이렇게 쓰고 보니 도움이 될지 모르겠네요… 하지만 더 궁금한 점이 있으면 알려주세요. :slight_smile: