Skip to content

Latest commit

 

History

History
98 lines (60 loc) · 4.67 KB

CONTRIBUTING.md

File metadata and controls

98 lines (60 loc) · 4.67 KB
Raw

Contributing to Looker BQJDBC

🎉 Before we dive in... Thank you for taking the time contribute! 🎉

The following is a set of guidelines for contributing to the bqjdbc repository, which are hosted in the Looker Organization on GitHub. These are mostly guidelines, not rules. Use your best judgment, and feel free to propose changes to this document in a pull request.

Contributor License Agreement

Contributions to this project must be accompanied by a Contributor License Agreement (CLA). You (or your employer) retain the copyright to your contribution; this simply gives us permission to use and redistribute your contributions as part of the project. Head over to https://cla.developers.google.com/ to see your current agreements on file or to sign a new one.

You generally only need to submit a CLA once, so if you've already submitted one (even if it was for a different project), you probably don't need to do it again.

Code of Conduct

This project and everyone participating in it is governed by the Code of Conduct. By participating, you are expected to uphold this code.

Developer Setup

See our README for development setup instructions.

Bug Reports

Bugs from the community are tracked in Github Issues.

  • Use a clear and descriptive title for the issue
  • Note what version you're using
  • Describe how to reproduce the problem
  • Explain the behavior your were expecting
  • Label your issue with "bug"

Enhancements Requests

Enhancements Requests from the community are tracked in Github Issues.

  • Use a clear and descriptive title for the issue
  • Describe what you want to be able to accomplish with Looker Components
  • Label your issue with "enhancement"
  • Link your issue to the relevant project

Pull Requests

We're so excited that you're ready to make your first contribution! Go ahead and open a "New Pull Request." You should see a sample "Developer Checklist" as well as a quick video on what we're looking for to help get your change accepted.

Title Guidelines

We squash Pull Requests (all commits in a pull request show up in our main branch history as a single commit) and we use Conventional Commits to generate our CHANGELOG.

So we use Conventional Commit style Pull Request titles:

<type>[optional scope]: <description>

Examples:

fix(FooBar): Fixed issue with FooBar
feat(Baz): Baz to support exciting new thing
chore(deps): Updated package dependency X from version y to z

Types

We generally follow Angular's types. The most common types used are:

  • fix: a commit of the type fix patches a bug (this correlates with PATCH in Semantic Versioning).
  • feat: a commit of the type feat introduces a new feature or changes an existing one (this correlates with MINOR in Semantic Versioning).

If a change does NOT make a change to the build artifacts produced (fix or feat above) you can also use one of these alternative types:

  • build: Changes that affect the build system or external dependencies
  • docs: Documentation only changes
  • refactor: A code change that neither fixes a bug nor adds a feature
  • style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
  • test: Adding missing tests or correcting existing tests

Scope

Specify a scope when your change is focused on a specific component, package, or portion of the code. E.g.:

feat(FooBar): Now has even more colors 🌈

Developer Checklist

Edit the developer checklist to reflect only items relevant to your pull request (delete items that aren't relevant). Feel free to reach out if you have questions or get stuck.

Not sure if an item applies? Leave it in place and ask your reviewer to help determine if it's relevant.

Thank you for opening a Pull Request! Before submitting your PR, there are a few things you can do to make sure it goes smoothly:

  • Make sure to open an issue as a bug/issue before writing your code! That way we can discuss the change, evaluate designs, and agree on the general idea
  • Ensure the tests pass
  • Appropriate docs were updated (if necessary)

Fixes #<issue_number_goes_here> 🦕

What does "addressed" mean?

If your pull request introduces a regression to the item (or simply leaves that task for a later PR if the component in question isn't already marked as "stable") please document that a follow-up issue has been logged to address that item as technical debt.