Community: Need a contrib / ecosystem repository to store non-core code

[flands]

In OpenCensus we had census-ecosystem to store non-core code to the project. We need something similar for OpenTelemetry. The immediate need is for storing non-core exporters. For more information see https://github.com/open-telemetry/opentelemetry-service/issues/140

[flands]

/cc @bogdandrutu

[bhs]

I'm positive about this, too. (we had opentracing-contrib for these purposes) Very helpful, esp as the number of contributed repos outpaces the number of "core" repos over time.

[mtwo]

+1

---

From: Ben Sigelman [e-mail]
Sent: Wednesday, July 10, 2019 4:54:35 PM
To: open-telemetry/community
Cc: Subscribed
Subject: Re: [open-telemetry/community] Need a contrib / ecosystem repository to store non-core code (#148)

I'm positive about this, too. (we had opentracing-contrib for these purposes) Very helpful, esp as the number of contributed repos vastly outnumbers the number of "core" repos over time.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHubhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopen-telemetry%2Fcommunity%2Fissues%2F148%3Femail_source%3Dnotifications%26email_token%3DAAIXLK3VE3SOUPACKIWA2C3P6ZZDXA5CNFSM4IADNN32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZVCLOA%23issuecomment-510272952&data=02%7C01%7C%7Ca1a471bb299845a813b308d70591f6e8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636983996774730700&sdata=bL2EdGhaki73rPNHsG0RoMjMiE2Vc5GvFsPAKZvQe1Y%3D&reserved=0, or mute the threadhttps://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAAIXLKY6YT4ZVFRFN3VQ5GLP6ZZDXANCNFSM4IADNN3Q&data=02%7C01%7C%7Ca1a471bb299845a813b308d70591f6e8%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636983996774740699&sdata=Ph6ZEbxlJRGaG8JubVYipLBSJ5m7k1oCujuZyAcMJQo%3D&reserved=0.

[yurishkuro]

opentelemetry-contrib?

[bogdandrutu]

For consistency I would go with open-telemetry-contrib unless we move to opentelemetry. Maybe worth reserving both.

[bhs]

Ugh, that's a good point re the -!

Reserving both seems like the right move. I am happy to do this if we are ok with contrib as the suffix.

[bogdandrutu]

@flands to unblock your work I created https://github.com/open-telemetry/opentelemetry-service-contrib, this will be moved to the new org when setup (CLA, etc.).

[bhs]

We talked about this a bit at the last OpenTel governance committee meeting... TL;DR we felt the the OpenTracing "registry" ended up being a better solution to the discoverability problem than the opentracing-contrib organization; and that having a contrib org with essentially zero rules about code quality, licensing, etc, can turn into a bit of a dumping ground that actually reduces confidence in the higher-quality repos in said contrib org.

As such, the current thinking is as follows:

• do create a separate org (open-telemetry-contrib, I guess?)
• create a "template" repo within contrib that specifies the APL, ultra-basic code of conduct, ultra-basic "micro-governance" rules, etc
• allow people to basically stamp that template into contrib repos as needed
• perhaps (?) do some sort of badging to indicate repo maturity... the OpenTelemetry TC would make the call about maturity.

@sarahnovotny @bogdandrutu @SergeyKanzhelev @yurishkuro does that sound like what we discussed?

Happy to take feedback from anyone in the larger community about this, too, of course!

[tigrannajaryan]

and that having a contrib org with essentially zero rules about code quality, licensing, etc, can turn into a bit of a dumping ground that actually reduces confidence in the higher-quality repos in said contrib org.

To avoid this I think we need relevant core members of OpenTelemetry to commit to guide/help the appropriate parts of contrib org. For instance we want to have a "contrib" for OpenTelemetry Service for vendors to contribute support for their protocols. As OpenTelemetry Service SIG maintainer I plan to review PRs, comment on issues and otherwise help the contributors of "contrib".

We need to seed the contrib repos with initial people who have approval rights anyway. Current maintainers/approvers are the best place to start.

ultra-basic code of conduct,

I think we can start with a copy of OpenTelemetry code of conduct.

[austinlparker]

One thing we could think about doing is having part of the template repo include a metadata file (similar to the ones in the opentracing registry, see https://raw.githubusercontent.com/opentracing/opentracing.io/master/content/registry/csharp-jaeger-tracer.md for an example). This would theoretically let us streamline the registry process a bit, maybe give people a form to fill out with the link to their metadata file and have an automated process that kept track of them + pulled the information into the site.

[yurishkuro]

I like the metadata file idea, but there are a couple of issues with it:

• it still requires a commit to the registry because some repos maybe hosted outside of OpenTelemetry org
• if we want to support maturity badges then those need to be curated so that they cannot simply be changed by the repo author, which means they need to be defined elsewhere (namely the registry)

[bhs]

We may be getting off-topic, but about the registry: I feel great about having a registry, but def want to get out of the model where there's a central file somewhere that requires a commit.

@yurishkuro I think this is still attainable for external repos... we could basically establish a convention that you need to add an opentelemetry (or opentelemetry-registry) "tag" to the github repo... we could then have the registry script / cron job do something like this:

1. Query the public GitHub API to discover all repos with that ^^^ tag
2. Foreach such repo, look for the registry metadata file and incorporate it into the registry

Thoughts?

[austinlparker]

I think GitHub topics would work OK. I'm a bit leery of tying things so closely to an API that's still in preview, but eh. If it went away for some reason, we could figure out a different way to discover the metadata (manually submitting repos or something). I like that the metadata is decentralized.

To Yuri's point, I think we can just use the honor system for making sure people don't use maturity badges they "shouldn't" be.

[tedsuo]

Breaking down this issue into two categories, here is my suggestion:

• A registry for the ENTIRE OpenTelemetry ecosystem, regardless of who is maintaining it and where it is hosted (implementation TBD). This is a discoverability mechanism.
• A contrib or ecosystem GitHub org is for non-core code which we as core community members are committed to maintaining. Code repos are moved to this org in order to share the maintenance burden, not for discoverability.

In more detail:
The reason we want an ecosystem org is because we want canonical or "blessed" implementations for critical instrumentation (rails, spring, etc). OpenTelemetry is only as good as the data it produces - we are saying that we are willing to maintain critical chunks of the ecosystem as a community.

If we aren't willing to maintain chunks of the ecosystem, then there is no point in blessed repos, and thus there is no point in an ecosystem organization. All we need is a registry. But I believe we should commit to this set of work, given that we are trying to develop semantic conventions and maintain a high level of uniformity across instrumentation packages. An ecosystem organization would facilitate that.

[bhs]

@tedsuo I think that's a :100: summary of my own thinking. If it sounds correct, we can create the -contrib org and a README that explains what belongs there, what does not, and so forth.

Only caveat is that there's no OpenTel registry at the moment, though we could draft a spec and some functional requirements (around discovery, etc) easily.

[tedsuo]

Bringing this issue back from stasis. I am seeing all of the SIGs starting to create non-core code, such as exporters and plugins. So in general we should have a plan for how to manage these repos.

Last couple of discussions, it seemed like people were leaning towards keeping all repos in the same open-telemetry org, rather than using open-telemetry-contrib, as it would simplify permissions. The python team can manage all of the python repos, etc. For code that the SIGs are not directly maintaining, like 3rd party plugins, I don’t believe we want to host those repos this time, like we were in OpenTracing. For third party code, we will only provide a registry on our website for discoverability.

In general, I would like OpenTelemetry to be adopted by library and project maintainers, and the plugins for their code to eventually be moved over to their own orgs. For example, Jaeger and Prometheus maintain their own exporters, and frameworks/libraries maintain their own instrumentation. For critical plugins, we will seed the efforts and start them in our own org – OpenTelemetry can't function effectively without them – but we want to transfer ownership as soon as the original project maintainers become interested in maintaining them.

[SergeyKanzhelev]

I think we are following the -contrib repository prefixes approach. Let's re-open when this solution will not scale any longer