このガイドでは、コード変更の提出前に必要なことなど、Apache Sparkへの様々な種類の貢献を行うための最善の方法について説明します。

Sparkへの貢献は、コードを書くだけではありません。メーリングリストで新米ユーザーを支援したり、リリースをテストしたり、ドキュメントを改善したりすることも歓迎されます。実際、大幅なコード変更を提案するには、まず他の方法でコミュニティに貢献して経験と信頼を築くことが必要となる場合が多いです。このガイドは、効果的な貢献者になるためのものでもあります。

そのため、このガイドでは、長期的に関与したいと考えている新規貢献者が考慮すべき順序で貢献を整理しています。単にプルリクエストを開くだけでなく、他者を支援する実績を積み重ねましょう。

他のユーザーを支援することによる貢献

Sparkに貢献する素晴らしい方法は、user@spark.apache.orgメーリングリストまたはStackOverflowでユーザーの質問に答えることです。Sparkの新米ユーザーは常に多くいます。質問に答えるために数分を費やすことは、非常に価値のあるコミュニティサービスです。

貢献者は、このメーリングリストを購読し、Sparkの動向を把握しておく必要があります。質問に答えることは、コミュニティを支援するための優れた、そして目に見える方法であり、あなたの専門知識を示すことにもなります。

メーリングリストやStackOverflowのようなフォーラムでの効果的な議論への参加方法については、メーリングリストガイドを参照してください。

リリースをテストすることによる貢献

Sparkのリリースプロセスはコミュニティ主導であり、コミュニティのメンバーはdev@spark.apache.orgメーリングリストで新しいリリースに投票することができます。Sparkユーザーは、アナウンスを受け取り、新しいリリースでワークロードをテストし、新しいリリースで見つかったパフォーマンスまたは正確性の問題についてフィードバックを提供するために、このメーリングリストを購読することが推奨されます。

変更をレビューすることによる貢献

Sparkのソースコードへの変更は、GitHubのプルリクエスト（後述）を通じて提案、レビュー、コミットされます。誰でもここでアクティブな変更を表示してコメントすることができます。他の人の変更をレビューすることは、変更プロセスがどのように機能するかを学び、コードの様々な部分の活動に触れる良い方法です。タイポや小さなスタイル上の問題であっても、変更をレビューし、質問をしたり、問題点を指摘したりすることで貢献できます。また、オープンなPRを表示およびフィルタリングする便利な方法として、https://spark-prs.appspot.com/も参照してください。

ドキュメント変更による貢献

リリースドキュメント（https://spark.dokyumento.jp/docs/の下に表示されるドキュメント）への変更を提案するには、Sparkのdocs/ディレクトリにあるMarkdownソースファイルを編集します。このディレクトリのREADMEファイルには、ローカルでドキュメントをビルドして変更をテストする方法が示されています。ドキュメント変更の提案プロセスは、後述するコード変更の提案プロセスと同じです。

それ以外のドキュメント（https://spark.dokyumento.jp/docs/の下に表示されないドキュメント）への変更を提案するには、同様に、spark-websiteリポジトリのMarkdownを編集し、プルリクエストを開いてください。

ユーザーライブラリをSparkに貢献すること

JavaやScalaのアプリケーションが、JavaやScala自体には含まれていない膨大な数のライブラリやユーティリティにアクセスできるのと同様に、Sparkは豊富なライブラリエコシステムをサポートすることを目指しています。多くの新しい有用なユーティリティや機能は、コアSpark内ではなく、外部に存在するべきです。例えば、言語サポートはコアSparkの一部である必要がありますが、有用な機械学習アルゴリズムはMLlibの外部に存在することができます。

そのために、大規模で独立した新機能は、Spark自体への取り込みが拒否されることが多いですが、個別のプロジェクトおよびリポジトリとしてホストされ、spark-packages.orgコレクションに含まれることができますし、そうされるべきです。

バグレポートによる貢献

理想的には、バグレポートにはバグを修正するためのコード変更の提案が伴います。バグを発見した人がそれを修正する経験を持っていない場合もあるため、これは常に可能とは限りません。JIRAを作成することでバグを報告できますが、プルリクエストを作成する必要はありません（下記参照）。

