开源项目的最佳实践

来自GitHub的Phil Haack在Channel 9网站上举办了一次座谈会，专一于谈论开源项目的最佳实践。

本次会议的四位与会者都是开源项目的维护者，包括来自微软拉美区的听众布道经理（Audience Evangelism Manager）Carlos Rojas，用于建立松耦合、可维护、易测试的XAML应用的PRISM框架的做者Brian Lagunas，参与了多个开源项目工做的David Paquette，以及适用于C#及VB的分析器库CodeCracker的维护者Carlos dos Santos。

Haack为与会者所提出的第一个话题是：对于那些但愿加入本身的开源项目的开发者们，他们有哪些指望？Lagunas认为，提交issue是一种 与项目的维护者开展对话的重要方法。Rojas则指出，对于但愿为项目做出贡献的开发者，首先浏览一遍未解决问题的列表也很是重要。他们两位都提到了一种 很是实用的相关实践，即为某些未解决问题打上一个“随意领取”的标签，愿意参与这个项目的开发 者均可以领取这些问题。如今甚至还出现了一个“随意领取”的网站，那些潜在的贡献者们能够在此查到来自多个开源项目的各类可“随意领取”的未解决问题。Dos Santos表示，对他来讲，重要的是贡献者们可以为项目提交及修复bug，而且切实地用到这些项目。

全部与会者们都认为，贡献者应当避免将代码直接提交并推送至master分支。正确的作法是提交一个pull请求（PR）。Lagunas谈论了这 方面更多的细节内容，他所指望的方式是贡献者可以建立一个属于本身的分支，在其中实现某些特性或进行bug修复，而后添加相应的测试代码，最后再提交 PR。到了适当的时机，这个PR将经过某种集中式的筛选操做进行测试，一旦它经过了全部的测试，维护者就将组织一次复审，以确保其中的代码变动符合项目的 标准。

dos Santos表示，为了帮助贡献者们，保证他们的PR符合项目的标准，能够在项目的根目录中加入一个CONTRIBUTE.md文件，这种作法很是实用。 Haack也指出，若是项目中已有CONTRIBUTE.md文件存在，那么在贡献者提交PR时，GitHub就会自动显示一条信息，提醒贡献者去阅读该 文件。Lagunas特别强调了仔细阅读CONTRIBUTE.md文件的重要性，由于它有些时候会包含一些重要的内容，而这些内容并不局限于代码标准。 举例来讲，Prism项目要求贡献者经过一个永久的、不可撤消的贡献者许可协议（Contributor License Agreement），放弃所贡献代码的全部权，将其转交给该项目全部。若是贡献者自己就受雇于某些公司，那么这一点就变得尤其重要，由于说不定有贡献者 会回头宣称他对于该项目拥有知识产权。总的来讲，与会者都认为，项目的许可条款必须明肯定义，这一点十分重要。Paquette还特别强调，这种重要性不 仅限于贡献者，同时也包括项目的潜在用户。

Haack又将讨论的方向转回了原来的话题上，即如何确保PR不会对项目产生破坏。Lagunas提到了适用于.NET平台上的开源项目的一个免费服务appveyor，能够经过该服务对每一个PR进行构建与测试。Haack进一步表示，只要你的GitHub项目中没有什么特别古怪的问题，那么appveyor一般都可以正确地处理项目的各类依赖。

另外一个让人感兴趣的话题是项目的文档。Rojas表示，在项目中最低限度也要提供一个README.md文档。Haack以Prism的文档做为示 例，指出编写项目文档的正确方式，即经过readme文件说明整体状况，而后再经过其它文件描述各类细节。Rojas还提到了GitHub所提供的另外一个 工具wiki，他认为能够经过使用wiki有效地创建文档。

随后话题转向了开源的文化。开源社区在这方面存在着一个问题，若是贡献者出了某些差错，有时可能会换来一些粗暴的回应。与会者们都认为：应当以良好 的态度对待贡献者，认识到这些贡献者们的出发点是帮助这个项目。尤为某个PR或许是这个开发者第一次为开源项目贡献代码，那么项目维护者的沟通方式就可能 会直接影响到这名开发者从此看待开源项目的态度。

最后，全部的与会者们都表示，贡献者们应当努力尝试克服胆怯的心态，去寻找那些可以点燃本身激情的项目。不要忘记，开源的核心是协做。有许多人对于他们所维护的项目充满了热情和感情，尤为是看到有人在实际使用他们的项目，或是为这些项目做出贡献时。

查看英文原文：Best Practices for Open-source Projects

转载自：infoq.com/cn