通过

参与语义内核

  • 项目

可以通过提交问题、开始讨论和提交拉取请求（PR）来参与语义内核。 贡献代码非常感激，但仅仅为遇到的问题提出问题也是一种很好的贡献方式，因为它帮助我们集中精力。

报告问题和反馈

我们始终欢迎 Bug 报告、API 建议和总体反馈。 由于我们使用 GitHub，因此可以使用“问题和讨论”选项卡开始与团队的对话。 下面是提交问题和反馈时的一些提示，以便我们可以尽快响应你的反馈。

报告问题

SDK 的新问题可以报告在我们的 问题列表中，但在提出新问题之前，请搜索问题列表以确保它尚不存在。 如果语义内核文档（此站点）出现问题，请在语义内核文档存储库中提出问题。

如果 确实 发现了想要报告的内容的现有问题，请在讨论中包括你自己的反馈。 我们还强烈建议投票（👍 反应）原始帖子，因为这有助于我们在积压工作中优先考虑热门问题。

编写良好的 Bug 报告

良好的 bug 报告使维护人员更容易验证和根本原因的根本问题。 bug 报告越好，问题就越快。 理想情况下，bug 报告应包含以下信息：

  • 问题的概要说明。
  • 最小 复制，即重现错误行为所需的最小代码/配置大小。
  • 预期行为的说明，与观察到的实际行为形成对比。
  • 有关环境的信息：OS/分发、CPU 体系结构、SDK 版本等。
  • 其他信息，例如，它是以前版本的回归吗？ 是否有已知的解决方法？

创建问题

提交反馈

如果你对语义内核有一般反馈或有关如何使其变得更好的想法，请在我们的 讨论板上分享它。 在开始新讨论之前，请搜索讨论列表以确保它尚不存在。

如果你对语义内核有疑问，建议使用 创意类别 （如果想要共享特定想法）和 Q&A 类别 。

还可以通过加入 语义内核不和谐服务器，在不和谐社区中开始讨论（并共享已创建的任何反馈）。

开始讨论

帮助我们确定反馈的优先级

我们目前使用向上投票来帮助我们在积压工作中确定问题和功能的优先级，因此请向上投票，你希望查看已解决的问题或讨论。

如果你认为其他人会受益于一项功能，我们还鼓励你要求其他人对问题进行投票。 这有助于我们确定影响大多数用户的问题的优先级。 你可以通过共享指向问题或讨论的链接，让同事、朋友或 社区 对问题进行投票。

提交拉取请求

欢迎对语义内核的贡献。 如果存在 bug 修复或要参与的新功能，请按照以下步骤提交拉取请求（PR）。 之后，项目维护人员将查看代码更改，并在接受后合并这些更改。

建议使用以下工作流参与语义内核（这是语义内核团队使用的相同工作流）：

  1. 为工作创建问题。
    • 可以跳过此步骤进行简单更改。
    • 如果存在现有问题，则重复使用该主题上的现有问题。
    • 通过讨论问题中的讨论，从团队和社区获得你建议的更改是一个很好的协议。
    • 明确说明要执行实现的问题。 这样，我们就可以向你分配问题，并确保其他人不会意外处理该问题。
  2. 在 GitHub 上创建存储库的个人分支（如果还没有）。
  3. 在分支中，创建主分支（git checkout -b mybranch）。
    • 为分支命名，以便它清楚地传达你的意图，例如“issue-123”或“githubhandle-issue”。
  4. 对分支进行更改并提交。
  5. 添加与更改对应的新测试（如果适用）。
  6. 使用更改生成存储库。
    • 确保生成干净。
    • 确保测试全部通过，包括新测试。
  7. 针对存储库 的主 分支创建 PR。
    • 说明中正在解决哪些问题或改进状态。
    • 验证是否通过了所有持续集成检查。
  8. 等待代码维护者的更改的反馈或批准。
  9. 当区域所有者已注销并且所有检查均为绿色时，PR 将合并。

参与时 Dos 和 Don'ts

下面是 Dos 和 Dos 列表，建议在参与语义内核时尽快查看和合并更改。

请执行以下操作：

  • 请 遵循标准的 .NET 编码样式 和 Python 代码样式
  • 如果项目或文件的当前样式与一般准则存在分歧，请 优先考虑要更改的项目或文件的当前样式。
  • 添加新功能时，请 包括测试。 修复 bug 时，首先添加一个测试，突出显示当前行为被破坏的方式。
  • 请 集中讨论。 当新的或相关的主题出现时，创建新问题通常比旁跟踪讨论更好。
  • 请 明确说明要执行该操作的问题。
  • 做 博客和/或关于你的贡献的推文！

注意 事项：

  • 不要让球队大拉取请求感到惊讶。 我们希望支持参与者，因此我们建议提交问题并开始讨论，以便我们可以在投入大量时间之前就方向达成一致。
  • 不要 提交未编写的代码。 如果发现适合添加到语义内核的代码，请在继续之前提交问题并开始讨论。
  • 不要 提交更改许可相关文件或标头的 PR。 如果你相信他们有问题，提出一个问题，我们很乐意讨论这个问题。
  • 不要 在不提交问题并首先与团队讨论的情况下创建新的 API。 向库添加新的公共外围应用是个大问题，我们希望确保正确。

重大更改

贡献必须保持 API 签名和行为兼容性。 如果想要进行更改会中断现有代码，请提出问题，讨论你的想法或更改（如果你认为有必要进行重大更改）。 否则，将拒绝包含重大更改的贡献。

持续集成 （CI） 过程

持续集成（CI）系统将自动执行所需的生成和运行测试（包括你还应在本地运行的版本）来运行 PR。 生成和测试运行必须干净，才能合并 PR。

如果 CI 生成因任何原因而失败，则 PR 问题将更新为一个链接，该链接可用于确定失败原因，以便可以解决此问题。

参与文档

我们还接受对 语义内核文档存储库的贡献。