【51CTO.com快译】本次于奥斯汀召开的OpenStack峰会成为大家交换开源项目管理经验的***平台。事实证明，在经历了多年的社区参与及项目贡献工作之后，我对这方面事务还是有点儿发言权的。
不过，在今天的文章中，我打算以反面视角解读这一议题，即讨论开源项目管理当中不可取的种种作法。
1.给贡献者们增添烦恼
软件的开发者与维护者已经很忙了，所以过量的任务分配只会令人更加反感。事实上，开源领域***的误解之一就是，管理者往往以为铺天盖地的工作能够增加成员的参与感。这里说得直白一点，任务太多的话人家可能干脆就走人了。
我有位好朋友自2013年开始，就一直在为Ceilometer做出贡献。他的代码审查水平相当高，甚至能发现许多旁人意识不到的错误。项目管理团队最终让他晋升为核心审查员——而非单纯交给他更多任务。相信我，正是这种成就感让更多水平超群的技术人员继续留在项目当中。
2.只让人们参与枯燥的工作
在新人加入时，他们的动机往往不尽相同。部分用户希望通过贡献实现自身价值，也有些人是抱着学习的目的。但一般来说，人们其实比较抗拒始终接触***级的枯燥工作。如果管理者对于底层贡献者的感受毫不关心，那么无聊的内容再结合上一条提到的工作强度，肯定会让很多有志于开源的朋友迅速撤离。
3.不重视点滴贡献
改个错字也能算贡献?重新捋顺说明文档也能算贡献?这种心态在开源项目中并不罕见，但事实证明这类工作其实同样具有重要价值。
我个人就曾经在某个项目中负责修复文档错误，并在短时间之内发布了56项补丁、修正了部分bug并添加了些额外的功能。没人因为这些都是小事而看轻我，我也相信自己的工作确实拥有其价值。
4.为新人们设置过高的门槛
新人在参与开源项目时，其个人技术水平与从业经历往往千差万别。而很多管理者则直接给他们设置太过复杂的任务，这会让很多人遭遇挫折感，甚至觉得自己太笨而默默退出。
事实上，我们应当对新人进行技术水平评估(简单的交流应该能大致摸清其程度)，而后再为其分配力所能及但又有些挑战的工作。
5.要求人们牺牲自己的个人生活
大多数参与者只会拿出空闲时间进行开源贡献，这也是种非常健康的发展方式。请注意，不要指望项目成员牺牲个人生活进行贡献，那样既不现实也不利于项目的长期发展。
另外，过于频繁的视频会议乃至IRC会议也会让人感到厌烦。开源项目应当以人为本，并针对不同成员采取不同的交流及贡献方式。
6.潜在的行为准则太难融入
随着社区的发展，总会有种潜在的风格或者行事方式成为其个性标签。虽然这能让老鸟们乐在其中，但却也可能让新人们望而却步。
诚然，我们没必要就行为规范整理什么说明指南。但作为项目管理者，大家***是能让团队在保持个性的同时，充分考虑新人的感受。有事没事抛出一大堆内部用语或者“梗”，除了妨碍组织规模进一步扩大外真的没什么好处。
7.让非英语为母语的发言者感到毫无参与感
绝大多数开源项目社区会以英语进行交流，而这也成为大家协作的重要前提。然而，我们也应该考虑到部分技术人员来自非英语为母语的国家，这意味着他们可能很难与原有成员顺畅沟通，甚至因此受到打击。
面对这种方式，我们可以想想其他的办法进行替代。例如采用异步沟通方式，以文本为载体发送交流内容。如此一来，对方即可借助翻译软件大致理解其中的含义，同时也避免了开口说外语所带来的紧张感。
8.缺乏远见，不愿放权
这两项错误常见于各类开源项目。事实上，部分贡献者在加入后会开发新功能并向原有成员寻求反馈意见，这时负责维护的管理者可能意识到自己并不熟悉这部分技术，甚至因此决定退出。必须强调的是，项目的发展愿景与围绕这一点展开的沟通非常重要，这样我们才能让各位成员拥有相同的判断并了解是否应当留在队伍里发挥作用。
另外，就是应当将部分职责放心交给其他成员，而非全部由自己掌控。补丁审查、子系统设计、错误修正以及文档编写等都可以由专人负责。通过这种方式，每位成员都能感受到自己的作用与价值，并更为积极地留在项目团队当中。
9.不承认贡献者们的成绩
为开源项目做出贡献的方式多种多样，绝不限于编写代码。说明文档、bug调试、用户支持、体验设计、传播乃至翻译等等，这一切都是非常重要的工作。
因此，我们应当对非技术贡献予以充分的重视，并在建立团队成员阶层时小心再小心，以免遗漏了任何一类人才。
10.缺少感恩的心态
作为结尾，我要强调开源项目中感恩心态的重要性。这类项目往往是由参与者无偿构建而成的，作为管理者我们要为每个人的分享精神喝彩——当然，要用能让他们直观感受到的方式!
原文标题：Avoiding bad practices in open source project management，作者：Julien Danjou
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
