Skip to main content

Guidelines for Contributing

Note: This guide is written for the Delivery domain, but the instructions here apply to all projects. Please take these guidelines into account for new projects, new features or bugfixes.

Note: Contributions to this guide are also welcome. Please don't hesitate to contact the team.

Welcome, and thank you for your interest in contributing to this project! We welcome contributions. By participating in this project, you agree to abide by the Guidelines of Contributing.

In this project, we're using some principals of software developing standards, such as Semantic Versioning, Conventional Commits and A Code of Conduct for Open Source Communities. Also a agreement in the naming convention of branches and commit messages.

These are the guidelines for contributing to this project:

Branch Strategy and Workflow​

We are using Git Flow for this repository and we've three major branches:

  • main for production
  • uat for staging, UAT or QA or pre-production
  • develop for development also known as default branch

We're creating a new branch from develop branch for every new feature or bug fix. After the feature or bug fix is done, we're merging the branch to develop branch. After the develop branch is ready for merge, we're merging the develop branch to uat branch. After the uat branch is ready for release, we're merging the uat branch to main branch to the production deployment.

We're using uat and develop branches for continuous integration and development environment.

Branch Naming Convention​

  • feature/ for new features
  • fix/ for bug fixes
  • chore/ for chores
  • docs/ for documentation
  • refactor/ for refactoring
  • test/ for tests
  • ci/ for continuous integration

For example, feature/CORE-2023 or ci/DEV-32 also accepted docs/delete-a-courier. Please do not enter just fix in the branch name.

Commit Message Convention​

  • feat: for new features
  • fix: for bug fixes
  • chore: for chores
  • docs: for documentation
  • refactor: for refactoring
  • test: for tests
  • ci: for continuous integration

For example, feat: Adding courier profile picture in the app or chore: Typo on the CHANGELOG also accepted Conventional Commits specifications. For major changes, please BREAKING CHANGE in the commit message. Only accepted English language. Please do not enter just fix in the commit message.

Pull Requests are welcome. If your work has a JIRA task, you can enter the PR title like DEV-32: Support arm64 base image in the v2 App. Please be understandable for every member of Tech Team in the title. For review process, you can add reviewers or teams in the pull request.

Method or Function Naming Convention​

We are using Camel Case for naming methods or functions.

Variable Naming Convention​

We are using Camel Case for naming variables.

Constant Naming Convention​

We are using SCREAMING_SNAKE_CASE for naming constants.

Class Naming Convention​

We are using Pascal Case aka upper camel case for naming classes.

File Naming Convention​

We are using Camel Case for naming files.

Folder Naming Convention​

We are using Kebab Case for naming folders.

Code Style​

We are using Prettier and ESLint for code style. Please install the extension in your IDE.