고마워요. 
하지만 이걸 발견한 건 @Noah의 공이 크다고 생각해요.
7개의 좋아요
“Flag” 기능이 바로 이 용도로 만들어진 것 아닌가요?
5개의 좋아요
핵심은 로그인하지 않은 사용자에게 알림을 보낼 수 없도록 하겠다는 것이 아닙니다. 다만, 로그인하지 않은 사용자는 알림 버튼을 볼 수 없어야 합니다. 알림을 보낼 수 있는 권한은 로그인한 사용자에게만 있기 때문입니다.
3개의 좋아요
@dan 님이 초대 기능의 속도 제한(rate limiting) 작업을 맡으셨으니, 알림(notify) 기능의 속도 제한에 대해서도 의견을 주실 수 있을 것 같습니다.
또한, 이 기능이 아예 필요한지 여부에 대해서는 저도 고민 중입니다. 제 경험상 이 기능은 거의 사용되지 않는 것 같고, 발송되는 이메일은 다소 난해하고 기술적인 느낌이 강합니다. 얼마 전 급하게 누군가에게 응답을 받아야 할 때 이 기능을 사용해 봤는데, 상대방은 이메일의 지시를 제대로 읽지 않고 바로 답장을 보냈고, 그 결과 이메일이 반송(bounce)되어 버렸습니다. 바빴던 상대방은 그 반송된 이메일을 무시해 버렸죠.
요즘은 링크를 복사해서 이메일이나 문자, 트윗 등에 붙여넣는 것이 훨씬 쉽고 효과적이라고 생각합니다. 초대(invite) 기능에 대해서도 같은 생각을 하고 있습니다.
7개의 좋아요
어떤 입장인지 이해합니다. 개인적으로는 초대 기능이 여전히 좋습니다. 대규모 커뮤니티에서 작업할 때 초대 추적을 위해 유용할 수 있거든요.
1개의 좋아요
죄송합니다. 명확히 하자면, 초대 시스템을 완전히 없애자는 뜻이 아닙니다. 초대 시스템을 정말 좋아합니다! 제 말은, 디스코스가 이메일을 보내는 데 의존하는 것보다 초대 링크를 직접 받아서 보내는 것이 더 효과적이라는 뜻입니다.
3개의 좋아요
죄송합니다, 완전히 오해했네요.
3개의 좋아요
더 간단한 또 다른 옵션은 @멘션 제한을 활용하는 것입니다. 개념적으로 동일한 방식이며, 자리를 비운 상태에서도 @멘션은 기본적으로 이메일을 트리거합니다.
해당 기능을 제거하는 것에 동의합니다. 이 기능은 다소 이상하며, "왜?"라는 맥락을 함께 묶을 수 없기 때문에 종종 혼란스러운 알림을 유발합니다.
@codinghorror 의견 주시겠어요?
7개의 좋아요
사이트 편집을 처음 해보는 건데, 사이트의 CSS를 편집하는 방법에 대해 알려줄 자료가 있을까요?
우리 커뮤니티에서 누군가가 이 기능을 쉽게 악용할 수 있다는 사실을 알아냈습니다.
4개의 좋아요
테마 컴포넌트로 이렇게 추가하면 됩니다:
/admin/customize/themes경로로 이동합니다.- 설치를 클릭한 다음 새로 만들기를 선택합니다.
- 이름을 지정하고 'component’를 선택합니다.
- 생성을 클릭합니다.
- 테마에 추가합니다.
- CSS/HTML 편집 버튼을 클릭하고 코드를 공통 탭에 붙여넣습니다.
그리고 저장하세요. 
다만 이는 버튼의 겉모습만 숨기는 것일 뿐, 실제 기능은 비활성화되지 않습니다.
8개의 좋아요
아, 그래요, @Noah 감사합니다! 쪽지를 보내주시면 감사의 뜻으로 작은 선물을 보내드릴게요! 
(Jammy도 마찬가지예요)
8개의 좋아요
응답을 첨부할 수 있도록 하면 더 유용할 것 같습니다.
또한, 특정 주제나 답변에 다른 사람의 주의를 끌기 위한 훨씬 더 은밀한 방법이기도 합니다.
네, 하지만 이제 Discourse가 공유 대화상자를 하나로 통합하고 있으니 상황이 곧 변할 것 같은 느낌이 듭니다.
3개의 좋아요
여기에는 두 가지 접근 방식이 있는 것 같습니다:
- 공유 팝업에서 알림 버튼을 완전히 제거합니다. 이제 사용자는 링크를 복사/붙여넣어 다른 사람과 주제를 공유합니다.
- 알림 버튼을 @ 멘션과 동일한 방식으로 작동하도록 만듭니다. 한도는 @ 멘션과 동일하며, 알림을 받은 사람이 받는 이메일도 @ 멘션을 받은 사람이 받는 이메일과 동일합니다. 따라서 이메일로 답장을 결정하면 해당 답장이 주제에 도달합니다.
8개의 좋아요
개인적으로는 2번 옵션이 더 마음에 들지만, 다른 사람들은 내 의견에 동의하지 않을 것 같기도 해요.
5개의 좋아요
저는 옵션 (1)을 선호합니다. @codinghorror, 결정은 당신에게 맡깁니다. (1)은 훨씬 구현하기 쉽습니다(단순히 코드를 제거하면 되므로) 그리고 현재 이 기능은 이미 문제점이 있습니다. '핑’을 보내는 이유에 대한 맥락을 전혀 제공하지 않기 때문입니다.
5개의 좋아요
네, 저도 2번 옵션을 더 좋아합니다. “알림” 기능을 아예 제거하기보다는 기회를 주고 고치려고 노력해야 한다고 생각합니다.
2개의 좋아요
하지만 결국에는, 위험을 제거할 수만 있다면 저는 괜찮습니다. 기쁩니다.
1개의 좋아요
그 접근 방식이 악용될 수 있는가요?在那里에 작성된 내용에 대해 검열을 위한 기록이 남게 될까요? (즉, ‘비밀’ 메시지를 보내는 데 얼마나 쉽게 사용될 수 있는가)
3개의 좋아요