# 友好提醒，要对新人的建议或投诉保持开放 **URL:** \ **Category:** Site feedback\ **Created:** [2025年二月3日 09:54 UTC](https://meta.discourse.org/t/friendly-reminder-to-be-open-to-new-peoples-suggestions-or-complaints/350220 "2025-02-03T09:54:46Z")\ **Posts on this page:** 1\ **Showing post:** 1
**Author:** ![traceymoko](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/traceymoko/32/483235_2.png) [@traceymoko](https://meta.discourse.org/u/traceymoko)\ **Post date:** [2025年二月3日 09:54 UTC](https://meta.discourse.org/t/friendly-reminder-to-be-open-to-new-peoples-suggestions-or-complaints/350220/1 "2025-02-03T09:54:46Z")
> [@Why do Discourse installs enable digest email for all users?](https://meta.discourse.org/t/why-do-discourse-installs-enable-digest-email-for-all-users/347817/13?u=bloomexperiment): > > I’m not saying that isn’t a solution, I’m trying to offer some perspective to those in the thread who seem intent on just smashing OPs post, based on emotional kneejerk reactions about giving back to the community. > [@Why do Discourse installs enable digest email for all users?](https://meta.discourse.org/t/why-do-discourse-installs-enable-digest-email-for-all-users/347817/15?u=bloomexperiment): > > There’s an earlier request for a similar feature here: [Please don't autosubscribe me to summary emails](https://meta.discourse.org/t/please-dont-autosubscribe-me-to-summary-emails/127718) It’s something we are open to giving people more control over when they create their account and we’ve discussed some possible designs, but we haven’t had a chance to go any further than that yet. 我很欣赏 Discourse 团队对我和其他新成员提出的建议持开放态度。 多年来，我在 Meta 上看到过这种情况很多次，但这促使我也想就此发表一些看法。看到这种情况也让我感到沮丧，但我不知道该如何提出这个问题。所以，我现在就来写写我的想法： ## 背景 有时在 Meta 上，我注意到一种趋势，就是对新成员提出的关于 Discourse 功能或更改的建议进行评判。社区中的一些人不是倾听和理解软件新手（他们的见解即使对我们这些使用 Discourse 十多年的人也很有帮助）的经验，而是有时会先发制人地否定这个想法。 这通常发生在某个想法曾被 Discourse 团队拒绝，或者 Discourse 团队选择了某个默认设置而不是其他配置等情况下。 即使是这样，我也想谈谈为什么我们不应该先发制人地驳回对软件的想法或抱怨，即使它们以前已经被讨论过。 ## Discourse 团队拥有最终决定权。很多事情都变了。过去的事情可能不再适用。 首先，我们作为社区成员，并不是 Discourse 的产品经理。如果我们急于告诉某人他们的想法过去被拒绝了以及原因，这可能并不一定反映 Discourse 产品团队当前的决定。 有时，即使是 Discourse 团队自己，也可能决定着手开发一个过去被排除的功能。例如，聊天功能曾是这样一个功能。 > [@codinghorror](#): > > 毫无疑问，我们需要快速通道（聊天）和慢速通道（主题）支持并存。我们没有早点做到这一点是我的错，但请放心，这将是一个全新的、闪闪发光的、完全集成的体验。 因此，过去和现在的决定永远不能 100% 保证相同。 即使是 Discourse 团队内部，在 Discourse 的优先事项上也会有不同的看法。 例如，我经常关注 @erlend_sh 的博客，他讨论了他对聊天功能在 Discourse 中应该如何实现的看法与团队其他成员的不同——重点是我加粗的： > 大多数开源项目没有专门的论坛，但有论坛的项目几乎肯定也有群聊。我上次在 Discourse 的工作就是试图将这两种模式结合起来，[引入 Discourse 聊天功能](https://meta.discourse.org/t/introducing-discourse-chat-beta/210734)。 > > 我为那个 MVP（它已经[毕业成为核心功能](https://blog.discourse.org/2023/01/discourse-3-0-is-here/)）感到非常自豪， **但我希望的方向与 Discourse 作为传统论坛的 DNA 是不兼容的：我建议将聊天作为我们社区体验的_主导_。我认为社区始于聊天室。但 Discourse 不这么认为，所以我们友好地分道扬镳了。** > > 多年后，我的立场没有改变。“群聊”和“论坛”应该意味着大致相同的事情。事实上，这似乎是我们正在朝着的方向，因为统治我们社区领域的 Discord 现在支持各种适合论坛范式的线程和版块功能。 > **[Communal Bonfires](https://blog.erlend.sh/communal-bonfires)** > > Online community platforms are assembly-kits for large, communal bonfires, designed to draw people towards the light and into the warm to... 所以，我们不应该过早地决定什么_不_应该包含在 Discourse 中，因为这也会随着时间而改变。 我们这些早期使用 Discourse 的人会记得，当时 CDCK 的人数不到 10 人，产品管理很大程度上由 Discourse 的联合创始人驱动。但如今 CDCK 已有 100 人，[CDCK 拥有一个完整的产品团队](https://discourse.org/team)！ Discourse 本身的用户群要大得多，他们对该软件的需求和使用已经超出了早期用户的范围。更广泛地说，社交平台的格局已经发生了变化（例如，Facebook 的势头已转向 Discord 等），人们的普遍期望也发生了变化。 由于团队比早期规模大得多，他们有更多的能力来处理其他功能，这些功能在产品开发的早期阶段可能优先级很低。 因此，他们现在审查功能请求的方式可能与早期大不相同。产品团队将有自己的决策流程，决定最终在何时以及如何进行开发。 ## 更多数据点更好 其次，听到更多数据点而不是更少的数据点通常对 Discourse 团队很有帮助。 Meta 上曾经有一个[大致流行的“三人规则”](https://meta.discourse.org/search?q=%22Rule%20of%203%22%20@codinghorror%20)（至少有 3 个人抱怨某事，然后该功能请求才会被考虑）。即使如此，你也必须让人们分享他们的经历和抱怨，才能听到 3 个不同的人发现某个问题。 除此之外，还有一个流行的想法是“抱怨驱动开发”。有了这个，你也必须倾听人们的意见： > 我唯一见过有效的方法是 **深入用户群体，与他们沟通并建立关系** 。 > **[Complaint-Driven Development](https://blog.codinghorror.com/complaint-driven-development/)** > > If I haven’t blogged much in the last year, it’s because we’ve been busy building that civilized discourse construction kit thing I talked about. > > (Yes, that’s actually the name of the company. This is what happens when you put me in charge... 重读之后，我强烈认为那个“三人规则”的初衷_并非_如果你没有其他人抱怨，你的意见就不重要。 其核心在于（尤其是如果你是一个资源有限的团队），找出人们抱怨最多的问题，是一种有效的方式来找到最困扰用户的痛点——这样你就可以优先解决它们。 > 正如 Steve Krug 在《[别让我思考](http://www.amazon.com/dp/0321965515/?tag=codihorr-20&ref=blog.codinghorror.com)》中所说： > > > 你总会发现比你资源所能解决的更多的问题，所以优先解决最严重的问题非常重要。三个用户很可能在测试任务中遇到许多最重要的问题。 所以，仅仅因为没有多少其他人抱怨同样的事情，并不意味着它不重要。在考虑用户当前的主要/次要痛点时，更多的数据点仍然对 Discourse 团队很有帮助。 ## 即使不采纳，也可以欣赏人们的反馈 第三，即使你无法实现所有建议或已经决定不实现，仍然可以感谢人们的反馈。 在学习游戏设计后，我在这方面做得更好了，因为在游戏设计中，给予和接受反馈是过程的重要组成部分。在每个游戏关卡、设计文档或任何其他内容的迭代中，我们都会对至少 3 个其他人的作品提供反馈，并从至少 3 个人那里收到反馈。我过去常常尝试为 4 或 5 个人提供反馈，以弥补其他人缺席/迟交作业等情况。 很多时候，人们的反馈非常有见地和有帮助，但有 10 多个重要的问题，而你现在只能实现 1-3 个。 当我作为一名软件工程师在一家小型初创公司工作，并经常与社区互动时，情况也是如此。可能有 10 多个重要的错误报告，但在下一次更新中，你只能修复 1-3 个。 无论如何，我仍然觉得非常应该感谢人们的观察，感谢他们分享想法，感谢他们花时间写下重现错误的步骤，并为带来的不便道歉。 大多数时候，用户/玩家除非真的 bothered，否则不会说什么。所以，几乎所有的书面反馈/功能请求/错误报告都来自那些花时间分享他们对某事的想法的人——这些想法可能是其他人也想过但尚未识别或说出来，而你可能错过了，等等。 所以，即使你不能实现每个人说的所有内容——这可能占 90% 的时间——这并不意味着你必须对所有反馈都加以利用。反馈仍然很重要，即使你现在没有资源去实施它，或者即使你已经决定_不_去实施它。 总之，这就是为什么我认为，作为社区成员，我们应该让其他新成员分享他们的想法，而不是立即跳出来否定人们对 Discourse 的建议。这是因为 Discourse 团队对功能的立场可能会随着时间而改变，而且反馈仍然是 Discourse 团队有用的数据点，即使他们现在可能不实施它。 --- _[View the full topic](https://meta.discourse.org/t/friendly-reminder-to-be-open-to-new-peoples-suggestions-or-complaints/350220)._