Skip to content

Latest commit

 

History

History
104 lines (62 loc) · 5.25 KB

CONTRIBUTING.adoc

File metadata and controls

104 lines (62 loc) · 5.25 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

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 exisiting 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 wriiten 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 specificaton: 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 woring together. If the commit influences a visual change, screenshots are encouraged