Contributing changes

Apache Hop is developed by an open community, and contributing goes well beyond writing code. The project’s contribution guides live on the website and are the authority on process:

CONTRIBUTING.md in the repository root collects those links along with the ICLA requirements and how one becomes a committer.

This page is about the mechanics on the code side.

Before you open a pull request

  • There is a GitHub issue for the change, and the pull request references it.

  • ./mvnw spotless:apply has been run.

  • Every new file carries the Apache License 2.0 header, or RAT will fail the build.

  • The build passes locally — see Building and testing.

  • New behaviour has a test. Unit tests for logic, integration tests for anything that needs a pipeline to actually run, UI tests for dialogs and widgets.

  • User-visible behaviour has documentation — see Writing documentation.

Getting help

Questions are welcome on the mailing lists, in GitHub Discussions, and on Slack. For a change large enough that you would rather not build it twice, ask on the dev list before starting.

This page is a scaffold. Still to write:

  • Branch naming and commit message conventions as actually practised in this repository.

  • What reviewers look for, and what to expect in terms of turnaround.

  • Backporting to a release branch, and when that is appropriate.

  • Deprecation policy: how an API is removed, and over how many releases.