私たちのコミュニティでは、クローズドコミュニティとし、ユーザーの承認をスタッフが行う必要があると決定しました。そのため、「ユーザーの承認を必須にする」機能を有効にしました。機能は動作していますが、承認の審査に時間がかかりすぎています。
既存のメンバーが承認リクエストに投票して審査できれば理想的です。その後、投票期間が経過すればユーザーが自動的に承認されるようにするか、スタッフが投票を確認して迅速に対応できるようにするのが良いでしょう。現在、私は信頼レベル2のユーザーがリクエストを審査できるカテゴリに手動でトピックを作成し、そのトピックに審査ページのスクリーンショット（Inspect Elementを使用してユーザーのメールアドレスを非表示にした後）を手動で追加しています。これがDiscourseの機能として組み込まれると素晴らしいのですが。
「ユーザーを承認必須」にする代わりに、「招待のみ」にして、他の人を招待できるようにすべきです。
私が好きかどうか、あるいは他の誰かが好きかどうかはわかりません…
このプロセスは、ユーザーを承認ボタンを押すよりも時間がかかります 
これは、現状において既存のメンバーがコミュニティへの新規加入を決定すべきだと考えているためです。これは、あるユーザーの意見（つまり招待）やスタッフの承認のみに基づいて決定されるべきではありません。誰がコミュニティの新規メンバーになるのか、既存のメンバーが認識し、ある程度の管理権を持つべきです。
この種の参入障壁は Discourse コアには含めるべきではありません。ご要望の機能は、何らかのカスタムプラグインとして実装する必要があります。予算がある場合は、Marketplace に投稿してください。
ええ、その意見に賛成です。特定のユースケースが全員に適合するとは限りません。しかし、クローズドコミュニティが既存メンバーの過半数の承認を得たメンバーを受け入れることは適切ではないでしょうか？まずは、私がポールの機能を使って実施している独自の手動ソリューションで試してみて、その結果を見てみましょう。
これは私には全く理解できません。もしそれが閉じたコミュニティなら、民主主義は必要ありません。もし民主主義なら、ロックされていたり閉鎖されていたりする必然性はありません。あなたがここで目指そうとしているのは、非効率的で遅い、過度に複雑なシステムです。
もし私があなたの立場なら、個人としてユーザーの承認または却下を行う権限を持つ人々のグループ（できれば選挙または任命によって選ばれた人々）を設けるでしょう。
「グローバル民主主義」というものは存在しません。特定の国の市民権を持つ人々が投票権を持ち、その国の民主主義システムに参加するだけです。私はインドの市民なので、アメリカで投票することはできません。アメリカが民主主義システムを持つことは完全に理にかなっています。そして、そこで投票するには市民権を申請する必要があり、その当局（私たちの比喩で言えば「スタッフユーザー」）が私の申請を受け入れるか拒否するかを決めます。これがDiscourseの承認システムが機能する仕組みです。招待システムは、例えばアメリカが世界中の著名人や有用な人を招待して参加させる必要がある場合に機能します。つまり、私のケースでは承認システムが機能しますが、それは民主的ではありません。なぜなら、誰を受け入れ誰を拒否するかを決めるプロセス自体が民主的ではないからです。さらに、スタッフが受け入れや拒否の判断を十分に理解していない場合さえあります。
私の比喩がご理解いただけたことを願っています。それに、技術的な制約に縛られているわけではありません。ユーザーが承認または拒否された後、データベースをクリアすることも可能です。ユーザーが投票で勝利した場合のみ承認され、このプロセスは自動化されており、スタッフの介入は全く不要です。投票できるのはTL2以上のユーザーに限られます。
いずれにせよ、私のユースケースがすべての状況に適しているわけではありません。また、これは複雑な設定であることに同意します。ほとんどのシナリオでは、私が提案したように招待限定の設定やスタッフによる承認を採用するでしょう。もしかすると、私が提案したアプローチを採用することもあるかもしれません。
その類推は誤っています。
実際に行っているのは、インド人がアメリカのビザを申請した場合、アメリカのすべての市民に、その人にビザを交付するかどうかを投票させることです。
これは私には意味がわかりません。あなたは互いに無関係な2つの異なる側面を混同しています。
まあ、あなたの比喩と元の投稿者の比喩との本当の違いは、彼があなたよりも「より強く」永続的な受入を想定している点（ビザ対市民権）です。結局のところ、同じことです。
彼は確かに人々が直接、誰を受け入れるか（あるいは受け入れないか）を決めたいと考えています。そして、入国は誰でも自由にできるわけではありません。受入が必要なのです。
いいえ、それはディスカッションソフトウェアの役割ではありません。他にそのような機能を持つソフトウェアをご存じですか？
他に類例をご指摘いただけますか？
誰もやっていないからといって、それが悪いアイデアというわけではありません。原則として、個人的にはこのアイデアは非常に良いと思います。ソフトウェアが必ずしもそれに対応しなければならない（特にコア部分で）とは言いませんが、クローズドなコミュニティにとっては非常に優れた運用方法です。
たとえ市民権（またはフォーラムのメンバーシップ）のためだとしても、1人が参加するために全員の投票が必要だというのは意味がないと思います。
もちろん、あなたの意見は尊重されます。しかし、なぜそうお考えなのか、あるいはその根拠は何なのか、私はよくわかりません。コミュニティが大きいほど、あるいは潜在的な新規メンバーの数が多いほど、実用性が低下する可能性は確かにあります。しかし、私が述べたように、それほど大きくない閉じたコミュニティであれば、個人的にはこのコンセプトが好きです。
ただ、その意義が見当たりません。スタッフはユーザーの承認を行うために存在し、「どうやら」スタッフは信頼されているはずです。なぜコミュニティ全体がユーザー承認の手伝いをする必要があるのか、よくわかりません。特に、コミュニティ全体が「いや、このユーザーの印象は良くない」と言う場合、それが公開コミュニティであれ非公開コミュニティであれ、公的な屈辱になる可能性があります。まるで次のような状況です：
おい、おい！私たちが公的に拒絶した馬鹿どもの美しいコレクションをご覧ください。
この理由から、Raj_Rathore さんは見送ります。
ありがとう
はい、あなたがその意義を見ていないことは理解できます。スタッフは必ずしも「信頼されている」わけではなく、また多くの場合コミュニティによって選ばれたわけではありません（間接的に選ばれたと主張するかもしれません。人々がそのフォーラムに引き続き訪れることを選んだからです）。スタッフがユーザーを承認することは、民主主義というよりは独裁に近いものです。少なくとも、スタッフが選ばれている場合（OP が直接民主主義を望んでいる場合）、それは代表制民主主義に近いでしょう。
それは、ナイトクラブの入り口で断られたり、職を与えられなかったり、解雇されたり、あるいはこの話題により近い例として、フォーラムから禁止されたりする際の状況と同じです。スタッフが断った際に「公的に屈辱」を感じることと、どこに違いがあるのでしょうか？少なくとも、コミュニティによって行われる場合、それはかなり多くの人々によって決定されます。それがより「公平」である可能性が高いと信じてください（必ずしもそうとは限りませんが、おそらくそうでしょう）。一方、一人または少数の人によって恣意的に決定される場合とは異なります。
また、コミュニティに発言の機会を与えることで、コミュニティへの敬意を示す良い方法でもあります（そして、コミュニティが誰を望むかを決めることで、さらなる化学反応が生まれます）。
悪意はありませんが、なぜその意義が見えないのか理解できません。それがあなたを悩ませる、あるいはあなたが「コントロール」したままにしたい、といったことなら、それはわかります（これも独裁に近いですが、これは私有フォーラムの一般的な姿です。良い独裁者と悪い独裁者がいます）。
なぜ人々がこれに対してこれほど強く反対しているのでしょうか？そして、プロフィール写真に基づいてユーザーの承認を決定するのは誰なのでしょうか？ユーザーは自分のアカウントに任意の画像を選択または関連付けることができ、Discourse はさらに最初の文字に基づいて画像を割り当てるのに、なぜでしょうか？私たちの場合、ユーザーがサインアップする際にカスタムフィールドを使用してアンケートに回答する必要があり、その内容に基づいてユーザーの承認が行われます。
ユーザーが複数のユーザーによってレビューされる必要があると捉えることもできます。私は他の人の意見を重視します。例えば、『100 万円クイズ』でなぜ視聴者投票があるのでしょうか？なぜランダムに一人を選んで、その人だけに答えを問わないのでしょうか？私たちは視聴者の方がより確信を持っていると想定しています。そして、小規模なコミュニティでは、管理者を除いてスタッフは一人もいないこともあります。
また、ある意味で、私はコミュニティに「誰がメンバーになれるか」について発言権を持たせることを尊重したいと考えています。また、このコミュニティの一員であることが特権であり、それを乱用すべきではなく、常に貴重なものとして扱うべきだという意識を持たせたいのです。さらに、誰が承認され、誰が拒否されるかについて一定のコントロールと発言権を持つことも望んでいます。いずれにせよ、メンバーシップの承認または拒否の決定には、より多くの人が関与すべきです。@Mevo さんは私の考えを完璧に理解してくれました。
私の仮想的な解決策としては、TL2 以上のユーザーにレビューページを表示し、指定された時間で終了する投票を行うというものです（投票システムは既に Discourse の一部です）。もし Discourse 自体がモデレーターや TL4 ユーザーの選出時に投票を行うことを提案しているなら、コミュニティへの承認プロセスにもユーザーを関与させることに何の問題があるのでしょうか？新しいユーザーは、このコミュニティの一員になるための選挙に勝ったと感じ、他のユーザーを選ぶ権利を大切にするようになるでしょう。これは、互いを信頼する小規模なユーザーコミュニティであり、彼らは自由に自分の意見を共有し、その意見が受け入れられることを感じることができます。問題は良い方法で議論されるでしょう。彼らは互いにある程度の尊重を持つようになるでしょう（なぜなら、彼らがここにいるのは、誰かが彼らの承認に投票したからです）。また、少なくともコミュニティに参加する目的と目標には共通点があるでしょう。その目標を達成するために意見を共有するため、人々は互いの意見に対してより寛容になり、コミュニティ自体を尊重するようになるでしょう。少なくとも、そのように機能することを願っています。
とにかく、これが他の人にとって役立たず、Discourse の一部になれないとお考えであれば、それでも構いません。私は単に、私のユースケースでは有用であり必要となるものを提案しただけです。すべての人のユースケースが同じであるわけではなく、コミュニティによって異なる可能性があります。私自身もケースバイケースで異なるオプションや選択を選ぶでしょう。もしすべての人のユースケースが同じであれば、Discourse はメンバーシップの扱いについてたった一つの選択肢しか提供しなかったでしょうし、人生はもっとシンプルになったはずです。しかし、Discourse はこれらの複数のユースケースをサポートしています。
私のユースケースや考えを共有することで、何か害を及ぼしてしまったのではないかと心配しています。また、何かで不快に思われたとしても、私が提案している内容に何の攻撃性もありません。もしこれがあなたにとって理にかなっていなくても、それは構いません。少なくとも私のユースケースでは、コミュニティに「誰がメンバーになれるか」について発言権を持たせることは非常に理にかなっています。
こんにちは、Rajさん！興味深い会話ですね。強い口調の返信についてはあまり気にしなくて大丈夫ですよ。ここでは議論のあり方について強い意見を持つ人がたくさんいますし、それぞれが自分のニーズに合わせてどのように使うかを決める必要があります。
Discourseは、コミュニティ運営を比較的簡単にできるように設計されており、スタッフは毎日何時間もかけて新規メンバーの登録支援や議論のモデレーションに携わる必要がありません。私の経験では、デフォルトで提供される機能に頼れば頼るほど、多くの面で負担が軽減されます。カスタマイズやサードパーティ製プラグインの追加、デフォルト設定の変更などは魅力的で楽しいですが、プラットフォームの維持やコミュニティの満足度・参加度を保つための作業量も増えます。どれだけの追加作業を自分で行いたいかはあなた次第です。すべてのコミュニティは異なりますし、ここであなたが行おうとしていることが一部の人が「おかしい」と感じるかもしれませんが、あなたのコミュニティにとっては理にかなっているかもしれません。とりあえず試してみて、うまくいかなければ後から変更することもできます。
ただし、このトピックで得られたアドバイスの中には非常に良いものがいくつかあり、公開審査プロセスを設定する前に熟考する価値があると思います。よりシンプルな解決策として、一部のカテゴリを公開にし、一部を非公開にして、非公開カテゴリへの参加を難しくするという方法もあります。また、「参加を希望するメンバー」をリストしたトピックを作成し、スタッフ（またはより多くのガバナンス構造が必要だと感じる場合は委員会）に対して、一定の期間内に私的に異議や理由を返信するよう呼びかけることもできます。その後、却下されたメンバーの情報を削除するようそのトピックを更新すれば、その情報を長く保持しておく必要はありません。
審査のアイデア自体が必ずしもばかげているわけではありません。私は、人権団体「Namati」が運営する「Global Legal Empowerment Network」で設定した「コアメンバーシップ」の概念を思い出しました。誰でもネットワークに参加して法的エンパワーメント運動に加わることができますが、コアメンバーシップにはより高い基準があり、追加のメリットが得られます。そのため、その基準を満たすのが難しく、審査に追加の労力をかけることが理にかなっています。
あなたもコアメンバーシップのプロセスをご覧になり、私たちの経験から学ぶことに興味があるかもしれません。詳細は Core Membership - Grassroots Justice Network に記載されています。ほとんどの人は申請して候補に選出されたか、ネットワークイベントに参加したことでコアメンバーシップを取得しますが、メンバーは詳細な申請書に記入してスタッフに提出することもできます。その後、提出物が完全かつ適切かどうかを審査し、Discourseのプライベートメッセージ（PM）を使って追加の詳細や残りの質問への回答を求めます。すべての情報が受け入れられた後、候補者の却否を決定するために、ネットワーク指導委員会に非公開カテゴリで提案します。却否されなかった候補者はコアメンバーとして認定され、お祝いのメッセージを送り返します。これがサイクル完了後の典型的な流れです：
ラージ、あなたがやりたいことは私には完全に理にかなっていると思います。でも、多くの人が（おそらく大半が？）私の意見に同意しないことが多いので、そこが難しいところですね 
必ずしもそうではないですが、たまにあなたのように似た考え方の人に出会うこともあります 
トビアスが提案したように、Discourse のコア機能を使って目標を達成できるかもしれません。私は「足がかり」のような仕組みが良いアイデアだと思います。つまり、人々が自由に参加し、自分自身を好きなように紹介できるフォーラムの小さなセクションです。そして、メンバーがその人々と交流することもできます。本物のフォーラムに参加するためには、まず各自が「自分自身」を紹介する投票付きのトピックを作成する必要がある、と伝えることができます。
@Mevo 志を同じくする方々と交流できるのは素晴らしいことです。@tobiaseigen Discourse が提供する既存の機能で対応できるよう努めます。実際、私は Discourse を使う際、そのような方法を好んでいます。例えば、最近あるフォーラムでサードパーティ製のプラグインをいくつか導入したところ、そのうちの1つが問題を引き起こしました。そのため、すべてのサードパーティ製プラグインを削除しました。今では、絶対に必要な場合や明確な利点がある場合のみプラグインを使用するようにしています。私はそういう意味でのミニマリストであり、常に既に利用可能な機能を活用するように努めています。前述の通り、これは特定のユースケースにおいてのみ適切に思われるものです。また、コミュニティがメンバーを承認するというアイデアは、実際には有益で報われるものであり、より自動化され、スタッフユーザーの関与をあまり必要としないと考えています。なぜなら、メンバーはコミュニティとその目的について懸念を抱いた際に、自らの意見を表明したいと考え、その過程に参加したいと願うからです。
すでに、クローズドグループを作成し、そのグループのメンバーのみがアクセスできるプライベートセクションを作成するオプションがあります。既に登録されているユーザーは、このグループへのアクセスをリクエストすることで、プライベートカテゴリへのアクセス権を得ることができます。これはある種の2段階の仕組みですが、最終的には個人の意見に基づいています。例えば、オーナーがグループへのメンバーシップを承認でき、多くの人々がその決定に関与しない場合もあります。人々はメンバーシップリクエストの承認または拒否について話し合いますが、私はこれを自動化し、少なくともグループレベルで人々が関与できるようにできるのではないかと考えました。例えば、国連の安全保障理事会を例にとると、既存のメンバーが新しい国の加入を承認するかどうかが決まります。中国が国Aの加入を招待または承認するのは、中国と友好的だからであり、国Bの加入を却下するのは、他の国々には受け入れられるが中国が気に入らないからです。他のメンバーは誰を承認または拒否するかについて意見する機会さえ得られません。私のケースでは、ユーザーに拒否権を与えておらず、民主的であり、既存のメンバーの投票に基づいています。
とにかく、私のアイデアが好まれないことはわかりますし、おそらく小規模なコミュニティ向けなのだと思います。Discourse は本当に素晴らしく、これらのケースを処理するためのツールを提供しています。いくつかは既に統合されたソリューションであり、私の場合のように、新しい手動のソリューションや手順を考案することも可能です。いつもの通り、私は既存の機能を使用することを好みます。その方がシンプルだからです。稀なケースでは、何かしらの方法でプロセスを自動化したり、ある程度手動のソリューションを作成したりすることもあるかもしれません。それが有用であり、ユーザーに好まれる場合に限りますが。私も Discourse に最善を望んでいます。何も気にしていません。素晴らしいことです。
皆様からフィードバックをいただけたのは本当に嬉しかったです。貴重なお時間をいただき、ありがとうございます。
ありがとうございます。
敬具、
