贡献

贡献#

行为准则#

我们遵循Apache软件基金会的行为准则。保持开放、同理心、合作、好奇、措辞谨慎和简洁。我们不支持骚扰、不受欢迎的行为以及其他对我们社区有害的行为。

GitHub 首选#

开发者之间的交流应主要在GitHub的问题和拉取请求中进行，因为这最有助于异步沟通和未来的参考。

聊天！#

如有疑问，请访问Slack频道

报告错误和提出功能建议#

贡献的方式不仅仅是编写代码。提交错误报告，包括可用性问题，或者提出并投票支持大的功能改进想法，也是非常好的贡献方式！

请使用GitHub问题来报告和讨论主题并讨论它们。首先搜索开放/关闭的问题。

提交错误时，请提供一个完全可重现的代码片段。我们应该能够将其复制粘贴到Jupyter笔记本中并重现问题。

改进文档并分享示例#

文档总是可以更好：

  • 请随意扩展核心文档

  • 样式总是需要小心处理

  • 使用案例、集成和技术的示例总能帮助他人

欢迎提交PR#

我们很高兴接受PRs！

  • 查看good first issue和help wanted标签以获取开始的想法

  • 如果您有具体的内容想要添加，我们很乐意通过GitHub提供指导，告诉您从哪里开始以及添加什么内容以实现它

  • 数据集成、便捷方法、修复等都欢迎

  • 如有疑问，请在问题/拉取请求/Slack上提问！

Git 规范#

提交应该是原子的。每次提交——或压缩的PR——应该是一个自包含的添加/删除，以便我们可以根据需要挑选它们。

例如，如果你修复了一些错误，重构了一些代码，并在那里更新了依赖项…将其分成三个提交：fix()，refactor()，和garden()。

我们使用conventional commits。

消息应该看起来像：

fix(some feature name): verb action taken

提交类型包括 fix(), feat(), infra(), garden() / refactor(), docs(), security().

描述性的PRs和CHANGELOG.md

  • 每个PR都应详细说明添加/删除/修复和重大更改

  • 添加功能时，尝试在PR中添加示例

  • 作为PR的一部分，手动更新CHANGELOG.md

自动化

  • PRs 必须通过 CI，包括样式检查

  • 维护者负责发布