Ansible 项目的源代码托管在 github 上 ,核心应用位于 github.com/ansible/ansible ,还有两个模块相关的子项目 github.com/ansible/ansible-modules-core. 如果你想知道一个模块是核心模块(“core”)还是额外模块(“extras”),查阅那个模块的网页文档.

在提交代码之前,先到 ansible-devel 邮件列表讨论一下特性问题,这可以有效的避免后期重复的工作.如果你不确定一个新的特性是否合适,先去开发邮件列表讨论一下,这样相对后来不得不修改一个 pull 请求更容易一些.

提交补丁的时候,一定要先运行单元测试“make tests”, 有一些基本的测试会自动运行当创建PR时候. 有更多的深入测试在测试/集成目录,分为 destructive 和 non_destructive,运行这些如果他们属于你的修改.他们被设置了标签,这样你就可以运行子集,一些测试需要云凭证和只有他们提供的时候才会运行.当添加修复 bug 的新的特性的时候,最好添加新的测试防止后期重新回滚.

使用 “git rebase” vs “git merge”(让git pull 别名为git pull -rebase 是一个好主意) ,来避免合并提交.也有一些基础测试可以运行在 “test/integration” 目录

为了保证历史代码的整洁,和对新假如的代码做更好的审计,我们会要求那些包含合并注释的重新提交.使用”git pull –rebase” 而不是 “git pull” 和 “git rebase” 而不是 “git merge”.同样确保有主要分支在使用其他的分支的时候,这样你才不会丢失注释信息.(Also be sure to use topic branches to keep your additions on different branches, such that they won’t pick up stray commits later.)

如果你犯错了,你不需要关闭你的 PR ,创建一个清洁的本地分支然后推送到github上面使用 –force 选项,轻质覆盖已存在的分支(在没人使用哪个分支作为参考的情况下是允许的).代码注释不会丢失,他们只是不会连接到现有的分支

然后我们将审阅你的贡献和参与你的问题等等.

因为我们有一个非常大的和活跃的社区,我们可能需要一段时间才能看到你的贡献,看一下后面的优先级部分来了解一下我们的工作队列.要有耐心,你的要求可能不会马上合并,我们也让 devel 能够使用,因此我们需要小心的测试pull 请求,而这需要花费时间.

补丁应该一直在开发分支之上.

记住,小而专请求更容易检查和接受,如果有实例,会更加帮助我们理解 bug 修复的工具和新的特性.

贡献可以是新的特性,像模块,或者是修复一些你或其他人发现的 bug .如果你对写新模块感兴趣,请参考 module development documentation.

Ansible的理念鼓励简单、可读的代码和 一致的,保守扩展, 向后兼容的改进.代码开发Ansible需要支持Python 2.6 +, 而代码模块运行需要在Python 2.4之上.请使用4个空格的缩进,而不是tab,(we do not enforce 80 column lines, we are fine with 120-140. We do not take ‘style only’ requests unless the code is nearly unreadable, we are “PEP8ish”, but not strictly compliant.)

你也可以通过测试和修改其他请求贡献,特别是如果它是一个你用着有趣的东西.请保持你的评论清楚和中肯,礼貌的和有建设性的, ticket 不是一个好开始讨论的地方( ansible-devel 和 IRC 是专门为 tickets 的).

技巧：为了更容易的从一个分支运行,source ”./hacking/env-setup” 就这样,不需要安装.