英文原文：
Avoiding bad practices in open source project management
在 OpenStack 奥斯汀峰会期间，我有机会和一些人谈谈我在开源项目运行上的经验。事实证明在社区贡献这么多年之后，我可以提供一些看法，这对于外部的许多人来说都是新的。
有很多资源都在解释如何运行一个开源项目。今天，我想从不同的角度，在强调社交的情况下，你不应该做什么项目。这个列表来自我过去这些年遇到的各种开源项目。我发现了一些不好的实践，用一些随机的顺序，说明一些具体的例子。
探寻贡献者的烦恼
当软件开发者和维护者忙碌时，有一件事他们不用做：更多的工作。对于大多数人来说，外部贡献的直观反应是“糟糕，更多工作来了”。事实，也是如此。
因此，一些维护者打算避免剩余工作：他们说他们不想去作出贡献，或者做不受欢迎的贡献。这可以采取多种形式，来使他们免受不欢迎（对待）。避免即时需求来处理工作会给维护人员增加负担。
这是开源的其中一个最大错误和误导。假如别人分配你更多工作，无论什么情况你都乐意接受，别人才会继续与你一起配合工作。他们可能很快接替你的工作，你不用做了。那么考虑退休吧。
让我们看下我朋友Goldon的例子，他在2013年成为CeilMeter的贡献者。他正在查看庞大代码，但是事实上他分配我更多工作去通过补丁来捕获修复异常，并且发送我已查看过的补丁。他不再叫我重构代码和查看他的补丁而不是持强凌弱，我请求我们更多的信赖他，让他参与核心代码。
假如他们没这种一次性的贡献，他们不会再做第二次。他们再也不会做。那些工程将会失去它们新的维护人员。
让人们只做简单的工作
当新的贡献者们加入进来并且想要贡献一个特定的项目，他们可能有不同动机。他们中的一些人是使用者，但是他们这些人仅仅是想看到是如何做贡献的。从贡献中获得一种刺激，把它作为一种练习或是一种意愿来学习和开始回馈于他们使用的（开源的）生态系统。
维护者们通常的反应是让这些人做一些简单的工作。那意味着做一些他们没有兴趣的，几乎没有价值的，而且可能不会直接影响项目的工作。
一些人实际上对此（做一些简单的工作）没有意见，但一些人有。一些人对做一些低影响力的工作感到生气，但是只要你给他们一些认可，他们就会爱上这个工作。需要认识到的是，一定要为这些人鼓掌。只有这样，才能让他们围绕在（开源项目）周围。
其它翻译版本 (1)
加载中
不要拘泥于微小的贡献
当新贡献者给出的第一个补丁是纠正了一个拼写错误时，开发人员是怎么看待的呢？他们不在意，或者你的小小的贡献正在浪费他们宝贵的时间。而且没有人在意文档的英语水平多差，他们是这样认为的吗？
这么认为就是错误的。看看我给home-assistant和postmodern的第一个贡献：我纠正了文档中的拼写错误。
我为Org mode贡献已经有几年了，我给Org mode的第一个补丁就是修补了一个常量字符串。接下来，我提交了56个补丁，修补了许多漏洞，增加了一些有趣的功能，另外还编写了几个外部模块。到今天为止，我仍然在Org mode的390个贡献者的顶级提交者中排第16位。因此我不会称它为微小的贡献。我确信这个社团让我身心愉快，他们不会对我所做的文档修补有任何鄙视。
给新来者设置的标杆太高
当新的贡献者加入的时候，他们对项目，项目环境和项目所牵涉的技术的认知可能是千差万别的。人们经常犯的一个错误就是要求贡献者实现他们不可能实现的非常复杂的东西。这会把他们吓跑（许多人会感到羞耻或者不愿多说话了），而且他们因感觉到太笨不能提供帮助才跑走的。
在与人交流之前，你对他们的知识水平不应有任何假设。这就会使我们避免出现上述情况。在对他们技术进行评估时，你还应当十分敏锐，因为某些人会因为你太低估他们而感到懊恼。
一旦技术级别得到正确地评估（几次交流应该足够了），你需要把贡献者引导到正确的级别上，这样他或者她才能施展才能。要精通这个需要时间和经验，否则有人会在你的评估过程中出走，不过这是每个维护者必须要走的道路。
无论项目怎么样，引导都是欢迎项目的新加入者非常重要的一项工作。我确定它也非常适合非自由软件。
要求人们牺牲掉他们的业余生活
根据项目和内容的不同，这是变化很大的一方面，但是这方面确实是很重要的。作为一个自由的软件项目，许多人为此做出贡献都依赖于自己的意愿和业余时间，你不能要求他们必须为此作出大的牺牲，这根本不会起作用。
最糟糕的行为是要求人们飞5 000公里在某个地方见面来讨论这个项目。这会把贡献者们放到一个不公平的位置，基于他们的能力使他们离开家一周，乘坐飞机、轮船、汽车或者火车，租一间宾馆等等。这是不好的，每一件事都应该避免为了让人参加并觉得身在项目，融入项目而要求人做那些事。不要误会我的意思：我不是说社交活动应该被禁止，相反地。仅仅是当讨论任何项目时，避免排除人（的参与）。
这同样适用于任何其他形式的个人参与变得复杂的讨论，比如：IRC会议（对一些人来说计划好一小时是困难的，尤其是依赖于他们住在不同的时区里），视频会议（尤其是使用不免费的网络软件）等等。
每一件要求人们在项目里基本的互动交流的事，以一种在某个时间段内同步的行为都会给他们带来限制，会使他们觉得不舒服。
最好的媒介仍然是电子邮件和异步的的派生物（bug追踪器等），因为他们是异步的，并且允许人按照他们自己的节奏和时间来工作。
不具有（或者不暗含）编码指南
随着越来越多的社团向比他们过去广泛的多的、非常庞大的受众开放，编码指南似乎成为非常时髦（和敏感）的问题。
事实上，所有社团都有编码指南，有的是白纸黑字，有的是无意识的存在在每个人的大脑中。它的形式随社团大小和文化而变。
现在，根据社团规模以及如何舒适地推广编码指南，你可能需要像Debian那样编写编码指南文档。
具有编码指南不会让整个项目社团魔幻般地成为一批遵循编码指南的可爱的人。不过它可以在你需要的时候成为你可谈及的很有意思的话题。这也有助于向某些人表明在这个项目中他们的行为不受欢迎，而且即便在通常没有人遵循的情况下，它可以降低可能出现的排斥，这也是很难得的用武之地。
我认为对小一点的项目而言不一定非需要这样一份文档。然而你必须要记住你自己的行为是暗含的编码指南的源泉。领导者与其他成员的交流方式为项目搭建了整个社交氛围。请不要低估它。
当我们开启Ceilometer项目的时候，我们暗暗地遵循了已经存在很久的OpenStack编码指南，不过这个标杆设置的可能有点高。正是由于友好、欢迎和开明的思想，我们获得了相当高的多样化得分，我们核心团队中女性高达25%，这远远高于OpenStack和大多数开源项目中女性目前所占比率。
让那些非英语母语的人感觉到自己是局外人
认识到绝大多数自由软件项目是把英语做为基本交流语言这一点是非常重要的。它含有这样的理念：它是通常交谈时所用语言，而且说英语似乎才是正确的。
然而，绝大多数黑客都是非英语母语者。其中许多人不能流利地说英语。这意味着他们交流和进行一场对话的速度非常低，这会让一些人，尤其是英语为母语的人沮丧万分。
这种现象的论证可以在社会事件中找到答案（比如会议）人们在争论中的地方。对于人们来说，难以用英语表达他们的想法，与以适当的语速进行沟通，使得对话和语义翻译很慢。最糟糕的事情是，在这种场合下，英语本地说话人打断人们说话并且忽略他们，只是因为他们说的太慢。我能理解，这样会很令人沮丧的，但是这里问题不是非本地人说英语，它是作为媒介传递，不会使得你的同伴与同一水平的人以口头表达。
从较小范围来说，相同参与IRC会议的人，会相关同步的。在我看来，完全异步的媒介不会有这个缺陷，这就是为什么会变得完美。
没有观点，就没有代表
在开源工程中，两个最常见的错误：看到维护人员在与工程增长作斗争，这时有人尝试去帮助他们。
说句真心话，当贡献者的流量开始进来，增加新特性，询问反馈与方向，一些维护人员惊呆了，不知所措。结果使得他们十分沮丧，因此可能会失去他们。
项目要有愿景并把它进行传达是非常重要的。让贡献者明白在项目中你需要什么或者你不需要什么。以一种清晰的（但非咄咄逼人的）态度传达愿景是降低贡献者之间争吵的良好方式。他们很快就会知道是否要上你所驾驶的这条船，明白是否是他们所期望的东西。这样你才是一个好的船长。
如果他们选择与你一起工作和贡献，那么你应当信任他们，即刻尽你所能委派你应该负有的部分责任给他们。你过去常常负有的责任有：审核补丁、完成某些子系统、修补漏洞、编写文档。让参与者自己拥有项目的某个完整的部分，这样他们就想你一样感到责任重大，会精心维护它。与此相反，即做一个控制狂，这样会让你的开源软件处于孤立无援的状况。
而且没有项目会按照这种方式成长并取得成功的。
当Uli Schlachter在2009年给awesome发送第一个补丁时，我有许多工作要做。我必须审核这个补丁，而且，我已经因为要设计新版的awesome和日常工作而非常的忙！Uli的工作并不完美，我必须亲自进行修补。工作太多了，我该作那个呢？几分钟后，我回复了他：给了他应做的工作的清晰计划和我对他工作的想法。
Uli做出了回应，发送了几个补丁，并对项目进行了改进。你知道今天Uli在做什么吗？他从2010年起就替代了我管理着awesome的窗口管理器项目。我一直试图转达我的愿景、委派我的责任，接着就退休！
本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接。
2KB翻译工作遵照
CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。
2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务
