这是我们需要的功能。我们使用审批机制来处理漏洞报告（在拥有超过15万用户的情况下，用户往往倾向于先发帖后阅读）。我们有一个通用的“支持”论坛，鼓励用户在那里提出“如何使用”类的问题。如果出现问题，我们会要求他们在“漏洞报告”板块发帖。问题在于，如果他们的帖子被拒绝（例如作为重复帖子或因缺乏适当信息等原因），他们却无从得知……帖子直接消失，他们甚至不知道帖子是否成功提交。
这导致他们倾向于在摩擦更低的“支持”论坛发布漏洞报告，内容往往完全相同，且缺少我们需要的、用于复现问题的关键信息。这给我们带来了更多的工作量。我希望能够以具体理由拒绝帖子，从而教育用户如何正确提交漏洞报告，或者链接到已有的相关报告。
以下是用户将此作为顾虑提出的逻辑流程：
目前“漏洞报告”板块的帖子运作方式下，你可能永远看不到任何明确表明帖子已被接收的反馈。此类帖子需要版主审批后才能显示——这很有道理。一个漏洞可能影响许多人，如果没有审批机制，可能会产生许多不同的讨论线程。此外，这本身可能并非真正的漏洞。如果“漏洞报告”板块旨在同时作为漏洞列表，这也是帖子需要审批的另一个原因。
然而，如果帖子最终没有显示，似乎没有任何明确的确认表明帖子已被接收。即使（或类似的报告）最终显示，也可能需要相当长的时间。如果问题持续存在，你可能会想：“帖子真的被接收了吗？我应该再发一次吗？”你也会花费时间检查是否有任何新内容出现。
这令人沮丧。
但如果作为“建议与反馈”发布，帖子至少会显示出来，这样你就能看到它已被接收。即使后来被移动或删除，你至少知道它没有在传输过程中丢失。
这就不那么令人沮丧了。
从试图通过引起关注来提供帮助的用户角度来看，因此在“建议与反馈”中发帖似乎比在“漏洞报告”中发帖更有效。在“漏洞报告”中发帖，你还必须至少提供一个标签，这也阻碍了用户在那里发帖。而且，系统要求你提供大量可能并不相关的信息。
实际上，论坛的行为机制鼓励我们将问题作为“建议与反馈”而非“漏洞报告”来提交。
有人可能会争辩说，这可能会产生审批机制本意要避免的重复线程。然而，我们本就应该在发帖前查找现有线程，而且等待片刻让其他帖子有机会显示也是轻而易举的。
因此，综合来看，从希望提交报告的用户角度来看，在“建议与反馈”中发帖似乎仍然更有效。