Denodo Sharing Contributing Guidelines

Introduction

Dear contributor. Thank you for investing the time and energy to help make these Denodo Sharing projects as useful as possible. This document is a manual for Denodo Community contributors and maintainers. It explains what is expected of contributors, how they should work, and what tools are available to them.

Denodo Sharing Terms of Use

Personal Data

Any contributor to Denodo Sharing projects will be requested to create a Denodo Community User account. Denodo will use, process, and store your personal data at all times in compliance with our Privacy Notice, Cookies Notice and Terms of Use.

Intellectual property rights

The user or participant of the Denodo Sharing projects (the “User”) guarantees that any work or content provided within the scope of the Denodo Sharing project is original and does not infringe intellectual or industrial property rights, confidentiality obligations or any other exclusive rights belonging to third parties.

The User shall, in all cases, be solely responsible for the authorship and originality of the content provided as part of their contributions to the Denodo Sharing projects, and guarantees that such content does not infringe any third-party rights, including but not limited to intellectual or industrial property rights, image rights, trademarks, or copyrights. The User shall be liable to Denodo and/or any third party for any lack of originality or for any infringement of third-party rights arising from their contributions. In this regard, the User agrees to hold Denodo harmless from any damages, claims, liabilities, or expenses incurred by Denodo—including legal costs, attorneys’ fees, solicitors’ fees and expert fees—arising from a breach of this section or from any claim brought by a third party alleging that the content submitted to Denodo Sharing, in whole or in part, infringes their rights.

Notwithstanding the foregoing, the User agrees to grant Denodo a non-exclusive, worldwide, royalty-free license to all exploitation rights over such creations, in the proportion resulting from the existing agreements between them, for the maximum duration permitted by law. In particular, the economic rights of use, reproduction, public communication and transformation shall be licensed to Denodo. Users still reserve all rights, titles and interest in and to their contributions.

By virtue of this license, Denodo may use, reproduce, distribute, sublicense to third parties, incorporate into other materials, disseminate and/or publish the User's creations for any purpose and in any form that Denodo deem appropriate and/or necessary and through any format or medium, with the User expressly waiving any remuneration for this other than that which may result from participation in the project in accordance with these terms and conditions.

Acceptance of the rules

The simple participation in any Denodo Sharing project implies the acceptance of these rules in their entirety, so that the manifestation of non-acceptance of these rules will imply the exclusion of the participant from the project.

How to contribute to Denodo Sharing Projects

Code of Conduct

Do you intend to add a new feature to a project or change an existing one?

  • Before we accept a non-trivial patch or pull request we will need you to accept this Terms of Use from the Denodo Community.
  • Fork the Repository, create a branch for the feature and create a Pull Request. Before submitting, please read the Coding Conventions.
  • Before submitting a contribution that is not an obvious or trivial fix, discuss the proposal on the GitHub issues of the project or in the Denodo Community Q&As. We recommend not start coding or open a pull request until you have collected positive feedback about the change to maximize the possibility of your contributions being accepted. Please understand that not all contributions will be accepted and merged into the project's repositories.
  • Once you have created the pull request, please open a Denodo Community Q&A explaining the change. Please understand that not all contributions will be accepted and merged into the project's repositories.

Did you find a bug?

  • Do not open up a GitHub issue if the bug is a security vulnerability. Instead, refer to our Security Guidelines.
  • Ensure the bug was not already reported by searching on GitHub’s project repository under Issues.
  • If you're unable to find an open issue addressing the problem, open a new one. Be sure to include a title and clear description, as much relevant information as possible, and a code sample or an executable test case demonstrating the expected behavior that is not occurring.
  • If possible, use the relevant bug report templates (if the project includes them) to create the issue. Simply copy the content of the appropriate template, make the necessary changes to demonstrate the issue, and paste the content into the issue description.

Did you write a patch that fixes a bug?

  • Open a new GitHub pull request with the patch.
    • Include the relevant issue number if applicable.
  • Before submitting, please read the Coding Conventions.
  • Open a Denodo Community Q&A clearly describing the problem and the solution..

Did you fix whitespace, format code, or make a purely cosmetic patch?

Changes that are cosmetic in nature and do not add anything substantial to the stability, or functionality of the project will generally not be accepted because it would be needed to spend the time to review the patch and any tiny changes have the possibility of altering behavior and introducing bugs. In addition, cosmetic patches create noise, so thank you for your understanding.

Do you have questions about the source code?

Do you want to contribute to the documentation?

How are decisions made?

The Denodo Sharing projects are open-source projects with an open design philosophy. This means that the repository is the source of truth for EVERY aspect of the project, including its philosophy, design, roadmap and APIs. If it's part of the project, it's in the repo. It's in the repo, it's part of the project

As a result, all decisions can be expressed as changes to the repository. An implementation change is a change to the source code. An API change is a change to the API specification. And so on.

All decisions affecting the projects, big and small, follow the same procedure

  • Discuss a proposal on the Github Issues or in Denodo Community Q&A. Anyone can do this.
  • Open a pull request. Anyone can do this.
  • Discuss the pull request. Anyone can do this.
  • Endorse (LGTM) or oppose (Rejected) the pull request. The relevant maintainers do this (see below Who decides what?).
  • Merge or close the pull request. The relevant maintainers do this.

I'm a maintainer, should I make pull requests too?

Ideally, nobody should ever push to master directly. All changes should be made through a pull request, but there are exceptions for projects with a single contributor or maintainer

Who decides what?

All decisions are pull requests, and the relevant maintainers make decisions by accepting or refusing the pull request.

Overall the maintainer system works because of mutual respect. The maintainers trust one another to act in the best interests of the project. Sometimes maintainers can disagree and this is part of a healthy project to represent the points of view of various people. In the case where maintainers cannot find agreement on a specific change, maintainers should attempt to reach a consensus.

How are maintainers added?

The best maintainers have a vested interest in the project. Maintainers are first and foremost contributors that have shown they are committed to the long term success of the project. Contributors wanting to become maintainers are expected to be deeply involved in contributing code, pull request review, and triage of issues in the project for more than two months.

Just contributing does not make you a maintainer, it is about building trust with the current maintainers of the project and being a person that they can depend on to act in the best interest of the project. The final vote to add a new maintainer should be approved by the Denodo Community Team.

How are maintainers removed?

When a maintainer is unable to perform the required duties they can be removed from the team. Issues related to a maintainer's performance should be discussed with them among the other maintainers so that they are not surprised by a pull request removing them.

What are a maintainer's responsibilities?

It is every maintainer's responsibility to:

  • Deliver prompt feedback and decisions on pull requests.
  • Be available to anyone with questions, bug reports, criticism etc. on their component. This includes GitHub issues and pull requests.
  • Make sure their component respects the philosophy, design and roadmap of the projects.

Thanks

This Contributing Guidelines document is adapted from the Thymeleaf Contributing file, OCI Maintainers Guide, along with material from the Ruby on Rails and others.