Development Workflow
editDevelopment Workflow
editAll Issues and Pull Requests must be tracked using the Github issue tracker.
The plugin uses the Apache 2.0 license. Maintainers should check whether a patch introduces code which has an incompatible license. Patch ownership and copyright is defined in the Elastic Contributor License Agreement (CLA).
Terminology
editA "Contributor" is a role a person assumes when providing a patch. Contributors will not have commit access to the repository. They need to sign the Elastic Contributor License Agreement before a patch can be reviewed. Contributors can add themselves to the plugin Contributor list.
A "Maintainer" is a role a person assumes when maintaining a plugin and keeping it healthy, including triaging issues, and reviewing and merging patches.
Patch Requirements
editA patch is a minimal and accurate answer to exactly one identified and agreed upon problem. It must conform to the code style guidelines and must include RSpec tests that verify the fitness of the solution.
A patch will be automatically tested by a CI system that will report on the Pull Request status.
A patch CLA will be automatically verified and reported on the Pull Request status.
A patch commit message has a single short (less than 50 character) first line summarizing the change, a blank second line, and any additional lines as necessary for change explanation and rationale.
A patch is mergeable when it satisfies the above requirements and has been reviewed positively by at least one other person.
Development Process
editA user will log an issue on the issue tracker describing the problem they face or observe with as much detail as possible.
To work on an issue, a Contributor forks the plugin repository and then works on their forked repository and submits a patch by creating a pull request back to the plugin.
Maintainers must not merge patches where the author has not signed the CLA.
Before a patch can be accepted it should be reviewed. Maintainers should merge accepted patches without delay.
Maintainers should not merge their own patches except in exceptional cases, such as non-responsiveness from other Maintainers or core team for an extended period (more than 2 weeks).
Reviewer’s comments should not be based on personal preferences.
The Maintainers should label Issues and Pull Requests.
Maintainers should involve the core team if help is needed to reach consensus.
Review non-source changes such as documentation in the same way as source code changes.
Branch Management
editThe plugin has a master branch that always holds the latest in-progress version and should always build. Topic branches should kept to the minimum.