3.3 documentation

  1. Introduction
  2. Security Vulnerabilities
  3. Feature Requests
  4. Pull Requests
  5. Template for Pull Request, Proposal, Request or Bugfixes
  6. Coding Guidelines

Introduction

Orchestra Platform is free, open-source software, meaning anyone can contribute to its development and progress. Orchestra Platform source code is currently hosted on GitHub, which provides an easy method for forking the project and merging your contributions.

Security Vulnerabilities

If you discover a security vulnerability within Orchestra Platform, please send an e-mail to security@orchestraplatform.com. All security vulnerabilities will be promptly addressed.

Feature Requests

If you have an idea for a new feature you would like to see added to Orchestra Platform, you may create an issue on GitHub with [Request] in the title. The feature request will then be reviewed by a core contributor.

Pull Requests

The pull request process differs for new features and bugs. A pull request or bugfixes should include relevant test cases to ensure that Orchestra Platform work as expected and avoid regression bug is produced in the future.

Bugfixes

Pull requests for bugs may be sent without creating any proposal issue. If you believe that you know of a solution for a bug that has been filed on GitHub, please leave a comment detailing your proposed fix.

  • ALL bug fixes should be made to the branch which they belong to.
  • Bug fixes should never be sent to the master branch unless they fix features that exist only in the upcoming release.
  • If a bug is found on a minor version 3.1 and it exists on the major version 3.0, the bug fix should be sent to the 3.0 branch which will be afterwards merged into the 3.1 branch.
  • You may request to backport a bug fix to any previous version as long as the working branch is still maintained (not deprecated).

New Features

Before sending a pull request for a new feature, you should first create an issue with [Proposal] in the title. The proposal should describe the new feature, as well as implementation ideas. The proposal will then be reviewed and either approved or denied. Once a proposal is approved, a pull request may be created implementing the new feature. Pull requests which do not follow this guideline may be closed immediately.

Template for Pull Request, Proposal, Request or Bugfixes

Please include the following template when opening an issue on GitHub:

| Q             | A
| ------------- | ---
| Bug fix?      | [yes|no]
| New feature?  | [yes|no]
| BC breaks?    | [yes|no]
| Deprecations? | [yes|no]
| Tests pass?   | [yes|no]
| Fixed tickets | [comma separated list of tickets fixed by the PR]
| License       | MIT
| Doc PR        | [The reference to the documentation PR if any]

Coding Guidelines

Orchestra Platform follows the PSR-1, PSR-2 and PSR-4 coding standards. In addition to these standards, below is a list of other coding standards that should be followed:

  • Namespace declarations should be on the same line as <?php.
  • Preferable to use && and || instead of and or or.
  • Use imports should be ordered by length.
  • Trait names are suffixed with Trait (FooTrait).

We also include .php_cs file on each repository which would allow you to run PHP-CS-Fixer if you have it install locally.

php-cs-fixer fix