github-mirrors/kibana
1
0
Fork 0
mirror of https://github.com/elastic/kibana.git synced 2025-04-23 17:28:26 -04:00
Code Issues Projects Releases Packages Wiki Activity

Removing outdated instructions on labeling PRs with versions

Browse source
This commit is contained in:
Shaunak Kashyap 2016-04-06 14:49:03 -07:00
parent 53b05e9d99
commit f6b6feea0a
No known key found for this signature in database
GPG key ID: 0512E188DDE4FF2A
1 changed files with 0 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

1
CONTRIBUTING.md
View file

@ -210,7 +210,6 @@ Then sit back and wait. There will probably be discussion about the pull request
After a pull is submitted, it needs to get to review. If you have commit permission on the Kibana repo you will probably perform these steps while submitting your pull request. If not, a member of the elastic organization will do them for you, though you can help by suggesting a reviewer for your changes if you've interacted with someone while working on the issue.
1. Assign the `review` tag. This signals to the team that someone needs to give this attention.
1. Assign version tags. If the pull is related to an existing issue (and it should be!), that issue probably has a version tag (eg `4.0.1`) on it. Assign the same version tag to your pull. You may end up with 2 or more version tags if the changes requires backporting
1. Find someone to review your pull. Don't just pick any yahoo, pick the right person. The right person might be the original reporter of the issue, but it might also be the person most familiar with the code you've changed. If neither of those things apply, or your change is small in scope, try to find someone on the Kibana team without a ton of existing reviews on their plate. As a rule, most pulls will require 2 reviewers, but the first reviewer will pick the 2nd.
### Review engaged