github-mirrors/kibana
1
0
Fork 0
mirror of https://github.com/elastic/kibana.git synced 2025-06-27 18:51:07 -04:00
Code Issues Projects Releases Packages Wiki Activity

[DOCS] Add more PR label advice (#133245)

Browse source 
Co-authored-by: Kaarina Tungseth <kaarina.tungseth@elastic.co>
This commit is contained in:
Lisa Cawley 2022-06-02 16:18:19 -07:00 • committed by GitHub
parent f120dfb77d
commit ed8291510b
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
1 changed files with 34 additions and 1 deletions
Download patch file Download diff file Expand all files Collapse all files

35
dev_docs/contributing/how_we_use_github.mdx
View file

@ -131,7 +131,7 @@ would be useful to all teams, talk to your team or tech lead about getting it ad
### Team labels
Examples: `Team:Security`, `Team:Operations`.
Examples: `Team:Security`, `Team:Operations`, `Team:Docs`.
These labels map the issue to the team that owns the particular area. Part of the responsibilities of
(todo) is to ensure every issue has at least a team or a project
@ -178,3 +178,36 @@ it might mean the version the team is tentatively planning to merge a fix.
Consult the owning team if you have a question about how a version label is meant
to be used on an issue.
### Issue type and workflow labels
These labels categorize the type of work. For example:
- `blocked`: Indicates the issue is currently blocked
- `blocker`: Indicates that we should not release the product at the next
proposed version without the issue being resolved
- `bug`: Indicates an unexpected problem or unintended behavior
- `discuss`: Indicates that an issue is a discussion topic
- `docs`/`documentation`: Indicates improvements or additions to documentation
- `enhancement`: Indicates new feature or enhancement requests
- `meta`: Indicates that the issue tracks tasks related to a project
- `needs_triage`: Indicates that someone from the area team needs to investigate.
These labels affect whether your PR appears in the release notes (that is to say,
it's notable and affects our users) and which section it appears in. For example:
- `release_note:breaking`: Specifies a breaking change and adds the PR to the Breaking changes section in the release notes
- `release_note:deprecation`: Specifies a deprecated feature and adds the PR to the Deprecations section in the release notes
- `release_note:enhancement`: Specifies a feature enhancement and adds the PR to the Enhancements section in the release notes
- `release_note:feature`: Specifies a new feature and adds the PR to the Features section in the release notes
- `release_note:fix`: Specifies a bug fix and adds the PR to the Bug fixes section in the release notes
- `release_node:plugin_api_changes`: Specifies a changes to the plugin API and adds the PR to the Plugin API changes page in the Developer Guide
- `release_note:skip`: Omits the PR from release notes
These labels related to backporting PRs:
- `auto-backport`: Automatically backport this PR (to the branches related to
version labels) after it's merged
- `backport`: This PR was backported
- `backport:skip`: This PR does not require backporting