Change:
## Labels, annotations and taints used on API objects <ins> ### apf.kubernetes.io/autoupdate-spec Type: Annotation Example: `apf.kubernetes.io/autoupdate-spec: "true"` Used on: [`FlowSchema` and `PriorityLevelConfiguration` Objects](/concepts/cluster-administration/flow-control/#defaults) If this annotation is set to true on a FlowSchema or PriorityLevelConfiguration, the `spec` for that object is managed by the kube-apiserver. If the API server does not recognize an APF object, and you annotate it for automatic update, the API server deletes the entire object. Otherwise, the API server does not manage the object spec. For more details, read  [Maintenance of the Mandatory and Suggested Configuration Objects](/docs/concepts/cluster-administration/flow-control/#maintenance-of-the-mandatory-and-suggested-configuration-objects). </ins> ### app.kubernetes.io/component Type: Label

Discussion:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: According to , Kubernetes uses an annotation: . However, this annotation isn't registered (registration means adding it into ) Proposed Solution: Register and document the annotation. I am not sure which version of Kubernetes / will add the support for this annotation. Page to Update: <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /sig api-machinery /language en
This issue is currently awaiting triage. SIG Docs takes a lead on issue triage for this website, but any Kubernetes member can accept issues by applying the label. The label can be by org members by writing in a comment. <detailsInstructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
The label cannot be applied. Only GitHub organization members can add the label. <detailsIn response to : /triage accepted Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Anyone is welcome to work on this. See for information about contributing to Kubernetes, including to the documentation.
The label cannot be applied. Only GitHub organization members can add the label. <detailsIn response to : /triage accepted Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
hey can i work on this issue
Anyone is (still) welcome to work on this. See for information about contributing to Kubernetes, including to the documentation.
can you assign me this issue i would like to work on this issue
you are welcome to work on this issue; we have a no cookie licking policy in SIG Docs. Anyone is welcome to work on an issue. If someone has already said that they plan to work on it, it's polite to liaise with them first. However, a second contributor can join the effort: either by opening their own PR, by reviewing the first contributor's work, or by some other means such as pairing.

We rarely assign issues to contributors because of the policy on .
I'll add one thing. If people - including you - would like to document a missing annotation, take a look at Working top down (ie, oldest first) is even more helpful.
/assign