[Triage Process] Allow SIG maintainers to express their requirements

[svrnm]

What are you trying to achieve?

Note: This is an addendum to #3821, but I do not want to stall the PR for it (#3990) to be stalled any further.

An issue for especially (but not exclusively) smaller language SIGs¹, is that for them to influence the spec often feels impossible to accomplish. For one because they only have so much bandwidth themselves and need to focus on their implementation of the specification and second they feel reportedly treated like "external contributors" when they come to the spec with a requirement and not like an OpenTelemetry maintainer speaking to other OpenTelemetry Maintainers.

Since the language SIGs are the "primary customers" of the specification, I argue that they "deserve special treatment" if their issue is clearly linked to something they stumbled upon while implementing the specification in their respective language.

Therefore, I suggest that we extend the triaging process by the following:

• We add a sig:<language> label (similar to [meta] Define labels for each SIG language opentelemetry.io#1726), which is added to a new issue when it satisfies the following criteria:
  1. it was raised by a member of @opentelemetry/<language>-maintainers
  2. the issue description links to an issue (or PR) in opentelemetry-<language> that clarifies the underlying problem
  3. the SIG maintainer tags their GC liaison (the liaison can add the label if the maintainer lacks privileges on the repo)
• The same set of labels can be added to existing issues, when a comment to that issues satisfies the same requirement. Multiple tags of type sig:<language> can highlight that this is relevant to multiple SIGs.
• The same maintainer representing multiple language SIGs may apply multiple sig:<language> labels if they can provide issues from each language, although having one maintainer per SIG is preferred.

By applying those labels the triagers have the information that a certain issue is relevant for the language SIGs which can help to make a decision on rejecting/accepting it. Those issues should also be collected and reported to all maintainers on a regular basis to allow them to take a look as well (to add their sig:<language> label as well), e.g. during the weekly maintainers call or via the #otel-maintainers slack channel

CC @open-telemetry/cpp-maintainers, @open-telemetry/dotnet-maintainers, @open-telemetry/erlang-maintainers, @open-telemetry/go-maintainers @open-telemetry/java-maintainers @open-telemetry/javascript-maintainers @open-telemetry/php-maintainers @open-telemetry/python-maintainers @open-telemetry/ruby-maintainers @open-telemetry/rust-maintainers @open-telemetry/swift-maintainers

Update: Because of open-telemetry/community#2165 this also includes @open-telemetry/docs-approvers. Also sig:<language> or sig:<name> is just a suggestion, we can also aim for relevant-for-sig:<name> or blocking-sig:<name> (cc @arminru)

Footnotes

1. Other SIGs may have that requirement as well but to reduce the scope from "all SIGs" to something smaller to begin with I wanted to focus on the SIGs implementing the APIs & SDKs. ↩