Create new label for feature blogs for Release Comms and Blog Team tracking

[natalisucks]

What would you like to be added:

During the v1.30 Release Docs Team retro, facilitated by SIG Docs, an idea that @sftim and @kcmartin discussed during the release cycle was creating a new label for feature blogs, which would give both the Release Comms and Kubernetes Blog teams a better way to track feature blogs.

I resurfaced this idea in the retro after a 1:1 with Kristin, and it was agreed by the participants that this would be a useful feature.

Why is this needed:

We had an issue during the v1.30 release where there was confusion about which blogs were considered feature blogs, or which should live on the Kubernetes Contributor site. That confusion led to a decision being taken out of the Release Team's hands, despite following the appropriate processes of tracking in the Enhancements tracking board and commenting in the blog PR.

Having a label takes away any ambiguity and also means there is a trail if a decision about a feature blog is changed, as the label would be added/removed. It also creates an easy way to track and filter this work for both teams.

/area release-team

[natalisucks]

/cc @katcosgrove @gracenng

[k8s-triage-robot]

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

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[natalisucks]

/remove-lifecycle stale

[k8s-triage-robot]

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

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle stale

[k8s-triage-robot]

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

This bot triages un-triaged issues 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 as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

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

/lifecycle rotten

[sftim]

/remove-lifecycle rotten

The same label would be handle to have in k/website too