ただし、バグレポートは、バグを理解し、分離し、理想的には再現するために十分な情報が含まれていないと有用ではありません。単にエラーに遭遇したからといって、バグを報告すべきではありません。下記のように、まずJIRAを検索し、Sparkのユーザー/開発者メーリングリストで検索して問い合わせてください。再現できないバグや単純なエラーレポートは閉じられる場合があります。

バグレポートに、バグがどのように導入されたか、どのコミットによって導入されたかについての説明があると非常に役立ちます。これにより、レビュアーはバグを容易に理解できます。また、プルリクエストがマージされた際に、バグ修正をどの程度バックポートすべきかをコミッターが判断するのに役立ちます。バグを修正するプルリクエストは、問題を根本原因に絞り込む必要があります。

パフォーマンスの低下も一種のバグです。パフォーマンスの低下を修正するプルリクエストには、問題が実際に修正されたことを証明するベンチマークを提供する必要があります。

データ正確性/データ損失のバグは非常に深刻であることに注意してください。対応するバグレポートJIRAチケットにcorrectnessまたはdata-lossというラベルが付いていることを確認してください。バグレポートが十分な注目を集めない場合は、dev@spark.apache.orgにメールを送信して、より多くの注目を集めてください。

新機能の提案も可能です。これらは通常、設計ドキュメントやコード変更などの詳細が伴わない限り役立ちません。大規模な新規貢献は、まずspark-packages.orgを検討するか（上記参照）、まずメーリングリストで議論してください。機能リクエストは拒否されたり、長期間アクティブでない場合に閉じられたりする可能性があります。

JIRAメンテナンスへの貢献

Apache Spark JIRAに寄せられる問題の sheer volume を考えると、一部の問題は重複していたり、時代遅れになったり、最終的に他の方法で修正されたり、再現できなかったり、詳細が不足していたりすることは避けられません。これらの問題を特定し、議論を進めたり、JIRAを解決したりすることで貢献することは有益です。ほとんどの貢献者は、JIRAを直接解決できます。問題が解決されたと確信があるかどうかを判断する際には、判断力を使用してください。ただし、変更は簡単に元に戻すことができます。疑わしい場合は、JIRAにコメントを残すだけで十分です。

JIRAを解決する際には、いくつかの便利な規約に従ってください。

  • Fixedとして解決：問題が解決された変更を指摘できる場合
    • Fix Versionを設定：解像度がFixedの場合のみ
    • Assigneeを設定：解決に最も貢献した人に設定します。通常は、問題を解決したPRを開いた人です。
    • 複数の人が貢献した場合、より「ジュニア」でコミッターではない貢献者に割り当てることを優先します。
  • 報告されたとおりにmasterで再現できない問題は、Cannot Reproduceとして解決します。
    • 以前のプルリクエストで解決されたことが明らかな場合は、Fixedも妥当です。それにリンクしてください。
  • 問題が別の問題と同じか、そのサブセットである場合は、Duplicateとして解決します。
    • 重複するJIRAにリンクすることを忘れないでください。
    • 重複として解決する問題は、活動や議論が少ないものを選ぶことを優先します。
  • 問題が明らかに時代遅れであり、開かれてから大幅に変更された問題やコンポーネントに適用される場合は、Not a Problemとして解決します。
  • 問題が意味をなさない（実行可能でない、例えばSpark以外の問題）場合は、Invalidとして解決します。
  • 一貫性のある問題であるが、それに取り組むサポートや関心が明確にない場合は、Won’t Fixとして解決します。
  • Umbrellas（包括的な課題）は、それ自体で実行可能な変更に対応しないコンテナ課題である場合、しばしばDoneとマークされます。

コード変更の貢献準備

貢献するものを選ぶ

Sparkは非常に活発なプロジェクトであり、平均して数時間ごとに新しいJIRAやプルリクエストがあります。レビューにはコミッターの数時間または数日かかる場合があります。貢献者が有用で、明確で、評価しやすく、基本的なチェックにすでに合格する変更に集中すれば、誰もが恩恵を受けます。

時には、貢献者がすでに特定の新しい変更やバグを念頭に置いている場合があります。アイデアを探している場合は、JIRAのスタータータスクリストを参照するか、user@spark.apache.orgメーリングリストに問い合わせてください。

