Orekit是免费软件，这意味着您可以自由使用源代码，无需支付费用，在您的应用程序中使用它，并且您可以改进它并将您的改进包含在下一个主流版本中。
考虑贡献？太好了！非常感谢您！我们非常欢迎新的贡献者加入我们的社区，帮助我们改进Orekit。本文档旨在帮助您在项目中迈出第一步。
您可以通过多种方式进行贡献：
参与论坛讨论
您可以参与论坛上的讨论，分享您对Orekit或航天飞行动力学的经验，为经验较少的用户提供帮助，或者简单地解释您在Orekit中缺少的功能。
我们希望每个人在与Orekit社区的互动中都能有良好的体验。请友善、亲切和关心他人。避免使用侮辱性或贬低性的语言，或者其他在专业环境中被认为不适当的行为。
报告错误或功能请求
您可以在我们的错误跟踪系统中报告错误。如果您对问题的定性有困难，请先在论坛上讨论。请记住：社区获得的信息越多，社区就越容易重现和修复问题。
错误跟踪系统也是报告功能请求的正确位置。我们不承诺考虑它们，更不会迅速采纳，因为我们的人力资源有限，而且有自己的优先事项。但是通过在跟踪系统中表达您的需求，您留下了记录，贡献者将能够在他们可用时实现该功能。
改进文档
您可以帮助我们改进现有文档，或者编写新的教程，以帮助用户更好地理解某些功能的使用。
除了教程，所有文档都与源代码一起嵌入。您可以在Orekit源代码存储库的src/site目录中找到它。此文档使用Markdown轻量级文本格式。它与源代码集成，以确保与源代码版本的一致性。因此，要贡献文档，您应该像贡献源代码一样进行操作（参见下一点），但无需编写测试。 ;)
如果您想增强教程或编写新的教程，请注意这些都是在一个名为Orekit教程的专用项目中进行管理的，该项目可在我们的Gitlab forge上找到。我们邀请您阅读有关这些教程的具体贡献指南。
改进或扩展源代码
您可以提供一个修复错误、改进现有功能或实现新功能的补丁。
如果您的贡献是较小的，并且既不影响Orekit的API也不影响其架构，请立即开始，按照本指南中的建议进行操作。对于其他所有情况，请先在论坛上介绍您计划进行的贡献。核心团队将能够分析您的建议，并确认它与项目的目标和范围以及正在进行和计划中的开发是兼容的。这也将防止您开始其他人已经在做的工作。这种对话有助于项目的顺利进行。即使核心团队成员在进行重大贡献之前也要进行这种练习。
由于Orekit用于运营目的，我们希望其源代码高效、可靠、稳健且易于维护。代码质量对我们来说甚至是优先考虑的。因此，我们强烈建议您阅读我们的开发指南。
我们使用一组工具（CheckStyle、SpotBugs、SonarQube等）来检查代码是否符合我们的编码规则，并对源代码进行静态分析。这个验证是由持续集成过程完成的。SonarQube建立了代码质量报告。由于在Eclipse中使用CheckStyle并配置SonarQube以考虑您的项目并不容易，您将在本指南中找到有关它们的详细说明。我们知道这些“细节”可能看起来很无聊，但源代码的质量决定了社区在维护它时的困难程度。因此，在接受贡献之前会检查代码质量。
准备好了吗？太棒了！
以下是如何进行您的第一次贡献：
连接到Orekit forge。默认情况下，为了限制垃圾邮件，您只能使用Github、Gitlab.com或BitBucket平台上的帐户进行身份验证。如果这对您有困扰，请告诉我们，我们将为您创建一个本地帐户。
通过在Orekit存储库的右上角点击“Fork”按钮，在我们的forge上创建您自己的存储库副本（即“Fork存储库”）。下图中的红色矩形即为此按钮：
在您的工作站上克隆您的存储库，并检出develop分支。
在您检出的存储库中，配置您的用户名和电子邮件地址，以便您的贡献可以被正确提交：
git config user.name "First Last"
git config user.email "address@domain.tld"
在您的fork上创建一个新的分支。
该分支的名称必须与未来的贡献相关。
例如，如果您想纠正一个问题，名称必须为issue-XXX，其中XXX表示问题编号。
如果您正在贡献一个新功能或纠正一个需要API更改的错误，请将develop分支作为源分支。
您的贡献将符合次要版本或主要版本（如果更改了API）。
重要提示：
如果您正在纠正一个不需要API更改的错误，请将最新的release-X.Y分支作为源分支。
您的贡献将符合补丁版本。
补丁版本发布更频繁，如果您从最新的发布分支开始工作，这将极大地简化发布经理的工作。
确保激活checkstyle（使用项目根目录下的checkstyle.xml文件），以帮助您遵循Orekit的编码规则（请参见下面的示例）。
进行开发和验证。
更新src/changes/目录中的changes.xml文件（请参考以前的条目以帮助您）。
注意：只有当您的工作计划为次要/主要版本时才执行此操作。
如果您的贡献可以添加到补丁版本中，则发布经理将更新changes.xml文件。
这个文件是一个巨大的合并冲突源，所以在进行发布时一次性处理它会更容易。
有关次要/主要版本和补丁版本之间的区别，请参见第5点。
运行所有Orekit测试以确保一切正常。
在您的分支上提交您的代码并将其推送到Gitlab（您可以进行多次本地提交，然后一次性推送它们）。
通过在forge上点击New merge request按钮，向存储库提交合并请求（Gitlab术语中的“MR”）：
Gitlab会要求您选择源存储库和分支（选择您的fork和工作分支）以及目标存储库和分支（选择Orekit官方存储库和develop分支）。请确保您的请求目标是官方存储库的develop分支。
Gitlab会通知核心团队成员您的合并请求。其中一位成员将尽快审查它。如果您的贡献似乎符合项目的期望，他或她将接受它。如果不符合，他或她将解释如何改进。然后，您可以改进您的贡献并推送新的提交，这些提交将自动添加到当前的合并请求中。
如果您在贡献过程中有任何问题，您也可以访问论坛并提问。社区越大，Orekit就会越好。主要规则是，所有打算包含在Orekit核心中的内容必须在Apache许可证第2.0版下分发。
Checkstyle是一个开发工具，帮助程序员编写符合编码标准的Java代码。它自动化了检查Java代码的过程，减轻了人类进行这个乏味（但重要）任务的负担。这使得它非常适合希望强制执行编码标准的项目。
可以通过使用Maven命令在Linux终端快速验证Checkstyle违规。贡献者可以在与pom.xml文件相同的文件夹中执行以下命令：
mvn checkstyle:check findbugs:check test
请注意，此命令还用于检查是否创建了Spotbugs警告（findbugs:check）以及测试是否正常运行（test）。
在集成开发环境（IDE）中安装Orekit时，配置checkstyle可能是一项困难的任务。然而，这是为了为库做出贡献的重要步骤。以下是配置Eclipse中的checkstyle所需遵循的步骤。
在Eclipse IDE中，选择帮助 -> 安装新软件...
在安装向导的右上方按下添加...按钮，将显示一个小弹出窗口，要求输入新软件站点的名称和位置。
按下添加按钮关闭弹出窗口。
在安装窗口中选择Checkstyle，然后点击下一步 >。继续进行向导，接受插件的许可证并安装它。
通过右键单击项目资源管理器面板中的空白处，选择属性来创建本地配置。
在属性弹出窗口中，选择Checkstyle条目。
在第二个弹出窗口（即本地检查配置），按照下图所示定义一个项目相对配置。浏览工作区以选择您的checkstyle.xml文件，并选中保护Checkstyle配置文件复选框以防止插件更改配置。
.
通过按下附加属性...按钮来定义属性，这将触发另一个弹出窗口，可以在其中配置属性，如下图所示。
在最后一个打开的弹出窗口中按下确定按钮，完成本地检查配置的创建。选择仍然打开的第一个弹出窗口中的主要选项卡。
在主要选项卡中，取消选中右上角的使用简单配置复选框。会出现一些按钮，允许删除默认的Sun检查全局配置（选择它并按下删除按钮），然后添加我们的本地配置（按下添加...按钮）。例如，使用src/main/java/.*.java将仅对src/main/java目录中的文件应用checkstyle，而不应用于src/test/java目录中的文件。
按下确定和应用并关闭完成安装。
通过右键单击项目资源管理器面板中的空白处，选择Checkstyle -> 激活Checkstyle。
与Eclipse IDE一样，在Intellij IDE中配置checkstyle可能会比较困难。以下是在Intellij IDE中配置checkstyle的步骤。
在Intellij IDE中，选择文件 -> 设置 -> 插件 -> 市场
安装完成后，重新启动IDE
选择文件 -> 设置 -> 工具 -> Checkstyle
点击“+”图标添加新配置。将弹出一个新窗口。按照下面的示例填写，使用自己的Orekit的checkstyle.xml文件位置。
点击下一步。将弹出一个新窗口以配置checkstyle.header.file。该值应与下面的license-header.txt相同。
点击完成。
checkstyle配置几乎完成。在主配置选项卡中，执行的最后一步是：
点击应用和确定完成安装。checkstyle将自动激活。
为了让SonarQube检查您的源代码质量，您必须在SonarQube中初始化项目。以下是如何操作。
使用您的Gitlab账户连接到我们的SonarQube实例。
第一次登录SonarQube时，SonarQube会提示您生成一个令牌。生成并将其安全保存在您的工作站上。如果您第一次登录时没有这样做，您可以稍后在SonarQube的帐户设置中进行操作： 我的帐户 -> 安全 -> 生成令牌。
然后连接到Gitlab。
转到您的分支的持续集成（CI）配置页面（设置 -> CI/CD -> 变量 -> 展开），并声明一个名为SONAR_TOKEN的变量。此变量的值必须是SonarQube提供的令牌的值。勾选掩码变量选项，然后点击添加变量。
SonarQube会在第一次提交时动态初始化项目，但此第一次提交必须在master分支上进行。您可以通过手动触发流水线来实现这一点。从Orekit 11版本开始，您只需转到流水线页面（项目主页 -> CI/CD -> 流水线），然后点击运行流水线，然后选择master分支，然后点击运行流水线按钮。然后等待半个小时，这大约是编译和运行测试所需的时间。
之后，您可以在您的工作分支上再次运行流水线。
如果您的工作分支是在Orekit 11.0之前的版本中创建的，则上述第5步将无法工作，因为持续集成脚本没有正确处理分支。在这种情况下，您需要从您的工作站上执行以下命令来在SonarQube中初始化项目：
$ cd orekit-repository
$ git switch master
$ export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64
$ mvn -s .CI/maven-settings.xml --batch-mode --errors --fail-at-end \
--show-version -DinstallAtEnd=true -DdeployAtEnd=true verify site
$ export SONAR_TOKEN=<your-sonarqube-token>
$ export CI_PROJECT_TITLE=Orekit
$ export CI_PROJECT_NAMESPACE=<your-namespace>
$ export CI_PROJECT_NAME=orekit
$ export SONAR_PROJECT_KEY="${CI_PROJECT_NAMESPACE}:${CI_PROJECT_NAME}"
$ export SONAR_PROJECT_NAME="${CI_PROJECT_TITLE} (${CI_PROJECT_NAMESPACE}:${CI_PROJECT_NAME})"
$ mvn -s .CI/maven-settings.xml --batch-mode --errors --fail-at-end \
--show-version -DinstallAtEnd=true -DdeployAtEnd=true sonar:sonar \
-Dsonar.login=$SONAR_TOKEN -Dsonar.projectKey="$SONAR_PROJECT_KEY" \
-Dsonar.projectName="$SONAR_PROJECT_NAME"