Skip to main content

Contributing to Airbyte

Thank you for your interest in contributing! Contributions are very welcome. We appreciate first time contributors and we are happy help you get started. Join our community Slack and feel free to reach out with questions!

Everyone interacting in Slack, codebases, mailing lists, events, or any other Airbyte activities is expected to follow the Code of Conduct. Please review it before getting started.

Code Contributions​

Most of the issues that are open for contributions are tagged with good first issue or help-welcome. If you see an issue that isn't tagged that you're interested in, post a comment with your approach, and we'd be happy to assign it to you.

Here are the areas that we love seeing contributions to:​

  • Bug fixes, features, and enhancements to existing API source connectors.
  • New API sources built with the low-code CDK or Connector Builder.
  • Migrating existing sources from Python to the low-code CDK.
  • Bug fixes, features, and enhancements to the following database sources: Postgres, MySQL, MSSQL.
  • Bug fixes to the following destinations: BigQuery, Snowflake, Redshift, S3, and Postgres.
  • Helm Charts features, bug fixes, and other platform bug fixes.
warning

Airbyte is undergoing a major revamp of the shared core Java destinations codebase, with plans to release a new CDK in 2024. We are actively working on improving usability, speed (through asynchronous loading), and implementing Typing and Deduplication (Destinations V2). We're not actively reviewing/accepting new Java connectors for now.

The usual workflow of code contribution is:​

  1. Fork the Airbyte repository.
  2. Clone the repository locally.
  3. Create a branch for your feature/bug fix with the format {YOUR_USERNAME}/{FEATURE/BUG} (e.g. jdoe/source-stock-api-stream-fix)
  4. Make and commit changes.
  5. Push your local branch to your fork.
  6. Submit a Pull Request so that we can review your changes.
  7. Link an existing Issue that does not include the needs triage label to your Pull Request. Pull requests without an issue attached take longer to review.
  8. Write a PR title and description that follows the Pull Request Handbook.
  9. An Airbyte maintainer will trigger the CI tests for you and review the code.
  10. Review and respond to feedback and questions by Airbyte maintainers.
  11. Merge the contribution.

Guidelines to common code contributions:

Documentation​

We welcome Pull Requests that fix typos or enhance the grammar and structure of our documentation! Check the Updating Documentation guide for details on submitting documentation changes.

The following highlights from the Google developer documentation style guide are helpful for new writers:

Guideline for visuals: Use links to videos instead of screenshots (Reason: Users are more forgiving of outdated videos than screenshots).

For examples of good connector docs, see the Salesforce source connector doc and Snowflake destination connector doc

Community Content​

We welcome contributions as new tutorials / showcases / articles, or as enhancements to any of the existing guides on our tutorials page. Head to this repo dedicated to community content: Write for the Community.

Feel free to submit a pull request in this repo, if you have something to add even if it's not related to anything mentioned above.

Engage with the Community​

Another crucial way to contribute is by reporting bugs and helping other users in the community. You're welcome to join the Community Slack. Refer to our Issues and Feature Requests guide to learn about the best ways to report bugs.

Was this page helpful?