Robert Pająk

_Writing my thoughts before I forget._ I think that also each "auto-instrumentation" tool/agent/library/whatever should provide a high-level description of what this auto-instrumentation is and how it works. [Here](https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation/blob/main/docs/design.md#architecture) is how...

> whether the SDK requires code changes to be initialized or not This is how I understand the main difference. It should be possible to set up without making ANY...

@svrnm @austinlparker I am missing something. Where auto-instrumentation is used as a verb? For me it is a noun. Personally, I understand auto-instrumentation as "a method of getting the application...

I think we are nowhere near changing the name to "agent". Still, this issue uncovers some problems that we currently have (as a whole community). One of the problems is...

@reyang Could we also try consistently naming the "auto-instrumentation" repositories or is it too much for this issue? Current state: 1. [OpenTelemetry Instrumentation for Java](https://github.com/open-telemetry/opentelemetry-java-instrumentation) 2. [OpenTelemetry .NET Automatic Instrumentation](https://github.com/open-telemetry/opentelemetry-dotnet-instrumentation)...

@open-telemetry/dotnet-instrumentation-approvers It looks as if it is not a problem as the spec defined the behavior for SDK and not for automatic instrumentation.

I think we can even use methods like `SetOtlpMetricsExporter(int port)` that would simply call `SetEnv*Var*`. I think we do nave need optional parameters or other config types. It would simplify...

I think we are good to close it. I suggest to wait for @rajkumar-rangaraj to confirm.

@RassK Yes. Thanks.

What do you mean by "more locked down" and "reliable"? What are the differences other than `mage -version` printing the version? Downloading them manually is not so efficient especially for...