Contributing

Introduction

OpenG2P is a collaborative effort of several contributors. We welcome contributions to the OpenG2P Project.

Issues

Raise bugs/issues/tasks on GitHub Issues of individual repositories.

All the issues and tasks are tracked using Jira.

Code contributions

To contribute code to the OpenG2P project, follow the steps given below:

1. Create an issue on Github related to your task.

2. Fork the corresponding repository.

3. Commit your changes in your forked repo. Make sure the issue id of GitHub is mentioned in square braces, e.g. [#6] Minor changes to fix the bug.

4. Raise a Pull Request (PR) on the appropriate branch. In general, it is safe to send PRs to develop branch of a repo.

5. The PRs shall be reviewed by the technical team and merged after approval.

Coding conventions

• For Odoo modules, follow the Odoo Coding Guidelines.
• For non-Odoo Python code, follow PEP 8 – Style Guide for Python Code.

Documentation contributions

The documentation of the project is available as .md files in the Documentation repository. To highlight a correction or request for additional documentation, raise a GitHub Issue on the repository. To contribute to the documentation follow the steps given under Code contributions.

Versioning of modules

For Odoo modules, follow the Odoo Versioning. To indicate the maturity of a version (like alpha/beta etc.) use development_status field in the __manifest__.py file as described here.

For Non-Odoo modules, follow Semantic Versioning.

OpenG2P release will follow Semantic Versioning. For GitHub branches and tags versions, refer to the sections below.

Branching and tagging conventions

For Odoo module repositories, a prefix of Odoo version is added to the branch name, e.g. 15.0-1.0.0, 15.0-develop.Within a branch, multiple Git tags may be created like 15.0-1.0.0-rc1, 15.0-1.0.0-rc2 etc.

For non-Odoo module repositories, you should find a develop branch in the repo where in-progress work may be checked-in.

For releases, a release branch is forked out of the develop branch and subsequently, release specific check-ins like bug fixes are made on this branch. For the final release, this branch is Git tagged, frozen (no further check-ins allowed) and merged into the develop branch. Thus, all the changes related to the release are available in develop for further development. The recommended Github tagging convention for a final release is to have a prefix v or release before the version number. For example, v15.0.1.0.0, release-15.0.1.0.0, v1.0.0, release-1.0.0