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

[danielgblanco]

I like this idea. However, I also think we should make a distinction between the use of these labels as described above, and the use of these labels for cases where an external contributor opens an issue in the spec and triagers would like specific SIGs to have a look at it. In those cases, I think using Project Boards, adding issues to boards (in an icebox type column) for each SIG, would potentially achieve a better result, as SIGs should be reviewing their Project Boards frequently.

[codefromthecrypt]

I think having language sig tags part of semantic process has another side benefit, which is a force function to have at least one language implement the output of the SIG (in a non-vendor org).

We can also consider some improvements that can show how well things are working. For example, specification tests are a nice way to setup traps where developers can find out if a spec drifted them, even without being pinged explicitly. Developers can engage more with the sig as they can define canonical tests, fix them, and report in coherent ways what doesn't seem right, all without going to meetings. If they do go to meetings, that time can be better caged to something to elaborate. Not only does this make things more coherent, but in ways developers get stats (credit) for. I think something like this can help reduce a sense of "external contributors" as they are primary contributors, just to code defining the spec not just english.

[svrnm]

I like this idea. However, I also think we should make a distinction between the use of these labels as described above, and the use of these labels for cases where an external contributor opens an issue in the spec and triagers would like specific SIGs to have a look at it. In those cases, I think using Project Boards, adding issues to boards (in an icebox type column) for each SIG, would potentially achieve a better result, as SIGs should be reviewing their Project Boards frequently.

Good call out. This issue here is for "incoming issues", so those labels should not be used to indicate that a SIG needs to implement something, the labels should indicate that the SIG ran into a particular issue while implementing and is flagging this now (that's why relevant-for or blocking-for etc might be better than simply sig:...`

Developers can engage more with the sig as they can define canonical tests, fix them, and report in coherent ways what doesn't seem right, all without going to meetings.

This is maybe a broader topic, but also important to note. Thanks for calling it out

[jack-berg]

Discussed in 7/31/24 TC meeting. Would like more clarification on this and recommend discussing in the next TC/GC meeting. There was some consensus that tracking this type of thing with issue labels would be a valuable signal / reminder.

[carlosalberto]

Hey,

We discussed this during the last GC/TC joint call and here are some notes:

• Specially important for issues from maintainers who are in time zone that makes it hard to attend the Spec call.
• General triaging and labeling should help this, e.g. a "maintainer-blocked" or "maintainer-request" label.
• For such issues we will need people who can actually drive changes (remember, maintainers are blocked).
• An example of an issue like this could be stoping instrumentation via Context: Use Context to stop tracing #530

More importantly, we need to agree on a next step, which IMHO should start with defining such special label.

[jack-berg]

General triaging and labeling should help this, e.g. a "maintainer-blocked" or "maintainer-request" label.

Can someone open a PR to define these labels for the spec triage process? Then we can point maintainers to the process and use the labels as part of prioritization. Maintainers don't have write permission, and won't be able to add this label themselves, but we can document a process where maintainers leave a comment indicating that this is blocking their SIG, and a spec triager can respond by adding the appropriate label.

[svrnm]

Can someone open a PR to define these labels for the spec triage process?

I can create a PR, but I wonder if #3990 should be merged/finished first?