事前に設定された「サイトフィードバック」カテゴリを編集する際、セキュリティタブに警告が表示されます。
警告: このカテゴリは事前に設定されたカテゴリであり、セキュリティ設定は編集できません。このカテゴリを使用しない場合は、再利用するのではなく削除してください。
スタッフカテゴリのセキュリティルールがロックされているのには、おそらく合理的な理由があることは理解できます。しかし、同様に事前に設定された「ラウンジ」カテゴリのセキュリティルールはロックされていません。「サイトフィードバック」カテゴリも「ラウンジ」と同様に、セキュリティルールを編集可能にすべきだと考えています。
「サイトフィードバック」カテゴリのセキュリティ設定を編集できることで、何か有害な影響があるのかどうかはわかりません。他のカテゴリオプションはすべてロックされていないようです。
このカテゴリを異なるセキュリティ設定に移行しようとしています。1〜2回のクリックで簡単に設定を変更できる方法があれば幸いです。
全員が… 作成 / 返信 / 閲覧
ラウンジは、TL3 に達したユーザーのみがアクセスできるように設定されています。ラウンジは、コミュニティに積極的に参加しているユーザーへの「特典」や「報酬」という側面を持っています。もしこの種のカテゴリへのアクセス条件を変更したいのであれば、なぜご希望のセキュリティ設定で新しいカテゴリを作成しないのでしょうか？
サイトフィードバックについてですが、ユーザーが新規で高い TL に達していないからといって、コミュニティに有益な提案ができないとお考えですか？それは「新規ユーザーの意見は聞きたくない」と言っているようなものです 
試したことはありませんが、ご希望のセキュリティ設定で新しいカテゴリを作成し、すべての投稿をそのカテゴリに移動させた後、元のカテゴリを削除することは可能かもしれません。ただし、site-feedback とは異なる名前にすることを忘れないでください。
これは以前も議論された話題です（事前設定されたカテゴリのセキュリティ設定を変更しようとする試み）。であれば、なぜ要件に合わせた新しいカテゴリを作成し、事前設定されたカテゴリを削除しないのでしょうか？
ええ、@JimPas さんのご指摘はもっともです。確かに削除して再作成するという解決策もあります。これは大きな問題ではないと思いますが、そのカテゴリのセキュリティ設定を編集できるようにするのが、より理想的なデフォルト設定だと考えます。
多くの場合、新規ユーザーがフィードバックを投稿できるようにすることは望ましいでしょう。ただ、すべてのコミュニティにおいて、そのカテゴリのセキュリティ設定がデフォルトでロックされている状態でリリースするのは、少し意見が偏りすぎているように感じます。柔軟性を制限してロックすることによるメリットはあまり見当たりません。
より具体的な理由をいくつか挙げます。
セキュリティロックの理由の一つは、少なくとも表示されるメッセージによると、カテゴリの用途変更を防ぐことです。しかし、管理者はカテゴリ名やスラッグを自由に変更できます。もしかすると無自覚に、セキュリティ設定の編集はできないものの、望むようにカテゴリの用途を変更してしまうかもしれません。
一部の管理者は、ログインしていないユーザーやウェブクローラーにはサイトフィードバックカテゴリを非表示にしつつ、ログインしているすべてのユーザー（新規ユーザーを含む）には表示してフィードバックを投稿できるようにしたいと考えるかもしれません。
場合によっては、管理者がサイトフィードバックのサブカテゴリをより具体的なものとして作成し、親カテゴリでの投稿を禁止することで、ユーザーが適切なサブカテゴリを選択してフィードバックを投稿し、トピックの整理を改善したいと考えることがあります。セキュリティ設定を編集しない限り、これは可能ではないと考えています。
管理者はカテゴリを削除して新しいものを作成することで回避策とすることもできます。しかし、すでに運用されているフォーラムにとっては理想的ではないかもしれません。新しいカテゴリは異なる ID と URL を持つため、そのカテゴリへの静的な既存リンクや外部リンクが破綻します。とはいえ、パーマリンクオプションを使用して、古いカテゴリをリダイレクトする回避策をとることも可能です。
まさにその通りです。私たちの Discourse での開発はここ数ヶ月非常に活発でしたが、今では本来の目的（メーリングリストの代替）として利用しようとする人が増えています。フォーラムのセットアップや保守に関する解決済みの投稿が多数あり、一般のユーザーはそれらには全く関心を持っていません。
当フォーラムでは、未分類のメインカテゴリを設け、フィードバックを寄せたい場合は @staff とメンションするよう全ユーザーに促しています。新しいトピックを作成しようとする際に表示される説明文にもこれを明記しています。また、「フォーラムの問題をここに報告してください」という専用のトピックも設けており、スレッド内でリクエストされた機能の更新や追加状況をお知らせするとともに、ユーザーからの意見も歓迎しています。
その通りです。これはデータへのアクセスを制限する問題ではありません。私の家に来た際、建築図面や請求書を床やテーブルに散らばらせておくことはしません。もし誰かがそれらを望むなら、スタッフグループなどを通じて別の方法で入手すればよいでしょう。ユーザーはオプトアウトと同様に、オプトインをより自動的に行える仕組みがあります。
これは日常の利用と、実験的な機能を積極的にテストしたい人たちの間のバランスの問題です。
当フォーラムではそのようなことはありません。むしろ、「コミュニティのユーザーが実際に物事を進めようとしている際、いつまで足場を隠し、大規模な建設作業の可視性を制限すべきか」という点です。
当フォーラムでは、「サイトフィードバック」というカテゴリと「META」というカテゴリの両方があります。
META カテゴリでは、ユーザーが直面する具体的な問題について新しいトピックを作成できます。問題が解決すると、そのトピックは「解決済み」としてマークされます。「サイトフィードバック」カテゴリは、作成当初の状態のままです。ただし、当フォーラムは、現在活動していない別のフォーラムから7年以上知り合いである小規模なコミュニティであることを付記しておきます。
私のフォーラムでは以下のようになっています：
About カテゴリ（以前は Meta という名称でした）。同じ名前のグループが存在するため、混乱を避けるためにそのグループにこのカテゴリ名を割り当てました。大きな問題ではありませんが、ログインしていない人からはこの About カテゴリを非表示にしたいと考えています。また、単純な公開グループに限定することも検討に値するかもしれません。Staff カテゴリ：フォーラムを混乱させたくない、ランダムな統合や技術的な投稿用です。Staff Notes 機能は試していないため、このカテゴリがその役割を担っています。ほとんどの議論が、デフォルトの議論場所である uncategorized で行われていることに気づきました。タグは非常に好評ですが、誰でも自由にタグを作成できるようにしすぎたかもしれません。
これが私の主な理由です。ログインしていない人たちは、フォーラムの構成にはあまり関心がないでしょう。彼らが求めているのは、一般的な議論などを見ることです。
サイトのフィードバックカテゴリからの投稿を受け取りたくないユーザーは、いつでも設定でそのカテゴリをミュートできます。これにより、そのカテゴリからの不要な投稿や、カテゴリ全体が「最新」に表示されるのを防ぐことができます。もし時折確認したい場合は、カテゴリ一覧を下にスクロールしてそこからアクセスすることも可能です。
しかし、これは @markersocial さんの当初の質問（Site Feedback カテゴリのセキュリティルールの変更を許可すること）から少し脱線し始めているかもしれません。
（カテゴリのさまざまな用途についての議論を続けるのも素晴らしいことだとは思いますが。）
なぜユーザーは、特定のフィードバックに特化した新しいトピックを Site Feedback カテゴリ内で作成できないのでしょうか？私たちの Site Feedback カテゴリには、ユーザーによって作成された複数のトピックがあります。それはどちらかといえば「提案箱」や質問の場です。ユーザーが問題に直面した際は、適切に「メタ」と題されたトラブルシューティングカテゴリに投稿します。
ご提案の理由に対する簡単な解決策としては、以下のような手順が考えられます。
ただし…その設定をすると、サブカテゴリへの投稿も禁止されてしまうのでしょうか？
私は試したことがありません。興味深い実験のようですが、すぐに寝る時間になってしまいました。明日やってみるかもしれません。あるいは、これが機能するかどうかを説明してくれるチームメンバーがここに現れるかもしれませんね。
@JimPas さん、ありがとうございます
私が考えるに、主な質問はこれです：すべてのインストールにおいて、事前設定されたサイトフィードバックカテゴリのセキュリティ設定をロックすることの利点は何でしょうか？
それによる利点は思い当たりません。削除してもデメリットがないため、少し不要な障壁のように思えます。新規インストールではデフォルトで推奨されるセキュリティ設定が適用されつつ、それ以外のユースケースに対して柔軟性を許容する形が理想的です。Lounge の事前設定カテゴリと同じような仕組みですね。
大きな問題ではありません。あなたが提案された通り、カテゴリを削除して再作成することで回避策があるためです 。ただし、フォーラムが成長するにつれて後からこれらを変更したい場合、カテゴリの URL が変更されてしまうため、少し洗練されていない印象を与えます（この問題は、管理画面 > カスタマイズ > パーマリンクで対応可能です）。
その通りです。ユーザーはサイトフィードバックカテゴリ内に、自分のフィードバックに特化したトピックを作成できます。ただし、特定のユースケースでは、各トピックに対してサブカテゴリの使用を強制することが役立つかもしれません。特に、フォーラムが多様なブランドの一部であり、複数のユーザー向けサイト、アプリ、製品を持っている場合などです。
いくつかの例（ただし、サブカテゴリの使用を強制しているわけではありません）：
https://community.cloudflare.com/c/feedback/25
フィードバックの内容は、企業の主要製品やその特定の分類された側面に関するものもあれば、フォーラム自体に関するものもあります。このフォーラム自体にも、ブログ用の site-feedback サブカテゴリ があり、これには異なるタググループが割り当てられています。
これについてですが、以前に一部のカテゴリでこの設定を使用したことがあります（親カテゴリへの投稿を禁止し、そのサブカテゴリへの投稿は許可する）。サブカテゴリのセキュリティルールは、親カテゴリのセキュリティルールに影響されません。したがって、確かにこれは解決策となります 。
ありがとうございます。それを調べる手間が省けました。今日は3歳の孫娘が突然訪ねてきて、「おじいちゃんと遊びたい」というだけで、予期せぬことに約5時間を費やしてしまいました。
さて、やっと自分のフォーラムをチェックできます。
これは技術的な制限に対する回避策として存在しています。Discourse 側がデフォルト設定を更新したり、カテゴリの翻訳名を変更したりした場合、もし人々がこの事前設定されたカテゴリを「通常」のカテゴリとして再利用していたら、ある日突然それが変更されてしまい、大混乱を招くことになります。（はい、実際にそのようなことがありました。そのため、この制限が設けられています。）
セキュリティ設定の変更を禁止することで、それが特別であり、デフォルト設定の更新対象であることを思い出させる役割を果たしています。
このカテゴリを特別なものにしているのは自動更新機能だけであるため、ヘルプテキストでは、再利用するのではなく、カテゴリを完全に削除して新しく作成するよう案内しています。
なるほど、ご説明ありがとうございます @riking。
カテゴリの流用が非常に有害である場合（私はそれを推奨していませんが）、カテゴリ名変更の設定に警告を表示する方が現実的かもしれませんね。セキュリティルールは、そうした潜在的な問題と直接的に強く関連しているようには見えません。
いくつかの点を挙げさせていただきます：
私の知る限り、lounge は通常のカテゴリであり、ACL と信頼レベルに基づくアクセス権の例を示しているだけでしょ？
@Stephen - ‘site_settings’ テーブルで postgres 内に「lounge」カテゴリが参照されているのが見えます。それがどれほど意味があるかは完全に確信できませんが、おそらく同様に処理されているのでしょう。テストインスタンスで ‘meta_category_id’（サイトフィードバックカテゴリ）をいじったところ、再構築時にサイトフィードバックカテゴリに影響が出ました。
@markersocial 個別のトピックを一つずつ移動させる方法以外に、約100以上のトピックをプリシード済みから新しいカスタムカテゴリへ移行するための推奨方法はありますか？
@sunjam 以下に解決策を提示します：Bulk move many topics from one category to another - #2
さっそくテスト環境で試してみましたが、問題なく動作しました。ただし、話題の数が少ない場合のみです。
サーバーに SSH で接続し、以下のコマンドを実行してください（この例ではカテゴリ 2 のすべての話題をカテゴリ 1 に移動させるため、必要に応じて数値を書き換えてください）：
cd /var/discourse
./launcher enter app
rails c
Topic.where(category_id: 2).update_all(category_id: 1)
カテゴリ ID は、カテゴリ URL の末尾にある数値から確認できます。
追記：唯一の問題点は、「このカテゴリについて」の投稿も移動されてしまい、管理画面から元に戻したり削除したりできないようです。非公開リストにすることはできますが、それが問題を引き起こすかどうかは不明です。少しお待ちください、すぐに更新します。
追記 2：「このカテゴリについて」の話題を正しいカテゴリに戻すには、以下のコマンドを使用してください（話題 ID が 1 で、移動先のカテゴリ ID が 2 の場合）。さっそく試しましたが、問題なく動作しました：
Topic.where(id: 1).update_all(category_id: 2)
話題 ID は、カテゴリ ID と同様に、話題 URL の末尾から確認できます。