{"_id":"5771ab5901e8110e0041ad08","project":"576ebdb79c84a31900958aba","__v":10,"category":{"_id":"576ebfc59c84a31900958ac4","project":"576ebdb79c84a31900958aba","__v":0,"version":"576ebdb79c84a31900958abd","sync":{"url":"","isSync":false},"reference":false,"createdAt":"2016-06-25T17:30:45.835Z","from_sync":false,"order":0,"slug":"preface","title":"Preface"},"parentDoc":null,"user":"576ebd239c84a31900958ab9","version":{"_id":"576ebdb79c84a31900958abd","project":"576ebdb79c84a31900958aba","__v":10,"createdAt":"2016-06-25T17:21:59.854Z","releaseDate":"2016-06-25T17:21:59.854Z","categories":["576ebdb79c84a31900958abe","576ebfc59c84a31900958ac4","576ec32f52f96619007cfb9a","576ec7b7560eef0e00cd3096","576ed4249c84a31900958add","576ed429560eef0e00cd30a3","576ed43a52f96619007cfbb5","576ed44d5a8c72170082b794","577212f20da40019004f0816","57725c7e0a6d610e00de9e4c"],"is_deprecated":false,"is_hidden":false,"is_beta":false,"is_stable":true,"codename":"","version_clean":"3.3.0","version":"3.3"},"updates":[],"next":{"pages":[],"description":""},"createdAt":"2016-06-27T22:40:25.937Z","link_external":false,"link_url":"","githubsync":"","sync_unique":"","hidden":false,"api":{"results":{"codes":[]},"settings":"","auth":"required","params":[],"url":""},"isReference":false,"order":2,"body":"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](https://github.com), which provides an easy method for forking the project and merging your contributions.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Security Vulnerabilities\"\n}\n[/block]\nIf you discover a security vulnerability within Orchestra Platform, please send an e-mail to <security:::at:::orchestraplatform.besnappy.com>. All security vulnerabilities will be promptly addressed.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Feature Requests\"\n}\n[/block]\nIf 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.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Pull Requests\"\n}\n[/block]\nThe 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.\n\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Bug Fixes\"\n}\n[/block]\nPull 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.\n\n* **ALL** bug fixes should be made to the branch which they belong to.\n* Bug fixes should never be sent to the `master` branch unless they fix features that exist only in the upcoming release.\n* 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.\n* You may request to back-port a bug fix to any previous version as long as the working branch is still maintained (not `deprecated`).\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"New Features\"\n}\n[/block]\nBefore 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.\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Template for Pull Request, Proposal, Request or Bugfixes\"\n}\n[/block]\nPlease include the following template when opening an issue on GitHub:\n\n    | Q             | A\n    | ------------- | ---\n    | Bug fix?      | [yes|no]\n    | New feature?  | [yes|no]\n    | BC breaks?    | [yes|no]\n    | Deprecations? | [yes|no]\n    | Tests pass?   | [yes|no]\n    | Fixed tickets | [comma separated list of tickets fixed by the PR]\n    | License       | MIT\n    | Doc PR        | [The reference to the documentation PR if any]\n[block:api-header]\n{\n  \"type\": \"basic\",\n  \"title\": \"Coding Guidelines\"\n}\n[/block]\nOrchestra Platform follows the [PSR-1](https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-1-basic-coding-standard.md), [PSR-2](https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md) and [PSR-4](https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-4-autoloader.md) coding standards. In addition to these standards, below is a list of other coding standards that should be followed:\n\n* Namespace declarations should be on the same line as `<?php`.\n* Preferable to use `&&` and `||` instead of `and` or `or`.\n* Use imports should be ordered by length.\n\nWe also include `.php_cs` file on each repository which would allow you to run [PHP-CS-Fixer](https://github.com/FriendsOfPHP/PHP-CS-Fixer) if you have it install locally.\n[block:code]\n{\n  \"codes\": [\n    {\n      \"code\": \"php-cs-fixer fix\",\n      \"language\": \"text\",\n      \"name\": \"Terminal\"\n    }\n  ]\n}\n[/block]","excerpt":"Contributing To Orchestra Platform","slug":"contributing","type":"basic","title":"Contributing"}

Contributing

Contributing To Orchestra Platform

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](https://github.com), which provides an easy method for forking the project and merging your contributions. [block:api-header] { "type": "basic", "title": "Security Vulnerabilities" } [/block] If you discover a security vulnerability within Orchestra Platform, please send an e-mail to <security@orchestraplatform.besnappy.com>. All security vulnerabilities will be promptly addressed. [block:api-header] { "type": "basic", "title": "Feature Requests" } [/block] 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. [block:api-header] { "type": "basic", "title": "Pull Requests" } [/block] 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. [block:api-header] { "type": "basic", "title": "Bug Fixes" } [/block] 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 back-port a bug fix to any previous version as long as the working branch is still maintained (not `deprecated`). [block:api-header] { "type": "basic", "title": "New Features" } [/block] 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. [block:api-header] { "type": "basic", "title": "Template for Pull Request, Proposal, Request or Bugfixes" } [/block] 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] [block:api-header] { "type": "basic", "title": "Coding Guidelines" } [/block] Orchestra Platform follows the [PSR-1](https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-1-basic-coding-standard.md), [PSR-2](https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md) and [PSR-4](https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-4-autoloader.md) 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. We also include `.php_cs` file on each repository which would allow you to run [PHP-CS-Fixer](https://github.com/FriendsOfPHP/PHP-CS-Fixer) if you have it install locally. [block:code] { "codes": [ { "code": "php-cs-fixer fix", "language": "text", "name": "Terminal" } ] } [/block]