팀원에게 언급하지 않기/개인 메시지 보내지 않기 에티켓에 대해

사용자로서, 공개 포럼에서 팀원들이 활발하게 활동하고 기능 요청이나 버그에 대한 주제도 작성하는 모습을 보는 것은 정말 가치 있다고 생각합니다. 이렇게 하면 팀원들도 일반 사용자처럼 느껴져서 좋습니다. :hugs:
또한, 사용자가 이러한 팀원들에게 가볍게 말을 걸거나 직접 대화하게 유도하므로, 사용자가 무의식적으로 특정 "예절"을 무시하게 됩니다.

이 문제는 6년째 계속되고 있습니다. :grimacing:
팀원을 개인 메시지나 멘션으로 언급하지 말아야 한다는 예절 말입니다.
멘션은 자주 편집되고, 누군가가 "팀원을 멘션하지 마세요"라고 게시하는데, 때로는 무례하게 느껴지고, 사용자가 어떻게 그걸 알아야 하는지 모르겠습니다. 특히 다른 사용자들(보통 TL3 이상)은 팀원을 언급해도 지적을 받지 않는 상황에서 더욱 그렇습니다.

이렇게 갑자기 적용되는 규칙을 적용하는 대신, 팀원들이 누구와 연락하거나 멘션할 수 있는지를 제한하고 싶다면, 특정 그룹이나 사용자만 연락(PM 및 멘션)할 수 있도록 개인 프로필 설정을 구성해야 한다고 생각합니다. 예를 들어, 신뢰 수준 3 이상 + 테마 및 플러그인 작성자 + @arkshine 등…
이것은 특히 신규 사용자를 위한 더 환영하는 환경을 만들 것입니다.

이것을 일부 수행하는 공식 플러그인이 있지만, 세밀함이 부족하며, 제 주제는 메타에서 언급된 예절에 초점을 맞추고 있습니다. :technologist:

9개의 좋아요

이것이 주제와 직접적으로 관련이 없을 수 있지만, 이 부분을 언급하고 싶습니다.

Canapin이 언급한 것 외에도, 공개 포럼에서의 팀의 활동에 진심으로 감사드립니다. 팀의 존재감, 지식, 전문성은 여러분의 Discourse 경험을 환영받고 지원받는 것처럼 느끼게 해주며, 동시에 많은 것을 배우게 해줍니다.

사용자들이 서로를 도울 수 있도록 하는 것이 중요하다는 것을 이해하며, 팀의 적극적인 참여가 훌륭한 역동성을 만들어냅니다. 정말 즐거워요! 시간을 내어주신 팀에게 감사드립니다. :folded_hands:

15개의 좋아요

Arkshine와 Canapin과 마찬가지로 나도 같은 의견을 가집니다. 팀이 커뮤니티에 관여하는 것을 좋아하는데, 그렇게 하면 가치가 있다고 느끼게 되거든요.

내가 활동하는 다른 포럼에도 스태프를 태그하는 것에 관한 '규칙’이 있습니다. 하지만 그 표현은 '피하라(avoid)'로 되어 있어, 어떤 경우에는 태그해도 되는 것처럼 느껴집니다. 규칙/예절이 명확하게黑白(흑백)으로 나뉘어 있는 것을 선호합니다.

Meta의 경우, 마지막으로 팀 멤버를 언급한 시점이 언제였는지 기억이 나지 않습니다. 역할별로 누가 무엇을 하는지 항상 알지 못하기 때문에, 예절을 차치하더라도 팀 멤버를 언급하는 것은 물론이고, 적절한 사람을 언급하는 것에 대해 자신감이 생기지 않습니다.

하지만 제 생각에는, 중요하지 않은 상황에서 주의를 끌기 위해 스태프를 언급하는 것은 좋지 않다고 봅니다. 답변을 제공할 수 있는 다른 많은 사람들이 여기 있거든요.

