是我疯了吗？还是新的用户批准功能反过来了？
我已经习惯了每天查看新用户批准列表并点击“是”。今天我发现它改成了“是 = 不予批准”——这看起来太荒谬了。为什么批准“接受新用户”这样的正面操作时，“不”选项反而成了默认值？
这肯定会引起很多困惑，尤其是像我这样只是默默管理论坛、并不每天查看 Discourse 世界的人。
当有人申请加入时，我真的不想还得记住“否”其实意味着“是”。
我猜这和这个变更有关：
也许 用户 审批被忽略了 
并没有疏忽。反馈中的请求是统一方向，使得是/否始终代表相同的含义，无论队列项目的类型如何。
因此，对于用户审批，新的框架是“此账号是否存在问题”，其中“是”意味着不予批准。这与标记功能中使用的“此帖子是否存在问题”的框架一致。现在，“是”始终意味着“是的，存在一个问题”。
如果新的审批结构导致了问题，我们将不得不考虑进一步的更改……在这一点上，很可能完全放弃是/否的框架。
首先，我要感谢团队在分析和重构这一切方面所付出的努力和给予的理解。以下是我的一点微薄贡献：
也许其他用户可以纠正我的错误，但我认为大多数人都支持统一帖子和主题的举报标志。因此，这种统一各类举报标志的愿景可以保留，并加以调整以兼容例外情况：即在需要审批的用户列表中，当存在相反决定时进行特殊处理。
我认为这两者可以兼容，并且我相信这最终能够同时明确这两个流程，而不会给任何管理员或用户带来不便。
标记功能此前已经统一，是的，这意味着在更改之前存在一致性问题。逻辑发生翻转的例外情况是帖子和用户审批。
我们可以考虑的另一种方法是完全放弃审批功能中“是/否”的框架，改用“批准/拒绝”，同时保持顺序一致，使“拒绝”选项的位置与原“是”标记操作的位置相同。
这很有道理，我们只需要评估一下对管理员的影响，我想可以通过一个实验性功能来启用这个改变。
这里的问题在于，举报队列显示了两种不同的流程：
- 被举报的帖子 → “这有问题吗？”
- 待审核用户 → “批准用户？”
它们的响应逻辑自然是相反的：对被举报的帖子回答“是”意味着存在问题，而对用户回答“是”意味着一切正常 
抱歉提出了这一指控
我猜原帖作者以及经常参与用户审核的人只需要更新他们的认知框架即可。
就我个人而言（万幸），我没有多少需要审核的内容，所以无论执行标准如何，对我来说总是比较新鲜 
我认为这种方法可以避免混淆 
但那不又回到了之前的问题吗？即当它作为标记时，“批准”意味着帖子被删除，而当它作为垃圾邮件队列时，“批准”意味着帖子被保留。
我同意，如果用户审批也在同一个队列中，这确实不是一个容易解决的问题。即使交换了按钮的位置，“批准”一词意味着两种完全相反的含义，这仍然会让人有些困惑。
没错——如果仅在举报中使用“是/否”，而在审批中仅使用“批准/拒绝”，这种区分是否足以避免之前的混淆？
我仍然有兴趣收集其他人对当前状态的反馈，所以我并不急于马上更改任何东西。如果有人希望在我们达成一致之前不处理当前的状态，可以从 /admin/config/upcoming-changes 中禁用 Review queue consistent answers（审查队列一致答案）。
这是一个非常棘手的问题。我一直觉得审核队列有点奇怪，所以养成了一再检查自己选择的习惯。我认为这次改动合情合理，让审核队列更加直观。我从未考虑过原帖中提到的场景，但我也能理解他的观点。
不过，我只负责垃圾内容过滤的审核，而不负责新用户准入审核。也许这两者需要分开处理？？？
我认为类似这样的方案值得考虑，其核心在于批准或拒绝的是内容本身还是用户。这非常符合我的思维模型。
像垃圾内容这类情况则更为复杂，因为通常需要对帖子本身和帖子作者都采取行动。
Deny 仍然可能被理解为“拒绝标记”或“封禁用户”，这依然令人困惑。
改用 保留用户 / 移除用户 和 保留帖子 / 移除帖子 如何？
只要对话框能清楚表明这一点，我就没问题。
但这是一种逻辑反转，所以也许采用更明确、清晰的按钮文本才是解决之道。
务必彻底明确：批准意味着保留该对象，拒绝意味着该对象将被删除、丢失或驳回。我认为这两个词可能还不够清楚——就像之前批准投诉那个概念一样。
“批准 / 拒绝”的模式对我来说没问题，回到原始版本也可以。
我肯定不是 UI 专家，但就积极的结果（比如新用户注册）而言，我认为在两个选项中，第一个应该是接受这种积极情况，而不是拒绝它。
在发布这条消息之前，我刚处理了六个新用户，发现必须回答“否”才能让他们进入网站，这种感觉非常不自然。
当我意识到更改已生效时，我回头查看了管理日志，以确认没有因为这种违背直觉的操作而意外拒绝用户。