You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

The Apache Spark team welcomes all types of contributions, whether they be bug reports, documentation, or new patches.

Reporting Issues

If you'd like to report a bug in Spark or ask for a new feature, open an issue on the Apache Spark JIRA. For general usage help, you should email the user mailing list.

Contributing Code

We prefer to receive contributions in the form of GitHub pull requests. Please send pull requests against the github.com/apache/incubator-spark repository. If you've previously forked Spark from its old location, you will need to fork incubator-spark instead.

Here are a few tips to get your contribution in:

  1. Break your work into small, single-purpose patches if possible. It’s much harder to merge in a large change with a lot of disjoint features.
  2. Submit the patch as a GitHub pull request. For a tutorial, see the GitHub guides on forking a repo and sending a pull request.
  3. Follow the Spark code style guide.
  4. Make sure that your code passes the unit tests. You can run the tests with sbt/sbt assembly and then sbt/sbt test in the root directory of Spark. It's important to run assembly first as some of the tests depend on compiled JARs.
  5. Add new unit tests for your code. We use ScalaTest for testing. Just add a new Suite in core/src/test, or methods to an existing Suite.
  6. Update the documentation (in the docs folder) if you add a new feature or configuration parameter.

If you’d like to report a bug but don’t have time to fix it, you can still post it to our issue tracker, or email the mailing list.

Documentation

If you'd like to contribute documentation, there are two ways:

  • To have us add a link to an external tutorial you wrote, simply email the developer mailing list. 
  • To modify the built-in documentation, edit the MarkDown source files in Spark's docs directory, and send a patch against the incubator-spark GitHub repository. The README file in docs says how to build the documentation locally to test your changes.

Participating in Development Discussions

To keep up to date with the latest discussions, join the developer mailing list.

  • No labels