유사한 주제인 멘션에 대해 묻는 Hawk의 관련 있는 게시물을 찾았습니다.

5개의 좋아요

이 문제를 제기해 주셔서 감사합니다. 그 마음은 충분히 이해합니다. 다만, 겉으로 보이는 것보다 상황이 좀 더 복잡합니다.

태그를 받는 것 자체는 마다하지 않지만, 제가 해당 게시물에서 언급한 상황에서는 예외입니다. 우리에게 알림 피로(notification fatigue)는 실제로 존재하는 문제이기 때문입니다. 저는 메타(Meta)에서 시간을 보내는 것을 즐기지만, 의도적으로 시간을 낼 수 있을 때만 그렇습니다. 그래서 저는 일반적인 지원 질문보다는 긴급하거나 중요한 사항에 대해 알림을 의존합니다. 일반적인 지원 질문의 경우, 맥락을 파악하기 위해 긴 주제를 처음부터 다시 읽어야 하는 경우가 많기 때문입니다.

@Canapin 님, 대부분의 메타 사용자에게는 잘 알려져 있지 않지만, 저희가 메타를 통해 고객에게 비공개로 지원을 제공하는 것도 기억해 주셨을 것입니다. 저에게 알림을 보내는 기능을 끄면 중요한 요청을 놓칠 수 있습니다. 새로운 고객을 추가할 때마다 새 그룹을 만드는 것은 현실적으로 불가능합니다. 다른 우회 방법이 떠오르시면, 기꺼이 시도해 보겠습니다.

12개의 좋아요

조금 주제에서 벗어날 수 있지만, 저희도 Discourse를 개인 고객 지원을 위해 사용하고 있으며, 각 고객마다 새로운 그룹을 추가하고 있습니다. 그러니 지금 말씀하신 것처럼, 더 나은 방법이 있을까요?

그렇지 않다면, 모든 이유를 충분히 이해합니다. CEO와 다른 팀 멤버들이 이렇게 활발하게 활동하는 것은 저에게는 마법과도 같습니다. 그 자리에 있으면 알림이 정말 많을 텐데… 그리고 이것은 공식적인 지원이 아니라 “그저” 커뮤니티일 뿐입니다. 그런데 이 커뮤니티는 정말 빠르고, Discourse는 수익을 창출하는 오픈소스입니다. 저에게는 오픈소스 프로젝트가 어떻게 작동할 수 있는지에 대한 끊임없는 영감의 원천입니다.

10개의 좋아요

죄송합니다, 제가 의도를 잘못 전달했을 수 있습니다. 저희도 각 고객마다 그룹을 추가하고 있지만, 제 ‘연락 가능’ 목록에 새 그룹을 계속 확인하고 추가하는 번거로움은 없애고 싶습니다.

5개의 좋아요

커뮤니티 리에이전트(Community Liaison)를 위해 별도의 그룹을 만드는 것이 팀 멤버와 도움을 주기에 관심이 있는 파트너들로 구성될 수 있는 좋은 아이디어일 수 있습니다.

양(물량) 때문에 팀이 모든 사소한 일에 대해 핑을 받지 않기를 원한다는 점은 충분히 이해합니다. 또한 유료 고객에게 우선순위를 부여하는 특수한 비공개 카테고리가 있는 것도 이해하며, 그 경우에도 양이 많으면 부담이 될 수 있다고 생각합니다.

다른 분들이 말한 것처럼, 현재의 상황에서도 팀의 소통을 정말로 감사하게 생각합니다. 제 생각에 소통 경험은 99.7% 매우 긍정적이기 때문입니다.

자함(Jam)의 역할에서 퇴임한 지금, 불필요하지 않은 한 커뮤니티 리에이전트를 @mebtuon으로 멘션하는 것이 괜찮은가요? 여전히 ‘높은’ 우선순위로 취급되는 건가요? 커뮤니티 리에이전트를 멘션해도 괜찮은 시점과 부적절한 멘션의 예시를 보여주는 게시물을 올리는 것은 어떨까요?

