Add a warning to browser getting started

[svrnm]

We have the same warning now for Manual instrumentation - Browser, I think the getting started should have it as well, because at least I get ~weekly questions around OTel for browser/mobile/etc.

[chalin]

Oh, sorry, I missed that warning in the manual page earlier, but now it makes me want to ask: Why is the OTel JS status not reflecting this "experimental" status?

[svrnm]

Oh, sorry, I missed that warning in the manual page earlier, but now it makes me want to ask: Why is the OTel JS status not reflecting this "experimental" status?

Because browser and nodejs are different here. Good point, maybe we should also add some clarity on that page.

[pichlermarc]

Oh, sorry, I missed that warning in the manual page earlier, but now it makes me want to ask: Why is the OTel JS status not reflecting this "experimental" status?

Because browser and nodejs are different here. Good point, maybe we should also add some clarity on that page.

I fully agree. We should also do it in the OTel JS repo's README, as it could be clearer from that one too. I opened an issue on the JS repo to tackle that: open-telemetry/opentelemetry-js#4035

[chalin]

Ok, I'd vote to clarify the status on the JS landing page first.

If we do add a warning, it should be short -- especially if you're wanting to repeat the warning across several pages (maybe we need a shortcode to help keep things DRY)?

See inline comment.

[chalin]

Regarding the JS status: maybe it should be "mixed" with a footnote clarifying the status?

[svrnm]

I added the note to the hugo.yaml similar to the one we have for docker compose. I use the same wording now on three places: _index, getting-started and manual.

I also rephrased it once again to the following and decided against updating the status table of OTel JS:

Client instrumentation for the browser is experimental and mostly unspecified. If you are interested in helping out, get in touch with the Client Instrumentation SIG

Some rational for that: Upading the status table would be confusing, since the API & SDK for JavaScript in general are following the specification for traces, metrics, logs, etc. What we are looking at here is different from that as it is for Client-side instrumentation (or real user monitoring) which is (a) not solely a problem of the JS community and (b) will likely lead to an additional set of API/SDK specs or make use of existing ones in a certain way.

I took the wording "mostly unspecified" from the [Roadmap - P2: Client Instrumentation (RUM)]:

OpenTelemetry JS has technically supported capturing spans from web browsers since its first releases, however this behavior was mostly unspecified

[chalin]

Well done with the refactoring. LGTM ✨

[chalin]

Oops, missed that: this sentence should end with a period.

[svrnm]

let's have a follow up PR then for the period.

[chalin]

See #3134.