続行する前に、貢献者は提案された変更が関連性があり、新しく、実行可能である可能性が高いかどうかを評価する必要があります。

  • コードを変更する必要があることは明らかですか？ JIRAとプルリクエストの提案は、明確な問題または変更が特定された場合にのみ適切です。Sparkの使用で単に困っている場合は、JIRAを提出したり変更を提案したりすることを検討する前に、まずメーリングリストを使用してください。不明な場合は、まずuser@spark.apache.orgに、可能性のある変更についてメールしてください。
  • user@spark.apache.orgおよびdev@spark.apache.orgメーリングリストのアーカイブで関連する議論を検索してください。多くの場合、問題は以前に議論されており、コード変更を必要としない解決策が見つかったり、どのような種類の変更が解決策として受け入れられないかが記録されている場合があります。
  • JIRAで既存の問題を検索してください：https://issues.apache.org/jira/browse/SPARK
  • 右上検索ボックスでspark [検索語]と入力します。論理的に類似した問題がすでに存在する場合は、新しいものを作成する代わりに、既存のJIRAとプルリクエストでの議論に貢献してください。
  • 変更の範囲は、貢献者の経験レベルに合っていますか？ 誰でもタイポの修正を提案する資格がありますが、コアスケジューリングロジックのリファクタリングにはSparkのより深い理解が必要です。一部の変更は、まず経験を積む必要があります（上記参照）。

Sparkのコア、またはSQLやCatalystのような非常に複雑で重要なモジュールへの変更は、正しく行うのが難しいことを再強調する価値があります。それらはより多くの精査を受け、他の変更よりも高いレビュー基準で判断されます。

MLlib固有の貢献ガイドライン

アルゴリズムの豊富なセットはMLLibにとって重要な目標ですが、プロジェクトをスケーリングするには、保守性、一貫性、コード品質が最優先されます。新しいアルゴリズムは次の条件を満たす必要があります。

  • 広く知られていること
  • 使用され、受け入れられていること（学術論文の引用や具体的なユースケースがこれを正当化するのに役立ちます）
  • 高度にスケーラブルであること
  • 十分に文書化されていること
  • 同じことを行うMLLibの他のアルゴリズムとAPIが一貫していること
  • 開発者サポートの妥当な期待があること。
  • 公開クラス、メソッド、変数に@Sinceアノテーションが付いていること。

エラーメッセージガイドライン

Sparkでスローされる例外は、標準化され、実行可能なエラーメッセージに関連付けられるべきです。

エラーメッセージは、以下の質問に答えるべきです。

  • 何が問題でしたか？
  • なぜ問題が発生したのですか？
  • どのように問題を解決できますか？

エラーメッセージを作成する際は、以下の点に留意してください。

  • 能動態を使用する
  • 将来のサポートの約束のような、時間に基づいた記述を避ける
  • エラーを説明し、提案を提供する際には現在形を使用する
  • 解決策が不明確な場合は、具体的な例を提供する
  • 非難的、審判的、または侮辱的な口調を避ける
  • 直接的である
  • ユーザーが見るエラーメッセージにプログラミング専門用語を使用しない

詳細については、エラーメッセージガイドラインを参照してください。

動作の変更

動作の変更とは、パブリックAPIを介した新しいリリースにおける、ユーザーから見える機能的な変更のことです。「ユーザー」とは、クエリやSparkプラグインを開発するだけでなく、Sparkクラスターをデプロイおよび/または管理する人も指します。新機能やバグ修正（クエリ結果やスキーマの修正、以前は誤った結果を返していたサポートされていないクエリのエラー化など）は、動作の変更と見なされます。ただし、パフォーマンスの改善、コードのリファクタリング、未リリースAPI/機能の変更は該当しません。

誰もが間違いを犯します。Spark開発者も例外ではありません。発生した欠陥は引き続き修正します。しかし、これらの動作の変更を伝えることは、Sparkユーザーがバージョンアップに備えられるようにするために重要です。PRが動作の変更を導入する場合、PRの説明に明記する必要があります。動作の変更により追加のユーザーアクションが必要になる場合、これは移行ガイド（SQLコンポーネントのdocs/sql-migration-guide.mdおよび他のコンポーネントの類似ファイル）で強調されるべきです。可能な場合は、以前の動作を復元するオプションを提供し、これらのオプションをエラーメッセージに記載してください。例をいくつか示します。

  • クエリ結果を変更するバグ修正。ユーザーは既存のデータを修正するためにバックフィルする必要がある場合があり、これらの正確性修正について通知される必要があります。
  • クエリスキーマを変更するバグ修正。ユーザーはデータパイプラインのテーブルスキーマを更新する必要がある場合があり、これらの変更について通知される必要があります。
  • Spark設定の削除または名前変更。
  • エラークラスまたは条件の名前変更。
  • パブリックPython/SQL/Scala/Java/R API（開発者APIを含む）への非加算的な変更。例えば、関数の名前変更、パラメータの削除、パラメータの追加、パラメータの名前変更、パラメータのデフォルト値の変更などです。これらの変更は一般的に避けるべきですが、必要に応じて、古い関数を非推奨にし、新しい関数を導入することでバイナリ互換性のある方法で行われるべきです。
  • Sparkのデプロイおよび管理方法への非加算的な変更：デプロイスクリプトの引数名の変更、REST APIの更新、設定ファイルの読み込み方法の変更など。

このリストは網羅的なものではありません。PRをレビューする人は、変更がリスクが高く、アップグレード中にユーザーを混乱させる可能性があると判断した場合、PR作成者に移行ガイドへの追加を依頼できます。

コードレビュー基準

コードの貢献方法を検討する前に、コードがどのようにレビューされ、なぜ変更が却下される可能性があるかを理解することが役立ちます。Googleのエンジニアリングプラクティスドキュメントにあるコードレビュー担当者向けの詳細ガイドを参照してください。簡単に言えば、多くの大きなプラス点があり、マイナス効果やリスクが少ない変更は、マージされ、迅速にマージされる可能性がはるかに高くなります。リスクが高く価値の低い変更は、レビューの繰り返しを受けるのではなく、却下される可能性が非常に高いです。

プラス点

  • 既存機能のバグの根本原因を修正する
  • 多数のユーザーに必要な機能を追加したり、問題を修正したりする
  • シンプルで、的を絞った
  • Python、Java、Scala間の一貫性を維持または改善する
  • テストしやすい；テストがある
  • 複雑さとコード行数を減らす
  • 変更がすでに議論されており、コミッターが認識している

マイナス点、リスク

  • バグの症状のみを「絆創膏」で覆う
  • 複雑な新機能（特にサポートが必要なAPI）を導入する
  • ニッチなユースケースにしか役立たない複雑さを追加する
  • Sparkで維持する必要はないが、外部でホストされ、spark-packages.orgでインデックス化できるユーザー空間機能を追加する
  • パブリックAPIまたはセマンティクスを変更する（めったに許可されない）
  • 大きな依存関係を追加する
  • 既存の依存関係のバージョンを変更する
  • 大量のコードを追加する
  • 1回の「ビッグバン」変更で多数の変更を行う

コード変更の貢献

コード変更を提案する前に、前のセクションを確認してください。このセクションでは、その方法について説明します。

コードを貢献する際、あなたは貢献があなたのオリジナル作品であり、プロジェクトのオープンソースライセンスの下でその作品をプロジェクトにライセンスすることを認めます。明示的に述べているかどうかにかかわらず、プルリクエスト、メール、またはその他の手段を通じて著作権で保護された資料を提出することにより、その資料をプロジェクトのオープンソースライセンスの下でライセンスすることに同意し、そうする法的権限があることを保証します。

Apache Spark™ソースコードのクローニング

最新の開発コードに興味がある場合、またはApache Sparkの開発に貢献したい場合は、Gitからmasterブランチをチェックアウトできます。

# Master development branch
git clone git://github.com/apache/spark.git

Sparkをダウンロードしたら、ドキュメントページでインストールおよびビルドの手順を確認できます。

JIRA

