いいえ、そうではなかったのです。社内外を問わず、またコードベース全体でも、繰り返しこの問題が発生してきたのを目の当たりにしてきました。
まだカテゴリについては手がけておらず、ここでは何も変更されていません。
より良い表現方法がなかったため、人々は圧倒的にTL0を「すべてのログイン済みユーザー」を意味するために使用していました。logged_in_usersグループは少なくともそれが何を意味するかが完全に明確であり、引き続きTL0/TL1などを使用することに何の支障もありません。削除されるグループはeveryoneだけです。
はい、確かに私は「変化のためだけに」これらすべてを行っています 
一瞬でも言葉遣いを考えてみてください。私たちはここでは、何の理由もなく完全に不要なことをする習慣はありません。この作業は数ヶ月にわたり継続的に行われており、方向性は変わりません。
うーん、もしかしたら私の変更内容の理解が間違っているのかもしれない。
提案が以下を自動グループとして導入することであれば：
それは問題ないですし、意味も自明です。
（実際、私はその案をかなり気に入っています！ ）
しかし、提案が最終的に以下を削除することである場合：
私には意味がわかりません。everyoneは、アクセス権限の閾値を表す自動グループのセットの一部であり、そこには以下も含まれています：
など。
それらはすべてアクセス権限の閾値を表しており、everyoneも同様です。
everyoneグループは「trust_level_none」とも呼ばれます。
これは、パブリックアクセスを簡潔に表現する方法です。
現時点ではカテゴリ権限から削除する提案ではないことは理解しています（）が、少なくとも私にとっては意味が通じるため、この自動グループを維持する方針を明確にしてもらいたいと個人的には考えています。
それなら、他の自動信頼レベルグループと同様に、他の場所でも使用できるようにするのはどうでしょうか？
そうしないと、「パブリックアクセス」を表現する必要があるあらゆる場所で、2つのグループを追加する必要が生じ、意味のない複雑さになりませんか？
なぜ「everyone」を「マスクアウト（無効化）」するロジックを追加する必要があるのでしょうか？
もしより良い名前が存在するなら「everyone」という名前を見直すという別のアプローチも考えられますが、その意味と機能、そしてプラットフォーム全体での利用可能性は維持し、その上で全員（咳）が満足すればよいのではないでしょうか？
ここで重要なのは、「パブリックアクセス」を選択するための便利な手段を残すことと、既存の everyone グループを残すことの区別だと思います。パブリックアクセスを許可するたびに2つのグループを選択するのは面倒だと私も同意しますし、UIで改善することは可能です。
例えば、グループ選択ツールに「パブリック」のショートカットを追加し、1つの操作で anonymous_users と logged_in_users の両方を選択できるようにできます。そうすれば、両方のグループが選択されていることが視覚的に確認でき、どちらかを削除することも可能です。これにより、あなたが説明しているような利便性を提供しつつ、基礎となる権限設定を明示的に保つことができます。このショートカットは、両方のグループが許可されている場所でのみ提供されます。
既存の everyone グループを残すことの問題は、それが常に「パブリックアクセス」を意味してこなかったことです。カテゴリの表示設定ではそうなりますが、ほとんどのグループベースのサイト設定では、実質的に「ログイン済みの全ユーザー」を意味してきました。上記の議論でも示されたように、テーマやプラグインによって解釈が異なる場合もあります。
したがって、匿名ユーザーを含むと宣言するだけで、以前は存在しなかったアクセスを誤って付与してしまうリスクを伴います。既存の動作を維持すれば不整合が残り、名前を変更してもそれは解決されません。
一貫して定義されたユニバーサルグループを作ることは可能ですが、それでも現在行っているマイグレーションと監査が必要です。また、匿名アクセスがサポートされていない場所では使用を禁止する必要があります。そうしないと、これらの場所では everyone が再び「ログイン済みユーザーのみ」を意味することになります。以前は everyone が許可されていた設定に、anonymous_users を disallowed_groups の値として追加しなければならないものがたくさんあります。例えば：
私は、UI上でその利便性を提供し、その下では2つの明示的なグループを使用するアプローチを好みます。そうすることで、管理者と開発者の両者にとって、どこでも一貫性を持たせることができます。
全員が非常に明示的になっているようですが、私にはこれが不要な煩雑さに見えます。ただし、利便性が保たれている点は評価しています。
私の意見では、問題はそこにあるのであり、元の「everyone」カテゴリの概念にあるのではありません。
「everyone」グループとその根本的なカテゴリシステムでの使用は、2013年頃から存在しています。
もし設定システムがこれと乖離し、この契約を壊したのであれば、それは設定システムに関する作業の問題ではないでしょうか。
私の意見では、コミュニティがアイデアを提供できるようなRFCを、実装に一直線に進む前に用意してほしかったと思います。
何か見落としている点があれば、お詫び申し上げます……
うん、サイト設定の不整合が問題の一部である点には同意する。ただし、それを修正するということは、サイト設定で既存の everyone グループを使い続けることを必ずしも意味しない。
2013年の議論は、everyone がカテゴリ権限のために存在してきた期間の長さについてしか教えてくれない。2013年以降、Discourseは大きく変わっており、例えば多くのサイト設定が以前は信頼レベル（Trust Level）に基づいていたものが、今はグループに基づいている。その文脈でそれが合理的であることに異を唱える人はいないし、今回の作業ではカテゴリ権限は変更されていない（少なくとも現時点では）。everyone の年齢（存在期間）は、Discourseの他の部分で一貫した意味を持っていることを示すものでもなければ、それを永遠に維持すべきだということを示すものでもない。
たとえ元の意味からのすべての逸脱がミスだったと同意したとしても、既存のサイトでそれらの設定が実際にどのように動作しているかに対応しなければならない。元のカテゴリの動作によりよく一致させるために匿名ユーザーを含む解釈に変更することは、安全に行えない。上で説明したように、一貫した意味を持つユニバーサルなグループを維持するには、それらの使用箇所を監査し、移行する必要がある。それは代替の設計ではあるが、この作業の難しい部分を回避するものではない。
RFCの点についてだが、このような変更を行う前にコミュニティのRFCを行うのは遅く、現実的ではない。ただし、フィードバックは歓迎される。それがまさに、間もなく導入される変更システム（change system）の役割だからだ。このトピックはすでにMoinの例からいくつかの改善につながっており、私は当初見落としていたテーマ/コンポーネントのケースを認め、修正も行った。
変更に関する具体的な問題については、引き続き検討していく用意があるが、私は2つの明示的なグループで進めていくつもりだ。UIでパブリックアクセスを選択しやすくすることは、余計なクリックを減らすための合理的な方法だと思うが、今この瞬間に実装する必要があるとは考えていない。
いずれにせよ、The road to stable, then permanent, for granular_anonymous_and_logged_in_groups_permissions に追跡されている大量の作業があるため、これはまだ先のことになる。カテゴリシステムに関する変更も同様で、当面は everyone を維持している。カテゴリは、カンバンがすでに使用しているACL（アクセス制御リスト）と呼ばれるシステムに移行する可能性が高い：
