Spark 專案改善提案 (SPIP)

SPIP 的目的是在整個開發過程中通知並讓使用者社群參與 Spark 程式碼庫的重大改善，以提高滿足使用者需求的可能性。

SPIP 應使用於重大的使用者介面或跨領域變更，而非微小的漸進式改善。如有疑慮，如果提交者認為變更需要 SPIP，那就需要。

什麼是 SPIP？

SPIP 類似於產品管理中常用的產品需求文件。

SPIP

• 是標記為「SPIP」的 JIRA 票證，建議對 Spark 進行重大改善或變更
• 遵循下方定義的範本
• 包含在 JIRA 票證和 dev@ 清單中關於提案的討論

目前的 SPIP

過去的 SPIP

誰？

任何社群成員都可以透過討論 SPIP 是否可能滿足其需求，以及建議 SPIP 來提供協助。

貢獻者可以透過討論 SPIP 是否可能在技術上可行來提供協助。

提交者可以透過討論 SPIP 是否符合長期專案目標，以及引導 SPIP 來提供協助。

SPIP 作者是撰寫 SPIP 並致力於將變更推動至整個流程的任何社群成員。SPIP 作者身份可以轉移。

SPIP Shepherd 是 PMC 成員，承諾在整個過程中引導提出的變更。儘管 Shepherd 可以委派或與其他提交者在開發過程中合作，但 Shepherd 最終對 SPIP 的成功或失敗負責。Shepherd 的責任包括但不限於

• 成為提議變更的倡導者
• 協助推動設計並在主要利害關係人之間達成共識
• 檢閱程式碼變更，確保變更遵循專案標準
• 從使用者取得回饋，並反覆進行設計和實作
• 維護變更的品質，包括在釋出變更前驗證變更是否符合 SPIP 的目標且沒有重大錯誤

SPIP 流程

提出 SPIP

任何人都可以使用以下文件範本提出 SPIP。如果您願意協助，至少參與討論，請提交 SPIP。

在建立 SPIP 之後，作者應寄電子郵件至 dev@spark.apache.org 通知社群 SPIP，並應在 JIRA 票證上進行討論。

如果 SPIP 太小或逐步進行，且應透過正常的 JIRA 流程進行，提交者應移除 SPIP 標籤。

SPIP 文件範本

SPIP 文件是一份簡短的文件，包含幾個問題，靈感來自 Heilmeier 教義問答

Q1。您要執行什麼？完全不使用術語表達您的目標。

Q2。此提案未設計為解決什麼問題？

Q3。目前如何執行，以及目前做法的限制是什麼？

Q4。您的方法有何創新之處，以及您為何認為它會成功？

Q5。誰在乎？如果您成功，會產生什麼影響？

Q6。風險是什麼？

Q7。需要多長時間？

Q8。中期和最後的「考試」是什麼，用於檢查是否成功？

附錄 A。建議的 API 變更。如果有的話，定義 API 變更的選用部分。必須考慮向後和向前相容性。

附錄 B。選用的設計草圖：如何達成目標？提供足夠的技術細節，讓貢獻者可以判斷其可行性。請注意，這不是完整的設計文件。

附錄 C。 可選的已拒絕設計：考量了哪些替代方案？為何拒絕？如果未考量任何替代方案，則需要對問題進行更多思考。

討論 SPIP

所有關於 SPIP 的討論都應在公開論壇中進行，最好是附加在 Jira 上的討論。任何線下進行的討論都應透過會議記錄摘要討論內容，讓大眾線上取得。

在討論期間，應從 PMC 成員中找出一個或多個負責人。

討論結束後，負責人應在 dev@ 清單上呼籲針對 SPIP 繼續前進進行投票。投票應開放至少 72 小時，並遵循典型的 Apache 投票程序，並在達成共識後通過（至少有 3 位 PMC 成員投 +1 票，且沒有 PMC 成員投 -1 票）。應將投票結果通知 dev@。

如果在一個月內沒有至少一位 PMC 成員承諾負責變更，則拒絕 SPIP。

如果提交者認為 SPIP 與長期專案目標不符，或在提案時不可行，則提交者應明確拒絕 SPIP，並提出技術理由。

實作 SPIP

實作應透過程式碼變更的標準程序進行。通常需要 SPIP 的變更也需要撰寫和檢閱設計文件。