EventRecorder comment contradicts with Event field comment

[npinaeva]

EventRecorder interface used for events/v1 says

client-go/tools/internal/events/interfaces.go

Lines 35 to 38 in 53c7e93

	// 'reason' is the reason this event is generated. 'reason' should be short and unique; it
	// should be in UpperCamelCase format (starting with a capital letter). "reason" will be used
	// to automate handling of events, so imagine people writing switch statements to handle them.
	// You want to make that easy.

implying that the field should be machine-readable. At the same time Event.Reason comment says

	// reason is why the action was taken. It is human-readable.
	// This field cannot be empty for new Events and it can have at most 128 characters.

https://github.com/kubernetes/api/blob/9dc1a952bda9aeb400aa6409b7d89eff50d6ea77/events/v1/types.go#L61-L63
implying it should be human-readable. Also, Event.Action field says it should be machine-readable, so I would expect it to be used for switch statements.
I am confused, please help.

[sundaram2021]

The reason field serves both machine-readable and human-readable purposes.

• Machine-readable: It follows UpperCamelCase formatting, making it suitable for automated processing (e.g., switch statements).
• Human-readable: It is also intended to be short and understandable to users when viewed in logs or UIs.

These are not mutually exclusive; the key is to balance readability for both humans and machines. A concise, formatted reason like PodScheduled can serve both purposes effectively.

some thing like can be a solution .....

[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