언급할 수 있는 대상 제한 설정 방법?

누구를, 그리고 언제 멘션할 수 있는지에 대한 정책은 포럼에 따라 크게 달라집니다. 여기서는 가끔 다음과 같은 댓글을 볼 수 있습니다:

아까 멘션해서 죄송합니다. 그게 예의에 어긋난다는 걸 몰랐습니다.

어딘가에 설정을 만들 수 있다면 이 문제를 해결할 수 있을까요 — 예를 들어, 멘션을 받을 수 없는 사람이 제한된 특별 그룹을 만드는 것이라든가요. 하지만 그렇게 하면 너무 제한적일 수 있고, 스태프나 기타 백그라운드 그룹의 업무를 위해 누가, 언제 멘션을 사용할 수 있는지에 대한 추가 설정이 필요합니다.

또한 에러 메시지는 그 사람을 멘션할 권한이 없습니다라는 일반적인 메시지보다 더 구체적인 정보를 제공해야 합니다.

이 기능이 기술적으로 구현하기 어렵다는 의미에서 또 다른 초안(구상 단계)에 그칠 것 같은 불길한 느낌이 듭니다. 하지만 다시 한번 말씀드리자면, 개발 관련 지식이 제로 이하입니다. 만약 쉬운 일이었으면 이미 구현되어 있을 거 아니겠습니까?

하지만 사용자가 존재하는 도구를 사용하고 있는데, 그 도구를 사용해서는 안 되는 상황은 꽤 이상합니다.

(AI가 제안한 제목: @가 금기인 경우: 포럼 멘션 정책 관리 :winking_face_with_tongue:)

7개의 좋아요

최근 #marketplace에서 이 주제가 다뤄졌다고 생각합니다:

3개의 좋아요

알아두어서 좋습니다. 마켓플레이스를 잘 따라가지 못하는데도, 왜 코어에 포함되지 않는지 이해가 되지 않거든요.

2개의 좋아요

디스코어(Discourse) 코어가 커뮤니티 하트비트(heartbeat)를 팩스로 보내지 않는 이유와 같습니다. CDCK 팀이 고객들을 위해 수행하는 작업의 범위를 고려할 때, 이에 대한 큰 수요가 없다는 것을 알 수 있습니다. 다행히도 이 프로젝트는 오픈 소스이므로, 조건이 어떻게 설정되든 누군가 이 작업을 맡는 순간 해당 기능이 등장할 가능성이 이론상으로는 있습니다. 따라서 이 마켓플레이스 요청에 함께 참여해 주신다면, 잠재적인 개발자를 더 빨리 찾기 위해 예산을 늘릴 수 있습니다. 지금까지 해당 마켓플레이스 요청에 대한 답변은 없습니다.

1개의 좋아요

그것은 가장 형편없는 논리 중 하나이며, 당신도 그것을 알고 있습니다 :smirking_face:

고대 도구인 유선 전화기나 수표(종이 조각으로 현금 역할을 하는 것, 심지어 그것을 쓰는 것조차…)의 예를 들기 때문이 아니라, 디스코urses가 단순히 코드의 한 조각이기 때문입니다. 여기서 우리는 행동을 제한하는 도구에 대해 이야기하고 있습니다. 디스코urses 팝업이 화면에 표시되거나 손목에서 경고음을 울리기 시작하는 시점과 장소를 제한할 수 있는 것과 마찬가지로요.

정보 흐름을 제한할 필요가 있는 이유를 완전히 이해합니다. 하지만 사용자가 널리 사용되는 제공된 도구를 사용할 때 시시때때로 잔소리를 하는 것보다, 설정과 자동화를 통해 좀 더 문명적인 방식으로 이루어져야 합니다.

아니요. 메타의 정책에 대해 논의할 의사가 전혀 없습니다. 저는 그러한 옵션에 대한 필요성과 수요가 있다는 것을 보여주기 위해 이 포럼을 예시로 들었습니다.

당신의 해결책은 내장된 행동을 제한하는 옵션을 얻기 위해 돈을 내는 것입니다. 저는 소프트웨어 자체가 자신의 동작을 조정할 수 있는 옵션을 제공하는 것을 보고 싶습니다. 다른 모든 것과 마찬가지로요.

