add blog post announcing proposed changes/oteps for stability work

[austinlparker]

Adds a blog from the GC discussing proposed changes to stability and future project work/direction. cc @open-telemetry/governance-committee

[julianocosta89]

One point that is not mentioned on the blog, but it is important to help users navigate the project is repositories structure.
I was discussing SemConv with a colleague and I've noticed that each programming language has a different way of organizing them:

• .NET has it on the contrib repo: https://github.com/open-telemetry/opentelemetry-dotnet-contrib/tree/main/src/OpenTelemetry.SemanticConventions
• Go on the core repo: https://github.com/open-telemetry/opentelemetry-go/tree/main/semconv/v1.37.0
• Java on a separate repo: https://github.com/open-telemetry/semantic-conventions-java

It would be great if we could follow the same pattern across all languages.

[dmathieu]

I wonder if this post should emphasize more that all these are proposals that (I think and hope) need to be properly discussed with maintainers and contributors before they are finalized, and that the way they end up being implemented may change based on discussions with all the stakeholders of the project.

[pichlermarc]

Big change. Personally, I love this idea. 🙌

I think this aligns very well with the the idea behind the JS SIG's focus-topic selection criteria - having backing for something like this on a project-wide level AND having this communicated so publicly sounds like it has the potential to be a huge boost to stabilization efforts.

[evan-bradley]

Mostly just wordsmithing suggestions right now, thanks for putting this together!

[alolita]

Added comments inline.

[mx-psi]

Content LGTM, this would probably be more forceful if it's coming from the whole GC than from a single person individually but I am fine with either

[trask]

I'm not sure that the Semconv SIG is in agreement with this statement yet:

introducing alpha/beta stability

I believe the Semconv SIG preference is to decouple telemetry stability from semconv stability

meaning that instrumentation libraries can produce "stable telemetry" which doesn't break dashboards or alerts without a major version bump in the instrumentation library

but that is independent to whether or not it follows any stable semantic conventions

[austinlparker]

note to self: in tldr characterize this as changing of the 'audience' for otel publicly to be more of a product/end user focus rather than spec artifacts -- our external stability should be more about artifact stability/usability rather than the internal spec stability markers that we need for uncoordinated improvement of sdks/apis/etc

[tedsuo]

Do we need to turn discussions on for this? Could we stick to issues?

[austinlparker]

given that this is probably a multi-threaded topic and issues don't work great for that, I think a discussion is a good venue for the overall conversation, especially since the individual OTEPs will be better at hashing out single-threaded details?