我很欣赏 Discourse 团队对我和其他新成员提出的建议持开放态度。
多年来，我在 Meta 上看到过这种情况很多次，但这促使我也想就此发表一些看法。看到这种情况也让我感到沮丧，但我不知道该如何提出这个问题。所以，我现在就来写写我的想法：
背景
有时在 Meta 上，我注意到一种趋势，就是对新成员提出的关于 Discourse 功能或更改的建议进行评判。社区中的一些人不是倾听和理解软件新手（他们的见解即使对我们这些使用 Discourse 十多年的人也很有帮助）的经验，而是有时会先发制人地否定这个想法。
这通常发生在某个想法曾被 Discourse 团队拒绝，或者 Discourse 团队选择了某个默认设置而不是其他配置等情况下。
即使是这样，我也想谈谈为什么我们不应该先发制人地驳回对软件的想法或抱怨，即使它们以前已经被讨论过。
Discourse 团队拥有最终决定权。很多事情都变了。过去的事情可能不再适用。
首先，我们作为社区成员，并不是 Discourse 的产品经理。如果我们急于告诉某人他们的想法过去被拒绝了以及原因，这可能并不一定反映 Discourse 产品团队当前的决定。
有时，即使是 Discourse 团队自己，也可能决定着手开发一个过去被排除的功能。例如，聊天功能曾是这样一个功能。
因此，过去和现在的决定永远不能 100% 保证相同。
即使是 Discourse 团队内部，在 Discourse 的优先事项上也会有不同的看法。
例如，我经常关注 @erlend_sh 的博客，他讨论了他对聊天功能在 Discourse 中应该如何实现的看法与团队其他成员的不同——重点是我加粗的：
大多数开源项目没有专门的论坛，但有论坛的项目几乎肯定也有群聊。我上次在 Discourse 的工作就是试图将这两种模式结合起来，引入 Discourse 聊天功能。
我为那个 MVP（它已经毕业成为核心功能）感到非常自豪，但我希望的方向与 Discourse 作为传统论坛的 DNA 是不兼容的：我建议将聊天作为我们社区体验的主导。我认为社区始于聊天室。但 Discourse 不这么认为，所以我们友好地分道扬镳了。
多年后，我的立场没有改变。“群聊”和“论坛”应该意味着大致相同的事情。事实上，这似乎是我们正在朝着的方向，因为统治我们社区领域的 Discord 现在支持各种适合论坛范式的线程和版块功能。
所以，我们不应该过早地决定什么不应该包含在 Discourse 中，因为这也会随着时间而改变。
我们这些早期使用 Discourse 的人会记得，当时 CDCK 的人数不到 10 人，产品管理很大程度上由 Discourse 的联合创始人驱动。但如今 CDCK 已有 100 人，CDCK 拥有一个完整的产品团队！
Discourse 本身的用户群要大得多，他们对该软件的需求和使用已经超出了早期用户的范围。更广泛地说，社交平台的格局已经发生了变化（例如，Facebook 的势头已转向 Discord 等），人们的普遍期望也发生了变化。
由于团队比早期规模大得多，他们有更多的能力来处理其他功能，这些功能在产品开发的早期阶段可能优先级很低。
因此，他们现在审查功能请求的方式可能与早期大不相同。产品团队将有自己的决策流程，决定最终在何时以及如何进行开发。
更多数据点更好
其次，听到更多数据点而不是更少的数据点通常对 Discourse 团队很有帮助。
Meta 上曾经有一个大致流行的“三人规则”（至少有 3 个人抱怨某事，然后该功能请求才会被考虑）。即使如此，你也必须让人们分享他们的经历和抱怨，才能听到 3 个不同的人发现某个问题。
除此之外，还有一个流行的想法是“抱怨驱动开发”。有了这个，你也必须倾听人们的意见：
我唯一见过有效的方法是深入用户群体，与他们沟通并建立关系。
重读之后，我强烈认为那个“三人规则”的初衷并非如果你没有其他人抱怨，你的意见就不重要。
其核心在于（尤其是如果你是一个资源有限的团队），找出人们抱怨最多的问题，是一种有效的方式来找到最困扰用户的痛点——这样你就可以优先解决它们。
正如 Steve Krug 在《别让我思考》中所说：
你总会发现比你资源所能解决的更多的问题，所以优先解决最严重的问题非常重要。三个用户很可能在测试任务中遇到许多最重要的问题。
所以，仅仅因为没有多少其他人抱怨同样的事情，并不意味着它不重要。在考虑用户当前的主要/次要痛点时，更多的数据点仍然对 Discourse 团队很有帮助。
即使不采纳，也可以欣赏人们的反馈
第三，即使你无法实现所有建议或已经决定不实现，仍然可以感谢人们的反馈。
在学习游戏设计后，我在这方面做得更好了，因为在游戏设计中，给予和接受反馈是过程的重要组成部分。在每个游戏关卡、设计文档或任何其他内容的迭代中，我们都会对至少 3 个其他人的作品提供反馈，并从至少 3 个人那里收到反馈。我过去常常尝试为 4 或 5 个人提供反馈，以弥补其他人缺席/迟交作业等情况。
很多时候，人们的反馈非常有见地和有帮助，但有 10 多个重要的问题，而你现在只能实现 1-3 个。
当我作为一名软件工程师在一家小型初创公司工作，并经常与社区互动时，情况也是如此。可能有 10 多个重要的错误报告，但在下一次更新中，你只能修复 1-3 个。
无论如何，我仍然觉得非常应该感谢人们的观察，感谢他们分享想法，感谢他们花时间写下重现错误的步骤，并为带来的不便道歉。
大多数时候，用户/玩家除非真的 bothered，否则不会说什么。所以，几乎所有的书面反馈/功能请求/错误报告都来自那些花时间分享他们对某事的想法的人——这些想法可能是其他人也想过但尚未识别或说出来，而你可能错过了，等等。
所以，即使你不能实现每个人说的所有内容——这可能占 90% 的时间——这并不意味着你必须对所有反馈都加以利用。反馈仍然很重要，即使你现在没有资源去实施它，或者即使你已经决定不去实施它。
总之，这就是为什么我认为，作为社区成员，我们应该让其他新成员分享他们的想法，而不是立即跳出来否定人们对 Discourse 的建议。这是因为 Discourse 团队对功能的立场可能会随着时间而改变，而且反馈仍然是 Discourse 团队有用的数据点，即使他们现在可能不实施它。