TensorFlow RFC 流程

每個 TensorFlow 新功能都始於意見徵求 (RFC)。

RFC 是一份文件，描述需求以及將解決該問題的建議變更。具體來說，RFC 將

  • 根據RFC 範本格式化。
  • 以提取請求的形式提交至 community/rfcs 目錄。
  • 在接受之前，需經過討論和審查會議。

TensorFlow 意見徵求 (RFC) 的目的是讓 TensorFlow 社群參與開發，透過從利害關係人和專家那裡獲得回饋，並廣泛地溝通設計變更。

如何提交 RFC

  1. 在提交 RFC 之前，請與專案貢獻者和維護者討論您的目標並獲得早期回饋。使用相關專案的開發人員郵件列表 (developers@tensorflow.org，或相關 SIG 的列表)。

  2. 起草您的 RFC。

    • 閱讀設計審查標準
    • 遵循 RFC 範本。
    • 將您的 RFC 檔案命名為 YYYYMMDD-descriptive-name.md，其中 YYYYMMDD 是提交日期，而 descriptive-name 與您的 RFC 標題相關。(例如，如果您的 RFC 標題為平行小工具 API，您可以使用的檔案名稱為 20180531-parallel-widgets.md。
    • 如果您有圖片或其他輔助檔案，請建立 YYYYMMDD-descriptive-name 形式的目錄來儲存這些檔案。

    撰寫 RFC 草稿後，在提交之前先從維護者和貢獻者那裡獲得回饋。

    撰寫實作程式碼不是必要條件，但可能有助於設計討論。

  3. 招募贊助者。

    • 贊助者必須是專案的維護者。
    • 在張貼 PR 之前，在 RFC 中識別贊助者。

    您可以在沒有贊助者的情況下張貼 RFC，但如果在張貼 PR 後一個月內仍然沒有贊助者，則將關閉。

  4. 將您的 RFC 以提取請求的形式提交至 tensorflow/community/rfcs。

    在您的提取請求的註解中，使用 Markdown 包含標頭表格和目標章節的內容。如需範例，請參閱此 RFC 範例。包含共同作者、審查者和贊助者的 GitHub 帳號。

    在 PR 的頂部，識別評論期將持續多久。這應為自張貼 PR 起至少兩週。

  5. 透過電子郵件向開發人員郵件列表發送簡短描述、PR 連結和審查請求。遵循先前郵件的格式，您可以在此範例中看到。

  6. 贊助者將要求召開審查委員會會議，最早在 RFC PR 張貼後兩週。如果討論熱烈，請等到討論平息後再進行審查。審查會議的目標是解決次要問題；應事先就主要問題達成共識。

  7. 會議可能會批准 RFC、拒絕它，或要求變更後才能再次考慮。批准的 RFC 將合併到 community/rfcs 中，而被拒絕的 RFC 將關閉其 PR。

RFC 參與者

許多人參與 RFC 流程

  • RFC 作者 — 撰寫 RFC 並致力於推動其完成流程的一位或多位社群成員

  • RFC 贊助者 — 贊助 RFC 並將引導其完成 RFC 審查流程的維護者

  • 審查委員會 — 負責建議採用 RFC 的維護者群組

  • 任何社群成員都可以透過提供有關 RFC 是否能滿足其需求的意見回饋來提供協助。

RFC 贊助者

贊助者是專案維護者，負責確保 RFC 流程的最佳結果。這包括

  • 倡導建議的設計。
  • 引導 RFC 遵守現有的設計和樣式慣例。
  • 引導審查委員會達成富有成效的共識。
  • 如果審查委員會要求變更，請確保進行這些變更並尋求委員會成員的後續批准。
  • 如果 RFC 進入實作階段
    • 確保建議的實作符合設計。
    • 與相關方協調以成功完成實作。

RFC 審查委員會

審查委員會基於共識決定是否批准、拒絕或要求變更。他們負責

  • 確保已考慮到公眾回饋的實質性項目。
  • 將他們的會議記錄作為註解添加到 PR 中。
  • 提供他們決定的理由。

審查委員會的組成可能會根據每個專案的特定治理風格和領導方式而變化。對於核心 TensorFlow，委員會將由在相關領域具有專業知識的 TensorFlow 專案貢獻者組成。

社群成員和 RFC 流程

RFC 的目的是確保社群得到充分代表，並從 TensorFlow 的新變更中受益。社群成員有責任參與審查他們對結果感興趣的 RFC。

對 RFC 感興趣的社群成員應

  • 盡快提供回饋，以便有足夠的時間進行考慮。
  • 在提供回饋之前，徹底閱讀 RFC。
  • 保持禮貌和建設性。

實作新功能

一旦 RFC 獲得批准，即可開始實作。

如果您正在開發新程式碼以實作 RFC

  • 確保您了解 RFC 中批准的功能和設計。在開始工作之前提出問題並討論方法。
  • 新功能必須包含新的單元測試，以驗證該功能是否按預期運作。最好在編寫程式碼之前先編寫這些測試。
  • 遵循TensorFlow 程式碼樣式指南
  • 新增或更新相關的 API 文件。在新文件中參考 RFC。
  • 遵循您貢獻的專案儲存庫中 CONTRIBUTING.md 檔案中規定的任何其他指南。
  • 在提交程式碼之前執行單元測試。
  • 與 RFC 贊助者合作以成功完成新程式碼。

保持高標準

雖然我們鼓勵和讚揚每位貢獻者，但 RFC 接受的標準有意保持在高水平。新功能可能會在以下任何階段被拒絕或需要大幅修改

  • 相關郵件列表上的初始設計對話。
  • 未能招募到贊助者。
  • 回饋階段的關鍵異議。
  • 在設計審查期間未能達成共識。
  • 實作期間提出的疑慮 (例如：無法實現向後相容性、對維護的擔憂)。

如果此流程運作良好，則 RFC 預計會在早期階段而不是後期階段失敗。批准的 RFC 並不保證一定會實作，並且接受建議的 RFC 實作仍然需要經過通常的程式碼審查流程。

如果您對此流程有任何疑問，請隨時在開發人員郵件列表上提問或在 tensorflow/community 中提交問題。