贡献¶
PROJ拥有广泛多样的用户群。一些是对地图投影和参考系统有深入了解的高技能测地专家，一些是GIS软件开发人员，另一些是GIS用户。所有用户，无论专业或技能水平如何，都有能力为项目做出贡献。以下是一些建议：
帮助那些没有经验的用户。
编写错误报告
请求新功能
为您喜爱的地图投影编写文档
修复错误
实现新功能
在下面的部分中，您可以找到一些关于如何贡献的指导方针。由于项目是在GitHub上管理的，所以大多数贡献都要求您拥有GitHub帐户。熟悉 issues 以及 GitHub Flow 这是一个优势。
帮助其他项目用户¶
支持PROJ的主要论坛是邮件列表。你可以订阅邮件列表 here 阅读档案 here .
如果你对PROJ的使用有疑问，邮件列表也是你可以去的地方。拜托 不 使用GitHub问题跟踪器作为支持论坛。你的问题更有可能在邮件列表中得到回答，因为关注这个问题的人比关注问题的人多。
添加错误报告¶
错误报告在 issue tracker 在GitHub的PROJ家里。写一个好的bug报告并不容易。但是修复一个文档不完整的bug也不是一件容易的事，所以请努力创建一个完整的bug报告。
一个好的bug报告至少包括：
快速解释问题的标题
对问题的描述以及如何再现问题
正在使用的项目版本
正在使用的任何其他相关软件的版本号，例如操作系统
描述已经做了什么来解决问题
预先提供的信息越多，开发人员就越有可能对解决问题感兴趣。提交错误报告后，您可能会收到后续问题。如果您有兴趣解决问题，请及时回答。
最后，请只提交与项目实际相关的错误报告。如果问题出现在使用PROJ的软件中，则可能是该特定软件的问题。在提交问题之前，确保它实际上是一个项目问题。如果你只能用PROJ的工具重现这个问题，那肯定是PROJ的问题。
功能请求¶
想在PROJ中增加一个新功能吗？在中提交新功能的详细说明 issue tracker . 请包括任何技术文档，可以帮助开发人员使新功能成为现实。这方面的一个例子可以是一篇公开发表的学术论文，其中描述了一个新的预测。另外，包含一个数值测试用例将使验证所请求特性的实现是否如您所期望的那样工作变得更加容易。
请注意，并非所有功能请求都被接受。
编写文档¶
项目急需更好的文件。任何文件的贡献都非常感谢。项目文档可在 proj.org . 网站是用 Sphinx . 对文件的贡献应如下所示： Pull Requests 在吉瑟布上。
如果您打算记录项目支持的预测之一，请使用 Mercator projection 作为模板。
代码贡献¶
法律用语¶
提交者是一线的把关者，负责保持代码库中不存在不正确贡献的代码。对于Proje用户、开发者和OSGEO基金会来说，重要的是避免向项目提交任何代码，而不需要在项目许可下明确授权。
一般来说，关键问题是，那些提供代码并包含在存储库中的人理解代码将在MIT/X许可下发布，并且提供代码的人有权贡献代码。对于提交者自己来说，对许可证的理解是非常明确的。对于其他贡献者，提交者应该验证理解，除非提交者非常满意贡献者理解许可证（例如频繁贡献者）。
如果出资是代表雇主（在工作时间、作为工作项目的一部分等）开发的，那么，重要的是雇主的适当代表理解，该代码将根据MIT/X许可证进行出资。该安排应与授权主管/经理等进行澄清。
代码应该由贡献者开发，或者代码应该来自可以正确贡献的源代码，例如来自公共域，或者来自兼容许可证下的开源项目。
所有异常情况都需要讨论和/或记录。
提交者应遵守以下准则，并可能对向源存储库不适当地提供代码承担个人法律责任：
确保出资人（可能是雇主）了解出资条款。
来自贡献者以外的源代码（例如从另一个项目改编的代码）应该清楚地标明原始源代码、版权持有者、许可条款等等。此信息可以在文件头中，但如果与常规项目授权（复制）不完全匹配，则也应添加到项目授权文件中。
现有的版权标题和许可证文本不应从文件中删除。如果版权持有者希望放弃版权，他们必须在版权信息被删除之前以书面形式向基金会提交。如果许可条款发生变更，则必须由版权所有人同意（以电子邮件形式书写即可）。
代码与许可证要求信贷，或披露给用户应添加到复制。
当向文件添加大量贡献（如大量补丁）时，应将作者/贡献者添加到文件的版权所有者列表中。
如果不确定是否有适当的改变对代码库有所贡献，请从项目指导委员会或基金会法律顾问处寻求更多信息。
额外资源¶
确认¶
这个 代码贡献 这一部分的贡献文件的灵感来自 PDAL's 以及 法律用语 节修改自 GDAL committer guidelines