아니요, 그렇지 않았습니다. 내부와 외부에서, 그리고 코드베이스 전체에서 이 문제가 반복적으로 제기되어 왔습니다.
카테고리 부분은 아직 다루지 않았으며, 여기서는 아무것도 변경되지 않았습니다.
더 나은 표현 방법이 없었기 때문에 사람들이 '모든 로그인한 사용자’를 의미할 때 TL0을 압도적으로 많이 사용했습니다. logged_in_users 그룹은 적어도 그것이 무엇을 포함하는지 완전히 명확하며, 여전히 TL0/TL1 등을 사용하는 것을 막는 것은 전혀 없습니다. 제거되는 그룹은 everyone 하나뿐입니다.
네, 맞습니다. 저는 모든 것을 "변화를 위한 변화"로만 하고 있습니다 
잠시 말투를 돌아봐 주세요. 우리는 여기서 이유 없이 전혀 불필요한 일을 하는 습관이 없습니다. 이 작업은 몇 달 동안 진행되어 왔으며 방향이 바뀌는 것은 아닙니다.
음, 제가 이 변경 사항을 오해하고 있는 건가요?
제안 내용이 다음과 같은 자동 그룹을 도입하는 것이라면:
그건 괜찮아 보이고, 이름만 봐도 용도가 명확합니다.
(사실 꽤 마음에 듭니다! )
하지만 제안 내용이 결국 다음을 제거하는 것이라면:
그건 제게는 이해가 가지 않습니다. everyone은 접근 권한의 임계값을 나타내는 자동 그룹들의 일부이기 때문입니다. 그 그룹에는 다음도 포함됩니다:
등등.
이들은 모두 everyone을 포함하여 접근 권한의 임계값을 나타냅니다.
everyone 그룹은 즉 "trust_level_none"입니다.
이는 공개 접근(public access)을 간결하게 표현하는 방법입니다.
현재로서는 카테고리 권한에서 이를 제거할 의도가 없다는 점은 이해합니다() 하지만 개인적으로는 이 자동 그룹을 유지하겠다는 확약이 있었으면 합니다. 적어도 제게는 이게 훨씬 합리적이기 때문입니다.
그렇다면 왜 이 자동 신뢰 수준(trust level) 그룹처럼 다른 곳에서도 사용할 수 있게 하지 않을까요?
그렇지 않으면 "공개 접근"을 표현해야 하는 모든 곳에서 두 개의 그룹을 추가해야 하는데, 이는 불필요한 복잡성으로 보입니다?
"everyone"을 “가려내기(mask out)” 위한 로직을 추가하는 데 왜 애를 쓸까요?
혹시 더 나은 이름이 있다면 "everyone"이라는 이름을 재고하되, 그 의미와 기능, 그리고 플랫폼 전반에서의 가용성은 유지하는 것이 또 다른 대안이 될 수 있습니다. 그러면 모든 사람(숨)이 만족할까요?
여기서 구분할 점은 '공개 액세스’를 선택할 수 있는 편리한 방법을 유지하는 것과 기존 everyone 그룹을 유지하는 것 사이입니다. 공개 액세스를 원할 때마다 두 개의 그룹을 매번 선택해야 하는 것은 더 번거롭다는 데 동의하며, 이는 UI를 통해 개선할 수 있습니다.
예를 들어, 그룹 선택기에 ‘공개’ 단축키를 추가하여 anonymous_users와 logged_in_users를 한 번의 작업으로 모두 선택하도록 할 수 있습니다. 그러면 두 그룹이 모두 선택된 상태로 표시되며, 원하면 어느 하나를 제거할 수 있습니다. 이렇게 하면 여러분이 설명한 편의성을 제공하면서도 하위 권한은 명시적으로 유지할 수 있습니다. 이 단축키는 두 그룹이 모두 허용되는 곳에서만 제공될 것입니다.
기존 everyone 그룹을 유지하는 문제는 그것이 일관되게 '공개 액세스’를 의미하지 않았다는 것입니다. 카테고리 가시성의 경우 그러하지만, 대부분의 그룹 기반 사이트 설정에서는 사실상 '로그인된 모든 사용자’를 의미해 왔습니다. 또한 위의 논의에서 보았듯이 테마와 플러그인도 이를 다르게 해석하고 있습니다.
따라서 이전에는 존재하지 않았던 액세스 권한을 부여할 위험이 있으므로, 모든 곳에서 익명 사용자를 포함한다고 선언하면서 그대로 유지할 수 없습니다. 기존 동작을 유지하면 일관성 부족이 남게 되며, 이름을 변경하는 것만으로는 이를 해결할 수 없습니다.
일관되게 정의된 범용 그룹을 만드는 것은 가능하지만, 현재 진행 중인 마이그레이션 및 감사 작업이 여전히 필요합니다. 또한 익명 액세스가 지원되지 않는 곳에서는 이를 허용하지 않도록 해야 하며, 그렇지 않으면 해당 위치에서 다시 'everyone’이 '로그인된 사용자만’을 의미하게 됩니다. 이전에는 everyone이 허용되던 설정들에 anonymous_users를 disallowed_groups 값으로 추가해야 했던 경우가 매우 많습니다. 예를 들어:
저는 관리자 및 개발자를 위해 모든 곳에서 일관성을 확보하기 위해, 내부적으로는 두 개의 명시적인 그룹을 사용하면서 UI에서 그 편의성을 제공하는 방식을 선호합니다.
모든 것이 매우 명시적이라는 점은 좋지만, 저에게는 불필요한 복잡성처럼 느껴집니다. 그래도 편의성이 유지된 점은 감사하게 생각합니다.
제 생각에는 문제가 바로 거기에 있는 것이지, 원래의 “everyone” 카테고리 개념에는 없는 것 같습니다.
“everyone” 그룹과 기본 카테고리 시스템에서의 사용은 2013년부터 존재해 왔습니다.
설정 시스템이 이 계약을 벗어나 깨뜨렸다면, 이는 설정 시스템 개발 과정에서 발생한 문제 아닙니까?
제 생각에는 구현 단계로 직행하는 것처럼 보이는 지금, 커뮤니티가 아이디어를 기여할 수 있도록 RFC를 먼저 마련하는 것이 좋았을 것 같습니다.
무언가를 놓쳤다면 죄송합니다 …
네, 사이트 설정의 일관성 부족이 문제의 일부라는 데 동의합니다. 하지만 그것을 수정한다고 해서 반드시 사이트 설정에서 기존 everyone 그룹을 계속 사용해야 한다는 의미는 아닙니다.
2013년에 제기된 논거는 everyone이 카테고리 권한에 대해 얼마나 오래 존재해 왔는지를 보여주는 것 이상을 우리에게 알려주지 않습니다. 2013년 이후 Discourse에서는 많은 것이 변했습니다. 예를 들어, 많은 사이트 설정이 원래 신뢰 수준(trust level) 기반으로 작동했지만, 이제는 그룹 기반으로 작동합니다. 그 맥락에서 그것이 합리적이라는 데에 이의를 제기하는 사람은 없습니다. 또한 카테고리 권한은 이 작업으로 인해 변경되지 않았습니다(적어도 당분간은요). everyone의 오래된 존재는 Discourse의 나머지 부분에서 일관된 의미를 가졌음을 입증하지도 않으며, 영원히 유지해야 한다고 주장하는 근거도 되지 않습니다.
원래 의미에서 벗어난 모든 것이 실수였다고 동의하더라도, 기존 사이트에서 해당 설정이 실제로 어떻게 작동하는지를 처리해야 합니다. 원래 카테고리 동작과 더 잘 일치시키기 위해 해석을 변경하여 익명 사용자를 포함하는 것은 안전하지 않습니다. 위에서 설명했듯이, 일관된 의미를 가진 범용 그룹을 유지하려면 여전히 해당 사용 사례를 감사하고 마이그레이션해야 합니다. 이는 대안적인 설계이지만, 이 작업의 어려운 부분을 피할 수는 없습니다.
RFC(기능 요구 사양) 문제에 관해 말하자면, 이러한 변경 사항을 수행하기 전에 커뮤니티 RFC를 거치는 것은 느리고 과도한 부담이 될 것입니다. 물론 피드백은 환영하며, 바로 다가올 변경 시스템(change system)이 그 역할을 할 것입니다. 이 주제에서는 이미 Moin의 예시를 통해 여러 개선 사항이 도출되었고, 저는 처음에 놓쳤던 테마/컴포넌트 사례를 인정하고 그것들도 수정했습니다.
이 변경 사항에 대한 구체적인 문제를 계속 논의하는 데는 기꺼이 참여하겠지만, 저는 여전히 명시적인 두 그룹으로 진행할 것입니다. UI에서 공개 액세스를 선택하기 쉽게 만드는 것은 추가 클릭을 줄이는 합리적인 방법이라고 생각하지만, 지금 당장 구현해야 할 필수 사항은 아니라고 봅니다.
어쨌든, 세밀한 익명 및 로그인 사용자 그룹 권한을 위한 안정화, 그리고 영구화를 향한 길에서 이 작업에 대해 여전히 많은 항목을 추적하고 있으므로, 상당한 시간이 걸릴 것입니다. 카테고리 시스템과 관련된 변경도 마찬가지입니다. 카테고리 시스템은 당분간 everyone을 유지할 것입니다. 카테고리 시스템은 kanban이 이미 사용 중인, ACL(액세스 제어 목록)이라고 부르는 시스템으로 전환될 가능성이 높습니다:
