Contribution Guidelines for Developers

开发者代码贡献指南

欢迎！无论你是想要实现新的特性贡献给整个社区，还是想贡献简单的 Patch ，甚至只是想修改文档中的错别字，我们都非常欢迎并感谢您的帮助。

许可协议和行为准则

每个项目均有附带其对应的许可协议，在开始之前请确保您理解并同意对应的许可协议。另外请您遵守 Contributor Covenant 1.2 贡献者行为准则。如果您对此有疑问，请邮件咨询 [email protected] 。

获取代码和简易的构建说明

目前，Deepin 的所有源代码仓库均存放在 GitHub 上，故您只需要找到对应的项目，然后通过 git clone 或你喜欢的方式获取代码即可。

值得一提的是，Deepin 的各个项目的 master 分支均是开发分支，某个应用程序的 master 分支状态可能会依赖其他也同时处于 master 分支状态的版本，故如果直接获取 master 分支的代码并尝试编译并不总是保证能够编译通过，故当您从 git 仓库获取版本时，请在必要时先 git checkout 切换到对应您所需要的 tag 上，再尝试构建。

项目的对应 README.md 文档通常会有构建项目等相关的步骤描述，请参阅这些文档以帮助您构建项目。

提交 Pull Request

我们目前接受 GitHub Pull Request ，并且所有开发提交的合并均通过 Pull Request 进行，故你可以直接点击对应项目的 Fork 按钮得到你自己的 Fork ，在其上方进行提交，并在修改完毕后直接通过 GitHub 网页发起 Pull Request 即可。对于 Pull Request 的介绍和使用方式，可以参阅 GitHub 帮助文档中的 “关于 Pull Request” 部分。

如果您不希望使用 GitHub Pull Request，您依然可以通过提供 patch 或 diff 文件/代码片段的方式贡献代码，您可以以任何我们看得到的方式提交您的 patch 给我们，当然，我们总是建议优先考虑使用 Pull Request。

Pull Request 提交准则

为了确保代码质量和可维护程度，您所提交的 Pull Request 均需要经过自动构建和代码审核（Review）后才能合并进入，为了帮助您的代码能更方便快捷的并入，请您阅读并下方给出的注意事项：

确保代码可以被接受

我们很乐意帮助合并社区贡献者的代码，但并非所有类型的贡献都能够被并入，所以，在开始贡献代码前，请确保您的变更是可以被接受的。

我们可以接受缺陷修复（bug fix）或拼写更正 (fix typo) 类的问题修补，故您无需顾虑您的代码在符合下方准则的情况下是否可以并入。如果您希望对某个模块进行重构或增加额外的支持（如插件），或是希望实现新的特性并希望您的新特性合并进来，请先在开发者中心中发起一个新的 Issue 描述您的特性，然后与我们讨论相关的细节。

值得一提的是，我们的多国语言本地化支持并不通过此流程进行，如果您希望修正（非英语的）本地化翻译问题，或是增加新的本地化语言支持等相关内容，请移步 Transifex 平台。

如果您希望增加的特性在最终的讨论后还是无法被接受，也请希望您理解。如果您希望的话，也始终可以创建并维护您自己的衍生版 (fork) 来使用并共享给社区用户。

在确保您的修改可以被接受后，请注意下方的注意事项。

注意事项

代码风格
请您在开始前优先查看项目内有没有单独的代码风格规范文档，如果没有，请按照项目本身的代码风格编写新的代码。您可以到分类页面寻找相关文档。
Commit 信息规范
请参考 commit 信息格式规范，
一个 Pull Request 只做一件事
您可能会希望对某个项目做一系列的改动，但为了保证代码的提交信息的有序，也为了保证代码审核方便有序，请保证您的一个 Pull Request 只做一件事，对于不同的修改内容，请提交多个不同的 Pull Request 来做。