HIP: Enhance Helm Pull Request Lifecycle Policy #420
Conversation
Signed-off-by: Scott Rigby <scott@r6by.com>
| 34. `in progress` → GitHub draft PR status handles this | ||
| 35. `keep open` → automation can handle this | ||
| 36. `needs-pick` → release automation handles this | ||
| 37. `oci` → use title prefixes instead |
There was a problem hiding this comment.
Isn't more a "scope" ? Like feat(oci): or bug(sdk):
There was a problem hiding this comment.
This is what I meant by title prefixes 👍
There is a convention some projects use like area/AREA - we have only one label following that syntax, area/helm-test. But other labels like oci could perhaps follow this. At the moment I lean toward just using prefixing in the PR title like you said.
There was a problem hiding this comment.
maybe going with conventional commits language could be good, eg using scope/oci, scope/docs etc. I'm on the fence about this because often a PR touches more than one of these kinds of areas/scopes, and it seems to be a judgement call about whether to add this and if so what scope should be.
banjoh
left a comment
banjoh
left a comment
There was a problem hiding this comment.
Is the intention to rely on Conventional Commits as well when automating processes such as generating release notes?
|
|
||
| ### Conventional Commits Integration | ||
|
|
||
| #### Required PR Title Format |
There was a problem hiding this comment.
I'm finding this list quite long to remember. When someone is making a PR, they'll tend to choose from a few of these, meaning that some will never be used.
| - `build: description` for build system changes | ||
| - `ci: description` for CI/CD changes |
There was a problem hiding this comment.
I would bundle ci and build into one. Maybe ci. For changes related to building locally
| ### Policy Implementation | ||
|
|
||
| #### Triage Phase | ||
| - Triager or core maintainers update PR title to follow Conventional Commits format |
There was a problem hiding this comment.
Why not fail the build and expect the author to add the necessary categorisation. I'm leaning towards just using labels and not relying on conventional commits
3 participants
No description provided.