디스코urses의 기술적 구조, 작업량 등을 고려할 때 그것이 불가능한 임무라면, 그리고 그 결과로 인간이 잔소리를 하는 것이 더 저렴한 옵션이라면, 저는 기쁩니다 — 하지만 그것을 듣고 싶습니다. 또는… 아무도 AI 시대에 인간 모더레이션과 더 긴 규칙책보다 더 신뢰할 수 있는 도구가 필요하다고 생각하지 않는다면, 이 기능 요청은 '3의 규칙’을 충족하지 못하거나 심지어 기업 고객의 필요조차 충족하지 못하는 것이며, 그 또한 괜찮습니다.

2개의 좋아요

예절의 핵심은 어느 정도 맥락에 달려 있다는 점입니다.

고객 지원 주제에서 특정인의 개입을 요구하는 것은 적절하지 않지만, 다른 맥락에서는 적절할 수 있습니다. 예를 들어, 다른 곳에서 해당 인물의 참여를 인용하거나 감사의 뜻을 전하는 경우 등이 그렇습니다. 이러한 행동을 코드에 구현할 수 있는 논리를 찾아내더라도, 사용자들이 반드시 그 의미를 이해하지는 못할 것입니다.

2개의 좋아요

정말 그렇습니다. 그리고 바로 그 이유 때문에 우리/그들/모든 사람이 설정 항목을 하나 더 필요로 합니다.

참고로, 멘션 기능을 제한하지 않는 진짜 이유가 배경 작업(다시 한번 예를 들어)이 너무 쉽게 깨지기 때문이라면, 예를 들어 팀 메시징이나 거기서 작동하는 기타 기능들이 영향을 받는다면, 그것은 이해할 수 있는 일입니다.

저는 라이브 서포트와 판매 분야에서 일한 경험이 있습니다. 글로벌 시장보다는 스칸디나비아 시장을 주로 다뤘지만, 영국인들은 요구 사항이 충족되지 않으면 즉시 상급자에게 연락하려는 매우 강한 경향이 있습니다. 그래서 고객에게 이메일 주소와 전화번호가 전혀 제공되지 않았습니다. 고객들이 다른 업무를 하고 있으므로 귀찮게 하지 말라고 요청하는 것에 의존하지 않았습니다.

멘션 제한에도 동일한 원리가 적용됩니다. 환경은 다르지만, 원칙은 완전히 같습니다.

2개의 좋아요

우리는 동일한 문제에 직면해 있습니다. 하지만 Discourse 구조에서 상위 관리자분들을 언급하는 것은 예의가 아니라고 생각되고(이 요청을 그들의 시야에 올리려면 누구를 태그해야 할지 확신이 서지 않습니다), 우리는 그들이 흥미로운 기능 요청을 우연히 발견하거나, Meta-Discourse에 열정을 가진 사람들이 내부적으로 공유할 수 있는 어떤 경로를 통해 이 문제가 해결되기를 바랄 수밖에 없습니다.

동시에, 이 훌륭한 제품을 사용하는 커뮤니티로서, 아웃소싱 개발을 지원함으로써 핵심 기능 개선을 도울 수 있습니다. 마켓플레이스 요청 기능에 크라우드펀딩이라는 훌륭한 기능이 추가될 수도 있는데, 이는 우리가 구현할 수 있는 또 다른 생산적인 아이디어가 됩니다. :slight_smile:

2개의 좋아요

이 주제는 기본적으로 이 주제와 동일합니다:

멘션이 아닌, PM을 제한하는 해결책

Discourse Restrict PMs to certain Groups

2개의 좋아요

@멘션에 그 플러그인이 그렇게 유용할지 확신하지 못합니다. 개인 메시지에만 사용되는 것 같네요.

2개의 좋아요

이것은 이중적인 용도로 사용되는 것 같습니다:

수정: 이것은 게시글 상단의 정보 블록에서만 언급되고 다른 곳에서는 언급되지 않으며, 이것이 실제로 해당 플러그인의 일부인지 확신할 수 없습니다.

3개의 좋아요

변명은 5km 달리기를 마치고 집에 돌아왔다는 거예요. 밖 기온이 -10˚C / 14˚F였고, 땀에 젖은 채로 사우나를 간절히 기다리고 있었거든요.

그리고 이제 제가 처음에 링크를 걸어둔 글을 읽어야겠네요…

2개의 좋아요

오해의 소지가 있는 요약을 드려 죄송합니다. 거기서 실수를 했습니다. 우리가 후원한 플러그인은 개인 메시지(PM)만 제한할 뿐, 멘션(mention)에는 영향을 미치지 않습니다.

3개의 좋아요