Skip to content

CONTRIBUTING.md

Latest commit

 

History

History
106 lines (74 loc) · 5.43 KB

CONTRIBUTING.md

File metadata and controls

106 lines (74 loc) · 5.43 KB

Contributing to OpenLineage

This project welcomes contributors from any organization or background, provided they are willing to follow the simple processes outlined below, as well as adhere to the Code of Conduct.

Joining the community

The community collaborates primarily through GitHub and the instance messaging tool, Slack. There is also a mailing list. See how to join here

Reporting an Issue

Please use the issues section of the OpenLineage repository and search for a similar problem. If you don't find it, submit your bug, question, proposal or feature request.

In the case of bugs, please provide steps to reproduce it and tag your issue with "bug"

Contributing to the project

Creating Pull Requests

Before sending a Pull Request with significant changes, please use the issue tracker to discuss the potential improvements you want to make.

OpenLineage uses GitHub's fork and pull model to create a contribution.

Make sure to sign-off your work to say that the contributor has the rights to make the contribution and agrees with the Developer Certificate of Origin (DCO)

To ensure your pull request is accepted, follow these guidelines:

  • All changes should be accompanied by tests
  • Do your best to have a well-formed commit message for your change
  • Do your best to have a well-formed pull request description for your change
  • Keep diffs small and self-contained
  • If your change fixes a bug, please link the issue in your pull request description
  • Your pull request title should be of the form [CATEGORY][COMPONENT] Your title, where CATEGORY is either PROPOSAL, or INTEGRATION, and COMPONENT is one of AIRFLOW, DBT, SPARK, etc.

Branching

  • Use a group at the beginning of your branch names:

    feature  Add or expand a feature
bug      Fix a bug

    For example:

    feature/my-cool-new-feature
bug/my-bug-fix
bug/my-other-bug-fix

  • Choose short and descriptive branch names

  • Use dashes (-) to separate words in branch names

  • Use lowercase in branch names

Proposing changes

Create an issue and prefix the description with "[PROPOSAL]"

In the description provide the following sections:

  • Purpose (Why?): What is the use case this is for.
  • Proposed implementation (How?): Quick description of how do you propose to implement it. Are you proposing a new facet?

This can be just a couple paragraphs to start with.

New Integrations

New integrations should be added under the ./integrations folder. Each module should have its own build configuration (e.g., build.gradle for a Gradle project, setup.py for python, etc.) with appropriate unit tests and integration tests (when possible).

Adding a new integration requires updating the CI build configuration with a new workflow. Job definitions, orbs, parameters, etc. shoudl be added to the .circleci/continue_config.yml file. Workflow definition files are added to the .circleci/workflows directory. Each workflow file adheres to the CircleCI config.yml schema, including only the workflows subschema (see [https://circleci.com/docs/2.0/configuration-reference/#workflows](the CircleCI docs) for the schema specification). Each workflow must include a workflow_complete job that requires each terminal required step in the workflow (e.g., you might depend on run-feature-integration-tests as the final step in the workflow). Job names must be unique across all workflows, as ultimately the workflows are merged into a single config file. See existing workflows for examples.

First-Time Contributors

If this is your first contribution to open source, you can follow this tutorial or check this video series to learn about the contribution workflow with GitHub.

Look tickets labeled 'good first issue' and 'help wanted'. These are a great starting point if you want to contribute. Don't hesitate to ask questions about the issue if you are not sure about the strategy to follow.

Triggering CI runs from forks (committers)

CI runs on forks are disabled due to possibility to access external services via CI run. Once contributor decides PR is ready to be checked, they can use this script to trigger CI run on separate branch with same commit ID. This will update CI status of a PR.