Umbrella issue - API conventions, changes, review guidelines

This issue is to coordinate efforts to improve and add to the [API conventions](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md) and [API changes](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md) documentation, based on existing issues filed, and feedback from reviewers/shadows.

Questions encountered during designs/reviews (answer or clarify in existing docs):
- [ ] how should OS-specific fields be treated? should they be required to be empty or ignored when running on other OSes?

Issues encountered during code reviews (add guidance to relevant docs, or make more explicit if it already exists):
- [ ] don't increment storage version of a resource in the same release that introduces the new version (breaks HA upgrade)
- [ ] don't update callers that support version skew to older api servers (kubectl, controllers) to use new API versions in the same release where they are introduced
- [ ] when copying an existing resource to a new API group, [update roles to permit the new API group as well](https://github.com/kubernetes/kubernetes/pull/74531)

Checklists for developing and reviewing different types of API changes:
- [ ] New API group
- [ ] New resource
- [ ] New version of an existing resource
- [ ] New field in an existing resource (some guidance exists in [API changes](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api_changes.md) doc, ensure it is up to date)
- [ ] New allowed value in an enum field
- [ ] New value in a union type
- [ ] Tightening validation
- [ ] Relaxing validation

Items in the existing docs needing explanation or rationale
- ...

see also:
- [ ] PUT creating objects - https://github.com/kubernetes/community/issues/876
- [ ] name length limit - https://github.com/kubernetes/community/issues/814
- [ ] use of finalizers - https://github.com/kubernetes/community/issues/691
- [ ] conventions for RAW API fields - https://github.com/kubernetes/community/issues/357
- [ ] list of api_changes suggestions - https://github.com/kubernetes/community/issues/1297
- [ ] overall developer guide improvements - https://github.com/kubernetes/community/issues/3064

hoisted from https://github.com/kubernetes/community/pull/5842#discussion_r778487246:

* topic talking about reasons to use patch instead of read-modify-update:
* avoid touching/dropping fields you don't know about
* avoid precondition failures on rv if some other actor touched the object
* topic talking about how to use rv preconditions in conjunction with patch requests
* sweep existing "controllers" (including things like the kubelet) to see how they read from status fields of their objects to see if there are other patterns to follow or traps to avoid