Migrate existing contrib libs to this repo

bryannaegele commented 3 years ago

Before moving the existing projects into this repo we need to settle on a couple of items.

Outstanding Questions

Directory Structure

There are a couple of patterns being used by the other langs. The Go repo https://github.com/open-telemetry/opentelemetry-go-contrib seems to have a nice structure which is also close to the Python structure https://github.com/open-telemetry/opentelemetry-python-contrib. The basic pattern on both of these is organizing libraries by function, e.g. instrumentation, exporter, propagator, etc. The JS repo groups packages slightly differently but it seems like more a function of the server/web split.

Package Naming

Most of the languages seem to have settled on including the library's function as part of the name, e.g. opentelemetry-instrumentation-redis or opentelemetry-exporter-zipkin. This is a divergence from our current naming patterns but it sees useful to easing adoption and otel concepts. This seems like the time to undertake the migration if we choose to do so.

Git History

Most of the history probably isn't worth keeping and we can archive the old repos under https://github.com/opentelemetry-beam as they migrate.

Proposal

I propose we adopt the patterns in Python and Go for directory structure, Python and JS for package naming, and not worry about keeping the Git history. We can migrate one at a time to get things moving and archive as we go along.

bryannaegele commented 3 years ago

Action Items

[ ] Add Contributing file with the basics, including CLA, hex package ownership, spec compliance, reviews, licensing, etc
[ ] Add sections to readme covering adding new vs migrating projects, including CLAs, directory structure, CI, project labels, etc. This could also be in Contributing with links
[x] Erlang CI setup

kw7oe commented 3 years ago

Do we have any plans on moving opentelemetry-beam/opentelemetry-examples into this repository as well?

If that's the case, is there any guidelines in general and do we need to add CI for that?

luizmiranda7 commented 3 years ago

I would suggest moving the http://hex.pm references to this repo. opentelemetry_phoenix hex page still points to the old repo.

Nezteb commented 2 years ago

Is this issue at a point where it can be worked on by non-contributors/members? I'd like to assist, but I wouldn't know where to start on the above "Action Items"

Admittedly despite reading the repo descriptions of this and https://github.com/open-telemetry/opentelemetry-erlang I still don't quite understand what functionality is supposed to go in which repo.

tsloughter commented 2 years ago

@Nezteb I think so.

Anything that isn't covered by the Otel Spec goes here. Which is why the zipkin exporter is in the main repo. And if a jaeger exporter were created it should go in the main repo instead of in contrib.

But basically everything that isn't part of the API or SDK goes here.

open-telemetry / opentelemetry-erlang-contrib