Kodi 是一个非营利性的开源爱好项目，由志愿者在业余时间开发，没有任何金钱收益。 致力于 Kodi 的开发团队鼓励任何人提交源代码补丁，以修复错误、添加新特性/功能或改进现有功能。 感谢对源代码的任何和所有贡献，但请理解，不能保证您的补丁会被接受并实施到 Kodi 中。 如果您希望在实施功能或改进之前获得 Kodi 开发人员的意见，请在 kodi 论坛上展开讨论。最后，请理解我们可能需要一点时间来审查您的补丁，因此请耐心等待 - 干净且文档齐全的代码很可能会比凌乱或未记录的代码更快地被查看。

代码提交

请将所有代码提交作为“拉取请求”提交到 Kodi Github - 有关如何创建拉取请求的信息，请参阅以下部分。然后，为了获得一些关注，请在我们论坛的 development-section 发布一个描述补丁的新帖子。这样做可以与整个 Kodi 社区（包括非开发人员）就可能的改进/增强或添加以及错误/修复进行更公开的讨论。请注意，您提交的任何代码都将是 （c） Team XBMC。

最低要求

我们目前没有任何其他最低要求，除了代码在 LGPL 或 GPL 许可下，它是干净的，并且任何评论和文档都是准确的和英文的。

代码文档

虽然尚未成为所有 Kodi 源代码的标准，但请尝试使用 doxygen 内联注释至少记录代码的“公共”部分。 如果您要提交新的特性或功能，请在补丁中添加一个小的“readme.txt”，描述该功能的使用情况，该特性可能用作以后 wiki 中用户文档的基础。非常欢迎您在提交补丁后为 wiki 格式化此内容。

代码指南和格式约定

请咨询

所有代码都应努力与平台无关 - Kodi 是多平台软件，因此在实施之前，应与 Kodi 团队成员讨论任何特定于平台的功能。 理想情况下，主要功能应该在单独的分支中开发或以小增量开发，以便其他成员有机会在开发过程中查看代码并对其进行注释。

补丁格式

请不要发送完整的文件。这些需要手动比较才能看到变化，这使得评论更难且不太可能发生。此外，一旦其中一个文件发生更改，您的版本就会变得更加难以应用，从而降低其被接受的机会。为 Kodi 制作补丁时请遵循以下简单规则：

1. 充分利用 git 的潜力。最好的办法是在 Kodi github 上分叉 Kodi 项目，从那里分支，然后在 HEAD 上开发你的补丁。请参阅 github 上的优秀文档以获取此方面的帮助。

2. 确保每个提交尽可能简单且自包含。也就是说，在每次提交时构建并构建所需功能的提交系列比一次更改很多东西的单个大型提交要好得多。

3. 当你更改需要重新缩进的函数时，最好在一次提交中完成功能更改，第二次提交进行修饰重新缩进。

4. 检查你的提交是否有不必要的外观更改，例如空格更改，尤其是行尾的空格。

5. 添加了 Doxy 和新函数，特别是当它们被添加到类的公共 API 时。如有必要，还可以参加 Doxy 课程。重要的是函数应该做什么，参数值是什么（加上任何默认值）以及返回代码是什么。

6. 确保在合理的情况下保持恒定。

7. 如果您实现新功能或修改现有功能的行为，请不要忘记在 wiki 文档中指出是否需要进行任何更改，最好在您的补丁系列被接受后执行这些更改。

8. 完成后，推送到您的 github 存储库并针对主 Kodi 存储库执行拉取请求。有关更多信息，请参阅 github 上的优秀文档。

9. 给我们几天的时间来反应。我们尝试尽快审查补丁，但不幸的是，我们的工作经常超负荷，无论是与 Kodi 相关的还是我们的日常生活。如果您的补丁似乎被忽略了，请在论坛的开发部分发布提醒以征求意见，或者作为对原始补丁票的回复，提及您被忽略了 - 我们对您的工作感兴趣，最终会接受或拒绝它，并解释我们喜欢和不喜欢您的补丁的哪些方面。请注意，在我们提交补丁之前，我们通常会要求您对补丁进行更改以使其可接受，因此请实施这些更改，并使用您所做的更改更新您的分支。其中一些更改可能看起来微不足道，但我们需要做的工作越少，它到达 GIT 的速度就越快。

10. 享受为 Kodi 🙂 开发的乐趣

外部链接

• 软件版本和良好的修补实践 HOW-TO 补丁最佳实践的优秀指南。