類似している点は理解できますが、他の議論にはここでの問題に関連する問題があります。
ただし、管理者である場合、通常はアクセスできない機密性の高い会話へのリンクが実際には制限されていることを確認する方法がありません。これは、管理者の役割と参加者の役割が分離されていないことが問題となる可能性のあるケースの 1 つ です（昨日私たちに起こり、このトピックを開始するきっかけとなったものです）。
さらに、Discourse チームは全員が管理者であるという習慣があり、これは水平的な超能力であり、文化として通常の利用と特権的な利用を区別するのに役立ちません。すべてのコミュニティが水平的であるわけではありません。場合によっては、管理者権限を持つ技術担当者はフォーラムのすべてを信頼されるべきではなく、これは例外的なケースではありません。コンピューターシステムは、root がすべてを見たり行ったりできるという形で、最初から構築されてきました。特権には確かに責任が伴いますが、時には善意だけでは不十分です。特に、正常な場合と制限されている場合を区別できない場合はなおさらです。
通常の管理者アカウントと管理者アカウントを処理するための「別のブラウザープロファイルを使用する」という解決策は、特にツールをすぐに使える状態にしておくことに慣れている場合、あまり実用的ではありません。管理者機能が必要になるたびに新しいブラウザーを起動するのは非常に迷惑です（誰もが自分のマシンでアイドル状態のリソースを消費することを好むわけでも、許容できるわけでもありません）。また、詮索好きな目の特権的な [abbr title=“Bastard Operator From Hell”]BOFH[/abbr] 状況が発生するのを防ぐこともできません。
時代は変わりました。ここでは、管理者が機密情報に誤ってアクセスし、他の人々の生活に影響を与えたケースがありましたが、それは本来アクセスすべきではありませんでした。これはプライバシー侵害です。セキュリティの問題です。
潜在的な複雑さは理解していますが、根本的な問題は残っており、何らかの方法で解決されるべきです。私の意見では、コードベースが成熟した今、この問題を再検討し、提案されたアプローチが実行可能かどうかを評価することは有益でしょう。
はい！この種の（立ち入り禁止）問題に関する警告とガードがあると役立ちます。
既存のプラグインについて：
- GitHub - discourse/discourse-anonymous-moderators は役立つかもしれませんが、電子メールを処理する最近の変更（https://meta.discourse.org/t/enabling-e-mail-normalization-by-default/338641）により、デフォルト設定に依存しないことが問題になる可能性があります。
- GitHub - discourse/discourse-staff-alias: Allow staff users to post under an alias は 投稿 に限定されています。
上記すべての理由から、古典的でよく知られた sudo の比喩を使用して、参加者と管理者の間に本当にクリーンな分離を設けたいと考えています。