chore: Add KEP to the supported PR titles

[szaher]

What this PR does / why we need it:

SDK PRs needs to support a new type for proposals

Which issue(s) this PR fixes (optional, in Fixes #<issue number>, #<issue number>, ... format, will close the issue(s) when PR gets merged):

Fixes #

Checklist:

• Docs included if any changes are user facing

[google-oss-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign andreyvelich for approval. For more information see the Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[coveralls]

Pull Request Test Coverage Report for Build 17143541281

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.3%) to 64.877%

---

Totals
Change from base Build 17059769083:	0.3%
Covered Lines:	290
Relevant Lines:	447

---

💛 - Coveralls

[kramaranya]

Do we really need it? I think we should use feat: KEP-NN

[szaher]

I would say yes, KEP is different from features. features are new features that we introduce to the sdk but KEP is a proposal or enhancement proposal.

[kramaranya]

We can just use feat(docs): KEP-NN for that

[szaher]

proposal are not really docs... wDYT?

[andreyvelich]

I kind of agree with @kramaranya, we can use (docs) scope for KEPs. Otherwise, we can just to feat: KEP-nn, since scope is not required.
I would like us to keep feat, fix in the title name since it is easier to group them in CHANGELOG later.

[szaher]

if we use feat it will be confusing to users or whoever reads the changelog or release notes. Users would assume this feature is already implemented as the release notes mentions it as one of the PRs.

If we add KEP it clearly signals this is a TODO or planned feature...

feat: Local Execution >>> contains KEP
feat: Local Execution >>> Actual implementation

cc: @andreyvelich @kramaranya

[andreyvelich]

Yeah, but we can group them in the dedicated subsection in the CHANGELOG, like we did here:
https://github.com/kubeflow/trainer/blob/master/CHANGELOG.md#llm-trainer-v2

[andreyvelich]

FYI, KFP also uses docs prefix for KEPs: kubeflow/pipelines#11551

[szaher]

If we add the KEP type I think it will be consistent with the following.

which I believe is cleaner.

With KEP type
KEP 2: Local execution
feat: Local execution

Without KEP type (Current Behaviour)
docs: KEP-2 Local exection
feat: Local execution

Which one do you think is cleaner?

I believe we can group both or leave both in the release notes in the respective sections

[andreyvelich]

I suggest that we use feat: and fix: prefix, and we add the KEP number after.
E.g.:

feat: KEP-2 - Add local backend for KF Trainer
fix: KEP-2 - Update the runtime return type
chore: KEP-2 Add unit tests for utils

Since that will be simpler to group fixes, chores, and features dedicated to the particular KEP.

[kramaranya]

I agree with @andreyvelich, that would be much cleaner. Also, if we add a KEP prefix, it could confuse contributors, and they might end up using both options:

feat: KEP-NN - ...
KEP-NN: ...

So I think it’s better to stick with one clear format to keep it consistent