Labels, Milestones, and Triaging

[patrickblackjr]

Labels, Milestones, and Triaging

The following is a living issue, pinned to the top of domicile GitHub issues for wide visibility, that represents the current labeling, triaging, milestone, and maintenance state of domicile. Maintainers, contributors, and users may refer to this in order to understand how bugs and features are being triaged and where their feature request may be in the maintenance cycle.

Inspired by cobra

Labels

kind/ - The type of issue

kind/bug: A bug in domicile; unintended behavior kind/feature: A feature request for domicile; new or enhanced behavior kind/docs: Documentation kind/testing: CI/CD, testing, etc. for domicile. Usually also gets the github label kind/security: Related to security concerns in domicile itself. Refer to the security policy before opening any public issue. kind/deprecation: Related to a feature or part of code being deprecated kind/support: Questions, supporting users, etc.

area/ - The area of work that needs to be executed against

area/github: For changes to Github specific things not shipped in the app (like maintainers files, actions, etc)

triage/ - The state of an issue being triaged

triage/needs-triage: Needs to be placed into a milestone or be closed by maintainers. This label is removed once placed into a milestone. triage/blocked: Cannot move forward until some roadblock is lifted triage/needs-info: An issue that needs more investigation from maintainers or more info from the issue provider triage/duplicate: A duplicate issue. These issues are usually closed after receiving this label.

lifecycle/ - Where something is at in its lifecycle

lifecycle/active: Actively being worked on by a community member or maintainer. This label should also correspond with someone being assigned to the issue lifecycle/needs-proposal: For large features / bugs that need a proposal and community buy in lifecycle/approved: For large features / bugs that have a proposal and have gotten community buy in lifecycle/needs-pr: Ready for a PR from the community lifecycle/stale: Labeled by GitHub actions after 30 days of inactivity lifecycle/rotten: Labeled by GitHub actions after 30 days of having the lifecycle/stale label. Issues and PRs with this label will close after another 30 days of inactivity. lifecycle/frozen: Prevents GitHub actions from labeling Issues and PRs with lifecycle/stale or lifecycle/rotten `lifecycle/rejected: For issues and PRs the community has determined are not a priority and will not execute against

size/ - The size of the PR Utilizes the pr-size-labeler to label PRs with a given size per number of lines changed

size/xs: Denotes a PR that changes 0-9 lines size/s: Denotes a PR that changes 10-24 lines size/m: Denotes a PR that changes 24-99 lines size/l: Denotes a PR that changes 100-199 lines size/xl: Denotes a PR that changes 200 or more lines. Note: An XL pull request exceeds the recommended size of changes in a single PR. This is fine, but needs special attention from maintainers and may be rejected due to it's size. Make sure you are not addressing multiple issues in a single PR.

Milestones

Milestones are used to categorize work and contributions into specific releases.

The next milestone is used as a catch all for work that is being planned for some arbitrary upcoming release by the community The icebox milestone is used to track things that may need to be executed against eventually but are blocked, have the lifecycle/frozen label, etc.

Release cadence

domicile attempts to release quarterly. This is a best effort.

Generally, a pinned release tracker issue is made that corresponds with the current release. On release, tags will be made on GitHub that then can be consumed by downstream Go modules.

SemVer

domicile follows Semantic Versioning. This generally means that:

major bumps (i.e. v1.x.x to v2.x.x) have breaking changes (like deprecations, changing APIs, etc). minor bumps (i.e v1.1.x to 1.2.x) have no breaking changes, but include new features. patch bumps (i.e. v1.1.1 to v1.1.2) do not include new features or breaking changes but only backwards compatible bug fixes.