原文来自 Coding Horror 博客，作者是 Jeff Atwood ，stackoverflow.com 创始人。本文由虎嗅翻译。
采访者喜欢问你最大的缺点是什么，犯过最大的错误是什么。这些问题听起来有点太程式化了，甚至都有点让人腻了，但是当你做出回答的时候还是要小心：这些问题比看上去要重要得多。
人们问我，在创建 Stack Overflow 的过程中犯过最大的错误是什么，我不会用陈词滥调来瞎编一套。我可以诚恳地、公开地指出在 Stack Overflow 初期犯下的一个荒谬蠢笨的大错，更糟糕的是，在社区的持续抗议下，在长达九个月的时间内我依然坚持错误做法。我甚至写了一篇博客文章否认。
很长时间以来，我对这件事的看法和《搏击俱乐部》电影里的一样：Stack Overflow 的第一条原则是，不能讨论 Stack Overflow！毕竟，我们是彼此学习如何编程，而不是纯粹去搞一个蠢网站，不是吗？
我当时并没有看到对 meta 的需求。这里的 meta 是指你讨论问题的地方。仔细想想这是什么意思。Meta 是为那些十分关注社区的用户准备的，他们愿意更进一步，走到一起，投入更多时间来讨论决定如何维护管理这个社区。简单来说，我当时会对那些深爱着 Stack Overflow 的用户说⋯⋯滚蛋，哪凉快哪待着去。
在给自己的辩解中，我最终意识到了问题所在，要感谢社区不断的刺激。尽管从网站内测开始就曾使用过一个外部的 meta 站点，在 2009 年六月我们终于发布了自己的 meta.stackoverflow，其时已经是公开内测的十个月之后了。在 Stack Exchange 上我们完善了这一点。每一个 Stack Exchange 站点从一开始就有一个 meta 。我们现在知道了，对 meta 的参与是社区中一切有意义的领导力量和管理能力的来源，meta 起到了近距离培育、监管的作用。
我也为自己成为 meta 排名最高的用户这一点付出了代价。在过去两年零七个月中，我完全投入到 meta 中，从程序 bug 到功能需求，从讨论到支持。你可以在我的用户页面中看到，我在这段时间内有901天访问了 meta ，基本上也就是每天都上。我认为自己积极投入 meta 的表现是一种荣耀，远不止如此，我的工作就是把社区做大。我们在 Stack Exchange 做的每一件事都要公开，故意与象牙塔式开发（Ivory Tower Development）截然相反。
这段期间，在与社区共同开发软件、应对社区反馈方面，我得到了一些经验教训。
一、社区反馈中 90％ 都是胡扯
我们可以马上讨论完这个问题。任何男人、女人、孩子⋯⋯甚至整个社区，都无法否认史特金定律（Sturgeon's Law）。Meta 社区，我爱你爱到死，让我们坦诚对待彼此吧：无数个理由说明，大部分你提出的反馈和功能需求只不过⋯⋯ 厄⋯⋯ 可以实行罢了。
但是一定要记住：这说明你获取到的社区反馈中，有 10％ 是很厉害的！我保证你会发现十条含金量很高的帖子，提出的建议能够让网站变得对所有人来说都更好⋯⋯ 前提是你有毅力把上百篇帖子都看完。准备好在这里投入许多时间吧，我说的可是许多许多许多的时间啊，把整个社区反馈的精华提炼出来。我坚信每一个社区都有一些牛人能够或多或少制造一些精华，这些内容实在是太棒了。
二、在开发中不要被各种观点左右
你应该可以立刻把问题反馈和功能需求分成两大类：
我们要这部轿车有电动车窗！
我们要这部轿车有车厢！
前者是很合理的需求，后者确在改变一部车的本质。软件的可塑形态诱惑着我们去给车子加上车厢。为什么不呢？用户不断要求，卡车更方便，不是吗？
千万不要掉进这个陷阱里面。明确任务目标。轿车-卡车的混合体对许多人来说是很恐怖的，最后你可能完成的是一辆斯巴鲁 Brat 轿卡。除非你真相希望要一辆卡车，那些要卡车功能的用户应该很友好的被告知怎样去最近的卡车零售店，因为他们不应该在这里出现。
三、如果不会去做的话就坦白说
看到 bug 追踪和反馈论坛里面有上千条信息无人回应的时候，我会很沮丧。一个没有被很好管理的社区就是这样，还有更糟的，对社区不诚实。这种错误十分典型，千万别这么做！
我的意思可不是让你告诉社区他们的反馈差劲极了，虽然常常就是这种情况。那样太不礼貌了。但是当你觉得建议不合理或者不能实施的时候，不要害怕，礼貌地拒绝这些的需求。（当然，你永远应该保持在未来改变主意的权利。）被拒绝肯定让人伤心——但是被忽视更让人伤心。我非常非常坚信，如果你对社区诚实，最终他们会加倍尊敬你。
一切的关系都基于信任。如果你不愿意对你的社区坦诚，怎么能期望他们尊敬你⋯⋯ 并且维持联系呢？
四、倾听社区的反馈，但不要让别人告诉你应该去做什么
把 meta 社区里面的需求作为开发的模板，这个主意很吸引人。Meta 的意义就在于让你倾听社区，针对反馈做出行动，不是吗？恰恰相反，针对社区反馈直接做出调整是极端危险的，这也是许多社区一开始照本宣科结果失败的原因。我这里引用 GitHub 联合创始人汤姆•普赖斯顿-沃纳（Tom Preston-Werner）的话作为解释：
比如说有一个功能需求「GitHub 可以让用户通过 FTP 为项目上传说明文档」。这位用户真正想说的是「我想要一个简单的发布内容的方式」，但是他们已经习惯现有的技术产品，于是他们用熟悉的东西来提交功能需求。我们可以实现这种恐怖的 FTP 解决方案，但是我们要研究需求背后的深层次问题。现在我们让用户可以方便地更新 Git 库，功能性和优雅性都兼顾了。
社区回馈很棒，但是不能被用来当作枴杖，不能代替对设计什么和为什么这两个问题的深刻思考。永远尝试弄清楚真正的需求是什么，提出明智的方案。
五、和你的社区在一起
在任何时间内，有一半的社区关系并不是社区所想象的样子，但是要和你的社区在一起，随时倾听并回应。当 Stack Exchange 的联合合伙人回复了你的 meta 文章时——即使那不是你希望听到的——我希望这代表了我们是真心和社区一起来创造这个网站。
不管是否有交易，你应该乐于发现社区需求中的精华，或者是 meta 中的程序修正，这些会让你的网站和产品越来越好，你要一头扎进去。这是一个公开反馈的良性循环：它告诉用户你们很重要，我们很重视，一切都在以令人欣喜的姿态，变好。
难道这不是最重要的吗？