Skip to content

Latest commit

 

History

History
139 lines (85 loc) · 6.26 KB

CONTRIBUTING.adoc

File metadata and controls

139 lines (85 loc) · 6.26 KB
Raw

Contributing to Eclipse JNoSQL

Table of Contents

Thanks for your interest in this project.

Developer resources

Information regarding source code management, builds, coding standards, and more.

The project maintains the following source code repositories

Eclipse Contributor Agreement

Before your contribution can be accepted by the project team contributors must electronically sign the Eclipse Contributor Agreement (ECA).

Commits that are provided by non-committers must have a Signed-off-by field in the footer indicating that the author is aware of the terms by which the contribution has been provided to the project. The non-committer must additionally have an Eclipse Foundation account and must have a signed Eclipse Contributor Agreement (ECA) on file.

For more information, please see the Eclipse Committer Handbook: https://www.eclipse.org/projects/handbook/#resources-commit

Developer Certificate of Origin - DCO

This is a security layer for the project and for the developers. It is mandatory.

Follow one of these two methods to add DCO to your commits:

1. Command line

Follow the steps: Step 1: Configure your local git environment adding the same name and e-mail configured at your GitHub account. It helps to sign commits manually during reviews and suggestions.

git config --global user.name “Name”
git config --global user.email “[email protected]”

Step 2: Add the Signed-off-by line with the '-s' flag in the git commit command:

$ git commit -s -m "This is my commit message"

2. GitHub website

You can also manually sign your commits during GitHub reviews and suggestions, follow the steps below:

Step 1: When the commit changes box opens, manually type or paste your signature in the comment box, see the example:

Signed-off-by: Name < e-mail address >

Contact

Contact the project developers via the project’s "dev" list.

Issues

If you found a bug or have an idea, check out the following sections before submitting your contribution.

Check the issue tracker

All our issues are centralized in our main repository, it is quite likely that you will find a topic that is being discussed. Check the open issues, another good way to start is good first issues.

Open an issue for any new problem

Writing a good issue will help our team better analyze and manage your contributions, therefore, follow the standards and best practices below:

With the title:

Project:Scope - Title Description

  • Project: Name of the project or repository you want to contribute to.

  • Scope: Add what your issue refers to:

  • Bug report: Report a reproducible bug.

  • Feature request: Suggest a new idea for Eclipse JNoSQL.

Example: Eclipse JNoSQL:feat request - Suggestion for a better user experience

With the issue description:

Try to explain the scenario to us by following these tips:

  • Context: explain the conditions which led you to write this issue.

  • Problem or idea: the context should lead to something, an idea or a problem that you’re facing.

  • Solution or next step: this where you move forward. You can engage others (request feedback), assign somebody else to the issue, or simply leave it for further investigation, but you absolutely need to propose a next step towards solving the issue.

Contribute to the repo

To contribute to the repo one must adhere to the following:

Types of Commits:

  • fix: Any commit that patches a bug anywhere in the codebase

  • feat: Any commit that introduces a new feature or focuses on enhancing the scope of existing features

  • breaking changes: Any commit that has a footer "BREAKING CHANGE", or appends a ! after the type/scope, introduces a breaking API change (correlating with MAJOR in Semantic Versioning). A BREAKING CHANGE can be part of commits of any type.

  • other than fix and feat: Any commit that consists of the following keywords: build:, chore:, ci:, docs:, style:, refactor:, perf:, test:, and others. For other keywords refer to @commitlint/config-conventional (based on the Angular convention)

  • other footers:<description> may be provided and follow a convention similar to git trailer format

Examples of commits

  • Regular Commit Message: This may be used for either fix or feat and can be written as fix: <message> or feat: <message>

  • Commit with breaking change: Example: A new feature being introduced as a breaking change can be written as feat!: <message>, this can also simply be written as a regular feat with the BREAKING CHANGE appended to it at the end of the commit

  • Specific breaking change:: Example: A breaking change introduced with a new feature somewhere in the api can be written as feat(api)!: <message>

  • Changing the docs: docs: <message>

  • Regular commit message with specification: A new feature introduced in the api can be written as feat(api): <message>

Formatting Commit messages

All commit messages must clearly state the change that takes place. Multiple paragraphs or bullet points explaining the changes in detail are encouraged. The message must contain the link to the issue that it is directed towards. If there are other people working on a particular issue which you wanted to work on as well, consider working together. If the commit influences a visual change, screenshots are encouraged