[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.

[pellared]

What if there is something missing in the specification that blocks the implementation?

[reyang]

I guess we can use bug for things that require fixes. And if maintainers are blocked by things that don't exist yet, those can be tagged as feature. (side note: most GitHub repositories make heavy use of these labels, the fact that OTel spec repo doesn't use it frequently is somewhat odd to me)

[pellared]

they can go forward with the implementation regardless

This seems very unwanted

[reyang]

👀

[carlosalberto]

+1 to what @pellared said. Also, for cases of adding new functionality, there's the OTEP path. Implementation specific doubts (to leave out ambiguity) are fine though, IMHO. But honestly we could use the maintainer-blocked label for that purpose too.

[pellared]

Shouldn't ambiguity be a blocker?

[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?