kubebuilder icon indicating copy to clipboard operation
kubebuilder copied to clipboard

Define and doc an standard for the PR titles to make clear specific plugins changes

Open camilamacedo86 opened this issue 2 years ago • 8 comments

What do you want to happen?

IMO: We need to discuss in the community meeting what standard we would like to have to make clear in the release notes that the changes made are valid only for some specific plugin (to be easier for users to have this information by looking at the release notes). Then, we need to doc it out in: https://github.com/kubernetes-sigs/kubebuilder/blob/master/CONTRIBUTING.md (to make clear for contributes how that need to be done, when and why)

See the release notes: https://github.com/kubernetes-sigs/kubebuilder/releases

Some options/suggestions:

  • <icon indicating whether it's a> ( plugin/version ) : <description>
  • <icon indicating whether it's a> For plugin/version, : <description>

See how we do it in the templates to generate the release notes in SDK:

https://github.com/operator-framework/operator-sdk/blob/master/changelog/fragments/00-template.yaml#L10-L14

Extra Labels

No response

camilamacedo86 avatar Mar 21 '22 10:03 camilamacedo86

May I suggest the 🔌 :electric_plug: Icon? Seems fitting 😄

mariuskimmina avatar Mar 21 '22 11:03 mariuskimmina

The icons are used to define bug fixes, breaking changes and etc:

Every PR should be annotated with an icon indicating whether it's a:

  • Breaking change: :warning: (:warning:)
  • Non-breaking feature: :sparkles: (:sparkles:)
  • Patch fix: :bug: (:bug:)
  • Docs: :book: (:book:)
  • Infra/Tests/Other: :seedling: (:seedling:)
  • No release note: :ghost: (:ghost:)

Then, it will be used to. break the subsections in the release notes. ( https://github.com/kubernetes-sigs/kubebuilder/releases)

Not sure how the :electric_plug: Icon would fit in this case.

camilamacedo86 avatar Mar 21 '22 12:03 camilamacedo86

Oh, maybe I missunderstood your request, I thought you wanted to have a new one for PRs related to plugins? My bad if that was not the case

mariuskimmina avatar Mar 21 '22 13:03 mariuskimmina

Teh goal is to define a standard for the releases notes which are Breaking changes, Patch fix, etc but that does affect the specific plugin and not all. See the examples in the release notes with (go/v2 or go/v3) for example: https://github.com/kubernetes-sigs/kubebuilder/releases

camilamacedo86 avatar Mar 21 '22 17:03 camilamacedo86

Hey @camilamacedo86 🙂 I can work on this if this issue is not assigned to anyone.

Ankit152 avatar Mar 23 '22 06:03 Ankit152

HI @Ankit152,

We will need first to check with the Community what the standard should be and what they think about it. Then, we can move forward. I am hoping we have this conversation in the next KB / C+R meeting : https://docs.google.com/document/d/1Ih-2cgg1bUrLwLVTB9tADlPcVdgnuMNBGbUl4D-0TIk/edit#heading=h.dp4gt7gj3cn

camilamacedo86 avatar Mar 23 '22 10:03 camilamacedo86

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

  • After 90d of inactivity, lifecycle/stale is applied
  • After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
  • After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

  • Mark this issue or PR as fresh with /remove-lifecycle stale
  • Mark this issue or PR as rotten with /lifecycle rotten
  • Close this issue or PR with /close
  • Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

k8s-triage-robot avatar Jun 22 '22 16:06 k8s-triage-robot

/remove-lifecycle stale

camilamacedo86 avatar Jul 12 '22 22:07 camilamacedo86

Done, It is added in the contribution guide now.

camilamacedo86 avatar Dec 08 '22 08:12 camilamacedo86