Issues and Pull Request Guiedlines

Hi there! We're thrilled that you'd like to contribute to this project, thank you for your interest. Whether it's a bug report, new feature, correction, or additional documentation, we greatly value feedback and contributions from our community.

Please read through this document before submitting any issues or pull requests to ensure we have all the necessary information to effectively respond to your bug report or contribution.

• We accept contributions made to the OLake staging branch

General Guidelines

Before making any significant changes and before filing a new issue, please check existing open, or recently closed issues to make sure somebody else hasn't already reported the issue. Please try to include as much information as you can.

Details like these are incredibly useful:

• Requirement - what kind of use case are you trying to solve?
• Proposal - what do you suggest to solve the problem or improve the existing situation?
• Any open questions to address❓

If you are reporting a bug, details like these are incredibly useful:

• A reproducible test case or series of steps.
• The version of our code being used.
• Any modifications you've made relevant to the bug🐞.
• Anything unusual about your environment or deployment.
• Discussing your proposed changes ahead of time will make the contribution process smooth for everyone 🙌.

Issues

Report a Bug

Bug reports help us make OLake better for everyone. We provide a preconfigured template for reporting bugs to make it very clear what information we need. To avoid duplicate reports, check if the bug was already reported before raising a new one.

Request new Features or a Connector

Requesting new features is an essential way to contribute. Your input helps us understand your needs and priorities, enabling us to enhance the functionality and versatility of OLake. Starting a Github Discussion is the best way to do it.

Reporting Security Issues

Please do not create a public GitHub issue. If you've found a security issue, please email us directly at hello@olake.io instead of raising an issue.

Pull Request (PR) guidelines

Contributions via pull requests are much appreciated. Once the approach is agreed upon ✅, make your changes and open a Pull Request(s). Before sending us a pull request, please ensure that,

• Fork the olake repo on GitHub, clone it on your machine.
• Create a branch with your changes.
• You are working against the latest source on the staging branch.
• Modify the source; please focus only on the specific change you are contributing.
• Commit to your fork using clear commit messages.
• Send us a pull request, answering any default questions in the pull request interface.
• Pay attention to any automated CI failures reported in the pull request, and stay involved in the conversation.
• Once you've pushed your commits to GitHub, make sure that your branch can be auto-merged (there are no merge conflicts). If not, on your computer, merge master into your branch, resolve any merge conflicts, make sure everything still runs correctly and passes all the tests, and then push up those changes.
• Once the change has been approved and merged, we will inform you in a comment.

GitHub provides additional document on forking a repository and creating a pull request.

Note: Unless your change is small, please consider submitting different Pull Request(s):

• 1️⃣ First PR should include the overall structure of the new component:
  • Readme, configuration, interfaces or base classes, etc...
  • This PR is usually trivial to review, so the size limit does not apply to it.
• 2️⃣ Second PR should include the concrete implementation of the component. If the size of this PR is larger than the recommended size, consider splitting ⚔️ it into multiple PRs.
• If there are multiple sub-component then ideally each one should be implemented as a separate pull request.
• Last PR should include changes to any user-facing documentation. And should include end-to-end tests if applicable. The component must be enabled only after sufficient testing, and there is enough confidence in the stability and quality of the component.

You can always reach out to hello@olake.io to understand more about the repo and product. We are very responsive over email and slack community.

Pointers:

• If you find any bugs → please create an issue.
• If you find anything missing in documentation → you can create an issue with the label documentation.
• If you want to build any new feature → please create an issue with the label enhancement.
• If you want to discuss something about the product, start a new discussion.

Conventions to follow when submitting Commits and Pull Request(s).

We try to follow Conventional Commits, more specifically the commits and PRs should have type specifiers prefixed in the name. This should give you a better idea.

e.g. If you are submitting a fix for an issue in frontend, the PR name should be prefixed with fix(FE):

• Follow GitHub Flow guidelines for your contribution flows.

• Feel free to ping us on #contributing-to-olake on our slack community if you need any help.

There are many other ways to get involved with the community and to participate in this project:

• Use the product, submitting GitHub issues when a problem is found.
• Help code review pull requests and participate in issue threads.
• Submit a new feature request as an issue.
• Help answer questions on forums such as Stack Overflow and OLake Community Slack Channel.
• Tell others about the project on Twitter, your blog, etc.

Again, Feel free to ping us on #contributing-to-olake on our slack community if you need any help on this :)

Goodies

We know how much you love swags and stickers, for each PR merged (again, not typo fixes or documentation fixes) we will send over a Tshirt and stickers to you. Take a sneak peak below.

Note: PR qualifying for goodies is subject to value it adds and the OLake team approval.

Thank You!