[Triage Process] Allow SIG maintainers to express their requirements

[svrnm]

Since #3990 is merged now, this fixes #4083

Changes

This introduces what has been discussed in #4083: it adds words to the issue management document to define the maintainer-blocked and maintainer-request labels and the process on how they can be applied by SIG maintainers.

• Related issues [Triage Process] Allow SIG maintainers to express their requirements #4083, Document issue triage labels #3990
• CHANGELOG.md file updated for non-trivial changes

[pellared]

I have a feeling that having a single maintainer-request label could be good enough. The TC can prioritize the issue based on their judgement. Different maintelainers may also have different opinions on what is a blocker and what is not.

[svrnm]

@pellared @reyang thanks for the initial feedback. I tried to distinguish between "blocked" and "requested" to create some kind of "escalation levels" but based on your comments and re-thinking this may not be necessary. I can rewrite it with only one label (maintainer-request ?)

[reyang]

@pellared @reyang thanks for the initial feedback. I tried to distinguish between "blocked" and "requested" to create some kind of "escalation levels" but based on your comments and re-thinking this may not be necessary. I can rewrite it with only one label (maintainer-request ?)

I don't have strong preference between the two proposals.

When I think about the process, I can see the following cases which we might need to consider:

1. If an issue is created by someone who is not a maintainer, later a maintainer saw it and said "Oh, that's exactly the issue that I'm facing right now", we need to have a way to tag it (we can also create a new issue and resolve the original one as duplicated, I don't like this approach though).
2. Issues targeting the "Development" or "Deprecated" part of the spec might have much lower priority than issues against the "Stable" part of the spec.

I understand that defining process is very hard. Nobody likes complicated process, but a big/complex project cannot succeed with clear/good process. THANK YOU for helping us to improve the process/efficiency @svrnm!

[pellared]

I prefer small incremental changes in processes when these are not totally wrong (and need be rebuild from ground 😉) Thus proposing just one label. It will be easier also for maintainers to use as they won't need to think which label to select.

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[svrnm]

Will follow up as soon as possible!

[svrnm]

20cef8e addresses the feedback provided:

• Use only one label and with that the wording how they are different
• Make it clear that a maintainer can also use comments on an existing issue to express their needs
• add links to the meetings + cncf slack

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.

[svrnm]

Can someone take a look at the recent changes I made?

[trask]

I'm supportive of trying this out

[jsuereth]

I'm on board to try that out. I think there's some unideal fallout due to how github works, but we can figure out how to work around that.

[svrnm]

I resolved the still open conversations since they were all outdated.