Skip to content

Latest commit

 

History

History
125 lines (94 loc) · 7.47 KB

CONTRIBUTING.md

File metadata and controls

125 lines (94 loc) · 7.47 KB

build status

How to Contribute

Contributing to an open source project is a great way to build skills, make connections, and gain experience. We welcome many different types of contributions that include:

  • Adding new features and proposals
  • Creating and updating documentation
  • Writing design specifications
  • Creating visual graphics
  • Identifying and fixing bugs
  • Triaging issues
  • Answering questions and provide feedback
  • Helping onboard new contributors

Code of Conduct

VDK follows the Code of Conduct, adapted from the Contributor Covenant. Please read the Code of Conduct guide to familiarize yourself with the expectations and responsibilities of the community.

Contributor License Agreement CLA.

If you wish to contribute code, you must sign the contributor license agreement (CLA). For any questions about the CLA process, please refer to our FAQ page.

Open Development

All contributors follow GitHub’s pull request (PR) workflow to submit changes. Before merging, all pull requests require two approvals.

Semantic Versioning

VDK follows semantic versioning standards as part of https://semver.org/.

Given a version number MAJOR.MINOR.PATCH, increment the:

  • MAJOR version when you make incompatible API changes
  • MINOR version when you add functionality in a backwards compatible manner
  • PATCH version when you make backwards compatible bug fixes

Bugs

Where to Find Known Issues

Review the list of existing issues to see if the bug has already been reported.

Reporting New Issues

To report a bug, create a GitHub issue. Include steps to replicate the bug in the issue description.

Security Bugs

If you believe you have found a security bug, create a GitHub issue and reach out to us first using any method in the Contact Us section.

Design Principles

Familiarize with Verstaile Data Kit Design Principles. We want to prioritize user-centered development, seamless user experience, and data-centric interfaces.

Propose a Change

Before proposing a feature or change, consider the impact of this change. Does it only serve your needs, or does it serve the broader community's needs?

For substantial features or changes, submitting your design is valuable.

To submit a change:

  1. Create a PR in Github.
  2. Follow the VDK Enhancement Proposal (VEP) template.
  3. Add your proposal as markdown in the /specs directory.

Reviews, feedback, and approvals are documented in the PR.

Reach out to the community through Slack or e-mail in the Contact Us section to discuss your idea. We are happy to help.

Your First Pull Request

If this is your first PR, take a look at this video series to get you started: How to Contribute to an Open Source Project on GitHub.

Take a look at our list of good first issues. These issues are a great place to start.

If you see an issue that you would like to work on, leave a comment in the issue to let people know you are interested.

Submit and merge a change

Before submitting your first PR, please review our general guidelines in How to prepare a new PR.

Pull Request Checklist

Before submitting your pull request, review the following:

  • Check if your code changes pass both code linting checks and unit tests.
  • Ensure your commit messages are descriptive. Be sure to include any related GitHub issue references in the commit message. See Basic writing and formatting syntax for guidelines on syntax formatting.
  • Check the commit and commit messages to ensure they are free from spelling and grammar errors.
  • Use clear commit titles and commit descriptions for generating changelog release notes.

Submit a pull request

  • All changes must be submitted to the main branch using pull requests.
  • Any change must go on a feature branch or on a fork.
  • Pipeline must pass before merging.
  • Code commits must be broken down into small self-contained units.
  • Commit messages must follow the template in git-commit-template.txt. See How to Write a Git Commit Message as a guideline to writing commit messages.
  • The change must abide by the Versatile Data Kit Coding Standard.
  • Each change is a subject to two code reviews and approvals before it is merged.

We prefer to maintain a straight branch history by rebasing before merging. Fast-forward merges should not create merge conflicts.

Development Workflow

A typical development workflow has the following process:

  • Create a topic branch from where you want to base your work, naming your branch according to our naming convention. For example, person/<github-username>/<feature-name>.
  • Make commits in logical units.
  • Use clear commit titles and commit descriptions.
  • Push your changes to the topic branch in your fork.
  • Create a pull request from commit.

We follow the GitHub workflow. See GitHub flow for more information.

Note: Use forks only for examples and documentation contributions. Currently we accept contribution from forks only for examples and documentation changes until PR 854 is fixed. Until then, please request write privileges and create a branch in the main repository.

Coding Standard

See Versatile Data Kit Coding Standard.

Next Steps

Ready to contribute? Take a look at the open issues list or create an issue for a suggested change.

Contact us

You can reach out to us using any of the following: