共用方式為

參與語意核心

  • 發行項

您可以提交問題、開始討論和提交提取要求（PR）來參與語意核心。 參與程序代碼非常值得讚賞，但只要針對您遇到的問題提出問題，也是貢獻的絕佳方式，因為它可協助我們專注我們的工作。

回報問題與意見反應

我們一律歡迎錯誤報告、API 提案和整體意見反應。 因為我們使用 GitHub，您可以使用 [問題和討論] 索引標籤來開始與小組交談。 以下是提交問題和意見反應時的一些秘訣，以便我們儘快回應您的意見反應。

回報問題

SDK 的新問題可以在我們的 問題清單中回報，但在您提出新問題之前，請搜尋問題清單，以確定問題不存在。 如果您有語意核心文件的問題（此網站），請在 Semantic Kernel 檔存放庫中提出問題。

如果您發現想要回報的內容現有的問題，請在討論中包含您自己的意見反應。 我們也強烈建議投票（👍 反應）原始帖子，因為這有助於我們在待辦專案中優先處理熱門問題。

撰寫良好的錯誤報告

良好的 Bug 報告可讓維護人員更輕鬆地驗證和根本原因的根本問題。 錯誤報告越好，問題就越快解決。 在理想情況下，錯誤報告應該包含下列資訊：

  • 問題的高階描述。
  • 最小重現，也就是重現錯誤行為所需的最小程式代碼/組態大小。
  • 預期行為的描述，與觀察到的實際行為形成對比。
  • 環境的相關信息：OS/散發、CPU 架構、SDK 版本等。
  • 其他資訊，例如是否為舊版的回歸？ 是否有任何已知的因應措施？

建立問題

正在提交意見反應

如果您有語意核心的一般意見反應，或有關如何使其變得更好的想法，請在我們的 討論區上分享。 開始新的討論之前，請搜尋討論清單，以確定該討論不存在。

如果您有想要共用的特定想法，如果您有關於語意核心的問題，建議您使用想法類別目錄。

您也可以加入 Semantic Kernel Discord 伺服器，以開始討論（並分享您已建立的任何意見反應）。

開始討論

協助我們排定意見反應的優先順序

我們目前使用向上投票來協助我們排定待辦項目的問題和功能優先順序，因此請對您想要查看的任何問題或討論進行投票。

如果您認為其他人會受益於某個功能，我們也建議您要求其他人對問題進行投票。 這有助於我們排定影響最多用戶的問題優先順序。 您可以藉由分享問題或討論的連結，向不和諧的同事、朋友或社群要求問題進行投票。

提交提取要求

我們歡迎對語意核心的貢獻。 如果您有想要參與的錯誤修正或新功能，請遵循下列步驟提交提取要求（PR）。 之後，專案維護人員會檢閱程式代碼變更，並在接受之後合併。

我們建議使用下列工作流程來參與語意核心（這是語意核心小組所使用的相同工作流程）：

  1. 為您的工作建立問題。
    • 您可以略過此步驟以進行簡單變更。
    • 如果有的話，請重複使用主題上的現有問題。
    • 透過使用問題中的討論，取得小組和社群的同意，即您提議的變更是不錯的變更。
    • 清楚指出您將接受實作的問題。 這可讓我們將問題指派給您，並確保其他人不會不小心處理此問題。
  2. 在 GitHub 上建立存放庫的個人分支（如果您還沒有分支）。
  3. 在您的分叉中，從 main 建立分支 （git checkout -b mybranch）。
    • 將分支命名為 ，以便清楚地傳達您的意圖，例如 「issue-123」 或 「githubhandle-issue」。。
  4. 對分支進行變更並認可。
  5. 如果適用，請新增對應至變更的新測試。
  6. 使用變更建置存放庫。
    • 請確定組建是乾淨的。
    • 請確定測試都通過，包括您的新測試。
  7. 針對存放庫 的主要 分支建立PR。
    • 描述中說明您變更所處理的問題或改進狀態。
    • 確認所有持續整合檢查都通過。
  8. 等候程式代碼維護人員對變更的意見反應或核准。
  9. 當區域擁有者已註銷，且所有檢查都為綠色時，您的PR將會合併。

參與時 Dos 和 Don's

以下是 Dos 和 Don's 清單，建議您在參與語意核心時協助我們儘快檢閱和合併您的變更。

Do's：

  • 請 遵循標準 .NET 程式代碼樣式 和 Python 程式代碼樣式
  • 如果專案或檔案與一般指導方針不同，請務必 優先處理您正在變更的項目或檔案的目前樣式。
  • 新增新功能時，請 包含測試。 修正 Bug 時，請從新增測試開始，以醒目提示目前行為如何中斷。
  • 請 讓討論保持專注。 當新的或相關的主題出現時，建立新問題通常比追蹤討論更適合。
  • 請 明確說明您要實作的問題。
  • 請撰寫 部落格和/或關於您的貢獻的推文！

注意 事項：

  • 不要 讓小組對大型提取要求感到驚訝。 我們想要支持參與者，因此建議您提出問題並開始討論，以便我們可以在投入大量時間之前就方向達成一致。
  • 請勿 認可您未撰寫的程序代碼。 如果您發現適合新增至 Semantic Kernel 的程式代碼，請在繼續之前提出問題並開始討論。
  • 請勿 提交修改授權相關檔案或標頭的 PR。 如果您認為他們有問題，請提出問題，我們很高興討論這個問題。
  • 請勿 在不提出問題並先與小組討論的情況下建立新的 API。 將新的公用介面區新增至文檔庫是件大事，我們希望確保正確。

重大變更

參與必須維護 API 簽章和行為相容性。 如果您想要進行會中斷現有程式代碼的變更，請提出問題，以討論您的想法或變更，如果您認為需要重大變更。 否則，將會拒絕包含重大變更的貢獻。

持續整合 （CI） 程式

持續整合 （CI） 系統會自動執行必要的組建和執行測試（包括您也應該在本機執行）的 PR。 必須先清除組建和測試回合，才能合併PR。

如果 CI 組建因為任何原因而失敗，PR 問題將會更新為連結，可用來判斷失敗的原因，以便加以解決。

參與檔

我們也接受語意核心檔存放庫的貢獻。