저는 한 회사의 킥스타터(Kickstarter) 캠페인 기간 동안 6,000명의 활성 가족 구성원을 가진 올인원(All-in-one) 포럼에서 자원봉사자로 활동한 경험이 있습니다. 그래서 번아웃 요소를 잘 이해합니다. 당시 회사는 모드 팀에 멤버가 있었지만, moderator(모더레이터)로서의 마인드가 부족했습니다. 그래서 포럼에서 모더레이션을 하는 경우는 극히 드물었습니다. 저는 또한 커뮤니티 리에이전트로서, 회사 외부의 커뮤니티 멤버가 커뮤니티를 대표하고 가이드하는 목소리가 된다는 가치를 인정받아 이 역할을 맡게 되었습니다.

그들은 가끔 감사의 의미로 제품을 보내주기도 했습니다. 그리고 업그레이드 관리 등을 맡기 위해 저를 관리자(Admin) 권한으로 승격시켜 주기도 했습니다.

3개의 좋아요

Dan, 고마워요. 커뮤니티 연계 그룹은 좋은 아이디어예요. 팀에 전달해 보겠습니다.

우리는 Tobias/제품 팀이 주도하며 전체 팀이 메타(Meta) 관리를 공동으로 책임지고 있습니다. 최근 몇 주 전부터 업무를 시작했기 때문에 아직 적응하는 단계입니다.

5개의 좋아요

아니에요, 다들 도와주시니 감사할 따름입니다. 모든 일은 시간이 걸리죠. 우리 쪽에서 중요한 건 이해와 인내입니다. 로마도 하루아침에 지어진 건 아니지만, 공사는 이미 시작되었어요.

:clinking_beer_mugs::smiling_face_with_sunglasses::+1::sparkles:

4개의 좋아요

나는 글에서 팀원을 '멘션’하는 걸 본능적으로 피하는 편이지만, 급한 마음에 몇 번은 그렇게 한 적이 있습니다.

이 자리를 빌려, 과거에 멘션했을 때 퉁명스럽게 반응하지 않고 친절하게 답해 주신 팀원분들께 감사의 말씀을 전하고 싶습니다. 다만, 여기서 이름은 언급하지 않겠습니다. :wink:

6개의 좋아요

팀 멤버를 멘션하라는 첫 번째 경고 이후로, 저는 아무도 멘션하지 않았습니다. 그것이 가장 안전한 길이었으며, 이 전략을 계속 유지할 것입니다.

하지만… 사실 저는 멘션 자체가 필요하지 않습니다. 토픽에 글을 쓰면 때로는 답변을 받고, 때로는 받지 못합니다. 누군가를 멘션한다고 해서 그 상황이 달라지지 않습니다. 대신 누군가를 인용(quote)할 수도 있는데, 그건 멘션과 같은 효과를 냅니다. 그리고 솔직히 누구를 멘션해야 할지도 모르겠어요 :joy:

제 의견은 여전히 같습니다 — 코더로 가득한 집이라면, 팀 멤버를 멘션할 수 있는 기능을 더 높은 TL(Team Lead)에게만 부여할 수 있다고 생각합니다. 그들은 이 기능을 어떻게 사용하지 않아야 하는지 알고 있기 때문입니다. 그리고 이런 시도를 하는 (신규) 멤버들에게는 작은 안내 메시지를 보여주는 것도 좋겠습니다.

왜냐하면 제가 이런 토픽을 어느 정도 이해하긴 하지만, (신규) 사용자가 자신에게 주어진 도구와 익숙한 도구를 사용하는 것이 다소 무례하게 들릴 수 있기 때문입니다. 멘션을 하지 않는 것은 일반적인 정책이 아닙니다.

4개의 좋아요

Discourse가 “2차 그룹”(그룹을 포함하는 그룹)을 지원한다면 이 기능을 자동화할 수 있습니다.

이 주제는 공식 커뮤니티(예: 공립 학교)를 위한 소통 플랫폼이자 디지털 가든으로서의 Discourse에 대한 제 깊은 관심사와 맞닿아 있습니다.

Discourse는 공개적이고 비공식적인 커뮤니티에 매우 잘 최적화되어 있습니다. 그러나 공식 커뮤니티를 지원하려면 상세하고 세밀한 권한을 구현할 수 있는 능력이 필요합니다.

특정 그룹이 다른 그룹의 멤버에게 개인 메시지(PM)를 보낼 수 있는지 여부에 대한 결정은 이러한 요구 사항 중 하나입니다.

전역 권한(관리자, 모더레이터, TL)을 설정할 수 있는 거의 모든 영역에서는 지역 권한(그룹 멤버)에 대한 필요성이 있습니다.

현재 공식 커뮤니티를 지원하는 작업은 적절한 구성을 위해 외부 도구에 의존하는 경우가 많습니다. Discourse의 권한 시스템 기반으로서 그룹 산술과 2차 그룹을 도입하면 이러한 기능을 플랫폼 내에서 직접 구현할 수 있게 됩니다.

7개의 좋아요

이 주제를 다시 다뤄봅니다:

  • 어떤 주제가 중재자의 주의를 필요로 한다고 생각되면, 플래깅(신고) 시스템을 사용해주세요. 문제를 식별하는 데 도움을 주셔서 감사하며, 이를 통해 가능한 한 빨리 해결을 시작할 수 있습니다.
  • 중재나 피드백에 관한 질문이 있거나, 문제를 알려줄 일이 있을 때 언제든 @moderators에게 메시지를 보낼 수 있습니다. 우리 중 한 명(아마도 저일 겁니다)이 회신드리겠습니다.
  • Contribute > Site feedback 카테고리도 피드백을 주고 이 커뮤니티가 어떻게 조직되고 운영되는지에 대해 이야기하기 좋은 곳입니다. 저는 이런 대화를 정말 즐기고 있으며, 매우 적극적으로 대응하려 노력하고 있고, 이곳의 제안들을 바탕으로 이미 많은 변경 사항을 적용했습니다.

위 내용 외에도, 팀은 알림 피로감(notification burnout) 때문에 @ 멘션에 민감합니다. Hawk가 위에서 이 점을 잘 요약해 주셨습니다. 또한, 시급성에 대한 인식과 누가 응답해야 하는지에 대한 불일치가 종종 발생합니다. 저희 오픈 소스 제품은 이 포럼에서 커뮤니티 지원을 제공하며, 답을 알고 있는 많은 분들이 여기 계시며 질문에 답하고 있습니다. 이 문제를 해결하기 위해, 저희는 더 잘할 수 있다고 생각합니다:

  • 중재자로서, 문제가 있을 때 게시물을 수정하거나 삭제할 권리를 보유합니다. 하지만 그렇게 할 때, 이것이 회원에게 큰 스트레스를 줄 수 있다는 점을 염두에 두어야 합니다. 저희가 인지하는 부적절한 행동으로 회원을 공개적으로 지적하는 대신, 왜 그렇게 했는지 알려주기 위해 개인 메시지(PM)를 보내는 방식으로 회원에게 더 다정하게 메시지를 전달할 수 있습니다. (다만, 규칙을 모두에게 상기시켜 주기 위해 공개적으로 하는 것이 도움이 되는 경우도 있습니다.)
  • @ 멘션을 하지 말아야 할 경우에 대해 회원들에게 매우 부드럽게 상기시켜 주시고, 가능하다면 왜 그렇게 할 필요가 없었는지 이유를 설명해 주세요. 대부분의 경우, 답할 수 있는 사람들은 이미 대화에 참여해 있습니다.
  • 부적절한 @ 멘션은 종종 인내심 부족과 적절하지 않은 시급감 감정을 동반합니다. 이에 대해서도 부드러운 상기 메시지로 대응하고, 주제에 중재자 가이드라인이 가득 차지 않도록 개인 메시지(PM)를 통해 후속 조치를 취할 수 있습니다.
  • Jagster의 의견에 동의합니다. 신규 회원의 @ 멘션을 적시에 팝업으로 늦추는 것은 좋은 아이디어입니다. 누군가 시도해 보고 싶다면 플러그인 영역입니다!
  • 곧 커뮤니티 지원 프로그램을 재개할 예정이며, 이를 통해 Discourse에 대해 매우 잘 알고 있고 저희가 신뢰하는 답변을 제공하는 커뮤니티 내 회원들을 식별하는 것이 모든 사람에게 쉬워질 것입니다.
  • 우리가 보고 싶은 행동을 본보기로 보여주세요. 예를 들어, 이 게시물에서 저는 이 주제에서 그들의 게시물을 참조하고 싶기 때문에 회원들을 언급하고 있지만, 인용하거나 @를 사용하지 않아 그들이 불필요하게 이 주제로 소집되지 않도록 하고 있습니다. 이는 특히 저희 팀에게 도움이 되는데, 고객 지원뿐만 아니라 커뮤니티 지원에도 이 사이트를 사용하기 때문에 @ 멘션을 받으면 매우 적극적으로 대응하려 노력하고 있기 때문입니다.
