There is no policy regarding which instrumentations to accept

[ocelotl]

In the 2026-09-03 Python SIG meeting we discussed a topic: we don't have a policy on how to decide if we want to include a new instrumentation in the contrib repo or not.

Some context first

Definitions

A: an individual from the group of regular contributors, approvers, maintainers, etc. to this repo
B: an individual that does not belong to A

Contributions are very appreciated but maintaining new instrumentations can be difficult:

1. It is a growing load on maintainers
2. Maintainers may not be experts on the library the instrumentation instruments

For example, this scenario S may happen: B adds a new instrumentation X that instruments library Y, offers to maintain it and does. But after some time B is no longer able to maintain X and from that point on A has to maintain X.

Now, let's assume B is proposing adding X to this repo. What can A do?

A can only decide to accept or reject X.

That decision depends a lot on X. Since S may happen, A cannot count on B to maintain X. A has limited resources (time, mostly) so A must decide carefully to accept X or not. And that decision will be made depending on several factors, how critical X is, how many people will use it and so on.

What do I (@ocelotl) recommend?

I only see 2 possibilities here:

1. A accepts X and accepts to maintain X.
2. A rejects X.

and accepts to maintain X is the critical part here: so far A had counted on B to maintain X. I think A should reconsider that now.

What about A accepting X and then dropping it later if needed?

That's another possibility, but:

1. A first needs a policy on how to drop X
2. A could save all this trouble by simply rejecting X first

Something important here: A rejecting X does not mean there will never be an instrumentation for Y. A rejecting X only means X will not be in this repo. X can be in another repo.

What does Java do?

@trask joined the SIG meeting and shared with us the experience in Java, where they have 2 repos:

G: https://github.com/open-telemetry/opentelemetry-java-instrumentation
H: https://github.com/open-telemetry/opentelemetry-java-contrib

As far as I could understand there were instrumentations in both G and H and Java maintainers are commited to maintain the ones in G and not drop them but are ok with dropping one from H.

Now I am not sure I uderstood correctly because it seems to me like only G has instrumentations.

@trask please correct me here.

In any case, we need a policy to decide which instrumentations to accept, and this policy should be written down and define who will maintain such instrumentations. Please add your comments ✌️ 😎

@tammy-baylis-swi
@herin049
@xrmx
@lzchen
@aabmass
@lmolkova
@pmcollins
@carlosalberto

[ocelotl]

Just for reference, including the relevant section of our SIG notes here:

• [Leighton] Ownership of instrumentations: missing native cannot be a reason for rejection
  • feat: add opentelemetry-instrumentation-aerospike #4154
  • Process to also get rid of them
  • Diego: lockstep release is a limitation, better be strict
  • Riccardo:
    • not all instrumentations are created equals
    • Need to fix component owners model
  • Aaron: feedback: if -contrib model was better we woulnd’t end up with so many genai instrumentations
    • Maybe a sponsorship model, be a codeowner for some other package
  • Liudmila:
    • We can learn from java experience
    • Have a plan on how to handle this
  • Diego: don’t count on people without group privileges (approvers, maintainers) to maintain stuff
  • Lukas: we can take into account PyPi popularity but we should not stop to accept new instrumentations in -contrib altogether
  • Trask:
    • java has instrumentation repo that is maintainer owned (no component owners), more picky
      • For stuff we don’t understand we trust tests
      • Lot of test infrastructure
      • Leverage ai to compare instrumentations of similar kind
      • Sdk components harder to get in
      • We have a java agent knowledge base to get PRs in decent shape before having to review them
      • 100+ instrumentations
      • Support very old versions of libraries, rarely / never drop autoinstrumentation support
      • “As long as it look like the other similar instrumentation” should be fine
      • Pushback on instrumentations for personal projects
      • Test minimum and latest version, nightly job to check latest version (ai nice to fix issues)
        • We may test intermediate versions
        • Tool that checks api shape (muzzle)
      • stable Telemetry guarantee, breaking on major only
    • Contrib has component owner model
      • <50 instrumentations
  • Java https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/docs/safety-mechanisms.md
  • https://github.com/open-telemetry/opentelemetry-java-instrumentation/blob/main/VERSIONING.md#dropping-support-for-older-library-versions

[ocelotl]

A question regarding this has been asked here: #5033