このガイドは、コード変更の提出前に必要なものも含め、Apache Sparkへの様々な貢献方法を説明しています。
Sparkへの貢献は、コードを書くだけではありません。メーリングリストで新規ユーザーを支援したり、リリースをテストしたり、ドキュメントを改善したりすることも歓迎されます。実際、重要なコード変更を提案するには、通常、他の方法で貢献することでコミュニティ内で経験と信頼性をまず得る必要があります。これは、効果的な貢献者になるためのガイドでもあります。
そのため、このガイドでは、長期的に関与しようとする新規貢献者が検討すべき貢献を順序立てて説明します。プルリクエストを開くだけでなく、他者を助ける実績を築きましょう。
他のユーザーを支援することで貢献する
user@spark.apache.orgメーリングリストまたはStackOverflowでユーザーからの質問に答えることは、Sparkに貢献する素晴らしい方法です。常に多くの新規Sparkユーザーがいるため、数分間かけて質問に答えることは、非常に価値のあるコミュニティサービスです。
貢献者はこのリストを購読し、Sparkで何が起こっているかを最新の状態に保つためにフォローする必要があります。質問に答えることは、コミュニティを支援し、専門性を示す優れた方法です。
メーリングリストでの効果的な議論の参加方法、およびStackOverflowなどのフォーラムについては、メーリングリストガイドを参照してください。
リリースのテストを通じて貢献する
Sparkのリリースプロセスはコミュニティ指向であり、コミュニティのメンバーはdev@spark.apache.orgメーリングリストで新しいリリースに投票できます。Sparkユーザーは、このリストを購読して発表を受け取り、新しいリリースでワークロードをテストし、新しいリリースで見つかったパフォーマンスや正確性の問題に関するフィードバックを提供するように招待されています。
変更のレビューを通じて貢献する
Sparkソースコードへの変更は、GitHubプルリクエスト（後述）を介して提案、レビュー、コミットされます。誰でもここでアクティブな変更を表示し、コメントできます。他の人の変更をレビューすることは、変更プロセスがどのように機能するかを学び、コードの様々な部分のアクティビティを理解する良い方法です。変更をレビューし、質問したり、問題（タイプミスや小さなスタイルの問題など）を指摘したりすることで、支援できます。https://spark-prs.appspot.com/も参照してください。これは、開いているPRを表示およびフィルタリングするための便利な方法です。
ドキュメントの変更に貢献する
リリースドキュメント（つまり、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で発生した問題の膨大な量を考えると、必然的にいくつかの問題は重複しているか、時代遅れになり、最終的に別の方法で修正されるか、再現できないか、より詳細な説明が必要になるなどがあります。これらの問題を特定して解決することは、議論を進めることやJIRAを解決することによって役立ちます。ほとんどの貢献者は、直接JIRAを解決できます。変更は簡単に元に戻すことができるため、問題を解決できるかどうかについて十分な自信があるかどうかを判断してください。疑問がある場合は、JIRAにコメントを残すだけです。
JIRAを解決する際には、いくつかの便利な規則に従ってください。
- 問題を解決した変更を指摘できる場合は、**修正済み**として解決します。
- 解決策が「修正済み」の場合にのみ、修正バージョンを設定します。
- 解決策に最も貢献した人（通常は問題を解決したPRを開いた人）に担当者を設定します。
- 複数の人が貢献した場合、より「ジュニア」のコミッターではない貢献者に割り当てることを優先します。
- 報告されたとおりにマスターに対して再現できない問題については、**再現できません**として解決します。
- 以前のプルリクエストがそれを解決したことが明らかな場合は、「修正済み」も妥当です。それにリンクしてください。
- 問題が別の問題と同じか、そのサブセットである場合は、**重複**として解決します。
- それが重複するJIRAにリンクすることを確認してください。
- アクティビティや議論が少ない問題を重複として解決することを優先します。
- 問題が開設されて以来根本的に変更された問題やコンポーネントに適用される、明らかに時代遅れの問題と思われる場合は、**問題ではありません**として解決します。
- 問題が意味をなさない場合（たとえば、実行不可能な非Sparkの問題など）は、**無効**として解決します。
- それが首尾一貫した問題でありながら、それに対処することに対するサポートや関心が明らかにないことを示している場合は、**修正しません**として解決します。
- 傘は、それ自体で実行可能な変更に対応しないコンテナの問題である場合、頻繁に**完了**とマークされます。
コード変更への貢献の準備
貢献するものを選択する
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でスローされる例外は、標準化され、実行可能なエラーメッセージに関連付ける必要があります。
エラーメッセージは、次の質問に答える必要があります。
- 何が問題でしたか？
- なぜ問題が発生しましたか？
- どのように問題を解決できますか？
エラーメッセージを作成する際には、次のことを行う必要があります。
- 能動態を使用する
- 将来のサポートに関する約束など、時間に基づく記述を避ける
- 現在時制を使用してエラーを説明し、提案を提供する
- 解決策が不明な場合は、具体的な例を示す
- 非難する、批判する、または侮辱するような表現を避ける
- 直接的にする
- ユーザー向けのエラーメッセージには、プログラミング用語を使用しないでください。
詳細は、エラーメッセージに関するガイドラインを参照してください。
コードレビュー基準
コードへの貢献方法を検討する前に、コードのレビュー方法と変更が拒否される理由を理解することが役立ちます。Googleのエンジニアリングプラクティスドキュメントにあるコードレビュー担当者向け詳細ガイドを参照してください。簡単に言えば、メリットが多く、デメリットやリスクが少ない変更ほど、マージされやすく、迅速にマージされます。リスクが高く価値の低い変更は、マージされる可能性が非常に低く、レビューの繰り返しを受けるのではなく、完全に拒否される可能性があります。
メリット
- 既存機能のバグの根本原因を修正する
- 多くのユーザーが必要とする機能を追加するか、問題を修正する
- シンプルで的を絞っている
- Python、Java、Scala全体での一貫性を維持または向上させる
- 簡単にテストできます。テストがあります。
- 複雑さとコード行数を削減する
- 変更は既に議論されており、コミッターに知られている
デメリット、リスク
- バグの症状に対処するだけの応急処置
- 複雑な新しい機能、特にサポートが必要なAPIを導入する
- ニッチなユースケースにしか役立たない複雑さを追加する
- Sparkで維持する必要のないユーザー空間の機能を追加するが、外部でホストし、spark-packages.orgでインデックス付けできます。
- 公開APIまたはセマンティクスを変更する（めったに許可されない）
- 大きな依存関係を追加する
- 既存の依存関係のバージョンを変更する
- 大量のコードを追加する
- 一度に多くの変更を加える「ビッグバン」変更を行う
コード変更の貢献
コード変更を提案する前に、前のセクションを確認してください。このセクションでは、その方法について説明します。
コードを寄稿する際には、その寄稿があなたのオリジナル作品であり、プロジェクトのオープンソースライセンスに基づいてプロジェクトにその作品をライセンス供与することに同意したものとします。明示的に述べるかどうかにかかわらず、プルリクエスト、電子メール、その他の手段を介して著作権のある資料を送信することにより、あなたはプロジェクトのオープンソースライセンスに基づいて資料をライセンス供与することに同意し、そうする法的権限を有することを保証します。
Apache Spark™ソースコードのクローン作成
開発中の最新のコードを使用したり、Apache Sparkの開発に貢献したりすることに関心がある場合は、Gitからmasterブランチをチェックアウトできます。
# Master development branch
git clone git://github.com/apache/spark.git
Sparkをダウンロードしたら、インストールとビルドの方法については、ドキュメントページを参照してください。
JIRA
一般的に、SparkではJIRAを使用してバグや改善を含む論理的な問題を追跡し、GitHubのプルリクエストを使用して特定のコード変更のレビューとマージを管理します。つまり、JIRAは修正または変更する必要があるものと、上位レベルのアプローチを説明するために使用され、プルリクエストはプロジェクトのソースコードでその変更を実装する方法を説明します。たとえば、主要な設計上の決定はJIRAで議論されます。
- 変更に関連する既存のSpark JIRAを見つけます。
- JIRAにある既存の問題に対処するための変更を作成する場合、新しいJIRAを作成しないでください。代わりに、既存の議論と作業に追加してください。
- JIRAからリンクされている既存のプルリクエストを探して、誰かが既にJIRAに取り組んでいるかどうかを理解してください。
- 変更が新しいものである場合、通常は新しいJIRAが必要です。ただし、変更する内容と変更方法が事実上同じである些細な変更は、JIRAは必要ありません。例：
Foo scaladocのタイプミスを修正する - 必要に応じて、新しいJIRAを作成します。
- 説明的なタイトルを指定します。「Web UIの更新」または「スケジューラの問題」では不十分です。「Kafkaストリーミングサポートは、YARNクラスタモードで空のキューを処理できません」は適切です。
- 詳細な説明を記述します。バグレポートの場合、理想的には問題の簡単な再現が含まれている必要があります。新機能の場合、設計ドキュメントが含まれる場合があります。
- 必須フィールドを設定します。
- 問題の種類。一般的に、SparkではBug、Improvement、New Featureのみが使用されます。
- 優先度。Major以下に設定します。より高い優先度は、一般的にコミッターが設定するために予約されています。主な例外は、ブロッカーとしてフラグ付けできる正確性またはデータ損失の問題です。JIRAは残念ながら、優先度のフィールド値で「サイズ」と「重要性」を混同する傾向があります。それらの意味はおおよそ次のとおりです。
- ブロッカー：リリースが多数のユーザーにとって使用不能になるため、この変更なしでリリースすることは無意味です。正確性とデータ損失の問題は、対象バージョンに対してブロッカーと見なされる必要があります。
- クリティカル：この機能がないと、多数のユーザーが重要な機能を失い、回避策も困難です。
- メジャー：この機能がないと、少数のユーザーが重要な機能を失いますが、回避策があります。
- マイナー：ニッチなユースケースでいくつかのサポートが不足していますが、使用に影響を与えたり、簡単に回避できたりします。
- トリビアル：便利な変更ですが、そうでなくても実際には問題になる可能性は低いです。
- コンポーネント
- 影響を受けるバージョン。バグの場合、問題が発生していることがわかっているか、変更が必要である少なくとも1つのバージョンを割り当てます。
- ラベル。次の場合を除いて、広く使用されていません。
correctness：正確性の問題data-loss：データ損失の問題release-notes：変更の影響はリリースノートに記載する必要があります。JIRAまたはプルリクエストには、リリースノートに含めるのに適した詳細を含める必要があります。「ドキュメントテキスト」を参照してください。starter：新しい貢献者にとって適した、小さくシンプルな変更
- ドキュメントテキスト：リリースノートにエントリが必要な問題については、リリースマネージャーがリリースノートに含めるべき情報を含める必要があります。これには、影響を受ける動作の簡単な概要と、動作の変更に関する詳細を含める必要があります。JIRAを開いたときに暫定的に記入できますが、問題が解決したときに最終的な詳細で更新する必要がある可能性があります。
- 次のフィールドは設定しないでください。
- 修正バージョン。これは、解決済みの場合にのみコミッターによって割り当てられます。
- ターゲットバージョン。これは、コミッターによって、PRがターゲットバージョンによる修正のために承認されたことを示すために割り当てられます。
- パッチファイルを含めないでください。プルリクエストを使用して、実際の変更を提案します。
- 変更が大きな変更である場合は、変更を実装する前に、まず
dev@spark.apache.orgで問題に関する議論を検討してください。
プルリクエスト
Apache Sparkでプルリクエストを作成する前に、ブランチでテストがパスできるかどうかを確認することが重要です。これは、GitHub Actionsのワークフローがプルリクエスト/後続のコミットのテストを自動的に実行し、各実行がApache SparkリポジトリのGitHub Actionsの限られたリソースに負担をかけるためです。次の手順でプロセスを進めます。
- まだ行っていない場合は、https://github.com/apache/sparkでGitHubリポジトリをフォークします。
- フォークされたリポジトリの「Actions」タブに移動し、「ビルドとテスト」および「テスト結果のレポート」ワークフローを有効にします。
- フォークをクローンして新しいブランチを作成します。
- 変更の一部としてドキュメントまたはテストを追加または更新する必要があるかどうかを検討し、必要に応じて追加します。
- テストを追加する場合は、テストが自己記述的であることを確認してください。
- また、プルリクエストが特定の問題の修正を対象としている場合、テストに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", { ...
- Scala
- 変更の一部としてベンチマークの結果を追加または更新する必要があるかどうかを検討し、フォークされたリポジトリでベンチマークを実行することにより、必要に応じてベンチマークの結果を生成します。
./dev/run-testsを使用してすべてのテストを実行し、コードがまだコンパイルされ、テストに合格し、スタイルチェックに合格することを確認します。スタイルチェックに失敗した場合は、以下のコードスタイルガイドを確認してください。- コミットをブランチにプッシュします。これにより、フォークされたリポジトリで「ビルドとテスト」および「テスト結果のレポート」ワークフローがトリガーされ、変更のテストと検証が開始されます。
- プルリクエストを
apache/sparkのmasterブランチに対して開きます。（特別な場合を除き、PRは他のブランチに対して開かれません）。これにより、「あなたの」フォークされたリポジトリで成功したワークフロールンを探します/監視する「On pull request*」（Sparkリポジトリ）ワークフローがトリガーされます（実行中の場合は待機します）。- PRのタイトルは、
[SPARK-xxxx][COMPONENT] タイトルの形式にする必要があります。ここで、SPARK-xxxxは関連するJIRA番号、COMPONENTはspark-prs.appspot.comに示されているPRカテゴリの1つ、タイトルはJIRAのタイトルまたはPR自体をより具体的に説明するタイトルです。 - プルリクエストがまだ進行中で、マージの準備ができていないが、レビューを容易にするためにGitHubにプッシュする必要がある場合は、コンポーネントの後に
[WIP]を追加します。 - 変更されているコードに取り組んできたコミッターまたは他の貢献者を特定することを検討してください。GitHubでファイルを見つけて「Blame」をクリックして、最後にコードを変更したユーザーの行ごとの注釈を確認します。PRの説明に
@usernameを追加して、すぐに通知することができます。 - 寄稿があなたのオリジナル作品であり、プロジェクトのオープンソースライセンスに基づいてプロジェクトにその作品をライセンス供与することに同意したことを明記してください。
- PRのタイトルは、
- 関連するJIRAがある場合は、「進行中」としてマークされ、プルリクエストが自動的にリンクされます。作業を行うためにJIRAの担当者である必要はありませんが、作業を開始したことをコメントすることもできます。
- プルリクエストにSparkRに関連する変更がある場合、AppVeyorがWindowsでSparkRをテストするために自動的にトリガーされ、約1時間かかります。上記の手順と同様に、エラーを修正し、新しいコミットをプッシュしてAppVeyorでの再テストを要求します。
レビュープロセス
- コミッターを含む他のレビューアーが変更についてコメントし、修正を提案する場合があります。変更は、同じブランチにさらにコミットをプッシュするだけで追加できます。
- 活発で丁寧な迅速な技術的な議論は、コミュニティのすべての人々に奨励されています。結果として、変更全体が拒否される可能性があります。
- Sparkの中核やSQLコンポーネントなど、より重要な部分への変更は、より多くのレビューの対象となり、他の変更よりも多くのテストと正確性の証明が必要になることを覚えておいてください。
- レビューアーは、「このパッチは良さそうです」などのコメントで、変更がマージに適していることを示すことができます。Sparkでは、パッチに対する最も強力なレベルの技術的な承認を示すためにLGTM規則を使用しています。単に「LGTM」という単語でコメントしてください。これは具体的には、「これを入念に確認し、自分がパッチを書いたかのように責任を負います」という意味です。「LGTM」とコメントすると、パッチのバグや後続の問題に対処することが期待されます。LGTMの一貫した慎重な使用は、より広範なコミュニティでレビューアーとしての信頼を得るための優れた方法です。
- 他の変更がマージされる際に、あなたのプルリクエストの変更と競合することがあります。競合が解決されるまで、PRはマージできません。この競合は、例えば、以下のコマンドでアップストリームの変更を反映するリモートを追加することで解決できます。
git remote add upstream https://github.com/apache/spark.git、続いてgit fetch upstreamとgit rebase upstream/masterを実行し、手動で競合を解決した後、結果をあなたのブランチにプッシュします。 - 返信までに数日も待たせるのではなく、議論に迅速に対応してください。
プルリクエスト/JIRAのクローズ
- 変更が承認されると、マージされ、プルリクエストは自動的にクローズされます。関連付けられたJIRAがあれば、それも同様にクローズされます。
masterブランチ以外に対してプルリクエストの作成を求められるまれなケースでは、プルリクエストを手動でクローズする必要があることに注意してください。- JIRAは、変更への主要な貢献者に割り当てられ、功績が認められます。JIRAが迅速にクローズおよび/または割り当てられない場合は、JIRAにコメントしてください。
- 最終的にプルリクエストが拒否された場合は、速やかにクローズしてください。
- …コミッターは直接PRをクローズできないためです。
- コミッターが「このPRをクローズしてもらえますか？」のようなコメントをした場合、約1週間後にApacheの自動プロセスによってプルリクエストが自動的にクローズされます。これは、コミッターが特にクローズを要求していることを意味します。
- プルリクエストがほとんど注目されていない場合は、説明または変更自体を改善し、数日後に可能性のあるレビュアーに再度通知することを検討してください。より小さい、そして/または影響の少ない変更など、より簡単に含めることができる変更を提案することを検討してください。
- 最も関連性の高いレビュアーからのレビュー依頼後、数週間経っても採用されない場合、または、中立的な反応しか得られない場合は、結果は「事実上の却下」と見なされる場合があります。この場合は、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行動規範を参照してください。
最新ニュース
- Spark 3.4.3リリース (2024年4月18日)
- Spark 3.5.1リリース (2024年2月23日)
- Spark 3.3.4リリース (2023年12月16日)
- Spark 3.4.2リリース (2023年11月30日)
