Clarify prototyping requirements for semantic convention stability

[tedsuo]

Our current protocol for stabilizing semantic conventions works like this:

• propose spec changes for a semantic convention
• prototype conventions in two or three languages (one library per language)
• mark convention as stable
• update all current instrumentation in various contrib repos

A flaw in this approach is that while prototyping across different languages is a good requirement for testing API design and SDK functionality, it does not necessarily uncover issues that may be present in a subset of libraries within the same language.

For example, when stabilizing HTTP, we discovered the following:

• Some libraries require signed HTTP requests, which was incompatible with the requirement that the spanID change on every retry.
• Some HTTP libraries were at different levels of abstraction, with access to different lifecycle hooks and information. The proposed semantic conventions did not address this effectively.

It would have been unfortunate if we had only discovered these issues after the conventions were marked stable, and the spec working group was disbanded. And it seems likely that a number of semantic conventions will face similar situations – for example, the wide variety of database clients we want to instrument.

To close this gap, I recommend that the charter for each semantic convention working group be extended, to include a period where the conventions are marked as "frozen" or "release candidate" in the spec, while the group participates in porting instrumentation libraries to the new spec – possibly on a branch to avoid thrash.

cc @trask

[trask]

I've opened #3279 to track marking the HTTP semantic conventions as stable frozen