Denodo Sharing Code Conventions

These coding conventions guidelines apply to all Denodo Sharing projects managed by the Denodo Community.

These guidelines are not exhaustive or complete. We expect all members of the Denodo community to follow these guidelines in spirit as much as in the letter, so that it can enrich all of us and the technical communities in which we participate.

This is the standard folder organization for any Denodo Sharing project:

• A test Folder to store the integration, unit, and other tests.
• An src Folder for the source code.
• A build Folder that contains all build process-related scripts, such as Docker compose and PowerShell.
• A .config Folder which should have the local configuration related to set up on a local machine.
• A tools Folder that acts as a convenience directory. It should contain scripts for automating tasks in your software projects, such as rename and build scripts. The folder typically contains .cmd and .sh files.
• A doc Folder containing your documentation.
• A dep Folder that has the directory of your stored dependencies.
• A samples Folder that provides “Hello World” & Co code supporting the documentation.
• A res Folder for all your project’s static resources, such as images, sql scripts and other files.
• Create dedicated repository folders for your special files.
• Include the following documents:
  • An ISSUE_TEMPLATE FILE to let project contributors instantly see the template’s contents within the issues’ body when you add an issue template to your repository.
    • Templates allow you to standardize and customize the information you want to include when contributors open issues. Create a ISSUE_TEMPLATE/ directory within your project root to add multiple repository issue templates. Check this list to see multiple issues and pull request templates.
  • A PULL_REQUEST_TEMPLATE File to instantly display the template’s content within the pull request body.
  • A README File (README.md) to describe your project’s what, why, and how. GitHub recognizes and automatically surfaces the README to the repository visitors.
  • A CHANGELOG File describes what is happening in your repositories, such as software updates, bug fixes, and version number increases.
  • A LICENSE File explains the legal licensing, including restrictions, rights, and regulations (among others).
  • A SECURITY File contains your project’s security policies and a list of versions currently maintained with security updates. The file also provides instructions on how users can submit a vulnerability report.
  • A SUPPORT File contains the support level for the artifact.

It is mandatory to license each Denodo Sharing project so other users are free to use, change, and distribute it. The license file has to explain the legal licensing, including restrictions, rights, and regulations (among others).

Our recommendation is to use the Apache License 2.0 by default in all the Denodo Sharing projects.

Each Denodo Sharing project must declare what type of support is going to be provided for the artifact and who is doing it. Projects should select one of these recommended support levels:

• Community Supported artifacts: All bugs and vulnerabilities will be solved by Denodo without a specific timeframe. Any user can request new features and submit problems.
• Best effort: Only major security vulnerabilities and major bugs will be fixed by Denodo without a specific timeframe. We will try to keep the artifact updated with new enhancements, but it is not guaranteed. Any user can request new features and submit problems.
• Minimum Support: Only major security vulnerabilities and major bugs will be fixed by Denodo without a specific timeframe. Pull requests will be reviewed but it is not guaranteed that they will be accepted
• No support: No bugs will be solved by Denodo in a proactive manner. The Denodo user community will be in charge of maintaining the artifact by means of pull requests. This is the default support level for projects submitted by any Denodo community user.