3개의 좋아요

모두가 게시물 링크에 대한 알림을 비활성화하셨나요?

그렇게 묻는 이유는, 제 생각에는 인용과 게시물 링크 사이에 거의 차이가 없기 때문입니다. 둘 다 기본적으로 작성자에게 알림을 보내며, 제가 인용하여 언급하는 내용이 주제 내에서 바로 보이게 하는 것이든, 아니면 링크를 걸어 다른 주제로 이동해야만 제가 언급하는 내용을 읽을 수 있게 하는 것이든, 개인에게 어떤 차이가 있는지 구별하기 어렵다고 느낍니다.

그리고 @멘션이 귀찮을 수 있다는 점에는 동의합니다. 최근에 누군가가 제 답변이 도움이 되었는지 사용자에게 물어보며 그 질문들에서 저를 @멘션하기도 했거든요 ;).
하지만 동시에, 계정을 익명 처리해 달라고 요청할 때 @멘션은 익명 처리됩니다. 반면 @가 사용되지 않은 경우는 익명 처리되지 않아 원래 사용자명을 쉽게 알아낼 수 있습니다. 저에게는 사용자가 이렇게 쉽게 익명 처리되는 옵션을 갖는 것이 옳지 않게 느껴지는 경우가 많습니다.

2개의 좋아요

알림 설정은 아무것도 변경하지 않았습니다. 인용과 멘션은 알림 아이콘이 다르며, 알림 메뉴에서 @를 보이면 우선순위를 높게 설정합니다.

그럼에도 불구하고, 인용하는 사람이 대화에 참여하지 않거나 현재 대화에 포함될 필요가 없는 경우에도 과도하게 인용하지 않도록 주의하고 있습니다.

그것이 귀찮다고 생각한다는 점을 알아서 다행입니다! 그걸 멈출 수 있습니다. :hugs:

흥미로운 지적입니다. 그 점은 생각해보지 못했고, 해결책이 있는지 알지 못합니다. 전체 사용자 이름을 언급하고 백틱을 붙이는 것이 더 나을 것 같습니다. 예를 들어 @moin

3개의 좋아요

백틱이 붙은 @멘션은 아무것도 바꾸지 않는 것 같습니다.

다음 내용을 테스트해 보았어요.

@signup 

<a class="mention" href="/u/signup">signup</a>

`@signup`

그중에서 첫 번째 항목만 익명 처리되었습니다.

그래서 Meta에서 여기서 무언가를 시도해 볼 가치가 있는지 확신이 서지 않습니다. AI 요약에 게시글과 연결된 사용자 이름이 너무 많이 포함되어 있거든요. 수동으로 사용자 이름을 멘션하는 것이 그 부분에 크게 기여하지 못할 것 같습니다.

그렇게 하신 건 하루뿐이셨던 것 같습니다. 보통 그런 경우에는 @멘션을 사용하지 않으시잖아요. 만약 자주 하신 거라면 말씀해 주셨을 텐데요. 아마 그날 @멘션 하고 싶으신 마음이셨던 것 같습니다 :woman_shrugging: . 그리고 그중 일부가 관련이 있는지 확인하는 것만 귀찮았을 뿐입니다. 하지만 @team이 해당 사람의 주의를 끌 필요가 없는 곳에서는 @멘션을 피해 달라고 요청한 맥락에서 보면, 꽤 놀라운 일이었습니다.

3개의 좋아요

@username~를 도입하여 알림을 억제하는 "비공개 멘션"으로 작동하게 하는 건 어떨까요? 틸드(~)는 렌더링된 콘텐츠에서 제거되어 시각적으로도 동일하게 보일 수 있습니다. 구현도 그리 어렵지 않을 것 같습니다.

6개의 좋아요

현재 HTML 옵션보다 더 간편한 무음 @멘션 기능이 있으면 좋겠다는 아이디어를 좋아합니다. 무음 인용도 가능할 것입니다.
링크에 사용되는 ?silent=true와 유사한 구문을 인용에도 추가할 수 있습니다. full:true 매개변수와 마찬가지로 silent:true
[quote="RGJ, post:17, topic:351280, full:true"]를 사용할 수 있습니다.

4개의 좋아요

또한 인용하는 사람이 해당 대화에 참여하지 않거나 현재 대화에 끌려들 필요가 없는 경우, 과도하게 인용하지 않도록 주의하고 있습니다.

인용된 쪽(quotee)에게 미치는 영향을 진지하게 생각해 본 적이 없었습니다 – 아마도 제가 그런 통보를 많이 받지 않기 때문일 것입니다. 매번 누군가를 알림하는 것이 아니라, 전체 게시물에 대한 링크를 제공하려는 것입니다. 팝업에 “조용한 인용(quiet quote)” 옵션이 있다면 이 문제를 더 쉽게 해결할 수 있을 것 같습니다:

3개의 좋아요

예절에 대한 대화가 이렇게 빠르게 제품 브레인스토밍으로 변하는 걸 보면 참 재미있네요. :rofl:

제안하신 아이디어들이 꽤 좋습니다. '무음 멘션’과 ‘무음 인용’ 아이디어는 Contribute > Feature 토픽에서 더 깊이 다룰 가치가 있습니다. 상대방에게 알림을 보내지 않으면서도, 사용자를 클릭해서 사용자 카드를 볼 수 있도록 멘션할 수 있는 아이디어가 좋습니다. 인용도 마찬가지입니다. 인용된 게시물을 다시 참고할 수 있도록 인용 기능을 유지하는 것이 유용하지만, 항상 인용된 사용자에게 알림을 보내고 싶지는 않죠.

하지만 솔직히 말하면, 이는 메타(meta) 차원의 문제라고 생각합니다. 대부분의 커뮤니티는 정반대의 요구사항을 가지고 있습니다. 멘션이나 인용이 되었을 때 사람들이 다시 돌아와 대화를 이어가도록 자극하고 참여도를 높이기 위해 이러한 알림이 필요하거든요.

그리고 OP(원문)로 돌아가서 말하자면, 여기 메타에서도 규범 설정만으로도 '충분하다’고 생각합니다. 커뮤니티가 @멘션을 과도하게 사용하지 않을 것이라고 신뢰하고 있습니다. 드물게 그런 일이 발생하면, 아마도 신규 멤버일 가능성이 높은 그 사람에게 (부드럽고 친절하게!) 그렇게 하지 말아 달라고 살짝 권고할 수 있습니다.

6개의 좋아요