There is no policy regarding which instrumentations to accept

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

Start by reviewing this issue and its two comments, then compare the Java repositories G and H and the maintenance approach discussed in the meeting. Done means the contributors agree on a written policy for accepting or dropping instrumentations and identify who is responsible for maintaining accepted instrumentations.