一般的に、SparkはJIRAを使用してバグや改善を含む論理的な問題を追跡し、GitHubプルリクエストを使用して特定のコード変更のレビューとマージを管理します。つまり、JIRAは何を修正または変更すべきか、および高レベルのアプローチを記述するために使用され、プルリクエストはプロジェクトのソースコードでどのようにその変更を実装するかを記述します。たとえば、主要な設計上の決定はJIRAで議論されます。

  1. 変更が関連する既存のSpark JIRAを見つけてください。
    1. JIRAの既存の問題に対応する変更を作成する場合、新しいJIRAを作成しないでください。既存の議論と作業に追加してください。
    2. JIRAからリンクされている既存のプルリクエストを探して、誰かがすでにJIRAに取り組んでいるかどうかを理解してください。
  2. 変更が新しい場合、通常は新しいJIRAが必要です。ただし、変更すべき内容と変更方法がほぼ同じである、些細な変更にはJIRAは必要ありません。例：Foo scaladocのタイポを修正
  3. 必要に応じて、新しいJIRAを作成してください。
    1. 説明的なタイトルを付けてください。「Web UIを更新」や「スケジューラの問題」は十分ではありません。「Kafka StreamingサポートはYARNクラスタモードで空のキューを処理できない」が良い例です。
    2. 詳細な説明を記述してください。バグレポートの場合、理想的には問題の簡単な再現手順を含めるべきです。新機能の場合は、設計ドキュメントが含まれる場合があります。
    3. 必須フィールドを設定してください。
      1. Issue Type。通常、Sparkで使用されるのはBug、Improvement、New Featureのみです。
      2. Priority。Major以下に設定してください。それ以上の優先度は通常、コミッターが設定するために予約されています。主な例外は、Blockerとしてフラグを立てることができる正確性またはデータ損失の問題です。JIRAは、Priorityフィールドの値で「サイズ」と「重要性」を混同する傾向があります。その意味はほぼ次のとおりです。
        1. Blocker：この変更なしではリリースは不可能であり、リリースは多数のユーザーの半分にとって使用不能になる。正確性およびデータ損失の問題は、対象バージョンにとってBlockerと見なされるべきである。
        2. Critical：この機能がないと、多数のユーザーの半分が重要な機能を利用できず、かつ/または回避策が困難である。
        3. Major：少数のユーザーが重要な機能を利用できないが、回避策がある。
        4. Minor：ニッチなユースケースで一部のサポートが欠けているが、使用に影響せず、または容易に回避できる。
        5. Trivial：あると嬉しい変更だが、それ以外では実質的な問題にはならない可能性が高い。
      3. Component
      4. Affects Version。バグの場合、問題が発生しているか、変更が必要であることがわかっているバージョンを少なくとも1つ割り当ててください。
      5. Label。広くは使用されていませんが、以下は例外です。
        • correctness：正確性に関する問題
        • data-loss：データ損失の問題
        • release-notes：変更の影響をリリースノートで言及する必要がある。JIRAまたはプルリクエストには、リリースノートに含めるのに適した詳細を含める必要があります。「Docs Text」を参照してください。
        • starter：新規貢献者向けの小さくて簡単な変更。
      6. Docs Text：リリースノートにエントリが必要な問題の場合、リリース管理者がリリースノートに含めるべき情報が含まれます。影響を受ける動作の簡単な概要と、動作がどのように変更されたかの詳細が含まれるべきです。JIRAが開かれたときに暫定的に記入することができますが、問題が解決されたときに最終的な詳細で更新する必要があるでしょう。
    4. 以下のフィールドは設定しないでください。
      1. Fix Version。これは、解決されたときにのみコミッターによって割り当てられます。
      2. Target Version。これは、PRがターゲットバージョンで修正のために受け入れられたことを示すためにコミッターによって割り当てられます。
    5. パッチファイルを含めないでください。実際の変更を提案するには、プルリクエストを使用します。
  4. 変更が大きい場合は、実装に進む前に、まずdev@spark.apache.orgで問題について議論することを検討してください。

プルリクエスト

