Spark プロジェクト改善提案 (SPIP)

SPIPの目的は、開発プロセス全体を通してSparkコードベースへの主要な改善についてユーザーコミュニティに情報を提供し、関与させることで、ユーザーニーズが満たされる可能性を高めることです。

SPIPは、小さな段階的な改善ではなく、重要なユーザー向けまたはクロスカットの変更に使用されるべきです。疑問がある場合は、コミッターが変更にSPIPが必要だと考えるならば、SPIPが必要です。

SPIP とは？

SPIPは、製品管理で一般的に使用される製品要件文書に似ています。

SPIPとは

  • 「SPIP」というラベルの付いたJIRAチケットで、Sparkへの主要な改善または変更を提案することです。
  • 下記で定義されているテンプレートに従います。
  • JIRAチケットとdev@リストでの提案に関する議論が含まれています。

現在のSPIP

過去のSPIP

誰が？

SPIPが彼らのニーズを満たす可能性があるかどうかについて議論し、SPIPを提案することで、どの**コミュニティメンバー**でも貢献できます。

**コントリビューター**は、SPIPが技術的に実現可能かどうかについて議論することで貢献できます。

**コミッター**は、SPIPが長期的なプロジェクト目標と合致するかどうかについて議論し、SPIPを推進することで貢献できます。

**SPIP作成者**は、SPIPを作成し、プロセス全体を通して変更を推進することにコミットしているコミュニティメンバーです。SPIPの作成者は変更できます。

**SPIPシェパード**は、プロセス全体を通して提案された変更を推進することにコミットしているPMCメンバーです。シェパードは開発プロセスで他のコミッターに委任したり、協力したりできますが、最終的にはSPIPの成功または失敗の責任を負います。シェパードの責任には、以下が含まれますが、これらに限定されません。

  • 提案された変更の擁護者になる
  • 設計を推進し、主要な利害関係者間の合意を達成する支援をする
  • コード変更をレビューし、変更がプロジェクト標準に従っていることを確認する
  • ユーザーからのフィードバックを得て、設計と実装を繰り返す
  • 変更の品質を維持する。これには、変更がSPIPの目標を満たし、リリース前に重大なバグがないことを確認することが含まれます。

SPIPプロセス

SPIPの提案

下記の文書テンプレートを使用して、誰でもSPIPを提案できます。少なくとも議論に協力する意思がある場合にのみ、SPIPを提出してください。

SPIPが作成された後、作成者はdev@spark.apache.orgにメールを送信してコミュニティにSPIPを通知し、JIRAチケットで議論が行われます。

SPIPが小さすぎるか増分的なものであり、通常のJIRAプロセスで行われるべきであった場合、コミッターはSPIPラベルを削除する必要があります。

SPIP文書テンプレート

SPIP文書は、Heilmeier Catechismに触発された、いくつかの質問を含む短い文書です。

Q1. 何をしようとしていますか？専門用語を一切使用せずに目的を明確に記述してください。

Q2. この提案では、どのような問題を解決しようとしていませんか？

Q3. 現在どのように行われており、現在の慣習の限界は何ですか？

Q4. あなたのアプローチで何が新しく、なぜそれが成功すると思いますか？

Q5. 誰が気にしますか？成功した場合、どのような違いが生じますか？

Q6. リスクは何ですか？

Q7. どれくらいの時間がかかりますか？

Q8. 成功を確認するための中期および最終的な「試験」は何ですか？

付録A. 提案されたAPIの変更。APIの変更を定義するオプションのセクション。後方および前方互換性を考慮する必要があります。

付録B. オプションの設計スケッチ：目標はどのように達成されますか？コントリビューターが実現可能性を判断できるように十分な技術的な詳細を提供してください。これは完全な設計文書ではないことに注意してください。

付録C. オプションの拒否された設計：どのような代替案が検討されましたか？なぜ拒否されましたか？代替案が検討されていない場合、問題についてさらに検討する必要があります。

SPIPの議論

SPIPに関するすべての議論は、できればJiraに添付された議論の中で、公開フォーラムで行われるべきです。オフラインで行われた議論は、議論を要約した議事録を通じて、公開でオンラインで利用可能にする必要があります。

この議論の中で、PMCメンバーの中から1人以上のシェパードが選出されます。

議論が落ち着いた後、シェパードはdev@リストでSPIPの推進に関する投票を呼びかけます。投票は少なくとも72時間公開され、通常のApache投票プロセスに従い、コンセンサス（PMCメンバーから少なくとも3つの+1票、PMCメンバーから-1票がない）で可決されます。dev@には投票結果が通知されます。

1ヶ月以内に変更を推進することにコミットしているPMCメンバーが少なくとも1人存在しない場合、SPIPは拒否されます。

コミッターがSPIPが長期的なプロジェクト目標と合致しないと考える場合、または提案時点では現実的ではない場合、コミッターはSPIPに-1を明示的に付与し、技術的な理由を示す必要があります。

SPIPの実装

実装は、コード変更の標準プロセスで行う必要があります。SPIPを必要とする変更には、通常、設計文書を作成してレビューする必要もあります。

最新ニュース

アーカイブ