Instrumentation acceptance policy and general guidelines for external instrumentation authors

[srikanthccv]

We don't have a formal written policy for this yet. As a SIG, we have decided not to accept instrumentation unless there is a solid reason. We should have a written policy.

[dacevedo12]

what is considered a 'solid reason'?

[srikanthccv]

It's probably not phrased correctly, but we have yet to write a clear policy to convey that. We have in the past and continue to push for either adding the instrumentation directly into the library litestar-org/litestar#796, faust-streaming/faust#382 or outside this repo. There is no need for everything to be put here. The packages maintained outside can always be added to the registry https://opentelemetry.io/ecosystem/registry/ to make them discoverable by a large audience.

[dacevedo12]

Just out of curiosity, is this a policy that all of OTel is on board with or is it just OTel python at the moment?

I've submitted a couple of PRs here (and was planning for more) to try to get OTel python stronger vs the number of instrumentors other languages have, so it would be a shame to close them and delay delivering value to other Pythonistas in the look of better observability.

Totally understand and respect the decision though. If this policy is to be enforced from now on, I'll close my PRs and try to contribute them directly to the libraries instead.

[lzchen]

@dacevedo12
Hey thanks for taking an interest in contributing to Otel Python. This policy was decided internally by the OT Python team. I believe a few other languages have adopted it in practice but it has never been formalized. Currently we are very short on maintainers and approvers so an ever-growing list of instrumentations is a difficult maintenance burden. Coupled with the fact that there has been several instances of contributors contributing an instrumentation that none of us are familiar with, leaving us with having to support libraries in which we do not have expertise in. We have tried to circumvent this with component_owners but it does not seem that many people are interested in continuous support.

Thanks for being an active contributor.

[srikanthccv]

Adding to what @lzchen said, There is no formal all OTEL level policy about this. I don't think such will exist in future. The maintainers of the subgroups have followed some policies that help them manage better. The go-contrib maintainer's team has had one such policy for a long time https://github.com/open-telemetry/opentelemetry-go-contrib/tree/main/instrumentation#new-instrumentation; the collector-contrib does something similar where new component requires a sponsor and any inactivity from the code owner gets the package removed from the distro https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/CONTRIBUTING.md#adding-new-components. These are two SIGs I personally know. There may be other SIGs that have something similar.

The component owners initially agree to provide continuous maintenance but do not keep the agreement after some time, and we have to take the maintenance ownership. There are several instances of this but here is one such instance #1655 (comment), #1655 (comment)

[dacevedo12]

I'd like to bring up this topic again to check if there have been any changes.

There are several open PRs that would be affected by this decision. It would be nice for the contributors to receive opportune feedback, closing the PRs and letting them know so they can start working on instrumentations elsewhere.

Thanks,

• Instrument mysqlclient library #1744
• Add graphql-core instrumentation #1719
• Add aiobotocore instrumentation #1709
• Cherrypy instrumentation #1410
• feat: Implement initial pulsar support #1405
• [WIP] Add support for AsyncElasticsearch #1007
• Add instrumentation for aioredis #569
• Add pymssql instrumentation #394
• Aiohttp server instrumentation #942

[kennytrytek-wf]

@srikanthccv, could you respond to the latest comment from @dacevedo12? If any of these pull requests are going to be denied, it is not worth our effort to continue to work on them here, and that effort would be better spent moving the implementation to another repository.

[srikanthccv]

I am no longer part of the maintainer's group so I will let @lzchen , @ocelotl comment on this.