Skip to main content
Version: 0.12.1

Contributing

We always welcome contributions to help make DataHub better. Take a moment to read this document if you would like to contribute.

Provide Feedback​

Have ideas about how to make DataHub better? Head over to DataHub Feature Requests and tell us all about it!

Show your support for other requests by upvoting; stay up to date on progess by subscribing for updates via email.

Reporting Issues​

We use GitHub issues to track bug reports and submitting pull requests.

If you find a bug:

  1. Use the GitHub issue search to check whether the bug has already been reported.

  2. If the issue has been fixed, try to reproduce the issue using the latest master branch of the repository.

  3. If the issue still reproduces or has not yet been reported, try to isolate the problem before opening an issue.

Submitting a Request For Comment (RFC)​

If you have a substantial feature or a design discussion that you'd like to have with the community follow the RFC process outlined here

Submitting a Pull Request (PR)​

Before you submit your Pull Request (PR), consider the following guidelines:

  • Search GitHub for an open or closed PR that relates to your submission. You don't want to duplicate effort.
  • Follow the standard GitHub approach to create the PR. Please also follow our commit message format.
  • If there are any breaking changes, potential downtime, deprecations, or big feature please add an update in Updating DataHub under Next.
  • That's it! Thank you for your contribution!

Commit Message Format​

Please follow the Conventional Commits specification for the commit message format. In summary, each commit message consists of a header, a body and a footer, separated by a single blank line.

<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Any line of the commit message cannot be longer than 88 characters! This allows the message to be easier to read on GitHub as well as in various Git tools.

Type​

Must be one of the following (based on the Angular convention):

  • feat: A new feature
  • fix: A bug fix
  • refactor: A code change that neither fixes a bug nor adds a feature
  • docs: Documentation only changes
  • test: Adding missing tests or correcting existing tests
  • perf: A code change that improves performance
  • style: Changes that do not affect the meaning of the code (whitespace, formatting, missing semicolons, etc.)
  • build: Changes that affect the build system or external dependencies
  • ci: Changes to our CI configuration files and scripts

A scope may be provided to a commit’s type, to provide additional contextual information and is contained within parenthesis, e.g., 

feat(parser): add ability to parse arrays

Description​

Each commit must contain a succinct description of the change:

  • use the imperative, present tense: "change" not "changed" nor "changes"
  • don't capitalize the first letter
  • no dot(.) at the end

Body​

Just as in the description, use the imperative, present tense: "change" not "changed" nor "changes". The body should include the motivation for the change and contrast this with previous behavior.

The footer should contain any information about Breaking Changes, and is also the place to reference GitHub issues that this commit Closes.

Breaking Changes should start with the words BREAKING CHANGE: with a space or two new lines. The rest of the commit message is then used for this.

Revert​

If the commit reverts a previous commit, it should begin with revert:, followed by the description. In the body it should say: Refs: <hash1> <hash2> ..., where the hashs are the SHA of the commits being reverted, e.g. 

revert: let us never again speak of the noodle incident

Refs: 676104e, a215868