开源项目的最佳实践

标签: 综合新闻 | 发表时间:2015-12-13 08:32 | 作者:
出处:http://www.oschina.net/?from=rss

来自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


相关 [开源 项目 最佳实践] 推荐:

开源项目的最佳实践

- - 开源中国社区最新新闻
来自GitHub的 Phil Haack在Channel 9网站上举办了一次 座谈会,专注于谈论开源项目的最佳实践. Haack为与会者所提出的第一个话题是:对于那些希望加入自己的开源项目的开发者们,他们有哪些期望. Lagunas认为,提交issue是一种 与项目的维护者开展对话的重要方法. Rojas则指出,对于希望为项目作出贡献的开发者,首先浏览一遍未解决问题的列表也非常重要.

Python项目自动化部署最佳实践@搜狐

- - the5fire的技术博客
今天主要介绍下我们组刚刚开源出来的一个自动化部署的工具 essay ,功能在readme上已经介绍的很详细了,这篇文章只是介绍下外围的情况,产生的环境,一些决策的考虑. 事情还得从头开始说起,从那些自动化的fabric文件开始,也从我刚入职搜狐负责手机搜狐开发开始说起. 我参与开发的时候项目的部署已经是自动化了,不过并没有抽象出一个工具来.

jQuery最佳实践

- andi - 阮一峰的网络日志
上周,我整理了《jQuery设计思想》. 那篇文章是一篇入门教程,从设计思想的角度,讲解"怎么使用jQuery". 今天的文章则是更进一步,讲解"如何用好jQuery". 我主要参考了Addy Osmani的PPT《提高jQuery性能的诀窍》(jQuery Proven Performance Tips And Tricks).

PHP最佳实践

- xiangqian - 阮一峰的网络日志
虽然名字叫《PHP最佳实践》,但是它主要谈的不是编程规则,而是PHP应用程序的合理架构. 它提供了一种逻辑和数据分离的架构模式,属于MVC模式的一种实践. 我觉得,这是很有参考价值的学习资料,类似的文章网上并不多,所以一边学习,一边就把它翻译了出来. 根据自己的理解,我总结了它的MVC模式的实现方式(详细解释见译文):.

MongoDB最佳实践

- - NoSQLFan
将 MongoDB加入到我们的服务支持列表中,是整个团队年初工作计划中的首要任务. 但我们感觉如果先添加一项对NoSQL存储的支持,而不是先升级已支持的关系型数据库,可能对用户不太好,毕竟目前的用户都使用关系型数据库. 所以我们决定将引入MongoDB这项工作放到升级MySQL和PostgreSQL之后来做.

Dockerfile 最佳实践

- - DockOne.io
在容器领域,Docker 公司提出的容器镜像已经成为目前容器打包交付的事实标准. 构建镜像需要编写 Dockerfile,如何编写一个优雅的 Dockerfile 呢. 在 Docker 公司的官方文档中给出了一篇:《 Best practices for writing Dockerfiles》.

文章: Grails最佳实践

- - InfoQ cn
我在IntelliGrape工作,这是一家专门使用Groovy & Grails进行开发的公司. 本文是我们Grails项目遵循的最佳实践的基本清单,收集自邮件列表、Stack Overflow、博文, 播客和 IntelliGrape的内部讨论. 它们分为控制器、服务、Domain、视图、TagLib、测试和其他.

PHP最佳实践(译)

- - CSDN博客Web前端推荐文章
原文:  PHP Best Practices-A short, practical guide for common and confusing PHP tasks. 译者: youngsterxyf. 本文档最后审阅于2013年3月8日. 由我, Alex Cabal,维护该文档. 我编写PHP程序已有很长一段时间了,当前我 经营着 Scribophile,由认真作家组成的一个在线写作团体,  Writerfolio,为自由职业者提供的一个易用写作工具集,以及  Standard Ebooks,一个图文并茂、无数字版权管理的公共领域电子书出版商.

Log4j最佳实践(原) - Mainz

- - 博客园_Mainz's Blog
本文是结合项目中使用 Log4j总结的最佳实践,非转载. 网上可以找到的是这一篇《 Log4j最佳实践》. 本来 Log4j使用是非常简单的,无需多介绍其用法,这只是在小型项目中;但在 大型的项目中使用 log4j不太一样. 大型项目非常依赖日志,因为解决线上问题必须依靠log,依靠大量的日志.

再谈RestAPI最佳实践

- - 企业架构 - ITeye博客
http://www.javacodegeeks.com/2014/05/rest-api-best-practices-reloaded.html ,仅供学习和参考,转载请注明出处. 近一年半,我参与了2到3个项目的工作,这些项目涉及到大量供“外部”使用的Rest API,稍后我们再来解释为什么要将“外部”这个词放在引号之中.