Code change:
In section it is said: The CRD can be either namespaced or cluster-scoped, as specified in the CRD's That text is wrong (a CRD object and the custom resource created from that CRD object are not the same). It should better say: The custom resource created from a CRD object can be either namespaced or cluster-scoped, as specified in the CRD's field
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
/wg API expression /language en I like the new wording you suggested - would you be willing to open a pull request proposing that fix?
The label(s) cannot be applied, because the repository doesn't have them. <detailsIn response to : /wg API expression /language en I like the new wording you suggested - would you be willing to open a pull request proposing that fix? </details
Thanks Yes, I am raising the PR. It is to be the first one I am creating against kubernetes documentation. Anything I should take care of? (thanks in advance ;-)
I found all details in . I am then following it ;-)
/wg api-expression
you've found the right guide. I hope it covers everything you need to know, but if it doesn't then please feel free to ask questions.
I don't see any updates; so unassigning you. Please feel free to assign it, if you come back here again and are willing to work on it! Thank you /unassign /good-first-issue
This request has been marked as suitable for new contributors. Please ensure that the issue body includes answers to the following questions: Why are we solving this issue? To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points? Does this issue have zero to low barrier of entry? How can the assignee reach out to you for help? For more details on the requirements of such an issue, please see and ensure that they are met. If this request no longer meets these requirements, the label can be removed by commenting with the command. <detailsIn response to : I don't see any updates; so unassigning you. Please feel free to assign it, if you come back here again and are willing to work on it! Thank you /unassign 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
Saw this good first issue with no one assigned, I could take it up /assign
Thanks a lot for putting hands on this ... and sorry a lot for not having done it myself as initially proposed (I was disconnected for some long time).

Related discussion:
text: ## Create a CustomResourceDefinition When you create a new CustomResourceDefinition (CRD), the Kubernetes API Server <del> creates a new RESTful resource path for each version you specify. The CRD can be either namespaced or cluster-scoped, as specified in the CRD's `scope` field. As with existing built-in objects, deleting a namespace deletes all custom objects in that namespace. CustomResourceDefinitions themselves are non-namespaced and are available to all namespaces. </del> <ins> creates a new RESTful resource path for each version you specify. The custom resource created from a CRD object can be either namespaced or cluster-scoped, as specified in the CRD's `spec.scope` field. As with existing built-in objects, deleting a namespace deletes all custom objects in that namespace. CustomResourceDefinitions themselves are non-namespaced and are available to all namespaces. </ins> For example, if you save the following CustomResourceDefinition to `resourcedefinition.yaml`: