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

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

SPIP は、小規模な段階的な改善ではなく、ユーザーに影響を与えるような主要な変更や、横断的な変更に使用されるべきです。疑わしい場合、コミッターが変更に SPIP が必要だと考えるなら、それは必要です。

SPIP とは？

SPIP は、プロダクトマネジメントで一般的に使用されるプロダクト要求仕様書に似ています。

SPIP とは

• Spark の主要な改善または変更を提案する、「SPIP」というラベルが付いた JIRA チケットです。
• 以下に定義されたテンプレートに従います。
• 提案に関する 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 を必要とする変更は、通常、設計ドキュメントの作成とレビューも必要とします。