尽可能公开你的组织的目标，不要因此而让商业秘密妥协。如果你希望项目能够获得某个特定的特性，例如你的客户要求这个特性，那么就应该在邮件列表中坦率的说出来。如果客户希望保持匿名，实践中这种情况很多，至少要询问一下客户是否愿意以未命名的方式使用他们的实例。开发社区对于你为什么这样做的原因了解越多，就会对你提议的事情越感到舒服。

这与直觉背道而驰—得到容易甩掉难—知识就是力量，你的目标别人知道的越多，他们就越有可能超越你的控制能力。但是那种直觉在这里并没有错。通过公开支持这个特性（或是bug修正或其他任何东西），你已经亮出了底牌。现在唯一的问题是你能否成功的引导社区来分享你的目标。如果你仅仅是表明你需要它，而不能提供任何表明原因的切实例子，你的论点就会很脆弱，而人们会开始猜疑其隐藏的动机。但是如果你能够提供现实的场景来展示为什么提议的特性是重要的，就可以有力的影响辩论的效果。

为了看清楚这样做为什么有效，考虑另外一种选择。关于新特性或新方向的讨论会非常耗时和烦人。人们提出的论点经常会变成“我个人希望X，”或曾经流行的“根据我多年作为软件设计师的经验，对用户来说，X是极端重要的/一个无用的花边功能不会让任何人满意。”可以预料到，现实用例的缺乏不仅不会缩短或缓和这种辩论，而会扯得离实际用户体验越来越远。如果没有一些增补的力量，那么最终的结果很可能需要由口才最好、坚持最久或地位最高的人决定。

对于有许多客户数据的组织，你有机会提供这种增补的力量。你可以作为无法达到开发者社区的数据的信息管道。不必因为那些支持你愿望的信息事实而感到窘迫。大多数开发者个人没有他们所写软件如何使用的广泛经验。每个开发者都会按照自己的怪异方式使用软件；只要有其他的使用模式，她就会凭直觉并臆断之，而且事实上，她们知道这一点。通过提供包含可观用户数量的可信数据，你就象为整个公共开发社区提供了氧气。只要你提供的例子是正确的，他们就会狂热的欢迎它，就会推动事情往你希望的方向发展。

关键是提供正确的例子。不要因为你要应付大量需要某特性（或以为他们需要）的用户，就坚决要求你的特性，也就是你的解决方案必须实现。相反，你必须将你最初的帖子关注于问题，而不是一个特定的解决方案。详细描述你的客户遇到问题的细节，尽可能提供你已经完成的分析，以及你能想到的可行性方案。当人们开始考虑不同方案的效果时，你可以继续通过提供数据来支持或反对她们的意见。你在心里可以有一个特定的解决方案，但是不要在开始单独提出来以期望获得特殊的考虑。这不是欺骗，这只是标准的“诚实代理人”的行为。毕竟，你的真正目标是解决问题；一个解决方案只是达到目标的一种方法。如果你选中的解决方案确实更好，其他开发者最终会识别出来—她们会出于自愿的跟进，肯定比你通过威逼她们实现更好。 （当然，也有可能她们找到了更好的方案。）

这不是说你不能说出你看好某个方案。但是你必须耐心的查看你所做的分析反复成为公共开发列表的中心。不要在列表中说“是的，我们试过这种方式，但是因为原因A、B和C，它是行不通的。当你彻底了解它后，解决它的唯一办法是...”问题不是它听起来很傲慢，而是让人觉得你对此问题已经研究了许多未知的（但是，人们会假设有很多）分析资源，只是一切都在门后面。它让人觉投入的精力白费了，或许已经做出了决定，而公众都不是有利害关系的人，这是招致怨恨的好方法。

自然，你知道你自己在某个问题上所投入的力量，而这些知识从某种意义上来说是一种劣势。它让你的开发者处于和邮件列表中的其他人些许不同的心理空间，减弱了开发者从那些普通人的视角看待这个问题的能力，这些普通人没有像开发者那样考虑过这个问题。你越早能够让所有人用与你相同的术语考虑问题，这种差距就会越小。这种逻辑不仅适于个人技术情形，而且适用于更广泛的让你的目标尽可能清晰的授权。未知总比已知的更不稳定。如果人们理解了为什么你希望你所希望的，即使他们不认可，在与你交谈时也会感到舒服些。如果他们不能指出何事让他们愤怒，他们会假定最坏的情况，至少有时候。

你不能宣传所有的事情，当然，人们也不会期望你如此。所有的组织都有秘密；或许会因为利益，但是没有利益也会如此。如果你必须发起这样一个过程，而无法揭示任何原因，那就提供你在这种不利条件下最好的论点，并接受你将不会在讨论中获得你期望影响力的后果。这是让你不必为开发社区支付薪水的一个折衷手段。