한편으로는 사이트를 익명 브라우징에 개방하여 검색 엔진이 인덱싱할 수 있도록 하고, 비회원도 접근할 수 있게 하며, 원칙적으로 공개적이고 투명하게 유지하는 것입니다.
다른 한편으로는 크롤러와 일회성 비회원에게 신원 식별 정보를 불필요하게 노출하는 것을 방지하는 것입니다. 우리는 커뮤니티 내에서 사람들이 이름을 공유할 수 있도록 하고, 많은 사람들이 이를 할 때 느끼는 경계심을 해소하고 싶습니다.
처음에는 “게시물에 표시 이름(Display name on posts)”을 비활성화하고 “공개에서 사용자 프로필 숨기기(Hide user profiles from public)”를 활성화하면匿名用户에게 이름이 노출되는 것을 차단할 수 있을 것 같았습니다. 하지만 그러지 않다는 것을 깨달았습니다. (이미 우리는 이용약관(TOS)과 FAQ를 통해 그렇게 하겠다고 약속했습니다. )
단순히匿名用户에게만 전체 이름 접근을 거부하는 것만으로도 목적을 달성할 수 있습니다. 하지만 그룹 멤버십에 따라 접근 권한을 설정하는 것이 사실상 동일한 노력을 요하므로, 그렇게 하는 것이 낫다고 생각합니다. 이는 우리 사이트에서 >=TL1 이상의 접근 권한을 제한하는 가능성을 열어주며, 이는 더 좋습니다. (현재는 가입 시 초대장이 필요하지만, 이를 없애고 싶습니다.)
이 문제/주제를 조사하면서 "특정 그룹만 이름을 볼 수 있기를 원한다"와 같은 유사한 요청을 여러 번 보았습니다. 따라서 이 기능은 그러한 사용 사례도 처리할 수 있습니다.
여러분에게 드리는 질문입니다(제품 관련 질문으로 간주하셔도 됩니다!):
enable_names 설정은 “사용자에게 전체 이름을 표시하지 마세요.” 라는 의미인가요, 아니면 “이 사이트는 애초에 전체 이름을 사용하지 않습니다.” 라는 의미인가요?
(코드 자체와 이 주제/이슈와 같은 것들로부터) 이점에 대해 근본적인 명확성 부족이 있다는 느낌을 받습니다 — 어떤 분들은 한 가지 방식으로, 어떤 분들은 다른 방식으로 이해하고 있습니다.
이 스레드에 기여해 주신 모든 분께 감사드립니다. 이 문제가 향후 릴리스에서 해결될지, 아니면 최소한 알려진 회귀 문제로 인정될지 정중히 여쭤보고 싶습니다.
현재 enable names를 비활성화하면 의도하지 않은 방식으로 주요 관리자 기능이 중단됩니다. 또한 이것이 의도된 설계인지 버그인지에 대한 명확한 설명이 없어 대응 계획을 세우기 어렵습니다. 사용자 이름이 전체 이름보다 선호되는 프로덕션 사이트를 운영 중인 우리에게 이 제한은 실질적인 마찰과 예상치 못한 동작을 초래합니다.
우선순위를 고려해야 한다는 점은 이해하지만, 팀에서 이 문제가 인지되고 있는지 여부에 대한 업데이트를 주신다면 큰 도움이 될 것입니다. 미리 감사드리며, 가능한 한 많은 통찰을 주시면 감사하겠습니다.
이 PR은 후속 PR의 선행 조건으로, Guardian 인스턴스가 실제로 한 시리얼라이저에서 다음 시리얼라이저로 전달되도록 보장합니다. 자세한 내용은 PR/커밋 메시지에 있습니다. 다음 PR을 준비하는 동안 이 PR에 대한 논의를 시작해도 좋을 것 같습니다.
내 미니 GitHub 계정 모험
…글쎄요, 제가 여기서 수정 상자에 URL을 입력하기 전까지는 있었었는데 …그리고 나서 제 계정이 갑자기 정지되었습니다.
계정 복원 요청을 접수했으며, 업데이트가 있으면 이 곳에 알리겠습니다.
13시간 후, 기본적으로 "이런 일은 가끔 발생하니 지금은 괜찮다"는 내용의 이메일을 받았습니다. 매우 카프카식이었죠. 제 계정은 사이트에서 사라졌고 — 제가 수년 전 이슈/PR에 남겼던 게시물들까지 사라져서, 누군가(저)가 그곳에 있었다는 유일한 증거로 몇 개의 유령 같은 인용 블록만 남긴 채, 기묘한 일방적인 대화들이 남게 되었습니다.
정지된 계정뿐 아니라, 프로젝트들의 역사 일부가 조용히 지워지는 점까지 고려하면, 이는 매우 무겁고 과도한 대응으로 보입니다.
enable_names 설정이 실제로 무엇을 해야 하는지에 대해 여전히 근본적인 오해 또는 의견 차이가 있는 것 같습니다. 이는 다음 질문으로 귀결됩니다:
enable_names 설정은 다음 중 어떤 의미를 가질 의도인가요?
“전체 이름을 공개적으로 표시하지 않는다.”
“이 사이트는 아예 전체 이름을 사용하지 않는다.”
이 주제에 대한 일부 사람들은 (1)이라고 생각하고, 다른 사람들은 (2)이라고 생각합니다. 제 인상으로는 후자, 즉 enable_names가 사이트가 전체 이름을 아예 사용할지 여부를 결정한다는 것입니다.
enable_names가 꺼져 있을 때를 생각해 보세요:
가입 대화상자에 전체 이름 필드가 제공되지 않습니다.
사용자는 자신의 계정 설정 페이지에서 전체 이름 필드를 볼 수 없으며, 어디서든 자신의 전체 이름을 볼 수 없습니다.
관리자만, 그리고 관리자만이 시스템에 전체 이름 필드가 존재한다는 사실을 아는 사이트의 사용 사례를 이해할 수 없습니다. 제 상상력이 부족해서인지, 여기에서 실제로 그런 기능을 원하는 사람이 있는지 의심스럽습니다. 만약 그런 기능을 원하시는 분이 계시다면, 제발 알려주세요!
(제 초안 PR이 무엇을 이루려는 것인지, 어떻게, 그리고 왜 그런지에 대해서도 일부 오해가 있는 것 같습니다. 하지만 먼저 "enable_names가 실제로 무엇을 하는가?"라는 질문에 대해 다루고 싶었습니다.)
네, 수많은 예를 들 수 있습니다. 커뮤니티를 소유한 기업은 고객들의 이름을 알릴 법적 권리(및/또는 필요성)가 있는 경우가 많지만, 개인정보 보호법은 그 이름들을 제3자에게 공개하는 것을 금지합니다. 대량 이메일에서 CC를 사용하는 것이 금기인 것과 거의 같은 이유이며, BCC를 사용해야 하는 것과도 같습니다.
글쎄요, 이것은 단순히 동작이 이상했던 꽤 단순한 버그 보고서로 시작되었습니다. 그리고 나서 우리는 그것이 무엇을 해야 하는지에 대한 논쟁으로 빠져들었고, 그로 인해 많은 혼란과 추가적인 논의가 발생했습니다. 그것은 괜찮지만, Contribute > Feature 주제에서 다루는 것이 더 나았을 것입니다.
1번입니다. 해당 설정의 설명은 다음과 같습니다:
사용자의 이름(실명)을 프로필, 사용자 카드 및 이메일에 표시합니다. 이름(실명)을 모든 곳에서 숨기려면 비활성화하십시오.
이름(실명)이 숨겨진다는 사실은 그것이 존재함을 의미하며, 관리자는 숨겨진 것을 볼 수 있습니다.
또한 display_name_on_posts, full_name_requirement 및 display_name_on_email_from도 있습니다.
2번을 원하신다면, full_name_requirement를 기반으로 하여 거기에 ‘Never’(절대) 옵션을 추가하는 것이 더 합리적일 것 같습니다.
(그리고 네, enable_names가 다른 이름으로 불려야 한다는 데 동의합니다. 하지만 설정 이름을 변경하는 일은 결코 쉽지 않습니다). 그리고 또한
이 수정으로 원래 기능이 복원될까요? 즉, 관리자와 사용자가 자신의 전체 이름을 볼 수 있게 되는 건가요? 이 변경 사항이 원래 기능에 비해 처음부터 많은 문제를 일으킨 것 같습니다. 일부 상황에서는 실명 확인이 필요하거나 바람직할 수 있으므로, 전체 권한을 가진 모더레이터(full moderator)에게도 설정을 통해 실명을 볼 수 있는 옵션이 제공되어야 합니다.
팀이 이 변경 사항을 적용한 후, 실명을 입력했던 모든 사용자의 이름이 공란으로 변했습니다.
개인적으로 이 설정은 명확한 정의가 있는 두 개의 설정으로 분리되어야 한다고 생각합니다. 이름 비활성화라는 새로운 기능은 실명을 끄는 별도의 새로운 설정이어야 합니다.
저는 작은 커뮤니티를 운영하고 있어 다행입니다. 수천 명의 회원이 있는 사이트에서 그들의 실명이 공란으로 변한다면 상상조차 하기 싫습니다.
)
)