Apache Sparkでプルリクエストを作成する前に、ブランチでテストがパスするかどうかを確認することが重要です。GitHub Actionsのワークフローがプルリクエスト/後続のコミットのテストを自動的に実行し、Apache SparkリポジトリのGitHub Actionsの限られたリソースに毎回負荷がかかるためです。以下の手順でプロセスを案内します。

  1. まだForkしていない場合は、https://github.com/apache/sparkのGitHubリポジトリをForkしてください。
  2. Forkしたリポジトリの「Actions」タブに移動し、「Build and test」と「Report test results」ワークフローを有効にしてください。
  3. Forkをクローンし、新しいブランチを作成してください。
  4. 変更の一環としてドキュメントやテストを追加または更新する必要があるかどうかを検討し、必要に応じて追加してください。
    1. テストを追加する際は、テストが自己記述的であることを確認してください。
    2. また、プルリクエストが特定のバグ修正を対象とする場合、テストにJIRA IDを記述することを検討すべきです。実際には、JIRAのタイプがバグである場合や、PRが既存のテストクラスにいくつかのテストを追加する場合に、通常追加されます。以下の例を参照してください。
      • Scala
        test("SPARK-12345: a short description of the test") {
  ...
      • Java
        @Test
public void testCase() {
  // SPARK-12345: a short description of the test
  ...
      • Python
        def test_case(self):
    # SPARK-12345: a short description of the test
    ...
      • R
        test_that("SPARK-12345: a short description of the test", {
  ...
  5. 変更の一環としてベンチマーク結果を追加または更新する必要があるかどうかを検討し、必要に応じてForkしたリポジトリでベンチマークを実行することによって追加し、ベンチマーク結果を生成してください。
  6. コードがまだコンパイルでき、テストに合格し、スタイルチェックに合格することを確認するために、./dev/run-testsで全てのテストを実行してください。スタイルチェックに失敗した場合は、後述のコードスタイルガイドを参照してください。
  7. コミットをブランチにプッシュします。これにより、Forkしたリポジトリで「Build and test」および「Report test results」ワークフローがトリガーされ、変更のテストと検証が開始されます。
  8. プルリクエストを開くには、apache/sparkのmasterブランチを対象とします（特別な場合を除き、他のブランチを対象とするPRは開かれません）。これにより、「On pull request*」（Sparkリポジトリ内）のワークフローがトリガーされ、「あなたの」Forkしたリポジトリでの成功したワークフロー実行が検索/監視されます（実行中の場合は待機します）。
    1. PRのタイトルは、[SPARK-xxxx][COMPONENT] Titleの形式にする必要があります。ここで、SPARK-xxxxは関連するJIRA番号、COMPONENTはspark-prs.appspot.comで表示されるPRカテゴリのいずれか、TitleはJIRAのタイトル、またはPR自体を説明するより具体的なタイトルになります。
    2. プルリクエストがまだ作業中であり、マージの準備ができていないが、レビューを容易にするためにGitHubにプッシュする必要がある場合は、コンポーネントの後に[WIP]を追加してください。
    3. 変更されているコードに取り組んだコミッターや他の貢献者を特定することを検討してください。GitHubでファイルを見つけて「Blame」をクリックすると、最後にコードを変更した人の行ごとの注釈が表示されます。PRの説明に@usernameを追加して、すぐに ping することができます。
    4. 貢献があなたのオリジナル作品であり、プロジェクトのオープンソースライセンスの下でその作品をプロジェクトにライセンスすることを記載してください。
  9. 関連するJIRA（もしあれば）は「In Progress」とマークされ、プルリクエストは自動的にリンクされます。JIRAのAssigneeである必要はありませんが、作業を開始したことをコメントしても構いません。
  10. プルリクエストに関連するSparkRの変更がある場合、AppVeyorはWindows上でSparkRをテストするために自動的にトリガーされます。これには約1時間かかります。上記の手順と同様に、失敗を修正し、新しいコミットをプッシュすると、AppVeyorで再テストが要求されます。

レビュープロセス

  • コミッターを含む他のレビュアーは、変更についてコメントし、修正を提案する場合があります。変更は、単に同じブランチにさらにコミットをプッシュすることで追加できます。
  • コミュニティ全体からの活発で丁寧で迅速な技術的議論が奨励されます。結果として、変更全体が却下されることもあります。
  • SparkのコアやSQLコンポーネントのような、よりクリティカルな部分への変更は、より多くのレビューを受け、他の変更よりも多くのテストと正確性の証明が必要になる場合があることを忘れないでください。
  • レビュアーは、「このパッチは良さそうだ」といったコメントで、変更がマージに適していることを示すことができます。Sparkは、パッチに対する技術的な署名の最も強力なレベルを示すためにLGTM（Looks Good To Me）の規約を使用しています。単に「LGTM」という単語をコメントしてください。これは、「徹底的に確認し、自分でパッチを作成した場合と同じくらい多くの責任を負う」ことを意味します。LGTMとコメントした場合、パッチに関するバグやフォローアップの問題の支援が期待されます。LGTMの一貫した、賢明な使用は、より広範なコミュニティからレビュアーとしての信頼を得るための素晴らしい方法です。
  • 時折、あなたのプルリクエストの変更と競合する他の変更がマージされることがあります。競合が解決されるまでPRはマージできません。これは、例えば、git remote add upstream https://github.com/apache/spark.gitでupstream変更を追跡するためのリモートを追加し、git fetch upstreamを実行し、その後git rebase upstream/masterを実行して手動で競合を解決し、その結果をブランチにプッシュすることで解決できます。
  • 数日間にわたって返信が滞るのではなく、議論に迅速に対応するように努めてください。

プルリクエスト/JIRAを閉じる

  • 変更が受け入れられた場合、マージされ、プルリクエストは自動的に閉じられます。関連するJIRAがあれば、それも同様に閉じられます。
    • まれにmaster以外のブランチに対してプルリクエストを開くように求められた場合、実際にはプルリクエストを手動で閉じる必要があることに注意してください。
    • JIRAは、クレジットを与える方法として、変更の主要な貢献者に割り当てられます。JIRAが迅速に閉じられず/割り当てられない場合は、JIRAにコメントしてください。
  • プルリクエストが最終的に却下された場合は、速やかに閉じてください。
    • …コミッターはPRを直接閉じることができないため。
    • プルリクエストは、コミッターが「このPRを閉じることを検討していただけますか？」のようなコメントをした場合、約1週間後にApacheの自動プロセスによって自動的に閉じられます。これは、コミッターがそれを閉じるように具体的に要求していることを意味します。
  • プルリクエストがあまり注目されていない、または全く注目されていない場合は、説明または変更自体を改善し、数日後に潜在的なレビュアーを再度pingすることを検討してください。含めやすい変更、つまり、より小さく/またはより侵襲性の低い変更を提案することを検討してください。
  • 数週間経ってもレビューはされたものの、取り上げられなかった場合、最も関連性の高いレビュアーからレビューを求めた後、または中立的な反応があった場合、結果は「ソフト却下」と見なされる可能性があります。この場合、PRを撤回して閉じるのが賢明です。
  • プルリクエストがJIRAの解決に適切なアプローチではないと判断されて閉じられた場合、JIRAは開いたままにしてください。ただし、レビューによってJIRAで特定された問題がプルリクエストで解決されないことが明らかになった場合（問題なし、修正しない）、JIRAも解決してください。

コードスタイルガイド

既存のコードベースのスタイルに従ってください。

  • Pythonコードの場合、Apache SparkはPEP 8に従いますが、例外が1つあります。行は79文字ではなく、最大100文字まで許可されます。
  • Rコードの場合、Apache SparkはGoogleのRスタイルガイドに従いますが、3つの例外があります。行は80文字ではなく、最大100文字まで許可され、関数名の制限はありませんが、最初の文字は小文字で、S4オブジェクト/メソッドが許可されます。
  • Javaコードの場合、Apache SparkはOracleのJavaコード規約と以下のScalaガイドラインに従います。後者が優先されます。
  • Scalaコードの場合、Apache Sparkは公式のScalaスタイルガイドとDatabricks Scalaガイドに従います。後者が優先されます。Scalaコードをフォーマットするには、PRを送信する前に./dev/scalafmtを実行してください。

不明な場合

何かの適切なスタイルがわからない場合は、既存のコードベースのスタイルに従うようにしてください。コード内に、あなたの機能を使用している他の例があるかどうかを確認してください。また、dev@spark.apache.orgリストで気軽に質問したり、コミッターに尋ねたりしてください。

行動規範

Apache Sparkプロジェクトは、Apache Software Foundation行動規範に従います。行動規範は、IRC、すべての公開および非公開メーリングリスト、課題追跡システム、Wiki、ブログ、Twitter、およびコミュニティが使用するその他のコミュニケーションチャネルを含む、Apache Software Foundationによって管理されるすべてのスペースに適用されます。対面イベント（カンファレンスなど）に特化した行動規範は、公開されているASFのハラスメント防止ポリシーに成文化されています。

この行動規範は、Apacheコミュニティに正式または非正式に参加するすべての人、または財団に関連する活動において、特にASFを代表する際に、財団への所属を主張するすべての人によって尊重されることを期待します。

このコードは網羅的または完全ではありません。これは、共同作業、共有環境、および目標についての共通の理解を簡潔にまとめたものです。私たち全員と私たちが参加する技術コミュニティを豊かにするために、文字通りだけでなく精神的にも従われることを期待します。

詳細および具体的なガイドラインについては、Apache Software Foundation行動規範を参照してください。

最新ニュース

アーカイブ