|
| 1 | +# **PRs** |
| 2 | + |
| 3 | +To categorize PRs, we use GitHub labels. Before a PR can be merged, it must be assigned one of the following **kind/** labels, as these labels are used to generate automatic release notes: |
| 4 | + |
| 5 | +- **kind/enhancement** - For PRs that add new features or improve existing functionality. This label should also be applied to PRs that improve documentation and testing, for example. |
| 6 | +- **kind/bugfix** - For PRs that resolve bugs. |
| 7 | +- **kind/refactor** - For PRs that improve code without changing its behavior. |
| 8 | +- **kind/dependencies** - For PRs that update dependencies or related components. |
| 9 | + |
| 10 | +## PR release notes |
| 11 | + |
| 12 | +GitHub release notes are automatically generated from PRs based on the assigned **kind/** labels, along with the PR title. To exclude PRs from release notes, add the **release-notes/ignore** label. |
| 13 | + |
| 14 | +--- |
| 15 | + |
| 16 | +# **Issues** |
| 17 | + |
| 18 | +Issues are categorized using the following three **GitHub types** (not GitHub labels): |
| 19 | + |
| 20 | +- **bug** - Reports an unexpected problem or incorrect behavior. |
| 21 | +- **enhancement** - Suggests a new feature, improvement, or idea. |
| 22 | +- **design** - Relates to design considerations or decisions. |
| 23 | + |
| 24 | +To track the lifecycle of issues, we also use GitHub labels: |
| 25 | + |
| 26 | +- **lifecycle/needs-review** - A temporary label indicating that the issue has not yet been reviewed. |
| 27 | +- **lifecycle/confirmed** - Confirms the issue’s validity: |
| 28 | + - If the issue type is **bug**, the bug has been verified. |
| 29 | + - If the issue type is **enhancement**, the proposal has been deemed ready for implementation. |
| 30 | + - This label does not indicate when the fix or enhancement will be implemented. |
| 31 | +- **lifecycle/needs-info** - The issue requires additional information from the original poster (OP). |
| 32 | +- **lifecycle/blocked** - The issue is blocked by another issue or external factor. |
| 33 | + |
| 34 | +The following labels should be applied to issues prior to closing, indicating the resolution status of the issue: |
| 35 | + |
| 36 | +- **lifecycle/fixed** - The issue has been resolved. |
| 37 | +- **lifecycle/duplicate** - The issue is a duplicate of another issue. |
| 38 | +- **lifecycle/not-a-bug** - The issue is not considered a bug, and no further action is needed. |
| 39 | +- **lifecycle/wont-fix** - The issue will not be fixed. |
| 40 | + |
| 41 | +In addition to lifecycle labels, we use the following labels to further categorize issues: |
| 42 | + |
| 43 | +- **question** - The issue is a question or request for information. |
| 44 | +- **help-wanted** - The issue is a request for help or assistance. |
| 45 | +- **good-first-issue** - The issue is suitable for new contributors or those looking for a simple task to start with. |
| 46 | + |
| 47 | +--- |
| 48 | + |
| 49 | +# **Issues & PRs** |
| 50 | + |
| 51 | +In addition to **kind/*** labels, we use optional **area/*** labels to specify the focus of a PR or issue. These labels are purely for categorization, are not mandatory, and are not used for release notes. |
| 52 | + |
| 53 | +- **area/documentation** – Related to documentation updates or improvements. |
| 54 | +- **area/API** – Related to the API or public interface. |
| 55 | +- **area/infrastructure** – Concerns infrastructure rather than core functionality. |
| 56 | +- **area/performance** – Addresses performance. |
| 57 | +- **area/security** – Involves security-related changes or fixes. |
| 58 | +- **area/testing** – Related to tests or testing infrastructure. |
0 commit comments