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[^1], 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:
it was raised by a member of @opentelemetry/<language>-maintainers
the issue description links to an issue (or PR) in opentelemetry-<language> that clarifies the underlying problem
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
[^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.
Update: Because of https://github.com/open-telemetry/community/issues/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)
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[^1], 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:
sig:<language>label (similar to https://github.com/open-telemetry/opentelemetry.io/issues/1726), which is added to a new issue when it satisfies the following criteria:@opentelemetry/<language>-maintainersopentelemetry-<language>that clarifies the underlying problemsig:<language>can highlight that this is relevant to multiple SIGs.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 channelCC @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
[^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.
Update: Because of https://github.com/open-telemetry/community/issues/2165 this also includes @open-telemetry/docs-approvers. Also
sig:<language>orsig:<name>is just a suggestion, we can also aim forrelevant-for-sig:<name>orblocking-sig:<name>(cc @arminru)