在我们的社区中，我们已决定需要一个封闭型社区，用户必须由工作人员审核批准。因此，我启用了“必须审核用户”选项。虽然功能已生效，但审核过程耗时过长。
理想情况下，现有成员可以对审核请求进行投票和审查。这样，在投票结束后，用户可自动获得批准；或者工作人员可以审查投票结果，并快速对请求采取行动。目前，我已在某个分类中手动创建了一个主题，供信任等级为 2 的用户审查请求，并手动添加审核页面的截图（通过检查元素并隐藏用户邮箱后截取）。如果这一功能能直接集成到 Discourse 中，那就太好了。
与其设置为“必须批准用户”，不如改为“仅限邀请”，并允许用户邀请他人。
6 个赞
不确定我自己或其他人是否喜欢这个…
这个过程比直接点击 批准用户 要耗时得多 
2 个赞
这仅仅是因为，在我们看来，目前应由现有成员决定是否接纳新成员加入社区。这一决定不应仅基于单个用户的意见（即邀请），也不应仅依赖工作人员的批准。谁将成为社区的新成员，现有成员应当知晓，并应在成员资格方面拥有某种程度的控制权。
2 个赞
这种准入门槛不能放在 Discourse 核心中。你所要求的功能必须通过某种自定义插件来实现。如果你有预算，欢迎在 Marketplace 频道发帖。
3 个赞
是的，我同意你的观点。某个人的特定使用场景可能并不适用于所有人。但对于一个封闭社区来说，由现有成员多数批准新成员加入，这难道不是合适的做法吗？我先用我自己定制的、基于投票的手动方案试试看，看看效果如何。
1 个赞
这对我来说完全讲不通。如果是封闭社区，就不需要民主；如果是民主机制，就不必锁定或封闭。你试图构建的是一个过于复杂的系统，既低效又缓慢。
如果我是你，我会设立一个小组（最好通过选举或任命产生），由他们 individually 拥有批准或拒绝用户的权限。
1 个赞
世界上并不存在所谓的“全球民主”。只有特定国家的公民才拥有投票权，并非人人如此，且他们仅能参与该国的民主体系。作为印度公民，我无法在美国投票。因此，美国实行民主制度是完全合理的。若想在美国投票，我可以申请入籍，而当地当局（在我们类比中相当于“工作人员用户”）可以批准或拒绝我的请求。这正是 Discourse 中审批系统的运作方式。邀请系统则适用于另一种情况：例如，当美国需要邀请全球范围内具有影响力或有用的人才加入时。因此，在我的案例中，审批系统适用，但它并非民主的，因为决定批准或拒绝的人选本身并不民主；而且有时工作人员甚至并不清楚是否应该批准或拒绝。
我希望你能理解我的这个类比。此外，我们在这里并不受技术限制。一旦用户被批准或拒绝，数据库也可以被清除。用户只有在投票中胜出时才会被接受，这一过程是自动化的，甚至无需工作人员干预。只有达到 TL2 及以上级别的用户才能投票。
无论如何，我的用例可能并不适用于所有场景。我同意这是一个复杂的设置。在大多数情况下，我也会选择仅邀请制或由工作人员审批的方案，正如你所建议的那样。我甚至可能最终采用你所建议的方法。
那么你的类比是不正确的。
你实际上是在说，如果一个印度人申请美国签证，你就要求美国的每一位公民投票决定是否授予该人签证。
1 个赞
这对我来说毫无意义。你把两个互不相关的方面混淆了。
好吧。你的类比与原作者的类比之间唯一的真正区别在于，他认为某种形式的接受比你的更“强烈”和永久（公民身份对比签证）。归根结底，两者是一样的。
他确实希望人们直接决定自己想接纳谁或不接纳谁。进入并非对所有人开放，需要获得接纳。
3 个赞
不，这不是讨论软件的角色。你知道有其他软件这样做吗？
你能指出任何类似的例子吗？
1 个赞
仅仅因为没人这么做，并不意味着这是个坏主意。原则上，我个人认为这个想法相当不错。我并不是说软件必须（尤其是核心部分）来处理它，但这对于封闭社区来说是一种非常棒的运作方式。
2 个赞
即使是为了公民身份（或论坛成员资格），我认为让所有人投票决定某人是否加入也是没有意义的。
1 个赞
你当然有权持有自己的观点。但我实在看不出是什么让你这么想，或者你的理由是什么。确实，社区规模越大，潜在新成员越多，这种做法的可行性可能就越低。但正如我刚才所说，对于一个规模不太大的封闭社区，我个人很认可这个概念。
1 个赞
我只是看不出其中的意义。工作人员本应负责批准用户，因为“显然”工作人员是可信赖的。我不太明白为什么整个社区都要参与批准用户……我不确定。尤其是当整个社区都说：“不，我们不喜欢这个用户的样子”时，无论社区是公开的还是私密的，这都会变成一种公开羞辱。这就好比：
快来快来！看看我们精心挑选并决定公开拒绝的那些“天才”们的精彩集锦。
因此，出于这个原因，Raj_Rathore，我退出了。
谢谢
3 个赞
是的，我明白你看不出这有什么意义。管理员并不一定“值得信赖”，而且在大多数情况下，他们也不是由社区选出来的（你可能会争辩说他们是间接选出来的，因为人们选择继续来到这个论坛）。由管理员批准用户加入，与其说是民主，不如说是独裁。充其量，如果管理员是经过选出的，那也只是代议制民主（而原帖作者想要的是直接民主）。
当人们在夜店门口被拒之门外、求职被拒或被解雇，或者更贴近主题的情况——被论坛封禁时，情况也是如此。那么，当被管理员拒绝时，与“公开羞辱”究竟有什么区别呢？至少，如果由社区来决定，那是由相当多的人共同做出的决定。你可以打赌，这会更“公平”（不一定，但概率较大），而如果仅由一两个人随意决定，情况就大不相同了。
这也是一种向社区表示尊重的好方法，让他们发表意见（并且当社区决定他们想要或不想要谁时，还能产生进一步的化学反应）。
无意冒犯，但我就是不明白你为什么看不出这有什么意义。如果你觉得这会让你烦恼，或者你想保持“控制权”等等，这没问题（再次强调，这更接近独裁，但私人拥有的论坛通常都是如此。因此，有开明的独裁者，也有昏庸的独裁者）。
1 个赞
为什么大家对这件事反应如此强烈？用户头像又由谁来决定是否批准用户呢？既然用户可以自由选择或关联任何图片作为头像，Discourse 甚至会根据首字母自动分配图片？在我们的案例中，注册时会通过自定义字段进行问卷调查，用户必须填写这些信息，而是否被接纳正是基于这些内容来判断的。
你可以这样理解：一个用户必须经过多位用户的审核……我希望听到其他人的意见。例如，在《谁想成为百万富翁》节目中，为什么会有观众投票环节？为什么不随机挑选一个人，只问一个人答案呢？我们假设观众的意见通常更可靠。而在小型社区中，除了管理员外甚至没有其他工作人员。
从某种意义上说，我希望尊重我的社区，让社区成员对谁可以成为成员有发言权，同时也让他们感受到成为社区一员是一种特权，不应滥用，而应始终珍视它。社区应对谁被接纳或拒绝拥有一定的控制权和发言权。无论如何，应该让更多人参与决定是否拒绝或接受会员申请。@Mevo 完全理解了我的观点。
至于我设想的解决方案，一个审核页面应对 TL2 及以上级别的用户可见，并应设置一个投票，该投票在指定时间后关闭（投票系统已经是 Discourse 的一部分）。如果 Discourse 本身在选拔版主或 TL4 用户时建议进行投票，那么让用户参与社区成员的接纳过程又有何不妥？我假设新用户会很高兴通过“选举”成为社区一员，并会珍视他们选择其他用户的权利。这将是一个由互信用户组成的小型社区，他们可以自由分享观点，获得认同，以良好的方式讨论问题。他们更可能对彼此怀有尊重（因为他们之所以在这里，是因为有人投票支持他们加入），并且在加入社区的目标上至少具有一定的相似性。为了实现这些目标，他们会分享各自的观点，因此彼此也会更加包容，同时也会更加尊重社区。我希望至少能实现这样的效果。
无论如何，如果你认为这对其他人没有用处，或者无法成为 Discourse 的一部分，那也没关系。我只是提出了一些在我使用场景中实用且必要的建议，并非每个人的使用场景都相同或相似，不同社区之间也会有所差异。即使是我自己，也会根据具体情况选择不同的选项和方案。如果所有人的使用场景都一样，那么 Discourse 只需提供一种处理会员申请的方式即可，生活也会更简单，但 Discourse 支持多种不同的使用场景。
我希望我分享自己的使用场景和观点没有造成任何伤害。也请不要因任何内容而感到被冒犯，我的建议中没有任何冒犯之意。如果对你来说没有意义，那也没必要强求有意义。至少在我的使用场景中，让社区对谁可以成为成员拥有发言权是非常有道理的。
3 个赞
你好，Raj！这是一段有趣的对话。你不必太担心那些措辞强烈的回复——这里有很多人对“话语（Discourse）”的运作方式持有强烈观点，而我们每个人都得决定如何根据自身需求来使用它。
Discourse 的设计初衷是让社区运营变得相当简单，无需工作人员每天投入大量工时去帮助人们注册、入门，甚至去 moderating 讨论。我的经验是，越依赖其开箱即用的功能，我在多个层面上就越轻松。添加自定义功能、第三方插件或更改默认设置等虽然诱人且有趣，但也会增加你维护平台以及保持社区活跃和满意度的工作量。你需要自行决定愿意为自己创造多少额外工作。每个社区都是独特的，虽然对你描述的做法，这里有些人可能觉得疯狂，但这对你的社区来说可能很有道理。你不妨先尝试一下，如果效果不佳，随时可以调整。
不过，我认为在这个话题中有人给你的建议相当不错，值得你在设立公开审核流程之前认真思考。一个更简单的方案可能是：设置一些公开分类和一些私密分类，并提高进入私密分类的门槛。你也可以创建一个主题，列出希望加入的成员名单，并邀请大家在限定时间内私下回复工作人员（或委员会，如果你认为需要更多治理结构），提出任何异议及理由。之后你可以更新这些主题，删除被拒绝的人员信息，无需让这些信息一直留存。
我认为“审核”这个想法本身并不一定疯狂。这让我想起了我为“全球法律赋能网络”（Global Legal Empowerment Network）设立的“核心成员”概念，该网络由一家名为 Namati 的人权组织管理。任何人都可以加入该网络以参与法律赋能运动，但“核心成员”门槛更高，并能解锁额外权益。因此，使其更难获得并投入额外精力进行审核是合乎逻辑的。
你可能有兴趣查看我们的核心成员审核流程，并从中借鉴经验。相关内容可在 Core Membership - Grassroots Justice Network 找到。大多数人成为核心成员是因为他们申请并进入短名单，或参加了网络活动；但成员也可以填写详尽的申请表格并提交给工作人员。随后我们会审查其提交的资料是否完整且合适，并通过 Discourse 私信（PM）要求提供完整细节并回答任何剩余问题。一旦我们确认所有信息无误，便会将其提交至网络指导委员会（通过一个私密分类），由委员会决定是否拒绝任何候选人。未被拒绝的候选人将被授予核心成员资格，我们会发信祝贺。以下是整个周期完成后的典型样子：
10 个赞
Raj，你提出的想法对我来说完全合理。不过，很多人（也许大多数？）经常不同意我的观点，所以情况就是这样 
不过也不总是这样，有时我也会遇到持有相似观点的人，就像你一样：ok_hand:
也许你可以像 Tobias 建议的那样，利用 Discourse 的核心功能来实现你的目标。我喜欢“踏脚石”这个概念：在论坛中开辟一小块区域，人们可以自由加入，按自己的方式描述自己，甚至其他成员也可以与他们互动。你可以告诉大家，他们必须各自创建一个“个人”主题，并在其中发起投票来描述自己，这样才能加入“正式”的论坛。
1 个赞
@Mevo 与像您这样志同道合的人交流真是太好了。@tobiaseigen 我会尝试利用 Discourse 现有的功能来实现，这也是我实际更倾向于使用 Discourse 的方式。例如，我最近的一个论坛中曾集成过几个第三方插件，其中一个插件引发了问题。因此，我移除了所有第三方插件。现在，我仅在绝对必要或确有实用价值时才使用插件。在这方面我是个极简主义者，总是力求充分利用已有功能。正如刚才所说，这里确实存在一个特定的使用场景，使得该方案显得恰当。我认为“由社区批准其成员”这一理念实际上既有益又令人感到充实，而且更加自动化，减少了对管理员用户参与的需求……因为当成员关心社区及其目标时，他们乐于表达自己的观点并参与其中。
目前已有创建封闭群组并随后建立仅该组成员可访问的私密版块的功能。已注册用户可以申请加入该群组，从而获得访问私密分类的权限。这算是一种两级设置，但最终仍取决于个人的意见：例如，群主可以决定是否接受成员加入该群组，而并非许多人能对此发表意见……人们会就接受或拒绝成员申请进行沟通。我认为这一过程可以自动化，至少可以在群组层面让成员参与进来。例如，假设这是联合国安全理事会，现有成员决定是否接纳一个新国家……比如，中国邀请或批准国家 A 加入，因为该国与中国是朋友；或者否决国家 B 的加入，尽管其他国家可以接受，但中国因不喜欢而反对。其他成员甚至没有机会对接受或拒绝谁发表意见。在我的案例中，我并不赋予用户否决权，而是采取民主方式……基于现有成员的投票。
无论如何，我能看出我的想法并不受欢迎，我猜它更适合小型社区。不过，Discourse 确实非常棒，提供了处理所有这些情况所需的工具：有些已是集成解决方案，而在某些情况下（如我的案例），则可以发明新的手动解决方案和流程。和往常一样，我仍倾向于使用现有功能，这样更简单。在极少数情况下，我可能会以某种方式自动化我的流程，或创建某种手动解决方案……前提是我觉得有用且用户喜欢。我也希望为 Discourse 带来最好的结果。我没有任何不满。这很酷。
真的很高兴收到你们的反馈。感谢你们抽出宝贵的时间。
谢谢与致敬，
3 个赞