How to contribute

This section is a practical guide to working in the Spark codebase. The authoritative external guide lives at spark.apache.org/contributing.html; the pages here are a fast in-tree reference.

TL;DR

1. Open or pick a JIRA ticket on issues.apache.org/jira/projects/SPARK.
2. Branch from apache/spark master and code your change.
3. Add or update tests. Spark's test culture is "every behavior change has a test".
4. Run dev/run-tests (or at least the affected suites) and the relevant linters.
5. Open a PR titled [SPARK-xxxxx][COMPONENT] Title against master. Fill out every section of .github/PULL_REQUEST_TEMPLATE.
6. Iterate with reviewers. Maintainers merge once they are satisfied; do not self-merge.

The rest of this section drills into the workflow:

• development-workflow.md - branch / commit / PR mechanics, including PR title format, commit hygiene, and how the JIRA ticket is created.
• testing.md - how to run JVM, Python, R, and SQL golden-file tests.
• debugging.md - logs, tracing, common error modes.
• patterns-and-conventions.md - coding patterns enforced (and not) by lint, plus repo-wide conventions like the no-non-ASCII rule.
• tooling.md - the SBT/Maven build system, lint runners, CI workflows, and release scripts.

Code of conduct and licensing

• Spark is governed by the Apache Code of Conduct.
• All contributions are licensed under Apache License 2.0 (LICENSE). New source files must carry the standard ASF header. The dev/check-license script enforces this.

Where decisions get made

• Design discussions. SPIP (Spark Project Improvement Proposal) tickets and the dev@spark.apache.org mailing list.
• Code review. GitHub PRs against apache/spark.
• Release votes. dev@spark.apache.org and private@spark.apache.org. Release scripts live in dev/create-release/.

Definition of done

A PR is mergeable when:

• All CI checks are green or have known-quirky failures explained on the PR.
• New behavior has tests (Scala suites, Python tests, golden files, etc.).
• Documentation is updated for any user-visible change. SQL functions need entries in sql/core/src/test/resources/sql-functions/.
• Migration notes are added for breaking changes (docs/core-migration-guide.md, docs/sql-migration-guide.md).
• For protocol changes in Spark Connect, the corresponding .proto and generated stubs are in the same PR. See sql/connect/common/src/main/protobuf/.